JP2018142125A - Device management apparatus, and device management method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To manage a device based on a usage mode. A device management device (10) according to the present invention is based on an application setting unit (12) in which an application (121) used by a primary user using the device (2) is set, and an application (121) set in the application setting unit (12). A context analysis unit 13 for generating a context indicating a usage mode of the device 2 is provided. [Selection diagram] Fig. 1

Description

  The present invention relates to a device management apparatus, a device management method, and a program.

  IoT (Internet of Things) marketplace (IoT-MP) that collects data from devices and executes actions by devices by reusing existing devices owned and used by general individuals and companies ) Is being implemented.

  In IoT-MP, the device owner (primary user) sells IoT resources such as sensing function and actuation function of the device, and the indirect user (secondary usage) of the device owned by the primary user. Purchase the IoT resource. Thereby, even if the secondary user does not have a device, the secondary user can use an arbitrary IoT resource, and can create a visualization service or an event detection type application.

  In order for the secondary user to specify the necessary IoT resources on the IoT-MP, the IoT-MP needs to have two elements.

  One is the definition of the IoT resource, which is synonymous with the definition of the function of the device. In recent devices, API (Application Programming Interface) is often defined in units of functions such as sensing and actuation. Such a device can operate the function of the device via a network by, for example, HTTP (Hypertext Transfer Protocol) communication including a message in a JSON (Java Script (registered trademark) Object Notification) format. In IoT-MP, external reference can be enhanced by defining IoT resources in API units.

  The other is IoT resource classification. It is also the role of IoT-MP to improve reusability by classifying according to the attribute based on the geography where the device is arranged or the attribute based on the type of data collected by the device such as temperature and humidity.

  A conventional IoT data store such as AWS IoT (see Non-Patent Document 1) provides a service for managing a device owned by a user and an API of the device on a database. According to such a service, the secondary user can specify an arbitrary IoT resource by referring to the attribute of the device registered in the database.

Amazon Web Service, “AWS IoT Developer Guide”, pp.67-74 (Managing Things with AWS IoT), [online], [Search February 1, 2017], Internet <http: //docs.aws.amazon .com / iot / latest / developerguide / iot-dg.pdf>

  In the current IoT-MP, it is difficult for a secondary user to find and provide a desired IoT resource. When a secondary user uses an IoT resource (secondary use), it is common to search for an IoT resource based on attribute information or the like on the IoT-MP and use the searched IoT resource. Here, since the primary user who owns the device is different from the secondary user who uses the IoT resource, the secondary user cannot know the state of the device or how it is used by the primary user. . Therefore, an IoT resource that is used in a manner different from the intention of the secondary user may be obtained.

  For example, when a secondary user wants to acquire room temperature information of a house, it may be possible to acquire temperature data using a device belonging to a room temperature meter. Here, depending on the primary user of the room temperature meter, there is a possibility that the device is used in a usage mode different from the purpose of the secondary user, such as installing the room temperature meter outdoors or wearing it on the body. There may be a discrepancy with the data that the secondary user wants to acquire. Therefore, in order to provide an IoT resource that matches the request of the secondary user, the device should be managed according to the usage mode such as the usage method and usage environment of the device, rather than simple management based on the device attribute. However, conventionally, sufficient studies have not been made on the management of devices according to such usage modes.

  An object of the present invention is to provide a device management apparatus, a device management method, and a program capable of solving the above-described problems and managing devices based on usage modes.

  In order to solve the above problems, a device management apparatus according to the present invention is a device management apparatus that manages a device owned by a primary user, and an application that is used by the primary user using the device is set. An application setting unit; and a context analysis unit that generates a context indicating a usage mode of the device by the primary user based on an application set in the application setting unit.

  In order to solve the above problem, a device management method according to the present invention is a device management method in a device management apparatus that manages a device owned by a primary user, and is used by the primary user using the device. And a step of generating a context indicating a usage mode of the device by the primary user based on the set application.

  In order to solve the above problems, a program according to the present invention causes a computer to function as the device management apparatus described above.

  According to the device management apparatus, the device management method, and the program according to the present invention, it is possible to manage devices based on the usage mode.

It is a figure which shows the structural example of the IoT resource management system which concerns on one Embodiment of this invention. It is a figure which shows the structural example of the application set to the application setting part shown in FIG. It is a figure which shows the structural example of the application set to the application setting part shown in FIG. It is a figure which shows the structural example of the application set to the application setting part shown in FIG. It is a figure which shows the structural example of the secondary usage controller shown in FIG. It is a figure for demonstrating the utilization format "indirect sensor." It is a figure for demonstrating the utilization format "direct sensor." It is a figure for demonstrating the utilization format "direct actuator". It is a flowchart which shows operation | movement of the primary utilization functional block group of the device management apparatus shown in FIG. It is a figure which shows typically the flow of the process by the primary utilization function block group of the device management apparatus shown in FIG. It is a figure which shows the structural example of device management DB shown in FIG. It is a figure which shows the example of a setting of the application in the application setting part shown in FIG. It is a figure which shows the structural example of the context handler which the context analysis part shown in FIG. 1 produces | generates. It is a flowchart which shows operation | movement of the secondary utilization function block group of the device management apparatus shown in FIG. It is a figure which shows typically the flow of a process until the production | generation of the secondary usage controller by the secondary usage functional block group of the device management apparatus shown in FIG. It is a figure which shows typically the flow of the process by the secondary usage controller shown in FIG. It is a figure which shows the example of a setting of the resource request | requirement acquired by the request | requirement interpretation part shown in FIG. It is a figure which shows the structural example of the secondary usage controller produced | generated by the secondary usage controller management part shown in FIG. It is a figure which shows the structural example of secondary usage pointer DB shown in FIG. It is a figure which shows the structural example of device management DB shown in FIG.

  Embodiments of the present invention will be described below.

  FIG. 1 is a diagram showing a configuration example of an IoT resource management system 1 according to an embodiment of the present invention.

  The IoT resource management system 1 shown in FIG. 1 includes a device management apparatus 10 between a primary user who owns a device 2 having an API 2a and a secondary user who secondary uses a function (IoT resource) included in the device 2. Is provided.

  The primary user owns one or more devices 2 and registers the owned devices 2 in the device management apparatus 10. The primary user uses the registered device 2 to use an application that performs event notification in response to the occurrence of a predetermined event.

  Data is transmitted to and received from the device 2 via the API 2a included in the device 2. The API 2a is defined for each function provided in the device 2, and the device 2 can be caused to perform a predetermined operation by transmitting a control message to the API 2a from the outside. For example, when the device 2 is a thermostat, the sensing function for notifying the request source of the current room temperature of the room where the thermostat is installed, and when the device 2 is an air-conditioning / heating device, an actuator function for blowing cool / warm air is specified as API 2a. Is done.

  The secondary user inputs a resource request for requesting use of the IoT resource to the device management apparatus 10 and executes a desired application using the IoT resource provided in response to the resource request. Specific examples of secondary users include, for example, an advertisement provider who wants to know the “hot rooms” in the world in real time and notify the residents of those rooms of soft drinks, or “detailed room temperature information”. "Regularly" and then a healthcare provider who wants to notify the presumed victim of influenza of an advertisement that encourages them to visit. The resource request mainly specifies data to be acquired, operation to be performed, communication timing, and the like.

  The device management apparatus 10 manages the device 2 owned by the primary user and provides the IoT resource to the secondary user in response to a resource request from the secondary user. Hereinafter, the configuration of the device management apparatus 10 will be described in more detail. In FIG. 1, bold arrows indicate input / output of data, solid arrows indicate input / output of control signals, and broken arrows indicate input by a primary user or a secondary user.

  A device management apparatus 10 shown in FIG. 1 includes a device management unit 11, an application setting unit 12, a context analysis unit 13, a device management DB 14, a request interpretation unit (request acquisition unit) 15, and a secondary usage controller management unit. 16 and a secondary usage pointer DB 17. 1 illustrates an example in which the device management apparatus 10 includes each of the above-described configurations. However, the configuration is not limited thereto, and each configuration may be distributed as individual devices. Although details will be described later, the device management unit 11, the application setting unit 12, the context analysis unit 13, and the device management DB 14 are mainly functional blocks related to the use (primary use) of the device 2 by the primary user. These function blocks may be collectively referred to as a primary use function block group. The request interpreter 15, the secondary usage controller management unit 16, and the secondary usage pointer DB 17 are functional blocks related to the usage (secondary usage) of the device 2 by the secondary user. Collectively, it may be referred to as a secondary use function block group.

  In response to the registration of the device 2 from the primary user, the device management unit 11 associates the primary user who owns the device 2, the registered device 2, and the API 2a included in the device 2, thereby managing the device. Record in DB14. Further, the device management unit 11 transmits a control message to the API 2 a included in the device 2 or creates an arbitrary application using the application setting unit 12 in response to an input from the primary user. In addition, the device management unit 11 is linked to the secondary usage controller management unit 16, and performs sensing or API for the API 2 a of the device 2 specified from the secondary usage controller 161 generated by the secondary usage controller management unit 16. The device 2 can be controlled by transmitting a control message for actuation.

  In the application setting unit 12, an application 121 (application program) using the device 2 owned by the primary user is set. Examples of the application 121 include an application set in detail by the primary user itself and an application created and set by a third party.

  2A to 2C are diagrams illustrating a configuration example of the application 121. FIG. As shown in FIGS. 2A to 2C, the application 121 has a configuration in which a controller 122 connected to the API 2a of the device 2 transmits a control message. FIG. 2A shows an example in which the API 2a of one device 2 and the controller 122 of the application 121 communicate with each other. In FIG. 2B, the API 2a of one device 2 communicates with the input controller 122a, the API 2a of another device 2 communicates with the output controller 122b, and between the input controller 122a and the output controller 122b. An example in which a control rule is set is shown. 2C shows an example in which a plurality of controllers 122 communicate with the API 2a of different devices 2 and a messaging flow between the controllers 122 is set.

  As the application 121, the API 2a of a plurality of devices 2 (for example, a thermostat and an air conditioner) is used in response to the occurrence of an event such as “when the room temperature reaches 26 ° C. or higher” or “turns on the cooling function”. An application that executes the operation can be set. Further, the API used for the application 121 may include not only the API 2 a of the device 2 but also an API included in the web service. In this case, for example, it is possible to set an application 121 that performs operations such as “when the room temperature reaches 26 ° C. or higher” and “tweets“ hot ”in SNS”.

  Referring to FIG. 1 again, the application setting unit 12 outputs the set configuration information (application configuration information) and event information of the application 121 to the context analysis unit 13. The application configuration information is information indicating the product information of the device 2 used by the application 121, the API 2a included in the device 2, a control message transmitted to the API 2a, a label set by the primary user, and the like. Further, information obtained by analyzing these pieces of information by machine learning may be included in the application configuration information. The event information is real-time information that is notified based on conditions set in the application 121.

  The context analysis unit 13 generates a context indicating the usage mode of the device 2 based on the application 121 set in the application setting unit 12. Specifically, the context analysis unit 13 analyzes the application configuration information output from the application setting unit 12, and indicates a usage mode such as a usage method and a usage environment of the device 2 used for the application 121 for each application 121. Is generated. Then, the context analysis unit 13 generates a process called a context handler 131. The context handler 131 has a role of reflecting the context of the device 2 obtained by analyzing the application configuration information in the entry of the corresponding device 2 in the device management DB 14 when the event information is notified. An expiration date is set for the context, and when the expiration date is exceeded, the context analysis unit 13 deletes the context. A plurality of contexts can be set in one entry of the device management DB 14, but in the case of a symmetric context, a new context is adopted.

  As an example, consider the aforementioned thermostat and air-conditioning appliance collaboration application. It is assumed that the label is set by the primary user as “turn on cooling when the room gets hot” in this application. The context analysis unit 13 analyzes the contexts “hot room” and “turn on cooling” from this label, and generates a context handler 131. If the event information is notified when the measurement result by the thermostat API “temperature measurement” is 26 ° C. or higher, the context analyzer 13 indicates that the thermostat API “temperature measurement” is “26 ° C. or higher”. Analyze that it has the context of “hot room” only in certain cases. This context becomes invalid after the expiration date or when a symmetric context ("cold room") is acquired.

  The device management DB 14 includes a pointer, a user name of a primary user who owns the device 2, an address of the device 2, a device name, an API name of the API 2a included in the device 2, and an API 2a context in an entry. It is. In addition to registration from the device management unit 11, the device management DB 14 accepts context registration from the context analysis unit 13. At this time, the device management DB 14 assigns an additional attribute as a context of the API 2 a included in the registered device 2. For example, when a thermostat is registered in advance by the device management unit 11, the device management DB 14 logically adds an attribute “room is hot” to the API “temperature measurement” of the thermostat in the context registration. This attribute changes in real time in response to the notification from the context analysis unit 13.

  The request interpretation unit 15 acquires a resource request from the secondary user, shapes the acquired resource request into a format that can be recognized by the device management apparatus 10, and outputs the request to the secondary usage controller management unit 16. As a request from the secondary user, a usage format for specifying a secondary usage format, a key (context or API name) to be searched, a schedule setting for determining communication timing, and mutual communication with the device management apparatus 10 are performed. There are endpoint settings to negotiate. The request interpreter 15 outputs the shaped resource request to the secondary usage controller manager 16.

  For example, when the secondary user is the above-mentioned advertising business, the resource request includes the usage type “indirect sensor”, key “context: hot room”, schedule setting “real time”, endpoint setting “secondary user side” Data reception address ”. The secondary user may input the content of the request in a natural language, and the request interpretation unit 15 may analyze the content of the request input in the natural language and obtain it as a resource request.

  When the resource request (resource request shaped into a recognizable format) is input from the request interpreter 15, the secondary usage controller management unit 16 generates a secondary usage controller 161 that executes secondary usage of the device 2. To do. Then, the secondary usage controller management unit 16 generates an entry corresponding to the generated secondary usage controller 161 in the secondary usage pointer DB 17 and registers the key included in the resource request in the generated entry. For example, when a resource request including a usage type “indirect sensor” and a key “context: hot room” is input, the secondary usage controller management unit 16 generates a new secondary usage controller 161 and the generated secondary usage. An entry corresponding to the controller 161 is generated in the secondary usage pointer DB 17. Further, the secondary usage controller management unit 16 registers the key “context: hot room” included in the resource request in the generated entry.

  The secondary usage pointer DB 17 is a database that stores secondary usage pointers, keys, and device management DB pointers in association with each other. The secondary usage pointer DB 17 includes entries generated for each secondary usage controller 161. One entry includes a secondary usage pointer for identifying the secondary usage controller 161, a key corresponding to a request from the secondary user, and a pointer to the entry in the device management DB 14 searched by the key (device management DB pointer) list. The list of device management DB pointers is updated each time the secondary usage controller 161 searches according to the schedule setting. By referring to the device management DB pointer, the secondary usage controller 161 can obtain the value at the time of the previous search for the corresponding device management DB 14 entry.

  Next, the secondary usage controller 161 will be described.

  FIG. 3 is a diagram illustrating a configuration example of the secondary usage controller 161.

  As shown in FIG. 3, the secondary usage controller 161 includes a secondary usage pointer 162, a scheduler 163, and an endpoint 164.

  The secondary usage pointer 162 stores a secondary usage pointer for identifying the secondary usage controller 161 in the secondary usage pointer DB 17. The scheduler 163 stores schedule settings included in resource requests. Note that the schedule setting includes a “polling type” that specifies a time interval for performing sensing and actuation, and a “request type” that specifies a time for performing sensing and actuation. The endpoint 164 stores an endpoint setting included in the resource request. The endpoint setting includes an address part and a control message part. In the address section, the secondary user side address (the output destination of data from the device 2) or the device management apparatus 10 side address for inputting a command to the device 2 according to the operation to be performed by the device 2 (Command input source to device 2) is set. In the control message portion, a control message (for example, a message in JSON format) corresponding to an operation desired to be performed by the device 2 is set. Depending on the endpoint setting, the secondary usage controller 161 can output data acquired from the device 2 to the secondary user side or input a control message to the device 2.

  The secondary usage controller 161 is an execution program that enables the secondary user to use the device 2 (IoT resource) of the primary user at an arbitrary timing. The secondary usage controller 161 has a one-to-one correspondence with the entry registered in the secondary usage pointer DB 17. The secondary usage controller 161 refers to the corresponding entry registered in the secondary usage pointer DB 17 and searches the device management DB 14 using the key held in the entry. Then, the secondary usage controller 161 refers to the entry of the hit device management DB 14 and temporarily stores the entry pointer as a device management DB pointer in the corresponding entry of the secondary usage pointer DB 17. By referring to the entry in the device management DB 14, the latest state of the device 2 stored in the entry can be acquired. Such a usage form corresponds to “indirect sensor”.

  That is, in the usage format “indirect sensor”, as shown in FIG. 4A, the secondary usage controller 161 stores the secondary usage pointer 162 at the timing specified by the schedule setting stored in the scheduler 163. An entry including the secondary usage pointer is searched from the secondary usage pointer DB 17. Then, the secondary usage controller 161 searches the device management DB 14 using the key held in the searched entry, and temporarily stores the pointer of the hit entry in the corresponding entry of the secondary usage pointer DB 17. Then, the secondary usage controller 161 stores the information of the device 2 included in the entry of the device management DB 14 in which the pointer is stored as the device management DB pointer, as a secondary user designated by the endpoint setting stored in the endpoint 164. Output to the local address.

  FIG. 4B is a diagram illustrating a usage format “direct sensor”. In the case of the usage format “direct sensor”, as shown in FIG. 4B, the secondary usage controller 161 searches the device management DB 14 and gives a control message for instructing sensing to the API 2a of the device 2 corresponding to the entry hit. Is obtained, and the data obtained by sensing according to the control message is acquired and output to the secondary user side.

  FIG. 4C is a diagram showing a usage format “direct actuator”. In the case of the usage format “direct actuator”, as shown in FIG. 4C, the secondary usage controller 161 searches the device management DB 14 to control the API 2a of the device 2 corresponding to the entry that hits the control. Send a message.

  The usage format described above is set in response to a request from a secondary user. Therefore, the secondary user can cause the device 2 to perform a desired operation by setting the usage format, schedule setting, endpoint setting, key, and the like.

  Next, the operation of the device management apparatus 10 according to the present embodiment will be described separately for the operation of the primary usage function block group and the operation of the secondary usage function block group. When the secondary usage functional block group uses the context, it is necessary to refer to the device management DB 14 to which the context is added by the primary usage functional block group. For this reason, the operation flow of the primary use function block group and the operation flow of the secondary use function block group are linked mainly with the device management DB 14.

  First, the operation of the primary use function block group will be described. FIG. 5 is a flowchart showing the operation of the primary use function block group. FIG. 6 schematically shows a flow of processing by the primary use function block group. In FIG. 6, solid line arrows indicate input / output of control signals, and broken line arrows indicate input by the primary user.

  The device management unit 11 accepts registration of the device 2 by the primary user and registers it in the device management DB 14 (step S101).

  FIG. 7 is a diagram illustrating a configuration example of the device management DB 14.

  As shown in FIG. 7, the device management DB 14 associates the pointer, the primary user name, the address of the device 2, the device name of the device 2, the API name of the API 2a included in the device 2, and the context. Add and remember.

  The device management unit 11 stores the user name, address, device name, and API name in the device management DB 14 according to the registration by the primary user.

  Referring to FIG. 5 again, the application setting unit 12 receives the setting of the application 121 created using the API 2a of the device 2 registered in the device management unit 11 (step S102).

  FIG. 8 is a diagram illustrating a setting example of the application 121. In FIG. 8, as an example, the application 121 performs an operation of “ON when the thermostat temperature measurement indicates 26 ° C. or higher (label: turn on the cooling when the room becomes hot)”. Is shown. In this case, the application 121 is set by using an if-then condition (if it is, it is changed to).

  Specifically, as shown in FIG. 8, the application ID, the user name of the primary user who uses the application 121, the device name, the API name, and the API2a operation setting in the if statement and the respectively statement, and the primary A label input by the user is set in association with the label.

  The application setting unit 12 outputs the application configuration information of the set application 121 to the context analysis unit 13.

  Referring again to FIG. 5, the context analysis unit 13 analyzes the application configuration information output from the application setting unit 12 and generates a context indicating a usage mode such as a usage method or usage environment of the device 2 used for the application 121. . Then, the context analysis unit 13 generates a context handler 131 including the generated context (Step S103).

  FIG. 9 is a diagram illustrating a configuration example of the context handler 131.

  As shown in FIG. 9, the context handler 131 has a configuration in which an application ID, a user name of a primary user who uses the application, a device name, an API name, a context, and an expiration date are associated with each other. . In FIG. 9, as an example, “setting” and “label” in the application configuration information of the application with the application ID “App_00” used by the primary user A in FIG. 8 are analyzed, and the event of the application with the application ID “App_00” is analyzed. An example is shown in which a context handler 131 that outputs a context of “hot room” and “turn on cooling” is generated when it occurs.

  Referring to FIG. 5 again, the context analysis unit 13 sets a link to the context handler 131 generated by analyzing the application configuration information of the application 121 in the application 121 (step S104). As a result, when the “thermostat temperature measurement” that is the if condition of the application with the application ID “App_00” becomes “26 ° C. or higher”, event information is notified to the context handler 131. As described above, an expiration date is set for the context.

  Next, the context analysis unit 13 determines whether or not the expiration date of the set context handler 131 has been exceeded (step S105).

  When it is determined that the context handler 131 has exceeded the expiration date (step S105: Yes), the context analysis unit 13 deletes the context handler 131 that has exceeded the expiration date. Then, the context analysis unit 13 also deletes the context from the entry (registration destination entry) of the device management DB 14 that registers the context (step S106).

  If it is determined that the expiration date of the context has not been exceeded (step S105: No), the context handler 131 determines whether or not event information has been received from the application 121 with the link set (step S107). .

  If it is determined that the event information has not been received (step S107: No), the context handler 131 returns to the process of step S105.

  If it is determined that the event information has been received (step S107: Yes), the context handler 131 sets an attribute symmetrical to the registration target context in the entry (registration destination entry) of the device management DB 14 for registering the context. It is determined whether or not a context (a symmetric context) is registered (step S108). For example, when the context to be registered is “hot room”, the context handler 131 registers a context “cold room” having an attribute symmetrical to the context to be registered in the registration destination entry of the device management DB 14. It is determined whether or not it has been done.

  When it is determined that a symmetric context is registered in the registration destination entry (step S108: Yes), the context handler 131 overwrites the symmetric context with a registration target context (step 109).

  When it is determined that a symmetric context is not registered in the registration destination entry (step S108: No), the context handler 131 adds the registration target context as a new context to the registration destination entry (step S110). ). In this case, as shown in FIG. 7, the context “hot room” is registered in the entry of the device name “thermostat” and API name “temperature measurement” in the device management DB 14, and the device name “cooling / heating appliance” and API name “cooling ON” ”Is registered in the entry“ ”.

  After the process of step S109 or step S110, the context handler 131 returns to the process of step S105. Moreover, after the process of step S106, a series of processes by the primary use functional block group are completed.

  Next, the operation of the secondary usage function block group will be described. FIG. 10 is a flowchart showing the operation of the secondary usage function block group. FIG. 11 schematically shows the flow of processing by the secondary usage functional block group until generation of the secondary usage controller 161. FIG. 12 schematically shows the flow of processing by the secondary usage controller. In FIGS. 11 and 12, bold arrows indicate input / output of data, solid arrows indicate input / output of control signals, and broken arrows indicate input by secondary users.

  The request interpretation unit 15 receives a resource request input by a secondary user (step S201). The input of the resource request may be an input using a natural language, or an input using a GUI (Graphical User Interface) or the like.

  The request interpreter 15 shapes the input resource request into a format that can be recognized by the device management apparatus 10, and acquires various settings from the resource request after shaping (step S202). In the following, as shown in FIG. 13, the key “context: hot room”, usage type “indirect sensor”, schedule setting “polling: hourly”, endpoint setting “secondary user X's” Assume that "Address" has been set.

  Referring back to FIG. 10, the secondary usage controller management unit 16 generates the secondary usage controller 161 based on the resource request acquired by the request interpretation unit 15.

  FIG. 14 is a diagram illustrating a configuration example of the secondary usage controller 161 generated in response to the resource request illustrated in FIG. As shown in FIG. 14, the secondary usage pointer “c_X_00” that can identify the secondary usage controller 161, the secondary user's user name, the key “context: hot room”, and the usage type “indirect sensor” The schedule setting “polling: hourly” and the endpoint setting “secondary user X address” are set. The secondary usage controller management unit 16 registers the generated secondary usage pointer “c_X_00” and key of the secondary usage controller 161 in the secondary usage pointer DB 17 (step S203).

  FIG. 15 is a diagram illustrating a configuration example of the secondary usage pointer DB 17. As shown in FIG. 15, the secondary usage pointer DB 17 stores a secondary usage pointer, a key, and a device management DB pointer in association with each other. In the example illustrated in FIG. 15, the secondary usage controller management unit 16 corresponds to the generated secondary usage pointer “c_X_00” of the secondary usage controller 161 with the key “context: hot room” set in the resource request. sign up.

  The processing from step S201 to S203 described above corresponds to the flow of processing up to the generation of the secondary usage controller 161 shown in FIG. The subsequent processing corresponds to the processing flow by the secondary usage controller 161 shown in FIG. In the following, it is assumed that information as shown in FIG. 16 is stored in the device management DB 14.

  Referring to FIG. 10 again, the secondary usage controller 161 determines whether or not the timing scheduled in the schedule setting has come (step S204). For example, in the case of the schedule setting “polling: hourly”, the secondary usage controller 161 performs polling every hour and enters a standby state until the polling execution timing.

  When it is determined that the scheduled timing has not come (step S204: No), the secondary usage controller 161 repeats the process of step S204.

  If it is determined that the scheduled timing has come (step S204: Yes), the secondary usage controller 161 searches the device management DB 14 using the key set in the entry of the corresponding secondary usage pointer DB 17. (Step S205). In the example illustrated in FIG. 15, the secondary usage controller 161 searches the device management DB 14 using “context: hot room” as a key.

  When the device management DB 14 shown in FIG. 16 is searched using “context: hot room” as a key, the entry of the pointer “d_A_01” and the entry of the pointer “d_B_02” are hit because the context is “hot room”. As shown in FIG. 15, the secondary usage controller 161 registers the pointers “d_A_01” and “d_B — 02” of the hit entry in the device management DB pointer of the entry of the secondary usage pointer “c_X_00” of the secondary usage pointer DB17. .

  Next, the secondary usage controller 161 determines whether or not the usage format is “indirect sensor” (step S206).

  When it is determined that the usage format is “indirect sensor” (step S206: Yes), the secondary usage controller 161 searches the device management DB 14 and stores information on the hit entry as shown in FIG. The message is transmitted to the address of the secondary user X set in the point setting (step S207).

  When it is determined that the usage format is not “indirect sensor” (step S206: No), the secondary usage controller 161 searches the device management DB 14 and refers to the address of the hit entry (step S208).

  Next, the secondary usage controller 161 determines whether or not the usage format is “direct sensor” (step S209).

  If it is determined that the usage format is “direct sensor” (step S209: Yes), the secondary usage controller 161 sends a control message instructing sensing to the device 2 of the referenced address as shown in FIG. Send. Then, the secondary usage controller 161 acquires data from the sensing device 2 according to the control message (step S210), and transmits the data to the secondary user X address set in the endpoint setting (step S211). .

  When it is determined that the usage format is not “direct sensor” (step S209: No), the secondary usage controller 161 sends a control message instructing the operation to the device 2 of the referenced address as shown in FIG. Transmit and command an action (step S212).

  As described above, in the present embodiment, the device management apparatus 10 is based on the application setting unit 12 in which the application 121 used by the primary user using the device 2 is set, and the application 121 set in the application setting unit 12. A context analysis unit 13 that generates a context indicating a usage mode of the device 2.

  By analyzing the application 121 used by the primary user using the device 2, it is possible to estimate a usage mode such as a usage method and a usage environment of the device 2 by the primary user. Therefore, the device 2 can be managed according to the usage mode of the device 2 by analyzing the application 121 and generating the context of the device 2.

  The device management apparatus 10 also includes a device management DB 14 that stores the device 2 and the context of the device 2 in association with each other, and a request interpreter that acquires a resource request for requesting the use of a desired resource from a secondary user. 15 and a device having a context corresponding to the resource request acquired by the request interpreter 15 is searched from the device management DB 14, and the secondary usage controller 161 that makes the resources of the searched device 2 available in response to the resource request And a secondary usage controller management unit 16 to be generated.

  By searching using the context, the device 2 having the context corresponding to the resource requested by the secondary user can be extracted and provided to the secondary user, and exhaustive IoT resources can be used.

  Further, the resource request includes a schedule setting for instructing the timing to use the resource, and the secondary usage controller 161 uses the resource of the device 2 searched at the timing instructed by the schedule setting included in the resource request. To do.

  In addition, the resource request includes an address part in which an address of an output destination of data from the device 2 or an input source address of an instruction to the device 2 is set, and a control message part in which a control message for the device 2 is set. The secondary usage controller 161 outputs data acquired from the device 2 or inputs a control message to the device according to the endpoint setting.

  Therefore, the secondary user can control the IoT resource at an arbitrary timing and an arbitrary command.

  Although not specifically mentioned in the embodiment, a program for causing a computer to execute each process performed by the device management apparatus 10 may be provided. The program may be recorded on a computer readable medium. If a computer-readable medium is used, it can be installed on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, but may be a recording medium such as a CD-ROM or a DVD-ROM. The program may be provided via a network.

  In the above-described embodiment, the configuration and operation of the device management apparatus 10 have been described. However, the present invention is not limited to this, and the device management apparatus 10 may be configured as a device management method.

  Although the present invention has been described based on the drawings and embodiments, it should be noted that those skilled in the art can easily make various variations or modifications based on the present disclosure. Therefore, it should be noted that these variations or modifications are included in the scope of the present invention. For example, functions included in each block or the like can be rearranged so that there is no logical contradiction, and a plurality of blocks can be combined into one or divided.

1 IoT resource management system 2 Device 3 API
DESCRIPTION OF SYMBOLS 10 Device management apparatus 11 Device management part 12 Application setting part 121 Application 122 Controller 122a Input controller 122b Output controller 13 Context analysis part 131 Context handler 14 Device management DB
15 Request interpretation part (request acquisition part)
16 Secondary Usage Controller Manager 161 Secondary Usage Controller 162 Secondary Usage Pointer 163 Scheduler 164 Endpoint 17 Secondary Usage Pointer DB

Claims (7)

A device management apparatus for managing devices owned by a primary user,
An application setting unit in which an application to be used by the primary user using the device is set;
A device management apparatus comprising: a context analysis unit that generates a context indicating a usage mode of the device by the primary user based on an application set in the application setting unit. The device management apparatus according to claim 1,
A device management DB for storing the device and the context of the device in association with each other;
A request acquisition unit that acquires a resource request for requesting use of a desired resource from a secondary user who requests use of the resource of the device;
A device having a context corresponding to the resource request acquired by the request acquisition unit is searched from the device management DB, and a secondary usage controller that makes available the resource of the searched device according to the resource request is generated. A device management apparatus, further comprising a secondary usage controller management unit. The device management apparatus according to claim 2,
The resource request includes a schedule setting that indicates the timing of using the resource,
The device management apparatus, wherein the secondary usage controller uses the resource of the searched device at a timing indicated by a schedule setting included in the resource request. The device management apparatus according to claim 2 or 3,
The resource request includes an address portion in which an output destination address of data from the device or an instruction input source address to the device is set, and a control message portion in which a control message for the device is set. Includes endpoint settings,
The secondary usage controller outputs data acquired from the device or inputs the control message to the device according to the endpoint setting. A device management method in a device management apparatus for managing devices owned by a primary user,
Setting an application to be used by the primary user using the device;
Generating a context indicating a usage mode of the device by the primary user based on the set application. The device management method according to claim 5,
Storing the device and the context of the device in association with each other;
Obtaining a resource request for requesting use of a desired resource from a secondary user requesting use of the resource of the device;
A secondary usage controller that stores a device having a context corresponding to the acquired resource request in association with the context, searches the device, and uses the resource of the searched device in response to the resource request. And a step of generating a device management method.   The program for functioning a computer as a device management apparatus as described in any one of Claim 1 to 4.

Images