Information processing device, information processing method, and program

Abstract

To realize more secure exchange of personal information between a data provider (DP) and a data consumer (DC).SOLUTION: An information processing device transmits a first identifier in response to a user identifier issuance request transmitted from a DC, transmits a second identifier in response to a user identifier issuance request transmitted from a DP, receives from the DC a ticket issuance request including information specifying user data requested by the DC, a first identifier, and the DP to which the request is made, issues a data request ticket corresponding to the ticket issuance request, transmits a ticket identifier of the issued data request ticket to the DC, and transmits the data request ticket corresponding to the ticket identifier to the DP when the ticket identifier is received from the DP. The ticket issuance request includes the first identifier. The data request ticket transmitted to the DP includes the second identifier corresponding to the first identifier.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present disclosure relates to an information processing apparatus, an information processing method, and a program.

Background Art

[0002] Patent Document 1 discloses an electronic commerce system capable of conducting commodity sales without transmitting personal information from a purchaser to a seller. Specifically, when a proxy server acts on behalf of a client to access a commodity information providing server, the proxy server transmits a user ID to the commodity information providing server. When the commodity information providing server receives an instruction to purchase a commodity, it transmits the commodity ID and the user ID to the proxy server. Then, the proxy server derives delivery destination information based on the user ID, and transmits the commodity ID and the delivery destination information to a delivery management server.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] One aspect of the present disclosure aims to provide a technology capable of more securely realizing the exchange of personal information between a data provider and a data consumer.

Means for Solving the Problems

[0005] One aspect of this disclosure is an information processing device for mediating the exchange of user data between a data consumer and a data provider, which includes transmitting a first identifier in response to a request from the data consumer to issue a user identifier to a user, transmitting a second identifier in response to a request from the data provider to issue a user identifier to the user, and receiving from the data consumer information that identifies the user data requested by the data consumer, the first identifier, and the requesting data provider identifier An information processing device comprising: a control unit that performs the following: receiving a ticket issuance request including; issuing a data request ticket corresponding to the ticket issuance request; transmitting the ticket identifier of the issued data request ticket to the data consumer; and, when the ticket identifier is received from the data provider, transmitting a data request ticket corresponding to the ticket identifier to the data provider, wherein the ticket issuance request includes the first identifier, and the data request ticket transmitted to the data provider includes the second identifier corresponding to the first identifier. [Effects of the Invention]

[0006] According to the manner of this disclosure, it is possible to securely exchange personal information between data providers and data consumers. [Brief explanation of the drawing]

[0007] [Figure 1] This figure shows an overview of a data exchange system according to one embodiment. [Figure 2] This figure shows an example of an ID correspondence table held by each device in one embodiment. [Figure 3] This is a sequence diagram showing the data exchange process in one embodiment. [Figure 4] This is a sequence diagram showing the dummy ID issuance process in one embodiment. [Figure 5]This is a state transition diagram for data request tickets and a flowchart of the state management process in one embodiment. [Modes for carrying out the invention]

[0008] As the value of data has become widely recognized, many services are accumulating user data. It is now common practice for data holders to provide data APIs as data providers to make their user data available to data consumers.

[0009] In such data exchange systems, billing arbitration and data matching prevention become challenges. In this embodiment, the platform provider mediates data exchange between data providers and data consumers, and solves the above challenges through a novel mediation method.

[0010] In this disclosure, platform provider, data provider, and data consumer are all terms that refer to devices, not businesses or individuals. Furthermore, in this disclosure, platform providers may also be referred to as PF, data providers as DP, and data consumers as DC.

[0011] One embodiment of this disclosure is an information processing device (platformer; PF) that mediates the exchange of user data between a data consumer (DC) and a data provider (DP). A data provider is a device that provides user data, and a data consumer is a device that obtains and uses user data from a data provider.

[0012] The PF according to this embodiment includes a control unit, which transmits a first identifier in response to a request from the DC to issue a user identifier to a user, and transmits a second identifier in response to a request from the DP to issue a user identifier to the same user. For example, the PF may include a storage unit that stores the first identifier, the second identifier, and the third identifier in association with each other. The DC holds the first identifier in association with the user identifier, and the DP holds the second identifier in association with the user identifier. It is common for the user identifiers used by the DC and the DP to be different, even for the same user. For example, if the PF stores the user identifier in the DC and the user identifier in the DP in association with each other for a user who exchanges data, the user identifiers in both can be converted to each other. In this case, the control unit of the PF does not store the user identifiers used by the DC and DP themselves, but identifies and stores the user using a dummy identifier issued by the PF. Therefore, the dummy identifier issued by the PF to the DC corresponds to the first identifier, and the dummy identifier issued by the PF to the DP corresponds to the second identifier. The PF issues its own third identifier corresponding to the pair of first and second identifiers, and stores the first, second, and third identifiers in association. Therefore, the PF can convert between these three identifiers. The PF may also be configured to derive the first and second identifiers. For example, the control unit of the PF may derive the first identifier by applying a DC conversion process to the third identifier, and derive the second identifier by applying a DP conversion process to the third identifier.

[0013] The control unit of the PF according to this embodiment also issues a data request ticket when it receives a ticket issuance request from the DC for requesting user data. The ticket issuance request includes information that identifies the user data requested by the DC, the first identifier (a dummy ID for the DC), and the DP to which the request is made. The issued data request ticket includes, for example, information that identifies the user data included in the ticket issuance request, and the third identifier stored in association with the first identifier included in the data request. The control unit of the PF then transmits the ticket identifier of the issued data request ticket to the DC.

[0014] In this embodiment, the control unit of the PF also sends a data request ticket corresponding to the ticket identifier to the DP when it receives a ticket identifier from the DP. At this time, the control unit of the PF stores the third identifier included in the data request ticket in association with the third identifier. The data request ticket is sent to the DP after being replaced with the second identifier (dummy ID for DP).

[0015] In this embodiment, when the DC requests user data from the DP, it first receives a data request ticket from the PF and sends the ticket identifier to the DP to request user data. The DP, upon receiving the data request ticket corresponding to the ticket identifier from the PF, can determine which user and which data the DC is requesting, and then sends the relevant data for that user to the DC. In this way, the exchange of user data between the DP and the DC is completed.

[0016] In this embodiment, the DC does not receive user identifiers in the DP, and the DP does not receive user identifiers in the DC. Therefore, by making it impossible to infer the first identifier from the second identifier, neither the DC nor the DP can associate the user identifiers it holds with the user identifiers held by the other party, thus preventing so-called name matching.

[0017] In addition, since PF does not retain user data, even if the information of PF is leaked, the user data will not be leaked. Also, PF only retains the user's dummy identifier and does not retain the user identifiers used by DP and DC. Therefore, even if the correspondence between the dummy identifiers becomes known due to information leakage, it is impossible to know specifically which user identifiers are associated with each other. From this perspective as well, the present embodiment can prevent name matching.

[0018] In addition, PF can utilize the data request ticket and the access status of DP and DC thereto as evidence for charging or incentive provision, so charging mediation is possible.

[0019] The control unit of PF according to the present embodiment may manage the state of the ticket and notify DC or DP that is presumed to be the cause when the data exchange does not end normally. Specifically, the control unit of PF manages the state of the ticket according to the access from DC and DP to the issued ticket, and when the state of the ticket does not transition to the next state according to the predefined state transition, it may identify whether the cause of the non-occurrence of the transition is in DC or DP, and notify the identified DC or DP. The cause can be identified, for example, based on an error state or a trigger for transition to an error state.

[0020] By doing so, it is possible to identify that the data exchange based on the ticket has not completed normally, and also to identify whether the cause is in DC or DP. In addition, the notification can be used to cause the data exchange to be performed normally or to provide an opportunity to prove that the cause of the error is not itself.

[0021] Other embodiments of the present disclosure are an information processing method or a data exchange mediation method performed by the above information processing apparatus (PF). Further, other embodiments of the present disclosure can be regarded as a computer program for causing a computer to function as the above information processing apparatus (PF), or a computer program for causing a computer to execute the above information processing method. Further, other embodiments of the present disclosure can be regarded as a data exchange system including a platform, a data consumer, and a data provider.

[0022] Hereinafter, embodiments of the present disclosure will be described based on the drawings. The configurations of the following embodiments are examples, and the present disclosure is not limited to the configurations of the embodiments.

[0023] (System Configuration) FIG. 1 is a diagram showing the configuration of a data exchange system according to an embodiment. The data exchange system has a configuration in which a platform (PF) 100, a data consumer (DC) 200, and a data provider (DP) 300 are communicably connected to each other via a network N.

[0024] PF100 is a computer (information processing apparatus) having a CPU 101, a memory 102, and a communication device 103. Programs executable by the CPU 101 are stored in the memory 102. By executing the program, the CPU 101, PF100 functions as a dummy ID issuing unit 110, an ID correspondence table storage unit 120, a user ID conversion unit 130, a ticket issuing management unit 140, and a ticket DB 150.

[0025] DC200 is a computer (information processing apparatus) having a CPU 201, a memory 202, and a communication device 203. Programs executable by the CPU 201 are stored in the memory 202. By executing the program, the CPU 201, DC200 functions as a dummy ID request unit 210, a ticket request unit 220, a data request unit 230, and an ID correspondence table storage unit 240.

[0026] DP300 is a computer (information processing device) having a CPU 301, memory 302, and communication device 303. The memory 302 stores a program that the CPU 301 can execute. When the CPU 301 executes this program, DP300 functions as a dummy ID request unit 310, a ticket request unit 320, a data provision unit 330, and an ID correspondence table storage unit 340.

[0027] Details of each of the above-mentioned functional components will be explained in detail later, referring to other drawings. Note that some or all of the above-mentioned functional components may be implemented by dedicated circuits or devices.

[0028] Network N is a network consisting of a wired communication network and / or a wireless communication network, and communication devices 103, 203, and 303 can communicate with each other via Network N.

[0029] (ID correspondence table) Figures 2(A) to 2(C) show examples of ID mapping tables for PF100, DC200, and DP300, respectively. Here, the same user has accounts in both DC200 and DP300, with the user ID in DC200 (hereinafter also referred to as DC user ID) being DC_A, and the user ID in DP300 (hereinafter also referred to as DP user ID) being DP_A. Furthermore, in PF100, this user is assigned and managed with the user ID PF_A1 (hereinafter also referred to as PF user ID).

[0030] As shown in Figure 2(A), PF100 issues a DC dummy ID 122 and a DP dummy ID 123 for a single PF user ID 121, and manages them in association. Therefore, the user ID conversion unit 130 can convert between PF user IDs (third identifiers), DC dummy IDs (first identifiers), and DP dummy IDs (second identifiers) by referring to the ID correspondence table 120.

[0031] As shown in Figure 2(B), DC200 manages DC user ID 241 in association with DC dummy ID 242 issued to that user by PF100. Therefore, DC200 can convert between DC user ID and DC dummy ID (first identifier).

[0032] As shown in Figure 3(C), the DP300 manages the association between the DP user ID 341 and the DP dummy ID 342 issued to that user by the PF100. Therefore, the DP300 can convert between the DP user ID and the DP dummy ID (second identifier).

[0033] In the example shown in Figures 3(A) to 3(C), specifically, PF100 issues a dummy ID PF_XX for DC200 and a dummy ID PF_ZZ for DP300 to the user PF_A1, and stores these associated IDs. DC200 stores the user ID DC_A associated with the DC dummy ID PF_XX. DP300 stores the user ID DP_A associated with the DP dummy ID PF_ZZ.

[0034] When PF100 receives a dummy ID for DC from DC200, it can obtain the dummy ID for DP for that user and notify DP300. By having each device maintain such an ID correspondence table, users between DC200 and DP300 can be identified via PF100 without any device needing to know the user IDs for other services. Alternatively, PF100 may store only the correspondence between dummy IDs for DC and dummy IDs for DP without using PF user IDs.

[0035] The issuance of dummy IDs is carried out in cooperation with the dummy ID issuance unit 110, the dummy ID request unit 210, and the dummy ID request unit 310. Details of this dummy ID issuance process will be described later with reference to Figure 4.

[0036] (Data exchange processing) Figure 3 is a sequence diagram showing the flow of user data exchange between DC200 and DP300 via PF100. Here, it is assumed that the dummy ID issuance process is complete, and that PF100, DC200, and DP300 each hold the ID correspondence tables shown in Figures 2(A) to 2(C). It is also assumed that the user has completed the authentication process at DC200, and that DC200 knows that the user's user ID is DC_A.

[0037] In step S10, the user accesses DC200 using a user terminal and requests that DC200 retrieve a certain type of user data from DP300. Here, the user terminal provides DC200 with an identifier (DP_ID) for the DP300 providing the data and an identifier (data ID) representing the type of data.

[0038] In step S11, the ticket request unit 220 of DC200 requests PF100 to issue a data request ticket for use in user data exchange between DC200 and DP300. Here, the ticket issuance request includes a dummy ID for DC, the identifier of DC200 (DC_ID), the identifier of the DP300 to which the data request is being made (DP_ID), and the data ID. The dummy ID for DC is obtained by the ticket request unit 220 referring to the ID correspondence table storage unit 240 and obtaining a dummy ID corresponding to the DC user ID. Here, a dummy ID "PF_XX" corresponding to the DC user ID "DC_A" is obtained. Also, the DC_ID is already known as it is its own ID, and the DP_ID and data ID have been notified from the user terminal.

[0039] In step S12, the ticket issuance management unit 140 of PF100 issues a data request ticket and stores the information of the ticket in the ticket DB 150. The data request ticket contains the ticket ID, PF user ID, DC_ID of the data request source, and DC_ID of the data request destination. This includes the P_ID, a data ID representing the type of requested data, and the ticket status. Here, the PF user ID can be obtained by the user ID conversion unit 130 from the DC dummy ID notified by DC200 and the ID correspondence table 120. In this case, the PF user ID "PF_A1" corresponding to the DC dummy ID "PF_XX" is obtained.

[0040] In step S13, the ticket issuance management unit 140 of PF100 sends the ticket ID of the issued data request ticket to DC200.

[0041] In step S14, the data request unit 230 of DC200 sends a data acquisition request to DP300. Specifically, the data request unit 230 sends the ticket ID sent from PF100 in step S13 to DP300 as a data acquisition request.

[0042] In step S15, the ticket request unit 320 of DP300 sends the DP_ID and ticket ID to PF300 to request details of the data request ticket.

[0043] In step S16, the ticket issuance management unit 140 of PF100 retrieves detailed information of the data request ticket corresponding to the received ticket ID from the ticket DB 150 and sends it to DP300. At this time, the ticket issuance management unit 140 replaces the PF user ID included in the data request ticket with a dummy ID for DP using the user ID conversion unit 130, and then sends the detailed information of the data request ticket. Specifically, the PF user ID "PF_A1" is replaced with the DP dummy ID "PF_ZZ". At this point, the ticket issuance management unit 140 transitions the state of the ticket in accordance with the fact that the ticket has been referenced by DP300.

[0044] In step S17, the data provision unit 330 of DP300 refers to the detailed information of the data request ticket and determines whether it can provide the requested user data to DC200. The determination result is either that it can be provided or not, that is, that the data request ticket is accepted or rejected. The data provision unit 330 transmits this determination result to PF100. The ticket issuance management unit 140 of PF100 changes the ticket status in response to whether DP300 accepts or rejects the ticket.

[0045] Steps S18 and beyond are performed when DP300 accepts the ticket. In step S18, the data provision unit 330 of DP300 sends the user data indicated in the data request ticket to DC200. The user is indicated by a dummy ID for DP in the data request ticket, but DP300 can obtain the corresponding DP user ID by referring to the ID correspondence table 340 and can identify which user's user data is being requested. Specifically, it can identify that the dummy ID for DP "PF_ZZ" corresponds to the DP user ID "DP_A".

[0046] In step S19, when the data request unit 230 of DC200 receives user data from DP300, it determines whether to accept or reject the user data and sends the determination result to PF100. The ticket issuance management unit 140 of PF100 changes the ticket state in response to whether DC200 accepts or rejects the user data. If DC200 accepts the user data, DC200 executes processing using the user data. The type of processing executed is not particularly limited in this disclosure.

[0047] Through the above process, DC200 can exchange user data without knowing the user ID in DP300, and DP300 can exchange user data without knowing the user ID in DC200. Furthermore, PF100 can also store the user data itself, and DC200 Furthermore, it is possible to mediate data exchange without maintaining user IDs in the DP300. For these reasons, secure data exchange is achieved.

[0048] (Dummy ID issuance process) The process of issuing dummy IDs will be explained with reference to Figure 4. Note that the process of issuing dummy IDs described here, i.e., the process of associating unique user IDs with dummy IDs in PF100, DC200, and DP300, is merely one example, and can be carried out by any other method.

[0049] In step S20, the user is authenticated by DC200 using the user terminal. At this point, DC200 obtains the user's DC user ID (e.g., DC_A). In step S21, when the user terminal requests DC200 to start data linkage processing, in step S22, the dummy ID request unit 210 of DC200 requests PF100 to issue a dummy ID. The information sent from DC200 to PD100 at this point is the DC identifier, and the DC user ID is not sent.

[0050] In step S23, the dummy ID issuing unit 110 of PF100 generates a new PF user ID and a DC dummy ID, associates them, and stores them in the ID correspondence table 120. The dummy ID issuing unit 110 also issues a new ID token and manages it in association with the PF user ID and the DC dummy ID. In step S24, the dummy ID issuing unit 110 sends the issued DC dummy ID and ID token to DC200. In step S25, the dummy ID request unit 210 of DC200 stores the received DC dummy ID in the ID correspondence table 240, associating it with the DC user ID.

[0051] In step S25, the user terminal sends a data linkage request to DC200 that includes the identifier of the DP300 to which the data linkage will be established. In step 26, DC200 redirects to DP300, passing the ID token received in step S24. In step S27, the user is authenticated by DP300 using the user terminal. At this point, DP300 obtains the user's DP user ID (e.g., DP_A).

[0052] In step S28, the dummy ID request unit 310 of DP300 requests PF100 to issue a dummy ID. Here, the DP identifier and ID token are sent from DP300 to PD100, but the DP user ID is not sent.

[0053] In step S29, the dummy ID issuing unit 110 of PF100 can determine from the ID token which PF user ID and DC dummy ID the request is for issuing a DP dummy ID for. The dummy ID issuing unit 110 issues a new DP dummy ID and stores it in the ID correspondence table 120 in association with the PF user ID and DC dummy ID. In step S30, the dummy ID issuing unit 110 sends the issued DP dummy ID to DP300. In step S31, the dummy ID request unit 310 of DP300 stores the received DP dummy ID in the ID correspondence table 340 in association with the DP user ID. In step S32, DP300 calls back to DC200, and control of the user terminal returns to DC200.

[0054] As described above, the issuance and sharing of dummy IDs for each user ID of PF100, DC200, and DP300, as shown in Figures 2(A) to 2(C), is completed. At this time, the PF user ID, DC user ID, and DP user ID are not notified to other devices, thus preventing account matching.

[0055] In other embodiments, PF100 uses a dummy ID for DC and a dummy ID for DP. The ID may be generated as ciphertext encrypted using encryption keys for DC200 and DP300. For example, the dummy ID issuing unit 110 may generate a new PF user ID in response to a new dummy ID issuance request from a DC, and then generate a DC dummy ID (first identifier) ​​by applying encryption (transformation) to the PF user ID using the DC encryption key. The dummy ID issuing unit 110 may also generate a DP user ID (second identifier) ​​in response to a dummy ID issuance request from a DP by applying encryption (transformation) to the PF user ID identified by the ID token using the DP encryption key. Furthermore, the user ID transformation unit 130 can obtain a DP user ID corresponding to the DC user ID by applying decryption (reverse transformation) to the DC user ID using the DC encryption key, and then applying encryption (transformation) to the DC user ID using the DP encryption key. The same procedure applies to transformation from a DP user ID to a DC user ID. Thus, the PF100 can convert between DC dummy IDs, DP dummy IDs, and PF user IDs without having to maintain DC dummy IDs and DP dummy IDs. In this embodiment, assuming that the secrecy of the encryption key is maintained, leakage of the correspondence table of PF user IDs, DC user IDs, and DP user IDs can also be prevented.

[0056] Furthermore, the dummy ID issuing unit 110 may use the PF user ID (third identifier) ​​itself as the DC dummy ID (first identifier) ​​and the DP dummy ID (second identifier). In this example, a disadvantage arises in that collusion between the DC and DP allows for direct data exchange without the mediation of the PF, but secure data exchange between the DC and DP is possible.

[0057] (Ticket status management and anomaly notification) Refer to Figures 5(A) and 5(B) to explain the state management of data request tickets and the notification process in case data exchange fails to complete successfully. Figure 5(A) is a state transition diagram for data request tickets, and Figure 5(B) is a flowchart representing the state management process for data request tickets.

[0058] As shown in Figure 5(A), the status of a data request ticket changes as follows: when issued in response to a request from DC200, it becomes the unreferenced state S42; when a reference request is made from DP300 (S15 in Figure 3), it transitions to the DP referenced state S43; when DP300 accepts the request (S17), it transitions to the DP received state S44; and when DC200 accepts the user data (S19), it transitions to the DC completed state S45. Furthermore, if there is no reference request from DP300 for a certain period of time while in the unreferenced state S42, it transitions to the DP unreferenced error state S46. In the DP referenced state S43, if there is no notification of acceptance from DP for a certain period of time, it transitions to the DP unaccepted error state S47, and if DP300 rejects it, it transitions to the DP rejected error state S48. In the DP received state S44, if no acceptance notification is received from DC200 within a certain period of time, the system transitions to the DC incomplete error state S49. If DC200 rejects the DP, the system transitions to the DC rejection error state S50.

[0059] As shown in Figure 5(B), after issuing a data request ticket in step S51, the ticket issuance management unit 140 monitors in step S52 whether an event has occurred that would cause a ticket state transition. If the ticket state has transitioned, the ticket issuance management unit 140 determines whether the destination state is an error state (step S53) or a DC completed state (step S54). If the destination state is neither an error state nor a DC completed state, the process returns to step S52 and waits for the next state transition.

[0060] If the DC transitions to the completed state (S54-YES), the ticket issuance management unit 140 deletes or empties the PF user ID from the record of the ticket in the ticket DB 150. This removes the association between the ticket and the user, reducing the risk of information leakage. Alternatively, instead of deleting the PF user ID, the same effect can be achieved by encrypting the PF user ID with a salt (random number).

[0061] If the destination state is one of the error states (S53-YES), the ticket issuance management unit 140 identifies whether the error is caused by DC200 or DP300 in step S56, and notifies the error cause in step S57. The error cause can be defined in advance in relation to the error state. For example, it is conceivable to define that the DP rejection error state S48 and the DC incomplete error state S49 are caused by DC200, and the DP not referenced error state S46, the DP not accepted error state S47, and the DC rejection error state are caused by DP300. Note that this definition is just one example.

[0062] By notifying the source of the error from PF100, the DC200 or DP300 that receives the notification can resolve the cause of the error and proceed with processing again. Alternatively, the DC200 or DP300 may prove to PF100 that it is not responsible for the cause of the error. By notifying the DC200 or DP300 suspected of causing the error in this way, an opportunity is given to resolve the cause of the error and to present evidence to refute the claim.

[0063] PF100 may also use the status of data request tickets to perform billing and incentive payments. Specifically, if a data request ticket successfully transitions to the DC completed state, PF100 may determine that the data exchange has been successfully completed, and may bill DC200 and provide incentive payments to DP300.

[0064] (Billing process) PF100 may also mediate the exchange of incentives based on completed data request tickets. For example, PF100 may extract completed data request tickets for each specific DC and DP pair at regular intervals (e.g., daily or monthly), aggregate the extracted tickets, and determine the total incentive amount based on the aggregation results. PF100 then reports the total incentive amount and its calculation results to DC200 and DP300. The provision of incentives from DC200 to DP300 may or may not be mediated by PF100.

[0065] The total incentive amount may be determined based on the number of data requests (number of tickets) or based on the size of the data sent. When using the size of the data sent, it is preferable to store the size of the data already sent in the data request ticket. Furthermore, weighting may be applied to the calculation of the total incentive amount based on the data category. The data category may be determined from the data ID or stored separately in the ticket.

[0066] (Customer consent management) When DC200 retrieves user data from DP300, it is necessary to clearly state the purpose of the data use to the user and obtain the user's consent. In this case, PF100 may be responsible for managing user consent instead of DC200. For example, when PD100 issues a data request ticket to DC200, it may present the user with terms and conditions that clearly state the purpose of the data use and issue the data request ticket only after obtaining the user's consent. These terms and conditions may be obtained by PF100 from DC200 or created independently by PF100. By having PF100 manage user consent in this way, it is possible to confirm user consent in a one-stop manner during the data request ticket issuance process.

[0067] (Advantageous effects of this embodiment) The DC200 can exchange user data without knowing the user ID in the DP300, and the DP300 can exchange user data without knowing the user ID in the DC200. Furthermore, the PF100 can also store the user data itself, and does not need to store it in the DC200 or DP300. It can mediate data exchange without maintaining user IDs. For these reasons, secure data exchange is achieved. In addition, billing and error handling can be performed based on the status management of data request tickets.

[0068] (Other embodiments) The embodiments described above are merely examples, and this disclosure may be modified as appropriate without departing from its essence.

[0069] The present disclosure can also be realized by supplying a computer program implementing the functions described in the embodiments above to a computer, and having one or more processors in the computer read and execute the program. Such a computer program may be provided to the computer by a non-temporary computer-readable storage medium that can be connected to the computer's system bus, or it may be provided to the computer via a network. Non-temporary computer-readable storage mediums include, for example, any type of disk such as magnetic disks (floppy disks, hard disk drives (HDDs), etc.), optical disks (CD-ROMs, DVDs, Blu-ray discs, etc.), read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic cards, flash memory, optical cards, and any type of medium suitable for storing electronic instructions. [Explanation of Symbols]

[0070] 100: Platformer (PF) 200: Data Consumer (DC) 300: Data Provider (DP)

Claims

1. An information processing device that mediates the exchange of user data between a data consumer and a data provider, In response to a request from the data consumer to issue a user identifier to the user, the first identifier is transmitted. In response to a request from the data provider to issue a user identifier to the user, a second identifier is transmitted. Receiving a ticket issuance request from the data consumer, which includes information identifying the user data requested by the data consumer, the first identifier, and the identifier of the data provider to which the request is made. To issue a data request ticket corresponding to the aforementioned ticket issuance request, Sending the ticket identifier of the issued data request ticket to the data consumer, When the ticket identifier is received from the data provider, a data request ticket corresponding to the ticket identifier is sent to the data provider. It includes a control unit that performs the following: The ticket issuance request includes the first identifier, The data request ticket sent to the data provider includes the second identifier corresponding to the first identifier. Information processing device.

2. The system further includes a storage unit that stores the first identifier and the second identifier in association with each other, The control unit transmits a data request ticket, which includes the second identifier associated with the first identifier included in the ticket issuance request, to the data provider. The information processing apparatus according to claim 1.

3. The information processing device does not retain the user identifier in the data consumer, the user identifier in the data provider, or the user data. The information processing apparatus according to feature 1.

4. The control unit further, The system manages the status of the issued tickets in response to access from the data consumer and the data provider to the issued tickets, When the status of the aforementioned ticket transitions to an error state, the system identifies whether the cause of the transition to the error state lies with the data consumer or the data provider, and notifies the identified data consumer or data provider. The information processing apparatus according to claim 1, characterized by performing the following.

5. An information processing method performed by an information processing device that mediates the exchange of user data between a data consumer and a data provider, A first identifier issuance step in which a first identifier is transmitted in response to a request for issuance of a user identifier to a user transmitted from the data consumer, A second identifier issuance step of transmitting a second identifier in response to a request for issuance of a user identifier to the user transmitted from the data provider, A receiving step of receiving a ticket issuance request from the data consumer, which includes information identifying the user data requested by the data consumer, the first identifier, and the identifier of the data provider to which the request is made. The issuance step involves issuing a data request ticket corresponding to the aforementioned ticket issuance request, A ticket identifier transmission step of sending the ticket identifier of the issued data request ticket to the data consumer, A transmission step in which, upon receiving the ticket identifier from the data provider, a data request ticket having the ticket identifier is sent to the data provider; Includes, The ticket issuance request includes the first identifier, The data request ticket sent to the data provider includes the second identifier corresponding to the first identifier. Information processing methods.

6. A program for causing a computer to perform each step of the information processing method described in claim 5.

Images