Patent Publication Number: US-2019197803-A1

Title: Information processing apparatus, information processing method, and information processing program

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2017-245774, filed on Dec. 22, 2017, the entire contents of which are incorporated herein by reference. 
     FIELD 
     The embodiments discussed herein are related to an information processing apparatus, an information processing method, and an information processing program. 
     BACKGROUND 
     A computer system offers services using various resources. Examples of the resources used to offer the services include software resources such as data and programs, and various kinds of equipment controlled by computers. 
     For example, the development of Internet of Things (IoT)-related technologies have enabled various things (IoT devices) including but not limited to computers to be connected to the Internet. The IoT devices themselves and data acquired from the IoT devices are resources used to offer services. 
     The IoT device is available for collection of data. For example, service providers collect data on the users of their IoT devices from a lot of IoT devices via a computing system (hereinafter referred to as cloud system). The service providers may perform data mining of the collected data to acquire various kinds of knowledges. 
     Data collected from the IoT device includes data indicating characteristics of actions of the user who holds the IoT device. For this reason, data collected from the IoT device used by a particular user may be used by the service provider collecting the data, as well as the user himself/herself offering the data. For example, the user may offer data to a particular service provider via the IoT device, and offer the data to another service provider according to the user&#39;s will, to receive an appropriate service (for example, discount of service fee). In this case, for example, the service provider that holds data passes an access right to data concerned to another service provider, and another service provider accesses data based on the access right. 
     An example of the technology concerning the access right to data is OAuth. A right transfer system for performing control such that customers may share an authenticated token within the scope of customer&#39;s authentication has been also proposed. An access right management system for invalidating, transferring, dividing, and changing the access right has been also proposed. Further, a resource management system for solving problems about the use right, for example, the problem that the access right on the network may not be dynamically offered to users has been suggested. Related techniques are disclosed in, for example, Japanese Laid-open Patent Publication Nos. 2013-145505, 2004-032220, and 2003-162464. 
     However, according to the conventional techniques about the access right to resources managed by servers, the unit of resources, the access right of which may be managed, is fixed, which is less flexible. 
     SUMMARY 
     According to an aspect of the embodiments, an information processing method, the method causing a computer to: generate, when receiving an acquisition request of a ticket indicating a use right of a resource available to a user from a first apparatus, the ticket including command information, the command information indicating a command concerning use of the resource, based on available resource information indicating the resource; transmit the ticket to the first apparatus; and execute, when receiving the ticket from a second apparatus that acquired the ticket via the first apparatus, the command indicated by the command information included in the ticket. 
     The object and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the claims. 
     It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG. 1  is a view illustrating an example of a functional configuration of an apparatus according to a first embodiment; 
         FIG. 2  is a view illustrating an example of a configuration of a system according to a second embodiment; 
         FIG. 3  is a view illustrating an example of a hardware configuration of a server; 
         FIG. 4  is a block diagram illustrating functions of each device; 
         FIG. 5  is a sequence diagram illustrating a procedure of rental contract processing and driving data collection processing; 
         FIG. 6  is a view illustrating an example of contract data; 
         FIG. 7  is a view illustrating an example of driving data; 
         FIG. 8  is a sequence diagram illustrating an example of a procedure of processing of offering an access ticket to a server for automobile insurance service; 
         FIG. 9  is a sequence diagram illustrating an example of a procedure of processing of acquiring the access ticket from a server for rental car service; 
         FIG. 10  is a view illustrating an example of an access ticket request; 
         FIG. 11  is a view illustrating an example of generation of an access ticket using a template; 
         FIG. 12  is a sequence diagram illustrating an example of a procedure of premium estimation processing using the access ticket; 
         FIG. 13  is a view illustrating an example of a system according to a third embodiment; 
         FIG. 14  is a view illustrating an example of a system according to a fourth embodiment; 
         FIG. 15  is a sequence diagram illustrating an example of a procedure of driving data receiving-URL acquisition processing; 
         FIG. 16  is a sequence diagram illustrating an example of a procedure of driving data acquisition processing according to the fourth embodiment; 
         FIG. 17  is a view illustrating an example of a system according to a fifth embodiment; 
         FIG. 18  is a view illustrating an example of a system according to a sixth embodiment; 
         FIG. 19  is a view illustrating an example of a flight reservation information storage unit; 
         FIG. 20  is a view illustrating an example of a hotel reservation information storage unit; 
         FIG. 21  is a view illustrating an example of a script included in an access ticket included in flight reservation information; 
         FIG. 22  is a view illustrating an example of a script in the access ticket included in hotel reservation information; 
         FIG. 23  is a view illustrating an example of a system according to a seventh embodiment; 
         FIG. 24  is a view illustrating an example of a script for unlocking a door of a room; 
         FIG. 25  is a view illustrating an example of user registration processing according to an eighth embodiment; 
         FIG. 26  is a view illustrating a use state of an access ticket according to the eighth embodiment; 
         FIG. 27  is a view illustrating an example of a system having a function of limiting the user of the access ticket; 
         FIG. 28  is a view illustrating an example of an access ticket request including a service ID; 
         FIG. 29  is a view illustrating an example of the access ticket including the service ID; 
         FIG. 30  is a sequence diagram illustrating an example of a procedure of premium estimation processing using the access ticket according to the eighth embodiment; 
         FIG. 31  is a view illustrating an example of a system according to a ninth embodiment; 
         FIG. 32  is a view illustrating an example of an access ticket including the script ID; and 
         FIG. 33  is a sequence diagram illustrating an example of a procedure of premium estimation processing using the access ticket according to a ninth embodiment. 
     
    
    
     DESCRIPTION OF EMBODIMENTS 
     Embodiments will be described below with reference to figures. The embodiments may be combined so as not to cause contradiction. 
     First Embodiment 
     First, a first embodiment is described.  FIG. 1  is a view illustrating an example of a functional configuration of an apparatus according to the first embodiment. A network  8  is connected to an information processing apparatus  10 , a first apparatus  3 , and a second apparatus  4 . 
     The information processing apparatus  10  manages resources that are available to a user  9 . For example, the information processing apparatus  10  periodically collects data on the state of automobiles  1 ,  2  from IoT devices  1   a,    2   a  mounted in automobiles  1 ,  2 , respectively, which are rented as rental cars. Examples of the data on the state of the automobiles  1 ,  2  include data on position, speed, and acceleration of the automobiles  1 ,  2 . In the case where the automobile  1  is rented to the user  9  for a predetermined period, data collected from the automobile  1  during the period is personal data  7  on the user  9 , and is resources available to the user  9 . 
     To manage an access right to the resources available to the user  9 , the information processing apparatus  10  has a storage unit  11  and a processing unit  12 . For example, the storage unit  11  is a memory or a storage device of the information processing apparatus  10 . For example, the processing unit  12  is a processor or an arithmetic circuit of the information processing apparatus  10 . 
     The storage unit  11  stores available resource information  11   a  indicating resources available to the user  9 . For example, the available resource information  11   a  indicates that data collected from the IoT device  1   a  mounted in the automobile  1  in the period in which the automobile  1  is rented to the user  9 , as user-available resources. The storage unit  11  stores data collected from the IoT devices  1   a,    2   a  (acquired data  11   b,    11   c ). 
     When receiving an acquisition request  5  of a ticket  6  indicating a use right of the resources available to the user from the first apparatus  3 , the processing unit  12  generates the ticket  6  including command information  6   a  indicating a command about the use of the resources, based on the available resource information  11   a.  The command information  6   a  is, for example, a script including one or more commands. The command information  6   a  may be an identifier associated with the command (command ID). For example, the command about the use of the resource is an acquisition command to acquire the personal data  7  on the user  9  from the storage unit  11 . The processing unit  12  transmits the generated ticket  6  to the first apparatus  3 . 
     After that, when receiving the ticket  6  from the second apparatus  4  obtained the ticket  6  via the first apparatus  3 , the processing unit  12  executes a command indicated by the command information  6   a  included in the ticket  6 . For example, if the command information  6   a  is the script, the processing unit  12  executes the command described in the script. If the command information  6   a  is the command ID, the processing unit  12  executes the command corresponding to the command ID. For example, if the command indicated by the command information  6   a  is the command to acquire the personal data  7  on the user  9 , the processing unit  12  acquires the personal data  7  on the user  9  from the storage unit  11 . Then, the processing unit  12  transmits the acquired personal data  7  to the second apparatus  4 . 
     According to an instruction of the user  9 , the first apparatus  3  acquires the ticket  6  from the information processing apparatus  10 , and transfers the ticket  6  to a party (second apparatus  4 ) permitted to use the resource available to the user  9 . The first apparatus  3  is, for example, a terminal device used by the user  9 . 
     When receiving the ticket  6 , the second apparatus  4  transmits the ticket  6  to the information processing apparatus  10 , and causes the information processing apparatus  10  to execute the command indicated by the command information  6   a  in the ticket  6 . If the command indicated by the command information  6   a  is the command to acquire the personal data  7  on the user  9 , the second apparatus  4  receives the personal data  7  as an execution result of the command from the information processing apparatus  10 . The second apparatus  4  uses the received personal data  7  to offer a service to the user  9 . 
     With such system, the command may designate the resource, the use right of which is given to the second apparatus  4 , based on the ticket  6 . Thus, any right may be flexibly managed according to the request of the user  9 . That is, if the command executed by the processing unit  12  is a command to acquire data, data to be acquired may be arbitrarily designated by designation of an argument. For this reason, by causing the information processing apparatus  10  to execute the command, only data that satisfies a particular search condition may be acquired from the storage unit  11 . For example, according to the instruction of the user  9 , the processing unit  12  may include the command information  6   a  indicating a command to acquire only some personal data designated by the user  9 , rather than all personal data on the user  9 , in the ticket  6 . 
     The resources available to the user may be equipment connected to the information processing apparatus  10  via the network  8 . In this case, when receiving the acquisition request from the first apparatus  3 , the processing unit  12  generates a ticket including command information indicating a command to control the equipment (control command), and transmits the ticket to the first apparatus  3 . When receiving the ticket transmitted to the first apparatus  3  from the second apparatus  4 , the processing unit  12  controls the equipment based on the command indicated by the command information included in the received ticket. 
     For example, it is assumed that a door is unlocked by remote control. In this case, the available resource information  11   a  indicates a room available to the user  9 . The equipment to be controlled is a locking device for looking and unlocking a door of the room. The processing unit  12  generates a ticket including command information indicating a command to instruct the equipment to unlock the door. For example, if the user  9  who owns the first apparatus  3  rents the room, the user  9  acquiring the ticket transmits the ticket for unlocking the door from the first apparatus  3  to the second apparatus  4  owned by a renter of the room. This enables the renter to enter into the room. 
     By use of the ticket  6 , the resources managed by the information processing apparatus  10  may be used from the second apparatus  4 , which is highly convenient. On the contrary, if the ticket  6  is wrongly used, the resources managed by the information processing apparatus  10  are in danger. 
     For example, if the command information  6   a  included in the ticket  6  is rewritten after issuance of the ticket  6 , there is a risk of access to data other than the personal data  7  on the user  9  in the storage unit  11 . Thus, when receiving the acquisition request from the first apparatus  3 , the processing unit  12  may encode (or encrypt) the command information  6   a,  and generate the ticket  6  including the encoded command information  6   a.  In this case, when receiving the ticket  6  from the second apparatus  4 , the processing unit  12  decodes (or decrypt) the encoded command information  6   a  in the ticket  6 , and executes the command indicated by the decoded command information  6   a.  In this manner, any unauthorized access to data stored in the storage unit  11  may be suppressed. 
     A device capable of using the ticket  6  may be limited. For example, when receiving the acquisition request from the first apparatus  3 , the processing unit  12  generates the ticket  6  including an identifier identifying the second apparatus  4  that may use the ticket  6 , and transmits the ticket  6  to the first apparatus  3 . Further, when receiving the ticket  6 , the processing unit  12  authenticates that a source of the ticket  6  is the second apparatus  4  corresponding to the identifier and then, executes the command. If the processing unit  12  does not correctly authenticates it, the processing unit  12  suppresses the execution of the command. Thereby, the processing unit  12  may execute the command only when the ticket  6  is transmitted from a previously designated device, to suppress unintended use of the ticket  6 . 
     To suppress a database structure in the storage unit  11  being analyzed due to a leakage of the executed command, only the command ID may be included as the command information  6   a  in the ticket  6 . In this case, the storage unit  11  previously stores a correspondence table (not illustrated) in which command IDs are associated with respective command IDs, and when receiving the acquisition request  5 , the processing unit  12  generates the ticket  6  indicating the command ID corresponding to the command as the command information  6   a,  and transmits the ticket  6  to the first apparatus  3 . Further, when receiving the ticket  6  including the command ID from the second apparatus  4 , the processing unit  12  executes the command corresponding to the command ID included in the ticket  6 . Thereby, the command may be suppressed from being disclosed to the outside of the information processing apparatus  10  such that the database structure in the storage unit  11  is analyzed based on the ticket  6 . 
     Second Embodiment 
     Next, a second embodiment is described. According to the second embodiment, data collected by a particular service provider from IoT devices using the cloud system may be offered from any user having the IoT device to other service providers. 
     Here, before describing details of the second embodiment, the importance of use of data collected using the IoT device is described. 
     Personal data such as a search history and a product purchase history of a particular consumer on the Internet has been increasingly utilized. For example, based on the personal data, the consumer&#39;s interests and consumption tendency may be found to present goods that are likely to attract the attention of the consumer. In addition, the movement called IoT has occurred and thus, computers connected to the Internet may collect more personal data by means of various cameras and sensors. Meanwhile, since the collected data is information about a particular user, it is conceivable that the service provider that collected data as well as the user concerned have a right to use the data. Thus, there is a demand for a system that may offer data collected by one service provider to other service providers in response to a user&#39;s instruction. 
     As an example, an automobile insurance that analyzes driving data collected from an IoT device mounted in an automobile, and calculates a premium paid by an owner of the automobile has recently provided. Such insurance is referred to as telematics insurance. In the case where the telematics insurance is applied to a driver of a rental car or user of a shared car service, only driving data of a particulate user, rather than driving data of all automobiles, are required to be offered from a provider or the rental car or the shared car service to a provider of an automobile insurance service. 
     The OAuth is a mechanism for achieving data access between servers that are service providers based on the user&#39;s permission. According to the OAuth, only data access between servers having a fiduciary relationship is possible. In addition, according to the OAuth, the user accesses a server that receives data and performs a user authentication, checks the scope of an access right given to the server and then, permits access to the data. In the case of the telematics insurance, if the user wants to estimate expenses of a plurality of automobile insurance services via a service broker, the user has to access a plurality of servers corresponding to the plurality of automobile insurance services, and give a permission for access to each of the servers. This brings the user much time and efforts. Alternatively, the service broker may acquire driving data, and send the driving data to the plurality of servers corresponding to the plurality of automobile insurance services. However, in this case, the service broker that does not use the driving data handles the data. As more persons handle the driving data, the possibility of leakage of the driving data becomes higher, putting the driving data in danger. 
     By encoding data and issuing a license including a key for decoding the encoded data, only a licensee may access the data. According to this method, a timing at which the right to access the data is given may not be synchronized with a timing at which data is accessed. However, during the operation of service, data to be collected may be added or deleted to change available data. In offering encoded data, each time data is changed, it is required to encode data to be disclosed again, making processing complicated. 
     A system capable of easily passing driving data held by a rental car service provider to an automobile insurance service provider of the telematics insurance according to the user&#39;s judgement is described below. 
       FIG. 2  is a view illustrating an example of a configuration of the system according to the second embodiment. A server  100  of the rental car service provider is connected to a server  200  of the automobile insurance service provider via a network  20 . An IoT device  31  is mounted on an automobile  30  rented by the rental car service. 
     The IoT device  31  generates driving data that records the driving state of the automobile  30 . For example, the IoT device  31  records temporal changes such as position, speed, and acceleration of the automobile  30  as driving data in an internal storage device. The IoT device  31  is connected to the network  20  via a wireless communication network. Then, the IoT device  31  transmits the driving data to the server  100 . For example, a car navigation may be used as the IoT device  31 . 
     A user  32  who attempts to obtain the telematics insurance owns a terminal apparatus  300 . The terminal apparatus  300  is, for example, a mobile terminal apparatus such as a smart phone. The terminal apparatus  300  may be a personal computer. The terminal apparatus  300  is connected to the network  20  in a wired or wireless manner. The terminal apparatus  300  may communicate with the server  100 ,  200  via the network  20 . 
       FIG. 3  is a view illustrating an example of a hardware configuration of the server. The server  100  is controlled by a processor  101  as a whole. The processor  101  is connected to a memory  102  and a plurality of peripheral devices via a bus  109 . The processor  101  may be a multi-processor. Examples of the processor  101  include a central processing unit (CPU), a micro processing unit (MPU), or a digital signal processor (DSP). At least some of functions implemented by causing the processor  101  to run a program may be implemented by an electronic circuit such as application specific integrated circuit (ASIC), programmable logic device (PLD), or the like. 
     The memory  102  is used as a main storage device of the server  100 . At least some of programs of operating system (OS) and application programs executed by the processor  101  are temporarily stored in the memory  102 . Various kinds of data used for the processing of the processor  101  is stored in the memory  102 . For example, a volatile semiconductor storage device such as a random access memory (RAM) is used as the memory  102 . 
     The peripheral devices connected to the bus  109  are a storage device  103 , a graphic processor  104 , an input interface  105 , an optical drive device  106 , a device connection interface  107 , and a network interface  108 . 
     The storage device  103  electrically or magnetically writes and reads data to and from a built-in recording medium. The storage device  103  is used as an auxiliary storage device of the computer. OS programs, application programs, and various kinds of data are stored in the storage device  103 . For example, the hard disk drive (HDD) or the solid state drive (SSD) is used as the storage device  103 . 
     The graphic processor  104  is connected to a monitor  21 . According to a command from the processor  101 , the graphic processor  104  displays an image on the monitor  21 . A display device such as a display device using organic electro luminescence (EL) or a liquid crystal display device is used as the monitor  21 . 
     The input interface  105  is connected to a keyboard  22  and a mouse  23 . The input interface  105  transmits signals sent from the keyboard  22  and the mouse  23  to the processor  101 . The mouse  23  is an example of a pointing device and however, any other pointing device may be used. Examples of the other pointing device include touch panel, tablet, touch pad, and track ball. 
     The optical drive device  106  uses laser light or the like to read recorded in an optical disc  24 . The optical disc  24  is a portable recording medium that records data such that the data may be read by light reflection. Examples of the optical disc  24  include digital versatile disc (DVD), DVD-RAM, compact disc read only memory (CD-ROM), and CD-R (Recordable)/RW (ReWritable). 
     The device connection interface  107  is a communication interface for connecting the peripheral devices to the server  100 . For example, the device connection interface  107  may be connected to a memory device  25  or a memory reader/writer  26 . The memory device  25  is a recording medium having a function of communicating with the device connection interface  107 . The memory reader/writer  26  is a device for writing data to a memory card  27  or read data from the memory card  27 . The memory card  27  is a card-type recording medium. 
     The network interface  108  is connected to the network  20 . The network interface  108  exchanges data with other computers or communication equipment via the network  20 . 
     The above-mentioned hardware configuration may implement the processing of the server  100  according to the second embodiment. The hardware configuration as the server  100  may also implement the processing of the server  200  and the terminal apparatus  300 . If the terminal apparatus  300  is the mobile terminal device, the terminal apparatus  300  includes a wireless communication interface using radio waves, in addition to the hardware illustrated in  FIG. 3 . The IoT device  31  includes the same hardware configuration as the server  100 , a wireless communication interface using radio waves, a receiver for satellite positioning system, and an acceleration sensor. The same hardware as the server  100  illustrated in  FIG. 3  may also implement the information processing apparatus  10  according to the first embodiment. 
     The servers  100 ,  200  and the terminal apparatus  300  execute the program recorded in a computer-readable recording medium, to implement the processing according to the second embodiment. The program describing contents of the processing executed by each of the servers  100 ,  200  and terminal apparatus  300  may be recorded in various recording media. For example, the program executed by the server  100  may be stored in the storage device  103 . The processor  101  loads at least a portion of the program in the storage device  103  into the memory  102 , and executes the program. The program executed by the server  100  may be recorded in a portable recording medium such as the optical disc  24 , the memory device  25 , or the memory card  27 . The program stored in the portable recording medium is installed in the storage device  103  under control of the processor  101  and then, becomes executable. The processor  101  may read the program directly from the portable recording medium, and execute the program. 
     Next, functions of each device to estimate the premium of the telematics insurance based on driving data collected while the user  32  drives the automobile  30  provided by the rental car service are described. 
       FIG. 4  is a block diagram illustrating the functions of each device. The server  100  for rental car service has a database  110 , a contract management unit  120 , a driving data acquisition unit  130 , an access ticket generation unit  140 , and an access ticket execution unit  150 . 
     The database  110  stores a use history of the user  32  about the automobile  30 , and driving data  41  acquired when the user  32  was driving the automobile  30 . The driving data  41  is a collection of measurement values (automobile state measurement values) indicating the state of the automobile  30  periodically measured while the user  32  drives the automobile  30 . The automobile state measurement values include the speed of the automobile  30  at respective measurement time points and so on, and the driving tendency of the user  32  may be analyzed based on information about the speed and so on, which is indicated by each of the plurality of automobile state measurement values. For example, a portion of a storage area of the memory  102  or the storage device  103  is used as the database  110 . In the example illustrated in  FIG. 4 , the database  110  stores a driving data management table  111  and a user management table  112 . The driving data management table  111  is a data table for managing the driving data  41 . In the driving data management table  111 , an identifier (automobile ID) of the automobile  30  is associated with place, speed, date and time of the automobile  30 . The user management table  112  is a table for managing the user  32  using the rental car service. In the user management table  112 , an identifier (user ID) of the user  32  is associated with the automobile ID and the rental period of the automobile  30  used by the user  32 . 
     The contract management unit  120  executes processing of concluding a rental contract of the automobile  30  with the user  32 . For example, in response to a request of the rental contract from the terminal apparatus  300  held by the user  32 , the contract management unit  120  establishes the rental contract. If lending of the automobile  30  to the user  32  is established, the contract management unit  120  registers a record that indicates contents of the rental contract in the user management table  112 . 
     The driving data acquisition unit  130  acquires the driving data  41  in a period when the user  32  was driving the automobile  30 , from the automobile  30 . The driving data  41  includes, for example, place (latitude and longitude), speed, and time and date of the automobile  30  measured at regular intervals. The driving data acquisition unit  130  stores the acquired driving data  41  in the driving data management table  111 . 
     In response to a request of an access ticket from the terminal apparatus  300 , the access ticket generation unit  140  generates an access ticket  42  for permitting an access to the driving data  41  in the period when the user  32  was using the automobile  30 . The access ticket  42  includes a script (a string of one or more commands) describing the processing of acquiring the driving data  41  in the period when the user  32  was using the automobile  30  from the database  110 . The access ticket generation unit  140  transmits the generated access ticket  42  to the terminal apparatus  300 . 
     When receiving the access ticket  42  from the server  200  for automobile insurance service, the access ticket execution unit  150  executes the script included in the access ticket  42 , thereby acquiring the driving data  41  from the database  110 . The access ticket execution unit  150  transmits the acquired driving data  41  to the server  200 . 
     The server  200  for automobile insurance service has a premium estimation unit  210 . Based on the driving data  41 , the premium estimation unit  210  calculates the premium of the automobile insurance offered to the user  32 . For example, when acquiring a premium estimation request at next use of a rental car from the terminal apparatus  300  used by the user  32 , the premium estimation unit  210  transmits the access ticket request to the terminal apparatus  300 . When acquiring the access ticket  42  from the terminal apparatus  300 , the premium estimation unit  210  transmits the access ticket to the server  100 . When further receiving the driving data  41  from the server  100 , the premium estimation unit  210  calculates the premium based on the driving data  41 . The premium estimation unit  210  transmits the calculated premium as an estimation result to the terminal apparatus  300 . 
     Line connecting the elements to each other in  FIG. 4  illustrate some of communication paths, and communication paths other than the illustrated paths may be set. Functions of the elements illustrated in  FIG. 4  may be implemented by causing the computer to execute program modules corresponding to the elements. 
     A procedure of premium estimation processing executed by the system illustrated in  FIG. 4  is described below in the execution order of the processing. 
     First, rental contract processing and driving data collection processing are described. 
       FIG. 5  is a sequence diagram illustrating a procedure of the rental contract processing and the driving data collection processing. First, using an access ticket management unit  310  of the terminal apparatus  300 , the user  32  accesses the server  100  for rental car service. Then, the user  32  inputs authentication information such as a set of a user ID and a password of the user  32  to the terminal apparatus  300 . Then, the access ticket management unit  310  transmits a user authentication request including the authentication information to the server  100  for rental car service (Step S 101 ). 
     In response to the user authentication request, the contract management unit  120  of the server  100  performs the user authentication (Step S 102 ). For example, the contract management unit  120  determines whether or not the authentication information included in the user authentication request matches user information (set of user ID and password) previously registered in the server  100 . If the authentication information matches the user information, the contract management unit  120  determines that the user  32  using the terminal apparatus  300  is a valid user corresponding to the matched user information. When determining that the user  32  is the valid user, the contract management unit  120  notifies that the user authentication succeeded to the terminal apparatus  300 . 
     When the user authentication succeeds, the access ticket management unit  310  transmits contract data indicating a service contract proposal to the server  100  (Step S 103 ). For example, the access ticket management unit  310  selects the automobile  30  and designates the rental period via a Web browser, and transmits the contract data. 
       FIG. 6  is a view illustrating an example of the contract data. Contract data  43  includes the user ID “user0001” of the user  32 , the automobile ID “car0001” of the automobile  30 , the use start data and time “2017-05-01T12:00:00”, and the use end data and time “2017-05-01T14:00:00”. 
     Hereinafter, description is made with reference to  FIG. 5 . 
     The contract management unit  120  of the server  100  receives the contract data  43  from the authenticated user, and if the designated automobile  30  may be rented in the designated period, establishes the service contract (Step S 104 ). Next, the contract management unit  120  stores the contract data  43  in the database  110  (Step S 105 ). For example, the contract management unit  120  registers the record including information indicated by the contract data  43 , in the user management table  112 . 
     In this manner, the rental contract processing is executed, and the user  32  will use the automobile  30  during the rental period. When the user  32  uses the automobile  30 , the states of the automobile (place, speed, date and time) are measured with a sensor and a communication device in the automobile  30 . 
     The IoT device  31  periodically measures the automobile states (place, speed, date and time), and acquires the automobile state measurement values (Step S 111 ). Then, the IoT device  31  transmits the automobile state measurement values to the server  100  (Step S 112 ). 
     In the server  100 , the driving data acquisition unit  130  receives the automobile state measurement values (Step S 113 ). The driving data acquisition unit  130  stores the acquired automobile state measurement values in the database  110  (Step S 114 ). For example, the driving data acquisition unit  130  registers the acquired automobile state measurement values and the automobile ID of the automobile  30  as one record, in the driving data management table  111 . 
     The automobile state measurement values are repeatedly accumulated while the user  32  uses the automobile  30  (rental period), and a collection of the accumulated automobile state measurement values becomes the driving data  41  on the user  32 . 
       FIG. 7  is a view illustrating an example of the driving data. The driving data  41  includes the automobile state measurement values at each measurement time. The automobile state measurement values include information on automobile ID, measurement date and time, and speed of the automobile  30 . 
     After that, when the user  32  rents the rental car again and obtains the automobile insurance, the user  32  uses the access ticket management unit  310  of the terminal apparatus  300  to access the server  200  for automobile insurance service. The automobile insurance of the server  200  offers the driving data, thereby notifying a change in the premium of the automobile insurance to the user, urging the user to offer the access ticket  42 . Using the access ticket management unit  310  of the terminal apparatus  300 , the user  32  that received the notification accesses the server  100  for rental car service and acquire the access ticket  42 . Then, using the access ticket management unit  310  of the terminal apparatus  300 , the user  32  transmits the access ticket  42  to the server  200  for automobile insurance service. 
     With reference to  FIGS. 8 to 11 , the processing of acquiring the access ticket  42  from the server  100  for rental car service is described below in detail. 
       FIG. 8  is a sequence diagram illustrating an example of a procedure of processing of offering the access ticket to the server for automobile insurance service. 
     The access ticket management unit  310  of the terminal apparatus  300  transmits a premium estimation request to the server  200  for automobile insurance service (Step S 121 ). In the server  200 , the premium estimation unit  210  receives the premium estimation request (Step S 122 ). When receiving the premium estimation request, the premium estimation unit  210  transmits the access ticket request on the driving data  41  to the terminal apparatus  300  (Step S 123 ). The access ticket management unit  310  of the terminal apparatus  300  receives the access ticket request (Step S 124 ). If the access ticket management unit  310  has not received the access ticket  42  yet at this time, the access ticket management unit  310  acquires the access ticket  42 . 
       FIG. 9  is a sequence diagram illustrating an example of a procedure of processing of acquiring the access ticket from the server for rental car service. 
     The access ticket management unit  310  of the terminal apparatus  300  transmits the user authentication request including the authentication information (the user ID and the password of the user  32 ) inputted from the user  32  to the server  100  for rental car service (Step S 131 ). Based on the authentication information indicated in the user authentication request, the access ticket generation unit  140  of the server  100  performs the user authentication (Step S 132 ). When the user authentication succeeds, the access ticket generation unit  140  transmits information indicating log-in to the terminal apparatus  300 . In this manner, the user  32  logs in to the server  100 . 
     When logging in to the server  100 , the user  32  instructs the access ticket management unit  310  to transmit the access ticket request. For example, the access ticket management unit  310  acquires history information indicating that the user  32  used the rental car service from the server  100 , and displays the history information. The user  32  selects a desired period of driving data from the displayed history information. Then, the access ticket management unit  310  transmits the access ticket request designating the selected period to the server  100  (Step S 133 ). 
       FIG. 10  is a view illustrating an example of the access ticket request. An access ticket request  40  includes the automobile ID of the automobile  30  used by the user  32  and the start date and time and the end date and time in the designated period of acquired driving data. 
     Hereinafter, description is made with reference to  FIG. 9  again. The access ticket generation unit  140  of the server  100  for rental car service receives the access ticket request (Step S 134 ). Next, the access ticket generation unit  140  generates a script for acquiring the driving data  41  on the user  32  in the designated period from the database  110  (Step S 135 ). At this time, to not generate any unauthorized request, the access ticket generation unit  140  may confirm that the user  32  used the automobile  30  as a source for the driving data  41  in the designated period. For example, since the access ticket generation unit  140  recognizes the user ID of the user  32  through the user authentication, the access ticket generation unit  140  searches the user management table  112  based on the user ID and the automobile ID of the automobile  30 . If the period indicated in the access ticket request falls within the rental period indicated in the record acquired as a search result, the access ticket generation unit  140  determines that the automobile  30  was rented to the user  32  in the designated period. 
     After generating the script, the access ticket generation unit  140  generates a key for encoding, and encodes the script using the key (Step S 136 ). The access ticket generation unit  140  stores the key used for encoding in the memory  102  or the storage device  103 . The key used for encoding is also used for decoding of the script. 
     Next, the access ticket generation unit  140  generates the access ticket  42  including the encoded script in payload (Step S 137 ). Then, the access ticket generation unit  140  transmits the generated access ticket  42  to the terminal apparatus  300  (Step S 138 ). In the terminal apparatus  300 , the access ticket management unit  310  receives the access ticket  42  (Step S 139 ). 
     In this manner, the user  32  may acquire the access ticket  42  about the driving data  41  in any period. The access ticket generation unit  140  may generate the access ticket  42 , for example, by using a template. 
       FIG. 11  is a view illustrating an example of the access ticket using a template. For example, the server  100  stores a template  44  for generating the access ticket  42  in the storage device  103 . The template  44  represents a script that instructs acquisition of driving data including temporary values of the automobile ID of the automobile  30  and the start date and time and the end date and time in the target acquisition period of driving data. The access ticket generation unit  140  replaces the temporary values of the template  44  with values indicated in the access ticket request, thereby generating a script  45  corresponding to the access ticket request. In the example illustrated in  FIG. 11 , items described as “CARID”, “DATE1”, and “DATE2” in the template  44  are replaced with the automobile ID of the automobile, the start date and time in the target acquisition period, and the end date and time in the target acquisition period, respectively. 
     The script  45  illustrated in  FIG. 11  is described in JavaScript (registered trademark), and accesses a database managed by MySQL. The script  45  may be described in any language other than JavaScript (registered trademark). The script  45  describes processing of acquiring data stored in the driving data management table  111  of the database  110  in the server  100  for rental car service. The script  45  designates automobile ID “car0001” and period “2017/5/110:00-12:00” as acquisition conditions. 
     After generating the script  45 , the access ticket generation unit  140  generates the access ticket  42  including a header and a payload. The header includes, for example, uniform resource locator (URL) identifying the access ticket execution unit  150  in the server  100 . The header includes the start date and time and the end date and time in an effective period of the access ticket  42 . The encoded script  45  is set to the payload of the access ticket  42 . 
     In this manner, the access ticket  42  may be easily generated using the template  44 . A method of designating the source for the driving data  41  using the access ticket  42  is not limited to URL. 
     When acquiring the access ticket, the terminal apparatus  300  offers the access ticket  42  to the server  200  for automobile insurance service. Using the access ticket  42 , the server  200  acquires the driving data  41  on the user  32  from the server  100  for rental car service, and estimates the premium based on the driving data  41 . 
       FIG. 12  is a sequence diagram illustrating an example of a procedure of the premium estimation processing using the access ticket. In response to the access ticket request from the server  200  for automobile insurance service (see  FIG. 10 ), the access ticket management unit  310  of the terminal apparatus  300  transmits the access ticket  42  acquired from the server  100  to the server  200  (Step S 141 ). The premium estimation unit  210  of the server  200  receives the access ticket  42  (Step S 142 ). 
     When receiving the access ticket  42 , the premium estimation unit  210  confirms the source (URL) for the driving data  41  according to the header of the access ticket  42  (Step S 143 ). The premium estimation unit  210  transmits the access ticket  42  to the access ticket execution unit  150  in the server  100  as the source for the driving data  41  (Step S 144 ). 
     The access ticket execution unit  150  receives the access ticket  42  (Step S 145 ). Using a key stored in the memory  102  or the storage device  103 , the access ticket execution unit  150  decodes encoded data set in the payload of the received access ticket  42  (Step S 146 ). The decoding generates the script  45  describing a statement for acquiring the driving data  41  (see  FIG. 11 ). The access ticket execution unit  150  executes the decoded script  45  (Step S 147 ). The access ticket execution unit  150  may execute the script  45  to acquire the driving data  41  on the user  32  from the database  110 . The access ticket execution unit  150  transmits the acquired driving data  41  to the server  200  (Step S 148 ). 
     The premium estimation unit  210  of the server  200  receives the driving data  41  (Step S 149 ). The premium estimation unit  210  calculates the premium concerning possible accidents occurring during driving of the rental car by the user  32 , based on the received driving data  41  (Step S 150 ). For example, when determining that the user  32  tends to drive carefully according to the driving data  41 , the premium estimation unit  210  estimates a low premium. When determining that the user  32  tends to drive carelessly according to the driving data  41 , the premium estimation unit  210  estimates a high premium. The driving tendency of the user  32  is determined based on presence/absence of rapid acceleration, level of compliance with regulation speed. 
     When calculating the premium, the premium estimation unit  210  transmits a calculation result of the premium to the terminal apparatus  300  (Step S 151 ). The access ticket management unit  310  of the terminal apparatus  300  receives an estimation result of the premium, and displays the premium on a monitor (Step S 152 ). 
     In this manner, the access ticket  42  may give an access right to the driving data  41  on the user  32  to the server  200  for automobile insurance service. In the access ticket  42 , the scope of the access right may be set using the script in more detail. For example, an SQL statement may limit data to be accessed. This enables highly flexible access right management. 
     Encoding the script in the access ticket  42  ensures the security of the driving data acquired though the script. That is, the script in the access ticket  42  is a command executed by the server  100  issuing the access ticket  42 , even if the script is viewed by a third party, no data is leaked. However, since the command contains information on the SQL, the internal structure of the database  110  may be grasped, or ID information contained in the SQL may provide a hint for hacking. Therefore, encoding the script may suppress information that is a hint for hacking from leaking to any unauthorized third party, further improving the security of data in the database  110 . 
     Moreover, only the server  100  may hold the key for encoding and decoding. Thus, there is less likely that the encoded script is illegally decoded by leakage of the key. 
     The script may not be encoded at generation of the access ticket  42 , but communication between servers may be encoded. For example, communication between servers may be encoded by hypertext transfer protocol secure (HTTPS) commonly used in Web services. 
     Third Embodiment 
     Next, a third embodiment is described. According to the third embodiment, the access right to the driving data  41  on the user  32  is given to a plurality of automobile insurance service providers via the insurance service broker. 
       FIG. 13  is a view illustrating an example of a system according to the third embodiment. A difference between the third embodiment and the second embodiment is that the user  32  does not directly access the server  200  for automobile insurance service, and a server  400  prepared by the insurance service broker is used instead. 
     At estimation of the premium, the user  32  uses the terminal apparatus  300  to access the server  400  for insurance service broker. The user  32  requests premium estimation for next rental from the terminal apparatus  300  to the server  400 . The request of premium estimation is received by a premium estimation proxy request unit  410  of the server  400 . The premium estimation proxy request unit  410  transmits the access ticket request to the terminal apparatus  300 . In response to the access ticket request, the terminal apparatus  300  acquires the access ticket  42  from the server  100  for rental car service. Details of the acquisition processing of the access ticket  42  are the same as those in the second embodiment. 
     The terminal apparatus  300  transmits the acquired access ticket  42  to the server  400  for insurance service broker. Then, the premium estimation proxy request unit  410  of the server  400  transmits access tickets  42   a,    42   b,  . . . to respective servers  200   a,    200   b,  . . . of the plurality of automobile insurance service providers. 
     When receiving the access ticket  42   a,  the server  200   a  transmits the access ticket  42   a  to the server  100  for rental car service, and acquires the driving data  41  from the server  100 . Similarly, other servers  200   b,  . . . for automobile insurance service transmit the acquired access ticket  42   b  to the server  100  to acquire the driving data  41 . Based on the driving data  41 , the servers  200   a,    200   b,  . . . calculate premiums according to standards in the automobile insurance service-offering companies that manage the respective servers  200   a,    200   b , . . . . The servers  200   a,    200   b,  . . . transmit the calculated premiums as estimation results  46   a,    46   b,  . . . to the server  400  of the insurance service broker. 
     In the server  400 , the premium estimation proxy request unit  410  receives the estimation results  46   a,    46   b,  . . . from the plurality of servers  200   a,    200   b,  . . . , and transmits the estimation results  46   a,    46   b,  . . . together to the terminal apparatus  300 . 
     By the intervention of the server  400  for insurance service broker, the user may simultaneously request a plurality of automobile insurance service companies to do estimation, and acquire the respective estimation results  46   a,    46   b , . . . . The user  32  may select a desired service from the plurality of estimation results  46   a,    46   b , . . . . 
     Fourth Embodiment 
     Next, a fourth embodiment is described. According to the fourth embodiment, an access destination for receiving the driving data may be determined without writing URL to the header of the access ticket. 
       FIG. 14  is a view illustrating an example of a system according to the fourth embodiment. The fourth embodiment is different from the second embodiment in that, in the processing in the server  100 , the URL indicating the access ticket execution unit  150  is described in the header in the access ticket  47 . According to the fourth embodiment, the access ticket generation unit  140  sets an identifier (service ID) of the service offered to the user  32 , to the header of the access ticket  47 . 
     The system according to the fourth embodiment is provided with a server  500  that performs a platform service for executing the processing of acquiring the driving data from the server  100  for rental car service. The server  500  has a driving data receiving-URL storage unit  510  and a driving data proxy acquisition unit  520 . The driving data receiving-URL storage unit  510  associates the service ID with the URL indicating the source for the driving data  41  acquired when the service represented by the service ID is offered. 
     The premium estimation unit  210  of the server  200  for automobile insurance service acquires the access ticket  47  from the terminal apparatus  300  in the same manner as in the second embodiment. The premium estimation unit  210  transmits the acquired access ticket  47  to the server  500 . In the server  500 , referring to the driving data receiving-URL storage unit  510 , the driving data proxy acquisition unit  520  acquires a driving data receiving-URL corresponding to the service ID indicated in the access ticket  47 . Then, the driving data proxy acquisition unit  520  transmits the access ticket  47  to the acquired URL, to acquire the driving data  41 . The driving data proxy acquisition unit  520  transmits the acquired driving data  41  to the server  200  for automobile insurance service. 
     In preparing proxy acquisition of the driving data on the user  32 , the driving data proxy acquisition unit  520  of the server  500  acquires the driving data receiving-URL from the server  100  for rental car service. 
       FIG. 15  is a sequence diagram illustrating an example of a procedure of driving data receiving-URL acquisition processing. For example, it is assumed that the authentication information (the user ID and the password) on the user  32  is previously registered in the server  500 . Then, the driving data proxy acquisition unit  520  transmits the authentication information on the user  32  to the server  100  (Step S 151 ). The access ticket execution unit  150  of the server  100  performs user authentication of the user  32  having an account based on the authentication information (Step S 152 ). Then, the access ticket execution unit  150  transmits a set of the service ID of the service offered to the user  32  and the driving data receiving-URL identifying the access ticket execution unit  150  to the server  500  (Step S 153 ). The driving data proxy acquisition unit  520  of the server  500  receives the set of the service ID and the driving data receiving-URL (Step S 154 ). Then, the driving data proxy acquisition unit  520  stores the set of the service ID and the driving data receiving-URL in the driving data receiving-URL storage unit  510  (Step S 155 ). For example, the driving data receiving-URL storage unit  510  stores a URL management table  511 . The driving data proxy acquisition unit  520  adds a new record including the received set of the service ID and the driving data receiving-URL to the URL management table  511 . 
     Next, driving data acquisition processing via the server  500  for platform service is described. 
       FIG. 16  is a sequence diagram illustrating an example of a procedure of the driving data acquisition processing according to the fourth embodiment. When receiving the access ticket  47  from the terminal apparatus  300 , the premium estimation unit  210  of the server  200  for automobile insurance service sends an access ticket transmission (application programming interface) API call to the server  500  (Step S 161 ). The access ticket transmission API call includes the access ticket  47 . The driving data proxy acquisition unit  520  of the server  500  receives the access ticket transmission API call from the premium estimation unit  210  (Step S 162 ). The driving data proxy acquisition unit  520  acquires the service ID from the header of the access ticket  47  included in the access ticket transmission API call, and acquires the URL corresponding to the service ID from the access ticket receiving-URL storage unit  510  (Step S 163 ). The driving data proxy acquisition unit  520  transmits the access ticket  47  to the acquired URL. The transmitted access ticket  47  is received by the access ticket execution unit  150  of the server  100  (Step S 165 ). 
     The access ticket execution unit  150  of the server  100  decodes encoded data in the payload of the access ticket  47 , and generates the script (Step S 166 ). The access ticket execution unit  150  executes the generated script (Step S 167 ). The driving data  41  is acquired by executing the script. Then, the access ticket execution unit  150  sends a data transmission API call to the server  500  (Step S 168 ). The data transmission API call includes the driving data  41 . 
     The driving data proxy acquisition unit  520  of the server  500  receives the driving data  41  included in the data transmission API call (Step S 169 ). The driving data proxy acquisition unit  520  transmits the received driving data to the server  200  (Step S 170 ). The premium estimation unit  210  of the server  200  receives the driving data  41  (Step S 171 ). 
     In this manner, even if the access ticket  47  does not include the URL indicating the access ticket execution unit  150 , the server  200  may pass the access ticket  47  acquired from the terminal apparatus  300  to the access ticket execution unit  150 , and acquire the driving data  41 . 
     Fifth Embodiment 
     Next, a fifth embodiment is described. According to the fifth embodiment, a platform for managing user&#39;s access tickets is provided. 
       FIG. 17  is a view illustrating an example of a system according to the fifth embodiment. In the example illustrated in  FIG. 17 , the user  32  has rented rental cars from a plurality of rental car service-offering companies, and servers  100   a,    100   b,  . . . of the rental car service-offering companies hold the driving data on the user  32 . 
     A server  600  of a company providing the platform service is connected to the servers  100   a,    100   b,  . . . for rental car service and the terminal apparatus  300  via a network. The server  600  has access ticket storage units  610 ,  620  by user and an access ticket management proxy unit  630 . 
     The access ticket storage unit  610  stores access tickets  48   a,    48   b,  . . . indicating the data access right of the user  32 . Similarly, the access ticket storage unit  620  stores the access ticket indicating the data access right of a user not illustrated. 
     The access ticket management proxy unit  630  manages the access tickets by user. For example, each of the servers  100   a,    100   b,  . . . for rental car service collects the driving data on the user  32  and then, transmits access tickets  48   a,    48   b,  . . . indicating the access right to the driving data, to the server  600  for platform service. For example, the servers  100   a,    100   b,  . . . transmit the access tickets when the rental period of the rental car of the user  32  has passed. 
     In the server  600 , the access ticket management proxy unit  630  receives the access ticket  48   a,    48   b , . . . . The access ticket management proxy unit  630  stores the received access tickets  48   a,    48   b,  . . . in the access ticket storage unit  610  corresponding to the user  32 . For example, the access ticket management proxy unit  630  has an API execution function using the user ID as an argument. In this case, the servers  100   a,    100   b,  . . . send an API call using the user ID as the argument. The access ticket management proxy unit  630  receives the API call, and stores the access ticket in the access ticket storage unit corresponding to the user ID indicated by the argument in the API call. In response to the access ticket request from the terminal apparatus  300 , the access ticket management proxy unit  630  transmits the access tickets  48   a,    48   b,  . . . to the terminal apparatus  300 . 
     The access ticket management unit  310  of the terminal apparatus  300  accesses the server  600 , and acquires the access tickets  48   a,    48   b,  . . . indicating the access right to the own driving data. Then, at estimation of the premiums, the access ticket management unit  310  transmits the access ticket  48   a,    48   b,  . . . to the server  200  for automobile insurance service. It is assumed that the headers of the access tickets  48   a,    48   b,  . . . each include the URL identifying the source for the driving data. The premium estimation unit  210  of the server  200  transmits the access tickets  48   a,    48   b,  . . . to the respective URLs indicated in the headers. The plurality of servers  100   a,    100   b,  . . . transmit driving data  49   a,    49   b,  . . . on the user  32  to the server  200 . The premium estimation unit  210  of the server  200  determines the driving tendency of the user  32  based on the driving data  49   a,    49   b,  . . . , and calculates the premiums. Then, the premium estimation unit  210  transmits the premium estimation results to the terminal apparatus  300 . 
     In this manner, the server  600  for platform service may manage access tickets about a plurality of services, thereby easily acquiring driving data in a plurality of rental car services. 
     The platform service only has to provide the access tickets at any time when the user wants. In the example illustrated in  FIG. 17 , the method of managing the access tickets on the server  600  is described. However, for example, the access tickets may be managed by using an application software in the terminal apparatus  300 . In this case, in response to the access ticket request at estimation of the premium, the user  32  selects the access ticket to be transmitted from among the access tickets stored in the terminal apparatus  300 . The terminal apparatus  300  transmits the access ticket selected by the user to the server  200  for automobile insurance service. 
     It is convenient to provide the user  32  with information that is a ground for selecting the access ticket. Thus, the servers  100   a,    100   b,  . . . may add information about contents of the access tickets to the access tickets. In this case, when accepting the selection of the access ticket from the user  32 , the terminal apparatus  300  displays the information about contents of each access ticket. This enables the user  32  to select the access ticket as desired. The information about contents of the access ticket may be service name, for example, in the case of rental car, rental period, car name, and the like. The information may be included in the header of the access ticket. Alternatively, the terminal apparatus  300  may acquire the information about contents of the access tickets, separately from the access tickets, from the servers  100   a,    100   b, . . . or the server  600 .    
     Sixth Embodiment 
     Next, a sixth embodiment is described. According to the sixth embodiment, in an overseas tour service, the access right to data using the access ticket is managed. According to the sixth embodiment, when the user  32  participates in a tour, using the access ticket, the access right to reservation data on airplane and hotel is given to travel agency, planning companies of optional tour, and so on. 
       FIG. 18  is a view illustrating an example of a system according to the sixth embodiment. According to the sixth embodiment, a plurality of servers  710 ,  720 ,  730 , and  740  and the terminal apparatus  300  execute processing in cooperation with each other. 
     The server  710  is a server computer for flight service managed by an airline. The server  710  has a flight reservation information storage unit  711 , a reservation acceptance unit  712 , an access ticket generation unit  713 , and an access ticket execution unit  714 . The flight reservation information storage unit  711  stores information indicating contents of reservation of an airplane seat (flight reservation information). The reservation acceptance unit  712  accepts reservation of the airplane seat. The access ticket generation unit  713  generates an access ticket  51  indicating the access right to the flight reservation information. The access ticket execution unit  714  executes a script included in the access ticket  51 , to acquire flight reservation information  53  on the user  32  from the flight reservation information storage unit  711 . 
       FIG. 19  is a view illustrating an example of the flight reservation information storage unit. The flight reservation information storage unit  711  stores, for example, a flight reservation management table  711   a.  A record including user ID, tour ID, flight ID, origin, destination, departure time, and arrival time for each flight reservation is registered in the flight reservation management table  711   a.    
     Hereinafter, description is made with reference to  FIG. 18  again. 
     The server  720  is a server computer for hotel service managed by a hotel operating company. The server  720  has a hotel reservation information storage unit  721 , a reservation acceptance unit  722 , an access ticket generation unit  723 , and an access ticket execution unit  724 . The hotel reservation information storage unit  721  stores information indicating contents of reservation of hotel (hotel reservation information). The reservation acceptance unit  722  accepts the hotel reservation. The access ticket generation unit  723  generates an access ticket  52  indicating the access right to the hotel reservation information. The access ticket execution unit  724  executes a script included in the access ticket  52 , and acquires hotel reservation information  54  on the user  32  from the hotel reservation information storage unit  721 . 
       FIG. 20  is a view illustrating an example of a hotel reservation information storage unit. The hotel reservation information storage unit  721  stores, for example, a hotel reservation management table  721   a.  A record including user ID, tour ID, hotel name, hotel place, check-in date, and check-out date for each reservation is registered in the hotel reservation management table  721   a.    
     Hereinafter, description is made with reference to  FIG. 18  again. 
     The server  730  is a server computer for tour service managed by a tour planning company. The server  730  has an access ticket storage unit  731  and a tour reservation management unit  732 . The access ticket storage unit  731  stores access tickets  51 ,  52  for each customer. In response to an order of the tour from the user  32 , the tour reservation management unit  732  executes processing of booking the airplane seat and a hotel as a place to stay. The tour reservation management unit  732  also executes processing of acquiring the access ticket. 
     The server  740  is a server computer for optional tour service managed by an optional tour planning company. The server  740  has an optional tour reservation management unit  741 . Based on the flight reservation information  53  and the hotel reservation information  54  on the user  32 , the optional tour reservation management unit  741  determines optional tours in which the user  32  may participate, and presents the optional tours to the user  32 . 
     The user  32  accesses the server  730  for tour service, for example, by using the terminal apparatus  300 , and applies to reserve the tour. In response to the application for reservation of the tour from the terminal apparatus  300 , the tour reservation management unit  732  of the server  730  requests the server  710  for flight service to reserve the airplane seat (flight reservation). In response to the request of flight reservation, the reservation acceptance unit  712  of the server  710  reserves the airplane seat for the user  32 . Further, the reservation acceptance unit  712  stores the flight reservation information in the flight reservation information storage unit  711 . When the flight reservation is completed, the access ticket generation unit  713  generates the access ticket  51  indicating the access right to the flight reservation information, and transmits the access ticket  51  to the server  730 . The access ticket  51  includes a script that described a command to acquire the flight reservation information for the user  32 . 
       FIG. 21  is a view illustrating an example of the script included in the access ticket of the flight reservation information. For example, a script  51   a  includes an SQL statement (SELECT*FROM flight_data WHERE tourid=‘tour0001’ AND userid=‘user0001’;) that designates the tour ID and the user ID, and acquires the flight reservation information. 
     Hereinafter, description is made with reference to  FIG. 18  again. 
     Further, in response to an order of the tour from the terminal apparatus  300 , the tour reservation management unit  732  requests the server  720  for hotel service to reserve a hotel room (hotel reservation). In response to the request of hotel reservation, the reservation acceptance unit  722  of the server  720  reserves the hotel room stayed by the user  32 . Further, the reservation acceptance unit  722  stores the hotel reservation information in the hotel reservation information storage unit  721 . When the hotel reservation is completed, the access ticket generation unit  723  generates the access ticket  52  indicating the access right to the hotel reservation information, and transmits the access ticket  52  to the server  730 . The access ticket  52  includes a script that describes a command to acquire the hotel reservation information on the user  32 . 
       FIG. 22  is a view illustrating an example of a script included in the access ticket of the hotel reservation information. For example, a script  52   a  includes an SQL statement (SELECT*FROM hotel_data WHERE tourid=‘tour0001’ AND userid=‘user0001’;) that designates the tour ID and the user ID, and acquires the hotel reservation information. 
     Hereinafter, description is made with reference to  FIG. 18  again. 
     In the server  730 , the access tickets  51 ,  52  transmitted from the servers  710 ,  720  are received by the tour reservation management unit  732 . The tour reservation management unit  732  stores the received access tickets  51 ,  52  in the access ticket storage unit  731 . 
     Here, it is assumed that the user  32  is considering participating in an optional tour at a staying place. In this case, the user  32  applies to reserve a tour, and uses the terminal apparatus  300  to access the server  740  for optional tour service. Then, the user  32  inputs an instruction to display optional tours in which the user may participate on the terminal apparatus  300 . Then, the access ticket management unit  310  of the terminal apparatus  300  requests the server  740  to propose optional tours. 
     The request to propose the optional tours from the terminal apparatus  300  is received by the optional tour reservation management unit  741  of the server  740 . When receiving the request to propose the optional tours, the optional tour reservation management unit  741  transmits the access ticket request to the terminal apparatus  300 . 
     In the terminal apparatus  300 , the access ticket management unit  310  receives the access ticket request. Then, the access ticket management unit  310  transmits the access ticket request to the server  730 . In response to the access ticket request from the terminal apparatus  300 , the tour reservation management unit  732  of the server  730  acquires the access tickets  51 ,  52  about the tour reserved by the user  32  from the access ticket storage unit  731 . Then, the tour reservation management unit  732  transmits the acquired access tickets  51 ,  52  to the terminal apparatus  300 . 
     The access ticket management unit  310  of the terminal apparatus  300  receives the access tickets  51 ,  52  from the server  730 . Then, the access ticket management unit  310  transmits the access tickets  51 ,  52  to the server  740 . 
     In the server  740  for optional tour service, the optional tour reservation management unit  741  receives the access tickets  51 ,  52 . Then, the optional tour reservation management unit  741  transmits the access ticket  51  to the server  710  for flight service. In the server  710 , the access ticket execution unit  714  receives the access ticket  51 . The access ticket execution unit  714  executes the script  51   a  included in the payload of the access ticket  51  (see  FIG. 21 ). As a result, the access ticket execution unit  714  acquires the flight reservation information  53  on the user  32  from the flight reservation information storage unit  711 . The access ticket execution unit  714  transmits the acquired flight reservation information  53  to the server  740 . 
     The optional tour reservation management unit  741  transmits the access ticket  52  to the server  720  for hotel service. In the server  720 , the access ticket execution unit  724  receives the access ticket  52 . The access ticket execution unit  724  executes the script  52   a  included in the payload of the access ticket  52  (see  FIG. 22 ). As a result, the access ticket execution unit  724  acquires the hotel reservation information  54  on the user  32  from the hotel reservation information storage unit  721 . The access ticket execution unit  724  transmits the acquired hotel reservation information  54  to the server  740 . 
     The optional tour reservation management unit  741  of the server  740  receives the flight reservation information  53  transmitted from the server  710 . The optional tour reservation management unit  741  receives the hotel reservation information  54  transmitted from the server  720 . Based on the flight reservation information  53  and the hotel reservation information  54 , the optional tour reservation management unit  741  recognizes a rough tour schedule of the user  32 . Then, according to the tour schedule of the user  32 , the optional tour reservation management unit  741  extracts optional tours in which the user  32  may participate from a prepared optional tour list. The optional tour reservation management unit  741  transmits information on the extracted optional tour as optional tour proposal information to the terminal apparatus  300 . 
     The access ticket management unit  310  of the terminal apparatus  300  displays optional tour information that is the optional tour proposal information on a monitor. Based on the displayed optional tour information, the user  32  selects a desired optional tour, and applies to participate in the optional tour. 
     In this manner, the user  32  may only pass the access tickets  51 ,  52  to the server  740  for optional tour service, thereby receiving a proposal for optional tours suitable for the tour that the user participate in. This may facilitate selection of the optional tour. 
     In the example illustrated in  FIG. 18 , the terminal apparatus  300  acquires the access tickets  51 ,  52  from the server  730 . However, the terminal apparatus  300  may acquire the access tickets  51 ,  52  from each of the servers  710 ,  720 . 
     Seventh Embodiment 
     Next, a seventh embodiment is described. According to the second to sixth embodiments, the access right to data stored in the database is handled. However, the access right to resources other than data may be managed using the access ticket. Thus, according to the seventh embodiment, a device is controlled by a script included in the payload of the access ticket. 
       FIG. 23  is a view illustrating an example of a system according to the seventh embodiment. According to the seventh embodiment, a plurality of servers  810 ,  820  and the terminal apparatus  300  perform processing in cooperation with each other. 
     The server  810  is a server computer for hotel service managed by a hotel operating company. The server  810  has a hotel reservation information storage unit  811 , a reservation acceptance unit  812 , an access ticket generation unit  813 , and an access ticket execution unit  814 . 
     The hotel reservation information storage unit  811  stores reservation information about a hotel room. For example, the hotel reservation information storage unit  811  associates the identifier (user ID) of the user  32  who reserves the hotel with information such as the name of the stayed hotel, the room number of the reserved room, and stay period, as reservation information. 
     The reservation acceptance unit  812  accepts the hotel room, and stores the reservation information in the hotel reservation information storage unit  811 . Based on the hotel reservation information, the access ticket generation unit  813  generates an access ticket  61  for unlocking a door  816  of the room reserved by the user  32 . The access ticket execution unit  814  is connected to an electronic lock unit  815  of the door  816 . The electronic lock unit  815  is a device for electronically locking and unlocking the door  816 . When receiving the access ticket  61 , the access ticket execution unit  814  executes a script included in the access ticket  61 , thereby transmitting an unlocking instruction to the electronic lock unit  815 . In response to the unlocking instruction, the electronic lock unit  815  unlocks the door  816 . 
       FIG. 24  is a view illustrating an example of a script for unlocking a room door. A script  61   a  illustrated in  FIG. 24  is stored in a payload of the access ticket  61 . First two lines in the script  61   a  represent an available period of the access ticket  61 . The first line represents the use start data and time, and the second line represents the use end data and time. If a following statement falls within the available period, it is a statement that unlocks a key.
         if (now&gt;=begindate &amp;&amp; now&lt;enddate) {   WoT.discover({devid:“dev0001”}).subscribe(   thing=&gt;{thing.invokeAction(“unlock”);       

     Exacting this statement calls API that tries to find the device having the ID “dev0001”, resulting in that “thing” is obtained as an instance of the device. Then, for the instance, Action “unlock” is executed. As a result, the door  816  is unlocked. 
     Hereinafter, description is made with reference to  FIG. 23  again. 
     The server  820  is a server computer for hotel reservation proxy service managed by a company offering the hotel reservation proxy service. The server  820  has a hotel reservation management unit  821 . According to the designation of a hotel stayed by the user  32  from the terminal apparatus  300  of the user  32 , the hotel reservation management unit  821  accesses the server  810  of the hotel, and reserves a room of the hotel. The hotel reservation management unit  821  receives the access ticket  61  for unlocking a key of the reserved room from the server  810 , and transmits the access ticket  61  to the terminal apparatus  300 . 
     The terminal apparatus  300  has an access ticket storage unit  320  in addition to the access ticket management unit  310 . The access ticket storage unit  320  stores the access ticket  61 . In response to an input from the user  32 , the access ticket management unit  310  transmits a designation of the hotel to be stayed to the server  820 , and acquires the access ticket  61 . The access ticket management unit  310  stores the acquired access ticket  61  in the access ticket storage unit  320 . According to the instruction from the user  32 , the access ticket management unit  310  reads the access ticket  61  from the access ticket storage unit  320 , and transmits the access ticket  61  to the server  810 . 
     In such system, the user  32  first operates the terminal apparatus  300  to select a hotel to be stayed. Then, the access ticket management unit  310  of the terminal apparatus  300  transmits the designation of a hotel to be stayed to the server  820 . The hotel reservation management unit  821  of the server  820  transmits a reservation request to the server  810  of the designated hotel. In the server  810 , the reservation acceptance unit  812  accepts the reservation, and stores contents of the reservation in the hotel reservation information storage unit  811 . Then, the access ticket generation unit  813  generates the access ticket  61 , and transmits the access ticket  61  to the server  820 . When receiving the access ticket  61 , the hotel reservation management unit  821  transmits the access ticket  61  to the terminal apparatus  300 . In the terminal apparatus  300 , the access ticket management unit  310  stores the access ticket  61  in the access ticket storage unit  320 . This completes the reservation of the hotel room. 
     When reaching the hotel on the very day of staying, the user  32  operates the terminal apparatus  300  in front of the stayed room, and inputs an instruction to unlock the door  816 . Then, the terminal apparatus  300  transmits the access ticket  61  to the server  810 . The access ticket execution unit  814  of the server  810  executes a script  61   a  included in the access ticket  61 . If the execution data falls within an available period of the access ticket  61 , the access ticket execution unit  814  transmits an instruction to unlock the electronic lock unit  815 . As a result, the door  816  is unlocked. 
     As described above, according to the seventh embodiment, an object for controlling the device based on a device ID is acquired without acquiring data using the access ticket  61 . Then, the server  810  calls the API of the object to actually control the device. That is, the access ticket  61  according to the seventh embodiment does not indicate the access right to refer to data, but indicates a right to unlock the electronic lock unit  815 . 
     In this manner, the user  32  may unlock the door  816  using the access ticket  61  without receiving a key at a reception of the hotel. For example, if a common private house is rented to a tourist, it is difficult to offer an excellent service as offered at the hotel reception. Thus, by transmitting the access ticket  61  for unlocking the room key to the tourist in advance in the system illustrated in  FIG. 24 , the time and effort for passing of the room key may be reduced. 
     Eighth Embodiment 
     Next, an eighth embodiment is described. According to the eighth embodiment, users of the access ticket are limited. 
     According to the second to seventh embodiments, by transmitting the access ticket to a server, irrespective of transmitter, the script included in the access ticket is executed without authentication. This is advantageous in terms of convenience. However, if the access ticket is copied without any restriction, the reliability of the system is lowered. Thus, according to the eighth embodiment, the user who instructs transmission of the access ticket is authenticated to limit the users of the access ticket. 
     The user of the access ticket is managed in a server prepared as a platform. Thus, to manage the user, the user is previously registered in the server that functions as the platform. 
       FIG. 25  is a view illustrating an example of user registration processing according to the eighth embodiment. For example, a server  830  that is a source for the access ticket transmits authentication information (service ID and password) of an administrator of the server  830  and an URL identifying the server  830  on the network to a server  850  that function as the platform. The server  850  registers the information transmitted from the server  830  to an authentication information storage unit  851 . 
     A server  840  that may use the access ticket transmits authentication information (the service ID and the password) of an administrator of the server  840  and an URL identifying the server  840  on the network to the server  850 . The server  850  registers the information transmitted from the server  840  in the authentication information storage unit  851 . 
       FIG. 26  is a view illustrating the use state of the access ticket according to the eighth embodiment. As in the second embodiment, the user  32  acquires an access ticket  62  from the server  830 . At this time, the server  830  adds a service ID of a service using the access ticket to a header of the access ticket  62 . In the example illustrated in  FIG. 26 , the service ID (id 2 ) corresponding to the server  840  is added. 
     As illustrated in  FIG. 27 , the server  850  may be provided with a communication log storage unit  852 . The server  850  records communication history with other servers  830 ,  840  (information indicating communication contents) in the communication log storage unit  852 . By recording the communication history in the communication log storage unit  852 , the access ticket and how data acquired using the access ticket moves may be recognized. Recognizing the transmission/reception state of the access ticket and data facilitates investigation in case of information leakage. 
     To suppress forgery of the header, the server  830  may a signature of the server  830  to the access ticket  62 . The server  840  may include the service ID in the payload in place of the header. 
     Further, the terminal apparatus  300  rather than the server  830  may add the service ID added to the header of the access ticket  62 . In this case, the terminal apparatus  300  adds the signature to the access ticket  62 . If the terminal apparatus  300  adds the signature, for verification of correctness of the signature made by the server  830 , the terminal apparatus  300  transmits a certificate to the server  830 . The server  830  stores the certificate, and verifies the access ticket  62  transmitted from the server  850  based on the certificate. 
     The function of limiting users using the access ticket by means of the service ID as illustrated in  FIG. 26  may be implemented in the system according to any one of the second to seventh embodiments. A system capable of acquiring driving data on the rental car only in a server operated in a particular automobile insurance service provider is described below. 
       FIG. 27  is a view illustrating an example of the system having the function of limiting users of the access ticket. In the example illustrated in  FIG. 27 , the server  830  is a server computer for rental car service. The server  840  is a server computer for automobile insurance service. The server  850  is a server computer for platform service. 
     The server  830  has a database  831 , a contract management unit  832 , a driving data acquisition unit  833 , an access ticket generation unit  834 , and an access ticket execution unit  835 . The elements of the server  830  have the same functions as those in the server  100  according to the second embodiment in  FIG. 4 . The access ticket generation unit  834  further may add the service ID indicating the server that may use the access ticket  62  to the access ticket  62 . 
     The server  840  has a premium estimation unit  841 . The premium estimation unit  841  has the same function as that of the server  200  according to the second embodiment in  FIG. 4 , as well as the function of adding the service ID to the access request. That is, when requesting the access ticket  62  from the terminal apparatus  300 , the server  840  notifies the own service ID to the terminal apparatus  300 . The terminal apparatus  300  transmits the access ticket request, to which the service ID of the server  840  is added, to the server  100 . 
       FIG. 28  is a view illustrating an example of an access ticket request including the service ID. As illustrated in  FIG. 28 , the service ID (“userid”:“service2”) that is an ID of the user using the access ticket is set to the access ticket request  63 . The access ticket request  63  indicates the start date and time (“startdatetime”:“2017-05-01T12:00:00”) and the end date and time (“enddatetime”:“2017-05-01T14:00:00”) in the accessible period. 
     When receiving the access ticket request  63 , the server  830  generates the access ticket  62  having a header including information on the service ID and the accessible period in the access ticket request  63 , and transmits the access ticket  62  to the terminal apparatus  300 . 
       FIG. 29  is a view illustrating an example of the access ticket including the service ID. The service ID (“userid”:“service2”) that is an ID of the user using the access ticket is set to the access ticket  62  illustrated in  FIG. 29 . Data in the payload of the access ticket  62  is encoded. 
     Premium estimation processing using the access ticket in the system illustrated in  FIG. 27  is described below. 
       FIG. 30  is a sequence diagram illustrating an example of a procedure of the premium estimation processing using the access ticket according to the eighth embodiment. 
     The access ticket management unit  310  of the terminal apparatus  300  transmits the access ticket  62  with service ID to the server  840  for automobile insurance service (Step S 201 ). The premium estimation unit  841  of the server  840  receives the access ticket  62  (Step S 202 ). Next, the premium estimation unit  841  confirms the URL of the source for driving data based on the header of the access ticket  62  (Step S 203 ). Then, the premium estimation unit  841  transmits the authentication information and the access ticket  62  to the server  850  for platform service (Step S 204 ). For example, the premium estimation unit  841  calls the API of the server  850  for platform, and transmits the access ticket  62 . At this time, the premium estimation unit  841  designates the source for the access ticket as the URL confirmed in Step S 203 . 
     Based on the authentication information of the server  840 , a driving data proxy acquisition unit  853  of the server  850  authenticates the server  840 , and receives the access ticket  62  (Step S 205 ). The driving data proxy acquisition unit  853  transmits use service information on the service ID of the server  840  and the access ticket to the server  830  for rental car service (Step S 206 ). Then, the driving data proxy acquisition unit  853  stores information on the transferred access ticket  62  in the communication log storage unit  852  (Step S 207 ). 
     The access ticket execution unit  835  of the server  830  receives the access ticket  62  (Step S 208 ). Next, the access ticket execution unit  835  decodes encoded data in the payload (Step S 209 ). At this time, the access ticket execution unit  835  confirms whether or not the service ID indicated in the header of the access ticket  62  matches the service ID included in the use service information. Then, when the service IDs match each other, the access ticket execution unit  835  decodes encoded data in the payload of the access ticket  62 . Then, the access ticket execution unit  835  executes the script obtained by decoding (Step S 210 ). The driving data  41  may be acquired by executing the script. The access ticket execution unit  835  transmits the driving data  41  with the service ID of the server  840  to the server  850  (Step S 211 ). 
     The driving data proxy acquisition unit  853  of the server  850  receives the driving data  41  with the service ID (Step S 212 ). After that, according to the service ID added to the driving data  41  received from the server  830 , the driving data proxy acquisition unit  853  recognizes that the received data is the driving data  41  to be transmitted to the server  840 , and transmits the driving data  41  to the server  840  (Step S 213 ). Then, the driving data proxy acquisition unit  853  stores information on the transferred driving data  41  in the communication log storage unit  852  (Step S 214 ). 
     The premium estimation unit  841  of the server  840  receives the driving data  41  (Step S 215 ). The premium estimation unit  841  calculates the premium for the user  32  based on the driving data  41  (Step S 216 ). Then, the premium estimation unit  841  transmits an estimation result of the calculated premium to the terminal apparatus  300  (Step S 217 ). In the terminal apparatus  300 , the access ticket management unit  310  receives the estimation result, and displays the premium indicated in the estimation result on a monitor (Step S 218 ). 
     In this manner, using the service ID may limit servers capable of using the access ticket  62 . This may suppress illegal use of the driving data  41  that is personal information on the user  32 . 
     In the above-mentioned example, the server  850  for platform service authenticates the server  840 . However, the server  830  for rental car service may authenticate the server  840 . 
     Ninth Embodiment 
     Next, a ninth embodiment is described. According to the ninth embodiment, only an index is described in a payload, and a command itself is managed in another place. For example, a server that issues the access ticket associates a command with a command ID identifying the command, and holds them. 
       FIG. 31  is a view illustrating an example of a system according to the ninth embodiment. In the example illustrated in  FIG. 31 , a server  860  is a server computer for rental car service. A server  870  is a server computer for automobile insurance service. 
     The server  860  has a database  861 , a contract management unit  862 , a driving data acquisition unit  863 , an access ticket generation unit  864 , an access ticket execution unit  865 , and a script storage unit  866 . The database  861 , the contract management unit  862 , and the driving data acquisition unit  863  have the same functions as those in the server  100  according to the second embodiment in  FIG. 4 . 
     When receiving the access ticket request, the access ticket generation unit  864  adds a script ID to a script for acquiring the driving data  41  in the database  861 , and stores the script in the script storage unit  866 . Then, the access ticket generation unit  864  generates an access ticket  64  including the script ID in the payload. 
     When receiving the access ticket  64 , the access ticket execution unit  865  acquires a script corresponding to the script ID included in the access ticket  64  from the script storage unit  866 . Next, the access ticket execution unit  865  executes the script acquired from the script storage unit  866  to acquire the driving data  41  from the database  861 . Next, the access ticket execution unit  865  transmits the driving data  41  to the server  870  that is a source for the access ticket  64 . 
     The script storage unit  866  stores a set of the script ID and the script. 
     The server  870  for automobile insurance service has a premium estimation unit  871 . The premium estimation unit  871  has the same function as the premium estimation unit in the server  200  according to the second embodiment in  FIG. 4 . 
       FIG. 32  is a view illustrating an example of the access ticket including the script ID. Only the script ID (“0x12345678”) is set to the payload of the access ticket  64 . 
     Premium estimation processing using the access ticket in the system illustrated in  FIG. 31  is described below. 
       FIG. 33  is a sequence diagram illustrating an example of a procedure of premium estimation processing an access ticket according to a ninth embodiment. 
     The access ticket management unit  310  of the terminal apparatus  300  transmits the access ticket  64  with script ID to the server  870  for automobile insurance service (Step S 301 ). The premium estimation unit  871  of the server  870  receives the access ticket  64  (Step S 302 ). Next, based on the header of the access ticket  64 , the premium estimation unit  871  confirms an URL of a source for the driving data (Step S 303 ). Then, the premium estimation unit  871  transmits the access ticket  64  to the server  860  for rental car service (Step S 304 ). 
     The access ticket execution unit  865  of the server  860  receives the access ticket  64  (Step S 305 ). Next, the access ticket execution unit  865  acquires a script corresponding to the script ID in the payload from the script storage unit  866  (Step S 306 ). Then, the access ticket execution unit  865  executes the acquired script (Step S 307 ). The driving data  41  is acquired by executing the script. The access ticket execution unit  865  transmits the driving data  41  to the server  870  (Step S 308 ). 
     The premium estimation unit  871  of the server  870  receives the driving data  41  (Step S 309 ). Based on the driving data  41 , the premium estimation unit  871  calculates the premium for the user  32  (Step S 310 ). Then, the premium estimation unit  871  transmits an estimation result indicating the calculated premium to the terminal apparatus  300  (Step S 311 ). In the terminal apparatus  300 , the access ticket management unit  310  receives the estimation result, and displays the premium indicated in the estimation result on a monitor (Step S 312 ). 
     In this manner, the script that acquires the driving data  41  on the user  32  may be executed without being taken out of the outside of the server  860 , according to the access ticket  64  from the server  870 . Since the script is not taken out of the server  860 , contents of the script is not illegally rewritten. 
     Other Embodiments 
     The access ticket may be passed via an API prepared by the platform. A server that transmits the access ticket (for example, server for automobile insurance service) designates the service ID of a destination server (for example, server for rental car service) as an argument of the API. The server for platform acquires an URL corresponding to the service ID, and transmits the access ticket to the URL. This may illegal copy of the access ticket. 
     Such illegal used may be also suppressed by limiting the number of times the access ticket is used. For example, the server that issues the access ticket (for example, server for rental car service) adds different IDs to headers of different access tickets, and stores the available number of times for each ID. Then, when receiving the access ticket, the server confirms the added ID, and counts the number of times the access ticket for each ID is used, and if the count exceeds the available number of times, does not transmit data. 
     A server that uses the access ticket (for example, server for automobile insurance service) may transmit an encoding key together with the access ticket to a server that is a source for the access ticket (for example, server for rental car service). In this case, the source server of the access ticket encodes data acquired based on the access ticket using the encoding key, and transmits the encoded data to the server using the access ticket. The server using the access ticket decodes the received data and then, performs a service using the data. This may improve the security of personal data on the user  32 . 
     Although the embodiments have been described, each of the elements in the embodiments may be replaced with another element having the same function. Any other suitable structure or process may be added. Further, two or more configurations (features) in the above-mentioned embodiments may be combined with each other. 
     All examples and conditional language provided herein are intended for the pedagogical purposes of aiding the reader in understanding the invention and the concepts contributed by the inventor to further the art, and are not to be construed as limitations to such specifically recited examples and conditions, nor does the organization of such examples in the specification relate to a showing of the superiority and inferiority of the invention. Although one or more embodiments of the present invention have been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.