WO2023007834A1 - 情報処理装置、情報処理システム、情報処理方法、および情報処理プログラム - Google Patents

情報処理装置、情報処理システム、情報処理方法、および情報処理プログラム Download PDF

Info

Publication number
WO2023007834A1
WO2023007834A1 PCT/JP2022/013150 JP2022013150W WO2023007834A1 WO 2023007834 A1 WO2023007834 A1 WO 2023007834A1 JP 2022013150 W JP2022013150 W JP 2022013150W WO 2023007834 A1 WO2023007834 A1 WO 2023007834A1
Authority
WO
WIPO (PCT)
Prior art keywords
iotsp
data
information processing
node
information
Prior art date
Application number
PCT/JP2022/013150
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 CN202280051020.4A priority Critical patent/CN117693745A/zh
Priority to US18/580,167 priority patent/US20240340344A1/en
Publication of WO2023007834A1 publication Critical patent/WO2023007834A1/ja

Links

Images

Classifications

    • 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
    • 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/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • 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/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G06F16/909—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using geographical or spatial information, e.g. location
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y10/00—Economic sectors
    • G16Y10/75—Information technology; Communication
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y30/00—IoT infrastructure
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y40/00—IoT characterised by the purpose of the information processing
    • G16Y40/30—Control

Definitions

  • the present disclosure relates to an information processing device, an information processing system, an information processing method, and an information processing program.
  • IoT Internet of Things
  • Examples include collection of information on factory equipment, collection of inventory information, and collection of environmental information (see, for example, Non-Patent Document 1).
  • IoT systems are closed and used by themselves, but it is believed that more advanced services can be provided to users by linking multiple IoT systems.
  • the "user” here refers to people who use the services provided by the IoT system, as well as things other than people that connect and communicate with the IoT system (IoT devices, sensor devices, machine type communication devices, etc.), people
  • IoT devices IoT devices, sensor devices, machine type communication devices, etc.
  • sensor devices such as surveillance cameras installed in shopping malls are often not integrated as IoT systems, but if such sensor devices can be integrated into existing IoT systems and used, the types of data that can be acquired will increase. It increases, and the area from which data can be acquired expands.
  • oneM2M is a standardization body for M2M (Machine to Machine) systems and IoT systems, and defines connections between these IoT systems (see, for example, non-patent documents 3 and 4).
  • Patent Documents 1 to 5 also propose various technologies related to cooperation of IoT systems.
  • IoT Service Provider an organization that holds only sensor devices that have not been integrated as an IoT system.
  • the present disclosure proposes a new and improved information processing device, information processing system, information processing method, and information processing program that can easily realize cooperation between multiple IoTSPs and sensor providers.
  • an information processing device that operates as a first IoTSP that provides a service that allows a user to acquire sensor data, and performs communication with a second IoTSP other than the first IoTSP a communication unit; and a control unit that searches for the sensor data corresponding to the acquisition request of the user via an application and responds to the user with the searched sensor data, wherein the control unit responds to the acquisition request. Search the sensor data from the second IoTSP via the communication unit based on the included identifier of the second IoTSP and policy information indicating whether information can be shared between IoTSPs, and when searching for the sensor data, An information processing device is provided that uses a protocol interface that includes the same procedures between an application and the first IoTSP.
  • an information processing method using an information processing device that operates as a first IoTSP that provides a service for allowing a user to acquire sensor data, wherein the second IoTSP other than the first IoTSP , searching for the sensor data corresponding to the user's acquisition request via an application, and responding to the user with the searched sensor data, wherein the responding
  • the sensor data is retrieved from the second IoTSP through executing the communication based on the identifier of the second IoTSP included in the acquisition request and policy information indicating whether or not information can be shared between IoTSPs. and using a protocol interface including the same procedures between said application and said first IoTSP when retrieving said sensor data.
  • an information processing program for causing a computer that operates as a first IoTSP that provides a service for acquiring sensor data to a user to function, wherein the computer includes, other than the first IoTSP executing communication with a second IoTSP, searching for the sensor data corresponding to the user's acquisition request via an application, and responding to the user with the searched sensor data; The responding is performed from the second IoTSP to the sensor through executing the communication based on the identifier of the second IoTSP included in the acquisition request and policy information indicating whether information can be shared between IoTSPs.
  • An information processing program is provided for retrieving data and using a protocol interface including the same procedures between said application and said first IoTSP when retrieving said sensor data.
  • FIG. 2 illustrates the architecture of oneM2M
  • FIG. 3 illustrates CSE in oneM2M
  • FIG. 4 is a diagram showing the relationship between each class of Area, Pseudo Sink, Node, and Mobile Node.
  • FIG. 4 is a diagram showing the relationship between instances of Area, Pseudo Sink, Node, and Mobile Node
  • 1 is a diagram illustrating a configuration example of an IoTSP cooperation system proposed in an embodiment of the present disclosure
  • FIG. 10 is a diagram showing an example of Area instance data of Area11 (initial state); It is a figure which shows the installation procedure of Node.
  • FIG. 10 is a diagram illustrating an example structure of a node installation request message;
  • FIG. 10 is illustrating an example structure of a node installation request message
  • FIG. 10 is a diagram showing an example structure of instance data of Pseudo Sink 11 in a node installation request message;
  • FIG. 10 is a diagram showing a structure example of instance data of Node 11 in a Node installation request message;
  • FIG. 10 is a diagram showing a structure example of instance data of Node 12 in a Node installation request message;
  • FIG. 10 is a diagram showing a structural example of an authentication authorization request message (1);
  • FIG. 10 is a diagram showing a structural example of an authentication authorization response message;
  • FIG. 10 is a diagram illustrating an example structure of a Node registration request message;
  • FIG. 10 is a diagram illustrating a structural example of instance data of Area 11 after Node 11 registration;
  • FIG. 10 is a diagram showing an example structure of instance data of Pseudo Sink 11 after Node 11 registration;
  • FIG. 10 is a diagram illustrating an example structure of a Node registration response message;
  • FIG. 10 is a diagram illustrating an example structure of a Node installation response message;
  • FIG. 4 is a diagram showing an example of the structure of instance data of Pseudo Sink 21;
  • 4 is a diagram showing a structural example of instance data of Node 21;
  • FIG. It is a figure which shows the removal procedure of Node.
  • FIG. 10 is a diagram illustrating an example structure of a Node removal request message;
  • FIG. 10 is a diagram showing an example structure of a Node deletion request message;
  • FIG. 10 is a diagram illustrating an example structure of a Node deletion response message
  • FIG. 10 is a diagram illustrating an example structure of a Node removal response message
  • FIG. 4 is a diagram showing a configuration change notification procedure between IoTSPs
  • FIG. 11 is a diagram showing an example structure of a change acquisition request message
  • FIG. 10 is a diagram illustrating an example structure of a change acquisition response message
  • FIG. 10 is a diagram showing a structural example of a change notification message (1)
  • FIG. 10 is a diagram showing an example structure of a change registration request message
  • FIG. 11 is a diagram showing an example structure of a change registration response message
  • FIG. 13 is a diagram showing a structural example of a change notification message (2); It is a figure which shows the notification procedure (1) of sensor data from Node.
  • FIG. 10 is a diagram showing an example structure of a data notification message (1);
  • FIG. 10 is a diagram showing a structural example of a data registration request message (1);
  • It is a figure which shows the structure example of a data registration response message.
  • It is a figure which shows the notification procedure (2) of sensor data from Node.
  • FIG. 10 is a diagram showing a structural example of a data notification message (2);
  • FIG. 10 is a diagram showing an example structure of a data notification request message;
  • FIG. 10 is a diagram showing a structural example of an authentication authorization request message (2);
  • FIG. 10 is a diagram showing a structural example of a data registration request message (2); FIG. 10 is a diagram showing an example structure of a data notification response message; FIG. 10 is a diagram showing a sensor data notification procedure (3) from a Node; Fig. 10 shows an example structure of a mobile data notification message; FIG. 10 is a diagram showing a structural example of an authentication authorization request message (3); FIG. 10 is a diagram showing a structural example of a data registration request message (3); FIG. 10 is a diagram showing a data acquisition procedure by IoT APP; FIG. 11 is a diagram showing an example of a search range; FIG. FIG. 10 is a diagram showing an example structure of a data acquisition request message; FIG.
  • FIG. 10 is a diagram showing a structural example of an authentication authorization request message (4);
  • FIG. 10 is a diagram showing an example structure of a data acquisition response message;
  • FIG. 10 illustrates a graph solution procedure;
  • FIG. 4 is a diagram showing an example structure of a graph resolution request message (1);
  • FIG. 10 is a diagram showing an example structure of a graph search request message (1);
  • FIG. 10 is a diagram showing an example structure of a graph search response message (1);
  • FIG. 10 is a diagram showing an example structure of a graph resolution response message (1);
  • FIG. 10 is a diagram showing an example structure of a graph resolution request message (2);
  • FIG. 10 is a diagram showing an example structure of a graph resolution response message (2); It is a figure which shows a graph search procedure.
  • FIG. 10 is a diagram showing a structural example of an authentication authorization request message (4);
  • FIG. 10 is a diagram showing an example structure of a data acquisition response message;
  • FIG. 10 illustrates a graph
  • FIG. 13 is a diagram showing an example structure of a graph resolution request message (3);
  • FIG. 10 is a diagram showing a structural example of an authentication authorization request message (5);
  • FIG. 10 is a diagram showing an example structure of a graph search request message (2);
  • FIG. 10 is a diagram showing an example structure of a graph search response message (2);
  • FIG. 10 is a diagram showing an example structure of a graph resolution response message (3); It is a figure which shows a data solution procedure (1).
  • FIG. 10 is a diagram showing an example structure of a data resolution request message (1);
  • FIG. 10 is a diagram showing an example structure of a data search request message (1);
  • It is a figure which shows the structure example of a data search response message.
  • FIG. 10 is a diagram showing an example structure of a data resolution response message;
  • FIG. 10 is a diagram showing an example structure of a data resolution response message;
  • FIG. 10 is a diagram showing an example structure of a data resolution response message;
  • FIG. 10 is a diagram showing a data resolution procedure (2);
  • FIG. 10 is a diagram showing an example structure of a data resolution request message (2);
  • FIG. 10 is a diagram showing an example structure of a data search request message (2);
  • 1 is an explanatory diagram showing a functional configuration example of an information processing device according to an embodiment of the present disclosure;
  • FIG. It is explanatory drawing (1) of a modification.
  • FIG. 11 is an explanatory diagram (part 3) of a modified example; It is explanatory drawing (4) of a modification. It is explanatory drawing (5) of a modification.
  • IoTSP linking Also, hereinafter, linking multiple IoTSPs and sensor providers is referred to as "IoTSP linking”.
  • Notification of sensor data from Node (2) 1.4.13. Notification of sensor data from Node (3) 1.4.14. Data Acquisition by IoT App 1.4.15. Pseudo Sink Resolution Procedure 1.4.16. Node resolution procedure 1.4.17. Data resolution procedure (1) 1.4.18. Data resolution procedure (2) 1.5. Functional configuration example of information processing apparatus 2 . Summary 2.1. Effect 2.2. Modification
  • FIG. 1 is a diagram showing the architecture of oneM2M.
  • FIG. 2 is a diagram showing a CSE (Common Services Entity) in oneM2M.
  • each oneM2M service provider has one IN (Infrastructure Node), and a CSE exists within the IN. Connects to other oneM2M service domains with an interface called Mcc' owned by CSE (IN-CSE) within IN.
  • CSE CSE
  • the CSE contains many functions and is complex, so connection between oneM2M service providers is not easy. Therefore, it can be said that it is necessary to simplify the interface between IoT systems in order to realize connection between IoT systems, that is, IoTSP cooperation.
  • management information such as the areas covered by each IoTSP and the installation locations of sensors, as well as sensor measurement data.
  • the IoTSP that publishes the information can determine the IoTSP to which it is published.
  • oneM2M defines an interface for IoT system cooperation, but it is very complicated and difficult to implement. Therefore, in the embodiment of the present disclosure, the interface of the IoT system (IoTSP) is unified into a query language (for example, GraphQL) to facilitate cooperation between IoTSPs. Specifically, the proposed interface consists of queries to graph databases and queries to time-series databases.
  • an App API Application Programming Interface
  • the App API converts a request from the application into a query language so that the application can easily access the IoTSP.
  • IoTSP In addition to sensor nodes, which are devices equipped with sensors, IoTSP requires servers and databases that accept queries. Therefore, in the embodiment of the present disclosure, an individual or a small organization that owns a sensor node but is difficult to operate as an IoTSP is positioned as a sensor provider, and the sensor provider provides (sells) sensor data to the IoTSP.
  • the Pseudo Sink installed in the sensor provider and the Pseudo Sink installed in the IoTSP cooperate to provide the sensor data of the sensor provider to the IoTSP.
  • shared information is propagated along a predetermined route.
  • the IoTSP that is the source of the information has a policy of sharing information with which IoTSP and not sharing information with which IoTSP.
  • a field called policy is provided as a data property of a Pseudo Sink instance or a Node instance, and an IoTSP that permits sharing or an IoTSP that does not permit sharing can be described in the policy field. .
  • Patent Literature 1 proposes a connection device for connecting a robot and an IoT platform and connecting different IoT platforms.
  • connections are made between IoT platforms (IoTSPs) without using connection devices.
  • Patent Document 2 proposes a method of setting a relay device or the like on the network side in order to eliminate the need to add functions to an IoT terminal.
  • the relay device or the like has functions such as name resolution, L3 address allocation, and configuration information distribution.
  • the embodiments of the present disclosure focus on connections between IoT networks (IoTSPs) on the premise that the IoT terminals are properly connected to the IoT networks (IoTSPs).
  • IoT gateway that connects IoT devices such as temperature and humidity sensors to networks is also known.
  • a method is adopted in which a whitelist, which lists permitted communications, is installed in the IoT gateway.
  • Patent Literature 3 proposes a method of quickly creating a whitelist for an IoT gateway.
  • the embodiments of the present disclosure focus on connections between IoT networks (IoTSPs) on the premise that the IoT terminals are securely connected to the IoT networks (IoTSPs).
  • Patent Document 4 proposes a technique for realizing such network separation.
  • the embodiments of the present disclosure focus on connections between IoT networks (IoTSPs) on the premise that the IoT terminals are securely connected to the IoT networks (IoTSPs).
  • a device to connect a device to a restricted network that requires access credentials, such as a Wi-Fi network
  • the user scans for available networks, requests to connect to an available network, and then Manually enter the credentials to connect to the network.
  • WO 2005/010002 proposes a technique for automatically enabling devices to connect to allow automatic configuration to restricted networks that require access credentials.
  • the embodiments of the present disclosure focus on connections between IoT networks (IoTSPs) on the premise that the IoT terminals are securely connected to the IoT networks (IoTSPs).
  • IoTSP that provides weather data (temperature, humidity, wind direction, wind speed, atmospheric pressure, etc.) to users, and cooperation between sensor providers that have sensor devices that measure weather data, that is, IoTSPs and sensor providers that provide similar sensor data
  • IoTSP-A one IoTSP
  • IoTSP-B another IoTSP
  • sensor provider-A provides measured weather data to IoTSP-A.
  • the cooperation of IoTSP-A, IoTSP-B, and sensor provider-A enables the user to obtain meteorological data in a wider area.
  • IoTSP-A for example, we assume cooperation with IoTSP-C that provides data on the number of people in each downtown area in the Kanto region, that is, cooperation between IoTSP and sensor providers that provide heterogeneous sensor data.
  • IoTSP-C by linking IoTSP-A and IoTSP-C, the user can know the relationship between weather conditions and crowds.
  • a configuration example for realizing IoTSP cooperation will be specifically described below.
  • Node A device equipped with a sensor is called a "node”. Since nodes are installed in real space in IoT systems, how to handle location information plays an important role. Node is assumed to be fixed and installed. On the other hand, a Node that moves by mounting a sensor such as a car or a smart phone is called a "Mobile Node”. In addition, below, Node may be written as a "node” with a katakana. A Node is an example of a “sensor node”.
  • a geographical area is represented by a 0.1 minute (6 seconds) square surrounded by longitude and latitude lines. 0.1 minute of latitude and longitude is about 185m near Japan. Note that the length of one side of Area may be arbitrary.
  • Nodes and Mobile Nodes transmit sensor data via wireless communication, but we will introduce a "Pseudo Sink” as a module that terminates wireless communication from Nodes and connects to the wired network.
  • a wireless base station may serve as a pseudo sink, or a dedicated device may be installed as a pseudo sink.
  • Pseudo Sink is installed in Area and has latitude and longitude information.
  • the relationship between geographic information and nodes is represented by an ontology.
  • ontology relationships between things are represented by a subject, a predicate (property), and an object (object).
  • the object can be the subject of another triad, so the relations of things spread out in a web.
  • a type of thing is called a "class”, and a concrete thing is expressed as an "instance" of the corresponding class.
  • object property A predicate that expresses the relationship between classes or instances
  • a predicate that expresses the relationship between a class or instance and its attributes is called a "data property”.
  • FIG. 3 shows the relationship between the Area class, Pseudo Sink class, Node class, and Mobile Node class.
  • FIG. 3 is a diagram showing the relationship between each class of Area, Pseudo Sink, Node, and Mobile Node.
  • the Area class has object properties of "isEastOf", “isWestOf”, “isSouthOf”, “isNorthOf” and an Area Represents the north, south, east, and west adjacencies between instances.
  • the Area class has data properties such as Area ID (Area identifier), SW Lat, Lon (latitude and longitude of the southwest corner), NW Lat, Lon (latitude and longitude of the northeast corner), and Description (annotation).
  • An example of the annotation of the Area instance is "within Shinagawa-ku, Tokyo".
  • the Area class expresses the relationship with the Pseudo Sink instance by the object property "contains”.
  • the Pseudo Sink class has data properties such as IoTSP ID (IoTSP identifier), Pseudo Sink ID (Pseudo Sink identifier), Lat, Lon (latitude and longitude), Description (annotation), Policy (policy for disclosure of management information to other IoTSPs), etc. have.
  • An example of an annotation for a Pseudo Sink instance is "Osaki Station”.
  • An example of Policy may be a list of IoTSP identifiers that permit disclosure of information about the Pseudo Sink instance.
  • the Pseudo Sink class expresses the relationship with the Area instance by the object property "isInstalledIn", and the relationship with the Node instance by the object property "collectsDataFrom".
  • the Node class has data properties such as Node ID (Node identifier), Capabilities (function), Description (annotation), Policy (whether or not information can be disclosed to other IoTSPs).
  • the Node class expresses the relationship between Node instances by the object property "isCollocatedWith (located in the same Pseudo Sink)", and expresses the relationship between Pseudo Sink instances by the object property "sendsDataTo (sends data)”.
  • the Mobile Node class Define the Mobile Node class as a subclass of the Node class.
  • the Mobile Node subclass has data properties such as IoTSP ID (IoTSP identifier), Date, Time (date and time), Lat, Lon (latitude and longitude), and Credential (authentication information) in addition to the data properties possessed by the Node class.
  • IoTSP ID IoTSP identifier
  • Date Date
  • Time date and time
  • Lat Lat
  • Lon latitude and longitude
  • Credential authentication information
  • FIG. 4 shows an example of the relationship between Area instances, Pseudo Sink instances, Node instances, and Mobile Node instances.
  • FIG. 4 is a diagram showing the relationship between instances of Area, Pseudo Sink, Node, and Mobile Node.
  • Area 11 is connected to adjacent Areas 12 to 15 by object properties "isEastOf", “isWestOf”, “isSouthOf", or “isNorthOf". Furthermore, Area 11 is connected to Pseudo Sink 11 by object properties "contains” and “isInstalledIn”.
  • Pseudo Sink 11 is connected to Node 11 and Node 12 with object properties "CollectsDataFrom” and “sendsDataTo". Also, Node11 and Node12 are connected by an object property "isCollocatedWith".
  • Pseudo Sink 11 is connected to Mobile Node 13 by object properties "CollectsDataFrom" and "sendsDataTo".
  • Mobile Node 13 is temporarily connected to Pseudo Sink 11 because it entered the wireless communication range of Pseudo Sink 11 while moving.
  • the above instance information is stored in a Graph DB, which will be described later.
  • the connection relationship between the Mobile Node instance and the Pseudo Sink instance is temporary, it is not stored in GraphDB.
  • Area 11 has data properties of the southwest corner latitude "35 degrees 37 minutes 6 seconds" and longitude "139 degrees 43 minutes 36 seconds", and the northeast corner latitude "35 degrees 37 minutes 12 seconds” and longitude "139 seconds”. degree 43 minutes 42 seconds".
  • Pseudo Sink 11 has as data properties the IoTSP identifier "IdIoTSP_1", the Pseudo Sink identifier "IdPSink_11", the Description “Osaki Station”, the latitude “35 degrees 37 minutes 11.85 seconds", and the longitude “139 degrees 43 minutes 41. 06 seconds”. Also, the Policy values are "IdIoTSP_ALL” and “except IdIoTSP_3", indicating that disclosure is possible to all IoTSPs except IoTSP3.
  • Node 11 has the following data properties: Node identifier "IdNode_11”, Capability "Temperature” and “Humidity”, Description “Outdoor Module”, and Policy "IdIoTSP_ALL (open to all other IoTSPs)".
  • Node 12 also has the same data property value as Node 11, but the Policy value is "IoTP_None (undisclosed to other IoTSPs)".
  • Mobile Node 13 has, as data properties, a Node identifier of "IdNode_13", an IoTSP identifier (identifier of IoTSP to which Mobile Node 13 has a contract) of "idIoTSP_1", Capability of "Speed”, Description of "Vehicle”, and Date and Time of "2021". February 10, 10:00:00", latitude and longitude is "35 degrees 37 minutes 12.0 seconds north latitude, 139 degrees 43 minutes 41.0 seconds east longitude", Credential is "CredNode_13", Policy is "IoTSP_ALL" has a value of
  • FIG. 5 shows a configuration example of the proposed system.
  • FIG. 5 is a diagram showing a configuration example of an IoTSP cooperation system proposed in an embodiment of the present disclosure.
  • the IoTSP cooperation system corresponds to an example of an "information processing system.”
  • Fig. 5 shows four IoTSPs ("IoTSP1" to "IoTSP4") and one sensor provider ("Sensor Provider5").
  • IoTSP1 shows internal details, and IoTSP2 to IoTSP4 are omitted.
  • the number of IoTSPs may be four or more and the number of sensor providers may be two or more.
  • IoTSP1 to IoTSP4 are connected in a straight chain, but the connection form between IoTSPs is not limited to a straight chain. It is assumed that this connection is logical and connected through a secure communication channel. It is also assumed that all IoTSPs are aware of the connection relationship between IoTSPs.
  • each IoTSP determines the connection relationship between IoTSPs and registers it in each IoTSP.
  • all IoTSPs recognize that IoTSP1 to IoTSP4 are connected in a straight chain.
  • each IoTSP has a private key and a public key in a public key cryptosystem. It is assumed that the private key is kept secret by each IoTSP and the public key is shared by all other IoTSPs. Sensor providers may also be included in the concept of "user" herein.
  • User is a user who has a contract with IoTSP.
  • "User1" has a contract with IoTSP1, and obtains sensor data and the like from IoTSP1 using "IoT App1", which is an application for the user.
  • the App API is an application API that converts a request from the application into a query language and accesses the Query Server.
  • 'App API1' receives a request from 'IoT App1', converts it into a query language, and accesses 'Query Server1'.
  • the App API realizes inter-IoTSP cooperation using a query language.
  • App API1 cooperates with "App API2" in IoTSP2, and realizes cooperation between IoTSP1 and IoTSP2 using a query language.
  • Admin is the administrator of the IoTSP.
  • 'Admin1' manages and operates IoTSP1 via the management API 'Admin API1'.
  • Query Server accepts query language from App API and accesses Sensing DB and Graph DB.
  • Query Server 1 accepts the query language from App API 1 and accesses "Sensing DB 1" and "Graph DB 1".
  • ⁇ AAA (Authentication, Authorization, and Accounting) ⁇ Server is a module that authenticates and authorizes users, administrators, IoTSP, sensor providers, and Mobile Nodes.
  • AAA Server1 authenticates User1, Admin1, and “Mobile Node13".
  • AAA Server2 in App API2 performs authentication and authorization for IoTSP1, etc.
  • Graph DB is a database that stores Area instances, Pseudo Sink instances, Node instances, and Mobile Node instances. It also has functions for registering and searching instance information in the database.
  • Graph DB1 is the Graph DB within IoTSP1.
  • the Sensing DB is a database that stores time-series data of sensor measurements. It also has functions for registering and searching sensor data in the database.
  • Sensing DB1 is the Sensing DB in IoTSP1.
  • Pseudo Sink is a module that collects sensor data from Node.
  • "Pseudo Sink 11” collects sensor data from Node 11 and Mobile Node 13. Furthermore, it is also connected to "Pseudo Sink 51" and collects sensor data from Sensor Provider 5.
  • Nodes and Mobile Nodes are physical modules equipped with sensors.
  • Node 11 and the like are connected to Pseudo Sink 11, and since Mobile Node 13 has entered the wireless communication range of Pseudo Sink 11, Mobile Node 13 is temporarily connected to Pseudo Sink 11.
  • Node 51 is connected to Pseudo Sink 51, and Pseudo Sink 51 is connected to Pseudo Sink 11 in IoTSP1.
  • the "Type" field represents the type of message.
  • Message types include AA Request/Response (authentication authorization request/response), Data Registration Request/Response (data registration request/response), Data Report (data notification), Data Report Request/Response (data notification request/response), DataResolution Request/Response, Data retrieve Request/Response, Data Search Request/Response, Graph Resolution Request/Response , Graph Search Request/Response, Mobile Data Report, Modified Data Report, Modified Data Registration Request/Response, Modified Data Request/Response (update information request/response), Node Delete Request/Response (node deletion request/response), Node Installation Request/Response (node installation request/response), Node Registration Request/Response (noo
  • the “Capability” field represents the functions that the Node has.
  • the “Credential” field represents credit information. Credential information includes passwords, electronic certificates, and the like.
  • the "Data Format ID” field represents the identifier of the sensor data format.
  • the “End Time” field represents the end date and time.
  • the “ID” field represents the identifier of the entity performing the action. The subjects are the users and administrators of the IoTSP, the IoTSP itself, and the sensor provider itself.
  • the “IoTSP ID” field represents the identifier of the IoTSP.
  • the “Lat” and “Lon” fields represent the latitude and longitude of the Pseudo Sink.
  • the "NE Lat” field and “NE Lon” field represent the latitude and longitude of the northeast corner of the Area.
  • the "No of Nodes” field indicates the number of target Nodes.
  • the “No of Pseudo Sinks” field indicates the number of target pseudo sinks.
  • the "No of Queries” field represents the number of queries.
  • the “No of Values” field represents the number of values.
  • the "Node ID” field represents the identifier of the Node.
  • the “Node Instance Data” field represents Node instance data.
  • the "Pseudo Sink ID” field represents the identifier of the Pseudo Sink.
  • the “Pseudo Sink Instance Data” field represents the instance data of the Pseudo Sink.
  • the "Query” field represents the content of the query.
  • the "Sensor Provider ID” field represents the identifier of the sensor provider.
  • the "Start Time” field represents the start date and time.
  • the “Status” field represents the end state of the operation.
  • the "SW Lat” field and the “SW Lon” field represent the latitude and longitude of the southwest corner of the Area.
  • the “Timestamp” field represents the date and time.
  • the "Value” field represents the answer to the query.
  • the "Area ID” field represents the identifier of the Area instance.
  • the “Area Instance Data” field represents all or part of the Area instance data.
  • the “Capability” field represents the functions possessed by the Node instance. For example, "temperature” and “humidity”.
  • the "collectsDataFrom” field indicates identifiers of Node instances and Mobile Node instances that are connected to the Pseudo Sink instance and collectsDataFrom, which is an object property.
  • the "contains” field represents the identifier of the Pseudo Sink instance that connects the Area instance and the object property “contains”.
  • the "Description” field represents user-friendly annotations.
  • the Description of an Area instance is "inside Shinagawa-ku, Tokyo"
  • the Description of a Pseudo Sink instance is “Osaki Station”
  • the Description of a Node instance is "Outdoor Module”.
  • the "End Time” field represents the end date and time.
  • the "isCollocatedWith” field represents the identifier of the Node instance that is connected to the Node instance by the object property isCollocatedWith.
  • the "isEastOf” field represents the identifier of the Area instance that is connected to the Area instance by the object property isEastOf.
  • the "isInstalledIn” field represents the identifier of the Area instance that is connected to the Pseudo Sink instance with the object property isInstalledIn.
  • the "isNorthOf” field represents the identifier of the Area instance that is connected to the Area instance by the object property isNorthOf.
  • the "isSouthOf” field represents the identifier of the Area instance that is connected to the Area instance by the object property isSouthOf.
  • the "isWestOf” field represents the identifier of the Area instance that is connected to the Area instance by the object property isWestOf.
  • the "NE Lat” and “NE Lon” fields represent the latitude and longitude of the northeast corner of the Area instance.
  • the “Lat” and “Lon” fields represent the latitude and longitude of the Pseudo Sink instance.
  • the "No of Nodes” field represents the number of Node instances of interest.
  • the "No of Pseudo Sinks” field represents the number of Pseudo Sink instances of interest.
  • a "Node ID” field represents an identifier of a Node instance or a Mobile Node instance.
  • the "Node Instance Data” field represents all or part of the Node or Mobile Node instance data.
  • the 'Policy' field represents the IoTSP that publishes the information. The value may be, for example, a list of identifiers of IoTSPs that are permitted to be disclosed, "IdIoTSP_ALL” that permits all IoTSPs, or "IdIoTSP_None” that disallows all IoTSPs.
  • the “Pseudo Sink ID” field represents the identifier of the Pseudo Sink instance.
  • the “Pseudo Sink Instance Data” field represents all or part of the Pseudo Sink instance data.
  • the “sendsDataTo” field indicates the identifier of the Node instance or Mobile Node instance that is connected to the Pseudo Sink instance by means of object property sendsDataTo.
  • the "Start Time” field represents the start date and time.
  • the "SW Lat” field and the “SW Lon” field represent the latitude and longitude of the southwest corner of the Area.
  • the “Timestamp” field represents the date and time.
  • each IoTSP assumes that the instance data of Area shown in FIG. 4 is already stored in the Graph DB.
  • the Area instance data of Area11 before installation of Pseudo Sink 11 is as shown in FIG.
  • FIG. 6 is a diagram showing an example (initial state) of Area instance data of Area11.
  • the identifier for this Area instance is "IdArea_11”.
  • the last modification date and time of this Area instance is “January 15, 2021, 10:00:00”.
  • the latitude and longitude of the southwest corner of this Area are "35 degrees 37 minutes 06 seconds north latitude" and "139 degrees 43 minutes 36 seconds east longitude”.
  • the latitude and longitude of the northeast corner of this Area are "35 degrees 37 minutes 12 seconds north latitude” and "139 degrees 43 minutes 42 seconds east longitude”.
  • the annotation of this Area is "within Shinagawa Ward, Tokyo”.
  • Identifiers of Area instances connected to this Area by isEastOf, isWestOf, isSouthOf, and isNorthOf are respectively "IdArea_12", “IdArea_13", “IdArea_14", and "IdArea_15".
  • FIG. 7 is a diagram illustrating a procedure for installing a Node.
  • FIG. 8 shows a node installation request message.
  • the value of the ID field is "IdAdmin_1”.
  • the value of the Credential field is "CredAdmin_1”.
  • the Pseudo Sink Instance Data field stores instance data of Pseudo Sink 11, which is a Pseudo Sink that collects data from Node 11 and Node 12.
  • the value of the No of Nodes field is "2". Below, the instance data of Node11 and the instance data of Node12 are stored.
  • Fig. 9 shows the instance data of Pseudo Sink 11.
  • the identifier of this Pseudo Sink instance is "IdPSink_11".
  • the last modification date and time of this Pseudo Sink instance is "February 1, 2021, 10:00:00".
  • the information of this Pseudo Sink instance is "disclosure to all other IoTSPs other than IoTSP3".
  • the latitude and longitude of this Pseudo Sink are "35 degrees 37 minutes 11.85 seconds north latitude” and "139 degrees 43 minutes 41.06 seconds east longitude".
  • the annotation on this Pseudo Sink is "Osaki Station”.
  • the Area instance connected to this Pseudo Sink instance by isInstalledIn is "undecided”.
  • the identifiers of the Node instances connected to this Pseudo Sink instance by collectsDataFrom are "IdNode_11" and "IdNode_12".
  • Figure 10 shows the instance data of Node11.
  • the identifier for this Node instance is "IdNode_11”.
  • the date and time when this Node was installed is “February 1, 2021, 10:00 am”.
  • the measurement data of this Node is "openable to all other IoTSPs”.
  • the annotation of this Node is "Outdoor Module”.
  • the functions of this Node are "temperature” and "humidity”.
  • the identifier of the Pseudo Sink instance connected to this Node instance by sendsDataTo is "IdPSink_11".
  • the identifier of the Node instance connected to this Node instance by isCollocatedWith is "IdNode_12".
  • FIG. 11 shows a Node instance representing Node12.
  • the content is the same as in FIG. 10, but since the value of the Policy field is "IdIoTSP_None", the measurement data of this Node is not disclosed to other IoTSPs.
  • Admin API1 When Admin API1 receives the Node installation request message, it sends an authentication authorization request message to AAA Server1 (step S102).
  • FIG. 12 shows an authentication authorization request message.
  • the value of the ID field is "IdAdmin_1”.
  • the value of the Credential field is "CredAdmin_1”.
  • AAA Server 1 When AAA Server 1 receives the authentication authorization request message, it verifies the authenticity and authority of the entity indicated by the ID field. If the confirmation succeeds, AAA Server1 sends an authentication authorization response message to Admin API1 (step S103).
  • FIG. 13 shows an authentication authorization response message. The value of the Status field is "OK" indicating normal termination of processing.
  • Admin API 1 When Admin API 1 receives the authentication authorization response message, it sends a Node registration request message to Graph DB 1 (step S104).
  • FIG. 14 shows the Node registration request message.
  • the values of the Pseudo Sink Instance Data field, No of Nodes field, and Node Instance Data field of the Node registration request message are the same as those of the Node installation request message shown in FIG.
  • Graph DB1 When Graph DB1 receives the Node registration request message, it stores Pseudo Sink instance data and Node instance data in the database. Furthermore, the instance data of Area 11 where Pseudo Sink 11 is installed is updated as shown in FIG. The value of the Timestamp field has been updated with respect to FIG. In addition, a contains field is added with a value of "IdPSink_11". Along with this, the instance data of Pseudo Sink 11 is updated as shown in FIG. That is, the value of the isInstalledIn field is "IdArea — 11".
  • FIG. 17 shows the Node registration response message.
  • the value of the Status field is "OK" indicating normal termination of processing.
  • Admin API1 When Admin API1 receives the Node registration response message, it sends a Node installation response message to Admin APP1 (step S106).
  • FIG. 18 shows a Node installation response message.
  • the Status field is "OK" indicating normal termination.
  • FIG. 19 shows the instance data of Pseudo Sink 21.
  • FIG. 20 shows the instance data of Node21.
  • FIG. 21 shows a procedure for removing a Node in IoTSP1.
  • FIG. 21 is a diagram illustrating a Node removal procedure.
  • Admin1 sends a Node removal request message to Admin API1 via Admin APP1 (step S201).
  • FIG. 22 shows a Node removal request message.
  • the value of the ID field is "IdAdmin_1”.
  • the value of the Credential field is "CredAdmin_1”.
  • the No of Nodes field represents the number of Nodes to be removed. Below, the Node ID field follows the number of values in the No of Nodes field.
  • Admin API1 When Admin API1 receives the Node removal request message, it sends an authentication authorization request message to AAA Server1 (step S202).
  • FIG. 12 shows an authentication authorization request message.
  • AAA Server 1 When AAA Server 1 receives the authentication authorization request message, it verifies the authenticity and authority of the entity indicated by the ID field. If the confirmation succeeds, AAA Server1 sends an authentication authorization response message to Admin APP1 (step S203).
  • FIG. 13 shows an authentication authorization response message.
  • FIG. 23 shows a Node deletion request message.
  • the values of the No of Nodes field and the Node ID field of the Node deletion request message are the same as those of the Node removal request message shown in FIG.
  • Graph DB1 When Graph DB1 receives the Node deletion response message, it deletes the Node instance indicated by the Node ID field from the database. Along with this, for the Pseudo Sink instance indicated by the sendsDataTo field of the Node instance to be deleted, the corresponding collectsDataFrom field is deleted. If the number of the collectsDataFrom field becomes 0 as a result of deletion, the corresponding Pseudo Sink Instance Data is also deleted.
  • Graph DB1 sends a Node deletion response message to Admin API1 (step S205).
  • FIG. 24 shows the Node deletion response message.
  • the Status field is "OK" indicating normal termination.
  • Admin API1 When Admin API1 receives the Node deletion response message, it sends a Node removal response message to IoTSP Admin1 (step S206).
  • FIG. 25 shows the Node removal response message.
  • the Status field is "OK" indicating normal termination.
  • FIG. 26 shows an example of a procedure for notifying other IoTSPs of the configuration change of IoTSP1.
  • FIG. 26 is a diagram showing a configuration change notification procedure between IoTSPs.
  • App API1 in IoTSP1 sends a change acquisition request message to Query Server1 in order to know the configuration change in IoTSP1 (step S301).
  • FIG. 27 shows the change acquisition request message.
  • the Timestamp field indicates that information updated after the date and time indicated in this field is requested, and in this example, it is "February 1, 2021, 00:00:00".
  • Query Server 1 When Query Server 1 receives the change acquisition request message, it queries Graph DB 1 for configuration information changed after the time indicated by the Timestamp field (step S302). In addition, in FIG. 26, the procedure for querying the Graph DB1 is omitted.
  • FIG. 28 shows the change acquisition response message.
  • the Status field is "OK” indicating normal termination. Since one Pseudo Sink (Pseudo Sink 11) was added after the specified time, the value of the No of Pseudo Sinks field becomes "1". The contents of the Pseudo Sink Instance Data field are the same as the instance data of the Pseudo Sink 11 shown in FIG.
  • App API1 When App API1 receives the change acquisition response message, it sends a change notification message to App API2 in IoTSP2, which is the predetermined transfer destination (step S304).
  • FIG. 29 shows the change notification message.
  • the value of the No of Pseudo Sinks field is "1".
  • the value of the Pseudo Sink Instance Data field is the Pseudo Sink 11 instance data shown in FIG. 16 encrypted with the IoTSP2 public key. That is, at this time, App API 1 determines public/non-disclosure destinations based on the Policy field shown in FIG. 16 (see step S304). In the case of the example of FIG. 16, only IoTSP3 is the private party, so App API1 encrypts the instance data of Pseudo Sink11 with the public key of IoTSP2.
  • App API2 When App API2 receives the change notification message, it uses its own private key to decrypt the Pseudo Sink Instance Data field. Next, App API2 sends a change registration request message to Query Server2 (step S305).
  • FIG. 30 shows the change registration request message.
  • the value of the No of Pseudo Sinks field is "1".
  • the value of the Pseudo Sink Instance Data field is the same as the instance data of Pseudo Sink 11 shown in FIG.
  • Query Server 2 When Query Server 2 receives the change registration request message, it accesses Graph DB 2 and registers the change information (step S306). In addition, in FIG. 26, the procedure for registration in the Graph DB2 is omitted.
  • Query Server 2 sends a change registration response message to App API 2 (step S307).
  • FIG. 31 shows the change registration response message.
  • the value of the Status field is "OK" indicating normal termination.
  • App API2 sends a change registration request message to Query Server2 and also sends a change notification message to App API3 in IoTSP3 (step S308).
  • FIG. 32 shows the change notification message.
  • the value of the No of Pseudo Sinks field is "1".
  • App API2 refers to the policy field of the instance data of Pseudo Sink 11 shown in FIG.
  • the instance data of Pseudo Sink 11 is encrypted with the public key of IoTSP4, which is the transfer destination, and stored in the Pseudo Sink Instance Data field. That is, at this time, App API 2 determines public/non-disclosure destinations based on the Policy field shown in FIG. 16 (see step S308).
  • IoTSP3 is the private party, so AppAPI2 encrypts the instance data of Pseudo Sink 11 with the public key of IoTSP4.
  • App API3 When App API3 receives the change notification message, it attempts to decrypt the Pseudo Sink Instance Data field with its own private key, but this field cannot be decrypted because it is encrypted with the public key of IoTSP4. Therefore, App API3 sends a change notification message to App API4 in IoTSP4, which is the next transfer destination (step S309).
  • FIG. 32 shows the change notification message. That is, at this time, App API 3 can be said to determine the public/private party of the Policy field by not being able to decrypt the Pseudo Sink Instance Data field with its own private key (see step S309).
  • App API4 When App API4 receives the change notification message, it uses its own private key to decrypt the Pseudo Sink Instance Data field. Next, App API 4 sends a change registration request message to Query Server 4 (step S310).
  • FIG. 30 shows the change registration request message.
  • Query Server 4 When Query Server 4 receives the change registration request message, it accesses Graph DB 4 and registers the change information (step S311). In addition, in FIG. 26, the procedure for registration in the Graph DB 4 is omitted.
  • Query Server 4 sends a change registration response message to App API 4 (step S312).
  • FIG. 31 shows the change registration response message.
  • IoTSP2, IoTSP3, and IoTS4 also notify other IoTSPs of the configuration change.
  • the information of Pseudo Sink 21 shown in FIG. 19 is notified from IoTSP2 to IoTSP1, IoTSP3, and IoTSP4.
  • FIG. 33 shows a procedure for the Node 11 installed in the IoTSP1 in FIG. 5 to register measurement data in the IoTSP1.
  • FIG. 33 is a diagram depicting a sensor data notification procedure (1) from a Node; Such notification procedure (1) indicates a data notification procedure within the IoTSP.
  • Node 11 periodically transmits measured data such as temperature to Pseudo Sink 11 in a data notification message (step S401). Assume that communication between Node 11 and Pseudo Sink 11 is secure.
  • FIG. 34 shows the data notification message.
  • the value of the Node ID field is "IdNode_11".
  • the Timestamp field represents the date and time when the sensor data was measured, which is "February 8, 2021, 10:00:00" in this example.
  • the Data Format ID field represents the format identifier of the data stored in the Data field. Sensor data is stored in the Data field.
  • Pseudo Sink 11 When Pseudo Sink 11 receives the data notification message, it sends a data registration request message to Sensing DB 1 (step S402).
  • FIG. 35 shows a data registration request message.
  • the values of the Node ID field, Timestamp field, Data Format ID field, and Data field are the same as in FIG.
  • Sensing DB1 is a database that stores the time series of sensor data for each Node. That is, one line (one record) consists of at least the date and time, Node identifier, Capability, sensor data value, Pseudo Sink identifier, and latitude and longitude.
  • the Sensing DB 1 receives the data registration request message, it stores the value of the Node ID field, the value of the Timestamp field, and the value of the Data field in the database. After that, Sensing DB 1 sends a data registration response message to Pseudo Sink 11 (step S403).
  • FIG. 36 shows the data registration response message.
  • the Status field is "OK" indicating normal termination.
  • FIG. 37 shows a procedure for the Sensor 51 installed in the Sensor Provider 5 in FIG. 5 to register measurement data in the IoTSP1.
  • FIG. 37 is a diagram depicting a sensor data notification procedure (2) from a Node; Such notification procedure (2) indicates a data notification procedure from Sensor Provider1 to IoTSP1.
  • the Sensor 51 periodically transmits measured data such as temperature to the Pseudo Sink 51 as a data notification message (step S501). Assume that communication between Sensor 51 and Pseudo Sink 51 is secure.
  • FIG. 38 shows the data notification message.
  • the value of the Node ID field is "IdNode_51”.
  • the Timestamp field represents the date and time when the sensor data was measured, which is "February 8, 2021, 10:00:00" in this example.
  • the Data Format ID field represents the format identifier of the data stored in the Data field. Sensor data is stored in the Data field.
  • Pseudo Sink 51 When Pseudo Sink 51 receives the data notification message, it sends a data notification request message to Pseudo Sink 11 in IoTSP1 (step S502).
  • FIG. 39 shows a data registration request message.
  • the value of the Sensor Provider ID field is "IdSensP_5".
  • the value of the Credential field is "CredSensP_5".
  • the values of the Node ID field, Timestamp field, Data Format ID field, and Data field are the same as in the data notification message shown in FIG.
  • Pseudo Sink 11 When Pseudo Sink 11 receives the data registration request message, it sends an authentication authorization request message to AAA Server 1 in IoTSP 1 (step S503).
  • FIG. 40 shows an authentication authorization request message.
  • the value of the ID field is "IdSensP_5".
  • the value of the Credential field is "CredSensP_5".
  • AAA Server 1 When AAA Server 1 receives the authentication authorization request message, it confirms the authenticity and authority of the subject indicated by the ID field. If the confirmation succeeds, AAA Server 1 sends an authentication authorization response message to Pseudo Sink 11 (step S504).
  • FIG. 13 shows an authentication authorization response message.
  • Pseudo Sink 11 When Pseudo Sink 11 receives the authentication authorization response message, it sends a data registration request message to Sensing DB 1 (step S505).
  • FIG. 41 shows the data registration request message.
  • the values of the Node ID field, Timestamp field, Data Format ID field, and Data field are the same as in the data notification message shown in FIG.
  • the Sensing DB 1 When the Sensing DB 1 receives the data registration request message, it stores the data in the database and sends a data registration response message to the Pseudo Sink 11 (step S506).
  • FIG. 36 shows the data registration response message.
  • the pseudo sink 11 When the pseudo sink 11 receives the data registration response message, it sends a data notification response message to the pseudo sink 51 (step S507).
  • FIG. 42 shows the data notification response message.
  • the Status field is OK indicating normal termination.
  • FIG. 43 shows a procedure for the Mobile Node 13 contracting with the IoTSP1 to register measurement data in the IoTSP1.
  • FIG. 43 is a diagram depicting a sensor data notification procedure (3) from a Node; Such notification procedure (3) indicates a data notification procedure from the Mobile Node 13 to the IoTSP1.
  • Mobile Node 13 detects that it has entered the wireless communication range of Pseudo Sink 11 in IoTSP1 to which it has a contract, and transmits measurement data to Pseudo Sink 11 in a mobile data notification message (step S601).
  • FIG. 44 shows the mobile data notification message.
  • the value of the Node ID field is "IdNode_13".
  • the value of the Credential field is "CredNode_13”.
  • the Timestamp field represents the date and time when the sensor data is transmitted, which is "February 8, 2021, 10:00:00" in this example.
  • the Lat field represents the latitude of Mobile Node 13 when sending sensor data, and in this example it is "35 degrees 37 minutes 12 seconds north latitude”.
  • the Lon field represents the longitude of Mobile Node 13 when sending sensor data, and in this example it is "139 degrees 43 minutes 41 seconds east longitude”.
  • the Data Format ID field represents the format identifier of the data stored in the Data field. Sensor data is stored in the Data field.
  • Pseudo Sink 11 When Pseudo Sink 11 receives the mobile data notification message, it sends an authentication authorization request message to AAA Server 1 (step S602).
  • FIG. 45 shows an authentication authorization request message.
  • the value of the ID field is "IdNode_13”.
  • the value of the Credential field is "CredNode_13”.
  • AAA Server 1 When AAA Server 1 receives the authentication authorization request message, it confirms the authenticity and authority of the subject indicated by the ID field. If the confirmation succeeds, AAA Server 1 sends an authentication authorization response message to Pseudo Sink 11 (step S603).
  • FIG. 13 shows an authentication authorization response message.
  • Pseudo Sink 11 When Pseudo Sink 11 receives the authentication authorization response message, it sends a data registration request message to Sensing DB 1 (step S604).
  • FIG. 46 shows the data registration request message.
  • the Sensing DB 1 When the Sensing DB 1 receives the data registration request message, it registers the data and sends a data registration response message to the Pseudo Sink 11 (step S605).
  • FIG. 36 shows the data registration response message.
  • the values of the Node ID field, Timestamp field, Data Format ID field, and Data field are the same as in the mobile data notification message shown in FIG.
  • IoT App1 is an application that acquires sensor data via App API1.
  • FIG. 47 shows a procedure for IoT App1 to acquire data.
  • FIG. 47 is a diagram showing a data acquisition procedure by IoT APP.
  • App API1 that is, User1
  • App API1 specifies the range of the solid line shown in FIG. Explain the procedure.
  • IoT App1 sends a data acquisition request message to App API1 (step S701).
  • FIG. 49 shows the data search request message.
  • the value of the ID field is "IdUser_1".
  • the value of the Credential field is "CredUser_1".
  • the values of the SW Lat field, SW Long field, NE Lat field, and NE Long field are respectively "35 degrees 37 minutes 09 seconds north latitude”, “139 degrees 43 minutes 21 seconds east longitude", “35 degrees 37 minutes 39 seconds north latitude”, It is "139 degrees 43 minutes 45 seconds east longitude”.
  • the value of the Capability field is "temperature”.
  • the values of the Start Time field and the End Time field are "February 10, 2021, 00:00:00” and “February 10, 2021, 23:59:59”, respectively.
  • App API1 When App API1 receives the data acquisition request message, it sends an authentication authorization request message to AAA Server1 (step S702).
  • FIG. 50 shows an authentication authorization request message.
  • the value of the ID field is "IdUser_1”.
  • the value of the Credential field is "CredUser_1”.
  • AAA Server 1 When AAA Server 1 receives the authentication authorization request message, it verifies the authenticity and authority of the entity indicated by the ID field. When the confirmation succeeds, AAA Server1 sends an authentication authorization response message to App API1 (step S703).
  • FIG. 13 shows an authentication authorization response message.
  • App API1 When App API1 receives the authentication authorization response message, it executes Pseudo Sink resolution (steps S704, S705). The details of the Pseudo Sink solution procedure will be described later. As a result, App API1 obtains a list of Pseudo Sink instance data existing in the area where IoT App1 is requesting data acquisition. In this example, App API1 obtains the instance data of Pseudo Sink 11 shown in FIG. 16 and the instance data of Pseudo Sink 21 shown in FIG.
  • App API1 executes node resolution (steps S706 to S709). Details of the node resolution procedure will be described later. Thus, the interface between App API1 and Query Server1 and the interface between App API1 and App API2 are the same. As a result of node resolution, App API1 obtains a list of Node instance data existing in the area where IoT App1 is requesting data acquisition. In this example, App API1 obtains the instance data of Node11 shown in FIG. 10, the instance data of Node12 shown in FIG. 11, and the instance data of Node21 shown in FIG.
  • App API1 executes data resolution (steps S710 to S713). Details of the data search procedure will be described later. Thus, the interface between App API1 and Query Server1 and the interface between App API1 and App API2 are the same. As a result of data resolution, App API1 can obtain temperature data measured by Node11, Node12, and Node13.
  • FIG. 51 shows an example of a data acquisition response message.
  • the No of Nodes field indicates the number of Nodes from which sensor values have been acquired, and in this example there are three Node11, Node12, and Node21. Three sets of Node ID field, No of Values field, and Value field follow.
  • the Node ID field represents the identifier of the Node that acquired the sensor value.
  • the Capability field represents the capabilities of the Node.
  • the Value field represents sensor values.
  • the Pseudo Sink solution shown in FIG. 47 is a process of searching for a Pseudo Sink that exists in a specified Area, and is a type of graph search.
  • the Pseudo Sink solving procedure will be explained using the graph solving procedure shown in FIG.
  • FIG. 52 is a diagram showing a graph solution procedure.
  • FIG. 53 shows the graph solution request message.
  • the IoTSP ID field represents the identifier of the IoTSP that performs graph resolution, which is "IdIoTSP_1" in this example
  • the No of Queries field represents the number of Queries, which is "30" in this example. This is the number of Areas shown in FIG.
  • the contents of the 30 Queries are to search for a Pseudo Sink instance connected with the object property "contains" for each Area.
  • FIG. 54 shows the graph retrieval request message.
  • the values of the No of Queries field and the Query field are the same as those of the graph resolution request message shown in FIG.
  • FIG. 55 shows the graph search response message.
  • the Status field is "OK" indicating normal termination.
  • the graph search response message includes 30 Value fields.
  • the contents of Pseudo Sink 11 shown in FIG. 16 are returned as Value in response to a Query about Area 11.
  • the contents of Pseudo Sink 21 shown in FIG. 19 are returned as Value in response to a Query about Area 21. Value for Query regarding other Areas is empty.
  • Query Server 1 When Query Server 1 receives the graph search response message, it sends a graph resolution response message to App API 1 (step S804).
  • FIG. 56 shows the graph resolution response message.
  • the Status field is "OK" indicating normal termination.
  • the values of the No of Values field and the Value field are the same as those of the graph search response message shown in FIG.
  • App API1 obtains the instance data of Pseudo Sink 11 shown in FIG. 16 and the instance data of Pseudo Sink 21 shown in FIG.
  • the node solution shown in FIG. 47 is a process of retrieving a node that satisfies a specified condition in a specified Pseudo Sink, and is a kind of graph retrieval.
  • App API1 first performs node resolution for Pseudo Sink 11 according to the procedure shown in FIG. FIG. 57 shows a graph solution request message sent by App API1.
  • the value of the IoTSP ID field is "IdIoTSP_1".
  • the value of the No of Queries field is "1".
  • the content of the Query field is to search for a node installed in the Pseudo Sink 11 and capable of measuring temperature.
  • App API1 receives the graph resolution response message shown in FIG.
  • the Status field is "OK” indicating normal termination.
  • the value of the No of Values field is "2".
  • the Value field contains instance data of Node11 and Node12 shown in FIGS.
  • FIG. 59 is a diagram showing a graph search procedure.
  • App API1 sends a graph resolution request message to App API2 in IoTSP2 (step S901).
  • FIG. 60 shows the graph resolution request message.
  • the value of the ID field is "IdIoTSP_1".
  • the value of the Credential field is "CredIoTSP_1”.
  • the value of the IoTSP ID field is "IdIoTSP_2”.
  • the value of the No of Queries field is "1".
  • the content of the Query field is to search for a node that is installed in the Pseudo Sink 21 and capable of measuring temperature.
  • FIG. 61 shows an authentication authorization request message.
  • the value of the ID field is "IdIoTSP_1”.
  • the value of the Credential field is "CredIOTSP_1”.
  • AAA Server 2 When AAA Server 2 receives the authentication authorization request message, it verifies the authenticity and authority of the entity indicated by the ID field. If the confirmation succeeds, AAA Server 2 sends an authentication authorization response message to App API 2 (step S903).
  • FIG. 13 shows an authentication authorization response message.
  • App API2 When App API2 receives the authentication authorization response message, it sends a graph search request message to Query Server2 (step S904).
  • FIG. 62 shows the graph search request message.
  • the value of the No of Queries field is "1".
  • the content of the Query field is to search for a node that is installed in the Pseudo Sink 21 and capable of measuring temperature.
  • Query Server 2 When Query Server 2 receives the graph search request message, it sends the graph search request message to Graph DB 2 (step S905).
  • Graph DB2 When Graph DB2 receives the graph search request message, it searches the database indicated by the Query field. Next, Graph DB 2 sends a graph search response to Query Server 2 and notifies the result of the search (step S906).
  • FIG. 63 shows the graph search response message.
  • the Status field is "OK" indicating normal termination. In this example, there is one Query field in the graph search request message, so the value of the No of Values field is "1".
  • the value of the Value field is the instance data of Node 21 shown in FIG.
  • Query Server 2 When Query Server 2 receives the graph search response message, it sends the graph search response message to App API 2 (step S907).
  • App API2 When App API2 receives the graph search response message, it sends a graph solution response message to App API1 (step S908).
  • FIG. 64 shows the graph resolution response message.
  • the value of the Status field is "OK" indicating normal termination.
  • the values of the No of Values field and the Value field are the same as those of the graph search response message shown in FIG.
  • step S901, S908 the interface between App API1 and App API12
  • step S904, S907 the interface between App API2 and Query Server2
  • the data solution shown in FIG. 47 is a process of obtaining measured values from the designated Node, measurement item, and measurement time.
  • App API1 acquires temperature data from Node11 and Node12 by the data solution procedure shown in FIG.
  • FIG. 65 is a diagram showing the data solution procedure (1).
  • FIG. 66 shows the data resolution request message.
  • the value of the IoTSP ID field is "IdIoTSP_1".
  • the value of the No of Queries field is "2".
  • Two quadruplets of Node ID field, Capability field, Start Time field, and End Time field follow.
  • the value of the Node ID field is "IdNode_11”.
  • the value of the Capability field is "temperature”.
  • the value of the Start Time field is "February 10, 2021, 00:00:00”.
  • the value of the End Time field is "February 10, 2021, 23:59:59”.
  • the value of the Node ID field is "IdNode_12" and the other fields are the same.
  • Query Server 1 When Query Server 1 receives the data resolution request message, it sends a data search request message to Sensing DB 1 (step S1002).
  • FIG. 67 shows the data search request message.
  • the values of the No of Queries field, Node ID field, Capability field, Start Time field, and End Time field are the same as those of the data resolution request message shown in FIG.
  • Sensing DB1 When Sensing DB1 receives the data search request message, it searches the database indicated by the Query field. Next, Sensing DB 1 transmits a data search response to Query Server 1 and notifies the result of the search (step S1003).
  • FIG. 68 shows the data search response message.
  • the Status field is "OK" indicating normal termination.
  • the No of Values field indicates the number of data serving as answers.
  • the 4-tuples of the Node ID field, the Capability field, the Timestamp field, and the Value field continue for the number of values in the No of Values field.
  • Query Server 1 When Query Server 1 receives the data search response message, it sends a data resolution response message to App API 1 (step S1004).
  • FIG. 69 shows the data resolution response message. Fields other than the Type field are the same as those of the data resolution response message shown in FIG.
  • FIG. 70 is a diagram showing the data solution procedure (2).
  • FIG. 71 shows the data resolution request message.
  • the value of the ID field is "IdIoTSP_1".
  • the value of the Credential field is "CredIoTSP_1".
  • the value of the IoTSP ID field is "IdIoTSP_2”.
  • the value of the No of Queries field is "1".
  • the value of the Node ID field is "IdNode_21”.
  • the value of the Capability field is "temperature”.
  • the value of the Start Time field is "February 10, 2021, 00:00:00”.
  • the value of the End Time field is "February 10, 2021, 23:59:59”.
  • App API2 When App API2 receives the data resolution request message, it sends an authentication authorization request message to AAA Server2 (step S1102).
  • FIG. 61 shows an authentication authorization request message.
  • AAA Server 2 When AAA Server 2 receives the authentication authorization request message, it verifies the authenticity and authority of the entity indicated by the ID field. When the confirmation succeeds, AAA Server 2 sends an authentication authorization response message to App API 2 (step S1103).
  • FIG. 13 shows an authentication authorization response message.
  • App API2 When App API2 receives the authentication authorization response message, it sends a data search request message to Query Server2 (step S1104).
  • FIG. 72 shows the data retrieval request message.
  • the values of the No of Queries field, Node ID field, Capability field, Start Time field, and End Time field are the same as those of the data resolution request message shown in FIG.
  • Query Server 2 When Query Server 2 receives the data search request message, it sends the data search request message to Sensing DB 2 (step S1105).
  • Sensing DB2 When Sensing DB2 receives the data search request message, it searches the database indicated by the Query field. Next, Sensing DB 2 transmits a data search response to Query Server 2 and notifies the result of the search (step S1106).
  • FIG. 68 shows the data search response message.
  • Query Server 2 When Query Server 2 receives the data search response message, it sends the data search response message to App API 2 (step S1107).
  • App API2 When App API2 receives the data search response message, it sends a data resolution response message to App API1 (step S1108).
  • FIG. 69 shows the data resolution response message.
  • FIG. 73 is an explanatory diagram showing a functional configuration example of the information processing device 100 according to the embodiment of the present disclosure.
  • FIG. 73 shows the functional conceptual configuration of the information processing apparatus 100, which is a computer that can function as an IoTSP, node, module, etc., and imposes physical restrictions on the configuration of the information processing apparatus 100. isn't it. Therefore, the information processing apparatus 100 may be physically composed of one device, or may be physically composed of a plurality of devices. When composed of multiple devices, each device may be scattered at various locations. Further, when configured by a plurality of devices, each device may function as an individual information processing device 100 or may virtually function as one information processing device 100 .
  • the information processing device 100 includes a communication section 110, a storage section 120, and a control section .
  • the communication unit 110 executes communication with another information processing device 100, for example, communication with another IoTSP if the information processing device 100 is regarded as one IoTSP.
  • the form of communication may be wired or wireless. From the communication unit 110, each of the above-described messages and the like is transmitted from a predetermined port to another information processing apparatus 100 under the control of the control unit 130 and received at a predetermined port.
  • the storage unit 120 stores various information and programs used in the IoTSP linkage architecture described above.
  • the storage unit 120 stores the above-mentioned Graph DB, Sensing DB, and the like.
  • the storage unit 120 stores an information processing program according to the embodiment of the present disclosure.
  • the storage unit 120 can be composed of semiconductor memory devices such as RAM (Random Access Memory) and flash memory, storage devices such as hard disks and optical discs, auxiliary storage devices such as SSDs (Solid State Drives), and the like.
  • the control unit 130 is configured by a processor such as a CPU (Central Processing Unit), for example, and by executing the information processing program according to the embodiment of the present disclosure stored in the storage unit 120 using the RAM as a work area, Various processes are executed based on the architecture of the IoTSP cooperation described above. For example, the control unit 130 performs Node installation processing, Node removal processing, configuration change notification processing between IoTSPs, based on various requests from users, that is, User1 and Admin1, or automatically, and Executes sensor data notification processing, data acquisition processing by IoT App, Pseudo Sink resolution processing, node resolution processing, data resolution processing, etc.
  • a processor such as a CPU (Central Processing Unit)
  • control unit 130 via the communication unit 110 based on the identifier of the other IoTSP included in the acquisition request of the user via the application and the policy information indicating whether information can be shared between the IoTSP, from the other IoTSP sensor It retrieves data and uses a protocol interface that includes the same procedures between the application and IoTSP1 when retrieving the sensor data.
  • the user makes various requests to the information processing apparatus 100 via, for example, a user terminal (not shown).
  • a user terminal is a terminal device used by a user.
  • the user terminal is, for example, a mobile phone including a smart phone, a tablet terminal, a desktop PC, a notebook PC, or an information processing device such as a PDA (Personal Digital Assistant).
  • User terminals also include wearable devices, which are spectacle-type or watch-type information processing terminals.
  • the user terminal acquires various information according to the operation by the user and the functions of the user terminal (for example, the function of executing an application for using the service provided by each IoTSP, the browser function, etc.) Generate and transmit information according to the information received.
  • the functions of the user terminal for example, the function of executing an application for using the service provided by each IoTSP, the browser function, etc.
  • the user terminal presents an area range specification screen and causes User1 to specify the solid line range shown in FIG. 48 during data acquisition processing by the IoT APP.
  • an information processing apparatus is provided that can easily realize cooperation between IoTSPs.
  • each step in the processing executed by each device in this specification does not necessarily have to be processed chronologically in the order described as a sequence diagram or flowchart.
  • each step in the process executed by each device may be processed in an order different from the order described as the flowchart, or may be processed in parallel.
  • the information processing apparatus 100 is an information processing apparatus that operates as an IoTSP1 (corresponding to an example of a "first IoTSP") that provides a service that allows a user to acquire sensor data.
  • IoTSP1 corresponding to an example of a "first IoTSP”
  • a control unit 130 that searches for the sensor data and responds to the user with the searched sensor data, and the control unit 130 controls the identifier of the other IoTSP included in the acquisition request and information sharing between IoTSP
  • the sensor data is retrieved from the other IoTSP via the communication unit 110 based on the policy information indicating whether or not it is possible, and when retrieving the sensor data, a protocol interface including the same procedure as between the application and the IoTSP1 is used.
  • the information processing apparatus 100 by unifying the interface of the IoT system (IoTSP) into a query language (for example, GraphQL), cooperation between IoTSPs is facilitated, and implementation of each IoTSP Differences can be hidden.
  • IoT system IoTSP
  • a query language for example, GraphQL
  • the App API is introduced between the IoT application and the IoTSP, and the App API converts the request from the application into a query language, making the application easier.
  • the proposed interface consists of queries to the graph database (Graph DB) and queries to the time series database (Sensing DB).
  • the query language GraphQL and the GraphQL server are used.
  • the information processing apparatus 100 also considers cooperation with a sensor provider that provides only sensors. Therefore, according to the information processing apparatus 100 according to the embodiment of the present disclosure, the sensor data collected by the sensor provider can be stored in the IoTSP Sensing DB via the Pseudo Sink.
  • the information processing apparatus 100 realizes cooperation between IoTSPs by sharing the information of the Pseudo Sink among the configuration information of the IoTSPs between the IoTSPs.
  • the Pseudo Sink contains information on the location where the sensor node is installed, but does not contain information on the sensor node itself, so it is considered to be the minimum necessary information to be shared between IoTSPs.
  • the amount of information to be exchanged between IoTSPs is suppressed as much as possible, and cooperation between IoTSPs is enabled without exposing too much configuration information inside the IoTSPs.
  • the IoTSP that owns the information of the Pseudo Sink and Node can set a public policy.
  • the Policy field is specified for the IoTSP level (for example, the values "IdIoTSP_ALL" and "except IdIoTSP_3" specify that disclosure is possible to all IoTSPs except IoTSP3).
  • such designation is not limited to the IoTSP level, and may be designated by the data level such as the Node level or the Capability level. That is, disclosure/non-disclosure may be specified for each Node in the IoTSP, or disclosure/non-disclosure may be specified for each capability level such as “temperature” or “humidity”. As a result, information protection settings can be made on a detailed level such as for each Node or for each capability level.
  • IoTSP1 always forms a mesh network without making a one-to-one connection to other IoTSP2, 3, 4 . . . It is possible to perform IoTSP without
  • IoTSP1 can indirectly acquire necessary sensor data from, for example, IoTSP4 through a linearly connected connection relationship, but not necessarily directly from other IoTSP5. It does not limit the acquisition of sensor data that is Therefore, the IoTSP 1 may acquire necessary sensor data directly as appropriate according to the relationship between the IoTSPs, for example, the contractual relationship.
  • the contractual relationship referred to here includes examples such as those shown in FIGS. 77 and 78.
  • FIG. 77 for example, when two IoTSPs each include the same type of sensor and are in a so-called equal relationship, a contractual relationship in which data is provided free of charge to each other in business can also be established.
  • IoTSP2 when the sensor group included in one of the two IoTSPs (IoTSP2) is more substantial than the other (IoTSP1), it can be said that IoTSP2 is the main and IoTSP1 is the secondary. It is easy to become a master-servant relationship. In such a case, from a business point of view, a contractual relationship in which IoTSP2 provides data to IoTSP1 for a fee may also be established.
  • IoTSP1 may indirectly acquire necessary data from other equivalent IoTSPs including IoTSP2.
  • IoTSP1 may always obtain necessary data directly from IoTSP5.
  • the present technology can also take the following configuration.
  • An information processing device that operates as a first IoTSP that provides a service that allows a user to acquire sensor data, a communication unit that performs communication with a second IoTSP other than the first IoTSP; a control unit that searches for the sensor data corresponding to the acquisition request of the user via an application and responds to the user with the searched sensor data, The control unit Searching for the sensor data from the second IoTSP via the communication unit based on the identifier of the second IoTSP included in the acquisition request and policy information indicating whether or not information can be shared between IoTSPs, and acquiring the sensor data
  • An information processing device that uses a protocol interface that includes the same procedures as between the application and the first IoTSP when retrieving.
  • the control unit The information processing apparatus according to (1), wherein the sensor data is obtained indirectly from the second IoTSP via a third IoTSP other than the first IoTSP and the second IoTSP.
  • the third IoTSP The information processing device according to (2), wherein one or more are connected in a straight chain between the first IoTSP and the second IoTSP.
  • the control unit The information processing device according to (3), which executes the same procedure using a query language.
  • the first IoTSP and the second IoTSP are Each has a first database that stores configuration information of each and a second database that stores the sensor data of the sensor nodes managed by each,
  • the control unit The information processing device according to (4), wherein the sensor data is obtained by querying the first database and the second database using the query language.
  • the configuration information includes the policy information; the policy information of the first IoTSP is set by an administrator of the first IoTSP;
  • the control unit The information processing apparatus according to (5), wherein the configuration information is shared between the second IoTSP and the third IoTSP, which are allowed to share the information, based on the policy information.
  • the control unit When the configuration information of the first IoTSP is changed, change registration using the query language to the first database of each of the second IoTSP and the third IoTSP that allows the information sharing.
  • the information processing device according to (6), wherein the configuration information of the first IoTSP is shared upon request.
  • the configuration information includes: According to any one of (5) to (8) above, having a data structure that expresses the relationship between the geographic information about the area managed by the first IoTSP and the sensor node managed in the area by an ontology.
  • the configuration information includes: The information processing apparatus according to (9), having the data structure represented by the ontology in which classes are the area, the sensor node, and a point installed in the area and terminating the sensor node. (11)
  • the control unit The information processing apparatus according to (10), wherein the sensor data corresponding to the point included in the search range specified by the user via the application is searched. (12)
  • the sensor node is The information processing apparatus according to (10) or (11), including a moving body that is temporarily connected to the point.
  • a first information processing device which is the information processing device according to any one of (1) to (12); and a second information processing device that operates as the second IoTSP.
  • An information processing method using an information processing device that operates as a first IoTSP that provides a service that allows a user to acquire sensor data, performing communication with a second IoTSP other than the first IoTSP; retrieving the sensor data corresponding to the acquisition request of the user via an application, and responding to the user with the retrieved sensor data; Said responding includes: Searching the sensor data from the second IoTSP through executing the communication based on the identifier of the second IoTSP included in the acquisition request and policy information indicating whether information can be shared between IoTSPs, A method of information processing using a protocol interface including the same procedures as between said application and said first IoTSP when retrieving sensor data.
  • An information processing program for functioning a computer that operates as a first IoTSP that provides a service that allows a user to acquire sensor data, to the computer; performing communication with a second IoTSP other than the first IoTSP; searching for the sensor data corresponding to the acquisition request of the user via an application, and responding to the user with the searched sensor data; Said responding includes: Searching the sensor data from the second IoTSP through executing the communication based on the identifier of the second IoTSP included in the acquisition request and policy information indicating whether information can be shared between IoTSPs, An information processing program that uses a protocol interface that includes the same procedures as between said application and said first IoTSP when retrieving sensor data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • Library & Information Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Medical Informatics (AREA)
  • Development Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • Accounting & Taxation (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

情報処理装置（１００）は、センサデータをユーザへ取得させるサービスを提供するＩｏＴＳＰ１（「第１のＩｏＴＳＰ」の一例に相当）として動作する情報処理装置であって、他のＩｏＴＳＰ（「第１のＩｏＴＳＰ以外の第２のＩｏＴＳＰ」の一例に相当）との間の通信を実行する通信部（１１０）と、アプリケーションを介した上記ユーザの取得要求に該当する上記センサデータを検索し、検索した上記センサデータを上記ユーザに対し応答する制御部（１３０）とを備え、制御部（１３０）は、上記取得要求に含まれる上記他のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて通信部（１１０）を介し上記他のＩｏＴＳＰから上記センサデータを検索し、当該センサデータの検索時に、上記アプリケーションおよびＩｏＴＳＰ１間と同一の手続きを含むプロトコルインタフェースを用いる。

Description

情報処理装置、情報処理システム、情報処理方法、および情報処理プログラム
　本開示は、情報処理装置、情報処理システム、情報処理方法、および情報処理プログラムに関する。
　従来、あらゆるモノをインターネットに接続するＩｏＴ（Internet　of　Things）は、モノからの情報を収集してビッグデータとして活用することを可能にする。例としては、工場設備の情報収集、在庫情報収集、環境情報収集などがある（例えば、非特許文献１参照）。
　一方、ＩｏＴシステムではさまざまなデバイスを利用するため、オントロジを定義してデバイスの属性やデバイス間の関係を定義し、デバイスへの統一的なアクセス方法を実現している例もある（例えば、非特許文献２参照）。
　ところで、多くのＩｏＴシステムはそれ自体で閉じて利用されているが、複数のＩｏＴシステムが連携することにより、より高度なサービスをユーザに提供可能であると考えられる。なお、ここに言う「ユーザ」は、ＩｏＴシステムが提供するサービスを利用する人、ならびに人以外にもＩｏＴシステムと接続・通信するモノ（ＩｏＴデバイス、センサデバイス、Ｍａｃｈｉｎｅ　Ｔｙｐｅ　Ｃｏｍｍｕｎｉｃａｔｉｏｎデバイスなど）や、人やモノで構成された組織・事業者まで概念に含むものとする。また、商店街に設置された監視カメラなどのセンサ機器はＩｏＴシステムとして統合されていない場合も多いが、このようなセンサ機器を既存のＩｏＴシステムに統合して使用できれば、取得できるデータの種類が増えたり、データを取得できるエリアが広がったりする。
　「ｏｎｅＭ２Ｍ」はＭ２Ｍ（Machine　to　Machine）システムやＩｏＴシステムの標準化団体であり、こうしたＩｏＴシステム間の接続を定義している（例えば、非特許文献３，４参照）。また、特許文献１～５にも、ＩｏＴシステムの連携に関する各種の技術が提案されている。
　なお、以下では、ＩｏＴシステムで得られたセンサデータをユーザに提供する事業者もしくは当該事業者と同視しうるシステム、装置を「ＩｏＴＳＰ（IoT　Service　Provider）」と称する。また、ＩｏＴシステムとして統合されていないセンサ機器のみを保持する組織を「センサプロバイダ」と称する。
特開２０１８－０１８５０２号公報 特開２０１８－１２５６４７号公報 国際公開第２０１９／１６８１９１号 特開２０１９－２０１４２８号公報 特表２０１８－５３００３８号公報
KDDI.　IoT　活用事例.　https://iot.kddi.com/iot/. Cheng　Xie,　Beibei　Yu,　Zuoying　Zeng,　and　Yun　Yang.　Multiplayer　Internet-of-Things　Middleware　Based　on　Knowledge　Graph.　IEEE　Internet　of　Things　Journal,　Vol.　8,　No.　4,　pp.　2635-2648,　2021. oneM2M.　oneM2M　Technical　Specification:　Functional　Architecture,　February　2021.　TS-0001-V4.10.1. oneM2M.　Standards　for　M2M　and　the　Internet　of　Things.　https://onem2m.org.
　しかしながら、上述した従来技術には、複数のＩｏＴＳＰやセンサプロバイダの連携を容易に実現するうえで、さらなる改善の余地がある。
　そこで、本開示では、複数のＩｏＴＳＰやセンサプロバイダの連携を容易に実現することが可能な、新規かつ改良された情報処理装置、情報処理システム、情報処理方法、および情報処理プログラムを提案する。
　本開示によれば、センサデータをユーザへ取得させるサービスを提供する第１のＩｏＴＳＰとして動作する情報処理装置であって、前記第１のＩｏＴＳＰ以外の第２のＩｏＴＳＰとの間の通信を実行する通信部と、アプリケーションを介した前記ユーザの取得要求に該当する前記センサデータを検索し、検索した前記センサデータを前記ユーザに対し応答する制御部とを備え、前記制御部は、前記取得要求に含まれる前記第２のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて前記通信部を介し前記第２のＩｏＴＳＰから前記センサデータを検索し、当該センサデータの検索時に、前記アプリケーションおよび前記第１のＩｏＴＳＰ間と同一の手続きを含むプロトコルインタフェースを用いる、情報処理装置が提供される。
　また、本開示によれば、センサデータをユーザへ取得させるサービスを提供する第１のＩｏＴＳＰとして動作する情報処理装置を用いた情報処理方法であって、前記第１のＩｏＴＳＰ以外の第２のＩｏＴＳＰとの間の通信を実行することと、アプリケーションを介した前記ユーザの取得要求に該当する前記センサデータを検索し、検索した前記センサデータを前記ユーザに対し応答することとを含み、前記応答することは、前記取得要求に含まれる前記第２のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて前記通信を実行することを介し前記第２のＩｏＴＳＰから前記センサデータを検索し、当該センサデータの検索時に、前記アプリケーションおよび前記第１のＩｏＴＳＰ間と同一の手続きを含むプロトコルインタフェースを用いる、情報処理方法が提供される。
　また、本開示によれば、センサデータをユーザへ取得させるサービスを提供する第１のＩｏＴＳＰとして動作するコンピュータを機能させるための情報処理プログラムであって、前記コンピュータに、前記第１のＩｏＴＳＰ以外の第２のＩｏＴＳＰとの間の通信を実行すること、アプリケーションを介した前記ユーザの取得要求に該当する前記センサデータを検索し、検索した前記センサデータを前記ユーザに対し応答することを実行させ、前記応答することは、前記取得要求に含まれる前記第２のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて前記通信を実行することを介し前記第２のＩｏＴＳＰから前記センサデータを検索し、当該センサデータの検索時に、前記アプリケーションおよび前記第１のＩｏＴＳＰ間と同一の手続きを含むプロトコルインタフェースを用いる、情報処理プログラムが提供される。
ｏｎｅＭ２Ｍのアーキテクチャを示す図である。 ｏｎｅＭ２ＭにおけるＣＳＥを示す図である。 Ａｒｅａ，Ｐｓｅｕｄｏ　Ｓｉｎｋ，Ｎｏｄｅ，Ｍｏｂｉｌｅ　Ｎｏｄｅの各クラス間の関係を示す図である。 Ａｒｅａ，Ｐｓｅｕｄｏ　Ｓｉｎｋ，Ｎｏｄｅ，Ｍｏｂｉｌｅ　Ｎｏｄｅの各インスタンス間の関係を示す図である。 本開示の実施の形態で提案するＩｏＴＳＰ連携システムの構成例を示す図である。 Ａｒｅａ１１のＡｒｅａインスタンスデータの例（初期状態）を示す図である。 Ｎｏｄｅの設置手順を示す図である。 Ｎｏｄｅ設置要求メッセージの構造例を示す図である。 Ｎｏｄｅ設置要求メッセージ内のＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータの構造例を示す図である。 Ｎｏｄｅ設置要求メッセージ内のＮｏｄｅ１１のインスタンスデータの構造例を示す図である。 Ｎｏｄｅ設置要求メッセージ内のＮｏｄｅ１２のインスタンスデータの構造例を示す図である。 認証認可要求メッセージ（１）の構造例を示す図である。 認証認可応答メッセージの構造例を示す図である。 Ｎｏｄｅ登録要求メッセージの構造例を示す図である。 Ｎｏｄｅ１１登録後のＡｒｅａ１１のインスタンスデータの構造例を示す図である。 Ｎｏｄｅ１１登録後のＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータの構造例を示す図である。 Ｎｏｄｅ登録応答メッセージの構造例を示す図である。 Ｎｏｄｅ設置応答メッセージの構造例を示す図である。 Ｐｓｅｕｄｏ　Ｓｉｎｋ２１のインスタンスデータの構造例を示す図である。 Ｎｏｄｅ２１のインスタンスデータの構造例を示す図である。 Ｎｏｄｅの撤去手順を示す図である。 Ｎｏｄｅ撤去要求メッセージの構造例を示す図である。 Ｎｏｄｅ削除要求メッセージの構造例を示す図である。 Ｎｏｄｅ削除応答メッセージの構造例を示す図である。 Ｎｏｄｅ撤去応答メッセージの構造例を示す図である。 ＩｏＴＳＰ間での構成変更通知手順を示す図である。 変更取得要求メッセージの構造例を示す図である。 変更取得応答メッセージの構造例を示す図である。 変更通知メッセージ（１）の構造例を示す図である。 変更登録要求メッセージの構造例を示す図である。 変更登録応答メッセージの構造例を示す図である。 変更通知メッセージ（２）の構造例を示す図である。 Ｎｏｄｅからのセンサデータ通知手順（１）を示す図である。 データ通知メッセージ（１）の構造例を示す図である。 データ登録要求メッセージ（１）の構造例を示す図である。 データ登録応答メッセージの構造例を示す図である。 Ｎｏｄｅからのセンサデータ通知手順（２）を示す図である。 データ通知メッセージ（２）の構造例を示す図である。 データ通知要求メッセージの構造例を示す図である。 認証認可要求メッセージ（２）の構造例を示す図である。 データ登録要求メッセージ（２）の構造例を示す図である。 データ通知応答メッセージの構造例を示す図である。 Ｎｏｄｅからのセンサデータ通知手順（３）を示す図である。 モバイルデータ通知メッセージの構造例を示す図である。 認証認可要求メッセージ（３）の構造例を示す図である。 データ登録要求メッセージ（３）の構造例を示す図である。 ＩｏＴ　ＡＰＰによるデータ取得手順を示す図である。 検索範囲の例を示す図である。 データ取得要求メッセージの構造例を示す図である。 認証認可要求メッセージ（４）の構造例を示す図である。 データ取得応答メッセージの構造例を示す図である。 グラフ解決手順を示す図である。 グラフ解決要求メッセージ（１）の構造例を示す図である。 グラフ検索要求メッセージ（１）の構造例を示す図である。 グラフ検索応答メッセージ（１）の構造例を示す図である。 グラフ解決応答メッセージ（１）の構造例を示す図である。 グラフ解決要求メッセージ（２）の構造例を示す図である。 グラフ解決応答メッセージ（２）の構造例を示す図である。 グラフ検索手順を示す図である。 グラフ解決要求メッセージ（３）の構造例を示す図である。 認証認可要求メッセージ（５）の構造例を示す図である。 グラフ検索要求メッセージ（２）の構造例を示す図である。 グラフ検索応答メッセージ（２）の構造例を示す図である。 グラフ解決応答メッセージ（３）の構造例を示す図である。 データ解決手順（１）を示す図である。 データ解決要求メッセージ（１）の構造例を示す図である。 データ検索要求メッセージ（１）の構造例を示す図である。 データ検索応答メッセージの構造例を示す図である。 データ解決応答メッセージの構造例を示す図である。 データ解決手順（２）を示す図である。 データ解決要求メッセージ（２）の構造例を示す図である。 データ検索要求メッセージ（２）の構造例を示す図である。 本開示の実施の形態に係る情報処理装置の機能構成例を示す説明図である。 変形例の説明図（その１）である。 変形例の説明図（その２）である。 変形例の説明図（その３）である。 変形例の説明図（その４）である。 変形例の説明図（その５）である。
　以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
　また、以下では、複数のＩｏＴＳＰやセンサプロバイダを連携させることを「ＩｏＴＳＰ連携」と称する。
　また、説明は以下の順序で行うものとする。
　１．本開示の実施の形態
　　１．１．ＩｏＴＳＰ連携を実現するうえでの問題点
　　１．２．問題点の整理と解決策のポイント
　　１．３．既存技術との比較
　　１．４．ＩｏＴＳＰ連携の具体的な説明
　　　１．４．１．地理情報の表現方法
　　　１．４．２．Ａｒｅａ，Ｐｓｅｕｄｏ　Ｓｉｎｋ，Ｎｏｄｅ，Ｍｏｂｉｌｅ　Ｎｏｄｅのオントロジによる表現
　　　１．４．３．システム構成
　　　１．４．４．識別子および信用情報の定義
　　　１．４．５．メッセージのフィールドの定義
　　　１．４．６．インスタンスデータのフィールドの定義
　　　１．４．７．Ａｒｅａインスタンス
　　　１．４．８．Ｎｏｄｅの設置
　　　１．４．９．Ｎｏｄｅの撤去
　　　１．４．１０．ＩｏＴＳＰ間での構成変更の通知
　　　１．４．１１．Ｎｏｄｅからのセンサデータ通知（１）
　　　１．４．１２．Ｎｏｄｅからのセンサデータ通知（２）
　　　１．４．１３．Ｎｏｄｅからのセンサデータ通知（３）
　　　１．４．１４．ＩｏＴ　Ａｐｐによるデータ取得
　　　１．４．１５．Ｐｓｅｕｄｏ　Ｓｉｎｋ解決手順
　　　１．４．１６．ノード解決手順
　　　１．４．１７．データ解決手順（１）
　　　１．４．１８．データ解決手順（２）
　　１．５．情報処理装置の機能構成例
　２．まとめ
　　２．１．効果
　　２．２．変形例
＜１．本開示の実施の形態＞
［１．１．ＩｏＴＳＰ連携を実現するうえでの問題点］
　本開示の実施の形態について詳細に説明する前に、まずＩｏＴＳＰ連携を実現するうえでの問題点について具体的に説明する。図１は、ｏｎｅＭ２Ｍのアーキテクチャを示す図である。また、図２は、ｏｎｅＭ２ＭにおけるＣＳＥ（Common　Services　Entity）を示す図である。
　図１および図２に示すように、各ｏｎｅＭ２Ｍサービスプロバイダには１台のＩＮ（Infrastructure　Node）が存在し、ＩＮ内にはＣＳＥが存在する。ＩＮ内のＣＳＥ（ＩＮ－ＣＳＥ）が持つＭｃｃ’というインタフェースで他のｏｎｅＭ２Ｍサービスドメインと接続する。図２に示すようにＣＳＥは多くの機能を含み、複雑なため、ｏｎｅＭ２Ｍサービスプロバイダ間の接続は容易ではない。したがって、ＩｏＴシステム間の接続、すなわちＩｏＴＳＰ連携を実現するには、ＩｏＴシステム間のインタフェースを簡素にする必要があると言える。
　また、ＩｏＴＳＰ同士が連携するには、各ＩｏＴＳＰがカバーするエリアやセンサの設置場所などの管理情報やセンサの測定データを相互に交換する必要がある。管理情報や測定データの交換においては、情報を公開するＩｏＴＳＰが公開先のＩｏＴＳＰを決定可能であることが求められる。
［１．２．問題点の整理と解決策のポイント］
　こうしたＩｏＴＳＰ連携における問題点について整理し、解決策のポイントをまとめると、まず、ｏｎｅＭ２ＭではＩｏＴシステムが連携するうえでのインタフェースを定義しているが、とても複雑であり、実装が困難である。そこで、本開示の実施の形態では、ＩｏＴシステム（ＩｏＴＳＰ）のインタフェースをクエリ言語（例えばＧｒａｐｈＱＬ）に統一することによりＩｏＴＳＰ間の連携を容易にすることとした。具体的には、提案するインタフェースはグラフデータベースへの問合せと時系列データベースへの問合せにより構成される。また、アプリケーションとＩｏＴＳＰ間にＡｐｐ　ＡＰＩ（Application　Programming　Interface）を導入し、Ａｐｐ　ＡＰＩがアプリケーションからの要求をクエリ言語に変換することにより、アプリケーションも容易にＩｏＴＳＰにアクセスできるようにする。
　また、ＩｏＴＳＰにはセンサ搭載機器であるセンサノードの他に、クエリを受け付けるサーバやデータベースなどが必要になる。そこで、本開示の実施の形態では、センサノードは所有しているが、ＩｏＴＳＰとして運用することが困難な個人や小規模組織をセンサプロバイダと位置付け、センサプロバイダがＩｏＴＳＰにセンサデータを提供（販売）するアーキテクチャを提案することとした。具体的には、センサプロバイダ内に設置したＰｓｅｕｄｏ　ＳｉｎｋとＩｏＴＳＰ内に設置したＰｓｅｕｄｏ　Ｓｉｎｋが協調し、センサプロバイダのセンサデータをＩｏＴＳＰに提供する。
　また、ＩｏＴＳＰが連携する際、ＩｏＴＳＰ間での情報の共有が必要である。そこで、本開示の実施の形態では、あらかじめ決められた経路にしたがって共有情報を伝播させることとした。なお、その際、情報の発信元のＩｏＴＳＰはどのＩｏＴＳＰとは情報を共有し、どのＩｏＴＳＰとは情報を共有しないというポリシを持つことが考えられる。この点については、本開示の実施の形態では、Ｐｓｅｕｄｏ　ＳｉｎｋインスタンスやＮｏｄｅインスタンスのデータプロパティとしてｐｏｌｉｃｙというフィールドを設け、ｐｏｌｉｃｙフィールドに共有を許可するＩｏＴＳＰ、あるいは共有を許可しないＩｏＴＳＰを記述できるようにした。
［１．３．既存技術との比較］
　なお、上記した特許文献１は、ロボットとＩｏＴプラットフォームの接続、および異なるＩｏＴプラットフォーム間の接続のための接続装置を提案している。これに対し、本開示の実施の形態では、接続装置を用いることなくＩｏＴプラットフォーム（ＩｏＴＳＰ）間を接続する。
　また、ＩｏＴネットワークでは多様な端末が接続するため、ＩｏＴサービス毎にＶＰＮ（Virtual　Private　Network）等の閉域網を構築し、サービス間での相互干渉を防止する手法が一般的であるが、ＩｏＴ端末への機能追加が必要になる。上記した特許文献２はＩｏＴ端末への機能追加を不要にするため、ネットワーク側に中継装置等を設定する手法を提案している。中継装置等は名前解決、Ｌ３アドレス割り当て、構成情報配布などの機能を有する。これに対し、本開示の実施の形態では、ＩｏＴ端末がＩｏＴネットワーク（ＩｏＴＳＰ）に適切に接続していることを前提とし、ＩｏＴネットワーク（ＩｏＴＳＰ）間の接続に焦点を当てている。
　また、温湿度センサ等のＩｏＴ機器をネットワークにつなげるＩｏＴゲートウェイが知られている。このようなＩｏＴ機器のセキュリティ対策として、許可する通信をリスト化したホワイトリストをＩｏＴゲートウェイに設置する方法が取られる。特許文献３はＩｏＴゲートウェイに迅速にホワイトリストを作成する手法を提案している。これに対し、本開示の実施の形態では、ＩｏＴ端末がＩｏＴネットワーク（ＩｏＴＳＰ）に安全に接続していることを前提とし、ＩｏＴネットワーク（ＩｏＴＳＰ）間の接続に焦点を当てている。
　また、ＩｏＴデバイスがゲートウェイ等のエッジノードを介してインターネットに接続する形態において、同一地点で異なる事業者Ａ，Ｂが設置するＩｏＴデバイスによるモニタや制御が行われることが予想される。このような形態では事業者Ａ，Ｂはネットワークを分離したいと考える。特許文献４はこのようなネットワーク分離を実現する手法を提案している。これに対し、本開示の実施の形態では、ＩｏＴ端末がＩｏＴネットワーク（ＩｏＴＳＰ）に安全に接続していることを前提とし、ＩｏＴネットワーク（ＩｏＴＳＰ）間の接続に焦点を当てている。
　また、Ｗｉ－Ｆｉ（登録商標）ネットワークなどのアクセスクレデンシャルを必要とする制限されたネットワークにデバイスを接続するには、ユーザは利用できるネットワークをスキャンし、利用できるネットワークへの接続要求をしてからネットワークに接続するためのクレデンシャルを手動で入力する。特許文献５は、アクセスクレデンシャルを必要とする制限されたネットワークに対する自動構成を可能にするために、デバイスを自動的に接続可能にするための手法を提案している。これに対し、本開示の実施の形態では、ＩｏＴ端末がＩｏＴネットワーク（ＩｏＴＳＰ）に安全に接続していることを前提とし、ＩｏＴネットワーク（ＩｏＴＳＰ）間の接続に焦点を当てている。
　なお、ＩｏＴＳＰ連携により、以下のような利点が生じる。まず、例えば気象データ（温度、湿度、風向、風速、気圧等）をユーザに提供するＩｏＴＳＰや、気象データを測定するセンサ機器を有するセンサプロバイダの連携、すなわち同種センサデータを提供するＩｏＴＳＰやセンサプロバイダの連携を想定する。ここで、あるＩｏＴＳＰ（ＩｏＴＳＰ－Ａ）は関東地方をカバーしており、別のＩｏＴＳＰ（ＩｏＴＳＰ－Ｂ）は東北地方をカバーしているとする。また、センサプロバイダ－ＡはＩｏＴＳＰ－Ａに測定した気象データを提供しているとする。かかる場合、ＩｏＴＳＰ－Ａ、ＩｏＴＳＰ－Ｂ、センサプロバイダ－Ａが連携することにより、ユーザはより広範囲な地域における気象データを得ることができる。
　また、上記のＩｏＴＳＰ－Ａに加え、例えば関東地方での各繁華街における人出のデータを提供するＩｏＴＳＰ－Ｃの連携、すなわち異種センサデータを提供するＩｏＴＳＰやセンサプロバイダの連携を想定する。かかる場合、ＩｏＴＳＰ－ＡとＩｏＴＳＰ－Ｃが連携することにより、ユーザは気象状況と人出の関係を知ることができる。以下、ＩｏＴＳＰ連携を実現するための構成例について、具体的に説明する。
［１．４．ＩｏＴＳＰ連携の具体的な説明］
（１．４．１．地理情報の表現方法）
　センサを搭載した機器を「Ｎｏｄｅ」と呼ぶこととする。ＩｏＴシステムではＮｏｄｅが実空間に設置されるため、位置情報の扱い方が重要な役割を果たす。Ｎｏｄｅは固定して設置されることを想定している。一方、自動車やスマートフォンなどのセンサを搭載して移動するＮｏｄｅを「Ｍｏｂｉｌｅ　Ｎｏｄｅ」と呼ぶこととする。なお、以下では、Ｎｏｄｅを「ノード」とカタカナで表記する場合がある。Ｎｏｄｅ（ノード）は、「センサノード」の一例に相当する。
　本開示の実施の形態では、地理的な領域（Ａｒｅａ）を経線と緯線で囲まれた０．１分（６秒）四方の矩形で表現する。緯度経度の０．１分は、日本付近では約１８５ｍとなる。なお、Ａｒｅａの１辺の長さは任意でよい。ＮｏｄｅやＭｏｂｉｌｅ　Ｎｏｄｅはセンサデータを無線通信で送信するが、Ｎｏｄｅからの無線通信を終端して有線ネットワークに接続するモジュールとして「Ｐｓｅｕｄｏ　Ｓｉｎｋ」を導入する。無線基地局がＰｓｅｕｄｏ　Ｓｉｎｋの役割を果たしてもよいし、Ｐｓｅｕｄｏ　Ｓｉｎｋとしての専用機器を設置してもよい。Ｐｓｅｕｄｏ　ＳｉｎｋはＡｒｅａ内に設置され、緯度経度の情報を持つ。
（１．４．２．Ａｒｅａ，Ｐｓｅｕｄｏ　Ｓｉｎｋ，Ｎｏｄｅ，Ｍｏｂｉｌｅ　Ｎｏｄｅのオントロジによる表現）
　本開示の実施の形態では、地理情報とノードの関係をオントロジにより表現する。オントロジでは、物事の関係を主語（subject）、述語（property）、目的語（object）の三つ組みで表現する。目的語は別の三つ組みの主語になり得るので、物事の関係は網目状に広がっていく。物事の型を「クラス」と呼び、具体的な物事は該当するクラスの「インスタンス」として表現する。クラス間やインスタンス間の関係を表す述語を「オブジェクトプロパティ（object　property）」と呼び、クラスやインスタンスとその属性との関係を表す述語を「データプロパティ（data　property）」と呼ぶ。
　図３にＡｒｅａクラス、Ｐｓｅｕｄｏ　Ｓｉｎｋクラス、Ｎｏｄｅクラス、Ｍｏｂｉｌｅ　Ｎｏｄｅクラスの関係を示す。図３は、Ａｒｅａ，Ｐｓｅｕｄｏ　Ｓｉｎｋ，Ｎｏｄｅ，Ｍｏｂｉｌｅ　Ｎｏｄｅの各クラス間の関係を示す図である。Ａｒｅａクラスは、「ｉｓＥａｓｔＯｆ（東に隣接する）」、「ｉｓＷｅｓｔＯｆ（西に隣接する）」、「ｉｓＳｏｕｔｈＯｆ（南に隣接する）」、「ｉｓＮｏｒｔｈＯｆ（北に隣接する）」というオブジェクトプロパティを持ち、Ａｒｅａインスタンス間の東西南北の隣接関係を表現する。ＡｒｅａクラスはＡｒｅａ　ＩＤ（Ａｒｅａ識別子）、ＳＷ　Ｌａｔ，Ｌｏｎ（南西隅の緯度経度）、ＮＷ　Ｌａｔ，Ｌｏｎ（北東隅の緯度経度）、Ｄｅｓｃｒｉｐｔｉｏｎ（注釈）などのデータプロパティを持つ。Ａｒｅａインスタンスの注釈の例としては、「東京都品川区内」などが考えられる。また、Ａｒｅａクラスは「ｃｏｎｔａｉｎｓ（包含する）」というオブジェクトプロパティによりＰｓｅｕｄｏ　Ｓｉｎｋインスタンスとの関係を表す。
　Ｐｓｅｕｄｏ　ＳｉｎｋクラスはＩｏＴＳＰ　ＩＤ（ＩｏＴＳＰ識別子）、Ｐｓｅｕｄｏ　Ｓｉｎｋ　ＩＤ（Ｐｓｅｕｄｏ　Ｓｉｎｋ識別子）、Ｌａｔ，Ｌｏｎ（緯度経度）、Ｄｅｓｃｒｉｐｔｉｏｎ（注釈）、Ｐｏｌｉｃｙ（他のＩｏＴＳＰへの管理情報開示に関するポリシ）などのデータプロパティを持つ。Ｐｓｅｕｄｏ　Ｓｉｎｋインスタンスの注釈の例としては、「大崎駅」などが考えられる。Ｐｏｌｉｃｙの例としては、当該Ｐｓｅｕｄｏ　Ｓｉｎｋインスタンスの情報開示を許可するＩｏＴＳＰ識別子のリストなどが考えられる。Ｐｓｅｕｄｏ　Ｓｉｎｋクラスは「ｉｓＩｎｓｔａｌｌｅｄＩｎ（設置されている）」というオブジェクトプロパティによりＡｒｅａインスタンスとの関係を表し、「ｃｏｌｌｅｃｔｓＤａｔａＦｒｏｍ（データを収集する）」というオブジェクトプロパティによりＮｏｄｅインスタンスとの関係を表す。
　ＮｏｄｅクラスはＮｏｄｅ　ＩＤ（Ｎｏｄｅ識別子）、Ｃａｐａｂｉｌｉｔｉｅｓ（機能）、Ｄｅｓｃｒｉｐｔｉｏｎ（注釈）、Ｐｏｌｉｃｙ（他のＩｏＴＳＰへの情報開示の可否）などのデータプロパティを持つ。Ｎｏｄｅクラスは、「ｉｓＣｏｌｌｏｃａｔｅｄＷｉｔｈ（同一Ｐｓｅｕｄｏ　Ｓｉｎｋに設置されている）」というオブジェクトプロパティによりＮｏｄｅインスタンス間の関係を表し、「ｓｅｎｄｓＤａｔａＴｏ（データを送信する）」というオブジェクトプロパティによりＰｓｅｕｄｏ　Ｓｉｎｋインスタンスの関係を表す。
　ＮｏｄｅクラスのサブクラスとしてＭｏｂｉｌｅ　Ｎｏｄｅクラスを定義する。Ｍｏｂｉｌｅ　ＮｏｄｅサブクラスはＮｏｄｅクラスが持つデータプロパティに加えてＩｏＴＳＰ　ＩＤ（ＩｏＴＳＰ識別子）、Ｄａｔｅ，Ｔｉｍｅ（日付と時刻）、Ｌａｔ，Ｌｏｎ（緯度経度）、Ｃｒｅｄｅｎｔｉａｌ（認証情報）などのデータプロパティを持つ。
　図４にＡｒｅａインスタンス、Ｐｓｅｕｄｏ　Ｓｉｎｋインスタンス、Ｎｏｄｅインスタンス、Ｍｏｂｉｌｅ　Ｎｏｄｅインスタンスの関係の例を示す。図４は、Ａｒｅａ，Ｐｓｅｕｄｏ　Ｓｉｎｋ，Ｎｏｄｅ，Ｍｏｂｉｌｅ　Ｎｏｄｅの各インスタンス間の関係を示す図である。Ａｒｅａ１１は隣接するＡｒｅａ１２～１５とは「ｉｓＥａｓｔＯｆ」、「ｉｓＷｅｓｔＯｆ」、「ｉｓＳｏｕｔｈＯｆ」、あるいは「ｉｓＮｏｒｔｈＯｆ」というオブジェクトプロパティで接続している。さらにＡｒｅａ１１はＰｓｅｕｄｏ　Ｓｉｎｋ１１と「ｃｏｎｔａｉｎｓ」および「ｉｓＩｎｓｔａｌｌｅｄＩｎ」というオブジェクトプロパティで接続している。Ｐｓｅｕｄｏ　Ｓｉｎｋ１１はＮｏｄｅ１１およびＮｏｄｅ１２と「ＣｏｌｌｅｃｔｓＤａｔａＦｒｏｍ」および「ｓｅｎｄｓＤａｔａＴｏ」というオブジェクトプロパティで接続している。また、Ｎｏｄｅ１１とＮｏｄｅ１２は「ｉｓＣｏｌｌｏｃａｔｅｄＷｉｔｈ」というオブジェクトプロパティで接続している。さらにＰｓｅｕｄｏ　Ｓｉｎｋ１１はＭｏｂｉｌｅ　Ｎｏｄｅ１３と「ＣｏｌｌｅｃｔｓＤａｔａＦｒｏｍ」および「ｓｅｎｄｓＤａｔａＴｏ」というオブジェクトプロパティで接続している。この例では、Ｍｏｂｉｌｅ　Ｎｏｄｅ１３は移動中にＰｓｅｕｄｏ　Ｓｉｎｋ１１の無線通信圏内に入ったため、一時的にＰｓｅｕｄｏ　Ｓｉｎｋ１１と接続している。本開示の実施の形態では、以上のようなインスタンスの情報を後述するＧｒａｐｈ　ＤＢに格納する。ただし、Ｍｏｂｉｌｅ　ＮｏｄｅインスタンスとＰｓｅｕｄｏ　Ｓｉｎｋインスタンスの接続関係は一時的であるので、ＧｒａｐｈＤＢには格納しない。
　このように表現することにより、ある１つのＡｒｅａインスタンス、Ｐｓｅｕｄｏ　Ｓｉｎｋインスタンス、Ｎｏｄｅインスタンス、あるいはＭｏｂｉｌｅ　Ｎｏｄｅインスタンスから、それと関係を持つインスタンスを順次見つけることができる。例えば、Ａｒｅａインスタンスを指定することにより、その中に設置されているＮｏｄｅインスタンスを検索することができる。また、Ｎｏｄｅインスタンスを指定することにより、そのＮｏｄｅインスタンスと関係を持つ別のＮｏｄｅインスタンスを知ることができる。
　Ａｒｅａ１１はデータプロパティとして南西隅の緯度が「３５度３７分６秒」、経度が「１３９度４３分３６秒」であり、北東隅の緯度が「３５度３７分１２秒」、経度が「１３９度４３分４２秒」という値を持つ。
　Ｐｓｅｕｄｏ　Ｓｉｎｋ１１はデータプロパティとしてＩｏＴＳＰ識別子が「ＩｄＩｏＴＳＰ＿１」、Ｐｓｅｕｄｏ　Ｓｉｎｋ識別子が「ＩｄＰＳｉｎｋ＿１１」、Ｄｅｓｃｒｉｐｔｉｏｎが「大崎駅」、緯度が「３５度３７分１１．８５秒」、経度が「１３９度４３分４１．０６秒」という値を持つ。またＰｏｌｉｃｙの値は「ＩｄＩｏＴＳＰ＿ＡＬＬ」、「ｅｘｃｅｐｔ　ＩｄＩｏＴＳＰ＿３」であり、ＩｏＴＳＰ３を除くすべてのＩｏＴＳＰに公開可能であることを示す。
　Ｎｏｄｅ１１はデータプロパティとしてＮｏｄｅ識別子が「ＩｄＮｏｄｅ＿１１」、Ｃａｐａｂｉｌｉｔｙが「Ｔｅｍｐｅｒａｔｕｒｅ」と「Ｈｕｍｉｄｉｔｙ」、Ｄｅｓｃｒｉｐｔｉｏｎが「Ｏｕｔｄｏｏｒ　Ｍｏｄｕｌｅ」、Ｐｏｌｉｃｙが「ＩｄＩｏＴＳＰ＿ＡＬＬ（他の全ＩｏＴＳＰに公開）」という値を持つ。Ｎｏｄｅ１２もＮｏｄｅ１１と同様のデータプロパティの値を持つが、Ｐｏｌｉｃｙの値が「ＩｏＴＳＰ＿Ｎｏｎｅ（他のＩｏＴＳＰには非公開）」となっている。
　Ｍｏｂｉｌｅ　Ｎｏｄｅ１３はデータプロパティとしてＮｏｄｅ識別子が「ＩｄＮｏｄｅ＿１３」、ＩｏＴＳＰ識別子（Ｍｏｂｉｌｅ　Ｎｏｄｅ１３が契約しているＩｏＴＳＰの識別子）が「ｉｄＩｏＴＳＰ＿１」、Ｃａｐａｂｉｌｉｔｙが「Ｓｐｅｅｄ」、Ｄｅｓｃｒｉｐｔｉｏｎが「Ｖｅｈｉｃｌｅ」、Ｄａｔｅ，Ｔｉｍｅが「２０２１年２月１０日，１０時０分０秒」、緯度経度が「北緯３５度３７分１２．０秒，東経１３９度４３分４１．０秒」、Ｃｒｅｄｅｎｔｉａｌが「ＣｒｅｄＮｏｄｅ＿１３」、Ｐｏｌｉｃｙが「ＩｏＴＳＰ＿ＡＬＬ」という値を持つ。
（１．４．３．システム構成）
　次に、図５に、提案するシステムの構成例を示す。図５は、本開示の実施の形態で提案するＩｏＴＳＰ連携システムの構成例を示す図である。ＩｏＴＳＰ連携システムは「情報処理システム」の一例に相当する。
　図５にはＩｏＴＳＰが４つ（「ＩｏＴＳＰ１」から「ＩｏＴＳＰ４」）、センサプロバイダが１つ（「Ｓｅｎｓｏｒ　Ｐｒｏｖｉｄｅｒ５」）示されている。ＩｏＴＳＰ１は内部の詳細を示しており、ＩｏＴＳＰ２からＩｏＴＳＰ４は内部が省略されている。ＩｏＴＳＰの数は４以上でもよく、センサプロバイダの数は２以上でもよい。また、この例ではＩｏＴＳＰ１からＩｏＴＳＰ４が直鎖状に接続しているが、ＩｏＴＳＰ間の接続形態は直鎖状に限らない。この接続は論理的なものであり、安全な通信路で接続されているとする。またすべてのＩｏＴＳＰはＩｏＴＳＰ間の接続関係を認識しているものとする。例えば各ＩｏＴＳＰの管理者がＩｏＴＳＰ間の接続関係を決定し、それぞれのＩｏＴＳＰ内に登録するなどの方法が考えられる。この例では、すべてのＩｏＴＳＰはＩｏＴＳＰ１からＩｏＴＳＰ４が直鎖状に接続していることを認識しているとする。さらに各ＩｏＴＳＰは公開鍵暗号系における秘密鍵と公開鍵を有しているとする。秘密鍵は各ＩｏＴＳＰが秘匿し、公開鍵は他のすべてのＩｏＴＳＰが共有しているとする。また、センサプロバイダは、本明細書では「ユーザ」の概念に含まれ得る。
　ＵｓｅｒはＩｏＴＳＰと契約を結んでいるユーザである。この例では、「Ｕｓｅｒ１」はＩｏＴＳＰ１と契約を結んでおり、ユーザ用のアプリケーションである「ＩｏＴ　Ａｐｐ１」を利用してＩｏＴＳＰ１からセンサデータ等を得る。
　Ａｐｐ　ＡＰＩはアプリケーション用ＡＰＩであり、アプリケーションからの要求をクエリ言語に変換し、Ｑｕｅｒｙ　Ｓｅｒｖｅｒにアクセスする。この例では、「Ａｐｐ　ＡＰＩ１」は「ＩｏＴ　Ａｐｐ１」からの要求を受付けてクエリ言語に変換し、「Ｑｕｅｒｙ　Ｓｅｒｖｅｒ１」にアクセスする。さらにＡｐｐ　ＡＰＩはクエリ言語によりＩｏＴＳＰ間連携を実現する。この例では、Ａｐｐ　ＡＰＩ１はＩｏＴＳＰ２内の「Ａｐｐ　ＡＰＩ２」と連携し、クエリ言語によりＩｏＴＳＰ１とＩｏＴＳＰ２間の連携を実現する。
　ＡｄｍｉｎはＩｏＴＳＰの管理者である。この例では、「Ａｄｍｉｎ１」は管理用ＡＰＩである「Ａｄｍｉｎ　ＡＰＩ１」を介してＩｏＴＳＰ１を管理・運用する。
　Ｑｕｅｒｙ　ＳｅｒｖｅｒはＡｐｐ　ＡＰＩからクエリ言語を受け付け、Ｓｅｎｓｉｎｇ　ＤＢやＧｒａｐｈ　ＤＢにアクセスする。この例ではＱｕｅｒｙ　Ｓｅｒｖｅｒ１はＡｐｐ　ＡＰＩ１からのクエリ言語を受け付け、「Ｓｅｎｓｉｎｇ　ＤＢ１」や「Ｇｒａｐｈ　ＤＢ１」にアクセスする。
　ＡＡＡ（Authentication,　Authorization,　and　Accounting）　Ｓｅｒｖｅｒはユーザ、管理者、ＩｏＴＳＰ、センサプロバイダ、Ｍｏｂｉｌｅ　Ｎｏｄｅの認証認可を行うモジュールである。この例では、「ＡＡＡ　Ｓｅｒｖｅｒ１」はＵｓｅｒ１、Ａｄｍｉｎ１、「Ｍｏｂｉｌｅ　Ｎｏｄｅ１３」の認証認可を行う。図には示していないが、Ａｐｐ　ＡＰＩ２内の「ＡＡＡ　Ｓｅｒｖｅｒ２」はＩｏＴＳＰ１等の認証認可を行う。
　Ｇｒａｐｈ　ＤＢはＡｒｅａインスタンス、Ｐｓｅｕｄｏ　Ｓｉｎｋインスタンス、Ｎｏｄｅインスタンス、Ｍｏｂｉｌｅ　Ｎｏｄｅインスタンスを保存するデータベースである。さらにデータベースへのインスタンス情報の登録や検索の機能も有する。この例では、Ｇｒａｐｈ　ＤＢ１はＩｏＴＳＰ１内のＧｒａｐｈ　ＤＢである。
　Ｓｅｎｓｉｎｇ　ＤＢはセンサの測定値の時系列データを保存するデータベースである。さらにデータベースへのセンサデータの登録や検索の機能も有する。この例では、Ｓｅｎｓｉｎｇ　ＤＢ１はＩｏＴＳＰ１内のＳｅｎｓｉｎｇ　ＤＢである。
　Ｐｓｅｕｄｏ　ＳｉｎｋはＮｏｄｅからセンサデータを収集するモジュールである。この例では、「Ｐｓｅｕｄｏ　Ｓｉｎｋ１１」はＮｏｄｅ１１やＭｏｂｉｌｅ　Ｎｏｄｅ１３からセンサデータを収集している。さらに「Ｐｓｅｕｄｏ　Ｓｉｎｋ５１」とも接続し、Ｓｅｎｓｏｒ　Ｐｒｏｖｉｄｅｒ５からのセンサデータも収集している。
　ＮｏｄｅやＭｏｂｉｌｅ　Ｎｏｄｅはセンサを搭載した物理的モジュールである。この例では、Ｎｏｄｅ１１等がＰｓｅｕｄｏ　Ｓｉｎｋ１１に接続されており、さらにＭｏｂｉｌｅ　Ｎｏｄｅ１３がＰｓｅｕｄｏ　Ｓｉｎｋ１１の無線通信範囲に入ったため、一時的にＭｏｂｉｌｅ　Ｎｏｄｅ１３はＰｓｅｕｄｏ　Ｓｉｎｋ１１に接続している。
　Ｓｅｎｓｏｒ　Ｐｒｏｖｉｄｅｒ５では「Ｎｏｄｅ５１」がＰｓｅｕｄｏ　Ｓｉｎｋ５１に接続しており、Ｐｓｅｕｄｏ　Ｓｉｎｋ５１はＩｏＴＳＰ１内のＰｓｅｕｄｏ　Ｓｉｎｋ１１に接続している。
（１．４．４．識別子および信用情報の定義）
　次に、識別子および信用情報を定義する。図５に示すＩｏＴＳＰ１～ＩｏＴＳＰ４の識別子を「ＩｄＩｏＴＳＰ＿１」～「ＩｄＩｏＴＳＰ＿４」とする。ＩｏＴＳＰ１～ＩｏＴＳＰ４の信用情報を「ＣｒｅｄＩｏＴＳＰ＿１」～「ＣｒｅｄＩｏＴＳＰ＿４」とする。Ｓｅｎｓｏｒ　Ｐｒｏｖｉｄｅｒ５の識別子を「ＩｄＳｅｎｓＰ＿５」とする。Ｓｅｎｓｏｒ　Ｐｒｏｖｉｄｅｒ５の信用情報を「ＣｒｅｄＳｅｎｓＰ＿５」とする。Ａｄｍｉｎ１の識別子を「ＩｄＡｄｍｉｎ＿１」とする。Ａｄｍｉｎ１の信用情報を「ＣｒｅｄＡｄｍｉｎ＿１」とする。Ｕｓｅｒ１の識別子を「ＩｄＵｓｅｒ＿１」とする。Ｕｓｅｒ１の信用情報を「ＣｒｅｄＵｓｅｒ＿１」とする。
　図４に示すＡｒｅａ１１～Ａｒｅａ１５の識別子を「ＩｄＡｒｅａ＿１１」～「ＩｄＡｒｅａ＿１５」とする。Ｐｓｅｕｄｏ　Ｓｉｎｋ１１の識別子を「ＩｄＰＳｉｎｋ＿１１」とする。Ｐｓｅｕｄｏ　Ｓｉｎｋ２１の識別子を「ＩｄＰＳｉｎｋ＿２１」とする。Ｎｏｄｅ１１の識別子を「ＩｄＮｏｄｅ＿１１」とする。Ｎｏｄｅ１２の識別子を「ＩｄＮｏｄｅ＿１２」とする。Ｍｏｂｉｌｅ　Ｎｏｄｅ１３の識別子を「ＩｄＮｏｄｅ＿１３」とする。Ｍｏｂｉｌｅ　Ｎｏｄｅ１３の信用情報を「ＣｒｅｄＮｏｄｅ＿１３」とする。
（１．４．５．メッセージのフィールドの定義）
　次に、メッセージのフィールドを定義する。「Ｔｙｐｅ」フィールドはメッセージのタイプを表す。メッセージタイプには、ＡＡ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（認証認可要求／応答）、Ｄａｔａ　Ｒｅｇｉｓｔｒａｔｉｏｎ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（データ登録要求／応答）、Ｄａｔａ　Ｒｅｐｏｒｔ（データ通知）、Ｄａｔａ　Ｒｅｐｏｒｔ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（データ通知要求／応答）、ＤａｔａＲｅｓｏｌｕｔｉｏｎ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（データ解決要求／応答）、Ｄａｔａ　Ｒｅｔｒｉｅｖｅ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（データ取得要求／応答）、Ｄａｔａ　Ｓｅａｒｃｈ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（データ検索要求／応答）、Ｇｒａｐｈ　Ｒｅｓｏｌｕｔｉｏｎ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（グラフ解決要求／応答）、Ｇｒａｐｈ　Ｓｅａｒｃｈ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（グラフ検索要求／応答）、Ｍｏｂｉｌｅ　Ｄａｔａ　Ｒｅｐｏｒｔ（モバイルデータ通知）、Ｍｏｄｉｆｉｅｄ　Ｄａｔａ　Ｒｅｐｏｒｔ（変更通知）、Ｍｏｄｉｆｉｅｄ　Ｄａｔａ　Ｒｅｇｉｓｔｒａｔｉｏｎ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（更新登録要求／応答）、Ｍｏｄｉｆｉｅｄ　Ｄａｔａ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（更新情報要求／応答）、Ｎｏｄｅ　Ｄｅｌｅｔｅ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（ノード削除要求／応答）、Ｎｏｄｅ　Ｉｎｓｔａｌｌａｔｉｏｎ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（ノード設置要求／応答）、Ｎｏｄｅ　Ｒｅｇｉｓｔｒａｔｉｏｎ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（ノード登録要求／応答）、Ｎｏｄｅ　Ｒｅｍｏｖａｌ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（ノード撤去要求／応答）がある。
　「Ｃａｐａｂｉｌｉｔｙ」フィールドはＮｏｄｅが持つ機能を表す。「Ｃｒｅｄｅｎｔｉａｌ」フィールドは信用情報を表す。信用情報とはパスワードや電子証明書などである。「Ｄａｔａ　Ｆｏｒｍａｔ　ＩＤ」フィールドはセンサデータのフォーマットの識別子を表す。「Ｅｎｄ　Ｔｉｍｅ」フィールドは終了日時を表す。「ＩＤ」フィールドは動作を行う主体の識別子を表す。主体とはＩｏＴＳＰの利用者や管理者、ＩｏＴＳＰ自体、センサプロバイダ自体である。「ＩｏＴＳＰ　ＩＤ」フィールドはＩｏＴＳＰの識別子を表す。「Ｌａｔ」フィールドと「Ｌｏｎ」フィールドはＰｓｅｕｄｏ　Ｓｉｎｋの緯度と経度を表す。「ＮＥ　Ｌａｔ」フィールドと「ＮＥ　Ｌｏｎ」フィールドはＡｒｅａ北東隅の緯度と経度を表す。「Ｎｏ　ｏｆ　Ｎｏｄｅｓ」フィールドは対象となるＮｏｄｅの個数を表す。「Ｎｏ　ｏｆ　Ｐｓｅｕｄｏ　Ｓｉｎｋｓ」フィールドは対象となるＰｓｅｕｄｏ　Ｓｉｎｋの個数を表す。「Ｎｏ　ｏｆ　Ｑｕｅｒｉｅｓ」フィールドはクエリの個数を表す。「Ｎｏ　ｏｆ　Ｖａｌｕｅｓ」フィールドは値の個数を表す。「Ｎｏｄｅ　ＩＤ」フィールドはＮｏｄｅの識別子を表す。「Ｎｏｄｅ　Ｉｎｓｔａｎｃｅ　Ｄａｔａ」フィールドはＮｏｄｅインスタンスデータを表す。「Ｐｓｅｕｄｏ　Ｓｉｎｋ　ＩＤ」フィールドはＰｓｅｕｄｏ　Ｓｉｎｋの識別子を表す。「Ｐｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａ」フィールドはＰｓｅｕｄｏ　Ｓｉｎｋのインスタンスデータを表す。「Ｑｕｅｒｙ」フィールドはクエリの内容を表す。「Ｓｅｎｓｏｒ　Ｐｒｏｖｉｄｅｒ　ＩＤ」フィールドはセンサプロバイダの識別子を表す。「Ｓｔａｒｔ　Ｔｉｍｅ」フィールドは開始日時を表す。「Ｓｔａｔｕｓ」フィールドは動作の終了状態を表す。「ＳＷ　Ｌａｔ」フィールドと「ＳＷ　Ｌｏｎ」フィールドはＡｒｅａ西南隅の緯度と経度を表す。「Ｔｉｍｅｓｔａｍｐ」フィールドは日時を表す。「Ｖａｌｕｅ」フィールドはクエリに対する回答を表す。
（１．４．６．インスタンスデータのフィールドの定義）
　次に、インスタンスデータのフィールドを定義する。「Ａｒｅａ　ＩＤ」フィールドはＡｒｅａインスタンスの識別子を表す。「Ａｒｅａ　Ｉｎｓｔａｎｃｅ　Ｄａｔａ」フィールドはＡｒｅａインスタンスデータの全部または一部を表す。「Ｃａｐａｂｉｌｉｔｙ」フィールドはＮｏｄｅインスタンスが有する機能を表す。例えば「温度（ｔｅｍｐｅｒａｔｕｒｅ）」や「湿度（ｈｕｍｉｄｉｔｙ）」などである。「ｃｏｌｌｅｃｔｓＤａｔａＦｒｏｍ」フィールドは当該Ｐｓｅｕｄｏ　ＳｉｎｋインスタンスとオブジェクトプロパティであるｃｏｌｌｅｃｔｓＤａｔａＦｒｏｍで接続するＮｏｄｅインスタンスやＭｏｂｉｌｅ　Ｎｏｄｅインスタンスの識別子を表す。「ｃｏｎｔａｉｎｓ」フィールドは当該Ａｒｅａインスタンスとオブジェクトプロパティであるｃｏｎｔａｉｎｓで接続するＰｓｅｕｄｏ　Ｓｉｎｋインスタンスの識別子を表す。「Ｄｅｓｃｒｉｐｔｉｏｎ」フィールドはユーザにとって理解しやすい注釈を表す。例えばＡｒｅａインスタンスのＤｅｓｃｒｉｐｔｉｏｎであれば「東京都品川区内」、Ｐｓｅｕｄｏ　ＳｉｎｋインスタンスのＤｅｓｃｒｉｐｔｉｏｎであれば「大崎駅」、ＮｏｄｅインスタンスのＤｅｓｃｒｉｐｔｉｏｎであれば「Ｏｕｔｄｏｏｒ　Ｍｏｄｕｌｅ」などである。「Ｅｎｄ　Ｔｉｍｅ」フィールドは終了日時を表す。「ｉｓＣｏｌｌｏｃａｔｅｄＷｉｔｈ」フィールドは当該ＮｏｄｅインスタンスとオブジェクトプロパティであるｉｓＣｏｌｌｏｃａｔｅｄＷｉｔｈで接続するＮｏｄｅインスタンスの識別子を表す。「ｉｓＥａｓｔＯｆ」フィールドは当該ＡｒｅａインスタンスとオブジェクトプロパティであるｉｓＥａｓｔＯｆで接続するＡｒｅａインスタンスの識別子を表す。「ｉｓＩｎｓｔａｌｌｅｄＩｎ」フィールドは当該Ｐｓｅｕｄｏ　ＳｉｎｋインスタンスとオブジェクトプロパティであるｉｓＩｎｓｔａｌｌｅｄＩｎで接続するＡｒｅａインスタンスの識別子を表す。「ｉｓＮｏｒｔｈＯｆ」フィールドは当該ＡｒｅａインスタンスとオブジェクトプロパティであるｉｓＮｏｒｔｈＯｆで接続するＡｒｅａインスタンスの識別子を表す。「ｉｓＳｏｕｔｈＯｆ」フィールドは当該ＡｒｅａインスタンスとオブジェクトプロパティであるｉｓＳｏｕｔｈＯｆで接続するＡｒｅａインスタンスの識別子を表す。「ｉｓＷｅｓｔＯｆ」フィールドは当該ＡｒｅａインスタンスとオブジェクトプロパティであるｉｓＷｅｓｔＯｆで接続するＡｒｅａインスタンスの識別子を表す。「ＮＥ　Ｌａｔ」フィールドと「ＮＥ　Ｌｏｎ」フィールドはＡｒｅａインスタンスの北東隅の緯度と経度を表す。「Ｌａｔ」フィールドと「Ｌｏｎ」フィールドはＰｓｅｕｄｏ　Ｓｉｎｋインスタンスの緯度と経度を表す。「Ｎｏ　ｏｆ　Ｎｏｄｅｓ」フィールドは対象となるＮｏｄｅインスタンスの数を表す。「Ｎｏ　ｏｆ　Ｐｓｅｕｄｏ　Ｓｉｎｋｓ」フィールドは対象となるＰｓｅｕｄｏ　Ｓｉｎｋインスタンスの数を表す。「Ｎｏｄｅ　ＩＤ」フィールドはＮｏｄｅインスタンスやＭｏｂｉｌｅ　Ｎｏｄｅインスタンスの識別子を表す。「Ｎｏｄｅ　Ｉｎｓｔａｎｃｅ　Ｄａｔａ」フィールドはＮｏｄｅ　またはＭｏｂｉｌｅ　Ｎｏｄｅのインスタンスデータの全部または一部を表す。「Ｐｏｌｉｃｙ」フィールドは情報を公開するＩｏＴＳＰを表す。値としては、例えば公開を許可するＩｏＴＳＰの識別子のリストでもよいし、すべてのＩｏＴＳＰに許可する「ＩｄＩｏＴＳＰ＿ＡＬＬ」や、すべてのＩｏＴＳＰに不許可である「ＩｄＩｏＴＳＰ＿Ｎｏｎｅ」でもよい。「Ｐｓｅｕｄｏ　Ｓｉｎｋ　ＩＤ」フィールドはＰｓｅｕｄｏ　Ｓｉｎｋインスタンスの識別子を表す。「Ｐｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａ」フィールドはＰｓｅｕｄｏ　Ｓｉｎｋインスタンスデータの全部または一部を表す。「ｓｅｎｄｓＤａｔａＴｏ」フィールドは当該Ｐｓｅｕｄｏ　ＳｉｎｋインスタンスとオブジェクトプロパティであるｓｅｎｄｓＤａｔａＴｏで接続するＮｏｄｅインスタンスやＭｏｂｉｌｅ　Ｎｏｄｅインスタンスの識別子を表す。「Ｓｔａｒｔ　Ｔｉｍｅ」フィールドは開始日時を表す。「ＳＷ　Ｌａｔ」フィールドと「ＳＷ　Ｌｏｎ」フィールドはＡｒｅａ西南隅の緯度と経度を表す。「Ｔｉｍｅｓｔａｍｐ」フィールドは日時を表す。
（１．４．７．Ａｒｅａインスタンス）
　図５に示すシステム構成例において、各ＩｏＴＳＰは図４に示すＡｒｅａのインスタンスデータをＧｒａｐｈ　ＤＢに格納済とする。例えば、Ｐｓｅｕｄｏ　Ｓｉｎｋ１１の設置前のＡｒｅａ１１のＡｒｅａインスタンスデータは図６のようになる。図６は、Ａｒｅａ１１のＡｒｅａインスタンスデータの例（初期状態）を示す図である。このＡｒｅａインスタンスの識別子は「ＩｄＡｒｅａ＿１１」である。このＡｒｅａインスタンスの最終変更日時は「２０２１年１月１５日１０時０分０秒」である。このＡｒｅａの南西隅の緯度と経度は「北緯３５度３７分０６秒」、「東経１３９度４３分３６秒」である。このＡｒｅａの北東隅の緯度と経度は「北緯３５度３７分１２秒」、「東経１３９度４３分４２秒」である。このＡｒｅａの注釈は「東京都品川区内」である。このＡｒｅａとｉｓＥａｓｔＯｆ、ｉｓＷｅｓｔＯｆ、ｉｓＳｏｕｔｈＯｆ、ｉｓＮｏｒｔｈＯｆで接続するＡｒｅａインスタンスの識別子はそれぞれ「ＩｄＡｒｅａ＿１２」、「ＩｄＡｒｅａ＿１３」、「ＩｄＡｒｅａ＿１４」、「ＩｄＡｒｅａ＿１５」である。
（１．４．８．Ｎｏｄｅの設置）
　次に、図５に示すＩｏＴＳＰ１が図４に示すＮｏｄｅ１１とＮｏｄｅ１２を新たに設置する場合の手順について、図７を用いて説明する。図７は、Ｎｏｄｅの設置手順を示す図である。
　Ａｄｍｉｎ１はＡｄｍｉｎ　ＡＰＰ１を介してＡｄｍｉｎ　ＡＰＩ１にＮｏｄｅ設置要求メッセージを送信する（ステップＳ１０１）。図８にＮｏｄｅ設置要求メッセージを示す。ＩＤフィールドの値は「ＩｄＡｄｍｉｎ＿１」である。Ｃｒｅｄｅｎｔｉａｌフィールドの値は「ＣｒｅｄＡｄｍｉｎ＿１」である。Ｐｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　ＤａｔａフィールドにはＮｏｄｅ１１とＮｏｄｅ１２からデータを収集するＰｓｅｕｄｏ　ＳｉｎｋであるＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータが格納される。Ｎｏ　ｏｆ　Ｎｏｄｅｓフィールドの値は「２」である。以下、Ｎｏｄｅ１１のインスタンスデータとＮｏｄｅ１２のインスタンスデータが格納される。
　図９にＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータを示す。このＰｓｅｕｄｏ　Ｓｉｎｋインスタンスの識別子は「ＩｄＰＳｉｎｋ＿１１」である。このＰｓｅｕｄｏ　Ｓｉｎｋインスタンスの最終変更日時は「２０２１年２月１日午前１０時０分０秒」である。このＰｓｅｕｄｏ　Ｓｉｎｋインスタンスの情報は「ＩｏＴＳＰ３以外の他のすべてのＩｏＴＳＰに公開可」である。このＰｓｅｕｄｏ　Ｓｉｎｋの緯度と経度は「北緯３５度３７分１１．８５秒」、「東経１３９度４３分４１．０６秒」である。このＰｓｅｕｄｏ　Ｓｉｎｋの注釈は「大崎駅」である。このＰｓｅｕｄｏ　ＳｉｎｋインスタンスとｉｓＩｎｓｔａｌｌｅｄＩｎで接続するＡｒｅａインスタンスは「未定」である。このＰｓｅｕｄｏ　ＳｉｎｋインスタンスとｃｏｌｌｅｃｔｓＤａｔａＦｒｏｍで接続するＮｏｄｅインスタンスの識別子は「ＩｄＮｏｄｅ＿１１」と「ＩｄＮｏｄｅ＿１２」である。
　図１０にＮｏｄｅ１１のインスタンスデータを示す。このＮｏｄｅインスタンスの識別子は「ＩｄＮｏｄｅ＿１１」である。このＮｏｄｅを設置した日時は「２０２１年２月１日午前１０時」である。このＮｏｄｅの測定データは「他のすべてのＩｏＴＳＰに公開可」である。このＮｏｄｅの注釈は「Ｏｕｔｄｏｏｒ　Ｍｏｄｕｌｅ」である。このＮｏｄｅの機能は「温度」と「湿度」である。このＮｏｄｅインスタンスとｓｅｎｄｓＤａｔａＴｏで接続するＰｓｅｕｄｏ　Ｓｉｎｋインスタンスの識別子は「ＩｄＰＳｉｎｋ＿１１」である。このＮｏｄｅインスタンスとｉｓＣｏｌｌｏｃａｔｅｄＷｉｔｈで接続するＮｏｄｅインスタンスの識別子は「ＩｄＮｏｄｅ＿１２」である。
　図１１にＮｏｄｅ１２を表すＮｏｄｅインスタンスを示す。内容は図１０と同様であるが、Ｐｏｌｉｃｙフィールドの値が「ＩｄＩｏＴＳＰ＿Ｎｏｎｅ」であるので、このＮｏｄｅの測定データは他のＩｏＴＳＰには公開されない。
　Ａｄｍｉｎ　ＡＰＩ１はＮｏｄｅ設置要求メッセージを受信するとＡＡＡ　Ｓｅｒｖｅｒ１に認証認可要求メッセージを送信する（ステップＳ１０２）。図１２に認証認可要求メッセージを示す。ＩＤフィールドの値は「ＩｄＡｄｍｉｎ＿１」である。Ｃｒｅｄｅｎｔｉａｌフィールドの値は「ＣｒｅｄＡｄｍｉｎ＿１」である。
　ＡＡＡ　Ｓｅｒｖｅｒ１は認証認可要求メッセージを受信すると、ＩＤフィールドが示すエンティティの真正性と権限を確認する。確認が成功すると、ＡＡＡ　Ｓｅｒｖｅｒ１はＡｄｍｉｎ　ＡＰＩ１に認証認可応答メッセージを送信する（ステップＳ１０３）。図１３に認証認可応答メッセージを示す。Ｓｔａｔｕｓフィールドの値は処理の正常終了を示す「ＯＫ」である。
　Ａｄｍｉｎ　ＡＰＩ１は認証認可応答メッセージを受信するとＧｒａｐｈ　ＤＢ１にＮｏｄｅ登録要求メッセージを送信する（ステップＳ１０４）。図１４にＮｏｄｅ登録要求メッセージを示す。Ｎｏｄｅ登録要求メッセージのＰｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａフィールド、Ｎｏ　ｏｆ　Ｎｏｄｅｓフィールド、Ｎｏｄｅ　Ｉｎｓｔａｎｃｅ　Ｄａｔａフィールドの値は図８に示すＮｏｄｅ設置要求メッセージと同一である。
　Ｇｒａｐｈ　ＤＢ１はＮｏｄｅ登録要求メッセージを受信するとＰｓｅｕｄｏ　ＳｉｎｋインスタンスデータとＮｏｄｅインスタンスデータをデータベースに格納する。さらにＰｓｅｕｄｏ　Ｓｉｎｋ１１が設置されるＡｒｅａ１１のインスタンスデータを図１５に示すように更新する。図６に対してＴｉｍｅｓｔａｍｐフィールドの値が更新されている。さらにｃｏｎｔａｉｎｓフィールドが追加され、値は「ＩｄＰＳｉｎｋ＿１１」となる。これに伴い、Ｐｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータは図１６に示すように更新される。すなわち、ｉｓＩｎｓｔａｌｌｅｄＩｎフィールドの値は「ＩｄＡｒｅａ＿１１」となる。
　次にＧｒａｐｈ　ＤＢ１はＡｄｍｉｎ　ＡＰＩ１にＮｏｄｅ登録応答メッセージを送信する（ステップＳ１０５）。図１７にＮｏｄｅ登録応答メッセージを示す。Ｓｔａｔｕｓフィールドの値は処理の正常終了を示す「ＯＫ」である。
　Ａｄｍｉｎ　ＡＰＩ１はＮｏｄｅ登録応答メッセージを受信するとＡｄｍｉｎ　ＡＰＰ１にＮｏｄｅ設置応答メッセージを送信する（ステップＳ１０６）。図１８にＮｏｄｅ設置応答メッセージを示す。Ｓｔａｔｕｓフィールドは正常終了を表す「ＯＫ」である。
　さらに、上記と同様の手順によりＩｏＴＳＰ２においてＰｓｅｕｄｏ　Ｓｉｎｋ２１にＮｏｄｅ２１が設置されたとする。図１９にＰｓｅｕｄｏ　Ｓｉｎｋ２１のインスタンスデータを示す。図２０にＮｏｄｅ２１のインスタンスデータを示す。
（１．４．９．Ｎｏｄｅの撤去）
　次に、図２１にＩｏＴＳＰ１においてＮｏｄｅを撤去する手順を示す。図２１は、Ｎｏｄｅの撤去手順を示す図である。
　Ａｄｍｉｎ１はＡｄｍｉｎ　ＡＰＰ１を介してＡｄｍｉｎ　ＡＰＩ１にＮｏｄｅ撤去要求メッセージを送信する（ステップＳ２０１）。図２２にＮｏｄｅ撤去要求メッセージを示す。ＩＤフィールドの値は「ＩｄＡｄｍｉｎ＿１」である。Ｃｒｅｄｅｎｔｉａｌフィールドの値は「ＣｒｅｄＡｄｍｉｎ＿１」である。Ｎｏ　ｏｆ　Ｎｏｄｅｓフィールドは撤去するＮｏｄｅの個数を表す。以下、Ｎｏｄｅ　ＩＤフィールドがＮｏ　ｏｆ　Ｎｏｄｅｓフィールドの値の個数続く。
　Ａｄｍｉｎ　ＡＰＩ１はＮｏｄｅ撤去要求メッセージを受信するとＡＡＡ　Ｓｅｒｖｅｒ１に認証認可要求メッセージを送信する（ステップＳ２０２）。図１２に認証認可要求メッセージを示す。
　ＡＡＡ　Ｓｅｒｖｅｒ１は認証認可要求メッセージを受信すると、ＩＤフィールドが示すエンティティの真正性と権限を確認する。確認が成功すると、ＡＡＡ　Ｓｅｒｖｅｒ１はＡｄｍｉｎ　ＡＰＰ１に認証認可応答メッセージを送信する（ステップＳ２０３）。図１３に認証認可応答メッセージを示す。
　Ａｄｍｉｎ　ＡＰＩ１は認証認可応答メッセージを受信するとＧｒａｐｈ　ＤＢ１にＮｏｄｅ削除要求メッセージを送信する（ステップＳ２０４）。図２３にＮｏｄｅ削除要求メッセージを示す。Ｎｏｄｅ削除要求メッセージのＮｏ　ｏｆ　ＮｏｄｅｓフィールドとＮｏｄｅ　ＩＤフィールドの値は図２２に示すＮｏｄｅ撤去要求メッセージと同様である。
　Ｇｒａｐｈ　ＤＢ１はＮｏｄｅ削除応答メッセージを受信するとＮｏｄｅ　ＩＤフィールドが示すＮｏｄｅ　インスタンスをデータベースから削除する。これに伴い、削除するＮｏｄｅ　インスタンスのｓｅｎｄｓＤａｔａＴｏフィールドが示すＰｓｅｕｄｏ　Ｓｉｎｋインスタンスについて、該当するｃｏｌｌｅｃｔｓＤａｔａＦｒｏｍフィールドを削除する。削除の結果ｃｏｌｌｅｃｔｓＤａｔａＦｒｏｍフィールドの数が０になった場合、該当するＰｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａも削除する。
　次にＧｒａｐｈ　ＤＢ１はＡｄｍｉｎ　ＡＰＩ１にＮｏｄｅ削除応答メッセージを送信する（ステップＳ２０５）。図２４にＮｏｄｅ削除応答メッセージを示す。Ｓｔａｔｕｓフィールドは正常終了を表す「ＯＫ」である。
　Ａｄｍｉｎ　ＡＰＩ１はＮｏｄｅ削除応答メッセージを受信するとＩｏＴＳＰ　Ａｄｍｉｎ１にＮｏｄｅ撤去応答メッセージを送信する（ステップＳ２０６）。図２５にＮｏｄｅ撤去応答メッセージを示す。Ｓｔａｔｕｓフィールドは正常終了を表す「ＯＫ」である。
（１．４．１０．ＩｏＴＳＰ間での構成変更の通知）
　上記の例において、ＩｏＴＳＰ１は自身の管理下にＰｓｅｕｄｏ　Ｓｉｎｋ１１を設置した。本開示の実施の形態ではこのような構成変更をＩｏＴＳＰ間で共有する。図２６に、ＩｏＴＳＰ１の構成変更を他のＩｏＴＳＰに通知する手順の例を示す。図２６は、ＩｏＴＳＰ間での構成変更通知手順を示す図である。
　ＩｏＴＳＰ１内のＡｐｐ　ＡＰＩ１はＩｏＴＳＰ１内の構成変更を知るためＱｕｅｒｙ　Ｓｅｒｖｅｒ１に変更取得要求メッセージを送信する（ステップＳ３０１）。図２７に変更取得要求メッセージを示す。Ｔｉｍｅｓｔａｍｐフィールドは、このフィールドに示す日時以降に更新された情報を要求することを表し、この例では「２０２１年２月１日，０時０分０秒」である。
　Ｑｕｅｒｙ　Ｓｅｒｖｅｒ１は変更取得要求メッセージを受信すると、Ｔｉｍｅｓｔａｍｐフィールドが示す時刻以降に変更された構成情報をＧｒａｐｈ　ＤＢ１に問合せる（ステップＳ３０２）。なお、図２６ではＧｒａｐｈ　ＤＢ１への問合せ手順を省略している。
　Ｑｕｅｒｙ　Ｓｅｒｖｅｒ１はＧｒａｐｈ　ＤＢ１から変更された構成情報を受信するとＡｐｐ　ＡＰＩ１に変更取得応答メッセージを送信する（ステップＳ３０３）。図２８に変更取得応答メッセージを示す。Ｓｔａｔｕｓフィールドは正常終了を表す「ＯＫ」である。指定された時刻以降には１つのＰｓｅｕｄｏ　Ｓｉｎｋ（Ｐｓｅｕｄｏ　Ｓｉｎｋ１１）が追加されていたので、Ｎｏ　ｏｆ　Ｐｓｅｕｄｏ　Ｓｉｎｋｓフィールドの値は「１」となる。Ｐｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａフィールドの内容は図１６に示すＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータと同一である。
　Ａｐｐ　ＡＰＩ１は変更取得応答メッセージを受信すると、あらかじめ決められた転送先であるＩｏＴＳＰ２内のＡｐｐ　ＡＰＩ２に変更通知メッセージを送信する（ステップＳ３０４）。図２９に変更通知メッセージを示す。Ｎｏ　ｏｆ　Ｐｓｅｕｄｏ　Ｓｉｎｋｓフィールドの値は「１」である。Ｐｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａフィールドの値は、図１６に示すＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータをＩｏＴＳＰ２の公開鍵で暗号化したものである。すなわち、このときＡｐｐ　ＡＰＩ１は、図１６に示すＰｏｌｉｃｙフィールドによって公開先／非公開先を判定している（ステップＳ３０４参照）。図１６の例の場合、ＩｏＴＳＰ３のみが非公開先であるので、Ａｐｐ　ＡＰＩ１はＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータをＩｏＴＳＰ２の公開鍵で暗号化している。
　Ａｐｐ　ＡＰＩ２は変更通知メッセージを受信すると、自身の秘密鍵を使用してＰｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａフィールドを復号する。次にＡｐｐ　ＡＰＩ２はＱｕｅｒｙ　Ｓｅｒｖｅｒ２に変更登録要求メッセージを送信する（ステップＳ３０５）。図３０に変更登録要求メッセージを示す。Ｎｏ　ｏｆ　Ｐｓｅｕｄｏ　Ｓｉｎｋｓフィールの値は「１」である。Ｐｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａフィールドの値は、図１６に示すＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータと同一である。
　Ｑｕｅｒｙ　Ｓｅｒｖｅｒ２は変更登録要求メッセージを受信すると、Ｇｒａｐｈ　ＤＢ２にアクセスし、変更情報を登録する（ステップＳ３０６）。なお、図２６ではＧｒａｐｈ　ＤＢ２への登録手順を省略している。
　次にＱｕｅｒｙ　Ｓｅｒｖｅｒ２はＡｐｐ　ＡＰＩ２に変更登録応答メッセージを送信する（ステップＳ３０７）。図３１に変更登録応答メッセージを示す。Ｓｔａｔｕｓフィールドの値は正常終了を示す「ＯＫ」である。
　Ａｐｐ　ＡＰＩ２はＱｕｅｒｙ　Ｓｅｒｖｅｒ２に変更登録要求メッセージを送信するとともに、ＩｏＴＳＰ３内のＡｐｐ　ＡＰＩ３に変更通知メッセージを送信する（ステップＳ３０８）。図３２に変更通知メッセージを示す。Ｎｏ　ｏｆ　Ｐｓｅｕｄｏ　Ｓｉｎｋｓフィールの値は「１」である。Ａｐｐ　ＡＰＩ２は図１６に示すＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータのｐｏｌｉｃｙフィールドを参照し、変更通知メッセージの次の転送先であるＩｏＴＳＰ３には当該Ｐｓｅｕｄｏ　Ｓｉｎｋの情報公開が禁止されていることを知り、その次の転送先であるＩｏＴＳＰ４の公開鍵でＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータを暗号化し、Ｐｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａフィールドに格納する。すなわち、このときＡｐｐ　ＡＰＩ２は、図１６に示すＰｏｌｉｃｙフィールドによって公開先／非公開先を判定している（ステップＳ３０８参照）。図１６の例の場合、ＩｏＴＳＰ３のみが非公開先であるので、Ａｐｐ　ＡＰＩ２はＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータをＩｏＴＳＰ４の公開鍵で暗号化している。
　Ａｐｐ　ＡＰＩ３は変更通知メッセージを受信すると自身の秘密鍵でＰｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａフィールドの復号を試みるが、当該フィールドはＩｏＴＳＰ４の公開鍵で暗号化されているため復号できない。そこで、Ａｐｐ　ＡＰＩ３は変更通知メッセージを次の転送先であるＩｏＴＳＰ４内のＡｐｐ　ＡＰＩ４に送信する（ステップＳ３０９）。図３２に変更通知メッセージを示す。すなわち、このときＡｐｐ　ＡＰＩ３は、いわば自身の秘密鍵でＰｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａフィールドを復号できないことによって、Ｐｏｌｉｃｙフィールドの公開先／非公開先を判定していると言える（ステップＳ３０９参照）。
　Ａｐｐ　ＡＰＩ４は変更通知メッセージを受信すると、自身の秘密鍵を使用してＰｓｅｕｄｏ　Ｓｉｎｋ　Ｉｎｓｔａｎｃｅ　Ｄａｔａフィールドを復号する。次にＡｐｐ　ＡＰＩ４はＱｕｅｒｙ　Ｓｅｒｖｅｒ４に変更登録要求メッセージを送信する（ステップＳ３１０）。図３０に変更登録要求メッセージを示す。
　Ｑｕｅｒｙ　Ｓｅｒｖｅｒ４は変更登録要求メッセージを受信すると、Ｇｒａｐｈ　ＤＢ４にアクセスし、変更情報を登録する（ステップＳ３１１）。なお、図２６ではＧｒａｐｈ　ＤＢ４への登録手順を省略している。
　次にＱｕｅｒｙ　Ｓｅｒｖｅｒ４はＡｐｐ　ＡＰＩ４に変更登録応答メッセージを送信する（ステップＳ３１２）。図３１に変更登録応答メッセージを示す。
　同様にしてＩｏＴＳＰ２、ＩｏＴＳＰ３、およびＩｏＴＳ４も構成変更を他のＩｏＴＳＰに通知する。この例では、図１９に示すＰｓｅｕｄｏ　Ｓｉｎｋ２１の情報がＩｏＴＳＰ２からＩｏＴＳＰ１、ＩｏＴＳＰ３、およびＩｏＴＳＰ４に通知される。
（１．４．１１．Ｎｏｄｅからのセンサデータ通知（１））
　Ｎｏｄｅは測定したデータを定期的にＰｓｅｕｄｏ　Ｓｉｎｋに送信する。図５において、ＩｏＴＳＰ１内に設置されたＮｏｄｅ１１が測定データをＩｏＴＳＰ１内に登録する手順を図３３に示す。図３３は、Ｎｏｄｅからのセンサデータ通知手順（１）を示す図である。かかる通知手順（１）は、ＩｏＴＳＰ内におけるデータ通知手順を示す。
　Ｎｏｄｅ１１は定期的に温度などの測定データをＰｓｅｕｄｏ　Ｓｉｎｋ１１にデータ通知メッセージで送信する（ステップＳ４０１）。Ｎｏｄｅ１１とＰｓｅｕｄｏ　Ｓｉｎｋ１１間の通信は安全であると仮定する。図３４にデータ通知メッセージを示す。Ｎｏｄｅ　ＩＤフィールドの値は「ＩｄＮｏｄｅ＿１１」である。Ｔｉｍｅｓｔａｍｐフィールドはセンサデータを計測した日時を表し、この例では「２０２１年２月８日，１０時０分０秒」である。Ｄａｔａ　Ｆｏｒｍａｔ　ＩＤフィールドは、Ｄａｔａフィールドに格納されたデータのフォーマットの識別子を表す。Ｄａｔａフィールドにセンサデータが格納される。
　Ｐｓｅｕｄｏ　Ｓｉｎｋ１１はデータ通知メッセージを受信するとＳｅｎｓｉｎｇ　ＤＢ１にデータ登録要求メッセージを送信する（ステップＳ４０２）。図３５にデータ登録要求メッセージを示す。Ｎｏｄｅ　ＩＤフィールド、Ｔｉｍｅｓｔａｍｐフィールド、Ｄａｔａ　Ｆｏｒｍａｔ　ＩＤフィールド、およびＤａｔａフィールドの値は図３４と同一である。
　Ｓｅｎｓｉｎｇ　ＤＢ１はＮｏｄｅごとのセンサデータの時系列を保存するデータベースである。すなわち、１行（１レコード）は少なくとも日時、Ｎｏｄｅの識別子、Ｃａｐａｂｉｌｉｔｙ、センサデータの値、Ｐｓｅｕｄｏ　Ｓｉｎｋの識別子、緯度経度で構成される。Ｓｅｎｓｉｎｇ　ＤＢ１はデータ登録要求メッセージを受信するとＮｏｄｅ　ＩＤフィールドの値、Ｔｉｍｅｓｔａｍｐフィールドの値、およびＤａｔａフィールドの値をデータベースに格納する。その後、Ｓｅｎｓｉｎｇ　ＤＢ１はＰｓｅｕｄｏ　Ｓｉｎｋ１１にデータ登録応答メッセージを送信する（ステップＳ４０３）。図３６にデータ登録応答メッセージを示す。Ｓｔａｔｕｓフィールドは正常終了を表す「ＯＫ」である。
（１．４．１２．Ｎｏｄｅからのセンサデータ通知（２））
　次に、図５において、Ｓｅｎｓｏｒ　Ｐｒｏｖｉｄｅｒ５内に設置されたＳｅｎｓｏｒ５１がＩｏＴＳＰ１に測定データを登録する手順を図３７に示す。図３７は、Ｎｏｄｅからのセンサデータ通知手順（２）を示す図である。かかる通知手順（２）は、Ｓｅｎｓｏｒ　Ｐｒｏｖｉｄｅｒ１からＩｏＴＳＰ１へのデータ通知手順を示す。
　Ｓｅｎｓｏｒ５１は定期的に温度などの測定データをＰｓｅｕｄｏ　Ｓｉｎｋ５１にデータ通知メッセージで送信する（ステップＳ５０１）。Ｓｅｎｓｏｒ５１とＰｓｅｕｄｏ　Ｓｉｎｋ５１間の通信は安全であると仮定する。図３８にデータ通知メッセージを示す。Ｎｏｄｅ　ＩＤフィールドの値は「ＩｄＮｏｄｅ＿５１」である。Ｔｉｍｅｓｔａｍｐフィールドはセンサデータを計測した日時を表し、この例では「２０２１年２月８日，１０時０分０秒」である。Ｄａｔａ　Ｆｏｒｍａｔ　ＩＤフィールドは、Ｄａｔａフィールドに格納されたデータのフォーマットの識別子を表す。Ｄａｔａフィールドにセンサデータが格納される。
　Ｐｓｅｕｄｏ　Ｓｉｎｋ５１はデータ通知メッセージを受信すると、ＩｏＴＳＰ１内のＰｓｅｕｄｏ　Ｓｉｎｋ１１にデータ通知要求メッセージを送信する（ステップＳ５０２）。図３９にデータ登録要求メッセージを示す。Ｓｅｎｓｏｒ　Ｐｒｏｖｉｄｅｒ　ＩＤフィールドの値は「ＩｄＳｅｎｓＰ＿５」である。Ｃｒｅｄｅｎｔｉａｌフィールドの値は「ＣｒｅｄＳｅｎｓＰ＿５」である。Ｎｏｄｅ　ＩＤフィールド、Ｔｉｍｅｓｔａｍｐフィールド、Ｄａｔａ　Ｆｏｒｍａｔ　ＩＤフィールド、およびＤａｔａフィールドの値は図３８に示すデータ通知メッセージと同一である。
　Ｐｓｅｕｄｏ　Ｓｉｎｋ１１はデータ登録要求メッセージを受信するとＩｏＴＳＰ１内のＡＡＡ　Ｓｅｒｖｅｒ１に認証認可要求メッセージを送信する（ステップＳ５０３）。図４０に認証認可要求メッセージを示す。ＩＤフィールドの値は「ＩｄＳｅｎｓＰ＿５」である。Ｃｒｅｄｅｎｔｉａｌフィールドの値は「ＣｒｅｄＳｅｎｓＰ＿５」である。
　ＡＡＡ　Ｓｅｒｖｅｒ１は認証認可要求メッセージを受信すると、ＩＤフィールドが示す主体の真正性と権限を確認する。確認が成功すると、ＡＡＡ　Ｓｅｒｖｅｒ１はＰｓｅｕｄｏ　Ｓｉｎｋ１１に認証認可応答メッセージを送信する（ステップＳ５０４）。図１３に認証認可応答メッセージを示す。
　Ｐｓｅｕｄｏ　Ｓｉｎｋ１１は認証認可応答メッセージを受信するとＳｅｎｓｉｎｇ　ＤＢ１にデータ登録要求メッセージを送信する（ステップＳ５０５）。図４１にデータ登録要求メッセージを示す。Ｎｏｄｅ　ＩＤフィールド、Ｔｉｍｅｓｔａｍｐフィールド、Ｄａｔａ　Ｆｏｒｍａｔ　ＩＤフィールド、およびＤａｔａフィールドの値は図３８に示すデータ通知メッセージと同一である。
　Ｓｅｎｓｉｎｇ　ＤＢ１はデータ登録要求メッセージを受信するとデータをデータベースに格納し、Ｐｓｅｕｄｏ　Ｓｉｎｋ１１にデータ登録応答メッセージを送信する（ステップＳ５０６）。図３６にデータ登録応答メッセージを示す。
　Ｐｓｕｅｄｏ　Ｓｉｎｋ１１はデータ登録応答メッセージを受信するとＰｓｅｕｄｏ　Ｓｉｎｋ５１にデータ通知応答メッセージを送信する（ステップＳ５０７）。図４２にデータ通知応答メッセージを示す。Ｓｔａｔｕｓフィールドは正常終了を表すＯＫである。
（１．４．１３．Ｎｏｄｅからのセンサデータ通知（３））
　次に、図５において、ＩｏＴＳＰ１と契約しているＭｏｂｉｌｅ　Ｎｏｄｅ１３がＩｏＴＳＰ１に測定データを登録する手順を図４３に示す。図４３は、Ｎｏｄｅからのセンサデータ通知手順（３）を示す図である。かかる通知手順（３）は、Ｍｏｂｉｌｅ　Ｎｏｄｅ１３からＩｏＴＳＰ１へのデータ通知手順を示す。
　Ｍｏｂｉｌｅ　Ｎｏｄｅ１３は自身が契約しているＩｏＴＳＰ１内のＰｓｅｕｄｏ　Ｓｉｎｋ１１の無線通信範囲内に入ったことを検知し、Ｐｓｅｕｄｏ　Ｓｉｎｋ１１にモバイルデータ通知メッセージで測定データを送信する（ステップＳ６０１）。図４４にモバイルデータ通知メッセージを示す。Ｎｏｄｅ　ＩＤフィールドの値は「ＩｄＮｏｄｅ＿１３」である。Ｃｒｅｄｅｎｔｉａｌフィールドの値は「ＣｒｅｄＮｏｄｅ＿１３」である。Ｔｉｍｅｓｔａｍｐフィールドはセンサデータを送信する日時を表し、この例では「２０２１年２月８日，１０時０分０秒」である。Ｌａｔフィールドはセンサデータを送信するときのＭｏｂｉｌｅ　Ｎｏｄｅ１３の緯度を表し、この例では「北緯３５度３７分１２秒」である。Ｌｏｎフィールドはセンサデータを送信するときのＭｏｂｉｌｅ　Ｎｏｄｅ１３の経度を表し、この例では「東経１３９度４３分４１秒」である。Ｄａｔａ　Ｆｏｒｍａｔ　ＩＤフィールドは、Ｄａｔａフィールドに格納されたデータのフォーマットの識別子を表す。Ｄａｔａフィールドにセンサデータが格納される。
　Ｐｓｅｕｄｏ　Ｓｉｎｋ１１はモバイルデータ通知メッセージを受信するとＡＡＡ　Ｓｅｒｖｅｒ１に認証認可要求メッセージを送信する（ステップＳ６０２）。図４５に認証認可要求メッセージを示す。ＩＤフィールドの値は「ＩｄＮｏｄｅ＿１３」である。Ｃｒｅｄｅｎｔｉａｌフィールドの値は「ＣｒｅｄＮｏｄｅ＿１３」である。
　ＡＡＡ　Ｓｅｒｖｅｒ１は認証認可要求メッセージを受信すると、ＩＤフィールドが示す主体の真正性と権限を確認する。確認が成功すると、ＡＡＡ　Ｓｅｒｖｅｒ１はＰｓｅｕｄｏ　Ｓｉｎｋ１１に認証認可応答メッセージを送信する（ステップＳ６０３）。図１３に認証認可応答メッセージを示す。
　Ｐｓｅｕｄｏ　Ｓｉｎｋ１１は認証認可応答メッセージを受信すると、Ｓｅｎｓｉｎｇ　ＤＢ１にデータ登録要求メッセージを送信する（ステップＳ６０４）。図４６にデータ登録要求メッセージを示す。
　Ｓｅｎｓｉｎｇ　ＤＢ１はデータ登録要求メッセージを受信するとデータを登録し、Ｐｓｅｕｄｏ　Ｓｉｎｋ１１にデータ登録応答メッセージを送信する（ステップＳ６０５）。図３６にデータ登録応答メッセージを示す。Ｎｏｄｅ　ＩＤフィールド、Ｔｉｍｅｓｔａｍｐフィールド、Ｄａｔａ　Ｆｏｒｍａｔ　ＩＤフィールド、およびＤａｔａフィールドの値は図４４に示すモバイルデータ通知メッセージと同一である。
（１．４．１４．ＩｏＴ　Ａｐｐによるデータ取得）
　図５において、ＩｏＴ　Ａｐｐ１はＡｐｐ　ＡＰＩ１を介してセンサデータを取得するアプリケーションである。図４７にＩｏＴ　Ａｐｐ１がデータを取得する手順を示す。図４７は、ＩｏＴ　ＡＰＰによるデータ取得手順を示す図である。例として、Ａｐｐ　ＡＰＩ１（すなわち、Ｕｓｅｒ１）が図４８に示す実線の範囲を指定し、２０２１年２月１０日０時０分０秒から２３時５９分５９秒までの温度データを取得する場合の手順を説明する。
　ＩｏＴ　Ａｐｐ１はＡｐｐ　ＡＰＩ１にデータ取得要求メッセージを送信する（ステップＳ７０１）。図４９にデータ検索要求メッセージを示す。ＩＤフィールドの値は「ＩｄＵｓｅｒ＿１」である。Ｃｒｅｄｅｎｔｉａｌフィールドの値は「ＣｒｅｄＵｓｅｒ＿１」である。ＳＷ　Ｌａｔフィールド、ＳＷ　Ｌｏｎｇフィールド、ＮＥ　Ｌａｔフィールド、およびＮＥ　Ｌｏｎｇフィールドの値はそれぞれ「北緯３５度３７分０９秒」、「東経１３９度４３分２１秒」、「北緯３５度３７分３９秒」、「東経１３９度４３分４５秒」である。Ｃａｐａｂｉｌｉｔｙフィールドの値は「温度」である。Ｓｔａｒｔ　ＴｉｍｅフィールドとＥｎｄ　Ｔｉｍｅフィールドの値はそれぞれ「２０２１年２月１０日，０時０分０秒」と「２０２１年２月１０日，２３時５９分５９秒」である。
　Ａｐｐ　ＡＰＩ１はデータ取得要求メッセージを受信するとＡＡＡ　Ｓｅｒｖｅｒ１に認証認可要求メッセージを送信する（ステップＳ７０２）。図５０に認証認可要求メッセージを示す。ＩＤフィールドの値は「ＩｄＵｓｅｒ＿１」である。Ｃｒｅｄｅｎｔｉａｌフィールドの値は「ＣｒｅｄＵｓｅｒ＿１」である。
　ＡＡＡ　Ｓｅｒｖｅｒ１は認証認可要求メッセージを受信すると、ＩＤフィールドが示すエンティティの真正性と権限を確認する。確認が成功するとＡＡＡ　Ｓｅｒｖｅｒ１はＡｐｐ　ＡＰＩ１に認証認可応答メッセージを送信する（ステップＳ７０３）。図１３に認証認可応答メッセージを示す。
　Ａｐｐ　ＡＰＩ１は認証認可応答メッセージを受信するとＰｓｅｕｄｏ　Ｓｉｎｋ解決を実行する（ステップＳ７０４，Ｓ７０５）。Ｐｓｅｕｄｏ　Ｓｉｎｋ解決手順の詳細は後述する。その結果、Ａｐｐ　ＡＰＩ１はＩｏＴ　Ａｐｐ１がデータ取得を要求しているエリアに存在するＰｓｅｕｄｏ　Ｓｉｎｋインスタンスデータのリストを得る。この例では、Ａｐｐ　ＡＰＩ１は図１６に示すＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータと図１９に示すＰｓｅｕｄｏ　Ｓｉｎｋ２１のインスタンスデータを得る。
　次にＡｐｐ　ＡＰＩ１はノード解決を実行する（ステップＳ７０６～Ｓ７０９）。ノード解決手順の詳細は後述する。このように、Ａｐｐ　ＡＰＩ１とＱｕｅｒｙ　Ｓｅｒｖｅｒ１の間のインタフェースと、Ａｐｐ　ＡＰＩ１とＡｐｐ　ＡＰＩ２間のインタフェースは同一となっている。ノード解決の結果、Ａｐｐ　ＡＰＩ１はＩｏＴ　Ａｐｐ１がデータ取得を要求しているエリアに存在するＮｏｄｅインスタンスデータのリストを得る。この例では、Ａｐｐ　ＡＰＩ１は図１０に示すＮｏｄｅ１１のインスタンスデータ、図１１に示すＮｏｄｅ１２のインスタンスデータ、および図２０に示すＮｏｄｅ２１のインスタンスデータを得る。
　次にＡｐｐ　ＡＰＩ１はデータ解決を実行する（ステップＳ７１０～Ｓ７１３）。データ検索手順の詳細は後述する。このように、Ａｐｐ　ＡＰＩ１とＱｕｅｒｙ　Ｓｅｒｖｅｒ１の間のインタフェースと、Ａｐｐ　ＡＰＩ１とＡｐｐ　ＡＰＩ２間のインタフェースは同一となっている。データ解決の結果、Ａｐｐ　ＡＰＩ１はＮｏｄｅ１１、Ｎｏｄｅ１２、およびＮｏｄｅ１３が測定した温度データを得ることができる。
　次にＡｐｐ　ＡＰＩ１はＩｏＴ　Ａｐｐ１にデータ取得応答を送信する（ステップＳ７１４）。図５１にデータ取得応答メッセージの例を示す。Ｎｏ　ｏｆ　Ｎｏｄｅｓフィールドはセンサ値を取得したＮｏｄｅの個数を表し、この例ではＮｏｄｅ１１、Ｎｏｄｅ１２、およびＮｏｄｅ２１の３個である。以下、Ｎｏｄｅ　ＩＤフィールド、Ｎｏ　ｏｆ　Ｖａｌｕｅｓフィールド、およびＶａｌｕｅフィールドの組が３組続く。Ｎｏｄｅ　ＩＤフィールドはセンサ値を取得したＮｏｄｅの識別子を表す。ＣａｐａｂｉｌｉｔｙフィールドはＮｏｄｅの機能を表す。Ｖａｌｕｅフィールドはセンサ値を表す。
（１．４．１５．Ｐｓｅｕｄｏ　Ｓｉｎｋ解決手順）
　図４７に示すＰｓｅｕｄｏ　Ｓｉｎｋ解決とは、指定されたＡｒｅａに存在するＰｓｅｕｄｏ　Ｓｉｎｋを検索する処理であり、グラフ検索の一種である。図５２に示すグラフ解決手順を用い、Ｐｓｅｕｄｏ　Ｓｉｎｋ解決手順を説明する。図５２は、グラフ解決手順を示す図である。
　Ａｐｐ　ＡＰＩ１はＱｕｅｒｙ　Ｓｅｒｖｅｒ１にグラフ解決要求メッセージを送信する（ステップＳ８０１）。図５３にグラフ解決要求メッセージを示す。ＩｏＴＳＰ　ＩＤフィールドはグラフ解決を行うＩｏＴＳＰの識別子を表し、この例では「ＩｄＩｏＴＳＰ＿１」である、Ｎｏ　ｏｆ　ＱｕｅｒｉｅｓフィールドはＱｕｅｒｙの個数を表し、この例では「３０」である。これは、図４８に示すＡｒｅａの数である。３０個のＱｕｅｒｙは、それぞれのＡｒｅａに関してｃｏｎｔａｉｎｓというオブジェクトプロパティで接続するＰｓｅｕｄｏ　Ｓｉｎｋインスタンスを検索するという内容である。
　Ｑｕｅｒｙ　Ｓｅｒｖｅｒ１はグラフ解決要求メッセージを受信すると、Ｇｒａｐｈ　ＤＢ１にグラフ検索要求メッセージを送信する（ステップＳ８０２）。図５４にグラフ検索要求メッセージを示す。Ｎｏ　ｏｆ　ＱｕｅｒｉｅｓフィールドとＱｕｅｒｙフィールドの値は、図５３に示すグラフ解決要求メッセージと同一である。
　Ｇｒａｐｈ　ＤＢ１はグラフ検索要求メッセージを受信すると、データベースに対しＱｕｅｒｙフィールドが示す検索を行う。次に、Ｇｒａｐｈ　ＤＢ１はＡｐｐ　ＡＰＩ１にグラフ検索応答を送信し、検索の結果を伝える（ステップＳ８０３）。図５５にグラフ検索応答メッセージを示す。Ｓｔａｔｕｓフィールドは正常終了を表す「ＯＫ」である。この例ではグラフ検索要求メッセージにＱｕｅｒｙフィールドが３０個あったので、グラフ検索応答メッセージはＶａｌｕｅフィールドを３０個含む。この例では、Ａｒｅａ１１に関するＱｕｅｒｙに対し、図１６に示すＰｓｅｕｄｏ　Ｓｉｎｋ１１の内容がＶａｌｕｅとして返る。また、Ａｒｅａ２１に関するＱｕｅｒｙに対し、図１９に示すＰｓｅｕｄｏ　Ｓｉｎｋ２１の内容がＶａｌｕｅとして返る。その他のＡｒｅａに関するＱｕｅｒｙに対するＶａｌｕｅは空となる。
　Ｑｕｅｒｙ　Ｓｅｒｖｅｒ１はグラフ検索応答メッセージを受信すると、Ａｐｐ　ＡＰＩ１にグラフ解決応答メッセージを送信する（ステップＳ８０４）。図５６にグラフ解決応答メッセージを示す。Ｓｔａｔｕｓフィールドは正常終了を表す「ＯＫ」である。Ｎｏ　ｏｆ　ＶａｌｕｅｓフィールドとＶａｌｕｅフィールドの値は、図５５に示すグラフ検索応答メッセージと同一である。結果として、Ａｐｐ　ＡＰＩ１は図１６に示すＰｓｅｕｄｏ　Ｓｉｎｋ１１のインスタンスデータと、図１９に示すＰｓｅｕｄｏ　Ｓｉｎｋ２１のインスタンスデータを得る。
（１．４．１６．ノード解決手順）
　図４７に示すノード解決とは、指定されたＰｓｅｕｄｏ　Ｓｉｎｋにおいて指定された条件を満たすノードを検索する処理であり、グラフ検索の一種である．Ａｐｐ　ＡＰＩ１はまず図５２に示す手順でＰｓｅｕｄｏ　Ｓｉｎｋ１１についてノード解決を行う。図５７にＡｐｐ　ＡＰＩ１が送信するグラフ解決要求メッセージを示す。ＩｏＴＳＰ　ＩＤフィールドの値は「ＩｄＩｏＴＳＰ＿１」である。Ｎｏ　ｏｆ　Ｑｕｅｒｉｅｓフィールドの値は「１」である。Ｑｕｅｒｙフィールドの内容は、Ｐｓｅｕｄｏ　Ｓｉｎｋ１１に設置され、温度を計測可能なノードを検索することである。結果としてＡｐｐ　ＡＰＩ１は図５８に示すグラフ解決応答メッセージを受信する。Ｓｔａｔｕｓフィールドは正常終了を表す「ＯＫ」である。Ｎｏ　ｏｆ　Ｖａｌｕｅｓフィールドの値は「２」である。Ｖａｌｕｅフィールドには図１０と図１１に示すＮｏｄｅ１１とＮｏｄｅ１２のインスタンスデータが含まれる。
　次にＡｐｐ　ＡＰＩ１は図５９に示す手順でＰｓｅｕｄｏ　Ｓｉｎｋ２１についてノード解決を行う。図５９は、グラフ検索手順を示す図である。
　Ａｐｐ　ＡＰＩ１はＩｏＴＳＰ２内のＡｐｐ　ＡＰＩ２にグラフ解決要求メッセージを送信する（ステップＳ９０１）。図６０にグラフ解決要求メッセージを示す。ＩＤフィールドの値は「ＩｄＩｏＴＳＰ＿１」である。Ｃｒｅｄｅｎｔｉａｌフィールドの値は「ＣｒｅｄＩｏＴＳＰ＿１」である。ＩｏＴＳＰ　ＩＤフィールドの値は「ＩｄＩｏＴＳＰ＿２」である。Ｎｏ　ｏｆ　Ｑｕｅｒｉｅｓフィールドの値は「１」である。Ｑｕｅｒｙフィールドの内容は、Ｐｓｅｕｄｏ　Ｓｉｎｋ２１に設置され、温度を計測可能なノードを検索することである。
　Ａｐｐ　ＡＰＩ２はグラフ解決要求メッセージを受信すると、ＡＡＡ　Ｓｅｒｖｅｒ２に認証認可要求メッセージを送信する（ステップＳ９０２）。図６１に認証認可要求メッセージを示す。ＩＤフィールドの値は「ＩｄＩｏＴＳＰ＿１」である。Ｃｒｅｄｅｎｔａｉｌフィールドの値は「ＣｒｅｄＩｏＴＳＰ＿１」である。
　ＡＡＡ　Ｓｅｒｖｅｒ２は認証認可要求メッセージを受信すると、ＩＤフィールドが示すエンティティの真正性と権限を確認する。確認が成功するとＡＡＡ　Ｓｅｒｖｅｒ２はＡｐｐ　ＡＰＩ２に認証認可応答メッセージを送信する（ステップＳ９０３）。図１３に認証認可応答メッセージを示す。
　Ａｐｐ　ＡＰＩ２は認証認可応答メッセージを受信すると、Ｑｕｅｒｙ　Ｓｅｒｖｅｒ２にグラフ検索要求メッセージを送信する（ステップＳ９０４）。図６２にグラフ検索要求メッセージを示す。Ｎｏ　ｏｆ　Ｑｕｅｒｉｅｓフィールドの値は「１」である。Ｑｕｅｒｙフィールドの内容は、Ｐｓｅｕｄｏ　Ｓｉｎｋ２１に設置され、温度を計測可能なノードを検索することである。
　Ｑｕｅｒｙ　Ｓｅｒｖｅｒ２はグラフ検索要求メッセージを受信すると、Ｇｒａｐｈ　ＤＢ２にグラフ検索要求メッセージを送信する（ステップＳ９０５）。
　Ｇｒａｐｈ　ＤＢ２はグラフ検索要求メッセージを受信すると、データベースに対しＱｕｅｒｙフィールドが示す検索を行う。次に、Ｇｒａｐｈ　ＤＢ２はＱｕｅｒｙ　Ｓｅｒｖｅｒ２にグラフ検索応答を送信し、検索の結果を伝える（ステップＳ９０６）。図６３にグラフ検索応答メッセージを示す。Ｓｔａｔｕｓフィールドは正常終了を表す「ＯＫ」である。この例ではグラフ検索要求メッセージにＱｕｅｒｙフィールドが１個あったので、Ｎｏ　ｏｆ　Ｖａｌｕｅｓフィールドの値は「１」である。Ｖａｌｕｅフィールドの値は、図２０に示すＮｏｄｅ２１のインスタンスデータである。
　Ｑｅｕｒｙ　Ｓｅｒｖｅｒ２はグラフ検索応答メッセージを受信すると、Ａｐｐ　ＡＰＩ２にグラフ検索応答メッセージを送信する（ステップＳ９０７）。
　Ａｐｐ　ＡＰＩ２はグラフ検索応答メッセージを受信すると、Ａｐｐ　ＡＰＩ１にグラフ解決応答メッセージを送信する（ステップＳ９０８）。図６４にグラフ解決応答メッセージを示す。Ｓｔａｔｕｓフィールドの値は正常終了を示す「ＯＫ」である。Ｎｏ　ｏｆ　ＶａｕｌｅｓフィールドとＶａｌｕｅフィールドの値は図６３に示すグラフ検索応答メッセージと同一である。
　このように、Ａｐｐ　ＡＰＩ１とＡｐｐ　ＡＰＩ１２の間のインタフェース（ステップＳ９０１，Ｓ９０８）と、Ａｐｐ　ＡＰＩ２とＱｕｅｒｙ　Ｓｅｒｖｅｒ２間のインタフェース（ステップＳ９０４，Ｓ９０７）は同一となっている。
（１．４．１７．データ解決手順（１））
　図４７に示すデータ解決は、指定されたＮｏｄｅ、測定項目、測定時間から測定値を取得する処理である。Ａｐｐ　ＡＰＩ１は図６５に示すデータ解決手順でＮｏｄｅ１１とＮｏｄｅ１２から温度データを取得する。図６５は、データ解決手順（１）を示す図である。
　Ａｐｐ　ＡＰＩ１はＱｕｅｒｙ　Ｓｅｒｖｅｒ１にデータ解決要求を送信する（ステップＳ１００１）。図６６にデータ解決要求メッセージを示す。ＩｏＴＳＰ　ＩＤフィールドの値は「ＩｄＩｏＴＳＰ＿１」である。Ｎｏ　ｏｆ　Ｑｕｅｒｉｅｓフィールドの値は「２」である。以下、Ｎｏｄｅ　ＩＤフィールド、Ｃａｐａｂｉｌｉｔｙフィールド、Ｓｔａｒｔ　Ｔｉｍｅフィールド、およびＥｎｄ　Ｔｉｍｅフィールドの４つ組が２組続く。１つ目の４つ組では、Ｎｏｄｅ　ＩＤフィールドの値は「ＩｄＮｏｄｅ＿１１」である。Ｃａｐａｂｉｌｉｔｙフィールドの値は「温度」である。Ｓｔａｒｔ　Ｔｉｍｅフィールドの値は「２０２１年２月１０日，０時０分０秒」である。Ｅｎｄ　Ｔｉｍｅフィールドの値は「２０２１年２月１０日，２３時５９分５９秒」である。２つ目の４つ組ではＮｏｄｅ　ＩＤフィールドの値は「ＩｄＮｏｄｅ＿１２」であり、他のフィールドは同一である。
　Ｑｕｅｒｙ　Ｓｅｒｖｅｒ１はデータ解決要求メッセージを受信すると、Ｓｅｎｓｉｎｇ　ＤＢ１にデータ検索要求メッセージを送信する（ステップＳ１００２）。図６７にデータ検索要求メッセージを示す。Ｎｏ　ｏｆ　Ｑｕｅｒｉｅｓフィールド、Ｎｏｄｅ　ＩＤフィールド、Ｃａｐａｂｉｌｉｔｙフィールド、Ｓｔａｒｔ　Ｔｉｍｅフィールド、およびＥｎｄ　Ｔｉｍｅフィールドの値は図６６に示すデータ解決要求メッセージと同一である。
　Ｓｅｎｓｉｎｇ　ＤＢ１はデータ検索要求メッセージを受信すると、データベースに対しＱｕｅｒｙフィールドが示す検索を行う。次に、Ｓｅｎｓｉｎｇ　ＤＢ１はＱｕｅｒｙ　Ｓｅｒｖｅｒ１にデータ検索応答を送信し、検索の結果を伝える（ステップＳ１００３）。図６８にデータ検索応答メッセージを示す。Ｓｔａｔｕｓフィールドは正常終了を表す「ＯＫ」である。Ｎｏ　ｏｆ　Ｖａｌｕｅｓフィールドは回答となるデータの個数を示す。以下、Ｎｏｄｅ　ＩＤフィールド、Ｃａｐａｂｉｌｉｔｙフィールド、Ｔｉｍｅｓｔａｍｐフィールド、およびＶａｌｕｅフィールドの４つ組がＮｏ　ｏｆ　Ｖａｌｕｅｓフィールドの値の数だけ続く。
　Ｑｕｅｒｙ　Ｓｅｒｖｅｒ１はデータ検索応答メッセージを受信すると、Ａｐｐ　ＡＰＩ１にデータ解決応答メッセージを送信する（ステップＳ１００４）。図６９にデータ解決応答メッセージを示す。Ｔｙｐｅフィールド以外のフィールドは図６８に示すデータ解決応答メッセージと同一である。
（１．４．１８．データ解決手順（２））
　次にＡｐｐ　ＡＰＩ１は図７０に示すデータ解決手順でＮｏｄｅ２１から温度データを取得する。図７０は、データ解決手順（２）を示す図である。
　Ａｐｐ　ＡＰＩ１はＱｕｅｒｙ　Ｓｅｒｖｅｒ１にデータ解決要求メッセージを送信する（ステップＳ１１０１）。図７１にデータ解決要求メッセージを示す。ＩＤフィールドの値は「ＩｄＩｏＴＳＰ＿１」である。Ｃｒｅｄｅｎｔｉａｌフィールドの値は「ＣｒｅｄＩｏＴＳＰ＿１」である。ＩｏＴＳＰ　ＩＤフィールドの値は「ＩｄＩｏＴＳＰ＿２」である。Ｎｏ　ｏｆ　Ｑｕｅｒｉｅｓフィールドの値は「１」である。Ｎｏｄｅ　ＩＤフィールドの値は「ＩｄＮｏｄｅ＿２１」である。Ｃａｐａｂｉｌｉｔｙフィールドの値は「温度」である。Ｓｔａｒｔ　Ｔｉｍｅフィールドの値は「２０２１年２月１０日，０時０分０秒」である。Ｅｎｄ　Ｔｉｍｅフィールドの値は「２０２１年２月１０日，２３時５９分５９秒」である。
　Ａｐｐ　ＡＰＩ２はデータ解決要求メッセージを受信すると、ＡＡＡ　Ｓｅｒｖｅｒ２に認証認可要求メッセージを送信する（ステップＳ１１０２）。図６１に認証認可要求メッセージを示す。
　ＡＡＡ　Ｓｅｒｖｅｒ２は認証認可要求メッセージを受信すると、ＩＤフィールドが示すエンティティの真正性と権限を確認する。確認が成功するとＡＡＡ　Ｓｅｒｖｅｒ２はＡｐｐ　ＡＰＩ２に認証認可応答メッセージを送信する（ステップＳ１１０３）。図１３に認証認可応答メッセージを示す。
　Ａｐｐ　ＡＰＩ２は認証認可応答メッセージを受信すると、Ｑｕｅｒｙ　Ｓｅｒｖｅｒ２にデータ検索要求メッセージを送信する（ステップＳ１１０４）。図７２にデータ検索要求メッセージを示す。Ｎｏ　ｏｆ　Ｑｕｅｒｉｅｓフィールド、Ｎｏｄｅ　ＩＤフィールド、Ｃａｐａｂｉｌｉｔｙフィールド、Ｓｔａｒｔ　Ｔｉｍｅフィールド、およびＥｎｄ　Ｔｉｍｅフィールドの値は図７１に示すデータ解決要求メッセージと同一である。
　Ｑｕｅｒｙ　Ｓｅｒｖｅｒ２はデータ検索要求メッセージを受信するとＳｅｎｓｉｎｇ　ＤＢ２にデータ検索要求メッセージを送信する（ステップＳ１１０５）。
　Ｓｅｎｓｉｎｇ　ＤＢ２はデータ検索要求メッセージを受信すると、データベースに対しＱｕｅｒｙフィールドが示す検索を行う。次に、Ｓｅｎｓｉｎｇ　ＤＢ２はＱｕｅｒｙ　Ｓｅｒｖｅｒ２にデータ検索応答を送信し、検索の結果を伝える（ステップＳ１１０６）。図６８にデータ検索応答メッセージを示す。
　Ｑｕｅｒｙ　Ｓｅｒｖｅｒ２はデータ検索応答メッセージを受信すると、Ａｐｐ　ＡＰＩ２にデータ検索応答メッセージを送信する（ステップＳ１１０７）。
　Ａｐｐ　ＡＰＩ２はデータ検索応答メッセージを受信すると、Ａｐｐ　ＡＰＩ１にデータ解決応答メッセージを送信する（ステップＳ１１０８）。図６９にデータ解決応答メッセージを示す。
　このように、Ａｐｐ　ＡＰＩ１とＡｐｐ　ＡＰＩ２の間のインタフェース（ステップＳ１１０１，Ｓ１１０８）と、Ａｐｐ　ＡＰＩ２とＱｕｅｒｙ　Ｓｅｒｖｅｒ２間のインタフェース（ステップＳ１１０４，Ｓ１１０７）は同一となっている。
　以上、本開示の実施の形態について説明した。続いて、本開示の実施の形態に係るＩｏＴＳＰやノード、モジュール等として機能しうる情報処理装置の機能構成例を説明する。
［１．５．情報処理装置の機能構成例］
　図７３は、本開示の実施の形態に係る情報処理装置１００の機能構成例を示す説明図である。なお、図７３は、ＩｏＴＳＰやノード、モジュール等として機能しうるコンピュータである情報処理装置１００の機能概念的な構成を示すものであって、情報処理装置１００の構成に物理的な制約を課すものではない。したがって、情報処理装置１００は、物理的に１つの装置によって構成されてもよいし、物理的に複数の装置によって構成されてもよい。複数の装置によって構成される場合、各装置は、種々の場所に点在してもよい。また、複数の装置によって構成される場合、各装置が、それぞれ個別の情報処理装置１００として機能してもよいし、仮想的に１つの情報処理装置１００として機能してもよい。
　この点は、後述する通信部１１０、記憶部１２０、および制御部１３０についても同様であって、例えば、各ブロックの分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することが可能である。
　図７３に示すように、情報処理装置１００は、通信部１１０、記憶部１２０、および制御部１３０を含んで構成される。
　通信部１１０は、他の情報処理装置１００との間の通信、例えば情報処理装置１００を１つのＩｏＴＳＰと見なせば、他のＩｏＴＳＰとの間の通信を実行する。通信形態は有線であってもよく、無線であってもよい。通信部１１０からは、上述してきた各メッセージ等が、制御部１３０の制御の基で他の情報処理装置１００との間で、所定のポートより送信および所定のポートで受信される。
　記憶部１２０は、上述してきたＩｏＴＳＰ連携のアーキテクチャで用いられる各種情報やプログラムを記憶する。例えば、記憶部１２０は、上述したＧｒａｐｈ　ＤＢやＳｅｎｓｉｎｇ　ＤＢ等を記憶する。また、例えば、記憶部１２０は、本開示の実施の形態に係る情報処理プログラムを記憶する。記憶部１２０は、ＲＡＭ（Random　Access　Memory）、フラッシュメモリ（Flash　Memory）等の半導体メモリ素子や、ハードディスク、光ディスク等の記憶装置、ＳＳＤ（Solid　State　Drive）等の補助記憶装置等で構成されうる。
　制御部１３０は、例えばＣＰＵ（Central　Processing　Unit）等のプロセッサで構成され、記憶部１２０に記憶されている本開示の実施の形態に係る情報処理プログラムがＲＡＭを作業領域として実行されることにより、上述してきたＩｏＴＳＰ連携のアーキテクチャに基づく各種の処理を実行する。例えば、制御部１３０は、ユーザ、すなわちＵｓｅｒ１やＡｄｍｉｎ１の各種の要求等に基づいて、あるいは自動的に、Ｎｏｄｅの設置処理、Ｎｏｄｅの撤去処理、ＩｏＴＳＰ間での構成変更の通知処理、Ｎｏｄｅからのセンサデータ通知処理、ＩｏＴ　Ａｐｐによるデータ取得処理、Ｐｓｅｕｄｏ　Ｓｉｎｋ解決処理、ノード解決処理、データ解決処理、等を実行する。
　また、例えば、制御部１３０は、アプリケーションを介したユーザの取得要求に含まれる他のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて通信部１１０を介し他のＩｏＴＳＰからセンサデータを検索し、当該センサデータの検索時に、アプリケーションおよびＩｏＴＳＰ１間と同一の手続きを含むプロトコルインタフェースを用いる。
　なお、ユーザは、例えば図示略のユーザ端末を介して情報処理装置１００に対し各種の要求を行う。
　ユーザ端末は、ユーザによって利用される端末装置である。ユーザ端末は、例えば、スマートフォンを含む携帯電話機や、タブレット端末や、デスクトップ型ＰＣや、ノート型ＰＣや、ＰＤＡ（Personal　Digital　Assistant）等の情報処理装置である。また、ユーザ端末には、眼鏡型や時計型の情報処理端末であるウェアラブルデバイス（wearable　device）も含まれる。
　ユーザ端末は、ユーザによる操作や、ユーザ端末が有する機能（例えば、各ＩｏＴＳＰが提供するサービスを利用するためのアプリを実行する機能や、ブラウザ機能等）に応じて、各種情報を取得し、取得した情報に応じた情報を生成して送信する。
　例えば、ユーザ端末は、ＩｏＴ　ＡＰＰによるデータ取得処理に際しては、エリアの範囲指定画面を提示して、Ｕｓｅｒ１に図４８に示す実線の範囲を指定させる。
＜２．まとめ＞
　以上説明したように本開示の実施の形態によれば、ＩｏＴＳＰ間の連携を容易に実現することが可能な情報処理装置が提供される。
　本明細書の各装置が実行する処理における各ステップは、必ずしもシーケンス図またはフローチャートとして記載された順序に沿って時系列に処理する必要はない。例えば、各装置が実行する処理における各ステップは、フローチャートとして記載した順序と異なる順序で処理されても、並列的に処理されてもよい。
　また、各装置に内蔵されるＣＰＵ、ＲＯＭ（Read　Only　Memory）およびＲＡＭ（Random　Access　Memory）などのハードウェアを、上述した各装置の構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供されることが可能である。また、機能ブロック図で示したそれぞれの機能ブロックをハードウェアで構成することで、一連の処理をハードウェアで実現することもできる。
　以上、添付図面を参照しながら本開示の好適な実施の形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
［２．１．効果］
　上述してきたように、本開示の実施の形態に係る情報処理装置１００は、センサデータをユーザへ取得させるサービスを提供するＩｏＴＳＰ１（「第１のＩｏＴＳＰ」の一例に相当）として動作する情報処理装置であって、他のＩｏＴＳＰ（「第１のＩｏＴＳＰ以外の第２のＩｏＴＳＰ」の一例に相当）との間の通信を実行する通信部１１０と、アプリケーションを介した上記ユーザの取得要求に該当する上記センサデータを検索し、検索した上記センサデータを上記ユーザに対し応答する制御部１３０とを備え、制御部１３０は、上記取得要求に含まれる上記他のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて通信部１１０を介し上記他のＩｏＴＳＰから上記センサデータを検索し、当該センサデータの検索時に、上記アプリケーションおよびＩｏＴＳＰ１間と同一の手続きを含むプロトコルインタフェースを用いる。
　したがって、本開示の実施の形態に係る情報処理装置１００によれば、ＩｏＴＳＰ連携を容易に実現することができる。
　すなわち、本開示の実施の形態に係る情報処理装置１００によれば、ＩｏＴシステム（ＩｏＴＳＰ）のインタフェースをクエリ言語（例えばＧｒａｐｈＱＬ）に統一することによりＩｏＴＳＰ間の連携を容易にし、各ＩｏＴＳＰの実装の違いを隠蔽することができる。
　また、本開示の実施の形態に係る情報処理装置１００によれば、ＩｏＴアプリケーションとＩｏＴＳＰ間にＡｐｐ　ＡＰＩを導入し、Ａｐｐ　ＡＰＩがアプリケーションからの要求をクエリ言語に変換することにより、アプリケーションも容易にＩｏＴＳＰにアクセスできる。具体的には、提案するインタフェースはグラフデータベース（Ｇｒａｐｈ　ＤＢ）への問合せと時系列データベース（Ｓｅｎｓｉｎｇ　ＤＢ）への問合せにより構成される。なお、実際にはクエリ言語ＧｒａｐｈＱＬとＧｒａｐｈＱＬサーバを使用することとなる。
　また、本開示の実施の形態に係る情報処理装置１００は、センサのみを提供するセンサプロバイダとの連携も考慮している。したがって、本開示の実施の形態に係る情報処理装置１００によれば、センサプロバイダが収集したセンサデータを、Ｐｓｅｕｄｏ　Ｓｉｎｋを介してＩｏＴＳＰのＳｅｎｓｉｎｇ　ＤＢに格納することができる。
　また、本開示の実施の形態に係る情報処理装置１００は、ＩｏＴＳＰの構成情報のうち、Ｐｓｅｕｄｏ　Ｓｉｎｋの情報をＩｏＴＳＰ間で共有することによりＩｏＴＳＰ間の連携を実現する。Ｐｓｅｕｄｏ　Ｓｉｎｋはセンサノードが設置されている場所の情報は含むが、センサノード自体の情報は含まないため、ＩｏＴＳＰ間で共有すべき必要最低限の情報であると考えられる。これにより、ＩｏＴＳＰ間で交換する情報量をなるべく抑え、ＩｏＴＳＰ内部の構成情報を過度に公開することなく、ＩｏＴＳＰ間の連携を可能にする。
　また、本開示の実施の形態に係る情報処理装置１００によれば、Ｐｓｅｕｄｏ　ＳｉｎｋやＮｏｄｅの情報について、それらを所有するＩｏＴＳＰが公開ポリシを設定することが可能である。
［２．２．変形例］
　また、その他の変形例についても説明する。図７４～図７８は、変形例の説明図（その１）～（その５）である。
　上述した本開示の実施の形態では、ＰｏｌｉｃｙフィールドにＩｏＴＳＰレベルの指定（例えば、値「ＩｄＩｏＴＳＰ＿ＡＬＬ」、「ｅｘｃｅｐｔ　ＩｄＩｏＴＳＰ＿３」により、ＩｏＴＳＰ３を除くすべてのＩｏＴＳＰに公開可能であることを指定）を行った。
　しかし、図７４に示すように、かかる指定はＩｏＴＳＰレベルに限らず、Ｎｏｄｅレベルや、Ｃａｐａｂｉｌｉｔｙレベル等のデータレベルによって指定されてもよい。すなわち、ＩｏＴＳＰ内のＮｏｄｅごとに公開／非公開を指定したり、「温度」や「湿度」といったＣａｐａｂｉｌｉｔｙレベルごとに公開／非公開を指定したりすることができるようにしてもよい。これにより、ＮｏｄｅごとやＣａｐａｂｉｌｉｔｙレベルごとといった詳細なレベルでの情報保護設定が可能となる。
　また、本開示の実施の形態によれば、図７５に示すように、例えばＩｏＴＳＰ１が他のＩｏＴＳＰ２、３，４…に対し、常に１対１の接続を行うことなく、すなわちメッシュネットワークを形成することなくＩｏＴＳＰを行うことが可能である。
　すなわち、図７６に示すように、ＩｏＴＳＰ１は、直鎖状に接続された接続関係を介して例えばＩｏＴＳＰ４から必要なセンサデータを間接的に取得可能であるが、必ずしもその他のＩｏＴＳＰ５から直接的に必要となるセンサデータを取得することを制限するものではない。したがって、ＩｏＴＳＰ１は、ＩｏＴＳＰ間の関係、例えば契約関係等に応じて適宜直接的に必要となるセンサデータを取得するようにしてもよい。
　なお、ここに言う契約関係とは、例えば図７７や図７８に示すような例を挙げることができる。図７７に示すように、例えば２つのＩｏＴＳＰがそれぞれ同種のセンサを含んでおり、いわば対等関係にある場合には、ビジネス的には互いにデータを無償提供する契約関係も成り立ちうる。
　これに対し、図７８に示すように、２つのＩｏＴＳＰのうちの一方（ＩｏＴＳＰ２）に含まれるセンサ群が他方（ＩｏＴＳＰ１）に比べて充実している場合、いわばＩｏＴＳＰ２を主とし、ＩｏＴＳＰ１を従とする主従関係となりやすい。かかる場合、ビジネス的にはＩｏＴＳＰ２がＩｏＴＳＰ１に対しデータを有償提供する契約関係も成り立ちうる。
　したがって、例えば図７７に示すユースケースには、ＩｏＴＳＰ１はＩｏＴＳＰ２を含む対等な他のＩｏＴＳＰに対しては、必要なデータを間接的に取得するようにしてもよい。一方、例えば図７８に示すユースケースには、ＩｏＴＳＰ１はＩｏＴＳＰ５から常に直接的に必要なデータを取得するようにしてもよい。
　なお、本明細書に記載された効果はあくまで例示であって限定されるものでは無く、また他の効果があってもよい。
　また、本技術は以下のような構成も取ることができる。
（１）
　センサデータをユーザへ取得させるサービスを提供する第１のＩｏＴＳＰとして動作する情報処理装置であって、
　前記第１のＩｏＴＳＰ以外の第２のＩｏＴＳＰとの間の通信を実行する通信部と、
　アプリケーションを介した前記ユーザの取得要求に該当する前記センサデータを検索し、検索した前記センサデータを前記ユーザに対し応答する制御部と
　を備え、
　前記制御部は、
　前記取得要求に含まれる前記第２のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて前記通信部を介し前記第２のＩｏＴＳＰから前記センサデータを検索し、当該センサデータの検索時に、前記アプリケーションおよび前記第１のＩｏＴＳＰ間と同一の手続きを含むプロトコルインタフェースを用いる、情報処理装置。
（２）
　前記制御部は、
　前記第２のＩｏＴＳＰから、前記第１のＩｏＴＳＰおよび前記第２のＩｏＴＳＰ以外の第３のＩｏＴＳＰを介して間接的に前記センサデータを取得する、前記（１）に記載の情報処理装置。
（３）
　前記第３のＩｏＴＳＰは、
　前記第１のＩｏＴＳＰおよび前記第２のＩｏＴＳＰの間に直鎖状に１以上接続される、前記（２）に記載の情報処理装置。
（４）
　前記制御部は、
　クエリ言語を用いて前記同一の手続きを実行する、前記（３）に記載の情報処理装置。
（５）
　前記第１のＩｏＴＳＰおよび前記第２のＩｏＴＳＰは、
　各々の構成情報を保存する第１のデータベースおよび各々が管理するセンサノードの前記センサデータを保存する第２のデータベースをそれぞれ有しており、
　前記制御部は、
　前記クエリ言語を用いた前記第１のデータベースおよび前記第２のデータベースに対する問合せによって、前記センサデータを取得する、前記（４）に記載の情報処理装置。
（６）
　前記構成情報は、前記ポリシ情報を含み、
　前記第１のＩｏＴＳＰの前記ポリシ情報は、前記第１のＩｏＴＳＰの管理者によって設定され、
　前記制御部は、
　前記ポリシ情報に基づいて、前記情報共有を可とする前記第２のＩｏＴＳＰおよび前記第３のＩｏＴＳＰとの間で前記構成情報を共有させる、前記（５）に記載の情報処理装置。
（７）
　前記制御部は、
　前記第１のＩｏＴＳＰの前記構成情報が変更された場合に、前記情報共有を可とする前記第２のＩｏＴＳＰおよび前記第３のＩｏＴＳＰそれぞれの前記第１のデータベースに対する前記クエリ言語を用いた変更登録要求によって、前記第１のＩｏＴＳＰの前記構成情報を共有させる、前記（６）に記載の情報処理装置。
（８）
　前記制御部は、
　前記情報共有を可とする前記第２のＩｏＴＳＰまたは前記第３のＩｏＴＳＰのみ復号可能となるように、変更された前記構成情報の内容を暗号化する、前記（７）に記載の情報処理装置。
（９）
　前記構成情報は、
　前記第１のＩｏＴＳＰが管理するエリアに関する地理情報と前記エリアにおいて管理される前記センサノードとの関係をオントロジにより表現したデータ構造を有する、前記（５）～（８）のいずれか一つに記載の情報処理装置。
（１０）
　前記構成情報は、
　前記エリア、前記センサノード、前記エリアに設置されて前記センサノードを終端する地点をそれぞれクラスとする前記オントロジにより表現した前記データ構造を有する、前記（９）に記載の情報処理装置。
（１１）
　前記制御部は、
　前記アプリケーションを介して前記ユーザにより指定された検索範囲に含まれる前記地点に該当する前記センサデータを検索する、前記（１０）に記載の情報処理装置。
（１２）
　前記センサノードは、
　前記地点に対して一時的に接続する移動体を含む、前記（１０）または（１１）に記載の情報処理装置。
（１３）
　前記（１）～（１２）のいずれか一つに記載の情報処理装置である第１の情報処理装置と、
　前記第２のＩｏＴＳＰとして動作する第２の情報処理装置と
　を備える、情報処理システム。
（１４）
　センサデータをユーザへ取得させるサービスを提供する第１のＩｏＴＳＰとして動作する情報処理装置を用いた情報処理方法であって、
　前記第１のＩｏＴＳＰ以外の第２のＩｏＴＳＰとの間の通信を実行することと、
　アプリケーションを介した前記ユーザの取得要求に該当する前記センサデータを検索し、検索した前記センサデータを前記ユーザに対し応答することと
　を含み、
　前記応答することは、
　前記取得要求に含まれる前記第２のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて前記通信を実行することを介し前記第２のＩｏＴＳＰから前記センサデータを検索し、当該センサデータの検索時に、前記アプリケーションおよび前記第１のＩｏＴＳＰ間と同一の手続きを含むプロトコルインタフェースを用いる、情報処理方法。
（１５）
　センサデータをユーザへ取得させるサービスを提供する第１のＩｏＴＳＰとして動作するコンピュータを機能させるための情報処理プログラムであって、
　前記コンピュータに、
　前記第１のＩｏＴＳＰ以外の第２のＩｏＴＳＰとの間の通信を実行すること、
　アプリケーションを介した前記ユーザの取得要求に該当する前記センサデータを検索し、検索した前記センサデータを前記ユーザに対し応答すること
　を実行させ、
　前記応答することは、
　前記取得要求に含まれる前記第２のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて前記通信を実行することを介し前記第２のＩｏＴＳＰから前記センサデータを検索し、当該センサデータの検索時に、前記アプリケーションおよび前記第１のＩｏＴＳＰ間と同一の手続きを含むプロトコルインタフェースを用いる、情報処理プログラム。
　１００　　情報処理装置
　１１０　　通信部
　１２０　　記憶部
　１３０　　制御部

Claims (15)

  1. 　センサデータをユーザへ取得させるサービスを提供する第１のＩｏＴＳＰ（Internet　of　Things　Service　Provider）として動作する情報処理装置であって、
    　前記第１のＩｏＴＳＰ以外の第２のＩｏＴＳＰとの間の通信を実行する通信部と、
    　アプリケーションを介した前記ユーザの取得要求に該当する前記センサデータを検索し、検索した前記センサデータを前記ユーザに対し応答する制御部と
    　を備え、
    　前記制御部は、
    　前記取得要求に含まれる前記第２のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて前記通信部を介し前記第２のＩｏＴＳＰから前記センサデータを検索し、当該センサデータの検索時に、前記アプリケーションおよび前記第１のＩｏＴＳＰ間と同一の手続きを含むプロトコルインタフェースを用いる、情報処理装置。
  2. 　前記制御部は、
    　前記第２のＩｏＴＳＰから、前記第１のＩｏＴＳＰおよび前記第２のＩｏＴＳＰ以外の第３のＩｏＴＳＰを介して間接的に前記センサデータを取得する、請求項１に記載の情報処理装置。
  3. 　前記第３のＩｏＴＳＰは、
    　前記第１のＩｏＴＳＰおよび前記第２のＩｏＴＳＰの間に直鎖状に１以上接続される、請求項２に記載の情報処理装置。
  4. 　前記制御部は、
    　クエリ言語を用いて前記同一の手続きを実行する、請求項３に記載の情報処理装置。
  5. 　前記第１のＩｏＴＳＰおよび前記第２のＩｏＴＳＰは、
    　各々の構成情報を保存する第１のデータベースおよび各々が管理するセンサノードの前記センサデータを保存する第２のデータベースをそれぞれ有しており、
    　前記制御部は、
    　前記クエリ言語を用いた前記第１のデータベースおよび前記第２のデータベースに対する問合せによって、前記センサデータを取得する、請求項４に記載の情報処理装置。
  6. 　前記構成情報は、前記ポリシ情報を含み、
    　前記第１のＩｏＴＳＰの前記ポリシ情報は、前記第１のＩｏＴＳＰの管理者によって設定され、
    　前記制御部は、
    　前記ポリシ情報に基づいて、前記情報共有を可とする前記第２のＩｏＴＳＰおよび前記第３のＩｏＴＳＰとの間で前記構成情報を共有させる、請求項５に記載の情報処理装置。
  7. 　前記制御部は、
    　前記第１のＩｏＴＳＰの前記構成情報が変更された場合に、前記情報共有を可とする前記第２のＩｏＴＳＰおよび前記第３のＩｏＴＳＰそれぞれの前記第１のデータベースに対する前記クエリ言語を用いた変更登録要求によって、前記第１のＩｏＴＳＰの前記構成情報を共有させる、請求項６に記載の情報処理装置。
  8. 　前記制御部は、
    　前記情報共有を可とする前記第２のＩｏＴＳＰまたは前記第３のＩｏＴＳＰのみ復号可能となるように、変更された前記構成情報の内容を暗号化する、請求項７に記載の情報処理装置。
  9. 　前記構成情報は、
    　前記第１のＩｏＴＳＰが管理するエリアに関する地理情報と前記エリアにおいて管理される前記センサノードとの関係をオントロジにより表現したデータ構造を有する、請求項５に記載の情報処理装置。
  10. 　前記構成情報は、
    　前記エリア、前記センサノード、前記エリアに設置されて前記センサノードを終端する地点をそれぞれクラスとする前記オントロジにより表現した前記データ構造を有する、請求項９に記載の情報処理装置。
  11. 　前記制御部は、
    　前記アプリケーションを介して前記ユーザにより指定された検索範囲に含まれる前記地点に該当する前記センサデータを検索する、請求項１０に記載の情報処理装置。
  12. 　前記センサノードは、
    　前記地点に対して一時的に接続する移動体を含む、請求項１０に記載の情報処理装置。
  13. 　請求項１に記載の情報処理装置である第１の情報処理装置と、
    　前記第２のＩｏＴＳＰとして動作する第２の情報処理装置と
    　を備える、情報処理システム。
  14. 　センサデータをユーザへ取得させるサービスを提供する第１のＩｏＴＳＰ（Internet　of　Things　Service　Provider）として動作する情報処理装置を用いた情報処理方法であって、
    　前記第１のＩｏＴＳＰ以外の第２のＩｏＴＳＰとの間の通信を実行することと、
    　アプリケーションを介した前記ユーザの取得要求に該当する前記センサデータを検索し、検索した前記センサデータを前記ユーザに対し応答することと
    　を含み、
    　前記応答することは、
    　前記取得要求に含まれる前記第２のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて前記通信を実行することを介し前記第２のＩｏＴＳＰから前記センサデータを検索し、当該センサデータの検索時に、前記アプリケーションおよび前記第１のＩｏＴＳＰ間と同一の手続きを含むプロトコルインタフェースを用いる、情報処理方法。
  15. 　センサデータをユーザへ取得させるサービスを提供する第１のＩｏＴＳＰ（Internet　of　Things　Service　Provider）として動作するコンピュータを機能させるための情報処理プログラムであって、
    　前記コンピュータに、
    　前記第１のＩｏＴＳＰ以外の第２のＩｏＴＳＰとの間の通信を実行すること、
    　アプリケーションを介した前記ユーザの取得要求に該当する前記センサデータを検索し、検索した前記センサデータを前記ユーザに対し応答すること
    　を実行させ、
    　前記応答することは、
    　前記取得要求に含まれる前記第２のＩｏＴＳＰの識別子およびＩｏＴＳＰ間の情報共有の可否を示すポリシ情報に基づいて前記通信を実行することを介し前記第２のＩｏＴＳＰから前記センサデータを検索し、当該センサデータの検索時に、前記アプリケーションおよび前記第１のＩｏＴＳＰ間と同一の手続きを含むプロトコルインタフェースを用いる、情報処理プログラム。
PCT/JP2022/013150 2021-07-28 2022-03-22 情報処理装置、情報処理システム、情報処理方法、および情報処理プログラム WO2023007834A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202280051020.4A CN117693745A (zh) 2021-07-28 2022-03-22 信息处理装置、信息处理系统、信息处理方法和信息处理程序
US18/580,167 US20240340344A1 (en) 2021-07-28 2022-03-22 Information processing apparatus, information processing system, information processing method, and information processing program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-123308 2021-07-28
JP2021123308 2021-07-28

Publications (1)

Publication Number Publication Date
WO2023007834A1 true WO2023007834A1 (ja) 2023-02-02

Family

ID=85087817

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/013150 WO2023007834A1 (ja) 2021-07-28 2022-03-22 情報処理装置、情報処理システム、情報処理方法、および情報処理プログラム

Country Status (3)

Country Link
US (1) US20240340344A1 (ja)
CN (1) CN117693745A (ja)
WO (1) WO2023007834A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170187807A1 (en) * 2015-12-28 2017-06-29 Verizon Patent And Licensing Inc. Internet of things provisioning
US20200014660A1 (en) * 2017-03-15 2020-01-09 Abb Schweiz Ag Rule-based information exchange in internet of things

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170187807A1 (en) * 2015-12-28 2017-06-29 Verizon Patent And Licensing Inc. Internet of things provisioning
US20200014660A1 (en) * 2017-03-15 2020-01-09 Abb Schweiz Ag Rule-based information exchange in internet of things

Also Published As

Publication number Publication date
US20240340344A1 (en) 2024-10-10
CN117693745A (zh) 2024-03-12

Similar Documents

Publication Publication Date Title
US8589372B2 (en) Method and system for automated document registration with cloud computing
US9342806B2 (en) Method and system for automated project management
JP4612817B2 (ja) グループ管理装置及び情報処理方法、ならびにコンピュータプログラム及び記録媒体
EP2738672B1 (en) Communications network, computer architecture, computer-implemented method and computer program product for development and management of femtocell-based applications
KR101631618B1 (ko) 가상 개인화 그룹 생성 방법 및 가상 개인화 그룹을 이용하는 통신 기기와 허브를 포함하는 네트워크
JP2021527349A (ja) サービス加入者のプライバシのためのデータ匿名化
US20140081932A1 (en) Method and system for secure automated document registration from social media networks
CN111742531B (zh) 简档信息共享
JP2005293004A (ja) アクセス権管理システム及びアクセス権管理方法
US20200228986A1 (en) Unified data repository proxy
CN104520836A (zh) 用于促进应用之间的服务提供的系统和方法
WO2022062889A1 (zh) 一种切片管理方法、装置及通信设备
US10091134B2 (en) Open M2M system and method
JP2009075688A (ja) 携帯装置の位置に関する情報とファイル用暗号鍵とを管理するためのプログラムおよび方法
JP2005051475A (ja) 個人情報管理システム、個人情報管理方法及びそのプログラム
US20160308870A1 (en) Network access method and apparatus
CN101283540B (zh) 在数字权限管理中共享权限对象的方法及其装置和系统
US20210282009A1 (en) Integrity for mobile network data storage
Hao et al. Dbac: Directory-based access control for geographically distributed iot systems
JP2008250930A (ja) データ利用制限システム、ユーザ情報管理装置、データ利用判定装置及び移動機並びにデータ利用制限方法
WO2023007834A1 (ja) 情報処理装置、情報処理システム、情報処理方法、および情報処理プログラム
JP2000250832A (ja) 分散ディレクトリ管理システム
US9286305B2 (en) Virtual storage gate system
US20220311600A1 (en) Time-Aware Blockchain Staged Regulatory Control of Internet of Things Data
JP4915463B2 (ja) 情報処理装置

Legal Events

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

Ref document number: 22848918

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202280051020.4

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22848918

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP