WO2018186083A1 - 情報処理装置、情報処理システム及び情報処理方法 - Google Patents

情報処理装置、情報処理システム及び情報処理方法 Download PDF

Info

Publication number
WO2018186083A1
WO2018186083A1 PCT/JP2018/008297 JP2018008297W WO2018186083A1 WO 2018186083 A1 WO2018186083 A1 WO 2018186083A1 JP 2018008297 W JP2018008297 W JP 2018008297W WO 2018186083 A1 WO2018186083 A1 WO 2018186083A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
access
information processing
unit
terminal
Prior art date
Application number
PCT/JP2018/008297
Other languages
English (en)
French (fr)
Inventor
坂本　拓也
和明 二村
松本　達郎
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to EP18781328.2A priority Critical patent/EP3608824A4/en
Publication of WO2018186083A1 publication Critical patent/WO2018186083A1/ja
Priority to US16/586,875 priority patent/US11405398B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines

Definitions

  • the present invention relates to an information processing apparatus, an information processing system, and an information processing method.
  • IoT Internet of Things
  • cloud services can be used from various devices (referred to as IoT devices).
  • services called shared economy such as car sharing and AirBnB
  • sharing of devices that allow a part or all of the functions of a shared IoT device or another person's IoT device to be used for a certain period of time has also been studied.
  • a technology for accessing the device using a Web technology called WoT has been studied.
  • a terminal accesses a device using a document that describes a device name called “Thing Description”, a function name of the device, and a method of accessing the function.
  • an object of the present invention is to provide an information processing apparatus, an information processing system, and an information processing method capable of performing device access control according to a user.
  • the information processing apparatus receives a registration of a device that can be used by a user and a function of the usable device, generates a Web API according to registration in the reception unit, and transmits the Web API to the Web API.
  • a generation unit that generates a virtual device that responds to access in cooperation with the device, and information including an access method to the Web API corresponding to the authenticated user based on a result of user authentication using a terminal
  • a notification unit that notifies the terminal; and an access unit that receives access to the Web API from the terminal and accesses the device via the virtual device.
  • FIG. 2A is a diagram illustrating a hardware configuration of the user terminal
  • FIG. 2B is a diagram illustrating a hardware configuration of the server. It is a functional block diagram of a server. It is a figure which shows an example of the data structure of access management DB.
  • FIG. 5A is a diagram illustrating an example of TD managed by the TD management DB
  • FIG. 5B is a diagram illustrating an example of TD managed by the TD repository.
  • FIG. 7A is a flowchart showing the TD registration process
  • FIG. 7B is a flowchart showing the device registration process.
  • FIG. 10A and FIG. 10B are diagrams showing a TD according to the second embodiment.
  • FIG. 11A is a diagram illustrating a TD according to the third embodiment, and
  • FIG. 11B is a diagram illustrating an example of an HTTP header portion according to the third embodiment.
  • It is a functional block diagram of a server concerning a 4th embodiment.
  • FIG. 13A is a diagram showing the data structure of the API access management DB according to the fourth embodiment, and FIG. 13B is a diagram showing the data structure of the access rule management DB.
  • c) is a diagram showing an example of a notification format. It is a figure which shows TD which concerns on the modification 3.
  • FIG. 1 schematically shows the configuration of an information processing system 100 according to the first embodiment.
  • the information processing system 100 includes a device 60, a user terminal 70, and a server 10.
  • the device 60 and the user terminal 70 are connected to a network 80 such as the Internet via a wireless LAN (Local Area Network) or a mobile phone network.
  • the server 10 is also connected to the network 80.
  • the information processing system 100 according to the first embodiment is a system for an administrator (owner or the like) who manages the device 60 to allow a user holding the user terminal 70 to use the device 60.
  • the device 60 is a device that exists in various places such as an air conditioner, an automobile, a light, and a camera, and performs some control or returns some information in response to a Web API call.
  • the user terminal 70 is a terminal that is carried by the user and used to control the device 60, and is, for example, a smartphone or a tablet-type terminal.
  • FIG. 2A shows an example of the hardware configuration of the user terminal 70.
  • a user terminal 70 includes a CPU (Central Processing Unit) 90, a ROM (Read Only Memory) 92, a RAM (Random Access Memory) 94, and a storage unit (here, HDD (Hard Disk Drive)). ) 96, a network interface 97, a display unit 93, an input unit 95, a portable storage medium drive 99, and the like.
  • Each component of the user terminal 70 is connected to a bus 98.
  • the user terminal 70 various functions are realized by the CPU 90 executing a program stored in the ROM 92 or the HDD 96 or a program read by the portable storage medium drive 99 from the portable storage medium 91.
  • the user terminal 70 includes a terminal that can be used by an administrator who manages the device 60 (an administrator terminal 70 ′ (see FIG. 3)).
  • the server 10 mediates communication between the user terminal 70 and the device 60, and executes access control to the device 60 from the user terminal 70.
  • FIG. 2B shows an example of the hardware configuration of the server 10.
  • the server 10 includes a CPU (Central Processing Unit) 190, a ROM (Read Only Memory) 192, a RAM (Random Access Memory) 194, and a storage unit (here, HDD (Hard Disk Drive)). 196, a network interface 197, a portable storage medium drive 199, and the like.
  • Each component of the server 10 is connected to the bus 198.
  • the CPU 190 executes a program stored in the ROM 192 or the HDD 196 or a program read from the portable storage medium 191 by the portable storage medium drive 199, thereby functioning as each unit illustrated in FIG. 3.
  • FIG. 3 also shows various DBs stored in the HDD 196 and the like.
  • the CPU 190 functions as the service unit 12 and the control unit 14 by executing the program.
  • the service unit 12 is prepared for each service, and includes a use request receiving unit 20 and an access control unit 22.
  • the control unit 14 is a platform, and includes a virtual device control unit 40, a Web API control unit 42, a TD control unit 44, and a virtual device function unit 46.
  • TD Thing Description
  • the device registers its own TD in the server 10 (TD repository 54), and the terminal is one of the information held by the TD.
  • TD repository 54 There is a method of acquiring the TD by searching for a part (for example, device name or ID) as a key. In this embodiment, this method is applied.
  • the device administrator registers the URL of the virtual device control unit 40 of the server 10 instead of registering the URL of the TD repository 54 of the server 10 in the device.
  • the TD of the device is sent to the virtual device control unit 40, and the TD can be managed by the TD management DB 52.
  • the device administrator decides under what conditions the device should be rented and contracts with the service provider. For example, if a car is rented, a contract is made such that it is rented at 200 yen per hour on weekdays and 300 yen per hour on holidays. And a service provider will lend a car to various users according to the conditions.
  • the contract information between the user and the administrator is managed in the service unit 12 in association with the device ID and the user ID.
  • the use request receiving unit 20 receives the contract information when a device use procedure (use contract) using the service application is performed from the user terminal 70 where the service application managed by the application management DB 30 is downloaded. Register in the access management DB 32.
  • the user uses the service application on the user terminal 70 to access the service. Then, after performing user authentication, the plan (available device 60 and function information of the device 60 registered in the access management DB 32) provided from the use request receiving unit 20 is confirmed, and as a result, A reservation (contract) is made such that a certain device 60 is rented from a certain time to a certain time.
  • the flow related to this contract is the same as that for normal online shopping and hotel reservation online services. With this contract, in the access management DB 32, the device 60 registered by the device administrator is associated with the contracted user.
  • the access management DB 32 is a database that manages information registered from the administrator terminal 70 ′ (contract information with the service provider) and usage requests (contents of usage contracts) acquired from the user terminal 70. . Specifically, as shown in FIG. 4, each field includes “device ID”, “function”, “user ID”, “start”, and “end”.
  • identification information of a device for example, lighting
  • the function of the device that has been contracted for use on / off of lighting in FIG. 4
  • the user ID identification information of a contracted user is stored.
  • start and end the use start date and time and use end date and time of the device are stored.
  • the illumination function “onoff” with the device ID “0123-4567-89ab-cdef” the user with the user ID “00000001” changes from “2016/10/29 10:00” to “2016/10 / The content that the contract to use until "29 11:00" has been concluded is stored.
  • the access control unit 22 stores information registered from the administrator terminal 70 ′ in the access management DB 32. Further, the access control unit 22 refers to the user management DB 50 and the access management DB 32 and causes the Web API control unit 42 to generate a virtual device Web API and causes the TD control unit 44 to generate a virtual device TD. Furthermore, when a TD is requested from the user terminal 70, the access control unit 22 issues an instruction to the TD control unit 44 and causes the user terminal 70 to transmit a TD corresponding to the user.
  • the user management DB 50 is a database that stores combinations of user IDs and passwords.
  • the virtual device control unit 40 When the virtual device control unit 40 receives a TD (Thing Description) of the device 60 from the device 60, the virtual device control unit 40 stores the received TD in the TD management DB 52 and, based on the received TD, adds a virtual device to the virtual device function unit 46.
  • Virtual device function unit 46 functions as a virtual device).
  • the virtual device function unit 46 functions as a virtual device under the instruction of the virtual device control unit 40.
  • the Web API control unit 42 generates a Web API of the virtual device based on the access management DB 32 and the TD, and gives it to the virtual device.
  • the TD control unit 44 generates a TD of the virtual device based on the access management DB 32 and the TD and registers it in the TD repository 54.
  • the TD control unit 44 appropriately monitors the TD repository 54 to update the TD or delete unnecessary TDs.
  • the TD stored in the TD management DB 52 is, for example, as shown in FIG.
  • the TD control unit 44 Based on the TD information and the information in the access management DB 32 (see FIG. 4), the TD control unit 44 generates a TD for the virtual device.
  • the TD of FIG. 5A provides two functions “rgbw” and “onoff”.
  • the TD of the virtual device has only the “onoff” function as shown in FIG. This is because in the contract stored in the access management DB 32, only the contract using “onoff” is made.
  • “uris” indicates a part of the URL for accessing the device or the virtual device.
  • the “onoff” function information can be accessed by combining the “hrefs” information and the URL included in the description of the “onoff” function information.
  • the function “onoff” can be called by accessing the URL “http://192.168.0.101/LED/onoff” from FIG.
  • the function “onoff” can be called by accessing the URL “http://192.168.0.1/0123456789abcdef/00000001/xxxxxxxx/onoff” from FIG. 5B. it can.
  • the WebAPI can be used for both obtaining the state and changing the state.
  • http-get is used to obtain the onoff value
  • http-post is used to change the onoff value.
  • http-get by returning a value such as ⁇ “value”: true ⁇ as a return value, it is possible to grasp that the current state is true (currently turned on) or http-post
  • the uris of the virtual device must be an address that can be handled by the virtual device and must be unique within the virtual device. That is, it must not have the same uris as TDs for multiple devices.
  • the TD control unit 44 registers data as shown in FIG. 6 in which the TD of FIG. 5B is associated with the user ID in the TD repository 54.
  • the processing for the TD repository 54 is repeatedly executed periodically or irregularly. In the above contract, only 10/29 10: 00-11: 00 was valid, so if the date is out of this range, the TD is not registered, and if it is registered, it is deleted.
  • the user can use the device 60 at the contract date and time.
  • user authentication is performed through the user terminal 70.
  • the access control unit 22 refers to the user management DB 50 and performs user authentication similar to a normal Internet service.
  • the access control unit 22 issues an instruction to the TD control unit 44 and transmits a TD corresponding to the user from the TD repository 54 to the user terminal 70.
  • the user terminal 70 can acquire TD about the function of the device which a user can utilize.
  • the user terminal 70 parses the acquired TD, calculates a URL corresponding to the function, and accesses the virtual device (WebAPI call) using the calculated URL.
  • the virtual device function unit 46 receives the Web API access and calculates which function of which device is called from the TD repository 54 based on the received URL.
  • the TD of the device can be found from the TD management DB 52 based on the device ID, and the access method to the same function of the device can be found from the function name.
  • the virtual device function unit 46 accesses the device (WebAPI call). The device performs processing upon receiving a WebAPI call. For example, if the device is illuminated, processing such as turning on a light is performed.
  • the device returns a response to the virtual device function unit 46 when the execution of the process is completed.
  • the virtual device function unit 46 receives the response from the device and transfers the response to the user terminal 70.
  • the device 60 can be controlled from the user terminal 70.
  • the server 10 calculates the access method to the device from the TD repository 54 or the TD management DB 52. Fails and device access fails. Therefore, in this embodiment, only an access to a contracted device from an appropriate user is possible.
  • FIG. 7A shows a flowchart of the TD registration process.
  • the TD registration process is a process executed by the device 60 and the server 10. First, in the device 60, when the administrator registers the URL of the virtual device control unit 40 of the server 10, URL setting processing is executed in step S10. Next, the device 60 transmits a TD to the URL set by the administrator in step S12.
  • the virtual device control unit 40 of the server 10 stands by until receiving TD in step S20.
  • the virtual device control unit 40 proceeds to Step S22 and stores the TD in the TD management DB 52.
  • FIG. 7B shows a flowchart of the device registration process.
  • the device registration process is a process executed by the administrator terminal 70 ′ and the server 10.
  • the administrator terminal 70 ′ executes device registration processing in step S30.
  • the administrator terminal 70 ′ transmits the input device information to the server 10.
  • a plan registration process is executed in step S32. In this case, the administrator terminal 70 ′ transmits the input information to the server 10 in order to input under what conditions the loan is lent.
  • the access control unit 22 receives the registration information and waits until the plan information is received (S40, S42). Therefore, upon receiving these pieces of information, the access control unit 22 proceeds to step S44 and stores the plan information in the access management DB 32.
  • FIG. 8 shows a flowchart of the user registration process.
  • the process of FIG. 8 is a process executed for a user to make a contract for using (borrowing) a device.
  • the user terminal 70 transmits an application download request to the server 10 (usage request receiving unit 20) in accordance with a user operation.
  • the server 10 side since the use request receiving unit 20 is waiting until a download request is transmitted (S60), the process proceeds to step S62 when there is a request, and the application (service application) ) From the application management DB 30 and transmitted to the user terminal 70.
  • the user terminal 70 installs the application in step S52.
  • the user terminal 70 transmits a user authentication request to the use request receiving unit 20 of the server 10 in accordance with the user operation in step S54. Since the use request receiving unit 20 stands by until a user authentication request is made in step S64, if there is a user authentication request, the process proceeds to step S66, and user authentication is executed based on the user management DB 50. If the user authentication is successful, the application on the user terminal 70 displays a selectable plan based on the data stored in the access management DB 32.
  • the user terminal 70 transmits plan selection information to the use request receiving unit 20 of the server 10 in step S56.
  • the use request receiving unit 20 waits until receiving the plan selection information in step S68, and therefore the process proceeds to step S70 when the plan selection information is received.
  • step S70 the use request receiving unit 20 stores the plan selection information in the access management DB 32. That is, any plan is associated with the user ID of the user.
  • step S72 based on the plan selected by the user, the virtual device control unit 40 generates a virtual device (functions the virtual device function unit 46).
  • the WebAPI control unit 42 generates a virtual API WebAPI
  • the TD control unit 44 generates a virtual device TD.
  • FIG. 9 shows a flowchart of device access control processing.
  • the device access control process is a process executed by the user terminal 70, the server 10, and the device 60. This process is a process when the user uses the device 60 by using the user terminal 70.
  • step S110 a user authentication request using a user ID or password is made from the user terminal 70.
  • step S130 since the access control unit 22 of the server 10 is on standby until user authentication is performed (S130), when there is a user authentication request, the process proceeds to step S132.
  • step S132 the access control unit 22 refers to the user management DB 50 and performs user authentication.
  • step S112 a search request for TD is issued from the application of the user terminal 70.
  • the access control unit 22 stands by until a TD search request is made (S134). If there is a TD search request, the process proceeds to step S136.
  • step S ⁇ b> 136 the access control unit 22 issues an instruction to the TD control unit 44, searches the TD repository 54 for the TD corresponding to the authenticated user, and transmits the TD to the user terminal 70.
  • step S114 Since the user terminal 70 is on standby until the TD is transmitted in step S114, when the TD is transmitted, the process proceeds to step S116 and receives the TD.
  • step S118 the user terminal 70 selects which function (which TD) to use according to the user's operation, and in the next step S120, the TD is parsed to correspond to the function.
  • URL is calculated.
  • step S122 the user terminal 70 accesses the virtual device using the calculated URL (performs a Web API call).
  • step S140 the virtual device function unit 46 (virtual device) calculates which function of which device is called from the TD repository 54 based on the received URL.
  • step S142 the virtual device function unit 46 (virtual device) accesses the device (WebAPI call) based on the calculated information.
  • processing is executed in response to the WebAPI in step S150.
  • the device 60 returns a response to the virtual device function unit 46 in step S152.
  • the virtual device function unit 46 receives the response from the device 60 in step S144, transfers the response to the user terminal 70, and the user terminal 70 receives the response in step S124.
  • the use request receiving unit 20 receives registration of a device that can be used by the user and the function of the available device, stores the registration in the access management DB 32, and Web API
  • the control unit 42 generates a Web API according to the registration, and the virtual device control unit 40 causes the virtual device function unit 46 to function as a virtual device that responds to the access to the Web API in cooperation with the device.
  • the TD control unit 44 transmits a TD including an access method to the Web API corresponding to the authenticated user to the user terminal 70, and the virtual device function unit 46
  • the access to the Web API (Web API call) from the user terminal 70 is accepted and the device is accessed.
  • the first embodiment it is possible to perform device access control in accordance with the user without adding a function to the device side.
  • the function related to access control does not press the resource of the device.
  • the user can access a device for which a usage contract has been made in the same manner as for accessing a normal device.
  • the user terminal 70 accesses the virtual device using a temporary URL calculated from the TD, security can be improved.
  • FIG. 10A is an example in which an item “price” is added as information that did not exist in the TD of the first embodiment
  • FIG. 10B is an example in which an item “contractURL” is added. It is.
  • TD information indicating that the Web API for color change (rgbw) is not currently available (“enabled”: false), but can be used if an additional cost is paid. That is, the user terminal 70 can parse the TD and acquire this information to indicate that the user can use the color changing function by paying an additional cost.
  • a URL for accessing the Web page for the additional contract is added as a contractURL.
  • the access control unit 22 instructs the TD control unit 44 to update the TD stored in the TD repository 54.
  • the operation when a WebAPI call is received by the virtual device function unit 46 (virtual device) is also changed.
  • the TD since the TD includes information necessary for updating the function of the device available to the user, the user can It is possible to add the functions of available devices as appropriate.
  • the third embodiment is different from the first embodiment in that information difficult to guess is added to the URL of the Web API calculated from the TD registered in the TD repository 54.
  • a character string as key information is generated using a pseudo random number and the URL specified in the TD uris part registered in the TD repository 54 is used. Add the generated string (token) to.
  • the uris of the virtual device must be an address that can be handled by the virtual device and must be unique within the virtual device. If this is observed, the character string can be freely set. I can decide. For this reason, by complicating the character string, it is possible to reduce the possibility that a person who does not have the right originally has unauthorized access by predicting the character string.
  • a character string may be added to the HTTP header as shown in FIG. 11B.
  • a character string may be added to the body part of HTTP. Note that the character string may be included in the TD and passed to the user terminal 70 or may be passed to the user terminal 70 via another route.
  • the virtual device function unit 46 (virtual device) receives a WebAPI call from the user terminal 70, the virtual device function unit 46 confirms the token and then performs device access control.
  • the TD includes address information for accessing the Web API and a character string as key information. The possibility of access can be reduced.
  • the server 10 checks access to the virtual device in order to prevent unauthorized access to the device 60.
  • FIG. 12 shows a functional block diagram of the server 10 ′ according to the fourth embodiment.
  • the control unit 14 includes a Web API monitoring unit 64 and an API access management DB 62 and an access rule management DB 66. Further, the service unit 12 has a monitoring notification unit 24.
  • the Web API monitoring unit 64 may have made unauthorized access based on the access information from the user terminal 70 stored in the API access management DB 62 to the virtual device and the access rules stored in the access rule management DB 66. Determine if there is. When the Web API monitoring unit 64 determines that there is a possibility of unauthorized access, the Web API monitoring unit 64 notifies the monitoring notification unit 24 to that effect. When notified from the WebAPI monitoring unit 64, the monitoring notification unit 24 notifies the notification destination URL (for example, the user terminal 70) that there is a possibility of unauthorized access.
  • the notification destination URL for example, the user terminal 70
  • the API access management DB 62 has a data structure as shown in FIG. As shown in FIG. 13A, the API access management DB 62 has fields of “URL”, “device ID”, “access source IP address”, and “access date / time”.
  • the URL accessed from the user terminal 70 is stored in the “URL” field.
  • the “device ID” field virtual device identification information is stored.
  • the “access source IP address” field stores the IP address of the user terminal 70.
  • the “access date / time” field the date / time when the user terminal 70 accessed is stored.
  • the access rule management DB 66 has a data structure as shown in FIG. As shown in FIG. 13B, the access rule management DB 66 has fields of “device ID”, “notification destination URL”, and “rule ID”. In the “device ID” field, identification information of the accessed virtual device is stored, and in the “notification destination URL” field, a URL indicating the notification destination is stored. The “rule ID” field stores rule identification information for determining whether or not there is a possibility of unauthorized access.
  • the virtual device When the virtual device receives access from the user terminal 70, the virtual device identifies the device ID from the TD repository 54 based on the received URL, and performs API access to the current date and time and the IP address of the user terminal 70 that is the access source. Store in the management DB 62.
  • the Web API monitoring unit 64 receives the addition of information to the API access management DB 62 and refers to the access rule management DB 66 to verify whether the rule is met (access is valid) or not.
  • the WebAPI monitoring unit 64 checks the IP address of the access source and determines whether it has changed from the previous access. . If the IP address of the access source has changed, the monitoring notification unit 24 notifies the notification destination URL and confirms whether or not access is permitted.
  • the rule is that “when there is an access more than a predetermined number of times (for example, two times) within a predetermined time (for example, within one second)” or “there is an access from a different access source IP address within a predetermined time (for within ten seconds). If so, the Web API monitoring unit 64 determines whether or not such access has occurred. And when there is such access, the monitoring notification unit 24 notifies the notification destination URL.
  • notification formats can be adopted, for example, notification as shown in FIG. 13C can be performed.
  • the server 10 includes the Web API monitoring unit 64 that monitors access to the Web API, and the monitoring notification unit 24 that performs notification based on the monitoring result of the Web API monitoring unit 64. It is equipped with. Thereby, when the WebAPI monitoring unit 64 determines that there is a possibility of unauthorized access, the monitoring notification unit 24 can notify the user or the like to that effect.
  • the fifth embodiment is different from the first embodiment in that the virtual device has a cache function.
  • http-get is used when acquiring the current value of onoff of the device 60
  • http-post is used when changing.
  • the virtual device accesses the device 60 to acquire the value and returns the value to the user terminal 70.
  • Store as a cache When the same value is requested again by http-get, the stored value is returned to the user terminal 70 without accessing the device.
  • the stored value is deleted when a predetermined time has elapsed after storage. Or, once http-post is called, the stored value is deleted. Thereby, inconsistency between the actual state and the cache can be reduced.
  • the virtual device may have a function of temporarily storing Web API access when offline as a cache function. That is, when a virtual device receives a WebAPI call and accesses the corresponding device but cannot access it, the WebAPI access is temporarily stored, and after a predetermined time has elapsed, the stored WebAPI is used again. Access the device.
  • the virtual device can access the device again, so that the device can execute the request.
  • Modification 1 when the device 60 is turned off / on, or when the device 60 is moved, the IP address may be changed, and access may not be possible with the conventional access methods.
  • the server 10 may acquire the TD from the device 60 again. For example, when the device 60 detects that the connection destination network has changed, the device 60 may perform TD registration again.
  • the TD in the TD repository 54 is updated when the period of use contract is entered, when the use contract is terminated, or when the contract content is changed. It has become. However, since the user terminal 70 may have already acquired the TD, the user terminal 70 may try to access the virtual device using the original TD.
  • the server 10 may notify the user terminal 70 to prompt the user to reacquire the TD.
  • a function for receiving an event notification may be implemented in the service application so that the server 10 notifies the service application of an event for reacquiring the TD.
  • the contract period may be described in advance in the TD, and the user terminal 70 may reacquire the TD based on the information.
  • the contract period may be added to the TD.
  • the start date of the contract period is registered as “begindate”
  • the end date of the contract period is registered as “enddate”.
  • the user terminal 70 may acquire the TD before starting the contract.
  • access control may be performed based on begindate. For example, if the current date and time is before begindate, even if the corresponding Web API is called, the virtual device should not access the device corresponding to the Web API call.
  • the above processing functions can be realized by a computer.
  • a program describing the processing contents of the functions that the processing apparatus should have is provided.
  • the program describing the processing contents can be recorded on a computer-readable recording medium (except for a carrier wave).
  • the program When the program is distributed, for example, it is sold in the form of a portable recording medium such as a DVD (Digital Versatile Disc) or CD-ROM (Compact Disc Read Only Memory) on which the program is recorded. It is also possible to store the program in a storage device of a server computer and transfer the program from the server computer to another computer via a network.
  • a portable recording medium such as a DVD (Digital Versatile Disc) or CD-ROM (Compact Disc Read Only Memory) on which the program is recorded. It is also possible to store the program in a storage device of a server computer and transfer the program from the server computer to another computer via a network.
  • the computer that executes the program stores, for example, the program recorded on the portable recording medium or the program transferred from the server computer in its own storage device. Then, the computer reads the program from its own storage device and executes processing according to the program. The computer can also read the program directly from the portable recording medium and execute processing according to the program. Further, each time the program is transferred from the server computer, the computer can sequentially execute processing according to the received program.
  • a reception unit that receives registration of a device that can be used by a user and a function of the device that can be used;
  • a generation unit that generates a Web API in response to registration in the reception unit and generates a virtual device that responds to the access to the Web API in cooperation with the device;
  • a notification unit for notifying the terminal of information including an access method to the Web API corresponding to the authenticated user, based on a result of user authentication using the terminal;
  • An information processing apparatus comprising: an access unit that accepts access to the Web API from the terminal and accesses the device via the virtual device.
  • (Supplementary note 2) The information processing apparatus according to supplementary note 1, wherein the information notified by the notification unit includes information necessary for updating a function of a device that can be used by a user.
  • (Supplementary note 3) The information processing apparatus according to supplementary note 1 or 2, wherein the information notified by the notification unit includes address information for accessing the Web API and key information.
  • (Supplementary Note 4) a monitoring unit that monitors access to the Web API;
  • the information processing apparatus includes: A receiving unit that receives registration of a device usable by the user and a function of the available device from the terminal; A generation unit that generates a Web API in response to registration in the reception unit and generates a virtual device that responds to the access to the Web API in cooperation with the device; A notification unit for notifying the terminal of information including an access method to the Web API corresponding to the authenticated user, based on a result of user authentication using the terminal; An access unit that accepts access to the WebAPI from the terminal and accesses the device via the virtual device; An information processing system characterized by this.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Automation & Control Theory (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)

Abstract

【課題】ユーザに応じたデバイスのアクセス制御を行う。 【解決手段】利用要求受信部２０が、ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付けてアクセス管理ＤＢ３２に格納し、ＷｅｂＡＰＩ制御部４２は、登録に応じてＷｅｂＡＰＩを生成し、仮想デバイス制御部４０は、仮想デバイス機能部４６をＷｅｂＡＰＩへのアクセスに対してデバイスと連携して応答する仮想デバイスとして機能させる。そして、ＴＤ制御部４４は、ユーザ端末７０を利用したユーザ認証の結果に基づいて、認証したユーザに対応するＷｅｂＡＰＩへのアクセス方法を含むＴＤをユーザ端末７０に送信し、仮想デバイス機能部４６は、ユーザ端末７０からのＷｅｂＡＰＩへのアクセス（ＷｅｂＡＰＩ呼び出し）を受け付け、デバイスにアクセスする。

Description

情報処理装置、情報処理システム及び情報処理方法
　本発明は、情報処理装置、情報処理システム及び情報処理方法に関する。
　近年、ＩｏＴ（Internet of Things）の進展により、様々なデバイスがインターネットなどのネットワークに接続され、様々なデバイス（ＩｏＴデバイスと呼ぶ）からクラウドサービスを利用できるようになってきている。一方、様々なものを共有したり、貸し借りする、シェアードエコノミーと呼ばれるサービス（カーシェアリングやＡｉｒＢｎＢなど）も拡大しつつある。これらのことから、共有のＩｏＴデバイスや他人のＩｏＴデバイスが持つ一部又は全部の機能を一定時間だけ利用できるようにするデバイスのシェアリングも検討されてきている。
　最近では、ＩｏＴデバイスをネットワーク経由で操作したり、ＩｏＴデバイスから情報を取得する仕組みの一つとして、ＷｏＴ（Web of Things）と呼ばれるＷｅｂ技術を使ってデバイスにアクセスする技術が検討されている。この技術では、端末は、Thing Descriptionと呼ばれるデバイス名やデバイスが持つ機能名とその機能へのアクセス方法などを記述する文書を用いてデバイスにアクセスする。
　なお、デバイスのアクセス制御に関する技術として、端末でデバイスにタッチすることで接続し、認証、鍵交換を行い、その鍵を利用してデバイスへのアクセスを実現する技術が知られている（例えば、特許文献１等参照）。
特表２０１５－５３００３８号公報
　デバイスをシェアリングする場合、ユーザによって利用可能なデバイスや利用可能なデバイスの機能が異なる。したがって、ユーザに応じたアクセス制御を行うことが必要である。
　１つの側面では、本発明は、ユーザに応じたデバイスのアクセス制御を行うことが可能な情報処理装置、情報処理システム及び情報処理方法を提供することを目的とする。
　一つの態様では、情報処理装置は、ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付ける受付部と、前記受付部への登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成する生成部と、端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知する通知部と、前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスするアクセス部と、を備えている。
　ユーザに応じたデバイスのアクセス制御を行うことができる。
一実施形態に係る情報処理システムの構成を概略的に示す図である。 図２（ａ）は、ユーザ端末のハードウェア構成を示す図であり、図２（ｂ）は、サーバのハードウェア構成を示す図である。 サーバの機能ブロック図である。 アクセス管理ＤＢのデータ構造の一例を示す図である。 図５（ａ）は、ＴＤ管理ＤＢで管理されるＴＤの一例を示す図であり、図５（ｂ）は、ＴＤレポジトリで管理されるＴＤの一例を示す図である。 ＴＤレポジトリに格納されるデータの一例を示す図である。 図７（ａ）は、ＴＤ登録処理を示すフローチャートであり、図７（ｂ）は、デバイス登録処理を示すフローチャートである。 ユーザ登録処理を示すフローチャートである。 デバイスのアクセス制御処理を示すフローチャートである。 図１０（ａ）、図１０（ｂ）は、第２の実施形態に係るＴＤを示す図である。 図１１（ａ）は、第３の実施形態に係るＴＤを示す図であり、図１１（ｂ）は、第３の実施形態に係るＨＴＴＰヘッダ部の例を示す図である。 第４の実施形態に係るサーバの機能ブロック図である。 図１３（ａ）は、第４の実施形態に係るＡＰＩアクセス管理ＤＢのデータ構造を示す図であり、図１３（ｂ）は、アクセスルール管理ＤＢのデータ構造を示す図であり、図１３（ｃ）は、通知フォーマットの例を示す図である。 変形例３に係るＴＤを示す図である。
≪第１の実施形態≫
　以下、情報処理システムの第１の実施形態について、図１～図９に基づいて詳細に説明する。
　図１には、第１の実施形態に係る情報処理システム１００の構成が概略的に示されている。情報処理システム１００は、デバイス６０と、ユーザ端末７０と、サーバ１０と、を備える。デバイス６０及びユーザ端末７０は、無線ＬＡＮ（Local Area Network）や携帯電話網などを介して、インターネットなどのネットワーク８０に接続されている。また、サーバ１０もネットワーク８０に接続されている。本第１の実施形態の情報処理システム１００は、デバイス６０を管理する管理者（持ち主等）が、ユーザ端末７０を保持するユーザにデバイス６０を利用させるためのシステムである。
　デバイス６０は、エアコン、自動車、照明、カメラなど、様々な場所に存在する機器であり、ＷｅｂＡＰＩの呼び出しを受けて、何らかの制御を行ったり、何らかの情報を返答したりするものである。
　ユーザ端末７０は、ユーザが持ち歩き、デバイス６０を制御するために利用する端末であり、例えばスマートフォンやタブレット型端末であるものとする。図２（ａ）には、ユーザ端末７０のハードウェア構成の一例が示されている。図２（ａ）に示すように、ユーザ端末７０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、表示部９３、入力部９５、及び可搬型記憶媒体用ドライブ９９等を備えている。これらユーザ端末７０の構成各部は、バス９８に接続されている。ユーザ端末７０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラムをＣＰＵ９０が実行することにより、各種機能を実現する。なお、ユーザ端末７０には、デバイス６０を管理する管理者が利用可能な端末（管理者端末７０’（図３参照））も含まれるものとする。
　サーバ１０は、ユーザ端末７０とデバイス６０の間の通信を仲介し、ユーザ端末７０からのデバイス６０に対するアクセス制御を実行する。図２（ｂ）には、サーバ１０のハードウェア構成の一例が示されている。図２（ｂ）に示すように、サーバ１０は、ＣＰＵ（Central Processing Unit）１９０、ＲＯＭ（Read Only Memory）１９２、ＲＡＭ（Random Access Memory）１９４、記憶部（ここではＨＤＤ（Hard Disk Drive））１９６、ネットワークインタフェース１９７、及び可搬型記憶媒体用ドライブ１９９等を備えている。これらサーバ１０の構成各部は、バス１９８に接続されている。サーバ１０では、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ１９９が可搬型記憶媒体１９１から読み取ったプログラムをＣＰＵ１９０が実行することにより、図３に示す各部として機能する。なお、図３には、ＨＤＤ１９６等に格納されている各種ＤＢ等も図示されている。
　次に、図３に基づいて、サーバ１０の各部について具体的に説明する。サーバ１０においては、ＣＰＵ１９０がプログラムを実行することで、サービス部１２と、制御部１４として機能する。
　図３において、サービス部１２は、サービス毎に用意されており、利用要求受信部２０と、アクセス制御部２２と、を有する。また、制御部１４は、プラットフォームであり、仮想デバイス制御部４０と、ＷｅｂＡＰＩ制御部４２と、ＴＤ制御部４４と、仮想デバイス機能部４６と、を有する。
　ここで、Ｗ３Ｃで議論中のＷｏＴでは、端末がデバイスにアクセスする際に、ＴＤ（Thing Description）と呼ばれる情報をもとにアクセスする。端末がＴＤを取得する仕組みについてはさまざまな方法が検討されているが、その一つとして、デバイスが自身のＴＤをサーバ１０（ＴＤレポジトリ５４）に登録し、端末はそのＴＤが持つ情報の一部（例えばデバイスの名前やＩＤ)をキーとして検索することで、そのＴＤを取得する方法がある。本実施形態ではこの方法を応用するものとする。
　具体的には、本実施形態では、デバイスの管理者はデバイスにサーバ１０が有するＴＤレポジトリ５４のＵＲＬを登録する代わりに、サーバ１０の仮想デバイス制御部４０のＵＲＬを登録する。これにより、仮想デバイス制御部４０にデバイスのＴＤが送られ、ＴＤをＴＤ管理ＤＢ５２で管理することが可能になる。
　また、デバイスの管理者は、デバイスをどのような条件で貸し出すのかを取り決めてサービス事業者と契約する。たとえば、車を貸し出すのであれば、平日は１時間２００円、休日は１時間３００円で貸し出すといった契約を行う。そして、サービス事業者はその条件に応じてさまざまなユーザに車を貸し出すことになる。ユーザと管理者間における契約情報は、デバイスＩＤやユーザＩＤと対応付けてサービス部１２において管理される。
　利用要求受信部２０は、アプリ管理ＤＢ３０で管理されているサービスアプリがダウンロードされているユーザ端末７０から、サービスアプリを用いたデバイスの利用手続き（利用契約）が行われた場合に、契約情報をアクセス管理ＤＢ３２に登録する。
　より具体的には、ユーザはユーザ端末７０においてサービスアプリを利用し、サービスにアクセスする。そして、ユーザ認証を行った上で、利用要求受信部２０から提供されるプラン（アクセス管理ＤＢ３２に登録されている利用可能なデバイス６０及びデバイス６０の機能の情報）を確認して、その結果として、ある時間からある時間まであるデバイス６０を借りるといった予約（契約）を行う。この契約に関する流れは、通常のネットショッピングやホテル予約のネットサービスなどと同様である。この契約により、アクセス管理ＤＢ３２において、デバイスの管理者が登録したデバイス６０と契約したユーザとが対応付けられる。
　ここで、アクセス管理ＤＢ３２は、管理者端末７０’から登録された情報（サービス事業者との契約情報）と、ユーザ端末７０から取得した利用要求（利用契約の内容）とを管理するデータベースである。具体的には、図４に示すように、「デバイスＩＤ」、「機能」、「ユーザＩＤ」、「開始」、「終了」の各フィールドを有する。
　「デバイスＩＤ」のフィールドには、デバイス（例えば照明とする）の識別情報が格納される。「機能」のフィールドには、利用契約されたデバイスの機能（図４では照明のon／off）が格納される。「ユーザＩＤ」のフィールドには、契約したユーザの識別情報が格納される。「開始」及び「終了」のフィールドには、デバイスの利用開始日時及び利用終了日時が格納される。図４の例では、デバイスＩＤ「0123-4567-89ab-cdef」の照明の機能「onoff」について、ユーザＩＤ「00000001」のユーザが「2016/10/29 10:00」から「2016/10/29 11:00」まで利用する契約が結ばれたという内容が格納されている。
　アクセス制御部２２は、アクセス管理ＤＢ３２に管理者端末７０’から登録された情報を格納する。また、アクセス制御部２２は、ユーザ管理ＤＢ５０やアクセス管理ＤＢ３２を参照して、ＷｅｂＡＰＩ制御部４２に仮想デバイスのＷｅｂＡＰＩを生成させたり、ＴＤ制御部４４に仮想デバイスのＴＤを生成させたりする。更に、アクセス制御部２２は、ユーザ端末７０からＴＤが要求された場合に、ＴＤ制御部４４に指示を出し、ユーザに対応するＴＤをユーザ端末７０に送信させる。
　なお、ユーザ管理ＤＢ５０は、ユーザＩＤとパスワードの組み合わせ等を格納するデータベースである。
　仮想デバイス制御部４０は、デバイス６０からデバイス６０のＴＤ（Thing Description）を受け付けると、受け付けたＴＤをＴＤ管理ＤＢ５２に格納するとともに、受け付けたＴＤに基づいて、仮想デバイス機能部４６に仮想デバイスを生成する（仮想デバイス機能部４６を仮想デバイスとして機能させる）。仮想デバイス機能部４６は、仮想デバイス制御部４０の指示の下、仮想デバイスとして機能する。また、ＷｅｂＡＰＩ制御部４２は、アクセス管理ＤＢ３２とＴＤに基づいて仮想デバイスのＷｅｂＡＰＩを生成し、仮想デバイスに与える。ＴＤ制御部４４は、アクセス管理ＤＢ３２とＴＤに基づいて仮想デバイスのＴＤを生成し、ＴＤレポジトリ５４に登録する。なお、ＴＤ制御部４４は、ＴＤレポジトリ５４を適宜監視し、ＴＤを更新したり、不要なＴＤを削除したりする。
　ここで、ＴＤ管理ＤＢ５２に格納されるＴＤは、一例として図５（ａ）に示すようなものである。このＴＤの情報とアクセス管理ＤＢ３２（図４参照）の情報とに基づいて、ＴＤ制御部４４は、仮想デバイス用のＴＤを生成する。具体的には、図５（ａ）のＴＤでは「rgbw」と「onoff」の２つの機能が提供されている。一方、仮想デバイスのＴＤは、図５（ｂ）に示すように、「onoff」の機能しか存在しない。これは、アクセス管理ＤＢ３２に格納されている契約では「onoff」を利用する契約のみが結ばれているからである。なお、図５（ａ）、図５（ｂ）において、「uris」はデバイス又は仮想デバイスにアクセスするためのＵＲＬの一部を示している。「onoff」の機能にアクセスする場合には、「onoff」の機能の情報が記述しているところに含まれている「hrefs」の情報とＵＲＬとを組み合わせることでアクセスできる。例えば、アクセス先がデバイスの場合は、図５（ａ）より、ＵＲＬ「http://192.168.0.101/LED/onoff」にアクセスすることで「onoff」の機能を呼び出すことができる。一方、アクセス先が仮想デバイスの場合は、図５（ｂ）より、ＵＲＬ「http://192.168.0.1/0123456789abcdef/00000001/xxxxxxxx/onoff」にアクセスすることで「onoff」の機能を呼び出すことができる。また、http-getとhttp-postを使い分けることで、ＷｅｂＡＰＩを、状態を取得することと状態を変更することの両方に使用することができる。すなわち、onoffの値を取得するためにはhttp-getを使い、onoffの値を変更するためにはhttp-postを使う。たとえば、http-getのときには戻り値として、{“value”:true} のような値を返すことで、現在の状態がtrueである(現在照明がついている)ことを把握したり、http-postのときは{“value”:true}をhttp-postのボディ部に持たせることで、値をtrueに変更する（つまり照明をオンにする）ことが可能になる。なお、仮想デバイスのurisは仮想デバイスが扱えるアドレスで、かつ、仮想デバイス内で一意でなければならない。つまり、複数のデバイス用のＴＤとして同じurisを持っていてはならない。そのようにしなければ、仮想デバイスがアクセスを受けたときにどのデバイス向けの要求なのかわからなくなるからである。したがって、ＴＤ生成時には、連番で番号を振っておくなどして、一意になるようにする。なお、「name」は機能の名称、「valueType」はその機能の呼び出し時に指定する引数の型を示している。「onoff」の場合はvalueTypeが「boolean」であるのでtrue/falseを指定する。すなわち、上記で説明したＵＲＬにアクセスする際のＨＴＴＰプロトコルのｂｏｄｙ部にtrueかfalseを指定することでオンにするかオフにするかを指定できる。ＴＤ制御部４４は、図５（ｂ）のＴＤをユーザＩＤに対応付けた、図６に示すようなデータをＴＤレポジトリ５４に登録する。このＴＤレポジトリ５４に対する処理は定期的もしくは不定期的に繰り返して実行する。上記の契約では10/29 10:00-11:00のみ有効であったので、この範囲外の日時である場合はＴＤを登録せず、もし登録されていたら削除する。
　上述したようにしてＴＤが登録された後、ユーザは契約日時においてデバイス６０を利用することが可能となる。ユーザがデバイス６０を利用する場合、ユーザ端末７０を通して、ユーザ認証を行う。この場合、アクセス制御部２２は、ユーザ管理ＤＢ５０を参照して、通常のインターネットサービスと同様のユーザ認証を行う。そして、アクセス制御部２２は、ＴＤ制御部４４に指示を出し、ユーザに応じたＴＤをＴＤレポジトリ５４からユーザ端末７０に送信する。これにより、ユーザ端末７０は、ユーザが利用可能なデバイスの機能についてのＴＤを取得することができる。
　ユーザ端末７０では、取得したＴＤをパースして機能に対応するＵＲＬを算出して、算出したＵＲＬを用いて仮想デバイスにアクセス（ＷｅｂＡＰＩ呼び出し）する。仮想デバイス機能部４６（仮想デバイス）では、ＷｅｂＡＰＩアクセスを受信して、その受信したＵＲＬをもとにＴＤレポジトリ５４からどのデバイスのどの機能が呼び出されたのかを算出する。
　たとえば、http://192.168.0.1/0123456789abcdef/00000001/xxxxxxxx/onoff へアクセスを受けたのであれば、ＴＤレポジトリ５４の情報からデバイスＩＤ「0123-4567-89ab-cdef」の「onoff」機能にアクセスしたことが分かる。すなわち、デバイスＩＤに基づいてデバイスのＴＤをＴＤ管理ＤＢ５２から見つけ、機能名からデバイスの同機能へのアクセス方法を見つけることができる。この情報に基づいて、仮想デバイス機能部４６はデバイスにアクセス（ＷｅｂＡＰＩ呼び出し）する。デバイスはＷｅｂＡＰＩ呼び出しを受けて処理を行う。たとえば、デバイスが照明であれば明かりをつけるなどの処理を行う。そして、デバイスは処理の実行が終了すると仮想デバイス機能部４６に応答を返す。仮想デバイス機能部４６は、デバイスからの応答を受けて、ユーザ端末７０に応答を転送する。以上により、ユーザ端末７０からデバイス６０を制御することが可能となっている。
　なお、サーバ１０（仮想デバイス機能部４６）はＷｅｂＡＰＩ呼び出しを受けたときに、ＴＤレポジトリ５４やＴＤ管理ＤＢ５２からデバイスへのアクセス方法を算出するため、もしＷｅｂＡＰＩ呼び出しが契約外であれば、算出に失敗し、デバイスアクセスに失敗する。したがって、本実施形態では、適切なユーザからの契約しているデバイスへのアクセスのみが可能となっている。
（情報処理システム１００の処理について）
　次に、図７～図９に基づいて、情報処理システム１００における処理の流れについてフローチャートに沿って説明する。
（ＴＤ登録処理）
　図７（ａ）には、ＴＤ登録処理のフローチャートが示されている。ＴＤ登録処理は、デバイス６０とサーバ１０により実行される処理である。まず、デバイス６０においては、管理者が、サーバ１０の仮想デバイス制御部４０のＵＲＬを登録すると、ステップＳ１０において、ＵＲＬの設定処理を実行する。次いで、デバイス６０では、ステップＳ１２において、管理者が設定したＵＲＬに対してＴＤを送信する。
　一方、サーバ１０の仮想デバイス制御部４０は、ステップＳ２０において、ＴＤを受信するまで待機している。仮想デバイス制御部４０は、ＴＤを受信すると、ステップＳ２２に移行し、ＴＤをＴＤ管理ＤＢ５２に格納する。
　以上により、ＴＤ登録処理が終了する。
（デバイス登録処理）
　図７（ｂ）には、デバイス登録処理のフローチャートが示されている。デバイス登録処理は、管理者端末７０’とサーバ１０により実行される処理である。まず、管理者端末７０’では、ステップＳ３０において、デバイス登録処理を実行する。この場合、管理者は、貸し出すデバイスを管理者端末７０’において入力するため、管理者端末７０’は、入力されたデバイスの情報をサーバ１０に送信する。また、管理者端末７０’では、ステップＳ３２において、プラン登録処理を実行する。この場合、管理者は、どのような条件で貸し出すかを入力するため、管理者端末７０’は、入力された情報をサーバ１０に送信する。
　一方、サーバ１０では、アクセス制御部２２は、登録情報を受信し、プラン情報を受信するまで待機している（Ｓ４０、Ｓ４２）。したがって、これらの情報を受信すると、アクセス制御部２２は、ステップＳ４４に移行し、プラン情報をアクセス管理ＤＢ３２に格納する。
　以上により、デバイス登録処理が終了する。
（ユーザ登録処理）
　図８には、ユーザ登録処理のフローチャートが示されている。図８の処理は、ユーザがデバイスを利用する（借りる）契約を行うために実行される処理である。図８の処理では、まず、ステップＳ５０において、ユーザ端末７０は、ユーザの操作に応じてアプリダウンロード要求をサーバ１０（利用要求受信部２０）に対して送信する。これに対し、サーバ１０側においては、利用要求受信部２０がダウンロード要求が送信されてくるまで待機しているため（Ｓ６０）、要求があった段階で、ステップＳ６２に移行し、アプリ（サービスアプリ）をアプリ管理ＤＢ３０から取得してユーザ端末７０に送信する。この場合、ユーザ端末７０では、ステップＳ５２において、アプリをインストールする。
　アプリがインストールされた後、ユーザ端末７０は、ステップＳ５４において、ユーザの操作に応じて、ユーザ認証要求をサーバ１０の利用要求受信部２０に送信する。利用要求受信部２０では、ステップＳ６４においてユーザ認証要求があるまで待機しているため、ユーザ認証要求があると、ステップＳ６６に移行し、ユーザ管理ＤＢ５０に基づいてユーザ認証を実行する。なお、ユーザ認証に成功した場合、ユーザ端末７０上のアプリには、アクセス管理ＤＢ３２に格納されているデータに基づいて、選択可能なプランが表示されるようになっている。
　次いで、ユーザ端末７０のユーザの操作によりプラン選択が行われると、ユーザ端末７０は、ステップＳ５６において、プラン選択情報をサーバ１０の利用要求受信部２０に送信する。これに対し、サーバ１０側では、利用要求受信部２０は、ステップＳ６８において、プラン選択情報を受信するまで待機しているため、プラン選択情報を受信した段階で、ステップＳ７０に移行する。
　ステップＳ７０に移行すると、利用要求受信部２０は、プラン選択情報をアクセス管理ＤＢ３２に格納する。すなわち、いずれかのプランとユーザのユーザＩＤとを紐づける。
　次いで、ステップＳ７２では、ユーザが選択したプランに基づいて、仮想デバイス制御部４０が仮想デバイスを生成する（仮想デバイス機能部４６を機能させる）。また、ＷｅｂＡＰＩ制御部４２が仮想デバイスのＷｅｂＡＰＩを生成し、ＴＤ制御部４４が、仮想デバイスのＴＤを生成する。
　以上により、ユーザ登録処理が終了する。
（デバイスのアクセス制御処理）
　図９には、デバイスのアクセス制御処理のフローチャートが示されている。デバイスのアクセス制御処理は、ユーザ端末７０、サーバ１０、デバイス６０により実行される処理である。本処理は、ユーザがユーザ端末７０を用いてデバイス６０を利用する際の処理である。
　図９の処理では、まずステップＳ１１０において、ユーザ端末７０からユーザＩＤやパスワードを用いたユーザ認証要求が行われる。一方、サーバ１０のアクセス制御部２２は、ユーザ認証があるまで待機しているので（Ｓ１３０）、ユーザ認証要求があると、ステップＳ１３２に移行する。ステップＳ１３２では、アクセス制御部２２は、ユーザ管理ＤＢ５０を参照して、ユーザ認証を行う。
　次いで、ステップＳ１１２において、ユーザ端末７０のアプリからＴＤの検索要求が出される。この場合、アクセス制御部２２は、ＴＤの検索要求があるまで待機しているので（Ｓ１３４）、ＴＤの検索要求があると、ステップＳ１３６に移行する。ステップＳ１３６では、アクセス制御部２２は、ＴＤ制御部４４に指示を出して、認証されたユーザに対応するＴＤをＴＤレポジトリ５４から検索して、ユーザ端末７０に送信する。
　ユーザ端末７０は、ステップＳ１１４においてＴＤが送信されてくるまで待機しているため、ＴＤが送信されると、ステップＳ１１６に移行し、ＴＤを受信する。
　次いで、ステップＳ１１８に移行すると、ユーザ端末７０では、ユーザの操作に応じていずれの機能（いずれのＴＤ）を利用するかを選択し、次のステップＳ１２０では、ＴＤをパースして機能に対応するＵＲＬを算出する。そして、ステップＳ１２２では、ユーザ端末７０は、算出したＵＲＬを用いて仮想デバイスにアクセスする（ＷｅｂＡＰＩ呼び出しを行う）。
　一方、サーバ１０の仮想デバイス機能部４６（仮想デバイス）は、ユーザ端末７０からＷｅｂＡＰＩ呼び出しがあるまで待機しているので（Ｓ１３８）、ＷｅｂＡＰＩ呼び出しがあると、ステップＳ１４０に移行する。ステップＳ１４０に移行すると、仮想デバイス機能部４６（仮想デバイス）は、受信したＵＲＬをもとにＴＤレポジトリ５４からどのデバイスのどの機能が呼び出されたのかを算出する。次いで、ステップＳ１４２では、仮想デバイス機能部４６（仮想デバイス）は、算出した情報に基づいて、デバイスにアクセス（ＷｅｂＡＰＩ呼び出し）する。
　仮想デバイス機能部４６からアクセス（ＷｅｂＡＰＩ呼び出し）されたデバイス６０では、ステップＳ１５０において、ＷｅｂＡＰＩを受けて処理を実行する。そして、処理の実行が終了すると、デバイス６０は、ステップＳ１５２において、仮想デバイス機能部４６に応答を返す。この場合、仮想デバイス機能部４６は、ステップＳ１４４において、デバイス６０からの応答を受けて、ユーザ端末７０に応答を転送し、ユーザ端末７０では、ステップＳ１２４において応答を受信する。
　以上により、デバイスのアクセス制御処理が終了する。
　以上詳細に説明したように、本第１の実施形態によると、利用要求受信部２０が、ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付けてアクセス管理ＤＢ３２に格納し、ＷｅｂＡＰＩ制御部４２は、登録に応じてＷｅｂＡＰＩを生成し、仮想デバイス制御部４０は、仮想デバイス機能部４６をＷｅｂＡＰＩへのアクセスに対してデバイスと連携して応答する仮想デバイスとして機能させる。そして、ＴＤ制御部４４は、ユーザ端末７０を利用したユーザ認証の結果に基づいて、認証したユーザに対応するＷｅｂＡＰＩへのアクセス方法を含むＴＤをユーザ端末７０に送信し、仮想デバイス機能部４６は、ユーザ端末７０からのＷｅｂＡＰＩへのアクセス（ＷｅｂＡＰＩ呼び出し）を受け付け、デバイスにアクセスする。これにより、本第１の実施形態では、デバイス側に機能を追加することなく、ユーザに応じたデバイスのアクセス制御を行うことができる。この場合、一般的にサーバ１０に比べてリソースが小さいデバイスに機能を追加しないようにしているため、アクセス制御に関する機能がデバイスのリソースを圧迫することがない。また、ユーザは、通常のデバイスへのアクセスと同様の方法で、利用契約したデバイスに対してアクセスすることが可能となる。また、本第1の実施形態では、ユーザ端末７０は、ＴＤから算出される一時的なＵＲＬを用いて仮想デバイスにアクセスするため、セキュリティの向上を図ることができる。
≪第２の実施形態≫
　次に、第２の実施形態について、図１０に基づいて説明する。本第２実施形態は、第１の実施形態のＴＤに情報を更に追加する例である。図１０（ａ）は、第１の実施形態のＴＤには存在しなかった情報として“price”の項目を追加した例であり、図１０（ｂ）は、“contractURL”の項目を追加した例である。
　図１０（ａ）のＴＤの場合、色の変更（rgbw）のＷｅｂＡＰＩは現状利用できない（“enabled”:false）が、追加コストを支払えば利用できるという情報が追加されている。すなわち、ユーザ端末７０では、ＴＤをパースしてこの情報を取得することで、ユーザに色の変更の機能を追加コストを支払うことで利用できるということを示すことができる。
　一方、図１０（ｂ）のＴＤの場合、追加契約用のＷｅｂページにアクセスするためのＵＲＬが、contractURLとして追加されている。ユーザは、新たにデバイスの機能を利用したいと思ったときには、contractURLにアクセスし、Ｗｅｂページで追加手続きを行うことで、利用可能な機能を追加することができる。なお、追加手続きに関しては、第１の実施形態において説明した利用契約と同様の処理により実現することができる。この追加手続きが行われると、アクセス制御部２２は、ＴＤ制御部４４に指示を出し、ＴＤレポジトリ５４に格納されているＴＤを更新する。これにより、仮想デバイス機能部４６（仮想デバイス）によるＷｅｂＡＰＩ呼び出しを受けた際の動作も変わるようになっている。
　以上説明したように、本第２の実施形態によると、ＴＤには、ユーザが利用可能なデバイスの機能を更新するために必要な情報が含まれているので、ユーザは、必要に応じて、利用可能なデバイスの機能を適宜追加等することが可能となっている。
≪第３の実施形態≫
　次に、第３の実施形態について図１１に基づいて説明する。本第３の実施形態は、ＴＤレポジトリ５４に登録されるＴＤから算出されるＷｅｂＡＰＩのＵＲＬに、推測が困難な情報を付加する点が、第１の実施形態と異なる。
　本第３の実施形態では、図１１（ａ）に示すように、擬似乱数などを利用して鍵情報としての文字列を生成し、ＴＤレポジトリ５４に登録するＴＤのurisの部分で指定するＵＲＬに生成した文字列（token）を追加する。上記第１の実施形態で説明したように、仮想デバイスのurisは仮想デバイスが扱えるアドレスで、かつ、仮想デバイス内で一意でなければならないが、これを遵守していれば、文字列は自由に決めることができる。このため、文字列を複雑にすることで、本来権利のない人が文字列を予測して不正アクセスする可能性を低減することができる。
　なお、図１１（ａ）の例に限らず、例えばＨＴＴＰアクセスであれば、図１１（ｂ）に示すようにＨＴＴＰのヘッダ部に文字列を追加してもよい。なお、ＨＴＴＰのボディ部に文字列を追加してもよい。なお、文字列は、ＴＤに含ませてユーザ端末７０に渡してもよいし、別のルートでユーザ端末７０に渡してもよい。
　仮想デバイス機能部４６（仮想デバイス）は、ユーザ端末７０からＷｅｂＡＰＩ呼び出しを受信した際には、tokenを確認した上で、デバイスのアクセス制御を行うこととする。
　以上、説明したように、本第３の実施形態によると、ＴＤには、ＷｅｂＡＰＩへアクセスするためのアドレス情報と、鍵情報としての文字列が含まれているので、第三者からの不正なアクセスの可能性を低減することができる。
≪第４の実施形態≫
　次に、第４の実施形態について、図１２、図１３に基づいて、説明する。本第４の実施形態では、サーバ１０がデバイス６０への不正アクセスを防ぐために、仮想デバイスへのアクセスをチェックする。
　図１２には、本第４の実施形態に係るサーバ１０’の機能ブロック図が示されている。図１２に示すように、本第４の実施形態では、制御部１４が、ＷｅｂＡＰＩ監視部６４を有するとともに、ＡＰＩアクセス管理ＤＢ６２及びアクセスルール管理ＤＢ６６を有している。また、サービス部１２が、監視通知部２４を有している。
　ＷｅｂＡＰＩ監視部６４は、ＡＰＩアクセス管理ＤＢ６２に格納されたユーザ端末７０から仮想デバイスへのアクセス情報と、アクセスルール管理ＤＢ６６に格納されているアクセスルールとに基づいて、不正アクセスがあった可能性があるかを判断する。ＷｅｂＡＰＩ監視部６４は、不正アクセスがあった可能性があると判断した場合に、その旨を監視通知部２４に通知する。監視通知部２４は、ＷｅｂＡＰＩ監視部６４から通知があった場合には、不正アクセスがあった可能性があることを通知先ＵＲＬ（例えばユーザ端末７０）に通知する。
　ここで、ＡＰＩアクセス管理ＤＢ６２は、図１３（ａ）に示すようなデータ構造を有する。図１３（ａ）に示すように、ＡＰＩアクセス管理ＤＢ６２は、「ＵＲＬ」、「デバイスＩＤ」、「アクセス元ＩＰアドレス」、「アクセス日時」の各フィールドを有する。「ＵＲＬ」のフィールドには、ユーザ端末７０からアクセスがあったＵＲＬが格納される。「デバイスＩＤ」のフィールドには、仮想デバイスの識別情報が格納される。「アクセス元ＩＰアドレス」のフィールドには、ユーザ端末７０のＩＰアドレスが格納される。「アクセス日時」のフィールドには、ユーザ端末７０からアクセスがあった日時が格納される。
　また、アクセスルール管理ＤＢ６６は、図１３（ｂ）に示すようなデータ構造を有する。図１３（ｂ）に示すように、アクセスルール管理ＤＢ６６は、「デバイスＩＤ」、「通知先ＵＲＬ」、「ルールＩＤ」の各フィールドを有する。「デバイスＩＤ」のフィールドには、アクセスがあった仮想デバイスの識別情報が格納され、「通知先ＵＲＬ」のフィールドには、通知先を示すＵＲＬが格納される。「ルールＩＤ」のフィールドには、不正アクセスの可能性があるか否かを判断するためのルールの識別情報が格納される。
　仮想デバイスは、ユーザ端末７０からアクセスを受けたときに、受信したＵＲＬに基づいてＴＤレポジトリ５４からデバイスＩＤを特定し、現在の日時と、アクセス元のユーザ端末７０のＩＰアドレスと、をＡＰＩアクセス管理ＤＢ６２に格納する。そして、ＷｅｂＡＰＩ監視部６４は、ＡＰＩアクセス管理ＤＢ６２への情報の追加を受けて、アクセスルール管理ＤＢ６６を参照して、ルールに合っているか（アクセスが正当であるか）否かを検証する。
　たとえば、ルールが、「アクセスしてきたＩＰアドレスが以前のアクセスと変わっていない」であれば、ＷｅｂＡＰＩ監視部６４は、アクセス元のＩＰアドレスを確認し、以前のアクセスと変わっていないかを判断する。そして、アクセス元のＩＰアドレスが変わっている場合には、監視通知部２４が通知先ＵＲＬに対して通知を行い、アクセスを許可して良いかを確認する。また、ルールが、「所定時間内（例えば１秒以内）において所定回数（例えば２回）以上アクセスがあった場合」や「所定時間内（１０秒以内）に異なるアクセス元ＩＰアドレスからアクセスがあった場合」であれば、ＷｅｂＡＰＩ監視部６４は、そのようなアクセスがあったか否かを判断する。そして、そのようなアクセスがあった場合には、監視通知部２４が通知先ＵＲＬに通知する。
　なお、通知のフォーマットとしては、種々採用することができ、例えば、図１３（ｃ）に示すような通知を行うことができる。
　以上、説明したように、本第４の実施形態によると、サーバ１０は、ＷｅｂＡＰＩへのアクセスを監視するＷｅｂＡＰＩ監視部６４と、ＷｅｂＡＰＩ監視部６４の監視結果に基づく通知を行う監視通知部２４と、を備えている。これにより、ＷｅｂＡＰＩ監視部６４により、不正アクセスがあった可能性があると判断された場合に、監視通知部２４は、ユーザ等にその旨を通知することができる。
≪第５の実施形態≫
　次に、第５の実施形態について説明する。第５の実施形態は、仮想デバイスがキャッシュ機能を有する点が第１の実施形態と異なる。
　上述したように、デバイス６０のonoffの現在の値を取得するときにはhttp-getを用い、変更するときにはhttp-postを用いることとしている。本第５の実施形態では、仮想デバイスは、一度、http-getで値が要求されたときに、デバイス６０にアクセスして値を取得し、ユーザ端末７０に返答するが、その際に値をキャッシュとして記憶しておく。そして、再度http-getで同じ値が要求されたときにはデバイスにアクセスせずに記憶しておいた値をユーザ端末７０に返答する。なお、記憶後、一定時間が経過した場合には記憶しておいた値を消去する。または、一度http-postが呼び出された場合に、記憶しておいた値を消去する。これにより、実際の状態とキャッシュとの不整合を減らすことが可能である。
　なお、仮想デバイスは、キャッシュ機能として、オフライン時にＷｅｂＡＰＩアクセスを一時記憶する機能を有していてもよい。すなわち、仮想デバイスがＷｅｂＡＰＩ呼び出しを受け、対応するデバイスにアクセスしたが、アクセスできなかった場合に、ＷｅｂＡＰＩアクセスを一時記憶しておき、所定時間経過した後に、記憶しておいたＷｅｂＡＰＩを用いて再度デバイスにアクセスする。
　これにより、デバイスがオンライン状態になっていれば、仮想デバイスがデバイスに再度アクセスすることにより、デバイスが要求を実行することが可能である。
（変形例１）
　なお、デバイス６０が電源をオフ／オンした場合や、デバイス６０が移動された場合など、ＩＰアドレスが変更になり、これまでのアクセス方法ではアクセスできなくなる場合がある。この場合には、サーバ１０は、デバイス６０からＴＤを再度取得するようにすればよい。たとえば、デバイス６０は、接続先のネットワークが変わったことを検出した場合に、再度ＴＤの登録を行うようにすればよい。
（変形例２）
　上記第１の実施形態で説明したように、利用契約の期間に入った場合、利用契約が終了した場合、及び契約内容が変更された場合には、ＴＤレポジトリ５４内のＴＤは更新されるようになっている。しかしながら、ユーザ端末７０はすでにＴＤを取得している場合があるため、元のＴＤを使って仮想デバイスにアクセスしようとすることがある。
　そこで、サーバ１０は、ＴＤが更新された場合に、ユーザ端末７０に対して通知してＴＤの再取得を促すようにしてもよい。このようにするためには、サービスアプリにイベント通知を受け取る機能を実装しておき、サーバ１０がＴＤを再取得するイベントをサービスアプリに対して通知するようにすればよい。
（変形例３）
　なお、ＴＤに契約期間を予め記載しておき、その情報に基づいて、ユーザ端末７０がＴＤを再取得するようにしてもよい。この場合、例えば、図１４に示すように、ＴＤに契約期間を追加するようにすればよい。図１４のＴＤには、契約期間の開始日が「begindate」として登録されており、契約期間の終了日が「enddate」として登録されている。
　図１４のＴＤを用いる場合、ユーザ端末７０は、契約開始前にＴＤを取得してもよい。この場合、begindateに基づいて、アクセス制御を行うようにすればよい。たとえば、現在の日時がbegindateよりも前であれば、対応するＷｅｂＡＰＩを呼び出したとしても、仮想デバイスでＷｅｂＡＰＩ呼び出しに対応するデバイスにアクセスしないようにすればよい。
　なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体（ただし、搬送波は除く）に記録しておくことができる。
　プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
　プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
　上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
　なお、以上の第１～第５の実施形態及び変形例の説明に関して、更に以下の付記を開示する。
（付記１）　ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付ける受付部と、
　前記受付部への登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成する生成部と、
　端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知する通知部と、
　前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスするアクセス部と、を備える情報処理装置。
（付記２）　前記通知部が通知する前記情報には、ユーザが利用可能なデバイスの機能を更新するために必要な情報が含まれることを特徴とする付記１に記載の情報処理装置。
（付記３）　前記通知部が通知する前記情報には、前記ＷｅｂＡＰＩへアクセスするためのアドレス情報と、鍵情報が含まれることを特徴とする付記１又は２に記載の情報処理装置。
（付記４）　前記ＷｅｂＡＰＩへのアクセスを監視する監視部と、
　前記監視部の監視結果に基づく処理を実行する実行部と、を更に備える付記１～３のいずれかに記載の情報処理装置。
（付記５）　前記アクセス部が前記デバイスにアクセスしたときに取得した情報を記憶しておき、所定時間の間は、記憶してある情報に基づいて前記端末に応答する応答部を更に備える付記１～４のいずれかに記載の情報処理装置。
（付記６）　前記アクセス部が前記デバイスにアクセスできなかった場合には、所定時間経過後に、前記デバイスに再アクセスすることを特徴とする付記１～５のいずれかに記載の情報処理装置。
（付記７）　前記通知部は、前記デバイスの情報に変更があった場合に、前記端末に対して前記ＷｅｂＡＰＩへのアクセス方法を含む情報の更新を通知することを特徴とする付記１～６のいずれかに記載の情報処理装置。
（付記８）　前記ＷｅｂＡＰＩへのアクセス方法を含む情報は、有効期限情報を含むことを特徴とする付記１～７のいずれかに記載の情報処理装置。
（付記９）　端末と、デバイスと、情報処理装置とがネットワークに接続された情報処理システムであって、
　前記情報処理装置は、
　前記端末から、ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付ける受付部と、
　前記受付部への登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成する生成部と、
　端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知する通知部と、
　前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスするアクセス部と、を有する、
ことを特徴とする情報処理システム。
（付記１０）　コンピュータが、
　ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付け、
　前記登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成し、
　端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知し、
　前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスする、
処理を実行することを特徴とする情報処理方法。
（付記１１）　前記情報には、ユーザが利用可能なデバイスの機能を更新するために必要な情報が含まれることを特徴とする付記１０に記載の情報処理方法。
（付記１２）　前記情報には、前記ＷｅｂＡＰＩへアクセスするためのアドレス情報と、鍵情報が含まれることを特徴とする付記１０又は１１に記載の情報処理方法。
（付記１３）　前記ＷｅｂＡＰＩへのアクセスを監視し、
　前記監視部の監視結果に基づく処理を実行する、処理を前記コンピュータが更に実行する付記１０～１２のいずれかに記載の情報処理方法。
（付記１４）　前記デバイスにアクセスしたときに取得した情報を記憶しておき、所定時間の間は、記憶してある情報に基づいて前記端末に応答する、処理を前記コンピュータが更に実行する付記１０～１３のいずれかに記載の情報処理方法。
（付記１５）　前記デバイスにアクセスできなかった場合に、所定時間経過後に、前記デバイスに再アクセスすることを特徴とする付記１０～１４のいずれかに記載の情報処理方法。
（付記１６）　前記通知する処理では、前記デバイスの情報に変更があった場合に、前記端末に対して前記ＷｅｂＡＰＩへのアクセス方法を含む情報の更新を通知することを特徴とする付記１０～１５のいずれかに記載の情報処理方法。
（付記１７）　前記情報は、有効期限情報を含むことを特徴とする付記１０～１６のいずれかに記載の情報処理方法。
　　１０　サーバ（情報処理装置）
　　２０　利用要求受信部（受付部）
　　２４　監視通知部（実行部）
　　４０　仮想デバイス制御部（生成部の一部）
　　４２　ＷｅｂＡＰＩ制御部（生成部の一部）
　　４４　ＴＤ制御部（通知部）
　　４６　仮想デバイス機能部（アクセス部、応答部）
　　６０　デバイス
　　６４　ＷｅｂＡＰＩ監視部（監視部）
　　７０　ユーザ端末（端末）
　　８０　ネットワーク
　　１００　情報処理システム

Claims (17)

  1. 　　ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付ける受付部と、
    　前記受付部への登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成する生成部と、
    　端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知する通知部と、
    　前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスするアクセス部と、を備える情報処理装置。
  2. 　　前記通知部が通知する前記情報には、ユーザが利用可能なデバイスの機能を更新するために必要な情報が含まれることを特徴とする請求項１に記載の情報処理装置。
  3. 　　前記通知部が通知する前記情報には、前記ＷｅｂＡＰＩへアクセスするためのアドレス情報と、鍵情報が含まれることを特徴とする請求項１又は２に記載の情報処理装置。
  4. 　　前記ＷｅｂＡＰＩへのアクセスを監視する監視部と、
    　前記監視部の監視結果に基づく処理を実行する実行部と、を更に備える請求項１～３のいずれかに記載の情報処理装置。
  5. 　　前記アクセス部が前記デバイスにアクセスしたときに取得した情報を記憶しておき、所定時間の間は、記憶してある情報に基づいて前記端末に応答する応答部を更に備える請求項１～４のいずれかに記載の情報処理装置。
  6. 　　前記アクセス部が前記デバイスにアクセスできなかった場合には、所定時間経過後に、前記デバイスに再アクセスすることを特徴とする請求項１～５のいずれかに記載の情報処理装置。
  7. 　　前記通知部は、前記デバイスの情報に変更があった場合に、前記端末に対して前記ＷｅｂＡＰＩへのアクセス方法を含む情報の更新を通知することを特徴とする請求項１～６のいずれかに記載の情報処理装置。
  8. 　　前記ＷｅｂＡＰＩへのアクセス方法を含む情報は、有効期限情報を含むことを特徴とする請求項１～７のいずれかに記載の情報処理装置。
  9. 　　端末と、デバイスと、情報処理装置とがネットワークに接続された情報処理システムであって、
    　前記情報処理装置は、
    　前記端末から、ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付ける受付部と、
    　前記受付部への登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成する生成部と、
    　端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知する通知部と、
    　前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスするアクセス部と、を有する、
    ことを特徴とする情報処理システム。
  10. 　　コンピュータが、
    　ユーザが利用可能なデバイス及び利用可能なデバイスの機能の登録を受け付け、
    　前記登録に応じてＷｅｂＡＰＩを生成するとともに、該ＷｅｂＡＰＩへのアクセスに対して前記デバイスと連携して応答する仮想デバイスを生成し、
    　端末を利用したユーザ認証の結果に基づいて、認証したユーザに対応する前記ＷｅｂＡＰＩへのアクセス方法を含む情報を前記端末に通知し、
    　前記端末からの前記ＷｅｂＡＰＩへのアクセスを受け付け、前記仮想デバイスを介して前記デバイスにアクセスする、
    処理を実行することを特徴とする情報処理方法。
  11. 　　前記情報には、ユーザが利用可能なデバイスの機能を更新するために必要な情報が含まれることを特徴とする請求項１０に記載の情報処理方法。
  12. 　　前記情報には、前記ＷｅｂＡＰＩへアクセスするためのアドレス情報と、鍵情報が含まれることを特徴とする請求項１０又は１１に記載の情報処理方法。
  13. 　　前記ＷｅｂＡＰＩへのアクセスを監視し、
    　前記監視部の監視結果に基づく処理を実行する、処理を前記コンピュータが更に実行する請求項１０～１２のいずれかに記載の情報処理方法。
  14. 　　前記デバイスにアクセスしたときに取得した情報を記憶しておき、所定時間の間は、記憶してある情報に基づいて前記端末に応答する、処理を前記コンピュータが更に実行する請求項１０～１３のいずれかに記載の情報処理方法。
  15. 　　前記デバイスにアクセスできなかった場合に、所定時間経過後に、前記デバイスに再アクセスすることを特徴とする請求項１０～１４のいずれかに記載の情報処理方法。
  16. 　　前記通知する処理では、前記デバイスの情報に変更があった場合に、前記端末に対して前記ＷｅｂＡＰＩへのアクセス方法を含む情報の更新を通知することを特徴とする請求項１０～１５のいずれかに記載の情報処理方法。
  17. 　　前記情報は、有効期限情報を含むことを特徴とする請求項１０～１６のいずれかに記載の情報処理方法。
PCT/JP2018/008297 2017-04-05 2018-03-05 情報処理装置、情報処理システム及び情報処理方法 WO2018186083A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP18781328.2A EP3608824A4 (en) 2017-04-05 2018-03-05 INFORMATION PROCESSING DEVICE, INFORMATION PROCESSING SYSTEM AND INFORMATION PROCESSING METHOD
US16/586,875 US11405398B2 (en) 2017-04-05 2019-09-27 Information processing apparatus, information processing system, and information processing method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017-075322 2017-04-05
JP2017075322A JP6760186B2 (ja) 2017-04-05 2017-04-05 情報処理装置、情報処理システム及び情報処理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/586,875 Continuation US11405398B2 (en) 2017-04-05 2019-09-27 Information processing apparatus, information processing system, and information processing method

Publications (1)

Publication Number Publication Date
WO2018186083A1 true WO2018186083A1 (ja) 2018-10-11

Family

ID=63712574

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/008297 WO2018186083A1 (ja) 2017-04-05 2018-03-05 情報処理装置、情報処理システム及び情報処理方法

Country Status (4)

Country Link
US (1) US11405398B2 (ja)
EP (1) EP3608824A4 (ja)
JP (1) JP6760186B2 (ja)
WO (1) WO2018186083A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3629258A1 (en) * 2018-09-28 2020-04-01 Ricoh Company, Ltd. Resource reservation system, terminal setting method, and information processing apparatus
JP2022029306A (ja) * 2020-08-04 2022-02-17 富士通株式会社 ネットワークスイッチ，制御プログラムおよび制御方法
JP7148824B2 (ja) * 2021-03-02 2022-10-06 ダイキン工業株式会社 情報処理装置、情報処理方法、プログラム、及び情報処理システム

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015530038A (ja) 2012-08-20 2015-10-08 アルカテル−ルーセント 物理オブジェクトと通信デバイスとの間の許可された通信を確立するための方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105453047B (zh) 2013-05-06 2019-12-10 康维达无线有限责任公司 提供物联网(iot)适配服务的***和方法
US10268495B2 (en) * 2016-02-18 2019-04-23 Verizon Patent And Licensing Inc. Virtual device model system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015530038A (ja) 2012-08-20 2015-10-08 アルカテル−ルーセント 物理オブジェクトと通信デバイスとの間の許可された通信を確立するための方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GUINARD, D.: "Building the web of things", BCS, May 2016 (2016-05-01), XP055552271, Retrieved from the Internet <URL:https://www.bcs.org/upload/pdf/the-web-of-things-dguinard-120516.pdf> [retrieved on 20180522] *
SAKAMOTO, TAKUYA ET AL.: "Dynamic connection management between web apps and peripheral devices by web driver", PROC. OF 2016 IEEE INTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING AND COMMUNICATION WORKSHOPS, 2016, XP055552276 *
See also references of EP3608824A4

Also Published As

Publication number Publication date
JP2018180682A (ja) 2018-11-15
US20200028852A1 (en) 2020-01-23
EP3608824A1 (en) 2020-02-12
EP3608824A4 (en) 2020-03-25
JP6760186B2 (ja) 2020-09-23
US11405398B2 (en) 2022-08-02

Similar Documents

Publication Publication Date Title
KR101951973B1 (ko) 자원 액세스 허가 기법
CN105659558B (zh) 计算机实现的方法、授权服务器以及计算机可读存储器
US8776203B2 (en) Access authorizing apparatus
US8688813B2 (en) Using identity/resource profile and directory enablers to support identity management
US20140230020A1 (en) Authorization server and client apparatus, server cooperative system, and token management method
US7454421B2 (en) Database access control method, database access controller, agent processing server, database access control program, and medium recording the program
CN107925668A (zh) 资源驱动的动态授权框架
JP4496220B2 (ja) セキュリティ対応のコンテンツのキャッシュを容易にする方法および装置
US8752187B2 (en) Portable license server
JP7096736B2 (ja) システム、及びデータ処理方法
KR20130007797A (ko) 개방형 인증 방법 및 시스템
US20170230468A1 (en) Systems and Methods for Facilitating Service Provision Between Applications
KR102376254B1 (ko) 분산 식별자 관리 방법 및 장치
US11611551B2 (en) Authenticate a first device based on a push message to a second device
WO2018186083A1 (ja) 情報処理装置、情報処理システム及び情報処理方法
JP2002032216A (ja) アプリケーションのホスティング装置
EP2149848A1 (en) Data distribution system
TW201729121A (zh) 雲端服務伺服器及用來管理一雲端服務伺服器之方法
JP7170550B2 (ja) 管理装置およびその制御方法
WO2016188224A1 (zh) 一种业务授权方法、装置、***及路由器
CN103220261A (zh) 一种开放鉴权应用程序接口代理的方法、装置及***
US11641356B2 (en) Authorization apparatus, data server and communication system
EP2309390B1 (en) Data distribution system
KR102320550B1 (ko) Did 기반 인터체인 시스템 및 그의 데이터 교환／거래 방법
JP2007323235A (ja) 属性利用承認システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18781328

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018781328

Country of ref document: EP

Effective date: 20191105