Authorization apparatus, data server and communication system

An authorization apparatus includes a memory configured to store attribute information associating an identification information of data and information indicating an attribute of the data, the data being stored in a data server, a processor configured to generate an access token in association with an extraction condition to be used for extracting the data to be obtained by a terminal, and a communicator configured to receive a target access token from the data server, wherein when receiving the target access token, the processor is configured to extract identification information of data pieces satisfying the extraction condition associated with the target access token, and generate a list of identification information of the data to be disclosed to the terminal using a target access token, and the communicator transmits the list to the data server.

CROSS-REFERENCE TO RELATED APPLICATION

This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2019-190026, filed on Oct. 17, 2019, the entire contents of which are incorporated herein by reference.

FIELD

The embodiments discussed herein are related to an authorization apparatus, a data server and a communication system.

BACKGROUND

In recent years, various kinds of data including personal data are distributed and utilized to pursue the attempt to produce new findings and values. For distribution and utilization of data, access control over the data is performed. Access control such as User-Managed Access (UMA) 2.0 (in “User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization” ([online], [Searched on Feb. 14, 2019], the Internet, https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html), and “Federated Authorization for User-Managed Access (UMA) 2.0” ([online], [Searched on Feb. 14, 2019], the Internet, <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html, for example), for example, may also be used by a data owner for controlling access to personal data.

As a related art, a system has been proposed (in Japanese Laid-open Patent Publication No. 2015-228067, for example) that, when it is determined that an access token has been issued based on any of client identifiers associated with a user, issues an access token without asking the user to confirm authorization. A system has also been proposed (in Japanese Laid-open Patent Publication No. 2016-115260, for example) that preliminarily registers destination information pieces of a plurality of mediation devices corresponding to a plurality of resource servers with different performances for the same resource so that a client may select one of the destination information pieces, A system has also been proposed (in Japanese Laid-open Patent Publication No. 2015-201097, for example) that, when a menu including all of attributes set to be permitted exists in an access request designating a Web information menu, transmits a menu screen for accessing personal information to a user terminal. A system for confirming a processing result of a whole workflow in which a plurality of services cooperatively operates on a cloud platform service has also been proposed (in Japanese Laid-open Patent Publication No. 2014-186707, for example).

SUMMARY

According to an aspect of the embodiments, an authorization apparatus includes a memory configured to store attribute information associating an identification information of data and information indicating an attribute of the data, the data being stored in a data server, a processor configured to generate an access token in association with an extraction condition to be used for extracting the data to be obtained by a terminal, and a communicator configured to receive a target access token from the data server, wherein when receiving the target access token, the processor is configured to extract identification information of data pieces satisfying the extraction condition associated with the target access token, and generate a list of identification information of the data to be disclosed to the terminal using a target access token, and the communicator transmits the list to the data server.

DESCRIPTION OF EMBODIMENTS

In the rerated art, for access control, a client apparatus that attempts to obtain data pieces often generates a data obtaining request for each of the data pieces to be accessed. In this case, an authorization server also determines whether the data pieces may be obtained or not for each of the data pieces and issues access tokens. A data server that holds the data pieces also communicates with the client apparatus and the authorization server for each of the data obtaining requests. As a result, in order to obtain a plurality of data pieces, a large processing load is imposed on all of the authorization server, the data server and the client. This problem is not solved even by the methods described as related art. For example, even in a system in which confirmation of the authorization to a user may be omitted for issuing access tokens, an access token is to be issued for each data piece. Therefore, in order to obtain a plurality of data pieces, an increased processing load is imposed on the apparatuses in a network including an authorization server and so on.

According to one aspect, it is an object of the embodiments to reduce a processing load occurring for access to a plurality of data pieces.

FIG.1is a diagram illustrating an example of a network. Clients2(2ato2c), resource owners4(4ato4c), an authorization server20, and a resource server50are coupled to a network.FIG.1is an example of the network and may be changed in accordance with the implementation. For example, the numbers of the clients2and the resource owners4coupled to the network may be changed arbitrarily in accordance with the implementation.

The resource server50is a server that stores data pieces (resources) and is also called a “data server”. The resource server50stores a data piece in association with an identification information piece by which the data piece is identified. The data piece may be an arbitrary kind of data and may be an information piece related to an individual, for example. The authorization server20determines whether an access to a data piece by the client2is authorized and identifies a data piece that may be provided to the client2authorized to access the resource server50, for example. It is assumed that, in order to identify a data piece that may be provided to the client2, the authorization server20holds attribute information on the data piece in association with the identification information piece on the data piece. The attribute information includes information regarding the possibility of the disclosure of a data piece notified from the resource owner4, for example.

The client2is an apparatus that attempts to obtain a data piece from the resource server50and is also called a “terminal”. The client2may be a terminal of a company that provides a service and sets a provision condition of a service by using the obtained data pieces, for example. The resource owner4is a terminal to be used by a provider of a data piece stored in the resource server50. The resource owner4may properly set, for the authorization server20, a disclosure destination of a data piece and the possibility of the disclosure. For example, when personal data are stored in the resource server50, the provider of the personal data may set the possibility of the disclosure of the personal data by using the terminal illustrated as the resource owner4.

FIG.2is a diagram illustrating an example of a communication method according to an embodiment. An example of a communication to be performed in the network illustrated inFIG.1will be described with reference toFIG.2. It is assumed that, in a method according to an embodiment, the client2that attempts to access the resource server50is attempting to obtain from the resource server50a plurality of data pieces satisfying an extraction condition (filter information) usable for extraction of data pieces. For example, the example inFIG.2assumes that the client2cis attempting to obtain a plurality of data pieces satisfying filter information called a “filter A”. The client2may notify the filter information when accessing the resource server50, for example.

It is assumed that the authorization server20may obtain the filter information to be used by the client2attempting to access the resource server50, For example, the resource server50may notify filter information notified from the client2to the authorization server20. For authorizing the client2to access the resource server50, the authorization server20generates an access token usable by the client2in association with the filter information and notifies the access token to the client2. In the example inFIG.2, the authorization server20generates a as an access token usable by the client2cand stores it in association with the filter information=filter A. The authorization server20notifies the access token=a to the client2c.

The client2crequests data pieces by transmitting a packet P1including the access token a to the resource server50(arrow A1). The resource server50transmits a packet P2including the access token to the authorization server20(arrow A2).

When the authorization server20receives the access token=a from the resource server50, the authorization server20generates a list L1of identification information pieces (IDs) of data pieces (resources) satisfying the filter A associated with the access token=a. In order to generate the list L1, the authorization server20performs the extraction processing with the filter A based on identification information pieces (resource identifiers (IDs)) of the latest data pieces and the latest attributes of the data pieces. The authorization server20transmits the generated list L1to the resource server50(arrow A3) as a response to the communication indicated by the arrow A2.

The resource server50extracts, from the data pieces stored therein, data pieces with identification information pieces recorded in the list L1received from the authorization server20. The resource server50transmits the extracted data pieces to the client2c(arrow A4) as a response to the communication indicated by the arrow A1. Thus, the client2cmay collectively obtain, from the resource server50, the data pieces satisfying the filter A that is the extraction condition for the data pieces attempted to obtain by the client2c.

As described with reference toFIGS.1and2, the client2may collectively obtain, from the resource server50, data pieces satisfying filter information. Thus, the processing loads on all of the client2, the authorization server20and the resource server50may be reduced, compared with the system in which the access token issuing and authentication processing is performed the number of times equal to the number of data pieces notified to the client2.

FIG.3is a diagram illustrating an example of a configuration of the authorization sewer20. The authorization server20includes a communication unit21, a control unit30, and a storage unit40. The communication unit21includes a transmission unit22and a reception unit23. The transmission unit22transmits a packet to other apparatuses such as the client2, the resource owner4and the resource server50. The reception unit23receives a packet from other apparatuses such as the client2, the resource owner4and the resource server50. Thus, the control unit30may properly exchange data pieces with the client2and the resource server50through the transmission unit22and the reception unit23.

The storage unit40stores attribute information in which an identification information piece of a resource (data piece) held by the resource server50and information indicating an attribute of the resource are associated. As an example, a case in which the attribute information is divided into an owner table41, a resource table42, an agreement table43and a request table44will be described below. The owner table41stores information on a provision source of a resource. When personal data are held in the resource server50, the owner table41stores information on a provider of the personal data. The resource table42stores an identification information piece (resource ID) of a data piece for each kind of resource. The agreement table43stores information on a provision destination agreed by a provision source of a resource to provide the resource. The request table44stores information to be used for processing a request to obtain a resource by using an access token. Examples of the owner table41, the resource table42, the agreement table43, and the request table44will be described below.

The control unit30includes a generation unit31, an extraction unit32, and an update processing unit33. The update processing unit33performs update processing in response to an update request for information stored in the storage unit40.

The generation unit31generates an access token for the client2authorized to access resources stored in the resource server50. In this case, the generation unit31generates an access token in association with filter information (extraction condition) to be used for extracting resources to be obtained by the client2. The generation unit31also generates ticket information to be used for accessing the authorization server20by the client2attempting to obtain the resources.

When an access token to be processed is notified from the resource server50, the extraction unit32extracts identification information pieces of resources satisfying filter information associated with the access token to be processed by using information stored in the storage unit40. The extraction unit32generates a list of the extracted identification information pieces. The list generated by the extraction unit32is used as a list of identification information pieces of resources to be disclosed to the client2that has transmitted the access token to be processed.

FIG.4is a diagram illustrating an example of a configuration of the resource server50. The resource server50includes a communication unit51, a control unit60, and a storage unit70. The communication unit51includes a transmission unit52and a reception unit53. The transmission unit52transmits a packet to other apparatuses such as the client2, the resource owner4and the authorization server20. The reception unit53receives a packet from other apparatuses such as the client2, the resource owner4and the authorization server20. Thus, the control unit60may properly exchange data with the client2and the authorization server20through the transmission unit52and the reception unit53, The storage unit70stores a data piece (resource) in association with an identification information piece.

The control unit60has a request processing unit61and an extraction unit62and may optionally have a selection unit63. The request processing unit61requests the authorization server20to verify an access token received from the client2. The request processing unit61may also request the authorization server20to issue ticket information to be notified to the client2. The extraction unit62extracts resources in association with identification information pieces included in the list notified from the authorization server20as resources to be provided to the client2. The selection unit63selects targets to undergo the extraction processing in the resource server50from filter information notified by the client2to the resource server50. When targets to undergo the extraction processing in the resource server50are selected, the extraction unit62also performs the extraction processing in the resource server50.

FIG.5is a diagram illustrating an example of a hardware configuration. Both of the authorization server20and the resource server50include a processor101, a memory102, a bus103, a network coupling device104and an external storage device105. The processor101is an arbitrary processing circuit and may be a central processing unit (CPU), for example. The processor101uses the memory102as a working memory to execute a program stored in the memory102or the external storage device105, thereby executing various processes. The memory102includes a random-access memory (RAM) and a nonvolatile memory such as a read-only memory (ROM). The memory102stores the program and data to be used for the processes to be executed by the processor101. The external storage device105stores programs, data, and the like and properly provides the stored information to the processor101or the like. The network coupling device104is used to communicate with another device via the network. The bus103couples the processor101, the memory102, the network coupling device104, and the external storage device105to each other so that the processor101, the memory102, the network coupling device104, and the external storage device105may receive and output data from and to each other.

In the authorization server20, the control unit30is implemented by the processor101, The communication unit21is implemented by the network coupling device104. The storage unit40is implemented by the memory102and the external storage device105. In the resource server50, the control unit60is implemented by the processor101. The communication unit51is implemented by the network coupling device104. The storage unit70is implemented by the memory102and the external storage device105. Both of the authorization server20and the resource server50may be implemented as a computer, a server apparatus or the like.

With reference toFIGS.6to9, examples of attribute information of data pieces (resources) will be described below. The following description assumes, as an example, that the resource server50is managed by an automobile company and stores, as resources, data pieces (drive data pieces) regarding driving of automobiles sold or lent by the automobile company. The drive data pieces may be properly provided to the resource server50from devices (not illustrated) such as drive recorders mounted over automobiles. It is assumed that the client2identified by user01 is an insurance company that handles car insurances and is attempting to obtain drive data pieces of drivers satisfying a condition such as age and sex. It is assumed that the authorization server20stores information such as the age and sex of individual drivers whose drive data pieces are recorded in the resource server50, an agreement status with respect to disclosure of the drive data pieces of the drivers and so on.

FIG.6is a diagram illustrating an example of the owner table41. The owner table41stores, in association with an owner ID, an information piece on a provider identified by the owner ID. In the example inFIG.6, the name, birthday, and sex are recorded as the information pieces on the provider of a resource. For example, as the information pieces on a provider with owner ID=owner01, name=Taro Yamada, birthday=Jan. 2, 1980, sex=male are recorded. Though the example inFIG.6includes information pieces regarding four providers with owner IDs=owner01 to owner04, the owner table41may record information pieces on an arbitrary number of providers.

FIG.7is a diagram illustrating an example of the resource table42. The resource table42stores identification information pieces of individual resources held in the resource server50in association with resource types. The resource type is an arbitrary category name used for categorizing data pieces to be stored as resources. A resource associated with resource type=drive data is information indicating a driving evaluation, driving characteristic or the like of automobile driving performed by a provider of the resource. Though the example inFIG.7includes resource01 and resource02 as resource IDs associated with resource type=drive data, an arbitrary number of resource IDs may be associated with each resource type. The following description assumes that resource01 to resource04 are recorded in association with resource type=drive data,

FIG.8is a diagram illustrating an example of the agreement table43, The agreement table43includes a resource ID, an owner ID, a user ID, and an agreement status. For each combination of a resource and the client2attempting to access the resource, the agreement table43stores whether the provider who has provided the resource has agreed about the provision of the resource. In other words, for example, each entry in the agreement table43indicates whether a provider identified by an owner ID has agreed about provision of a resource identified by a resource ID in the entry to the client2identified by a user ID in the entry. For example, the first entry of an agreement table43_1indicates that a provider with owner ID=owner01 has agreed about provision of a resource with resource ID=resource01 to the client2identified by user01.

By searching through the owner table41by using an owner ID in the agreement table43as a key, an information piece on the provider of a resource to be processed may be identified. For example, it is assumed that the first entry of the owner table41and the first entry of the agreement table43_1are used. The information piece may be identified that Taro Yamada who is a male born on Jan. 2, 1980 has agreed about provision of a resource with resource ID=resource01 to the client2identified by user01. In the same manner, also for a combination of another resource and the client2, the agreement status of a provider of the resource may be identified from the agreement table43. By combining the agreement table43and the owner table41, which provider has agreed about provision of a resource may be identified.

A provider of a resource may properly update the agreement status by accessing the authorization server20from a terminal indicated as the resource owner4. For example, in the agreement table43_1, owner04 (Ichiro Kosugi inFIG.6) who is a provider of a resource with resource ID=resource04 has not agreed about provision of the resource identified by resource04 to the client2identified by user01. It is assumed that owner04 has then notified to the authorization server20of the agreement about provision of the resource identified by resource04 to the client2identified by user01. The update processing unit33in the authorization server20updates the agreement table43_1to the agreement table43_2. Thus, after the update to the agreement table43_2, the resource identified by resource04 may be provided to the client2in response to a request by the client2identified by user01. Like the agreement table43, the information in the owner table41and the resource table42may be updated in accordance with registration of a new resource or attribute information.

FIG.9is a diagram illustrating an example of the request table44. The request table44stores a user ID, a resource type, filter information, a permission ticket, an access token and an expiration date and time in association. The user ID is an identification information piece by which the client2is identified. The resource type is information indicating a type of resource. The filter information is an extraction condition to be used for extracting a resource that the client2attempts to obtain. For example, when ages=20s and 30s are set in the filter information, resources provided by providers in their 20s and 30s are extracted from resources categorized to the resource type that the client2attempts to obtains. The permission ticket (ticket) is ticket information to be used for requesting to issue an access token from the client2to the authorization server20. The access token is an access token issued to the client2identified by the user ID included in the entry. The expiration date and time is an expiration date and time of the access token.

In the example inFIG.9, the client2identified by user01 sets filter information for obtaining resources provided by providers in their 20s and 30s in the resources categorized in resource type drive data. In order for the client2identified by user01 to request issuance of an access token, a permission ticket ticket01 is used, An access token token01 that is valid until 12:00:00 on Dec. 31, 2019 is issued to the client2identified by user01.

First Embodiment

An example of processing to be performed when the client2being a terminal of an insurance company obtains drive data pieces of drivers in their 20s and 30s from the resource server50that holds drive data pieces will be described below. The following description assumes that user ID=user01 is assigned to the client2. According to a first embodiment, the resource server50may not include the selection unit63.

FIG.10is a sequence diagram illustrating an example of a communication according to the first embodiment. It is assumed that, at the beginning of the processing inFIG.10, information regarding the client2is not included in the request table44held by the authorization server20.

The client2to which an access token has not been issued transmits a resource request including a resource type and filter information and not including an access token to the resource server50(step S21). The resource type in the resource request represents a type of resources to be obtained by the client2. The filter information included in the resource request represents a condition to be used for processing of extracting resources that the client2attempts to obtain, Therefore, for example, in step S21, a resource request including information including resource type=drive data and filter information=20s and 30s is transmitted.

The resource request is transmitted in an arbitrary form usable for communication between the client2and the resource server50. For example, the resource request may be a Hypertext Transfer Protocol (HTTP) request having filter information as a request Uniform Resource Identifier (URI). Therefore, for example, when a Uniform Resource Locator (URL) of the resource server50is http://abc.com, an HTTP request as follows may be used as the resource request in step S21.

Further, the resource request may be an HTTP request in a form including a storage location of resources to be obtained as follows.

It is assumed that, when an HTTP request in a form including a storage location of resources is used, the client2may recognize in advance a storage condition of the resource in the resource server50.

The request processing unit61in the resource server50obtains the resource request transmitted from the client2through the reception unit53. The request processing unit61generates a permission request for obtaining a permission ticket (ticket) to be used by the transmission source of the resource request. The permission request includes the resource type and the filter information included in the resource request transmitted from the client2. The request processing unit61transmits the permission request to the authorization server20through the transmission unit52(step S22).

The generation unit31in the authorization server20obtains the permission request through the reception unit23. The generation unit31generates a ticket in association with the combination of the resource type and the filter information included in the permission request. The ticket is information in an arbitrary form by which a combination of a resource type and filter information associated with the ticket may be uniquely identified. The generation unit31records the generated ticket in the request table44along with the corresponding combination of the resource type and the filter information. For example, when a ticket ticket01 is generated, the following information is recorded in the request table44.

filter information=20s, 30s, and

The generation unit31transmits the generated ticket to the resource server50as a response message to the permission request (step S23).

The request processing unit61in the resource server50includes the ticket notified from the authorization server20and address information on the authorization server20in the response message to the resource request. The request processing unit61transmits the generated response message to the client2(step S24).

The client2transmits to the authorization server20a token request including the ticket notified from the resource server50and the user ID assigned to the client2(step S25). In this example, it is assumed that the token request is transmitted which includes:

ticket=ticket01, and

The generation unit31in the authorization server20obtains the token request through the reception unit23. The generation unit31searches through the request table44by using the ticket included in the token request as a key. At this point in time, a combination of resource type=drive data and filter information=20s, 30s is recorded in the request table44in association with the information indicating ticket=ticket01. When an entry including the ticket included in the token request is identified in the request table44, the generation unit31generates an access token for a request source of the token request. The generation unit31adds the user ID of the request source of the token request and the information on the access token to the identified entry. For example, it is assumed that the generation unit31has issued an access token token01 that is valid until 12:00:00 on Dec. 31, 2019 to the client2. The generation unit31updates the entry related to the client2as illustrated inFIG.9. The generation unit31transmits the generated access token to the client2by including the access token in a response to the token request (step S26).

The client2having obtained the access token transmits the access token to the resource server50to obtain the resource (step S27). The request processing unit61in the resource server50generates a token verification request including the access token received from the client2and transmits it to the authorization server20(step S28). The token verification request is a message for requesting to verify whether the access token in the token verification request is valid.

The extraction unit32in the authorization server20searches through the request table44(FIG.9) by using the access token included in the token verification request as a key. When an entry including the access token to be verified hits, the extraction unit32determines whether it is beyond the expiration date and time in the entry. When it is not beyond the expiration date and time, the extraction unit32determines that the access token is valid. The extraction unit32extracts the resource ID of a resource satisfying the filter information associated with the valid access token (step S29). The extraction unit32records the extracted resource ID in a resource ID list.

Details of the processing of extracting a resource ID and the processing of generating a resource ID list when the access token token01 is determined as valid will be described below. It is assumed that, at the point in time when the access token token01 is determined as valid, the authorization server20holds the information illustrated inFIGS.6,7, and9and the agreement table43_1inFIG.8as attribute information. It is assumed that the point in time when the access token is determined as valid is Apr. 14 in 2019.

By using the request table44(FIG.9), the extraction unit32recognizes that the resource type associated with token01 is drive data and the filter information is “ages=20s, 30s”. First, the extraction unit32identifies resource IDs given to drive data pieces held by the resource server50by searching through the resource table42(FIG.7) by using the resource type as a key. It is assumed that four IDs including resource01, resource02, resource03, and resource04 are identified as resource IDs given to drive data pieces.

The extraction unit32uses the information in the agreement table43_1(FIG.8) and the owner table41(FIG.6) to extract IDs associated with data pieces satisfying the filter information based on the identified resource IDs. The extraction unit32searches through the agreement table43_1by using resource ID=resource01 as a key and recognizes that owner ID=owner01 is associated with resource ID=resource01. Next, the extraction unit32searches through the owner table41by using, as a key, owner ID=owner01 corresponding to resource ID=resource01 and determines whether the information piece in a hit entry satisfies the filter information. The entry including owner ID=owner01 includes information indicating birthday=1/2/1980. Therefore, at the point in time of the resource search, the driver having performed the driving recorded as drive data identified by resource ID=resource01 is 39 years old. Accordingly, the extraction unit32determines that the information piece with resource ID=resource01 satisfies the filter information. The extraction unit32performs the same processing on the other resource IDs. At the point in time of the resource search, all of the drivers having performed the driving recorded as drive data identified by resource IDs=resource02 to resource04 are 29 years old. Therefore, the extraction unit32determines that the information pieces with resource IDs=resource01 to resourced satisfy the filter information.

Next, with reference to the agreement table43_1(FIG.8), the extraction unit32determines whether the owners who provide the resources satisfying the filter information agree about the disclosure of the resources. For example, the extraction unit32determines the agreement status in the entry combined with the user ID (user01) of the client2for each resource ID by which a resource satisfying the filter information is identified. Referring to the first entry in the agreement table43_1, provision of resource01 to the client2with user ID user01 has been agreed. Accordingly, the extraction unit32includes resource01 in a resource ID list. Referring to the third entry in the agreement table43_1, provision of resource03 to the client2with user ID=user01 has been agreed. On the other hand, referring to the entries corresponding to resource02 and resource04 in the agreement table43_1, provision of both resource02 and resource04 to the client2with user ID=user01 has not been agreed. Accordingly, the extraction unit32includes resource03 in the resource ID list but does not include resource02 and resource04 in the resource ID list. In other words, for example, even when a resource that has not been agreed about its disclosure by the owner satisfies filter information, the extraction unit32excludes the corresponding resource from resources to be provided to the client2.

In step S30inFIG.10, the extraction unit32transmits the generated resource ID list to the resource server50. It is assumed that resource01 and resource03 are recorded in the resource ID list.

When the extraction unit62in the resource server50obtains the resource ID list received from the authorization server20, the extraction unit62extracts resources associated with the resource IDs in the resource ID list. The extraction unit62collectively transmits the extracted resources (data pieces) to the client2(step S31), In this example, the extraction unit62extracts the drive data piece identified by resource01 and the drive data piece identified by resource03. The extraction unit62collectively transmits the extracted data pieces to the client2.

Therefore, when a plurality of data pieces satisfying the filter information is held in the resource server50, the client2may collectively obtain the data pieces satisfying the filter information. Because an access token is not issued to each data piece satisfying filter information, one access token is used to collectively obtain a plurality of data pieces. Thus, in the system according to the first embodiment, the processing loads on all of the client2, the authorization server20and the resource server50may be reduced, compared with a system in which the access token issuing and authentication processing is performed for each data piece.

FIG.11is a sequence diagram illustrating an example of a communication according to the first embodiment.FIG.11is an example of a communication to be performed after the communication illustrated inFIG.10ends. With reference toFIG.11, advantages will be described which occur when an attribute or the like of a data piece changes because an access token is associated with filter information.

For example, it is assumed that a fact that the agreement status about provision of a drive data piece identified by resource04 to the client2with user ID=user01 is changed from “NOT AGREED” to “AGREED” is notified to the authorization server20. The agreement about provision of the resource may be transmitted from the terminal of the driver (owner04) having performed the driving recorded as drive data to the authorization server20, for example. The update processing unit33in the authorization server20obtains a request to change the agreement status through the reception unit23and updates the agreement table43_1to the agreement table43_2in accordance with the request (step S41). The agreement status may be changed in response to input processing performed by an operator of the authorization server20when the driver applies to the operator of the authorization server20for changing the agreement status about provision of the resource. In this case, in response to the input from an input device (not illustrated) of the authorization server20, the update processing unit33updates the agreement table43.

It is assumed that the client2then transmits a resource request including the access token to the resource server50(step S42). It is assumed that the access token to be used in step S42is the access token notified to the client2in step S26inFIG.10. The request processing unit61in the resource server50generates a token verification request including the access token received from the client2and transmits it to the authorization server20(step S43).

The extraction unit32in the authorization server20performs the same processing as the processing described in relation to step S28inFIG.10by using the request table44(FIG.9) to determine whether the access token included in the token verification request is valid. It is assumed that the access token is determined as valid. It is assumed that the point in time when the access token is determined as valid is Apr. 22 in 2019.

When the access token is determined as valid, the extraction unit32extracts resource IDs of resources satisfying the filter information associated with the access token by using the latest agreement table43_2(step S44). In the extraction processing in step S44, the extraction unit32performs the same processing as the processing described with reference to step S29inFIG.10. First, the extraction unit32identifies resource IDs=resource01 to resource04 of resources satisfying the filter information associated with the access token token01. Next, with reference to the agreement table43_2(FIG.8), the extraction unit32determines whether the owners of the resources satisfying the filter information agree about the disclosure of the resources. In the agreement table43_2, the provision of resource01, resource03, and resource04 to the client2identified by user ID=user01 has been agreed. Accordingly, the extraction unit32includes resource01, resource03 and resource04 in the resource ID list. Therefore, because of the processing in step S44, the resource ID list including resource01, resource03, and resource04 is generated. The extraction unit32transmits the generated resource ID list to the resource server50(step S45).

When the extraction unit62in the resource server50obtains the resource ID list received from the authorization server20, the extraction unit62extracts resources associated with the resource IDs in the resource ID list. The extraction unit62collectively transmits the extracted resources (data pieces) to the client2(step S46). In this example, the extraction unit62collectively transmits the drive data pieces identified by resource01, resource03 and resource04 to the client2.

In the system according to the first embodiment, as described above, because an access token is associated with filter information, the processing of extracting resources satisfying the filter information is performed when the access token is verified. Therefore, as described with reference toFIG.11, when the agreement status is changed after an access token is issued, the client2may collectively obtain a plurality of data pieces based on the latest agreement table43_2by using the issued access token.

With reference toFIG.11, the case has been described where the agreement table43is changed after an access token is issued as an example. However, also when another kind of attribute information is changed, extraction by using the attribute information is performed at a point in time when the validity of the access token is confirmed. In other words, for example, by using the issued access token, the client2may collectively obtain a plurality of data pieces extracted based on the latest attribute information when the access token is verified. Also when a new data piece is added to the resource server50, the client2may collectively obtain, by using the issued access token, a plurality of data pieces extracted based on the latest attribute information when the access token is verified.

FIGS.12A to12Care flowcharts illustrating an example of processing to be performed in the authorization server20. The processing inFIG.12A to12Cis merely an example of processing and the order of the processing may be changed in accordance with the implementation. For example, the order of the processing in step S66and step S67may be reversed.

The reception unit23receives a request transmitted to the authorization server20(step S51). The generation unit31determines whether the request is a permission request (step S52). When the request is a permission request (YES in step S52), the generation unit31generates a ticket to be used by the client2that accesses the authorization server20(step S56). The generation unit31adds the resource type, the filter information and the ticket to the request table44(step S57). The resource type and filter information to be recorded in the request table44in step S56are information notified in the received permission request. The ticket is generated in association with the combination of the resource type and the filter information. The transmission unit22then transmits the ticket generated by the generation unit31to the resource server50as a response to the permission request (step S58).

On the other hand, when the received request is not a permission request (NO in step S52), the generation unit31determines whether the request is a token request (step S53). When the request is a token request (YES in step S53), the generation unit31generates an access token (step S59). The generation unit31adds the user ID and the access token generated in step S59to the entries including the ticket included in the token request among the entries in the request table44(step S60), The user TD is information included in the token request along with the ticket. The transmission unit22then transmits the access token generated by the generation unit31to the client2that is the transmission source of the token request as a response to the token request (step S61).

When the received request is not a permission request and is not a token request (NO in step S53), the extraction unit32determines whether the request is a token verification request (step S54). When the received request is not a token verification request (NO in step S54), the update processing unit33properly executes the requested processing (step S55).

When the received request is a token verification request (YES in step S54), the extraction unit32determines whether the access token included in the token verification request is a token within the expiration date and time (step S62). When the access token is not a token within the expiration date and time, the transmission unit22notifies an error to the resource server50(NO in step S62, step S63).

When the access token is a token within the expiration date and time (YES in step S62), the extraction unit32extracts the user ID, resource type and filter information associated with the access token from the request table44(step S64). After that, the extraction unit32identifies the resource IDs associated with the extracted resource type by using the resource table42(step S65). By using the agreement table43, the extraction unit32narrows the identified IDs to the resource IDs agreed about provision of the resources to the user identified by the user ID to be processed (step S66). The extraction unit32generates a list of the resource IDs by performing filtering with the filter information by using the owner table41(step S67). After that, the transmission unit22transmits the list of the resource IDs to the resource server50(step S68).

FIGS.13A and13Bare flowcharts illustrating an example of processing to be performed in the resource server50. The reception unit53receives a request transmitted to the resource server50(step S81). The request processing unit61determines whether the request is a resource request not including a token (step S82). When the request is a resource request not including a token (YES in step S82), the request processing unit61transmits a permission request to the authorization server20(step S85). The permission request includes the resource type and the filter information notified in the resource request. The reception unit53receives a response to the permission request from the authorization server20(step S86). The response to the permission request also includes ticket information to be used by the client2for requesting an access token to the authorization server20. The transmission unit52transmits the response to the resource request to the client2(step S87). The response to the resource request also includes ticket information to be used by the client2for requesting an access token to the authorization server20.

When the request is not a resource request not including a token and is not a resource request including a token (NO in step S82, NO in step S83), the control unit60executes the requested processing (step S84).

When the request is a resource request including a token, the request processing unit61generates a token verification request including the access token in the resource request (YES in step S83). The transmission unit52transmits the token verification request to the authorization server20(step S88). After that, the reception unit53receives a response to the token verification request from the authorization server20(step S89), When the access token is valid, the response to the token verification request includes information indicating that the access token is valid and the resource ID list. The resource ID list may be used as the information indicating that the access token is valid. In this case, the response to the token verification request may not include the information indicating the validity of the access token other than the resource ID list.

The extraction unit62extracts data pieces corresponding to the resource ID list notified from the authorization server20(step S90). The extraction unit62includes the data pieces obtained by the extraction in a response to the resource request. The transmission unit52transmits the response to the resource request to the client2(step S91).

According to the first embodiment, as described above, one access token is generated in association with filter information used by one client2. Thus, the client2may collectively obtain, from the resource server50, data pieces satisfying the filter information. According to the first embodiment, even when addition, change, deletion or the like occurs in the data pieces stored in the resource server50, the data pieces may be collectively obtained by using the issued access token. Even when the attribute information regarding the data pieces is changed, IDs of data pieces satisfying filter information are extracted in the authorization server20in response to the confirmation of the validity of the access token. In other words, for example, without re-issuing an access token even when a change occurs in the attribute information, the data pieces satisfying filter information may be collectively obtained. According to the first embodiment, the loads imposed for obtaining a plurality of data pieces on all of the client2, the authorization server20, and the resource server50may be reduced, compared with the case where an access token is generated for each of data pieces.

Second Embodiment

According to a second embodiment, an example of a case will be described in which filtering is performed in both of the authorization server20and the resource server50. In the second embodiment, it is assumed that the resource server50includes the selection unit63and that a filter table71and attribute information72are stored in the storage unit70.

FIG.14is a diagram illustrating examples of the filter table71and the attribute information72. The filter table71includes filter IDs and filter information pieces. Each of the filter information pieces in the filter table71is information to be used for filtering in the resource server50. For example, when the selection unit63in the resource server50receives a resource request including a filter information piece from the client2, the selection unit63may select an information piece for filtering in the resource server50in the filter information and record it in the filter table71, For the information piece for filtering in the resource server50, the selection unit63generates a filter ID for identifying the information piece and records it in the filter table71.

The filter table71illustrated inFIG.14includes a filter information piece “car type=X”. A filter ID used for identifying the filter information piece “car type=X” is filter01.

The attribute information72is arbitrary information that is associated with an information piece identified by a resource ID of a resource held in the resource server50and is usable for filtering on data pieces. In the example inFIG.14, a resource ID of a resource held in the resource server50and a car type used for generating the resource (drive data piece) identified by the resource ID are associated. In an example of the attribute information72, resource01 and resource04 are drive data pieces with car type=X. resource resource02 is a drive data piece with car type=Y, and resource03 is a drive data piece with car type=Z.

FIG.15is a sequence diagram illustrating an example of a communication according to the second embodiment. With reference toFIG.15, collective obtaining of data pieces in a case where the resource server50has the attribute information72illustrated inFIG.14will be described below.

The client2to which an access token has not been issued transmits a resource request including a resource type and a filter information piece and not including an access token to the resource server50(step S100). The resource request includes information including:

filter information=20s or 30, and

The selection unit63in the resource server50identifies information pieces of the types registered with the attribute information72of the filter information pieces transmitted from the client2as filter information pieces to be processed in the resource server50(step S101). In this example, the resource server50may perform filtering relating to a car type because the attribute information72illustrated inFIG.14is stored in the resource server50. Accordingly, the selection unit63determines that the filter information piece “car type=X” is to be processed in the resource server50. The selection unit63generates filter01 as a filter ID for identifying the filter information piece “car type=X”. Because of the processing in step S101, the filter table71illustrated inFIG.14is generated.

The request processing unit61generates a permission request for requesting a ticket to be used by the client2that is the transmission source of the resource request. The permission request includes a resource type, a filter ID and a filter information piece. The filter ID included in the permission request is a filter ID for identifying a filter condition to be processed by the resource server54. The filter information piece included in the permission request is a filter information piece that is not to be processed by the resource server50. Therefore, the permission request generated in this example includes information “resource type=drive data”, “filter information=20s or 30s” and “filter ID=filter01”. The request processing unit61transmits the permission request to the authorization sewer20through the transmission unit52(step S102).

The generation unit31in the authorization server20obtains the permission request through the reception unit23, The generation unit31generates a ticket in association with the combination of the resource type, the resource ID and the filter information piece included in the permission request. The generation unit31records the generated ticket in the request table44along with the corresponding combination of the resource type and the filter information. For example, when a ticket ticket01 is generated, the following information is recorded in the request table44.

filter ID=filter01, and

The generation unit31includes the generated ticket in a response message to the permission request and transmits it to the resource server50(step S103).

The processing in steps S104and S105is the same as the processing described with reference to steps S24and S25inFIG.10. Thus, an access token is generated in response to the reception of the token request, and the request table44is updated.

FIG.16is a diagram illustrating an example of the request table. The example inFIG.16assumes that a token request including the following information is transmitted from the client2, like the first embodiment.

ticket=ticket01, and

When the generation unit31in the authorization server20obtains the token request, the generation unit31searches entries including ticket01 in the request table44. At this point in time, the entries including ticket=ticket01 include information including resource type=drive data, filter information=20s, 30s, and filter ID=filter01. It is assumed that the generation unit31has issued an access token token01 that is valid until 12:00:00 on Dec. 31, 2019 The generation unit31adds the following information to the entries relating to the client2having transmitted ticket01.

access token=token01, and

Therefore, the request table44is updated as illustrated inFIG.16. After that, the generation unit31transmits the generated access token to the client2by including the access token in a response to the token request (step S106inFIG.15).

The client2having obtained the access token transmits the access token to the resource server50to obtain the resources (step S107). The request processing unit61in the resource server50generates a token verification request including the access token received from the client2and transmits it to the authorization server20(step S108).

The extraction unit32in the authorization server20searches through the request table44(FIG.16) by using the access token included in the token verification request as a key. When an entry including the access token to be verified hits, the extraction unit32determines whether it is beyond the expiration date and time in the entry. When it is not beyond the expiration date and time, the extraction unit32determines that the access token is valid. The extraction unit32identifies the filter ID associated with the valid access token. The extraction unit32extracts the resource ID of a resource satisfying the filter information piece associated with the valid access token (step S109). The resource ID extraction processing is the same as that in the first embodiment. The extraction unit32records the extracted resource ID in a resource ID list.

After that, the extraction unit32transmits the generated resource ID list and the filter ID associated with the access token to the resource server50(step S110). It is assumed that resource01, resource03 and resource04 are recorded in the resource ID list. The filter ID transmitted along with the resource ID list is filter01.

The extraction unit62in the resource server50further filters the resource IDs in the resource ID list received from the authorization server20by using the filter information piece to be processed by the resource server50(step S111). In this case, the extraction unit62identifies the filter information piece to be used for the filtering by searching through the filter table71by using the filter ID as a key. After that, the extraction unit62searches through the attribute information72by using the identified filter condition and thus extracts resource IDs satisfying the condition identified by the filter ID notified from the authorization server20among the resource IDs included in the resource ID list.

For example, in step S110, because filter ID=filter01 is notified, the extraction unit62identifies the filter information piece “car type=X” by searching through the filter table71(refer toFIG.14). Accordingly, the extraction unit62determines whether each of the resource IDs included in the resource ID list obtained from the authorization server20satisfies the filter information piece with reference to the attribute information72(refer toFIG.14). In this example, resource01, resource03 and resource04 are recorded in the resource ID list. When the extraction unit62recognizes that resource01 is associated with car type=X by using the first entry of the attribute information72, the extraction unit62determines resource01 as the ID of the resource to be transmitted to the client2. Also with respect to resource04, the extraction unit62recognizes that resource04 is associated with car type=X by using the fourth entry of the attribute information72. The extraction unit62determines resource04 as the ID of the resource to be transmitted to the client2. On the other hand, resource03 is associated with car type=Z in the third entry of the attribute information72. Accordingly, the extraction unit62excludes resource03 from the IDs of the resources to be transmitted to the client2. Therefore, in this example, the extraction unit62extracts resource01 and resource04 as the IDs of the resources to be transmitted to the client2. The extraction unit62collectively transmits the resources (data pieces) corresponding to the extracted resource IDs to the client2(step S112).

In this manner, according to the second embodiment, because filtering is performed also in the resource server50, the load due to the extraction processing may be distributed to the authorization server20and the resource server50.

FIGS.17A and17Bare flowcharts illustrating an example of processing to be performed in the resource server.FIGS.17A and17Bare an example of the processing, and the order of the processing, for example, may be changed in accordance with the implementation. For example, the order of the processing in step S132and step S133may be reversed.

The reception unit53receives a request transmitted to the resource server50(step S121). The request processing unit61determines whether the request is a resource request not including a token (step S122) When the request is a resource request not including a token (YES in step S122), the selection unit63selects a filter information piece to be processed in the resource server50from the filter information included in the request (step S125). The selection unit63adds the filter information piece to be processed in the resource server50to the filter table71(step S126). In this case, the selection unit63also generates a filter ID for identifying the filter information piece to be processed in the resource server50and records it in the filter table71. After that, the request processing unit61transmits a permission request to the authorization server20(step S127). The permission request includes a resource type, a filter ID, and a filter information piece not to be processed in the resource server50in the filter information included in the resource request. The processing in steps S128and S129is the same as the processing in steps S86and S87described with reference toFIG.13A.

When the request is not a resource request not including a token and is not a resource request including a token (NO in step S122, NO in step S123), the control unit60executes the requested processing (step S124).

When the request is a resource request including a token, the request processing unit61generates a token verification request including the access token included in the resource request (YES in step S123). The transmission unit52transmits the token verification request to the authorization server20(step S130). After that, the reception unit53receives a response to the token verification request from the authorization server20(step S131). When the access token is valid, the response to the token verification request includes information indicating that the access token is valid, the resource ID list, and the filter ID. The resource ID list may be used as the information indicating that the access token is valid, like the first embodiment. In this case, the response to the token verification request may not include the information indicating the validity of the access token other than the resource ID list.

The extraction unit62extracts data pieces corresponding to the resource ID list notified from the authorization server20(step S132). The extraction unit62further narrows the data pieces obtained by the extraction processing in step S132by using the filter information piece identified by the filter ID notified from the authorization server20(step S133). The filter information piece identified by the filter ID notified from the authorization server20is a filter information piece to be processed in the resource server50. The extraction unit62includes the data pieces acquired by the narrowing by using the filter information piece identified by the filter ID notified from the authorization server20in the response to the resource request. The transmission unit52transmits the response to the resource request to the client2(step S134).

The operations by the authorization server20according to the second embodiment involve the processing that is the same as the processing described with reference toFIGS.12A to12C, excluding the processing relating to a filter ID. According to the second embodiment, the authorization server20records the filter ID notified from the resource server50in the request table44in addition to the resource type, the filter information piece and the ticket when updating the request table44in step S57inFIG.12A. According to the second embodiment, the authorization server20transmits the resource ID list and the filter ID to the resource server50when transmitting the resource ID list to the client2in step S68inFIG.12C.

According to the second embodiment, the load due to the extraction processing may be distributed to the authorization server20and the resource server50, and different types of information are to be processed by the servers so that the authorization server20may be generically used. For example, personal information such as the age or sex of a provider of a resource may be stored in the authorization server20, and information usable for limitation of resources based on a resource type held in each of the resource severs50may be stored in the resource server50. The information usable for limitation of resources based on a resource type held by the resource server50may be determined based on the resource types. For example, for the resource server50holding drive data, information such as car types or areas where driving is performed may be the information usable for limitation of resources. In this manner, by the filtering of the information usable for limitation based on a resource type in the resource server50, the authorization server20may be specified to authorization of accesses to various resource servers50and filtering using personal information. The authorization server20is generically usable for one or more resource servers50holding various resource types.

The embodiments are not limited to the above and may be variously modified. Some examples thereof will be described below.

In the description above, the case has been described, as an example, in which a plurality of resources are extracted as resources to be notified to the client2. However, the number of resources to be notified to the client2is an arbitrary number equal to or higher than 1.

The information pieces in the tables described above are examples, and these pieces of information may also be changed in accordance with the implementation. For example, the owner table41, the resource table42, the agreement table43, and the request table44may be united to one table or may be divided into an arbitrary number.

The number and types of information pieces to be included in the filter information to be notified from the client2to the resource server50are arbitrary. For example, in both of the first and second embodiments, sex, for example, may be included in the filter information.

Also in the second embodiment, the attribute information held by the authorization server20and the information held by the resource server50may be changed after an access token is issued. Also in this case, like the first embodiment, the extraction processing is performed by using the latest attribute information at the point in time when the access token is determined as valid.