WO2017159009A1 - データフロー制御装置およびデータフロー制御方法 - Google Patents

データフロー制御装置およびデータフロー制御方法 Download PDF

Info

Publication number
WO2017159009A1
WO2017159009A1 PCT/JP2017/000577 JP2017000577W WO2017159009A1 WO 2017159009 A1 WO2017159009 A1 WO 2017159009A1 JP 2017000577 W JP2017000577 W JP 2017000577W WO 2017159009 A1 WO2017159009 A1 WO 2017159009A1
Authority
WO
WIPO (PCT)
Prior art keywords
side metadata
application
data
matching
metadata
Prior art date
Application number
PCT/JP2017/000577
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 US16/084,549 priority Critical patent/US10334420B2/en
Priority to EP17766017.2A priority patent/EP3432593B1/en
Publication of WO2017159009A1 publication Critical patent/WO2017159009A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q9/00—Arrangements in telecontrol or telemetry systems for selectively calling a substation from a main station, in which substation desired apparatus is selected for applying a control signal thereto or for obtaining measured values therefrom
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S5/00—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations
    • G01S5/0009—Transmission of position information to remote stations
    • G—PHYSICS
    • G08—SIGNALLING
    • G08C—TRANSMISSION SYSTEMS FOR MEASURED VALUES, CONTROL OR SIMILAR SIGNALS
    • G08C15/00—Arrangements characterised by the use of multiplexing for the transmission of a plurality of signals over a common path
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/22—Platooning, i.e. convoy of communicating vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M11/00—Telephonic communication systems specially adapted for combination with other electrical systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/04—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration using triggered events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2209/00—Arrangements in telecontrol or telemetry systems
    • H04Q2209/30—Arrangements in telecontrol or telemetry systems using a wired architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2209/00—Arrangements in telecontrol or telemetry systems
    • H04Q2209/40—Arrangements in telecontrol or telemetry systems using a wireless architecture

Definitions

  • the present invention relates to a technique for controlling a data flow that provides data obtained in a device such as a sensor to an application that uses the data.
  • M2M Machine to Machine
  • M2M cloud Such an M2M technology realized on a cloud computing environment is called an M2M cloud.
  • This provides basic functions required for M2M, such as services such as data collection and storage, processing, and analysis as applications on the cloud, making them available from anywhere. Reliability and completeness can be improved by collective management of data.
  • the user has an advantage that the collected data and computer resources can be used as much as necessary. Therefore, it is possible to analyze big data and obtain added value without building a system individually, and applications in a wide range of fields are expected.
  • Patent Document 1 a technique called a sensor network has been studied. This is because sensor devices that have a sensing function and a communication function (hereinafter also referred to simply as “sensors”) are installed in various locations, mobile objects, industrial facilities, etc., and they are networked to collect sensing data. Management and seamless use are possible.
  • sensor devices that have a sensing function and a communication function (hereinafter also referred to simply as “sensors”) are installed in various locations, mobile objects, industrial facilities, etc., and they are networked to collect sensing data. Management and seamless use are possible.
  • sensors are installed to collect data that the owners themselves need. Therefore, it is often not used except when the owner collects data (the sensor itself is not operating, or sensing data is not used even if the sensor is operating). For this reason, the distribution of sensing data is low, and no matter how meaningful the data is for a third party, the sensor owner himself has only analyzed and used it. As a result, redundant investment of equipment and network congestion due to communication with sensors installed by each person have been invited.
  • IoT Internet of Things
  • JP 2007-300571 A Japanese Patent No. 5445722
  • the applicants are diligently studying a technique for appropriately distributing information resources such as sensing data in the sensor network. For example, by appropriately matching data describing information about sensors with data describing information about applications that use sensing data, connect users who want to provide sensing data with users who want to use sensing data. (See Patent Document 2). Thereby, for example, the owner of the sensor can obtain compensation by permitting the data user to temporarily use the sensor or providing sensing data. For the user, there is an advantage that necessary data can be obtained at a low cost because investment for installing the sensor is unnecessary.
  • any device other than the sensor may be any device that outputs some data, such as an actuator, a controller, a computer, a household appliance, a wearable terminal, an automatic ticket gate, a vendor machine, and an ATM.
  • the term “device” is used as a concept including these devices (including sensors), and a network that distributes data output (provided) by such a device is referred to as a “device network”.
  • Various types of devices exemplified above may be mixedly connected to the device network.
  • the present invention has been made in view of the above circumstances, and an object thereof is to improve the establishment rate of a pair in a device network that matches a data provider and a data user.
  • the data flow control device is: For each of a plurality of devices, a device-side metadata acquisition unit that acquires device-side metadata indicating the specifications of data that can be provided by the device, and an application that uses the data provided by the device, Application-side metadata acquisition means for acquiring application-side metadata indicating specifications, storage means for storing the device-side metadata and application-side metadata, and either one of the device-side metadata or application-side metadata When newly registered, the registered device-side metadata or application-side metadata and the registered partner-side metadata that is registered before the registered device-side metadata or application-side metadata and matches the matching conditions Device-side metadata or A temporary matching unit that determines whether or not a temporary pair that is a pair with the re-side metadata exists, and that notifies the user who registered the device-side metadata or application-side metadata of the determination result; It is characterized by having.
  • the data flow control device performs a matching process between the application-side metadata and the device-side metadata, thereby providing the application and a device capable of providing data satisfying the specifications required by the application.
  • the notification may be executed prior to the matching process.
  • the temporary matching unit may notify the user whether to perform a matching process after notifying the result of the determination.
  • the temporary matching unit causes the user to select whether or not to maintain the temporary pair, and when there is an answer to maintain the temporary pair, Data indicating that a temporary pair is maintained may be added to the corresponding device-side metadata and application-side metadata.
  • pairing when a temporary pair exists, pairing can be maintained based on a user instruction. Thereby, it is possible to prevent the counterpart device (application) from being paired with another user's application (device) first.
  • the matching unit preferentially extracts a combination of a device and an application corresponding to the device-side metadata and the application-side metadata to which data indicating that the temporary pair is maintained is added, respectively. Also good.
  • metadata in which a temporary pair is established can be transferred to a formal combination.
  • the device-side metadata includes one or more items indicating specifications of data that can be provided by the device
  • the application-side metadata includes one or more items indicating specifications of data requested by the application.
  • the matching means includes a device and an application respectively corresponding to the device-side metadata and the application-side metadata when all the items to be matched among the items of the device-side metadata and the application-side metadata match. It is good also as extracting the combination with.
  • the device may be a sensor that outputs sensing data.
  • the data flow control device according to the present invention can be suitably applied to a sensor network composed of a data provider that provides sensing data and a data user that uses sensing data.
  • the present invention can be specified as a data flow control device including at least a part of the above means.
  • the present invention can also be specified as a device network system having the data flow control device.
  • the present invention can also be specified as a data flow control method including at least a part of the above processing.
  • the present invention can also be specified as a program that causes a computer to execute the above method.
  • the above processes and means can be freely combined and implemented as long as no technical contradiction occurs.
  • Device in the present invention means any device that outputs (provides) some data, and examples include sensors, actuators, controllers, computers, home appliances, wearable terminals, automatic ticket gates, vendor machines, ATMs, and the like.
  • the present invention is suitable for a sensor network that distributes sensing data output from a sensor.
  • the establishment rate of a pair can be improved in a device network that matches a data provider and a data user.
  • 1 is a configuration diagram of a sensor network system according to an embodiment. It is an example of the table which memorize
  • This sensor network system is a system for controlling the flow of sensing data from a data provider to a data user, and includes a plurality of sensors 21 and a sensor network adapter 22 that is a device that manages the sensors 21. And an application server 30 having an application for providing a service using sensing data, and a data flow control device that acts as an intermediary between a sensing data provider (hereinafter referred to as a data provider) and a user (hereinafter referred to as a data user) As a sensor network server 10.
  • a sensing data provider hereinafter referred to as a data provider
  • a data user hereinafter referred to as a data user
  • a sensor network server 10 As a sensor network server 10.
  • one sensor device 20 and one application server 30 are illustrated, but there may be a plurality of sensor devices 20 and application servers 30.
  • Each device is connected to be communicable by a wide area network such as the Internet or a LAN.
  • the network is not limited to a single network, and may be considered as a conceptual network in which a plurality of networks having various communication methods and topologies are connected to each other.
  • any form of network may be used as long as transmission / reception of sensing data and transmission / reception of data related to the distribution of sensing data and data such as data flow control commands can be realized.
  • the sensor 21 is a device that detects a physical quantity to be sensed and its change and outputs it as sensing data.
  • the sensor include an image sensor (such as a surveillance camera), a temperature sensor, a humidity sensor, an illuminance sensor, a force sensor, a sound sensor, an RFID sensor, an infrared sensor, a posture sensor, a rainfall sensor, a radiation sensor, a gas sensor, an acceleration sensor, and a gyro.
  • a scope, a GPS sensor, etc. correspond.
  • devices such as mobile phones, smartphones, tablet terminals, mobile PCs, and drones are equipped with various types of sensors, these devices can be handled as sensors.
  • any type of sensor including the sensors exemplified here can be connected to the sensor network system of this embodiment.
  • Many sensors have already been installed in various places in the world, such as factory FA, production management, urban traffic control, weather measurement, health care, crime prevention, etc. Can also be connected to the system.
  • the sensor network system may be configured with only one type of sensor, or a plurality of types of sensors may be mixed.
  • the sensor network adapter 22 is communicably connected to one or a plurality of sensors 21 by wire or wirelessly, manages the sensor 21, acquires sensing data from the sensor 21, and transmits sensing data to the sensor network system or application. It is a device that performs.
  • the sensor network adapter 22 may have a function of performing predetermined processing (for example, signal processing such as noise removal, calculation such as averaging processing, sampling, data compression, time stamp, and the like) on the sensing data.
  • the sensor network adapter 22 has a communication function with an external device, and can communicate with the application server 30, the sensor network server 10, and the like via a network.
  • Devices such as smartphones, tablet terminals, mobile PCs, drones, and wearable terminals have built-in sensors such as image sensors, GPS sensors, acceleration sensors, and microphones, and function to process and output data obtained by each sensor and network communication It has a function. Therefore, these devices are examples of devices in which the sensor 21 and the sensor network adapter 22 are physically integrated. When the sensor 21 has a built-in communication function, it can be connected to the sensor network system alone (that is, without going through the sensor network adapter 22).
  • the application server 30 is a server device in which various application programs that provide services using sensing data are installed.
  • the application server 30 can be configured by a general-purpose computer including a CPU (processor), a memory, an auxiliary storage device (HDD or the like), a communication device, an input device, a display device, and the like.
  • the application server 30 is installed by a user of sensing data, and various applications are assumed depending on the use / purpose.
  • a traffic jam map is generated by collecting traffic conditions at each point from a sensor installed on a road, an in-vehicle terminal mounted on a vehicle traveling on the road, or a driver's smartphone.
  • An application to be provided to a business operator who uses traffic information can be considered.
  • it collects image data taken while driving with a smartphone or in-vehicle camera, etc., and searches for the driving route of the vehicle based on video distribution application provided to users who want to know the situation at each point, traffic jam information, etc.
  • Route search application application that estimates passerby attributes (gender, age group, etc.) from camera images installed at a specific location, and provides them as data for various surveys, already sold by sensor manufacturers
  • Various applications such as online maintenance of in-house sensors can be considered.
  • the sensor network server 10 is a server device responsible for matching between a sensing data provider and a user, data flow control of sensing data from the provider to the user, and the like, and is one of the data flow control devices according to the present invention. It is a specific example.
  • the sensor network server 10 can also be configured by a general-purpose computer including a CPU (processor), a memory, an auxiliary storage device (HDD or the like), a communication device, an input device, a display device, and the like.
  • Various functions of the sensor network server 10 to be described later are realized by the CPU executing necessary programs.
  • a large number (or a wide variety) of sensors are networked to enable collection and use of sensing data.
  • a data provider (sensor 21) is a data user (sensor 21).
  • a mechanism is assumed in which sensing data is provided to the application server 30) to obtain compensation.
  • the sensor network server 10 is a server device that mediates such a sensing data transaction, and performs matching between the data provider and the data user to realize appropriate distribution of the sensing data.
  • this system prepares metadata (sensor side metadata) that describes the specifications and provision conditions of sensing data for all sensors registered in the sensor network, and for applications that are data users, Metadata describing the required specifications and usage conditions of sensing data (hereinafter, application-side metadata) is used. Then, by comparing the metadata, appropriate matching between the data provider (sensor) and the user (application) is performed.
  • metadata sensor side metadata
  • application-side metadata Metadata describing the required specifications and usage conditions of sensing data
  • the sensor network server 10 includes a storage unit 11, a matching unit 12, a temporary matching unit 13, an input / output unit 14, and a data flow control unit 15.
  • the storage unit 11 is a database that stores application-side metadata corresponding to all applications registered in the sensor network and sensor-side metadata corresponding to all sensors registered in the sensor network.
  • the matching unit 12 performs matching between the application-side metadata registered in the storage unit 11 and the sensor-side metadata, extracts sensors that can provide sensing data that satisfies the application requirements, and generates a sensor-application pair. Means for performing pairing.
  • the provisional matching unit 13 is a means for confirming whether there is metadata that can be a pairing candidate for newly registered sensor-side metadata or application-side metadata, and providing information to the user. is there. Details of the matching unit 12 and the temporary matching unit 13 will be described later.
  • the input / output unit 14 is an interface unit for acquiring sensor-side metadata or application-side metadata to be registered.
  • the input / output unit 14 is hardware that communicates with an external computer via a wired or wireless connection.
  • the input / output unit 14 may include a display device and a human interface device (such as a keyboard and a mouse). In this case, there is no need to communicate with an external computer. In either case, information can be provided to the user via the input / output unit 14 and information can be acquired from the user.
  • the data flow control unit 15 has a function of generating and transmitting a data flow control command for instructing transmission of sensing data based on information output from the matching unit 12. Details of these functions will be described later.
  • FIG. 2A is an example of sensor side metadata stored in the storage unit 11 in a table format.
  • the sensor side metadata is metadata describing attribute information of the sensor, information indicating the specifications of sensing data that can be provided by the sensor, information indicating conditions for providing sensing data, and the like.
  • the sensor attribute information may include, for example, an ID for identifying the sensor, a sensor type, a sensor network address, a sensor operation history, and the like.
  • As the network address for example, an IP address, a MAC address, a URI (Uniform Resource Identifier), or the like can be used.
  • Information indicating the specifications of the sensing data includes, for example, the sensing target (that is, what is to be sensed), the sensing location and area (eg, position, range, etc.), sensing time (time and time zone at which sensing data can be obtained) Include the data type of sensing data (eg: image, video, temperature, etc.), data format (eg: JPEG, text, etc.), sensing conditions (eg: shutter speed, resolution, sampling cycle, etc.), data reliability, etc. be able to.
  • the information indicating the provision conditions of the sensing data is information indicating the transaction conditions desired by the data provider. For example, an ID for identifying the data provider, consideration (data provision price), usage range / purpose of use (example: Commercial use, secondary use, etc.) can be included.
  • Data history information is information that represents the origin, history, origin, origin, feature, history, history, responsible person, etc. of the sensing data, and is an objective to judge the accuracy, quality, reliability, safety, etc. of the sensing data. Any information may be used as long as the information can be a material.
  • the temporary matching flag is a flag indicating whether or not the metadata is metadata for which temporary matching is permitted.
  • the temporary pair maintenance flag is a flag indicating whether or not to maintain a temporary pair generated by temporary matching. Details of both flags will be described later.
  • FIG. 2B is an example of application-side metadata stored in the storage unit 11 in a table format.
  • the application-side metadata is metadata describing application attribute information, information indicating sensing data specifications (requested specifications) required by the application, information indicating sensing data usage conditions, and the like.
  • the application attribute information may include, for example, an ID for identifying the application, the type of the application, the network address of the application, and the like. For example, an IP address or a port number can be used as the network address.
  • the information indicating the required specification of the sensing data can include, for example, a sensing target, a sensing area, a sensing time, a sensing data type, a data format, a sensing condition, a data reliability, and the like.
  • the information indicating the usage conditions is information indicating the transaction conditions desired by the data user, and includes, for example, an ID for identifying the data user, a consideration (upper limit of the data usage price), a usage range, a usage purpose, and the like. be able to.
  • Data history information can also be described in the metadata on the application side. Since the content of the data history information is the same as the information described in the sensor side metadata, the description is omitted. However, the data history information about the sensing data to be provided is described in the sensor side metadata, whereas the data history information required by the application is described in the application side metadata. Therefore, a plurality of data history information allowed by the application can be described in the application-side metadata.
  • the application side metadata also has a temporary matching flag and a temporary pair maintenance flag.
  • the contents of the flag are the same as the device side metadata.
  • FIG. 3 shows an example of a screen displayed when the data provider newly registers sensor-side metadata.
  • the screen is generated by the input / output unit 14 and output to the computer of the data provider connected to the input / output unit 14.
  • the user after inputting the content of the metadata, the user selects “normal registration” or “provisional matching execution”.
  • the input metadata is registered in the storage unit 11 and matching is started.
  • the sensor network server 10 (1) performs a pairing of metadata registered in the storage unit 11 and generates a data flow from the sensor to the application when the pair is established. (2)
  • newly registering metadata in the storage unit 11 it has a function of confirming whether the other party metadata that can be a pairing candidate is registered and notifying the user.
  • the former is referred to as “normal matching” and the latter is referred to as “temporary matching”.
  • sensor-side metadata waiting for processing is acquired one by one from the sensor-side metadata table of the storage unit 11 (step S11).
  • one application side metadata is acquired from the application side metadata table which the memory
  • step S13 whether or not the sensing data specifications and transaction conditions (providing conditions) specified in the app-side metadata satisfy the sensing data requirements and transaction conditions (use conditions) specified in the sensor-side metadata Determine.
  • the comparison target items included in the sensor side metadata and the application side metadata are matched, the pair is established, and when they are not matched, the pair is not established (step S13). It should be noted that it is not always necessary to determine whether or not the conditions are matched based on complete wording. For example, if the sensing location is “Kyoto City” on the sensor side and “Kyoto Station” on the application side, it is determined that the two match.
  • step S13 When a pair is established in step S13, the application-side metadata acquired in step S12 is extracted as one of the final pair candidates (step S14). The processes in steps S12 to S14 are executed for all application metadata registered in the application metadata table (step S15).
  • step S16 the number of application-side metadata extracted as candidates is determined.
  • the matching unit 12 selects the most advantageous for the data provider from among the plurality of candidates (step S17). For example, in the case of consideration priority, the data with the highest price may be selected. The criteria for selecting the most advantageous application for the data provider can be set as appropriate. If there is no application-side metadata extracted as a candidate, the processing may be terminated, or the closest data specification, transaction condition, and data history information may be recommended. Further, after the predetermined time has elapsed, the processing shown in FIG. 4 may be executed again.
  • the data flow control unit 15 generates a data flow control command for instructing the target sensor to transmit sensing data, and sends the data flow control command to the sensor network adapter 22 that manages the sensor 21. It transmits to (step S18). Then, as shown in FIG. 1, the sensor network adapter 22 acquires necessary sensing data from the sensor 21 based on the data flow control command, and transmits it to the corresponding application server 30.
  • the data flow control command includes a data flow control command ID, information for identifying a sensor (sensor ID, sensor network address), information for identifying an application (application ID, network address of the application), and time information for performing data transmission. However, information other than this may be included.
  • the comparison target item included in the sensor side metadata and the comparison target item included in the application side metadata must match. That is, if even one item does not match, no pair is established.
  • the sensor network server 10 Prior to normal matching, the sensor network server 10 according to the present embodiment determines whether or not there is counterpart metadata that can be paired under the currently input conditions, and notifies the user of the problem. Has solved. This process is called temporary matching.
  • provisional matching When the user who has input information presses “provisional matching execution” on the screen illustrated in FIG. 3, provisional matching is performed. Temporary matching is a process performed by the temporary matching unit 13 and is a process of trying matching before normal matching is performed and notifying the user of whether or not matching metadata exists. In provisional matching, data flow control is not performed even when a matching partner is found.
  • FIG. 5 is a flowchart of the provisional matching process. The process shown in FIG. 5 is executed when the user presses the provisional matching execution button.
  • step S21 sensor-side metadata input by the user is acquired.
  • the sensor side metadata is registered in the storage unit 11 in step S22.
  • the temporary matching flag is set to ON, and the temporary pair maintenance flag is set to OFF.
  • the temporary matching flag is a flag indicating whether or not the metadata is metadata for which temporary matching is permitted. The temporary pair maintenance flag will be described later.
  • step S23 it is determined whether there is application-side metadata to be provisionally matched. That is, a record whose temporary matching flag is ON is extracted from the application side metadata table. If the result does not exist, notification is made that there is no provisional matching partner (step S28), and the provisional matching process ends.
  • step S24 a search is made for items in which the comparison target item matches the condition input by the user (matching matching condition) from the application side metadata whose temporary matching flag is ON. For example, as shown in FIG. 6, it is assumed that only five items have been input in the sensor-side metadata newly input. In this case, matching is tried using only the five input items. As a result, if there is matching application-side metadata, the user is notified that there is a pairing candidate (step S25). Hereinafter, a pair established in the provisional matching is referred to as a provisional pair. If there is no matching application-side metadata, the user is notified that there is no pairing candidate (step S29), and the process ends.
  • the input sensor-side metadata may be deleted. By doing so, it is possible to change the condition and try provisional matching again. Further, when the input sensor side metadata is not deleted, it may be selected whether the temporary matching flag is kept ON or changed to OFF. For example, by leaving the temporary matching flag ON, it is possible to receive temporary matching with respect to metadata registered by others, so that it can be expected that opportunities for establishing a device-application pair will increase.
  • FIG. 7 is an example of a screen provided to the user when a temporary pair is established in step S25.
  • the first is a method of shifting to normal registration by using the result of provisional matching as a reference only.
  • the provisional matching process ends, and the process proceeds to the above-described normal matching (step S26—No).
  • the process of FIG. 3 may be started immediately, or when the process of FIG. 3 is periodically performed, the process start may be awaited.
  • shifting to the normal matching it may be selected whether the temporary matching flag is kept ON or changed to OFF.
  • the second method is to secure the partner metadata found by temporary matching on the spot. Since the normal matching is executed at a timing independent of the temporary matching, there is a possibility that the partner that has been hit by the temporary matching is paired with the metadata of another person. Therefore, when the temporary pair is established, the sensor network server 10 according to the present embodiment causes the user to select whether or not to maintain the temporary pair. Here, when the user presses “maintenance registration” on the screen, both the temporary pair maintenance flags of the corresponding metadata are turned ON (step S27).
  • the matching unit 12 when performing the normal matching (step S12), the matching unit 12 does not acquire the metadata whose temporary pair maintenance flag is ON, and performs pairing separately with priority.
  • the temporary pair maintenance flag is used, but information (for example, sensor ID and application ID) for specifying the partner with whom the temporary pair is established may be held.
  • the third method is to cancel the registration itself.
  • the sensor network server determines whether or not there is counterpart metadata that hits under the currently input conditions prior to normal matching. Confirm and notify the user.
  • Temporary matching can be performed under fewer conditions than normal matching. Thereby, the user can consider more preferable conditions based on the result of provisional matching.
  • any one may be selected by a predetermined method. For example, a data provider that has the best conditions may be selected. Also, the result of the temporary matching may be notified only of whether or not a temporary pair partner exists, or may be simultaneously notified of the number of provisional pairs established. In addition, the sensor-side metadata and the application-side metadata that have been paired may be deleted from the storage unit 11, or a flag indicating that a contract has been established is given and removed from the matching target until the contract is canceled. It may be.
  • step S17 the candidate of the other party metadata is selected based on the advantage for the data provider.
  • this method is an example, and the candidate is selected based on other conditions. May be.
  • the normal matching process illustrated in FIG. 4 is performed with the sensor side metadata newly registered as a trigger.
  • the application side metadata is newly registered. This may be executed as a trigger.
  • a sensor and an application, a data provider, and a data user may be read.
  • the normal matching process is executed at the timing when the metadata is registered. However, the normal matching process may be executed periodically.
  • the distribution of sensing data in the sensor network is exemplified, but the present invention can also be applied to the distribution of data in a device network including devices other than sensors.
  • the basic configuration of the system is the same as that of the above embodiment, and “sensor” in the above embodiment may be read as “device” and “sensing data” may be read as “data”.
  • a data flow control device comprising a memory and at least one hardware processor connected to the memory,
  • the memory is Device-side metadata storage means for storing device-side metadata indicating specifications of data that can be provided by the device for each of the plurality of devices;
  • Application-side metadata storage means for storing application-side metadata indicating the specification of data requested by the application for applications that use data provided by the device;
  • the at least one hardware processor is: When either the device-side metadata or application-side metadata is newly registered in the memory, the registered device-side metadata or application-side metadata and the registered device-side metadata or It is determined whether there is a temporary pair that is registered before the app-side metadata and that is a pair with the device-side metadata or app-side metadata on the other side that matches the matching condition.
  • a data flow control device for notifying a user who has registered the device side metadata or application side metadata.
  • Appendix 2 A data flow control method comprising: With at least one hardware processor For each of a plurality of devices, a device side metadata acquisition step for acquiring device side metadata indicating specifications of data that can be provided by the device; For an application that uses data provided by the device, an application-side metadata acquisition step that acquires application-side metadata indicating data specifications requested by the application; A storage step of storing the device side metadata and application side metadata; When either the device-side metadata or the application-side metadata is newly registered, the registered device-side metadata or application-side metadata and the registered device-side metadata or application-side metadata are registered.
  • the data flow control method characterized by performing.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Telephonic Communication Services (AREA)
  • Selective Calling Equipment (AREA)

Abstract

複数のデバイスについてデバイス側メタデータを取得するデバイス側メタデータ取得手段と、デバイスが提供するデータを利用するアプリケーションについてアプリ側メタデータを取得するアプリ側メタデータ取得手段と、各メタデータを記憶する記憶手段と、デバイス側メタデータあるいはアプリ側メタデータのどちらか一方が新規に登録された場合に、登録されたデバイス側メタデータあるいはアプリ側メタデータと、前記登録されたデバイス側メタデータあるいはアプリ側メタデータよりも先に登録され、マッチング条件が合致する相手側のデバイス側メタデータあるいはアプリ側メタデータとの組である仮ペアが存在するか否かを判定し、通知する仮マッチング手段と、を有する。

Description

データフロー制御装置およびデータフロー制御方法
　本発明は、センサなどのデバイスにおいて得られるデータを、当該データを利用するアプリケーションへと提供するデータフローを制御するための技術に関する。
　現在、Ｍ２Ｍクラウドと呼ばれるＩＴ環境が注目を集めている。Ｍ２Ｍ（Ｍａｃｈｉｎｅ　ｔｏ　Ｍａｃｈｉｎｅ）とは、様々な用途、大きさや性能を持つ機械同士がネットワーク上で情報をやり取りするシステムを指す。この情報を利用することで、それぞれの機械の適切な制御や、実社会の状況解析が可能になる。Ｍ２Ｍを支える無線通信技術の向上や機械の小型化、低廉化などにより、実用化への期待が高まっている。
　このようなＭ２Ｍの技術をクラウドコンピューティング環境上で実現したものはＭ２Ｍクラウドと呼ばれる。これは、Ｍ２Ｍに必要な基本機能、例えばデータの収集蓄積から加工、分析のようなサービスをクラウド上のアプリケーションとして提供し、どこからでも利用可能にしたものである。データの一括管理によって信頼性や網羅性を高めることができる。また利用者にとっては、収集されたデータやコンピュータ資源を必要な分だけ利用できるメリットがある。そのため、個別にシステムを構築することなくビッグデータを解析して付加価値を得ることが可能であり、幅広い分野での応用が期待されている。
　また、特許文献１に示すように、センサネットワークと呼ばれる技術が検討されている。これは、センシング機能と通信機能をもつセンサデバイス（以下、単に「センサ」とも呼ぶ）を様々な場所、移動体、産業設備などに設置し、それらをネットワーク化することで、センシングデータの収集、管理、シームレスな利用を可能とするものである。
　通常、センサは、その所有者自身が必要とするデータを収集するために設置される。そのため所有者がデータ収集を行うとき以外は利用されていない（センサ自体が稼働していない、またはセンサが稼働していてもセンシングデータが利用されない）ことが多い。そのためセンシングデータの流通性は低く、第三者にとっていかに有意義なデータであっても、センサの所有者自身による分析、利用に留まっていた。その結果、設備の重複投資や、各自が設置したセンサとの通信によるネットワークの輻湊を招いていた。
　また、ＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇｓ）という技術が検討されている。これは、世界に存在する多くの物に関する情報をネット上で組み合わせることで新しい価値を生むもので、社会インフラを始めとする様々なサービスのシームレスな展開が期待されている。ＩｏＴから価値を生み出すためには、ネットに繋がる物の状態を知る必要があり、センシングと通信が重要な要素技術となる。
特開２００７－３００５７１号公報 特許第５４４５７２２号公報
  出願人らはさらに、センサネットワークにおいて、センシングデータなどの情報資源を適切に流通させるための技術について鋭意検討している。例えば、センサに関する情報が記述されたデータと、センシングデータを利用するアプリケーションに関する情報が記述されたデータを適切にマッチングさせることで、センシングデータを提供したいユーザと、センシングデータを利用したいユーザとを結びつけることができる（特許文献２参照）。
　これにより、例えばセンサの所有者は、データ利用者に対してセンサの一時利用を許可したりセンシングデータを提供したりすることで対価を得られる。また利用者にとっては、センサを設置する投資が不要なため安価に必要なデータを得ることができるというメリットがある。
　特許文献２に記載の発明では、センサに対応するメタデータと、当該センシングデータを利用するアプリケーションに対応するメタデータを用いてマッチングを行い、センサとアプリケーションのペアを生成している。しかし、各メタデータには、センサ自体の属性情報、センシング対象の属性情報、センシング動作の属性情報などが数多く含まれており、これらが完全に一致しないとペアが成立しない。すなわち、登録されているメタデータの数によっては、センサとアプリケーションが結びつかないという課題があった。
　この課題を解決するためには、どのように条件を設定すればペアが成立しやすいかという情報をユーザに提供する必要がある。
　なお、ここまでセンサネットワークを例に挙げて説明をしたが、センサ以外の装置が出力（提供）するデータを流通させるネットワークにおいても、全く同様の課題が発生し得る。センサ以外の装置としては、例えば、アクチュエータ、コントローラ、コンピュータ、家電製品、ウェアラブル端末、自動改札機、ベンダマシン、ＡＴＭなど、何らかのデータを出力する装置であればどのような物も該当し得る。本明細書では、これらの装置（センサも含む）を包含する概念として「デバイス」という用語を用い、このようなデバイスが出力（提供）するデータを流通させるネットワークを「デバイスネットワーク」と呼ぶ。デバイスネットワークには、上に例示した様々な種類のデバイスが混在して接続されることもあり得る。
　本発明は上記実情に鑑みなされたものであり、データ提供者とデータ利用者とをマッチングさせるデバイスネットワークにおいて、ペアの成立率を向上させることを目的とする。
　本発明に係るデータフロー制御装置は、
　複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示すデバイス側メタデータを取得するデバイス側メタデータ取得手段と、前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示すアプリ側メタデータを取得するアプリ側メタデータ取得手段と、前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶手段と、前記デバイス側メタデータあるいはアプリ側メタデータのどちらか一方が新規に登録された場合に、前記登録されたデバイス側メタデータあるいはアプリ側メタデータと、前記登録されたデバイス側メタデータあるいはアプリ側メタデータよりも先に登録され、マッチング条件が合致する相手側のデバイス側メタデータあるいはアプリ側メタデータとの組である仮ペアが存在するか否かを判定し、前記判定の結果を、前記デバイス側メタデータあるいはアプリ側メタデータを登録したユーザに通知する仮マッチング手段と、を有することを特徴とする。
　かかる構成によると、ユーザがメタデータを新規に登録する際に、アプリケーションの要求する仕様を満たすデータを提供可能なデバイスが存在するか、または、デバイスが提供するデータを必要とするアプリケーションが存在するかを当該ユーザに通知することができる。すなわち、条件をどのように設定すれば、デバイスとアプリケーションのペアが成立しやすいか、ユーザに対して情報を与えることができる。
　また、本発明に係るデータフロー制御装置は、前記アプリ側メタデータと前記デバイス側メタデータのマッチング処理を行うことで、前記アプリケーションと、前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスとの組み合わせを抽出するマッチング手段と、前記マッチング手段により抽出された前記デバイスと前記アプリケーションを特定したデータフロー制御指令を生成するデータフロー制御手段と、をさらに有し、前記仮マッチング手段は、前記判定および通知を、前記マッチング処理に先立って実行することを特徴としてもよい。
　かかる構成によると、正式なマッチングが行われ、データフロー制御指令が生成されるよりも前の段階でユーザに対して情報を提供することができる。
　また、前記仮マッチング手段は、前記判定の結果を通知した後、前記ユーザに対してマッチング処理を行うか否かを選択させることを特徴としてもよい。
　かかる構成によると、判定結果を確認したユーザに対して、メタデータの内容を修正する機会を与えることができる。
　また、前記仮マッチング手段は、前記仮ペアが存在する場合に、前記ユーザに対して当該仮ペアを維持するか否かを選択させ、前記仮ペアを維持する旨の回答があった場合に、該当するデバイス側メタデータおよびアプリ側メタデータに対して、仮ペアを維持する旨を示すデータを付加することを特徴としてもよい。
　かかる構成によると、仮ペアが存在する場合に、ユーザの指示に基づいて、ペアリングを維持させることができる。これにより、相手側のデバイス（アプリケーション）が他ユーザのアプリケーション（デバイス）と先にペアリングされてしまうことを防ぐことができる。
　また、前記マッチング手段は、前記仮ペアを維持する旨を示すデータが付加された前記デバイス側メタデータおよびアプリ側メタデータにそれぞれ対応するデバイスとアプリケーションの組み合わせを優先的に抽出することを特徴としてもよい。
　かかる構成によると、仮ペアが成立したメタデータ同士を、正式な組み合わせに移行させることができる。
　また、前記デバイス側メタデータは、デバイスが提供可能なデータの仕様を示す一つ以上の項目を含み、前記アプリ側メタデータは、アプリケーションが要求するデータの仕様を示す一つ以上の項目を含み、前記マッチング手段は、前記デバイス側メタデータおよびアプリ側メタデータが有する項目のうち、マッチング対象の項目が全て一致した場合に、当該デバイス側メタデータおよびアプリ側メタデータにそれぞれ対応するデバイスとアプリケーションとの組み合わせを抽出することを特徴としてもよい。
　また、前記デバイスは、センシングデータを出力するセンサであることを特徴としてもよい。本発明に係るデータフロー制御装置は、センシングデータを提供するデータ提供者と、センシングデータを利用するデータ利用者とで構成されるセンサネットワークに好適に適用することができる。
　なお、本発明は、上記手段の少なくとも一部を含むデータフロー制御装置として特定することができる。また、本発明は、上記データフロー制御装置を有するデバイスネットワークシステムとして特定することもできる。また、本発明は、上記処理の少なくとも一部を含むデータフロー制御方法として特定することもできる。また、本発明は、コンピュータに上記方法を実行させるプログラムとして特定することもできる。上記処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。
　本発明における「デバイス」は、何らかのデータを出力（提供）するあらゆる装置を意味し、センサ、アクチュエータ、コントローラ、コンピュータ、家電製品、ウェアラブル端末、自動改札機、ベンダマシン、ＡＴＭなどが例示できる。中でも本発明は、センサから出力されるセンシングデータの流通を行うセンサネットワークに好適である。
　本発明によれば、データ提供者とデータ利用者とをマッチングさせるデバイスネットワークにおいて、ペアの成立率を向上させることができる。
実施形態に係るセンサネットワークシステムの構成図である。 センサ側／アプリ側メタデータをそれぞれ記憶するテーブルの例である。 センサ側メタデータを登録する画面の例である。 通常マッチング処理のフローチャート図である。 仮マッチング処理のフローチャート図である。 メタデータ同士のマッチングを説明する図である。 センサ側メタデータを登録する画面の例である。
　以下、本発明の好ましい実施形態について図面を参照しながら説明する。ただし、以下に記載されている各構成の説明は、発明が適用されるシステムの構成や各種条件により適宜変更されるべきものであり、この発明の範囲を以下の記載に限定する趣旨のものではない。
　以下に述べる実施形態では、本発明を、Ｍ２Ｍクラウドを用いたセンサネットワークシステムに適用した例について説明する。かかる仕組みが実現すれば、センサネットワーク上に存在する多数のセンサから得られる多種多様な情報のなかから、所望の情報を誰もがどこからでも容易に取得することができるようになり、センサ（リソース）の有効利用、並びに、データ提供者からデータ利用者へのセンシングデータの流通が促進されると期待される。このシステムは、例えば、交通状況のセンシングデータに基づく交通制御システム、環境のセンシングデータに基づく気象予測システム、ビッグデータを利用した各種分析システム、センサメーカによる販売済みセンサのメンテナンスサービスなど、様々な用途への応用展開が可能である。
　＜システムの全体構成＞
　図１を参照して、本発明の実施形態に係るセンサネットワークシステムの全体的な構成を説明する。このセンサネットワークシステムは、データ提供者からデータ利用者へのセンシングデータの流通を制御するためのシステムであり、複数のセンサ２１およびセンサ２１を管理する装置であるセンサネットワークアダプタ２２からなるセンサ装置２０と、センシングデータを利用してサービスを提供するアプリケーションを有するアプリケーションサーバ３０と、センシングデータの提供者（以下、データ提供者）と利用者（以下、データ利用者）の仲介を担うデータフロー制御装置としてのセンサネットワークサーバ１０とを有している。なお、本例では、センサ装置２０およびアプリケーションサーバ３０を一つずつ例示しているが、センサ装置２０およびアプリケーションサーバ３０は複数あってもよい。
　各装置の間は、インターネット等の広域ネットワーク又はＬＡＮによって通信可能に接続されている。なお、ネットワークは単一のネットワークとは限らず、様々な通信方式やトポロジーをもつ複数のネットワークを相互に接続した概念的なものと考えてもよい。要するに、センシングデータの送受信や、センシングデータの流通に関わるメタデータ及びデータフロー制御指令等のデータの送受信が実現できれば、どのような形態のネットワークを利用してもよい。
　（センサ）
　センサ２１は、センシング対象の物理量やその変化を検出し、センシングデータとして出力するデバイスである。
　センサには、例えば、画像センサ（監視カメラなど）、温度センサ、湿度センサ、照度センサ、力センサ、音センサ、ＲＦＩＤセンサ、赤外線センサ、姿勢センサ、降雨センサ、放射線センサ、ガスセンサ、加速度センサ、ジャイロスコープ、ＧＰＳセンサなどが該当する。また、携帯電話、スマートフォン、タブレット端末、モバイルＰＣ、ドローンなどの機器は様々な種類のセンサを搭載しているため、これらの機器をセンサとして取り扱うこともできる。本実施形態のセンサネットワークシステムには、ここで例示したセンサをはじめとして、いかなる種類のセンサを接続することができる。また、工場のＦＡや生産管理、都市交通制御、気象等の環境計測、ヘルスケア、防犯など、世の中のあらゆる場所に様々な用途・目的で多数のセンサが既に設置されているが、これらのセンサを本システムに接続することも可能である。なお、センサネットワークシステムは、一種類のセンサのみで構成してもよいし、複数の種類のセンサを混在させてもよい。
　（センサネットワークアダプタ）
　センサネットワークアダプタ２２は、１つ又は複数のセンサ２１と有線又は無線により通信可能に接続され、センサ２１の管理、センサ２１からのセンシングデータの取得、センサネットワークシステムやアプリケーションへのセンシングデータの送信などを行う装置である。センサネットワークアダプタ２２は、センシングデータに所定の処理（例えばノイズ除去などの信号処理、平均処理などの演算、サンプリング、データ圧縮、タイムスタンプなど）を施す機能を有していてもよい。センサネットワークアダプタ２２は、外部装置との通信機能を有しており、アプリケーションサーバ３０、センサネットワークサーバ１０等とネットワークを介して通信が可能である。
　スマートフォン、タブレット端末、モバイルＰＣ、ドローン、ウェアラブル端末などの機器は、画像センサ、ＧＰＳセンサ、加速度センサ、マイクなどのセンサを内蔵し、各センサで得られたデータを加工し出力する機能やネットワーク通信機能を有している。したがって、これらの機器は、センサ２１とセンサネットワークアダプタ２２とが物理的に一体となったデバイスの例である。なお、センサ２１が通信機能を内蔵している場合、単体で（つまりセンサネットワークアダプタ２２を介さずに）センサネットワークシステムに接続可能である。
　（アプリケーションサーバ）
　アプリケーションサーバ３０は、センシングデータを利用してサービスを提供する各種アプリケーションプログラムがインストールされたサーバ装置である。アプリケーションサーバ３０は、ＣＰＵ（プロセッサ）、メモリ、補助記憶装置（ＨＤＤ等）、通信装置、入力装置、表示装置などを備える汎用のコンピュータにより構成できる。アプリケーションサーバ３０は、センシングデータの利用者が設置するものであり、その用途・目的に応じて様々なアプリケーションが想定される。
　アプリケーションの例としては、例えば、道路に設置されたセンサや、道路上を走行する車両に搭載された車載端末又は運転者のスマートフォンなどから、各地点の交通状況を収集して渋滞マップを生成し、渋滞情報を利用する事業者等に提供するアプリケーションが考えられる。他にも、スマートフォンや車載カメラなどで走行中に撮影された画像データを収集し、各地点の状況を知りたい利用者に提供する映像配信アプリケーション、渋滞情報等を元に車両の走行ルートを検索する経路探索アプリケーション、特定の場所に設置されたカメラの映像から通行者の属性（性別、年齢層など）の統計データを推定し、各種調査用のデータとして提供するアプリケーション、センサメーカが販売済みの自社センサをオンラインメンテナンスするアプリケーションなど、様々なものが考えられる。
　（センサネットワークサーバ）
　センサネットワークサーバ１０は、センシングデータの提供者と利用者のあいだのマッチング、提供者から利用者へのセンシングデータのデータフロー制御などを担うサーバ装置であり、本発明に係るデータフロー制御装置の一具体例である。センサネットワークサーバ１０も、ＣＰＵ（プロセッサ）、メモリ、補助記憶装置（ＨＤＤ等）、通信装置、入力装置、表示装置などを備える汎用のコンピュータにより構成できる。後述するセンサネットワークサーバ１０の各種機能は、ＣＰＵが必要なプログラムを実行することにより実現される。
　センサネットワークシステムは、多数の（又は多種多様な）センサをネットワーク化し、センシングデータの収集や利用を可能とするものであるが、本実施形態では、データ提供者（センサ２１）がデータ利用者（アプリケーションサーバ３０）に対してセンシングデータを提供して対価を得る仕組みを想定している。これにより、データ提供者にとっては収益の機会、利用者にとっては安価なデータ取得というメリットが得られる。センサネットワークサーバ１０は、このようなセンシングデータの取引の仲介を行うサーバ装置であり、データ提供者とデータ利用者のあいだのマッチングを行い、センシングデータの適切な流通を実現する。
　ところで、データ提供者とデータ利用者のあいだのマッチングを行う際に、データ利用者の希望条件に合致するデータを膨大なセンシングデータのなかから抽出するのは現実的ではない。そこで本システムでは、センサネットワークに登録されているすべてのセンサについて、センシングデータの仕様や提供条件などを記述したメタデータ（センサ側メタデータ）を準備するとともに、データ利用者であるアプリケーションについても、センシングデータの要求仕様や利用条件などを記述したメタデータ（以下、アプリ側メタデータ）を用いる。そして、メタデータ同士を比較することで、データ提供者（センサ）と利用者（アプリケーション）の適切なマッチングを行う。
　図１のシステム構成例では、センサネットワークサーバ１０は、記憶部１１、マッチング部１２、仮マッチング部１３、入出力部１４、データフロー制御部１５を有する。
　記憶部１１は、センサネットワークに登録されているすべてのアプリケーションに対応するアプリ側メタデータと、センサネットワークに登録されているすべてのセンサに対応するセンサ側メタデータを記憶するデータベースである。
　マッチング部１２は、記憶部１１に登録されたアプリ側メタデータとセンサ側メタデータのマッチングを行い、アプリケーションの要求を満たすセンシングデータを提供可能なセンサを抽出し、センサとアプリケーションのペアを生成する（ペアリングを行う）手段である。
　また、仮マッチング部１３は、新規に登録されたセンサ側メタデータまたはアプリ側メタデータについて、ペアリングの候補となりうるメタデータが存在するか否かを確認し、ユーザに情報を提供する手段である。
　マッチング部１２および仮マッチング部１３の詳細については後述する。
　入出力部１４は、登録対象のセンサ側メタデータまたはアプリ側メタデータを取得するためのインタフェース手段である。入出力部１４は、有線または無線接続で外部のコンピュータと通信を行うハードウェアである。なお、入出力部１４は、ディスプレイデバイスとヒューマンインタフェースデバイス（キーボードやマウス等）を含んでいてもよい。この場合、外部のコンピュータと通信を行う必要はない。いずれの場合も、入出力部１４を介して、ユーザに情報を提供し、また、ユーザから情報を取得することができる。
　データフロー制御部１５は、マッチング部１２が出力した情報に基づき、センシングデータの送信を指令するデータフロー制御指令を生成し送信する機能である。これらの機能の詳細は後述する。
　（センサ側メタデータ）
　次に、記憶部１１に記憶されるメタデータの詳細について説明する。
　図２（Ａ）は、記憶部１１にテーブル形式で格納されるセンサ側メタデータの例である。
　センサ側メタデータは、センサの属性情報、センサが提供可能なセンシングデータの仕様を示す情報や、センシングデータの提供条件を示す情報などを記述したメタデータである。センサの属性情報は、例えば、センサを特定するＩＤ、センサの種別、センサのネットワークアドレス、センサの動作履歴などを含むとよい。ネットワークアドレスには、例えばＩＰアドレス、ＭＡＣアドレス、ＵＲＩ（Uniform Resource Identifier）などを利用できる。センサがセンサネットワークアダプタ２２を介してネットワークに接続している場合は、センサネットワークアダプタ２２のネットワークアドレスを設定すればよい。
　センシングデータの仕様を示す情報は、例えば、センシング対象（つまり何をセンシングするか）、センシングする場所や領域（例：位置、範囲など）、センシング時間（センシングデータを取得可能な時刻や時間帯）、センシングデータのデータ種別（例：画像、動画、温度など）、データフォーマット（例：ＪＰＥＧ、テキストなど）、センシング条件（例：シャッタスピード、解像度、サンプリング周期など）、データ信頼度などを含ませることができる。
　センシングデータの提供条件を示す情報は、データ提供者が希望する取引条件を示す情報であり、例えば、データ提供者を特定するＩＤ、対価（データの提供価格）、利用範囲・利用目的（例：商用利用不可、二次利用可など）などを含ませることができる。
　さらに、センサ側メタデータには、センシングデータの来歴を示す情報（「データ来歴情報」と呼ぶ）を記述することができる。データ来歴情報は、そのセンシングデータの由来、経緯、出所、起源、素性、履歴、成り立ち、責任者などを表す情報であり、センシングデータの精度や品質、信頼性、安全性などを判断する客観的な材料となり得る情報であればどのような情報でもよい。
　仮マッチングフラグは、当該メタデータが、仮マッチングが許可されたメタデータであるか否かを表すフラグである。また、仮ペア維持フラグは、仮マッチングによって生成された仮ペアを維持するか否かを表すフラグである。両フラグの詳細については後述する。
　（アプリ側メタデータ）
　図２（Ｂ）は、記憶部１１にテーブル形式で格納されるアプリ側メタデータの例である。
　アプリ側メタデータは、アプリケーションの属性情報、アプリケーションが要求するセンシングデータの仕様（要求仕様）を示す情報、センシングデータの利用条件を示す情報などを記述したメタデータである。
　アプリケーションの属性情報は、例えば、アプリケーションを特定するＩＤ、アプリケーションの種別、アプリケーションのネットワークアドレスなどを含むとよい。ネットワークアドレスには、例えばＩＰアドレス、ポート番号などを利用できる。センシングデータの要求仕様を示す情報は、例えば、センシング対象、センシングする領域、センシング時間、センシングデータのデータ種別、データフォーマット、センシング条件、データ信頼度などを含ませることができる。
　利用条件を示す情報は、データ利用者が希望する取引条件を示す情報であり、例えば、データ利用者を特定するＩＤ、対価（データの利用価格の上限）、利用範囲・利用目的などを含ませることができる。
　アプリ側メタデータにも、データ来歴情報を記述することができる。データ来歴情報の内容はセンサ側メタデータに記述する情報と同じであるため、説明を割愛する。ただし、センサ側メタデータには、提供するセンシングデータについてのデータ来歴情報を記述するのに対し、アプリ側メタデータには、アプリケーションが要求するデータ来歴情報を記述する点が異なる。したがってアプリ側メタデータには、アプリケーションが許容するデータ来歴情報を複数記述することができる。
　また、アプリ側メタデータも、仮マッチングフラグおよび仮ペア維持フラグを有している。当該フラグの内容は、デバイス側メタデータと同様である。
　（メタデータの登録）
　データ提供者あるいはデータ利用者が、データの提供または利用を希望する際は、自己が所有するコンピュータをセンサネットワークサーバ１０に接続し、メタデータの内容を入力する。具体的には、ネットワークを介して入出力部１４にアクセスし、入出力部１４が生成した画面に従って情報の入力を行う。これにより、センサ側メタデータあるいはアプリ側メタデータが生成され、記憶部１１に記憶される。本例では、データ提供者がセンサ側メタデータを生成する例を挙げて説明を行うが、データ利用者がアプリ側メタデータを生成する場合も同様である。
　図３は、データ提供者がセンサ側メタデータを新規登録する際に表示される画面の例である。当該画面は、入出力部１４が生成し、入出力部１４に接続されたデータ提供者のコンピュータに出力される。
　本実施形態では、メタデータの内容を入力した後で、ユーザが「通常登録」または「仮マッチング実行」を選択する。ユーザが通常登録を選択すると、入力されたメタデータが記憶部１１に登録され、マッチングが開始される。
　なお、本実施形態に係るセンサネットワークサーバ１０は、（１）記憶部１１に登録されたメタデータ同士のペアリングを行い、ペアが成立した場合に、センサからアプリケーションへのデータフローを発生させる機能と、（２）新規にメタデータを記憶部１１に登録する際に、ペアリングの候補となりうる相手側メタデータが登録されているか否かを確認し、ユーザに通知する機能を有している。
　以降、前者を「通常マッチング」、後者を「仮マッチング」と称する。それぞれの処理について説明する。
（通常マッチング）
　図３に示した画面で、情報を入力したユーザが「通常登録」を押下すると、センサ側メタデータが記憶部１１に登録され、通常マッチングが行われる。
　なお、「通常登録」を押下してメタデータを登録した場合、図２に示したフィールドのうち、仮マッチングフラグ、および、仮ペア維持フラグにはＯＦＦが設定される。
　通常マッチングとは、マッチング部１２が行う処理であって、記憶部１１に登録されたアプリ側メタデータとセンサ側メタデータ同士を比較し、条件が合致するもの同士を抽出してペアリングしたうえで、該当するセンサからアプリケーションへのセンシングデータのデータフロー制御指令を発行する処理である。通常マッチングは、新規にメタデータを登録した場合に実行される。
　図４は、センサ側メタデータを登録した際に実行される通常マッチングの処理フローチャート図である。
　まず、記憶部１１が有するセンサ側メタデータテーブルから、処理待ちのセンサ側メタデータを一つずつ取得する（ステップＳ１１）。
　次に、記憶部１１が有するアプリ側メタデータテーブルから、アプリ側メタデータを一つ取得する（ステップＳ１２）。なお、仮マッチングフラグにＯＮが設定されているレコードは、ステップＳ１２で取得対象とはならない。この点については後述する。
　次に、アプリ側メタデータで規定されたセンシングデータの仕様および取引条件（提供条件）が、センサ側メタデータで規定されたセンシングデータの要求仕様および取引条件（利用条件）を満足するか否かを判定する。ここで、センサ側メタデータおよびアプリ側メタデータが有する比較対象項目が一致した場合、ペア成立となり、一致しなかった場合、ペア不成立となる（ステップＳ１３）。
　なお、条件が一致するか否かは、必ずしも文言上の完全一致によって判断する必要はない。例えば、センシング場所が、センサ側において「京都市内」であって、アプリ側において「京都駅前」であった場合、両者は一致するものと判定される。
　ステップＳ１３でペアが成立した場合、ステップＳ１２で取得したアプリ側メタデータが、最終的なペア候補の一つとして抽出される（ステップＳ１４）。
　ステップＳ１２～Ｓ１４の処理は、アプリ側メタデータテーブルに登録されているすべてのアプリ側メタデータについて実行される（ステップＳ１５）。
　次に、ステップＳ１６で、候補として抽出されたアプリ側メタデータの数を判定する。
　候補として抽出されたアプリ側メタデータが複数存在する場合、マッチング部１２は、それら複数の候補のなかからデータ提供者にとって最も有利なものを選択する（ステップＳ１７）。例えば対価優先の場合は、データの価格が最も高いものを選択すればよい。データ提供者に最も有利なアプリケーションをどのような基準で選択するかは、適宜設定することができる。
　なお、候補として抽出されたアプリ側メタデータが一つもなかった場合は、処理を終了してもよいし、データ仕様や取引条件、データ来歴情報が最も近いものをレコメンドしてもよい。また、所定の時間が経過後、再度図４に示した処理を実行するようにしてもよい。
　最後に、データフロー制御部１５が、対象のセンサに対して、センシングデータの送信を指令するデータフロー制御指令を生成し、当該データフロー制御指令を、当該センサ２１を管理するセンサネットワークアダプタ２２に対し送信する（ステップＳ１８）。
　そして、図１に示したように、センサネットワークアダプタ２２が、データフロー制御指令に基づいてセンサ２１から必要なセンシングデータを取得し、対応するアプリケーションサーバ３０へと送信する。
　なお、データフロー制御指令は、データフロー制御指令ＩＤ、センサを特定する情報（センサＩＤ、センサのネットワークアドレス）、アプリを特定する情報（アプリＩＤ、アプリのネットワークアドレス）、データ送信を行う時間情報などを含んだデータであるが、これ以外の情報を含んでいてもよい。
　以上に説明したように、センサとアプリケーションのペアを成立させるためには、センサ側メタデータが有する比較対象項目と、アプリ側メタデータが有する比較対象項目が一致する必要がある。すなわち、一つでも一致しない項目があった場合、ペアは成立しない。
　しかし、メタデータを登録するユーザにとって、各項目にどのような条件を設定すればペアが成立しやすいのかを事前に知ることは容易ではない。
　本実施形態に係るセンサネットワークサーバ１０は、通常マッチングに先立って、現在入力されている条件でペアリングが可能な相手先メタデータがあるか否かを判定し、ユーザに通知することで当該課題を解決している。この処理を仮マッチングと呼ぶ。
（仮マッチング）
　図３に示した画面で、情報を入力したユーザが「仮マッチング実行」を押下すると、仮マッチングが行われる。
　仮マッチングは、仮マッチング部１３が行う処理であって、通常マッチングが行われる前にマッチングを試行し、一致する相手側メタデータが存在するか否かをユーザに通知する処理である。仮マッチングでは、一致する相手が見つかった場合であっても、データフロー制御は行わない。
　図５は、仮マッチングの処理フローチャート図である。図５に示した処理は、ユーザが仮マッチング実行ボタンを押下したタイミングで実行される。
　まず、ステップＳ２１で、ユーザが入力したセンサ側メタデータを取得する。
　次に、ステップＳ２２で、センサ側メタデータを記憶部１１に登録する。この際、図２に示したフィールドのうち、仮マッチングフラグにはＯＮが設定され、仮ペア維持フラグにはＯＦＦが設定される。仮マッチングフラグは、当該メタデータが仮マッチングを許可されたメタデータであるか否かを表すフラグである。仮ペア維持フラグについては後述する。
　次に、ステップＳ２３で、仮マッチングを行う対象のアプリ側メタデータが存在するか否かを判定する。すなわち、アプリ側メタデータテーブルから、仮マッチングフラグがＯＮであるレコードを抽出する。もし、結果が存在しない場合、仮マッチングの相手が存在しない旨を通知し（ステップＳ２８）、仮マッチング処理は終了する。
　次に、ステップＳ２４で、仮マッチングフラグがＯＮであるアプリ側メタデータの中から、比較対象項目が、ユーザによって入力された条件と一致するもの（マッチング条件が合致するもの）を検索する。
　例えば、図６のように、新規に入力されたセンサ側メタデータにおいて、５つの項目のみが入力されていたものとする。この場合、入力されている５つの項目のみを用いてマッチングを試行する。この結果、一致するアプリ側メタデータが存在する場合、ペアリングの候補が存在する旨をユーザに通知する（ステップＳ２５）。以降、仮マッチングにおいて成立したペアを仮ペアと称する。
　一致するアプリ側メタデータが存在しない場合、ペアリングの候補が存在しない旨をユーザに通知し（ステップＳ２９）、処理は終了する。
　なお、ステップＳ２８およびＳ２９の後で処理を終了させる場合、入力したセンサ側メタデータを消去するようにしてもよい。このようにすることで、条件を変更して再度仮マッチングを試行させることができる。
　また、入力したセンサ側メタデータを消去しない場合、仮マッチングフラグをＯＮのままとするか、ＯＦＦに変更するかを選択させてもよい。例えば、仮マッチングフラグをＯＮのままにすることで、他人が登録したメタデータに対して仮マッチングを受けることができるため、デバイスとアプリケーションとのペアが成立する機会が増えることが期待できる。
　図７は、ステップＳ２５において、仮ペアが成立した場合にユーザに提供される画面の例である。ここでユーザは、三つの選択を行うことができる。
　一つ目は、仮マッチングの結果はあくまで参考とし、通常の登録に移行する方法である。この場合、ユーザが画面上の「通常登録」を押下すると、仮マッチング処理は終了し、前述した通常マッチングに移行する（ステップＳ２６－Ｎｏ）。この場合、図３の処理をすぐ開始してもよいし、図３の処理が周期的に行われる場合、処理開始を待ってもよい。
　なお、通常マッチングに移行する場合も、仮マッチングフラグをＯＮのままとするか、ＯＦＦに変更するかを選択させてもよい。
　二つ目は、仮マッチングによって見つかった相手先メタデータをその場で確保する方法である。通常マッチングは、仮マッチングとは独立したタイミングで実行されているため、仮マッチングでヒットした相手先が、他人のメタデータとペアリングされてしまう可能性がある。そこで、本実施形態に係るセンサネットワークサーバ１０は、仮ペアが成立した場合に、当該仮ペアを維持するか否かをユーザに選択させる。ここで、ユーザが画面上の「維持登録」を押下すると、該当する双方のメタデータの仮ペア維持フラグがともにＯＮになる（ステップＳ２７）。
　また、マッチング部１２は、通常マッチングを行う際（ステップＳ１２）、仮ペア維持フラグがＯＮであるメタデータは取得せず、別途、優先的にペアリングを行う。なお、本例では仮ペア維持フラグを用いたが、仮ペアが成立した相手を特定する情報（例えばセンサＩＤやアプリＩＤ）を保持するようにしてもよい。
　三つ目は、登録自体をキャンセルする方法である。
　以上説明したように、本実施形態に係るセンサネットワークサーバは、メタデータの登録を行う際に、通常マッチングに先立って、現在入力されている条件でヒットする相手先メタデータがあるか否かを確認し、ユーザに通知する。また、仮マッチングは、通常のマッチングよりも少ない条件で行うことができる。これにより、ユーザは、仮マッチングの結果に基づいてより好ましい条件を検討することができる。
　また、仮マッチングの結果に基づいて、通常マッチングを行うか、仮マッチングで得られた関係を維持するかを選択することができる。例えば、仮マッチングの結果、候補となる相手が十分に存在する場合、よりよい条件を求めて通常登録を行ってもよいし、相手が少ない場合、確実なペアリングを行うために維持登録を行ってもよい。
　なお、ステップＳ２３およびＳ２４で、条件を満たすアプリ側メタデータが複数抽出された場合、所定の方法によっていずれかを選択するようにしてもよい。例えば、データ提供者にとって最も条件がよいものを選択するようにしてもよい。
　また、仮マッチングの結果は、仮ペアの相手が存在するか否かのみを通知してもよいし、仮ペアが成立した件数を同時に通知するようにしてもよい。
　また、ペアが成立したセンサ側メタデータおよびアプリ側メタデータは、記憶部１１から削除してもよいし、契約が成立した旨のフラグを付与し、契約が解除されるまでマッチング対象から外すようにしてもよい。
（変形例）
　なお、上述した実施形態の構成は本発明の一具体例を示したものにすぎず、本発明の範囲を限定する趣旨のものではない。本発明はその技術思想を逸脱しない範囲において、種々の具体的構成を採り得るものである。例えば、上記実施形態で示したデータ構造やテーブル構造は一例であり、項目を適宜追加したり入れ替えたりしてもよい。
　なお、本実施形態では、ステップＳ１７において、データ提供者にとっての有利さを基準として相手先メタデータの候補を選択したが、当該方法は一例であり、これ以外の条件に基づいて候補を選択してもよい。
　また、実施形態の説明では、センサ側メタデータが新規に登録されたことをトリガとして図４に示した通常マッチング処理を行う例を挙げたが、通常マッチングは、アプリ側メタデータが新規に登録されたことをトリガとして実行してもよい。この場合、センサとアプリ、データ提供者とデータ利用者をそれぞれ読み替えればよい。また、実施形態の説明では、メタデータを登録したタイミングで通常マッチング処理を実行するものとしたが、通常マッチング処理は周期的に実行されてもよい。
　同様に、実施形態の説明では、センサ側メタデータが新規に登録された場合に仮マッチングを行う例を挙げたが、仮マッチングは、アプリ側メタデータが新規に登録された際に実行してもよい。この場合、センサとアプリ、データ提供者とデータ利用者をそれぞれ読み替えればよい。
　また、上記実施形態では、センサネットワークにおけるセンシングデータの流通を例示したが、本発明は、センサ以外のデバイスを含むデバイスネットワークにおけるデータの流通にも適用可能である。その場合も、システムの基本的な構成は上記実施形態のものと同様であり、上記実施形態における「センサ」を「デバイス」と読み替え、「センシングデータ」を「データ」と読み替えればよい。
　本明細書に開示された技術思想は、以下のような発明として特定することもできる。
（付記１）
　メモリと、前記メモリに接続された少なくとも一つのハードウェアプロセッサと、を有するデータフロー制御装置であって、
　前記メモリは、
　複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示すデバイス側メタデータを記憶するデバイス側メタデータ記憶手段と、
　前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示すアプリ側メタデータを記憶するアプリ側メタデータ記憶手段と、を有し、
　前記少なくとも一つのハードウェアプロセッサは、
　　前記デバイス側メタデータあるいはアプリ側メタデータのどちらか一方が前記メモリに新規に登録された場合に、前記登録されたデバイス側メタデータあるいはアプリ側メタデータと、前記登録されたデバイス側メタデータあるいはアプリ側メタデータよりも先に登録され、マッチング条件が合致する相手側のデバイス側メタデータあるいはアプリ側メタデータとの組である仮ペアが存在するか否かを判定し、前記判定の結果を、前記デバイス側メタデータあるいはアプリ側メタデータを登録したユーザに通知する
　ことを特徴とするデータフロー制御装置。
（付記２）
　データフロー制御方法であって、
　少なくとも一つのハードウェアプロセッサにより、
　複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示すデバイス側メタデータを取得するデバイス側メタデータ取得ステップと、
　前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示すアプリ側メタデータを取得するアプリ側メタデータ取得ステップと、
　前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶ステップと、
　前記デバイス側メタデータあるいはアプリ側メタデータのどちらか一方が新規に登録された場合に、前記登録されたデバイス側メタデータあるいはアプリ側メタデータと、前記登録されたデバイス側メタデータあるいはアプリ側メタデータよりも先に登録され、マッチング条件が合致する相手側のデバイス側メタデータあるいはアプリ側メタデータとの組である仮ペアが存在するか否かを判定し、前記判定の結果を、前記デバイス側メタデータあるいはアプリ側メタデータを登録したユーザに通知する仮マッチングステップと、
　を実行することを特徴とするデータフロー制御方法。
　１０　センサネットワークサーバ
　１１　記憶部
　１２　マッチング部
　１３　仮マッチング部
　１４　入出力部
　１５　データフロー制御部
　２０　センサ装置
　２１　センサ
　２２　センサネットワークアダプタ
　３０　アプリケーションサーバ

Claims (9)

  1. 　複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示すデバイス側メタデータを取得するデバイス側メタデータ取得手段と、
    　前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示すアプリ側メタデータを取得するアプリ側メタデータ取得手段と、
    　前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶手段と、
    　前記デバイス側メタデータあるいはアプリ側メタデータのどちらか一方が新規に登録された場合に、前記登録されたデバイス側メタデータあるいはアプリ側メタデータと、前記登録されたデバイス側メタデータあるいはアプリ側メタデータよりも先に登録され、マッチング条件が合致する相手側のデバイス側メタデータあるいはアプリ側メタデータとの組である仮ペアが存在するか否かを判定し、前記判定の結果を、前記デバイス側メタデータあるいはアプリ側メタデータを登録したユーザに通知する仮マッチング手段と、を有する
    　ことを特徴とするデータフロー制御装置。
  2. 　前記アプリ側メタデータと前記デバイス側メタデータのマッチング処理を行うことで、前記アプリケーションと、前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスとの組み合わせを抽出するマッチング手段と、
    　前記マッチング手段により抽出された前記デバイスと前記アプリケーションを特定したデータフロー制御指令を生成するデータフロー制御手段と、をさらに有し、
    　前記仮マッチング手段は、前記判定および通知を、前記マッチング処理に先立って実行する
    　ことを特徴とする、請求項１に記載のデータフロー制御装置。
  3. 　前記仮マッチング手段は、前記判定の結果を通知した後、前記ユーザに対してマッチング処理を行うか否かを選択させる
    　ことを特徴とする、請求項２に記載のデータフロー制御装置。
  4. 　前記仮マッチング手段は、前記仮ペアが存在する場合に、前記ユーザに対して当該仮ペアを維持するか否かを選択させ、前記仮ペアを維持する旨の回答があった場合に、該当するデバイス側メタデータおよびアプリ側メタデータに対して、仮ペアを維持する旨を示すデータを付加する
    　ことを特徴とする、請求項２または３に記載のデータフロー制御装置。
  5. 　前記マッチング手段は、前記仮ペアを維持する旨を示すデータが付加された前記デバイス側メタデータおよびアプリ側メタデータにそれぞれ対応するデバイスとアプリケーションの組み合わせを優先的に抽出する
    　ことを特徴とする、請求項４に記載のデータフロー制御装置。
  6. 　前記デバイス側メタデータは、デバイスが提供可能なデータの仕様を示す一つ以上の項目を含み、
    　前記アプリ側メタデータは、アプリケーションが要求するデータの仕様を示す一つ以上の項目を含み、
    　前記マッチング手段は、前記デバイス側メタデータおよびアプリ側メタデータが有する項目のうち、マッチング対象の項目が全て一致した場合に、当該デバイス側メタデータおよびアプリ側メタデータにそれぞれ対応するデバイスとアプリケーションとの組み合わせを抽出する
    　ことを特徴とする、請求項２から５のいずれか１項に記載のデータフロー制御装置。
  7. 　前記デバイスは、センシングデータを出力するセンサである
    　ことを特徴とする、請求項１から６のいずれか１項に記載のデータフロー制御装置。
  8. 　コンピュータが、
    　複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示すデバイス側メタデータを取得するデバイス側メタデータ取得ステップと、
    　前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示すアプリ側メタデータを取得するアプリ側メタデータ取得ステップと、
    　前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶ステップと、
    　前記デバイス側メタデータあるいはアプリ側メタデータのどちらか一方が新規に登録された場合に、前記登録されたデバイス側メタデータあるいはアプリ側メタデータと、前記登録されたデバイス側メタデータあるいはアプリ側メタデータよりも先に登録され、マッチング条件が合致する相手側のデバイス側メタデータあるいはアプリ側メタデータとの組である仮ペアが存在するか否かを判定し、前記判定の結果を、前記デバイス側メタデータあるいはアプリ側メタデータを登録したユーザに通知する仮マッチングステップを、を実行する
    　ことを特徴とするデータフロー制御方法。
  9. 　請求項８に記載のデータフロー制御方法の各ステップをコンピュータに実行させることを特徴とするプログラム。
PCT/JP2017/000577 2016-03-15 2017-01-11 データフロー制御装置およびデータフロー制御方法 WO2017159009A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/084,549 US10334420B2 (en) 2016-03-15 2017-01-11 Data-flow control device and data-flow control method
EP17766017.2A EP3432593B1 (en) 2016-03-15 2017-01-11 Data-flow control device and data-flow control method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016051476A JP6376159B2 (ja) 2016-03-15 2016-03-15 データフロー制御装置およびデータフロー制御方法
JP2016-051476 2016-03-15

Publications (1)

Publication Number Publication Date
WO2017159009A1 true WO2017159009A1 (ja) 2017-09-21

Family

ID=59850165

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/000577 WO2017159009A1 (ja) 2016-03-15 2017-01-11 データフロー制御装置およびデータフロー制御方法

Country Status (4)

Country Link
US (1) US10334420B2 (ja)
EP (1) EP3432593B1 (ja)
JP (1) JP6376159B2 (ja)
WO (1) WO2017159009A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11657437B2 (en) * 2017-11-29 2023-05-23 Angelswing Inc Method and apparatus for providing drone data by matching user with provider

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008244810A (ja) * 2007-03-27 2008-10-09 Fujitsu Ltd センサ情報管理システム、センサ情報管理方法、センサ情報管理プログラム
JP2011180946A (ja) * 2010-03-03 2011-09-15 Oki Electric Industry Co Ltd センサデータ提供システム、方法及び装置
WO2014041826A1 (ja) * 2012-09-12 2014-03-20 オムロン株式会社 データフロー制御指令発生装置およびセンサ管理装置

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002230339A (ja) * 2001-02-06 2002-08-16 Yamaha Corp 催し物の仲介装置、クライアント装置及び方法並びに記録媒体
US20070118496A1 (en) * 2005-11-21 2007-05-24 Christof Bornhoevd Service-to-device mapping for smart items
JP4682912B2 (ja) 2006-05-08 2011-05-11 株式会社日立製作所 センサネットシステム、センサネット位置特定プログラム
US8509807B2 (en) * 2010-12-15 2013-08-13 At&T Mobility Ii Llc Location reporting responsive to transitions in motional state of wireless equipment
GB2487390A (en) * 2011-01-19 2012-07-25 Canon Kk Managing access to copies of resources
JP5676062B2 (ja) * 2012-10-31 2015-02-25 三菱電機株式会社 カーレンタル支援装置
EP2941656B1 (en) * 2013-01-06 2022-10-26 Ionroad Technologies Ltd. Driving support
KR20150054505A (ko) * 2013-11-12 2015-05-20 건국대학교 산학협력단 홈 가전기기들에 대한 관리 서비스를 제공하는 클라우드 기반의 데이터 서버 및 홈 가전기기들에 대한 관리 서비스 제공 방법
US10046521B2 (en) * 2014-01-16 2018-08-14 Jabil Inc. Remotely-accessible additive manufacturing systems and methods
US9913311B1 (en) * 2016-08-23 2018-03-06 Qualcomm Incorporated Methods for TxPool selection for LTE-D code transmission

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008244810A (ja) * 2007-03-27 2008-10-09 Fujitsu Ltd センサ情報管理システム、センサ情報管理方法、センサ情報管理プログラム
JP2011180946A (ja) * 2010-03-03 2011-09-15 Oki Electric Industry Co Ltd センサデータ提供システム、方法及び装置
WO2014041826A1 (ja) * 2012-09-12 2014-03-20 オムロン株式会社 データフロー制御指令発生装置およびセンサ管理装置

Also Published As

Publication number Publication date
US10334420B2 (en) 2019-06-25
EP3432593B1 (en) 2020-12-16
US20190090111A1 (en) 2019-03-21
EP3432593A4 (en) 2019-08-21
JP6376159B2 (ja) 2018-08-22
JP2017168992A (ja) 2017-09-21
EP3432593A1 (en) 2019-01-23

Similar Documents

Publication Publication Date Title
JP6458755B2 (ja) データフロー制御装置およびデータフロー制御方法
JP6465012B2 (ja) データフロー制御装置およびデータフロー制御方法
JP6365519B2 (ja) データフロー制御装置およびデータフロー制御方法
JP6693506B2 (ja) センサネットワークシステム
JP2012216163A (ja) アプリ提供システム、アプリ提供方法、情報処理装置及び情報処理プログラム
JP2015226102A (ja) 仮想センサのメタデータ構造
JP6372508B2 (ja) データフロー制御装置およびデータフロー制御方法
WO2014050192A1 (ja) デバイス管理装置及びデバイス検索方法
CN108369561B (zh) 电子设备控制装置及方法、计算机可读的记录介质
US20180139265A1 (en) Computerized system and method for automatically providing networked devices non-native functionality
El-Moursy et al. Home Automation Using Augmented Reality (HAAR)
JP6376159B2 (ja) データフロー制御装置およびデータフロー制御方法
JP2012208661A (ja) 情報提供システム、通信装置及び情報提供方法
JP5975125B2 (ja) アプリ提供システム及びアプリ提供方法
JP2016206911A (ja) 複数の端末装置の断続的なセンサーデータからユーザ状態を分析し、最適なレコメンド情報をユーザに配信するための分析システム。

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2017766017

Country of ref document: EP

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

Ref document number: 17766017

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017766017

Country of ref document: EP

Effective date: 20181015