Token management system, token management method, program
The token management system addresses the challenge of accommodating diverse restrictions in electronic transactions by generating and managing tokens with specific conditions, ensuring secure and compliant usage.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- JCB CO LTD
- Filing Date
- 2024-12-18
- Publication Date
- 2026-06-30
AI Technical Summary
Existing token management systems struggle to accommodate various restrictions and conditions in electronic transactions and procedures, limiting their flexibility and security.
A token management system that includes an acquisition unit to obtain restriction information, a generation unit to create tokens with specific restrictions, and an assignment unit to distribute these tokens to user devices, allowing for fine-grained control and verification of token legitimacy.
Enables flexible and secure management of tokens with various restrictions, ensuring compliance with service conditions and enhancing security in electronic transactions.
Smart Images

Figure 2026106831000001_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a token management system, a token management method, and a program.
Background Art
[0002] Conventionally, a mechanism for conducting transactions using so-called tokens has been known.
[0003] A token refers to something used as evidence. For example, as objects, it includes currency, gift certificates, tickets, vouchers, coupon tickets, and the like.
[0004] Also, a token refers to data having a role as evidence in the digital space, and includes, for example, electronic certificates, electronic tickets, one-time passwords, virtual currencies issued on a blockchain, and the like. In addition, it may be an identifier such as a Payment Token or certificate data such as a Verifiable Credential. That is, a token can be treated as data having some electronic value digitally.
Prior Art Documents
Patent Documents
[0005]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0006] Patent Document 1 describes "settlement tokens". Settlement tokens ensure security by using, for example, a mechanism of one-time tokens that can be used only once. Also, Patent Document 1 describes "usage history tokens". Usage history tokens are linked to the user's history information, and for example, using the usage history tokens, it is possible to access the train usage history of the corresponding user.
[0007] In electronic transactions and procedures, various conditions may be imposed depending on the content, but the system described in Patent Document 1 has difficulty accommodating such conditions.
[0008] Therefore, the present invention has been made in view of the above, and aims to provide a mechanism that can use tokens to address various restrictions on electronic transactions and electronic procedures. [Means for solving the problem]
[0009] A token management system according to one aspect of this disclosure includes: an acquisition unit that acquires restriction information from a device of a business operator that provides restriction information, which is information regarding predetermined restrictions when using a predetermined service; a generation unit that generates tokens for using the predetermined service under the predetermined restrictions based on the restriction information; and an assignment unit that assigns the generated tokens to a user device of a user who uses the predetermined service.
[0010] A token management method relating to another aspect of this disclosure includes a computer obtaining restriction information from a device of a service provider that provides restriction information, which is information relating to predetermined restrictions on using a predetermined service; generating a token for using the predetermined service under the predetermined restrictions based on the restriction information; and granting the generated token to a user device of a user using the predetermined service.
[0011] A program relating to another aspect of this disclosure causes a computer to perform the following actions: obtain restriction information from a device of a service provider that provides restriction information, which is information relating to predetermined restrictions on using a predetermined service; generate a token for using the predetermined service under the predetermined restrictions based on the restriction information; and grant the generated token to a user device of a user using the predetermined service.
[0012] In this invention, "part," "device," and "system" do not merely mean physical means, but also include cases where the functions of the "part," "device," or "system" are realized by software. The software may be, for example, a program (smart contract) that operates on a blockchain. Furthermore, even if the functions of one "part," "device," or "system" are realized by two or more physical means or devices, the functions of two or more "parts," "devices," or "systems" may be realized by one physical means or device. [Effects of the Invention]
[0013] According to aspects of the present invention, a mechanism can be provided that can accommodate various restrictions on electronic transactions and electronic procedures using tokens. [Brief explanation of the drawing]
[0014] [Figure 1] This figure shows an overview of the token management system 1 according to this embodiment. [Figure 2] This figure shows a schematic configuration of the token management system 1 according to this embodiment. [Figure 3] This figure shows an example of the hardware configuration of each device in the token management system 1 according to this embodiment. [Figure 4] This figure shows an example of the functional configuration of the token management device 10 according to this embodiment. [Figure 5] This figure shows an example of restriction information D151 according to this embodiment. [Figure 6] This figure shows an example of token information D152 according to this embodiment. [Figure 7] This figure shows an example of the functional configuration of the user device 20 according to this embodiment. [Figure 8] This figure shows an example of the functional configuration of the authorization device 30 according to this embodiment. [Figure 9] This figure shows an example of the functional configuration of the service provision device 40 according to this embodiment. [Figure 10]It is a diagram showing an example of the processing of the wallet system according to this embodiment. [Figure 11] It is a diagram showing an example of the token information D153 according to this embodiment.
Mode for Carrying Out the Invention
[0015] Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, the embodiments described below are merely examples, and there is no intention of excluding various modifications and applications of technologies not explicitly described below. That is, the present invention can be implemented with various modifications (such as combining each embodiment) without departing from its gist. Also, in the following description of the drawings, the same or similar parts are denoted by the same or similar reference numerals.
[0016] <Configuration Outline> FIG. 1 is a diagram showing an outline of a token management system 1 according to an embodiment of the present invention. Here, it is assumed that token A is used as an electronic ticket for entering a certain amusement facility (hereinafter sometimes simply referred to as "Facility A"). Also, token A is restricted to be valid only for one year.
[0017] For example, the token may be issued using a blockchain. Also, the token may be stored and managed as an "electronic value" in a virtual container called a "wallet" associated with the user device 20. The wallet may be an online wallet provided to users of the wallet service. Here, a general mechanism for managing electronic value by the wallet is adopted, and detailed description thereof is omitted here.
[0018] The token management system 1 is outlined below with reference to Figure 1. (1) For example, user A operates user device 20 to request token management device 10 to issue an electronic ticket (token A) for entry into facility A to user device 20 associated with A. Here, token A is assumed to have a validity period of one year. (2) In order to generate token A with a validity period of one year, token management device 10 requests information regarding predetermined restrictions on the token (hereinafter referred to as "restriction information") from the authorization device 30 and obtains the restriction information. The restriction information indicates that "the validity period is one year". Here, the authorization device 30 is an information processing device managed by the business operator that provides the restriction information. (3) Based on the token issuance request and the restriction information, token management device 10 generates token A. (4) Token management device 10 issues token A, and the issued token A is sent to user device 20. (5) User A operates user device 20 to transmit token A to service provision device 40 at facility A. Here, for example, user A may operate user device 20 to present token A as an electronic ticket to the service provider of facility A. (6) The service provider device 40 verifies the validity of token A, and if there is no problem with the validity of token A (i.e., if token A is presented within the validity period of "one year"), the user will be able to enter facility A using token A on user device 20.
[0019] Thus, the token management system 1 is a system that combines a mechanism for issuing tokens to enable the service and a mechanism for managing restriction information associated with the tokens, and for confirming the period and number of times a user can use the service. It should be noted that the above-described embodiment is merely one embodiment of the present invention, and the present invention is not limited to the above embodiment.
[0020] The provider of the token management system 1 may, for example, collect usage fees from users, authorization providers, and service providers. For example, the provider may collect fees from users for issuing tokens based on token issuance requests, fees from authorization providers for using the token management system 1 as a token issuance platform, and fees from service providers for verifying the legitimacy of tokens. The token management device 10 may be equipped with a function for settling such various fees.
[0021] Figure 2 is a diagram showing the schematic configuration of the token management system 1 according to this embodiment. As shown in Figure 2, the token management system 1 includes a token management device 10, a user device 20, an authorization granting device 30, and a service granting device 40.
[0022] The token management system 1 is connected via network N to a token management device 10, a user device 20, an authorization granting device 30, and a service granting device 40. Each device is configured as a single information processing device, but it may be composed of one or more different information processing devices. Furthermore, Figure 2 is merely an example, and the number of devices is not limited to those shown.
[0023] The token management device 10 is an information processing device that performs processing related to token management. For example, it acquires a token issuance request and restriction information, and generates a predetermined token. The restriction information may be recorded on the token, or it may be managed in association with the token so that it can be referenced.
[0024] Furthermore, the token management device 10 manages information about the issued tokens. For example, based on a request from the service provider device 40 that has received a token from the user device 20, the token management device 10 may verify the validity of the token. Verification of validity may involve checking the restriction information set on the token, for example, to confirm whether the token is within its validity period.
[0025] Furthermore, the token management device 10 may update the information of the tokens it manages. For example, if a token has a limited number of uses, the device may reduce the remaining number of valid uses of the token after verifying its validity.
[0026] Furthermore, the token management device 10 may manage the settlement process between each device that uses the token management system 1. For example, the token management device 10 may use the account information of the person in charge or business operator associated with the user device 20, the authorization device 30, and the service provision device 40 to bill for each charge and process settlements.
[0027] User device 20 is a device used by a user of the service, and may be, for example, a smartphone, tablet, personal computer, etc. User device 20 may be, for example, a terminal on which an application for handling tokens is installed.
[0028] The authorization device 30 is an information processing device managed by the authorization provider, and is an information processing device that sends restriction information to the token management device 10, such as that the token is "valid for one year" or "usable 10 times".
[0029] An authority provider is, for example, an entity that sets restrictions such as an expiration period or number of uses on tokens used to access services provided to users, and provides information about these restrictions. An authority provider may also be, for example, a business that provides a smart contract for setting restriction information on tokens on the blockchain. Furthermore, the authority provider may be the same as the service provider offering the service.
[0030] The service provider device 40 is an information processing device managed by the service provider, and is an information processing device that provides services to the user. The service provider device 40 may also request the token management device 10 to verify the validity of the token presented by the user device 20.
[0031] Network N may be any of the following: the Internet, LAN, telephone line, corporate network, mobile communication network, Bluetooth®, WiFi (Wireless Fidelity), other communication lines, or combinations thereof, and may be wired or wireless.
[0032] <Hardware Configuration> Figure 3 shows an example of the hardware configuration of each device (token management device 10, user device 20, authorization provision device 30, and service provision device 40) according to this embodiment. Each device has a processor 11 such as a CPU (Central Processing Unit) corresponding to an arithmetic unit, a storage unit 12, a transmission / reception unit 13, and an input / output unit 14. These components are connected to each other via a bus so that data can be transmitted and received from each other.
[0033] The storage unit 12 is composed of, for example, memory, an HDD (Hard Disk Drive), and / or an SSD (Solid State Drive). The storage unit 12 may store various information necessary for the execution of processing by the processor 11 (for example, programs executed by the processor 11).
[0034] The transmitting / receiving unit 13 is a device that communicates via the network N, and may include, for example, a network card, a communication module, a chip, an antenna, etc. The transmitting / receiving unit 13 may also include a transmitting unit that transmits various types of information via the network N, and / or a receiving unit that receives various types of information via the network N.
[0035] The input / output unit 14 includes, for example, an input unit such as a keyboard, touch panel, mouse, and / or microphone, and an output unit such as a display and / or speaker. The input unit receives various types of information from the user. The output unit may also include a display unit that displays various types of information.
[0036] The configuration described above is merely an example. Each device may omit some of the hardware shown in Figure 3, or may include hardware not shown in Figure 3. Furthermore, the hardware shown in Figure 3 may be composed of one or more chips.
[0037] <Functional Configuration> (Token management device) Figure 4 shows an example of the functional configuration of the token management device 10. The token management device 10 comprises an acquisition unit 101, a generation unit 102, a management unit 103, and an assignment unit 104. The means by which each of these functional units is realized are, for example, by the processor 11 executing a program stored in the storage unit 12 shown in Figure 3.
[0038] The acquisition unit 101 is, for example, a functional unit that acquires a token issuance request. The token issuance request may be acquired directly from the user device 20, or it may be acquired from the authorization device 30 that has been requested to issue a token by the user device 20.
[0039] A token issuance request includes information indicating the service to which the token will be sent, and information regarding the destination of the token (i.e., information about the user device 20 where the token will be stored).
[0040] Furthermore, the acquisition unit 101 acquires restriction information from the authorization device 30. For example, it acquires it from the authorization device 30 that has received a token issuance request from the user device 20.
[0041] Alternatively, after the acquisition unit 101 acquires a token issuance request from the user device 20, it may request and acquire restriction information from the authorization providing device 30.
[0042] Restriction information includes, for example, information used to set predetermined limits on a token, such as the token's validity period and the number of times it can be used. Other restriction information may also include the maximum transaction amount and information about the services on which the token can (or cannot) be used.
[0043] Multiple restriction pieces of information may be associated with a token. For example, it may include restrictions on the token's validity period and restrictions on the number of times the token can be used. Alternatively, it may include restrictions on the token's validity period and restrictions that make it valid only on specific days of the week. In this way, multiple restriction pieces of information can be set for a token, allowing for fine-grained control over the permissions of users using the service.
[0044] Figure 5 shows an example of restriction information D151. As shown in Figure 5, restriction information includes [ID] and [Restriction]. [ID] contains a code to identify the restriction information. [Restriction] stores information indicating the restriction to be set on the token. For example, the restriction information for ID#1 stores information indicating a restriction that limits the validity period of the token to 2 years. It also stores information indicating a restriction that limits the location where the token can be used to a facility called "ABC Park". The restriction information for ID#2 stores information indicating a restriction that limits the validity period of the token to 1 year. It also stores information indicating a restriction that limits the token to being usable only on Mondays. Furthermore, it stores information indicating a restriction that limits the token to being valid only 10 times. In this way, restriction information stores multiple restrictions, and the number and types of restrictions can be set as appropriate. This makes it possible to generate tokens that include various restriction information when tokens are generated in association with restriction information.
[0045] The generation unit 102 is a functional unit that generates a token with predetermined restrictions based on the token issuance request and / or restriction information acquired by the acquisition unit 101.
[0046] Token generation involves generating a token as electronic data based on a token issuance request, without using restriction information. Alternatively, token generation may involve recording restriction information on the token, or generating the token and then associating the token data (e.g., identifier) with the restriction information data. In this way, it is possible to generate tokens that are not associated with restriction information, as well as to obtain various restriction information from authority providers and generate tokens that include various restriction information. This allows, for example, the generation of tokens that combine restriction information according to the content of the service being provided.
[0047] The management unit 103 is a functional unit that manages the tokens generated by the generation unit 102. The management unit 103 may associate information indicating the generated token (for example, an identifier) with restriction information corresponding to the generated token, and store and manage this information as "token information" in the storage unit 12.
[0048] Token information is information that indicates a token generated by the generation unit 102. Token information may also be managed by associating token-representing data (e.g., an identifier) with restriction information. By managing token information, it is possible to perform processes to verify the legitimacy of the token used by the user, such as whether the token is still valid or how many times the token can be used by the user.
[0049] Figure 6 shows an example of token information D152. Token information D152 includes [Token ID] and [Status]. [Token ID] stores information about a code that identifies the generated token. [Status] stores information for querying whether the restriction information has been applied to the corresponding token and whether it is currently valid. For example, for token ID #1, if the restriction information "Validity Period: 2 years" is applied, the validity period is "from April 1, 2020 to March 31, 2022".
[0050] Furthermore, the management unit 103 verifies the validity of the token. For example, the management unit 103 verifies the validity of a token for which a verification request has been received from the service provider 40. A verification request is sent, for example, from the service provider 40 when a user presents a token to the service provider (service provider 40) using the user device 20.
[0051] Using Figure 6 as an example, if the token ID of the token requested for verification is #1, the management unit 103 checks whether the token requested for verification was used during the validity period of the token information (from April 1, 2020 to March 31, 2022). If it is within the validity period, it determines that there is no problem with the validity of the token and sends information to the service provider device 40 that there is no problem with the validity of the token. As a result, the service provider device 40 can verify the validity of the token and then provide the service to the user.
[0052] Furthermore, after verifying the validity of the token information, the management unit 103 may update the token information as necessary. For example, if the token information of the managed token has a set number of valid uses, the number of valid uses of the token may be reduced by one each time the validity is verified.
[0053] Taking Figure 6 as an example, if the validity of token ID #2 is confirmed, the management unit 103 may update the token information status from "10 times" to "9 times". In addition, when the management unit 103 notifies the result of the token's validity confirmation, it may also send information about the remaining number of valid uses of the token to the service provider device 40. This allows the service provider device 40 to share information about the remaining number of valid uses of the token with the user device 20.
[0054] Furthermore, the management unit 103 may calculate and settle fees for various processes related to tokens handled by the token management system 1. These processes include, for example, issuing tokens, verifying the validity of tokens, and updating token information. When settling fees, payment information linked to the account information of each device using the token management system 1 may be used. In this way, the management unit 103 can manage the various fee transactions conducted by the provider of the token management system 1.
[0055] The granting unit 104 is a functional unit that grants the generated tokens to the user.
[0056] The granting of tokens may, for example, involve sending the generated tokens to the user device 20 via electronic communication, or it may involve executing a smart contract on the blockchain to associate the generated tokens with a wallet address linked to the user device 20. Thus, the method of granting tokens is not particularly limited, as long as it enables the user to use a predetermined service based on the generated tokens.
[0057] (User equipment) Next, the user device 20 will be described. Figure 7 shows an example of the functional configuration of the user device 20. The user device 20 includes a storage unit 201, a communication unit 202, a UI (User Interface) unit 203, and a control unit 204. The means implemented by each of these functional units are realized, for example, by the processor 11 executing a program stored in the storage unit 12 shown in Figure 3.
[0058] The memory unit 201 stores, for example, tokens issued by the control unit 204 by the token management system 1. The tokens store, for example, restriction information.
[0059] The communication unit 202 is a functional unit that uses the transmitting / receiving unit 13 to perform various communications with the token management device 10, the authorization provision device 30, and the service provision device 40.
[0060] The UI unit 203 has the function of receiving various inputs from the user and the function of displaying various screens of the token management system 1 on the display to the input / output unit 14. In addition, if the token is an electronic ticket, for example, the UI unit 203 displays a screen showing the token on the input / output unit 14 of the user device 20 based on the user's operation.
[0061] The control unit 204, in cooperation with the token management device 10, provides various functions necessary for using the token management system 1. For example, the control unit 204 provides a function to send a token issuance request to the token management device 10. The control unit 204 also provides a function to send a token issuance request to the authorization providing device 30. Furthermore, the control unit 204 provides a function to send tokens obtained from the token management device 10 to the service providing device 40.
[0062] (Authority granting device) Next, the authorization granting device 30 will be described. Figure 8 is a diagram showing an example of the functional configuration of the authorization granting device 30. The authorization granting device 30 includes a storage unit 301, a communication unit 302, a UI unit 303, and a control unit 304. The means implemented by each of these functional units are realized, for example, by the processor 11 executing a program stored in the storage unit 12 shown in Figure 3.
[0063] The memory unit 301 stores, for example, restriction information to be set for the token.
[0064] The communication unit 302 has the function of performing various types of communication with the token management device 10, the user device 20, and the service provision device 40 using the transmitting / receiving unit 13.
[0065] The UI unit 303 has the function of receiving various inputs from the authorization provider and the function of displaying various screens related to the token management system 1 on the display to the input / output unit 14. In addition, the UI unit 303 displays a screen for creating restriction information on the input / output unit 14 of the authorization providing device 30 based on the operation of the authorization provider.
[0066] The control unit 304, in cooperation with the token management device 10, provides various functions necessary for using the token management system 1. For example, the control unit 304 provides a function to send a token issuance request to the token management device 10. The control unit 304 also provides a function to send restriction information to the token management device 10.
[0067] (Service provision device) Next, the service provision device 40 will be described. Figure 9 is a diagram showing an example of the functional configuration of the service provision device 40. The service provision device 40 includes a storage unit 401, a communication unit 402, a UI unit 403, and a control unit 404. The means implemented by each of these functional units are realized, for example, by the processor 11 executing a program stored in the storage unit 12 shown in Figure 3.
[0068] The storage unit 401 stores, for example, token information transmitted from the user device 20.
[0069] The communication unit 402 has the function of performing various communications with the token management device 10, the user device 20, and the authorization granting device 30 using the transmitting / receiving unit 13.
[0070] The UI unit 403 has the function of receiving various inputs from the service provider and the function of displaying various screens related to the token management system 1 on the display to the input / output unit 14. In addition, if the token is an electronic ticket, for example, the UI unit 403 displays a screen for verifying the token on the input / output unit 14 of the service provision device 40 based on the operation of the service provider.
[0071] The control unit 404, in cooperation with the token management device 10, provides various functions necessary for using the token management system 1. For example, the control unit 404 provides a function to request the token management device 10 to verify the validity of the token.
[0072] <Processing Procedure> Referring to Figure 10, the processing procedure performed in the token management system 1 according to one embodiment of the present invention will be described. Figure 10 is a sequence diagram showing an example of the processing procedure in the token management system 1.
[0073] First, the user operates the user device 20 and sends a request for the issuance of the necessary tokens in order to use the desired service. The token management device 10 receives the token issuance request (step S11).
[0074] Next, the token management device 10 obtains restriction information from the authorization device 30 (step S12). At this time, it may also request restriction information by linking a token issuance request to the authorization device 30.
[0075] Next, the token management device 10 generates a token with predetermined restrictions based on the token issuance request and restriction information, and sends it to the user device 20 (step S13).
[0076] Next, the user operates the user device 20 and uses the token. For example, the user sends the token from the user device 20 to the service provider device 40 in order to use the service (step S14).
[0077] Next, the service provider 40 requests the token management device 10 to verify the validity of the token. The token management device 10 receives this request (step S15).
[0078] Next, the token management device 10 verifies the validity based on the request for verification of validity. At that time, for example, it updates the validity count of the token (step S16).
[0079] Next, the token management device 10 sends the result of verifying the validity of the token to the service provision device 40 (step S17). At this time, if the token information has been updated, it may also send information indicating the details of the update to the token information.
[0080] Next, once its legitimacy is confirmed, the user device 20 receives a service from the service provider device 40 (step S18).
[0081] The steps described above are merely examples; the order of some steps may be changed, steps not shown may be added, and some steps may be omitted.
[0082] <Variation> The following describes a modified version of the token management device 10 according to one aspect of the present invention. Only configurations that differ from the token management device 10 described above will be described; unless otherwise specified, the configurations are the same as those described above.
[0083] In the modified token management device 10, for example, restriction information may be added to already created tokens.
[0084] The acquisition unit 101 acquires, for example, a request for additional restriction information from the authorization device 30 or the service provider 40. The request for additional restriction information may include information (for example, an identifier) indicating the token to which the restriction information is to be added.
[0085] The management unit 103 instructs the acquisition unit 101 to acquire the additional restriction information from the authorization device 30.
[0086] The generation unit 102 generates a token with additional restriction information added, based on the token information of the token and the additional restriction information. The generated token is sent to the user device 20 by the granting unit 104.
[0087] Furthermore, the generation unit 102 may acquire the token from the user device 20 and record additional restriction information on the token.
[0088] The management unit 103 reflects the information of the token to which restriction information has been added in the token information. In D153 of Figure 11, it is shown that restriction information has been added to token ID #1 (i.e., the information for "DEF Arena").
[0089] This enables a mechanism to add restriction information to tokens later, allowing for changes to token specifications at the request of, for example, authorization providers or service providers, thus enabling more flexible token generation.
[0090] <Summary> As described above, the token management system 1 according to this embodiment includes an acquisition unit 101 that acquires restriction information from a device of a business operator that provides restriction information, which is information regarding predetermined restrictions when using a predetermined service; a generation unit 102 that generates tokens for using a predetermined service under predetermined restrictions based on the restriction information; and an assignment unit 104 that assigns the generated tokens to the user device of a user who uses the predetermined service.
[0091] This allows for a mechanism that enables user access control through tokens. Furthermore, since token restriction information can be obtained from various restriction information providers, it becomes possible to provide a mechanism that imposes various restrictions using tokens on users accessing specific services.
[0092] Furthermore, the token management system 1 includes a management unit 103 that manages token information, which is information that associates information indicating a generated token with restriction information. The acquisition unit 101 receives a request to verify the legitimacy of the token from the device of a business operator that has been requested to provide a predetermined service based on the generated token. The management unit 103 verifies the legitimacy of the token based on the token information and sends the verification result to the business operator's device.
[0093] This allows the token management system 1 to verify the legitimacy of tokens presented by users, and enables service providers to ensure security regarding the use of services using tokens.
[0094] Furthermore, the restriction information includes information that is updated in accordance with the provision of a predetermined service, and when a predetermined service is provided to the user, the management unit 103 updates the restriction information included in the token information according to the content of the predetermined restriction.
[0095] This allows for a mechanism to control the permissions granted to users to use a service by updating restriction information as needed when a user accesses a designated service based on a token.
[0096] The embodiments described above are provided to facilitate understanding of the present invention and are not intended to limit its interpretation. The elements, arrangement, materials, conditions, shapes, and sizes of the embodiments are not limited to those exemplified and can be modified as appropriate. Furthermore, it is possible to partially substitute or combine the configurations shown in different embodiments. [Explanation of Symbols]
[0097] 1...Token management system, 10...Token management device, 20...User device, 30...Authority granting device, 40...Service providing device, 11...Processor, 12...Storage unit, 13...Transmit / receive unit, 14...Input / output unit, 101...Acquisition unit, 102...Generation unit, 103...Management unit, 104...Assignment unit.
Claims
1. An acquisition unit that acquires restriction information from a device of a business operator that provides restriction information, which is information regarding predetermined restrictions when using a predetermined service, A generation unit generates a token for using the predetermined service under the predetermined restrictions based on the aforementioned restriction information, A granting unit that grants the generated token to the user device of a user who uses the predetermined service, A token management system equipped with [features / equipment].
2. The system further includes a management unit for managing token information, which is information that associates the generated token information with the restriction information. The acquisition unit is, From the device of the business operator that has been requested to provide the predetermined service based on the generated token, a request to verify the validity of the token is obtained. The aforementioned management department, Based on the aforementioned token information, the validity of the token is verified, and the result of the verification is sent to the operator's device. The token management system according to claim 1.
3. The aforementioned restriction information includes information that is updated in accordance with the provision of the aforementioned specified service, The aforementioned management department, When the predetermined service is provided to the user, the restriction information included in the token information is updated according to the content of the predetermined restriction. The token management system according to claim 2.
4. Computers Obtaining the restriction information from the device of a service provider that provides restriction information, which is information regarding the restrictions on using a specified service, Based on the aforementioned restriction information, a token is generated to use the predetermined service under the predetermined restrictions, The generated token is to be assigned to the user device of a user who uses the predetermined service, A token management method that includes this.
5. On the computer, Obtaining the restriction information from the device of a service provider that provides restriction information, which is information regarding the restrictions on using a specified service, Based on the aforementioned restriction information, a token is generated to use the predetermined service under the predetermined restrictions, The generated token is to be assigned to the user device of a user who uses the predetermined service, A program that executes the command.