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

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

Info

Publication number
WO2017159005A1
WO2017159005A1 PCT/JP2017/000399 JP2017000399W WO2017159005A1 WO 2017159005 A1 WO2017159005 A1 WO 2017159005A1 JP 2017000399 W JP2017000399 W JP 2017000399W WO 2017159005 A1 WO2017159005 A1 WO 2017159005A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
data
side metadata
item
flow control
Prior art date
Application number
PCT/JP2017/000399
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 EP17766013.1A priority Critical patent/EP3432245B1/en
Priority to US16/083,863 priority patent/US10454837B2/en
Publication of WO2017159005A1 publication Critical patent/WO2017159005A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/903—Querying
    • G06F16/90335—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/01—Customer relationship services
    • G06Q30/012—Providing warranty services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/01—Customer relationship services
    • G06Q30/014—Providing recall services for goods or products
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/01—Customer relationship services
    • G06Q30/015—Providing customer assistance, e.g. assisting a customer within a business location or via helpdesk
    • G06Q30/016—After-sales
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0137—Measuring and analyzing of parameters relative to traffic conditions for specific applications
    • G08G1/0145—Measuring and analyzing of parameters relative to traffic conditions for specific applications for active traffic flow control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • 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
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • 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/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • 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]

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 characterized in that when metadata does not match as a result of matching metadata, a means for adjusting the item is provided.
  • the data flow control device is: For each of a plurality of devices, an application requests a device-side metadata acquisition unit that acquires device-side metadata including an item indicating a specification 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 including items indicating specifications of data to be performed, storage means for storing the device-side metadata and application-side metadata, the application-side metadata, and the device side Matching means for extracting a combination of the application and a device capable of providing data satisfying the specifications required by the application by performing metadata matching, and the device and the application extracted by the matching means
  • Data flow control means for generating a specified data flow control command, and the matching means determines whether or not a matching target item among the items of the device-side metadata and application-side metadata matches.
  • the combination is extracted based on whether or not there is an item that has a mismatch, and information indicating whether or not the item in which the mismatch has occurred can be changed is acquired, and the item in which the mismatch has occurred is changed based on the information. It is characterized by that.
  • the information indicating whether change is possible may be, for example, data set in advance for each item, or may be generated based on an instruction from the user by inquiring the user who registered the metadata. According to such a configuration, when a mismatch occurs between items in matching, the content of the item in which the mismatch has occurred can be individually corrected, and the probability that a device / application pair is established can be improved.
  • the matching unit may query the user who manages the device or the application whether or not the item in which the mismatch occurs may be changed, and may change the item based on an answer acquired from the user. .
  • Inquiries may be made via e-mail or messaging services, for example. According to such a configuration, it is possible to give the user an opportunity to modify the item, and the user can determine whether to change the conditions or to see off according to the situation in order to establish a device-application pair. .
  • a flag indicating whether or not change is possible is associated with each item to be matched included in the device-side metadata and application-side metadata, and the matching unit can change the item in which the mismatch occurs. In this case, an inquiry may be made to the user.
  • one or more change candidates are respectively associated with the matching target items included in the device-side metadata and the application-side metadata, and the matching unit, when a mismatch occurs between the items, The item may be changed based on the change candidate.
  • the items in the metadata may have change candidates and the items may be automatically corrected. There may be a plurality of change candidates. According to such a configuration, since it is not necessary to make an inquiry to the user, a device / application pair can be quickly established.
  • the matching means may not change the item when the number of items in which the mismatch occurs is larger than a predetermined number.
  • 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 a first embodiment. It is an example of metadata on the sensor side / application side in the first embodiment. It is an example of the screen which registers sensor side metadata. It is a flowchart figure of a matching process. It is a flowchart figure of an item correction process. It is a figure explaining the matching of metadata. It is an example of a change request mail. It is an example of the sensor side / application side metadata in 2nd embodiment. It is a process flowchart figure of the item correction process in 2nd embodiment.
  • 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, an adjustment 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. Moreover, when the item which has prevented the formation of a pair as a result of the matching process performed by the matching unit, the adjustment unit 13 adjusts the content of the item (that is, determines whether or not the item can be changed, and the determination result) To make changes based on Details of the matching unit 12 and the adjustment 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.
  • 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.
  • a field indicating the changeability (hereinafter referred to as a changeability flag) is added to each item included in both the sensor-side metadata and the application-side metadata.
  • a desired price of “50 yen or more” is set for the sensor with the sensor ID “V001”, and it is defined that the item is “changeable”. Details of the change enable / disable flag will be described later.
  • ⁇ Register metadata> When a data provider or a data user desires to provide or use data, he or she connects his own computer to the sensor network server 10 and inputs the contents of the metadata. Specifically, the input / output unit 14 is accessed via the network, and information is input according to the screen generated by the input / output unit 14. Thereby, sensor side metadata or application side metadata is generated and stored in the storage unit 11. In this example, an example in which a data provider generates sensor-side metadata will be described, but the same applies to a case where a data user generates application-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.
  • “Changeable” indicates that the content change of the item is permitted when a mismatch occurs in the matching. That is, if there is room for examination in the content of the item, the check box is turned on. For example, in the example of FIG. 3, a consideration of “100 yen or more” is set, but if it is not possible to conclude with consideration, if it is possible to consider making it less than 100 yen, a “changeable” check box Turn on.
  • Matching is a process performed by the matching unit 12.
  • the application-side metadata registered in the storage unit 11 and the sensor-side metadata are compared with each other. This is a process of issuing a data flow control command of sensing data from the corresponding sensor to the application. Matching is executed when metadata is newly registered.
  • FIG. 4 is a flowchart of matching processing executed when sensor-side metadata is registered.
  • 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 no match is found, 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 If there is an item that does not match in step S13 and the pair is not established, a process for correcting the item is tried. This process will be described later with reference to FIG.
  • 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 manages the data flow control command for the sensor 21 (or the sensor 21).
  • the data is transmitted to the sensor network adapter 22) (step S18).
  • 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 need to completely match. That is, if there is even one item that does not match, the pair is not established, and there is a case where both the data provider and the data user lose opportunity. Therefore, in the present embodiment, a flag indicating whether change is possible is added to the comparison target item included in the metadata, and when some items do not match, the sensor network server 10 has information set in the field. Adjust items based on
  • FIG. 5 is a flowchart illustrating processing performed by the adjustment unit 13.
  • step S21 it is determined in step S21 whether the number of items in which the mismatch has occurred is equal to or less than a predetermined number (for example, three).
  • a predetermined number for example, three.
  • the process proceeds to step S22.
  • the number of items in which the mismatch has occurred exceeds a predetermined number, it is determined that adjustment is difficult, and the pair is not established.
  • the predetermined number is an example and may be any number.
  • step S22 it is determined whether or not all changeable flags of the mismatched items are “changeable” in either the sensor-side metadata or the application-side metadata. As a result, if the determination is affirmative, the process proceeds to step S23. If the determination is negative, the pair is not established.
  • step S22 is affirmative.
  • step S23 in order to establish a pair, the user is inquired whether or not the item for which “change is possible” may be changed.
  • the inquiry is typically made by e-mail, but other means may be used.
  • the text as shown in FIG. 7 may be transmitted via e-mail or a messaging service, and a response from the user may be acquired via a Web server.
  • the case where there is only one item to be corrected is illustrated here, when there are a plurality of items to be corrected, all the changes are presented to the user, and whether or not the change is approved for all items is determined. Inquire.
  • step S24 an answer from the user is acquired, and it is determined whether or not the change can be performed. For example, when the user's consent to change the consideration of “50 yen or less” to “100 yen or less” is obtained, the item is changed to “100 yen or less”. When consent is not obtained (including the case where no answer is received within a predetermined time), it is assumed that the pair is not established. As a result, the comparison target items are matched, and as a result, a pair is established.
  • the sensor network server confirms whether or not the item can be changed when a mismatched item occurs as a result of matching between the metadata, and responds to the obtained answer. Based on this, the item is automatically corrected so that the pair is established. Thereby, the establishment rate of a pair can be improved.
  • an example in which an inquiry is made to the data user side is given.
  • the inquiry may be made to the data provider side.
  • the inquiry may be made to either. For example, an inquiry may be made later to the side that registered the metadata, or an inquiry may be made to the side that registered the metadata first.
  • a part may be corrected on the sensor side and the rest on the application side.
  • an inquiry may be made to both the data provider and the data user. In this case, the user may be notified that the other party is waiting for approval. Further, when either one of the approvals is not obtained, the other approval may be canceled.
  • the second embodiment is an embodiment in which correction candidates for changing items are provided in the metadata in advance, and the correction is automatically performed without making an inquiry to the user.
  • a plurality of conditions can be set for each item included in the metadata. For example, in the application ID “A001”, three conditions of “50 yen or less”, “75 yen or less”, and “100 yen or less” are set as the consideration. Each condition represents a first desire, a second desire, and a third desire, and the first hope is usually used in matching.
  • FIG. 9 is a flowchart of the item correction process in the second embodiment. Steps similar to those of the first embodiment are illustrated by dotted lines and description thereof is omitted.
  • step S25 when a mismatch occurs between items, it is determined in step S25 whether there is an item whose condition can be reset. For example, if a mismatch occurs as a result of matching with the first request, it is determined whether the second request is set, and the item is reset using the second request (step S26). Also, if a mismatch occurs as a result of matching with the second choice, it is tried whether the third choice can be set. In this example, the third request is illustrated, but the number is not limited. After resetting, step S13 is executed again to attempt pairing.
  • step S25 it may be determined that the pair is not established as shown in FIG. 9, but an inquiry is transmitted to the user as in the first embodiment, and the pair is determined. Confirmation may be made as to whether or not the conditions for satisfying are acceptable.
  • the candidate metadata candidate is selected in step S17 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 matching process illustrated in FIG. 4 is performed using the sensor-side metadata newly registered as a trigger.
  • the application-side metadata is newly registered. May be executed as a trigger.
  • a sensor and an application, a data provider, and a data user may be read.
  • the matching process is executed at the timing when the metadata is registered.
  • the matching process may be executed periodically.
  • 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.
  • 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 including items 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 including an item indicating the specification of data requested by the application for an application that uses data provided by the device;
  • the at least one hardware processor is: By matching the application-side metadata and the device-side metadata, a combination of the application and a device that can provide data that satisfies the specifications required by the application is extracted, Generating a data flow control command specifying the extracted device and the application; In the extraction, the combination is extracted based on whether the matching target item is matched among the items of the device side metadata and the application side metadata, and when there is a mismatched item
  • a data flow control device that acquires information indicating whether or not the item in which the mismatch has occurred can be changed
  • a data flow control method comprising: With at least one hardware processor A device-side metadata acquisition step for acquiring device-side metadata including an item indicating a specification of data that can be provided by the device for each of a plurality of devices; For an application that uses data provided by the device, an application-side metadata acquisition step for acquiring application-side metadata including an item indicating a specification of data requested by the application; A storage step of storing the device side metadata and application side metadata; A matching step of extracting a combination of the application and a device capable of providing data satisfying the specifications required by the application by performing matching between the application-side metadata and the device-side metadata; A data flow control step for generating a data flow control command specifying the device and the application extracted in the matching step; Run In the matching step, the combination is extracted based on whether the items to be matched among the items of the device-side metadata and the application-side metadata are matched, and there is an item where a mismatch has occurred.
  • a data flow control method comprising: obtaining information indicating whether or not the item

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Databases & Information Systems (AREA)
  • Development Economics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Chemical & Material Sciences (AREA)
  • Analytical Chemistry (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Tourism & Hospitality (AREA)
  • Telephonic Communication Services (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

複数のデバイスのそれぞれについてデバイス側メタデータを取得するデバイス側メタデータ取得手段と、デバイスが提供するデータを利用するアプリケーションについてアプリ側メタデータを取得するアプリ側メタデータ取得手段と、各メタデータを記憶する記憶手段と、アプリケーションと、アプリケーションの要求する仕様を満たすデータを提供可能なデバイスとの組み合わせを抽出するマッチング手段と、デバイスとアプリケーションを特定したデータフロー制御指令を生成するデータフロー制御手段と、を有し、マッチング手段は、各メタデータが有する項目のうち不一致が発生した項目がある場合に、当該不一致が発生した項目の変更可否を表す情報を取得し、当該情報に基づいて不一致が発生した項目を変更する。

Description

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

Claims (8)

  1. 　複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示す項目を含むデバイス側メタデータを取得するデバイス側メタデータ取得手段と、
    　前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示す項目を含むアプリ側メタデータを取得するアプリ側メタデータ取得手段と、
    　前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶手段と、
    　前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記アプリケーションと、前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスとの組み合わせを抽出するマッチング手段と、
    　前記マッチング手段により抽出された前記デバイスと前記アプリケーションを特定したデータフロー制御指令を生成するデータフロー制御手段と、
    　を有し、
    　前記マッチング手段は、前記デバイス側メタデータおよびアプリ側メタデータが有する前記項目のうち、マッチング対象の項目が一致したか否かに基づいて前記組み合わせを抽出し、不一致が発生した項目がある場合に、当該不一致が発生した項目の変更可否を表す情報を取得し、当該情報に基づいて前記不一致が発生した項目を変更する
    　ことを特徴とするデータフロー制御装置。
  2. 　前記マッチング手段は、前記不一致が発生した項目の変更可否を、前記デバイスまたはアプリケーションを管理するユーザに対して問い合わせ、ユーザから取得した回答に基づいて当該項目を変更する
    　ことを特徴とする、請求項１に記載のデータフロー制御装置。
  3. 　前記デバイス側メタデータおよびアプリ側メタデータが有する前記マッチング対象の項目には、変更可否を表すフラグがそれぞれ関連付けられており、
    　前記マッチング手段は、前記不一致が発生した項目が変更可である場合に、前記ユーザに対して問い合わせを行う
    　ことを特徴とする、請求項２に記載のデータフロー制御装置。
  4. 　前記デバイス側メタデータおよびアプリ側メタデータが有する前記マッチング対象の項目には、一つ以上の変更候補がそれぞれ関連付けられており、
    　前記マッチング手段は、項目間に不一致が発生した場合に、前記変更候補に基づいて当該項目を変更する
    　ことを特徴とする、請求項１に記載のデータフロー制御装置。
  5. 　前記マッチング手段は、不一致が発生した項目の数が所定の数より多い場合に、当該項目の変更を行わない
    　ことを特徴とする、請求項１から４のいずれか１項に記載のデータフロー制御装置。
  6. 　前記デバイスは、センシングデータを出力するセンサである
    　ことを特徴とする、請求項１から５のいずれか１項に記載のデータフロー制御装置。
  7. 　コンピュータが、
    　複数のデバイスのそれぞれについて、デバイスが提供可能なデータの仕様を示す項目を含むデバイス側メタデータを取得するデバイス側メタデータ取得ステップと、
    　前記デバイスが提供するデータを利用するアプリケーションについて、アプリケーションが要求するデータの仕様を示す項目を含むアプリ側メタデータを取得するアプリ側メタデータ取得ステップと、
    　前記デバイス側メタデータおよびアプリ側メタデータを記憶する記憶ステップと、
    　前記アプリ側メタデータと前記デバイス側メタデータのマッチングを行うことで、前記アプリケーションと、前記アプリケーションの要求する仕様を満たすデータを提供可能なデバイスとの組み合わせを抽出するマッチングステップと、
    　前記マッチングステップで抽出された前記デバイスと前記アプリケーションを特定したデータフロー制御指令を生成するデータフロー制御ステップと、
    　を実行し、
    　前記マッチングステップでは、前記デバイス側メタデータおよびアプリ側メタデータが有する前記項目のうち、マッチング対象の項目が一致したか否かに基づいて前記組み合わせを抽出し、不一致が発生した項目がある場合に、当該不一致が発生した項目の変更可否を表す情報を取得し、当該情報に基づいて前記不一致が発生した項目を変更する
    　ことを特徴とするデータフロー制御方法。
  8. 　請求項７に記載のデータフロー制御方法の各ステップをコンピュータに実行させることを特徴とするプログラム。
PCT/JP2017/000399 2016-03-15 2017-01-10 データフロー制御装置およびデータフロー制御方法 WO2017159005A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP17766013.1A EP3432245B1 (en) 2016-03-15 2017-01-10 Data-flow control device and data-flow control method
US16/083,863 US10454837B2 (en) 2016-03-15 2017-01-10 Data-flow control device and data-flow control method

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=59850714

Family Applications (1)

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

Country Status (4)

Country Link
US (1) US10454837B2 (ja)
EP (1) EP3432245B1 (ja)
JP (1) JP6458755B2 (ja)
WO (1) WO2017159005A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180157692A1 (en) * 2015-06-30 2018-06-07 Omron Corporation Data flow control device and data flow control method
JP6477935B1 (ja) * 2018-02-13 2019-03-06 オムロン株式会社 前処理判定装置、前処理判定方法及びプログラム
JP6477936B1 (ja) * 2018-02-13 2019-03-06 オムロン株式会社 データ処理装置、データ処理方法及びプログラム
CN111602168A (zh) * 2018-01-23 2020-08-28 索尼公司 信息处理装置、信息处理方法和记录介质
CN112598905A (zh) * 2020-12-14 2021-04-02 苏州智能交通信息科技股份有限公司 一种客流动态分析预警方法、系统和存储介质

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6969362B2 (ja) * 2017-12-21 2021-11-24 オムロン株式会社 センサ管理装置とその方法およびプログラム、マッチング装置とその方法およびプログラム
JP7003797B2 (ja) * 2018-03-29 2022-01-21 富士通株式会社 データ推薦装置、方法、プログラム、及びシステム
JP7153500B2 (ja) * 2018-08-09 2022-10-14 富士通株式会社 データ管理装置およびデータ推奨プログラム
JP7150585B2 (ja) * 2018-12-06 2022-10-11 エヌ・ティ・ティ・コミュニケーションズ株式会社 データ検索装置とそのデータ検索方法およびプログラム、エッジサーバとそのプログラム
JP7150584B2 (ja) 2018-12-06 2022-10-11 エヌ・ティ・ティ・コミュニケーションズ株式会社 エッジサーバとそのプログラム
JP7245079B2 (ja) * 2019-03-08 2023-03-23 株式会社日立製作所 計算機システム及びデータのアクセス制御方法
JP7264028B2 (ja) * 2019-12-05 2023-04-25 トヨタ自動車株式会社 情報提供システム、情報提供方法、情報端末及び情報表示方法
WO2021176612A1 (ja) * 2020-03-04 2021-09-10 株式会社日立製作所 マッチング方法及び充電権利譲渡マッチングシステム
JPWO2022044281A1 (ja) * 2020-08-28 2022-03-03
CN112150280B (zh) * 2020-10-16 2023-06-30 北京百度网讯科技有限公司 提升匹配效率的联邦学习方法及设备、电子设备和介质
US20240098143A1 (en) * 2022-06-29 2024-03-21 Amazon Technologies, Inc. Plug-in orchestrator for vehicle data stream subscription system
EP4322022A1 (de) * 2022-08-09 2024-02-14 One Data GmbH Verfahren und system zur bereitstellung von zumindest teilweise strukturierten daten an eine applikation

Citations (5)

* 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 催し物の仲介装置、クライアント装置及び方法並びに記録媒体
JP2003346011A (ja) * 2002-05-29 2003-12-05 Maki Inaba 不動産仲介システムとそれを実現するための方法及びコンピュータプログラム
JP2007300571A (ja) 2006-05-08 2007-11-15 Hitachi Ltd センサネットシステム、センサネット位置特定プログラム
JP5445722B1 (ja) 2012-09-12 2014-03-19 オムロン株式会社 データフロー制御指令発生装置およびセンサ管理装置
WO2014068697A1 (ja) * 2012-10-31 2014-05-08 三菱電機株式会社 カーレンタル支援装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5549976B2 (ja) * 2010-04-20 2014-07-16 株式会社フォーカルワークス 取引装置
GB2485241A (en) * 2010-11-05 2012-05-09 Bluecava Inc Incremental browser-based fingerprinting of a computing device
WO2014030510A1 (ja) * 2012-08-22 2014-02-27 オムロン株式会社 デバイス管理装置及びデバイス管理方法
US9286187B2 (en) * 2012-08-30 2016-03-15 Sap Se Static enforcement of process-level security and compliance specifications for cloud-based systems
US9736882B2 (en) * 2014-01-16 2017-08-15 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for adapting a DRX configuration for a RAN based on a preferred DRX configuration of an associated capillary network
US9978270B2 (en) * 2014-07-28 2018-05-22 Econolite Group, Inc. Self-configuring traffic signal controller

Patent Citations (6)

* 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 催し物の仲介装置、クライアント装置及び方法並びに記録媒体
JP2003346011A (ja) * 2002-05-29 2003-12-05 Maki Inaba 不動産仲介システムとそれを実現するための方法及びコンピュータプログラム
JP2007300571A (ja) 2006-05-08 2007-11-15 Hitachi Ltd センサネットシステム、センサネット位置特定プログラム
JP5445722B1 (ja) 2012-09-12 2014-03-19 オムロン株式会社 データフロー制御指令発生装置およびセンサ管理装置
WO2014041826A1 (ja) * 2012-09-12 2014-03-20 オムロン株式会社 データフロー制御指令発生装置およびセンサ管理装置
WO2014068697A1 (ja) * 2012-10-31 2014-05-08 三菱電機株式会社 カーレンタル支援装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3432245A4

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180157692A1 (en) * 2015-06-30 2018-06-07 Omron Corporation Data flow control device and data flow control method
US11748326B2 (en) * 2015-06-30 2023-09-05 Omron Corporation Data flow control device and data flow control method
CN111602168A (zh) * 2018-01-23 2020-08-28 索尼公司 信息处理装置、信息处理方法和记录介质
JP6477935B1 (ja) * 2018-02-13 2019-03-06 オムロン株式会社 前処理判定装置、前処理判定方法及びプログラム
JP6477936B1 (ja) * 2018-02-13 2019-03-06 オムロン株式会社 データ処理装置、データ処理方法及びプログラム
WO2019159488A1 (ja) * 2018-02-13 2019-08-22 オムロン株式会社 データ処理装置、データ処理方法及びプログラム
JP2019139544A (ja) * 2018-02-13 2019-08-22 オムロン株式会社 データ処理装置、データ処理方法及びプログラム
JP2019140550A (ja) * 2018-02-13 2019-08-22 オムロン株式会社 前処理判定装置、前処理判定方法及びプログラム
WO2019159487A1 (ja) * 2018-02-13 2019-08-22 オムロン株式会社 前処理判定装置、前処理判定方法及びプログラム
CN112598905A (zh) * 2020-12-14 2021-04-02 苏州智能交通信息科技股份有限公司 一种客流动态分析预警方法、系统和存储介质

Also Published As

Publication number Publication date
EP3432245A4 (en) 2019-10-09
JP6458755B2 (ja) 2019-01-30
US10454837B2 (en) 2019-10-22
JP2017167748A (ja) 2017-09-21
US20190036830A1 (en) 2019-01-31
EP3432245B1 (en) 2021-11-17
EP3432245A1 (en) 2019-01-23

Similar Documents

Publication Publication Date Title
JP6458755B2 (ja) データフロー制御装置およびデータフロー制御方法
JP6465012B2 (ja) データフロー制御装置およびデータフロー制御方法
JP6365519B2 (ja) データフロー制御装置およびデータフロー制御方法
JP5760716B2 (ja) アプリ提供システム、アプリ提供方法、情報処理装置及び情報処理プログラム
US9219608B2 (en) Apparatus and method for sharing contents of Social Network Service in communication system
US10798099B2 (en) Enhanced value component predictions using contextual machine-learning models
EP3370201A1 (en) Data distribution management system
JP6693506B2 (ja) センサネットワークシステム
US10484488B2 (en) Method for dynamic and automatic creation of user interfaces
WO2014002184A1 (ja) 設備管理システム及びプログラム
JP6372508B2 (ja) データフロー制御装置およびデータフロー制御方法
KR20120095573A (ko) 데이터 공유 시스템 및 방법
JP6587970B2 (ja) 契約機器の設定方法、通知の方法、通信システム、情報処理装置、及びプログラム
JP6376159B2 (ja) データフロー制御装置およびデータフロー制御方法
JP2012208661A (ja) 情報提供システム、通信装置及び情報提供方法
El-Moursy et al. Home Automation Using Augmented Reality (HAAR)
JP2012003437A (ja) Ｐｕｓｈ型情報配信システム及びｐｕｓｈ型情報配信方法
JP2015135686A (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: 2017766013

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017766013

Country of ref document: EP

Effective date: 20181015

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

Ref document number: 17766013

Country of ref document: EP

Kind code of ref document: A1