WO2024070609A1 - 情報処理装置、情報処理方法、および記録媒体 - Google Patents

情報処理装置、情報処理方法、および記録媒体 Download PDF

Info

Publication number
WO2024070609A1
WO2024070609A1 PCT/JP2023/032951 JP2023032951W WO2024070609A1 WO 2024070609 A1 WO2024070609 A1 WO 2024070609A1 JP 2023032951 W JP2023032951 W JP 2023032951W WO 2024070609 A1 WO2024070609 A1 WO 2024070609A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
data
app
information processing
access
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2023/032951
Other languages
English (en)
French (fr)
Inventor
秀樹 安藤
弘孝 三好
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Semiconductor Solutions Corp
Original Assignee
Sony Semiconductor Solutions Corp
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 Sony Semiconductor Solutions Corp filed Critical Sony Semiconductor Solutions Corp
Publication of WO2024070609A1 publication Critical patent/WO2024070609A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2871—Implementation details of single intermediate entities
    • 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/50—Network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M11/00—Telephonic communication systems specially adapted for combination with other electrical systems

Definitions

  • the present disclosure relates to an information processing device, an information processing method, and a recording medium, and in particular to an information processing device, an information processing method, and a recording medium that enable an apparatus interposed between a device and an application apparatus to appropriately provide data from the device to the application apparatus.
  • NICE Network of Intelligent Camera Ecosystem
  • a relay device called a data service (hereafter referred to as DS) may be placed between the device and the application device.
  • the DS acts as a subcontractor for the application device and communicates with the device on behalf of the application device.
  • the NICE standard assumes a one-to-one relationship between a DS and an application device, but it is conceivable that a DS may act as an intermediary between multiple application devices. If a DS attempts to act as a subcontractor for multiple application devices, the current NICE standard does not allow it to communicate to the DS the device access rights that differ for each application device. As a result, a DS acting as a subcontractor for an application device does not know to which application device it may provide data from the device.
  • the present disclosure has been made in light of these circumstances, and enables an intermediary device between a device and an application device to appropriately provide data from the device to the application device.
  • An information processing device includes:
  • the data acquisition device includes a control unit that acquires, for a plurality of application devices, linking information between a device that outputs data and an application device that performs a specified data processing using the data, determines a destination of the data acquired from one or more of the devices based on the acquired linking information, and controls the transmission of the data to the one or more application devices determined as the destination.
  • the information processing method includes: An information processing device, Linking information between a device that outputs data and an application device that performs specified data processing using the data is obtained for a plurality of the application devices, and a destination of the data obtained from one or more of the devices is determined based on the obtained linking information, and the data is transmitted to the one or more application devices determined as the destination.
  • a recording medium includes: On the computer, The device is computer-readable and has a program recorded thereon for executing a process of acquiring, for a plurality of application devices, linking information between a device that outputs data and an application device that performs a specified data processing using the data, determining a destination for the data acquired from one or more of the devices based on the acquired linking information, and transmitting the data to the one or more application devices determined as the destination.
  • linking information between a device that outputs data and an application device that performs a specified data processing using the data is acquired for a plurality of the application devices, and a destination of the data acquired from one or more of the devices is determined based on the acquired linking information, and the data is transmitted to the one or more application devices determined as the destination.
  • An information processing device includes: The device includes a control unit that performs control to transmit an identifier for identifying the role of a TLS client or a TLS server and a TLS certificate corresponding to the identifier to two entities that communicate data generated by the device.
  • An information processing method according to a second aspect of the present disclosure, An information processing device, The device transmits to two entities communicating data generated by the device an identifier that identifies the role of a TLS client or a TLS server, and a TLS certificate corresponding to the identifier.
  • a recording medium includes: On the computer, A computer-readable medium having a program recorded thereon for causing two entities communicating data generated by the device to transmit an identifier for identifying the role of a TLS client or a TLS server, and a TLS certificate corresponding to the identifier.
  • an identifier that identifies the role of a TLS client or TLS server and a TLS certificate corresponding to that identifier are sent to two entities that communicate data generated by the device.
  • Communication can refer not only to wireless communication and wired communication, but also to a mixture of wireless and wired communication, i.e., wireless communication in some sections and wired communication in other sections. Furthermore, communication from one device to another device can be performed by wired communication, and communication from the other device to one device can be performed by wireless communication.
  • the information processing device can be realized by causing a computer to execute a program.
  • the program executed by the computer to realize this information processing device can be provided by transmitting it via a transmission medium or by recording it on a recording medium.
  • the information processing device may be an independent device or an internal block that constitutes a single device.
  • NICE Version 1.0.1 This is a diagram explaining access control in NICE Version 1.0.1. This is a diagram explaining access control in NICE Version 1.0.1 when DS is involved. This is a diagram explaining access control in NICE Version 1.1. This is a diagram explaining the basic operation sequence in the NICE Version 1.0.1 standard.
  • 1 is a block diagram showing an example of a configuration to be realized in a data processing system; 1 is a block diagram showing an example of a configuration to be realized in a data processing system; 1 is a block diagram showing an example of a configuration to be realized in a data processing system; 1 is a block diagram illustrating a configuration example of a data processing system according to a first embodiment of the present disclosure. This is a diagram explaining an overview of the first access control method for NICE Version 1.0.1.
  • FIG. 11 is a diagram showing an example of an AppControl object in step S51 of FIG. 10.
  • FIG. 11 is a diagram showing an example of an access information issuance request command in step S52 of FIG. 10.
  • FIG. 11 is a diagram showing an example of an AppControl object in step S54 of FIG. 10.
  • FIG. 11 is a diagram showing an example of an AppControl object in step S51 of FIG. 10.
  • FIG. 11 is a diagram showing an example of a DeviceControl object in step S51 of FIG. 10.
  • FIG. 11 is a diagram showing an example of a DeviceControl object in step S51 of FIG. 10.
  • FIG. 11 is a diagram showing an example of a DeviceControl object in step S55 of FIG. 10.
  • FIG. 10 is a diagram showing an example of a DeviceControl object in step S55 of FIG. 10.
  • FIG. 11 is a diagram showing an example of a SceneMark object in step S58 of FIG. 10.
  • FIG. 11 is a diagram showing an example of a DataSection object in step S58 of FIG. 10.
  • This is a diagram explaining an overview of the first access control method for NICE Version 1.1.
  • 1 is a flowchart illustrating the first access control process for NICE Version 1.1.
  • FIG. 22 is a diagram showing an example of GetSceneMode in step S87 of FIG. 21.
  • This is a diagram explaining an overview of the second access control method for NICE Version 1.0.1.
  • 11 is a flowchart illustrating the second access control process for NICE Version 1.0.1.
  • FIG. 25 shows an example of a DeviceList object in step S122 of FIG. 24.
  • FIG. 32 is a diagram for explaining the provider of the access information and the operation instruction information in FIGS. 28 to 31 .
  • FIG. 2 is a diagram illustrating a data pipeline.
  • FIG. 11 is a block diagram showing a configuration example of a data processing system according to a second embodiment of the present disclosure.
  • FIG. 2 is a diagram illustrating a certificate issuing function of a management server.
  • FIG. 2 is a diagram illustrating distribution of TLS certificates to entities.
  • 10 is a flowchart illustrating an authentication process performed by a data processing system according to a second embodiment.
  • FIG. 2 illustrates another example of a data pipeline.
  • FIG. 13 is a diagram for explaining distribution of TLS certificates when two-way data communication is performed between devices.
  • FIG. 2 is a block diagram showing an example of the configuration of a device.
  • FIG. 2 is a block diagram showing an example of the hardware configuration of a computer.
  • Access control process of NICE standard 2. Desired system configuration 3. Data processing system according to the first embodiment 4. First access control method (for NICE Version 1.0.1) 5. First access control method (NICE Version 1.1) 6. Second access control method (NICE Version 1.0.1) 7. Second access control method (NICE Version 1.1) 8. When multiple DSs are involved 9. Summary of the data processing system according to the first embodiment 10. Data processing system according to the second embodiment 11. Flowchart of authentication process 12. Summary of the data processing system according to the second embodiment 13. Example of hardware configuration
  • NICE standard access control processing The data processing system of the present disclosure includes a control for granting access rights that cannot be realized by the control according to the current NICE standard. Before describing the data processing system of the present disclosure, the access control according to the current NICE standard will be described.
  • the current NICE standard has at least two versions, Version 1.0.1 and Version 1.1.
  • FIG. 1 is a diagram for explaining access control in NICE Version 1.0.1.
  • the data processing system 1 shown in FIG. 1 includes a management server 10, multiple devices 11, and multiple App devices 12.
  • FIG. 1 shows only three devices 11A, 11B, and 11W and one App device 12A.
  • Each of the management server 10, the devices 11, and the App devices 12 constitutes an entity of the data processing system 1.
  • the management server 10 is a server device that appropriately grants access rights to a plurality of devices 11 and a plurality of App devices 12 arranged on a predetermined network for each user, thereby controlling access to each of the devices 11 and the App devices 12. Specifically, the management server 10 manages the devices 11 and the App devices 12 by linking them to user accounts, and controls the devices 11 and the App devices 12 corresponding to a predetermined user so that they can exchange data, while controlling the devices 11 and the App devices 12 belonging to different users so that they cannot exchange data.
  • the management server 10 controls the App device 12A so that the App device 12A can access the device 11A and the device 11B of the same user and can transmit and receive data, but controls the App device 12A so that the App device 12A cannot access and transmit and receive data to the device 11W of another user W.
  • the management server 10 corresponds to, for example, NICE LA/AS (License Authority and NICE Account Service).
  • a wide area communication network for wireless mobile devices such as a so-called 4G line or 5G line, a WAN (Wide Area Network), a LAN (Local Area Network), the Internet, a home network, a satellite communication network, etc.
  • a public telephone line network a wide area communication network for wireless mobile devices such as a so-called 4G line or 5G line, a WAN (Wide Area Network), a LAN (Local Area Network), the Internet, a home network, a satellite communication network, etc.
  • the device 11 is composed of devices including sensors such as an imaging sensor such as a surveillance camera, a ToF sensor, an IR (infrared) camera, a positioning sensor such as a GNSS (Global Navigation Satellite System) sensor, a temperature sensor, a sound pickup device (microphone), an air pressure sensor, a humidity sensor, a wind direction and speed sensor, a sunshine sensor, a precipitation sensor, a water level sensor, and a seismic intensity sensor (a sensor that detects the seismic intensity of an earthquake).
  • sensors such as an imaging sensor such as a surveillance camera, a ToF sensor, an IR (infrared) camera, a positioning sensor such as a GNSS (Global Navigation Satellite System) sensor, a temperature sensor, a sound pickup device (microphone), an air pressure sensor, a humidity sensor, a wind direction and speed sensor, a sunshine sensor, a precipitation sensor, a water level sensor, and a seismic intensity sensor (a sensor that detects the seismic intensity of an earthquake).
  • GNSS Global Navigation Satellite System
  • the device 11 transmits data acquired by the sensors to the corresponding App device 12 either directly or after performing a predetermined data processing using an internal calculation device such as a CPU (Central Processing Unit) or MPU (Micro Processing Unit) or an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or FPGA (Field-Programmable Gate Array).
  • the ToF sensor is a sensor that directly or indirectly measures the return time of reflected light from the subject to acquire shape information (depth information/image) such as the distance between the ToF sensor and the subject and unevenness.
  • the device 11 may be installed in a fixed location, such as a surveillance camera installed at home or a store, or may be mounted on a mobile object and installed so that it can move anywhere. Examples of mobile objects include automobiles, electric vehicles, hybrid electric vehicles, motorcycles, bicycles, personal mobility, airplanes, drones, ships, robots (mobile robots), construction machinery, agricultural machinery (tractors), etc.
  • the App device 12 is an apparatus (application device) that has hardware such as a CPU (Central Processing Unit), a ROM (Read Only Memory), and a RAM (Random Access Memory), and that executes an application (program) that performs predetermined data processing using data transmitted from the device 11.
  • the App device 12 may be, for example, a server device, a mobile terminal such as a smartphone, a tablet PC (Personal Computer), a smart watch, a mobile phone, a laptop PC, or a notebook PC, or a wearable device such as an HMD (Head Mounted Display).
  • the App device 12 may also be an ECU (Electronic Control Unit) mounted on a vehicle, or a controller that remotely controls a drone or a robot.
  • ECU Electronic Control Unit
  • the App device 12 may also have a display unit (not shown) that displays to the user, an operation unit (not shown) that accepts operations from the user, a speaker (not shown) that outputs audio to the user, etc.
  • a display unit not shown
  • an operation unit not shown
  • a speaker not shown
  • NICE Version 1.0.1 the App device 12 is called an App or a Service.
  • the management server 10 manages the devices 11 and App devices 12 corresponding to the users by linking them to the user accounts of the respective users, and for each device 11, manages the App devices 12 that can use the device 11.
  • Devices 11A and 11B and App device 12A are linked to the account of user A, and App device 12A is registered as the App device 12 that can use devices 11A and 11B.
  • the management server 10 transmits to the App device 12A, by transmitting an AppControl object in response to a request from the App device 12A, access point information related to the devices 11A and 11B used when the App device 12A connects to the devices 11A and 11B.
  • This access point information includes a device ID (UUID) for identifying the device 11 of the communication partner, public key information, an access token, and the like.
  • the access token includes source information (sub: subject) and destination information (aud: audience).
  • the access point information related to the device 11A includes the device ID and public key information of the device 11A, the source (sub) of the access token is the App device 12A, and the destination (aud) is the device 11A.
  • the access point information related to the device 11B includes the device ID and public key information of the device 11B, the source (sub) of the access token is the App device 12A, and the destination (aud) is the device 11B.
  • each of the device 11 and the App device 12 is composed of a collection of one or more nodes, and the level of access point information (connection information) is classified into three classes: Management I/F (Interface), Control I/F, and Data I/F.
  • the Management I/F is a class that issues instructions to the entire device 11 or App device 12, and can include access point information for the Control I/F and Data I/F.
  • the Control I/F is a class that issues instructions to a node, and includes access point information for the Control I/F on a node-by-node basis.
  • the Data I/F is a class that issues instructions regarding data, and includes access point information for one or more ports of the Data I/F on a node-by-node basis.
  • a port is a concept that indicates the communication destination of the Data I/F, and a node can have multiple ports.
  • the management server 10 sends access point information about the App device 12A to device 11A, which is used when device 11A connects to the App device 12A.
  • the access point information about the App device 12A includes the device ID and public key information of the App device 12A, and the source (sub) of the access token is device 11A and the destination (aud) is the App device 12A.
  • the management server 10 similarly sends access point information about the App device 12A to device 11B by the DeviceControl object.
  • the access point information about the App device 12A includes the device ID and public key information of the App device 12A, and the source (sub) of the access token is device 11B and the destination (aud) is the App device 12A.
  • the DeviceControl object includes access point information for the Control I/F of the App device 12A, but does not include access point information for the Data I/F.
  • the access point information for the Data I/F is contained in the SceneMode object described below.
  • the AppControl object sent from the management server 10 to the App device 12A does not include access point information for the device 11W corresponding to another user, so the App device 12A cannot access the device 11W. Furthermore, the DeviceControl object provided to the device 11W does not include access point information for the App device 12A. If the App device 12A accesses the device 11W, the device 11W will refuse communication with the App device 12A.
  • the App device 12A communicates with the device 11A using the access point information for the device 11A acquired from the management server 10, and specifies data destination information, etc. by sending a SceneMode object to the device 11A.
  • the SceneMode object is an object that sets a scene mode as operation instruction information.
  • the device 11A uses the access point information for the Data I/F included in the SceneMode object to transmit data acquired by executing the operation set in the scene mode to the App device 12A.
  • the source (sub) of the access token for the access point information for the Data I/F is the device 11A, and the destination (aud) is the App device 12A.
  • the App device 12A specifies data destination information, etc. for the device 11B by sending a SceneMode object to the device 11B.
  • the source (sub) and destination (aud) are specified and access is controlled by the AppControl object, DeviceControl object, and SceneMode object based on the appropriate linking information between the device 11 and the App device 12 held by the management server 10.
  • the AppControl object, DeviceControl object, and SceneMode object are API (Application Programming Interface) objects that can be obtained from an information provider by sending a request requesting configuration information to the information provider.
  • NICE Version 1.0.1 (DS included)>
  • a DS 13 may be interposed between the device 11 and the App device 12.
  • the DS 13 is one of the entities of the data processing system 1, and manages a plurality of devices 11 and operates as a subcontractor of the App device 12. By interposing the DS 13, when there are a plurality (a large number) of devices 11 associated with the App device 12, the App device 12 does not need to access each device 11 individually.
  • the DS 13 is called a Data Service.
  • the management server 10 transmits to the App device 12 an AppControl object in response to a request from the App device 12, thereby transmitting to the App device 12 access point information related to the DS 13 that is used when the App device 12 connects to the DS 13.
  • the access point information includes a device ID (UUID) that identifies the communication partner DS 13, public key information, an access token, and the like.
  • the source (sub) of this access token is the App device 12A, and the destination (aud) is the DS 13.
  • DS13 behaves toward downstream devices 11A and 11B (on the edge side of the network) as an entity equivalent to App device 12 between device 11 and App device 12 shown in FIG. 1.
  • DS13 behaves toward upstream App device 12A (on the cloud side of the network) as an entity equivalent to device 11 between device 11 and App device 12 shown in FIG. 1.
  • an AppControl object for performing processing as an entity equivalent to App device 12A is sent from management server 10 to DS13 in response to a request from DS13.
  • the AppControl object includes access point information for device 11A and access point information for device 11B.
  • the access point information for device 11A includes a device ID for identifying device 11A, which is the communication partner, public key information, an access token, etc.
  • the source (sub) of the access token for device 11A is DS13, and the destination (aud) is device 11A.
  • the access point information for device 11B includes a device ID for identifying device 11B, which is the communication partner, public key information, an access token, etc.
  • the source (sub) of the access token for device 11B is DS13, and the destination (aud) is device 11B.
  • the management server 10 sends to the DS 13 a DeviceControl object for performing processing as an entity equivalent to the device 11.
  • the DeviceControl object includes the device ID and public key information of the App device 12A, and the source (sub) of the access token is the DS 13 and the destination (aud) is the App device 12A.
  • the management server 10 sends access point information for DS13 to device 11A, which is used when device 11A connects to DS13.
  • the access point information for DS13 intended for device 11A includes the device ID and public key information of DS13, with the source (sub) of the access token being device 11A and the destination (aud) being DS13.
  • the management server 10 similarly sends access point information for DS13 to device 11B by a DeviceControl object.
  • the access point information for DS13 intended for device 11B includes the device ID and public key information of DS13, with the source (sub) of the access token being device 11B and the destination (aud) being DS13.
  • DS13 communicates with device 11A using access point information about device 11A obtained from management server 10, and specifies data destination information, etc. by sending a SceneMode object to device 11A.
  • DS13 also communicates with device 11B using access point information about device 11B obtained from management server 10, and specifies data destination information, etc. by sending a SceneMode object to device 11B.
  • Device 11A uses the access point information for the Data I/F included in the SceneMode object to transmit data acquired by performing the operation set in the scene mode to DS13.
  • Device 11B uses the access point information for the Data I/F included in the SceneMode object to transmit data acquired by performing the operation set in the scene mode to DS13.
  • DS13 uses the access point information for the Data I/F included in the SceneMode object to transmit data acquired from device 11A or device 11B to App apparatus 12A.
  • DS13 access control similar to that between device 11 and App device 12 is performed between device 11 and DS13 and between DS13 and App device 12.
  • Data acquired by device 11A is transferred in the order from device 11A to DS13 and from DS13 to App device 12A.
  • Data acquired by device 11B is transferred in the order from device 11B to DS13 and from DS13 to App device 12A.
  • the AppControl object or DeviceControl object is sent from the management server 10 to the devices 11A and 11B, the App device 12A, and the DS 13, and the SceneMode object is sent from the App device 12A or DS 13, which is the higher-level entity.
  • a broker e.g., an MQTT broker may be present between the two.
  • NICE Version 1.1 Next, referring to FIG. 3, access control in NICE Version 1.1 will be described by taking as an example the access control for the device 11A and device 11B corresponding to a predetermined user A and the App apparatus 12A, as in the above example.
  • NICE Version 1.1 DS 13 is always present.
  • a DPC (Data Pipeline Controller) 14 that manages (controls) the data pipeline is newly added to the data processing system 1.
  • the management server 10 manages the device 11 and the App device 12 by linking them to a user account. However, the management server 10 does not have information that directly links the device 11 and the App device 12 corresponding to a specific user.
  • the DPC 14 has information related to data processing by acquiring the necessary information from the management server 10 and the App device 12A.
  • the DPC 14 has data pipeline information for device 11A-DS13-App device 12A and device 11B-DS13-App device 12A, and setting information for sending SceneMode objects, which it acquires from the management server 10 or the App device 12A.
  • the management server 10 transmits to the App device 12A access point information related to the DS13, which is used when the App device 12A connects to the DS13, by transmitting an AppControl object in response to a request from the App device 12A.
  • This access point information includes a device ID for identifying the communication partner DS13, public key information, an access token, and the like.
  • the source (sub) of this access token is the App device 12A, and the destination (aud) is the DS13.
  • the management server 10 sends access point information for DPC 14 to device 11A, which is used when device 11A connects to DPC 14, by sending a DeviceControl object to device 11A in response to a request from device 11A.
  • the access point information for DPC 14 intended for device 11A includes the device ID and public key information of DPC 14, with the source (sub) of the access token being device 11A and the destination (aud) being DPC 14.
  • the management server 10 sends access point information for DPC 14 to device 11B by sending a DeviceControl object to device 11B.
  • the access point information for DPC 14 intended for device 11B includes the device ID and public key information of DPC 14, with the source (sub) of the access token being device 11B and the destination (aud) being DPC 14.
  • NICE Version 1.0.1 the DeviceControl object can be sent in response to a request from each device 61, or can be sent without a request, but in NICE Version 1.1, the DeviceControl object is always sent in response to a request from each device 61.
  • the management server 10 transmits an AppControl object for performing processing equivalent to the App device 12 to the DS13 in response to a request from the DS13.
  • the AppControl object includes access point information for device 11A and access point information for device 11B.
  • the access point information for device 11A includes a device ID for identifying the communication partner device 11A, public key information, an access token, etc.
  • the source (sub) of the access token for device 11A is DS13, and the destination (aud) is device 11A.
  • the access point information for device 11B includes a device ID for identifying the communication partner device 11B, public key information, an access token, etc.
  • the source (sub) of the access token for device 11B is DS13, and the destination (aud) is device 11B.
  • the management server 10 sends a DeviceControl object to the DS13 in response to a request from the DS13, for performing processing equivalent to the device 11.
  • the DeviceControl object includes the device ID and public key information of the DPC14, and the source (sub) of the access token is the DS13, and the destination (aud) is the DPC14.
  • the DPC 14 communicates with the device 11A using access point information related to the device 11A shared with the App device 12A, and specifies data destination information, etc. by sending a SceneMode object to the device 11A.
  • the DPC 14 also communicates with the device 11B using access point information related to the device 11B shared with the App device 12A, and specifies data destination information, etc. by sending a SceneMode object to the device 11B.
  • the DPC 14 also communicates with the DS 13 using access point information related to the DS 13 shared with the App device 12A, and specifies data destination information, etc. by sending a SceneMode object to the DS 13.
  • NICE Version 1.1 is the same as NICE Version 1.0.1 in that the AppControl object or DeviceControl object is sent from the management server 10 to the devices 11A and 11B, the App device 12A, and the DS 13, but it differs in that the SceneMode object is sent from the DPC 14. Also, in NICE Version 1.1, the access token is defined in the application layer, and only the WebAPI is supported.
  • FIG 4 is a sequence diagram showing an example of a basic operation sequence in the NICE Version 1.0.1 standard.
  • the App device 12 or DS 13, which are higher-level entities that give instructions to the device 11, are collectively referred to as the App device 12/DS 13.
  • the basic operation consists of a capability acquisition phase P10 in which the App device 12/DS 13 acquires the processing capability of the device 11, a mode setting phase P20 in which a SceneMode object is set in the device 11, an execution phase P30 in which the device 11 executes a predetermined data processing specified in the SceneMode object (e.g., detection processing by AI), and an end phase P40 in which the device 11 ends the predetermined data processing.
  • a scene mode such as human detection or moving object detection can be specified.
  • the scene modes include, for example, "1. Face, 2. Human, 3. Object Label, 4. Animal, 5. Text/Logo/QRCode, 6. Vehicle, 7. Custom".
  • step S11 the App device 12/DS 13 notifies the device 11 of GetCapabilities, which is an instruction (command) for reporting the processing capability of the device 11 to the App device 12/DS 13.
  • step S12 the device 11 notifies the App device 12/DS 13 of information (Capabilities) related to its own processing capability.
  • the information (Capabilities) related to the processing capability of each device 11 may be managed in advance in the App device 12/DS 13 by performing the capability acquisition phase P10 in advance.
  • step S13 the App apparatus 12/DS 13 notifies the device 11 of SetSceneMode, which is an instruction as to which SceneMode object to use.
  • step S14 the App device 12/DS 13 notifies the device 11 of StartScene, which is an instruction for starting a predetermined data processing specified by SetSceneMode.
  • StartScene is notified
  • step S15 the device 11 executes the data processing specified by the SceneMode object in the mode setting phase P20.
  • step S16 the device 11 generates transmission data based on the acquired data and transmits it to the App device 12/DS 13 by SetSceneMark or SetSceneData.
  • SetSceneData data itself such as images and audio is transmitted.
  • SetSceneMark metadata associated with images and audio is transmitted.
  • the SceneMode object when human detection is set as the SceneMode object, information such as a thumbnail or a timestamp when a person appears is transmitted by SetSceneMark.
  • the destination of data transmitted by SetSceneMark and SetSceneData is not limited to the App device 12/DS 13, and may be another device 11, etc.
  • a StopScene command which is an instruction to end the predetermined data processing specified by the SceneMode object, is sent from the App device 12/DS 13 to the device 11. In response to this, the device 11 ends the predetermined data processing specified by the SceneMode object.
  • the data acquired by the device 11 is sent to the DS 13 and the App device 12 through the basic operation sequence described above.
  • FIG. 5 is a block diagram showing an example of a configuration that may be realized in data processing system 1.
  • the data processing system 1 in FIG. 5 is composed of three devices 11, device 11A, device 11B, and device 11C, a DS 13, and two App devices 12, App device 12X and App device 12Y.
  • App device 12X processes data sent from device 11A and device 11B.
  • App device 12Y processes data sent from device 11A and device 11C.
  • Device 11A is permitted to be used by both App device 12X and App device 12Y.
  • Device 11B is permitted to be used by App device 12X.
  • Device 11C is permitted to be used by App device 12Y.
  • DS13 is interposed between the three devices 11A to 11C and the two App devices 12X and 12Y, and as a subcontractor for the App devices 12X and 12Y, it is necessary to appropriately distribute and transmit data sent from the three devices 11A, 11B, and 11C to either the App device 12X or 12Y.
  • DS13 transmits data transmitted from device 11A to App devices 12X and 12Y. Furthermore, DS13 transmits data transmitted from device 11B only to App device 12X, and transmits data transmitted from device 11C only to App device 12Y. Conversely, DS13 needs to perform control so that data transmitted from device 11C is not transmitted to App device 12X, and data transmitted from device 11B is not transmitted to App device 12Y.
  • App devices 12X and 12Y want to use the data transmitted to them without being overly concerned about which device 11 that is permitted to use the data came from. However, if the information required is which device 11 the data came from, it is necessary to be able to accurately recognize this.
  • the DS 13 may perform additional processing on the data before forwarding it depending on the device 11 from which the data was sent and the App device 12 to which it is sent, but this is omitted in this process.
  • the AppControl object provided to each App device 12 includes access point information for accessing the DS 13.
  • the access token required to access the DS 13 is included in the AppControl object provided to each App device 12.
  • the DeviceControl object provided to DS13 includes access point information for accessing App devices 12X and 12Y.
  • the access token required to access App device 12X and the access token required to access App device 12Y are included in the DeviceControl object provided to DS13.
  • the AppControl object provided to DS13 includes access point information for accessing devices 11A, 11B, and 11C. For example, a total of three access tokens required for accessing devices 11A, 11B, and 11C are included in the AppControl object provided to DS13.
  • the DeviceControl object provided to devices 11A, 11B, and 11C includes access point information for accessing DS13.
  • the access token required to access DS13 is included in the DeviceControl object provided to devices 11A, 11B, and 11C.
  • DS13 since DS13 is not notified of the appropriate association (correspondence) between App device 12 and device 11, DS13 does not know that data sent from device 11C must not be sent to App device 12X. Similarly, DS13 does not know that data sent from device 11B must not be sent to App device 12Y.
  • the current NICE Version 1.1 standard also has a similar problem. That is, the management server 10 manages the devices 11 and App devices 12 by linking them to a user account, but does not have information that links the devices 11 and App devices 12 individually. Therefore, when multiple devices 11 or multiple App devices 12 are linked to one user account, it is not possible to specify the devices 11 that can be used for each App device 12.
  • the following describes a system that extends the NICE Version 1.0.1 (with DS) and Version 1.1 standards to properly distribute and transmit data when the DS 13 functions as a subcontractor for two or more App devices 12.
  • FIG. 8 is a block diagram illustrating a configuration example of a data processing system according to the first embodiment of the present disclosure.
  • the data processing system 51 shown in FIG. 8 includes a management server 60, three devices 61, devices 61A to 61C, two App devices 62, App devices 62X and 62Y, a DS 63, and a DPC 64.
  • Each of the management server 60, the devices 61, the App devices 62, the DS 63, and the DPC 64 constitutes an entity of the data processing system 51.
  • the management server 60, device 61, App device 62, DS 63, and DPC 64 of the data processing system 51 correspond to the management server 10, device 11, App device 12, DS 13, and DPC 14 of the data processing system 1 described above, respectively, and have the same configurations and functions except for the points described below.
  • each entity of the data processing system 51 operates in accordance with the current NICE Version 1.0.1 (with DS) and Version 1.1 standards, except for the fact that it has the functions to solve the problems described with reference to Figures 5 to 8.
  • the management server 60 manages the devices 61 and App devices 62 by linking them to user accounts.
  • the management server 60 has a function to send AppControl objects to each App device 62, a function to send AppControl objects and DeviceControl objects to the DS 63, and a function to send DeviceControl objects to each device 61.
  • NICE Version 1.0.1 the SceneMode object as operation instruction information is provided by a higher-level entity
  • NICE Version 1.1 the SceneMode object is provided by DPC 64. Note that if data processing system 51 operates in accordance with NICE Version 1.0.1, DPC 64 can be omitted.
  • the data processing system 51 can selectively execute either the first access control method or the second access control method described below, thereby appropriately allocating data from the device 61 to at least one of the App devices 62X and 62Y, thereby solving the problems described with reference to Figures 5 to 8.
  • NICE Version 1.0.1 An overview of the first access control method executed by the data processing system 51 in the case of NICE Version 1.0.1 will be described with reference to Fig. 9. In Fig. 9, changes from the existing NICE Version 1.0.1 will be described.
  • the management server 60 transmits to the App device 62 access information (AppControl object) for the device 61 and the App device 62 linked to the App device 62.
  • the management server 60 transmits to the App device 62 access information for connecting the DS 63 to the device 61 linked to the App device 62.
  • This access information corresponds to, for example, an AppControl object in NICE Version 1.0.1, and can be used by modifying an existing AppControl object.
  • the App device 62 transmits to the DS 63 access information (AppControl object) obtained from the management server 60 for the DS 63 to connect to the device 61 linked to the App device 62.
  • the access information of devices 61 that are not in use, such as devices 61 that are paused, may be omitted.
  • This access information corresponds to, for example, an AppControl object in NICE Version 1.0.1, and can be used by modifying an existing AppControl object.
  • the App device 62 also sends a SceneMode object, which is operation instruction information, to the DS 63 to instruct the operation. This process is the same as that of NICE Version 1.0.1 described above.
  • the first access control method employs a method in which the App device 62 acquires access information for the device 61 and the App device 62 linked to itself from the management server 60, and transmits access information from the App device 62 to the DS 63 for connecting to the device 61 linked to itself.
  • This allows the DS 63 to recognize that the device 61 to which the App device 62 has provided access information is the device 61 linked to that App device 62, and can recognize the correspondence between the App device 62 and the device 61.
  • the management server 60 transmits control information to each entity, i.e., devices 61A to 61C, App devices 62X and 62Y, and DS 63, in response to a request from each entity.
  • a DeviceControl object is provided to devices 61A to 61C
  • an AppControl object is provided to App devices 62X and 62Y.
  • An AppControl object and a DeviceControl object are provided to DS 63.
  • the AppControl object provided to App devices 62X and 62Y includes not only information for App device 62 to communicate with DS 63, but also information for DS 63 to communicate with device 61, which is a subcontractor of App device 62.
  • FIG. 11 shows an example of an AppControl object supplied as control information from the management server 60 to the App device 62X in step S51.
  • the AppControl object provided from the management server 60 to the App device 62X in step S51 includes device specific information 81, control I/F information 82A to 82C, and data I/F information 83A to 83C.
  • the device identification information 81 is information that identifies the App device 62X itself or the data pipeline of the App device 62X.
  • the device identification information 81 specifies that the version information "Version" is "1.0”
  • the identification information (device identification information) "AppID” of the App device 62X is "Application1ID”
  • the identification information (instance identification information) "AppInstanceID” of the instance running on the App device 62 is “AppInst1ID”
  • the identification information (data pipeline identification information) "DataPipelineID” of the data pipeline is "AppInst1DataPipelineID”.
  • the data pipeline identification information is information for identifying each data pipeline when a single App device 62 uses multiple data pipelines. When a single App device 62 uses one data pipeline, the data pipeline can be identified by the instance identification information, so the data pipeline identification information can be omitted.
  • the control I/F information 82A is information that enables the App device 62X to communicate with the Control I/F of the DS 63.
  • the control I/F information 82A includes "APIVersion”, which is API version information, "EndPointID”, which is information that identifies the communication partner (partner device identification information), "X.509Certificate”, which is the X.509 certificate (public key), and "AccessToken”, which is the access token.
  • the control I/F information 82B is information that enables the App device 62X to communicate with the Control I/F of the device 61A.
  • "APIVersion” is "1.0”
  • "EndPointID” is “Device0ID”
  • "X.509Certificate” is “Device0PublicKey”
  • "AccessToken” is "Device0ControlAccessToken4AppInst1”.
  • This access token "Device0ControlAccessToken4AppInst1" is an access token for the App device 62X, so DS63 cannot use it.
  • the control I/F information 82C is information that enables the App device 62X to communicate with the control I/F of the device 61B.
  • "APIVersion” is "1.0”
  • "EndPointID” is “Device1ID”
  • "X.509Certificate” is “Device1PublicKey”
  • "AccessToken” is "Device1ControlAccessToken4AppInst1”.
  • This access token "Device1ControlAccessToken4AppInst1” is an access token for the App device 62X, so DS63 cannot use it.
  • the data I/F information 83A is information for the App device 62X to communicate with the Data I/F of the DS 63.
  • the data I/F information 83A includes "APIVersion”, which is API version information, "EndPointID”, which is information identifying the communication partner (partner device identification information), "X.509Certificate”, which is the X.509 certificate (public key), and "AccessToken”, which is the access token.
  • the data I/F information 83B is information that enables the App device 62X to communicate with the Data I/F of the device 61A.
  • “APIVersion” is "1.0”
  • “EndPointID” is “Device0ID”
  • "X.509Certificate” is “Device0InstPublicKey”
  • "AccessToken” is "Device0DataAccessToken4AppInst1”.
  • This access token "Device0DataAccessToken4AppInst1" is an access token for the App device 62X, and therefore cannot be used by the DS 63.
  • the data I/F information 83C is information that enables the App device 62X to communicate with the Data I/F of the device 61B.
  • “APIVersion” is "1.0”
  • “EndPointID” is “Device1ID”
  • "X.509Certificate” is “Device1InstPublicKey”
  • "AccessToken” is "Device1ControlAccessToken4AppInst1”.
  • This access token "Device1DataAccessToken4AppInst1” is an access token for the App device 62X, and therefore cannot be used by the DS 63.
  • the AppControl object provided from the management server 60 to the App device 62X also includes information for connecting to the devices 61A and 61B linked to the App device 62X based on the linking information between the App device 62 and device 61 managed by the management server 60, as in the example of FIG. 11.
  • App device 62X requests management server 60 to issue access information for device 61 for which it wishes to transfer authority to DS 63.
  • App device 62X is linked to devices 61A and 61B, and requests DS 63 to communicate with devices 61A and 61B, so it requests management server 60 to issue access information for DS 63 for devices 61A and 61B.
  • App device 62Y requests management server 60 to issue access information for devices 61A and 61C for which it wishes to transfer authority to DS 63 in step S52.
  • the request to issue access information in step S52 is not specified in NICE Version 1.0.1, so it is necessary to add a new command (access information issuance request command), for example, by calling GetAppControl with the request information.
  • FIG. 12 shows an example of the GetAppControl access information issuance request command in step S52, in which the App device 62X requests the management server 60 to issue access information for DS.
  • GetAppControl includes, for example, as shown in FIG. 12, version information "Version”, request source information "Requester”, data pipeline identification information “DataPipelineID”, authority transfer destination information "Delegate”, and access information request target information "TargetEntities”.
  • the version information "Version” is "1.0”
  • the request source information "Requester” is the instance identification information “AppInst1ID” of the App device 62X
  • the data pipeline identification information "DataPipelineID” is “AppInst1DataPipelineID”
  • the authority transfer destination information "Delegate” is the instance identification information "DSInstID” of DS63
  • the access information request target information "TargetEntities” is the identification information "Device0ID” and "Device1ID” of devices 61A and 61B. If the data pipeline can be identified without the data pipeline identification information "DataPipelineID”, the data pipeline identification information may be omitted.
  • the management server 60 refers to the linking information managed by itself, and confirms that the DS 63 to which authority is to be transferred and the device 61 for which the access information is requested, which are described in the access information issuance request command from the App device 62, are linked to the App device 62 that originated the request.
  • the management server 60 transmits to the App device 62 that originated the request the access information to be used between the DS 63 and the device 61. More specifically, the management server 60 transmits to the App device 62X the access information that the DS 63 uses to communicate with the devices 61A and 61B, and transmits to the App device 62Y the access information that the DS 63 uses to communicate with the devices 61A and 61C. If the App device 62 requests access information for the DS 63 and device 61 that are not linked to the App device 62 that originated the request, the request to issue the access information is rejected.
  • step S54 the App device 62 transmits to the DS63 the access information for the DS63 acquired in response to the access information issuance request command, in response to a request from the DS63. More specifically, the App device 62X transmits to the DS63 the access information that the DS63 uses in communicating with the devices 61A and 61B, and the App device 62Y transmits to the DS63 the access information that the DS63 uses in communicating with the devices 61A and 61C.
  • FIG 13 shows an example of access information sent from App device 62X to DS 63.
  • This access information can be provided, for example, by an AppControl object.
  • This AppControl object was created by modifying the AppControl object in NICE Version 1.0.1.
  • the App device 62X selects a device 61 based on the access information acquired from the management server 60 according to the data pipeline, stores it in an AppControl object, and transmits it to the DS 63.
  • the AppControl object provided from the App device 62X to the DS 63 includes device specific information 91, control I/F information 92A and 92B, and data I/F information 93A and 93B.
  • the device identification information 91 is information that identifies the DS63 itself or the data pipeline of the DS63.
  • the device identification information 91 includes, for example, "1.0” as the version information "Version”, "DSID” that is the identification information of the DS63 as the device identification information "AppID”, and "DSInstID” that is the identification information of the instance running on the DS63 as the instance identification information "AppInstanceID”.
  • data pipeline identification information data pipeline identification information
  • the data pipeline identification information is also included.
  • the control I/F information 92A is information that enables the DS 63 to communicate with the control I/F of the device 61A.
  • the control I/F information 92A includes "APIVersion”, which is API version information, "EndPointID”, which is information that identifies the communication partner (partner device identification information), "X.509Certificate”, which is the X.509 certificate (public key), and "AccessToken”, which is the access token.
  • “APIVersion” is "1.0”
  • “EndPointID” is "Device0ID”
  • X.509Certificate is "Device0PublicKey”
  • AccessToken is "Device0ControlAccessToken4DSInst”.
  • Control I/F information 92B is information that enables DS63 to communicate with the control I/F of device 61B.
  • "APIVersion” is "1.0”
  • "EndPointID” is “Device1ID”
  • "X.509Certificate” is “Device1PublicKey”
  • "AccessToken” is "Device1ControlAccessToken4AppInst”.
  • Data I/F information 93A is information that enables DS 63 to communicate with the Data I/F of device 61A.
  • Data I/F information 93A includes "APIVersion”, which is API version information, "EndPointID”, which is information that identifies the communication partner (partner device identification information), "X.509Certificate”, which is the X.509 certificate (public key), and "AccessToken”, which is the access token.
  • Data I/F information 93B is information that enables DS63 to communicate with the Data I/F of device 61B.
  • “APIVersion” is "1.0”
  • “EndPointID” is “Device1ID”
  • "X.509Certificate” is “Device1InstPublicKey”
  • “AccessToken” is "Device1DataAccessToken4AppInst”.
  • DS 63 can recognize that App device 62X is linked to devices 61A and 61B. In other words, this access information corresponds to linking information between device 61 and App device 62.
  • FIG 14 shows an example of access information sent from App device 62Y to DS 63.
  • This access information can be provided by an AppControl object.
  • This AppControl object was created by modifying the AppControl object in NICE Version 1.0.1.
  • the App device 62Y selects a device 61 according to the access information obtained from the management server 60 in the data pipeline, stores it in an AppControl object, and transmits it to the DS 63.
  • the AppControl object provided from the App device 62Y to the DS 63 includes device specific information 101, control I/F information 102A and 102B, and data I/F information 103A and 103B.
  • the device identification information 101 is information that identifies the DS63 itself or the data pipeline of the DS63.
  • the device identification information 101 includes, for example, "1.0” as the version information "Version”, "DSID” that is the identification information of the DS63 as the device identification information "AppID”, and "DSInstID” that is the identification information of the instance running on the DS63 as the instance identification information "AppInstanceID”.
  • data pipeline identification information data pipeline identification information
  • the data pipeline identification information is also included.
  • the control I/F information 102A is information that enables the DS 63 to communicate with the control I/F of the device 61A.
  • the control I/F information 102A includes "APIVersion”, which is API version information, "EndPointID”, which is information that identifies the communication partner (partner device identification information), "X.509Certificate”, which is the X.509 certificate (public key), and "AccessToken”, which is the access token.
  • “APIVersion” is "1.0”
  • “EndPointID” is "Device0ID”
  • X.509Certificate is "Device0PublicKey”
  • AccessToken is "Device0ControlAccessToken4DSInst”.
  • Control I/F information 102B is information that enables DS 63 to communicate with the control I/F of device 61C.
  • "APIVersion” is "1.0”
  • "EndPointID” is “Device2ID”
  • "X.509Certificate” is “Device2PublicKey”
  • "AccessToken” is "Device2ControlAccessToken4AppInst”.
  • Data I/F information 103A is information that enables DS 63 to communicate with the Data I/F of device 61A.
  • Data I/F information 93A includes "APIVersion”, which is API version information, "EndPointID”, which is information that identifies the communication partner (partner device identification information), "X.509Certificate”, which is the X.509 certificate (public key), and "AccessToken”, which is the access token.
  • “APIVersion” is "1.0”
  • “EndPointID” is "Device0ID”
  • X.509Certificate is “Device0InstPublicKey”
  • AccessToken is "Device0DataAccessToken4DSInst”.
  • Data I/F information 103B is information that enables DS63 to communicate with the Data I/F of device 61C.
  • “APIVersion” is "1.0”
  • “EndPointID” is “Device2ID”
  • "X.509Certificate” is “Device2InstPublicKey”
  • “AccessToken” is "Device2DataAccessToken4DSInst”.
  • DS 63 can recognize that App device 62Y is linked to devices 61A and 61C.
  • step S54 The provision of access information in step S54 described above is performed, for example, by DS 63 calling GetAppControl for each App device 62 listed in the DeviceControl object supplied from management server 60 in step S51.
  • DS 63 needs information to communicate with the Management I/F of each App device 62, so the DeviceControl object supplied to DS 63 from management server 60 needs to contain information to communicate with the Management I/F of each App device 62.
  • Figure 15 shows an example of a DeviceControl object supplied from the management server 60 to the DS 63, which contains information for communicating with the management I/F of each App device 62.
  • the DeviceControl object provided from management server 60 to DS 63 includes device specific information 111, management I/F information 112A and 112B, and control I/F information 113A and 113B.
  • the device identification information 111 is information that identifies the DS63 itself.
  • the device identification information 111 includes, for example, "1.0” as the version information "Version”, "DSInstID” that is the identification information of the DS63 as the device identification information "DeviceID”, “Token1", “Token2”, ... as information on invalid access tokens (invalid token information) for establishing a communication path by TLS “RevokedJSONTokenIDs”, and "Cert1", “Cert2”, ... as information on TLS root certificates (TLS root certificate information) for establishing a communication path by TLS "AllowedTLSRootCertificates".
  • the "ManagementEndPoints" contains information for DS63 to communicate with the management I/F of the communication partner, and in the example of Figure 15, contains management I/F information 112A and 112B.
  • the management I/F information 112A is information that enables the DS 63 to communicate with the management I/F of the App device 62X.
  • the management I/F information 112A includes "APIVersion”, which is API version information, "EndPointID”, which is information that identifies the communication partner (partner device identification information), "X.509Certificate”, which is the X.509 certificate (public key), and "AccessToken”, which is the access token.
  • “APIVersion” is "1.0”
  • “EndPointID” is "AppInst1ID
  • X.509Certificate is "AppInst1PublicKey”
  • AccessToken is "AppInst1ManagementAccessToken”.
  • the management I/F information 112B is information that enables the DS 63 to communicate with the management I/F of the App device 62Y.
  • "APIVersion” is "1.0”
  • "EndPointID” is “AppInst2ID”
  • "X.509Certificate” is “AppInst2PublicKey”
  • "AccessToken” is "AppInst2ManagementAccessToken”.
  • ControlEndPoints contains information for DS63 to communicate with the control I/F of the communication partner, and in the example of Figure 15, contains control I/F information 113A and 113B.
  • the control I/F information 113A is information that enables the DS 63 to communicate with the control I/F of the App device 62X.
  • the control I/F information 113A includes "APIVersion”, which is API version information, "EndPointID”, which is information that identifies the communication partner (partner device identification information), "X.509Certificate”, which is the X.509 certificate (public key), and "AccessToken”, which is the access token.
  • the control I/F information 113B is information that enables the DS 63 to communicate with the control I/F of the App device 62Y.
  • "APIVersion” is "1.0”
  • "EndPointID” is “AppInst2ID”
  • "X.509Certificate” is “AppInst2PublicKey”
  • "AccessToken” is "AppInst2ControlAccessToken”.
  • the DeviceControl object shown in Figure 15 is configured by adding information for communicating with the Management I/F of each App device 62 to the DeviceControl object defined in NICE Version 1.0.1, but since the information for communicating with the Management I/F and the information for communicating with the Control I/F can be standardized, it is also possible to write them in a shared format.
  • Figure 16 shows an example of a DeviceControl object that shares information for communicating with the Management I/F and information for communicating with the Control I/F.
  • the DeviceControl object provided from the management server 60 to the DS 63 includes device specific information 121 and management control common I/F information 122A and 122B.
  • the device specific information 121 is similar to the device specific information 111 in FIG. 15, so a detailed explanation is omitted.
  • the management and control common I/F information 122A is information that enables the DS 63 to communicate with the management I/F and control I/F of the application device 62X.
  • the management and control common I/F information 122B is information that enables the DS 63 to communicate with the management I/F and control I/F of the application device 62Y. Each item is the same as in FIG. 14, so a description is omitted.
  • the management server 60 sends a DeviceControl object to each device 61, thereby sending access information to each device 11 for each device 61 to communicate with the DS 63.
  • the DeviceControl object can be sent in response to a request from each device 61, or can be sent without a request.
  • FIG. 17 shows an example of a DeviceControl object provided from management server 60 to device 61A.
  • the DeviceControl object provided from the management server 60 to the device 61A includes device specific information 131 and control I/F information 132.
  • the device identification information 131 is information that identifies the device 61A itself.
  • the device identification information 131 includes, for example, "1.0” as version information “Version”, "Device0ID” that is the identification information of the device 61A as device identification information "DeviceID”, “Token1”, “Token2”, ... as information on invalid access tokens (invalid token information) for establishing a communication path using TLS “RevokedJSONTokenIDs”, and "Cert1", “Cert2”, ... as information on TLS root certificates (TLS root certificate information) for establishing a communication path using TLS "AllowedTLSRootCertificates".
  • the control I/F information 132 is information that enables device 61A to communicate with the control I/F of DS 63.
  • the control I/F information 132 includes "APIVersion”, which is API version information, "EndPointID”, which is information that identifies the communication partner (partner device identification information), "X.509Certificate”, which is the X.509 certificate (public key), and "AccessToken”, which is the access token.
  • “APIVersion” is "1.0”
  • “EndPointID” is "DSInstID”
  • X.509Certificate is "DSInstPublicKey”
  • AccessToken is "DSInstControlAccessToken4Device0”.
  • each App device 62 sends a SceneMode object that sets a scene mode as operation instruction information to the DS 63, and instructs the operation.
  • the DS 63 calls GetAppControl for each App device 62 listed in the DeviceControl object acquired in step S51, and each App device 62 sends a SceneMode object as operation instruction information to the DS 63.
  • the DS 63 can recognize the correspondence between the device 61, the App device 62, and SceneMode.
  • step S57 based on the access information and operation instruction information supplied from each App device 62, the DS 63 transmits a SceneMode object that sets a scene mode as operation instruction information to each device 61, and instructs the device to operate. More specifically, device 61A is instructed to operate in accordance with the device 61A-App device 62X-SceneMode correspondence and the device 61A-App device 62Y-SceneMode correspondence. Device 61B is instructed to operate in accordance with the device 61B-App device 62X-SceneMode correspondence, and device 61C is instructed to operate in accordance with the device 61C-App device 62Y-SceneMode correspondence.
  • each device 61 executes an operation based on the SceneMode object, such as human detection or moving object detection, and transmits the detection result data using SetSceneData or SetSceneMark.
  • step S59 the DS 63 acquires the data sent from each device 61 and determines the App device 62 to which the data is to be sent, and in step S60, transmits the data to the determined App device 62 using SetSceneData or SetSceneMark.
  • step S59 DS63 transmits data from device 61B to App device 62X, and transmits data from device 61C to App device 62X, but needs to determine whether data from device 61A should be transmitted to App device 62X or to App device 62Y.
  • SetSceneData and SetSceneMark which are objects that transmit data, are configured to include operation instruction identification information that indicates which operation instruction (SceneMode object) the data was detected based on.
  • FIG. 18 shows an example of a configuration in which action instruction identification information is included in a SceneMark object of SetSceneMark.
  • a SceneMark object includes "SceneModeIDs", which is operation instruction identification information 151 that identifies the operation instruction (SceneMode object) that was the source of generating this data.
  • “SceneModeID1” and “SceneModeID2” are scene mode identification information that identify the SceneMode object.
  • FIG. 19 shows an example of a configuration in which action instruction identification information is included in a DataSection object of SetSceneData.
  • a DataSection object includes "SceneModeIDs," which is operation instruction identification information 152 that identifies the operation instruction (SceneMode object) that was the source of generating this data.
  • SceneModeIDs which is the operation instruction identification information 152, is expressed in an array format such as ["SceneModeID1", “SceneModeID2”, ...], and multiple operation instructions can be listed. If only one operation instruction needs to be specified, a single format instead of an array format may be used.
  • Operation instruction identification information can be included not only for SceneData objects and SceneMark objects, but also for their related objects, SceneDataManifest objects and SceneMarkManifest objects.
  • a SceneDataManifest is a data object that includes a reference and a URI to a file that includes SceneData
  • a SceneMarkManifest is a data object that includes a reference and a URI to a SceneMark.
  • DS63 determines the destination of the data based on the operation instruction identification information included in the SceneData object or SceneMark object as operation instruction information, and transmits the data to the App device 62 determined as the destination.
  • the first access control method by the data processing system 51 in the case of NICE Version 1.0.1 is carried out as described above.
  • a DPC Data Pipeline Controller 64 is newly added to the data processing system 51.
  • the management server 10 manages the device 11 and the App device 12 by linking them to a user account, but does not have information that directly links the device 11 and the App device 12. Therefore, the management server 60 that executes the first access control method manages the device 61 and the App device 62 by linking them to a user account, and also manages the device 61 and the App device 62 by linking them to each other. In other words, the management server 60 manages the correspondence between the device 61 and the App device 62 in the same way as in NICE Version 1.0.1.
  • the management server 60 transmits to the App device 62 access information (AppControl object) for the device 61 and the App device 62 linked to the App device 62.
  • the management server 60 transmits to the App device 62 access information for connecting the DS 63 to the device 61 linked to the App device 62.
  • the provision of access information from the management server 60 to the App device 62 is the same as in the case of NICE Version 1.0.1 described above.
  • the App device 62 transmits to the DS 63 the access information (AppControl object) for connecting to the device 61 linked to itself, obtained from the management server 60.
  • the access information for devices 61 that are not in use, such as devices 61 that are paused, may be omitted.
  • the provision of the access information from the App device 62 to the device 61 is the same as in NICE Version 1.0.1 described above.
  • the SceneMode object which is operation instruction information
  • the DPC 64 sends a SceneMode object, which is operation instruction information, to the device 61 or DS 63 in response to a request from the device 61 or DS 63.
  • the DPC 64 sends a SceneMode object to the DS 63 for each App device 62.
  • the management server 60 transmits control information to each entity, i.e., devices 61A to 61C, App devices 62X and 62Y, and DS 63, in response to a request from each entity.
  • a DeviceControl object is provided to devices 61A to 61C
  • an AppControl object is provided to App devices 62X and 62Y.
  • An AppControl object and a DeviceControl object are provided to DS 63.
  • the AppControl object provided to App devices 62X and 62Y includes not only information for App device 62 to communicate with DS 63, but also information for DS 63 to communicate with device 61, which is a subcontractor of App device 62.
  • step S81 the example of the AppControl object shown in FIG. 11 can be used as the AppControl object supplied as control information from the management server 60 to the App device 62X.
  • the example of the DeviceControl object shown in FIG. 15 or 16, which includes information for communicating with the Management I/F of each App device 62, can be used as the DeviceControl object supplied to the DS 63 from the management server 60.
  • step S82 App device 62X requests management server 60 to issue access information for device 61 for which it wishes to transfer authority to DS 63.
  • App device 62X is linked to devices 61A and 61B, and requests DS 63 to communicate with devices 61A and 61B, so it requests management server 60 to issue access information for DS 63 for devices 61A and 61B.
  • step S52 App device 62Y requests management server 60 to issue access information for devices 61A and 61C for which it wishes to transfer authority to DS 63.
  • the example of GetAppControl in FIG. 12 described in the first access control process of NICE Version 1.0.1 can be applied to the request to issue access information in step S82.
  • the management server 60 refers to the linking information it manages and confirms that the DS 63 to which authority is to be transferred and the device 61 for which the access information is requested, both of which are described in the access information issuance request command from the App device 62, are linked to the App device 62 that made the request.
  • the management server 60 then transmits the access information to be used between the DS 63 and the device 61 to the App device 62 that made the request.
  • step S84 the App device 62 transmits the access information for DS63 acquired in response to the access information issuance request command to the DS63 in response to a request from the DS63.
  • An example of the access information transmitted from the App device 62X to the DS63 can be the example of the AppControl object in FIG. 13 described in the first access control process of NICE Version 1.0.1.
  • An example of the access information transmitted from the App device 62Y to the DS63 can be the example of the AppControl object in FIG. 14.
  • step S85 the management server 60 transmits a DeviceControl object in response to a request from each device 61, thereby transmitting access information to each device 61 for communicating with the DS 63.
  • a DeviceControl object supplied from the management server 60 to device 61A can be the example of the DeviceControl object in FIG. 17 described in the first access control process of NICE Version 1.0.1.
  • steps S84 and S85 which are executed after step S83, may be executed in any order, or may be executed simultaneously.
  • each device 61 requests a SceneMode object as operation instruction information from the DPC 64, and obtains the SceneMode object from the DPC 64.
  • the DPC 64 instructs the operation by sending a SceneMode object in response to the request from each device 61.
  • step S87 the DS 63 requests a SceneMode object as operation instruction information from the DPC 64, and acquires the SceneMode object from the DPC 64.
  • the DPC 64 instructs the operation by sending a SceneMode object in response to the request from the DS 63.
  • the DS 63 needs to acquire a SceneMode object for each App device 62.
  • the DS 63 calls GetSceneMode by specifying an App device 62 listed in the DeviceControl object acquired in step S81, and the DPC 64 transmits a SceneMode object corresponding to the specified App device 62 to the DS 63.
  • FIG. 22 shows an example of the command GetSceneMode that obtains a SceneMode object for each App device 62, and shows an example of GetSceneMode that requests operation instruction information for the App device 62X from the DPC 64.
  • the parameters of GetSceneMode include, for example, version information "Version”, App device identification information "AppInstID”, and operation instruction target information "TargetInstanceID”, as shown in FIG. 22.
  • the App device identification information "AppInstID” is the instance identification information "AppInst1ID” of the App device 62X
  • the operation instruction target information "TargetInstanceID” is the instance identification information "DSInstID” of the DS63
  • this is an example of requesting operation instruction information for the App device 62X from the DS63.
  • data pipeline identification information data pipeline identification information
  • the data pipeline identification information is also included.
  • the DS 63 can recognize the correspondence between the device 61, the App device 62, and the SceneMode by acquiring the control information from the management server 60 in step S81, the access information from each App device 62 in step S84, and the operation instruction information in step S87.
  • each device 61 executes an operation based on the SceneMode object, such as human detection or moving object detection, and transmits the detection result data using SetSceneData or SetSceneMark.
  • step S89 the DS 63 acquires the data sent from each device 61 and determines the App device 62 to which the data is to be sent, and in step S90, transmits the data to the determined App device 62 using SetSceneData or SetSceneMark.
  • the data object like SceneMark in Figure 18 and DataSection in Figure 19, contains operation instruction identification information indicating which operation instruction (SceneMode object) the data was detected based on.
  • the first access control method by the data processing system 51 in the case of NICE Version 1.1 is carried out as described above.
  • the first access control method employs a method in which the App device 62 acquires access information for the device 61 and the App device 62 linked to itself from the management server 60, and transmits access information from the App device 62 to the DS 63 for connecting to the device 61 linked to itself.
  • This allows the DS 63 to recognize that the device 61 to which the App device 62 has provided access information is the device 61 linked to that App device 62, and thus recognizes the correspondence between the App device 62 and the device 61.
  • the management server 60 provides each App device 62 with not only its own (App device 62) access information, but also access information for the DS 63 to connect to the device 61 linked to that device. In the first access control method, the management server 60 does not need to provide each DS 63 with access information for the DS 63 to connect to the device 61.
  • the access information for connecting the DS 63 to the device 61 linked to the App device 62 is not provided from the management server 60 to each App device 62.
  • the AppControl object sent from the management server 60 to each App device 62 is the same as in the existing NICE Version 1.0.1.
  • the management server 60 does not provide each App device 62 with access information for the device 61 used by the DS 63, the process of transmitting access information from the App device 62 to the DS 63 for connecting the DS 63 to the device 61 linked to the App device 62 is not executed.
  • the second access control method differs from the first access control method described above in that each App device 62 provides the DS 63 with a device list (DeviceList object) that is a list of devices 61 linked to itself. Note that this device list is different from the DeviceList object supplied from the management server 60 to each App device 62 in the existing NICE Version 1.0.1.
  • the device list provided from the App device 62 to the DS 63 is a device list that lists the devices 61 linked to itself (App device 62) that the App device 62 wants DS 63 to execute processing on.
  • DS63 refers to the device list (DeviceList object) provided by each App device 62, and requests access information to connect to that device 61 from the management server 60.
  • the management server 60 transmits to DS63 access information for DS63 to connect to device 61.
  • This access information corresponds to, for example, an AppControl object in NICE Version 1.0.1, and can be used by modifying an existing AppControl object.
  • the DS 63 obtains access information for connecting to the device 61 linked to the App device 62 via the App device 62.
  • the DS 63 obtains access information for connecting to the device 61 linked to the App device 62 directly from the management server 60.
  • the DS 63 can recognize the device 61 linked to the App device 62 by obtaining a device list (DeviceList object) from the App device 62, recognizes the correspondence between the App device 62 and the device 61, and obtains access information for connecting to the device 61 directly from the management server 60. This access information corresponds to the linking information between the device 61 and the App device 62.
  • the management server 60 transmits control information to each entity, i.e., devices 61A to 61C, App devices 62X and 62Y, and DS 63, in response to a request from each entity.
  • a DeviceControl object is provided to devices 61A to 61C
  • an AppControl object is provided to App devices 62X and 62Y.
  • An AppControl object and a DeviceControl object are provided to DS 63.
  • the AppControl object provided to App devices 62X and 62Y includes not only information for App device 62 to communicate with DS 63, but also information for DS 63 to communicate with device 61, which is a subcontractor of App device 62.
  • step S121 the example of the AppControl object shown in FIG. 11 can be used as the AppControl object supplied as control information from the management server 60 to the App device 62X.
  • the example of the DeviceControl object shown in FIG. 15 or 16, which includes information for communicating with the Management I/F of each App device 62, can be used as the DeviceControl object supplied to the DS 63 from the management server 60.
  • step S122 the App device 62X sends to the DS 63 a device list (DeviceList object) which is a list of devices 61 for which authority is to be transferred to the DS 63.
  • the App device 62Y sends to the DS 63 a device list (DeviceList object) which is a list of devices 61 for which authority is to be transferred to the DS 63.
  • the device list from the App device 62X lists the devices 61A and 61B, and the device list from the App device 62Y lists the devices 61A and 61C.
  • a DeviceList object is sent from each App device 62 to the DS 63.
  • Figure 25 shows an example of a DeviceList object sent from App device 62X to DS 63.
  • the DeviceList object includes, for example, version information "Version”, user account identification information "AccountID”, and device list information "DeviceList”, as shown in FIG. 25.
  • the device list information "DeviceList” lists the device identification information "DeviceID” and "Status” information indicating the connection status with the device 61 for the device 61 to which authority is to be transferred.
  • the user account identification information "AccountID” is "AppInstOwner'sAccountID” corresponding to the user account of the App device 62X.
  • the device list information "DeviceList” stores the device identification information "Device0ID” corresponding to the device 61A and the connection status "Status” of "Connected", and the device identification information "Device1ID” corresponding to the device 61B and the connection status "Status” of "Connected”. Although omitted in this example, if data pipeline identification information (data pipeline identification information) is required, the data pipeline identification information is also included.
  • step S123 the DS 63 requests the management server 60 to issue access information for the device 61, which is the target of the authority transfer and is listed in the device list.
  • step S124 the management server 60 refers to the linking information it manages, and confirms that the DS 63 to which authority is to be transferred and the device 61 to which the access information is requested, which are described in the access information issuance request command from the DS 63, are linked to the App device 62 from which authority is to be transferred.
  • the management server 60 then transmits access information to be used between the DS 63 that made the request and the device 61 to which it is to be accessed.
  • the access information acquired here can be the same as the AppControl object in FIG. 12 and FIG. 13.
  • step S125 the management server 60 transmits a DeviceControl object to each device 61, thereby transmitting access information to each device 61 for each device 61 to communicate with the DS 63.
  • a DeviceControl object supplied from the management server 60 to device 61A may be the same as the DeviceControl object in FIG. 17 described in the first access control process of NICE Version 1.0.1.
  • each App device 62 sends a SceneMode object to the DS 63 as operation instruction information to instruct the DS 63 to operate.
  • the DS 63 calls GetAppControl for each App device 62 listed in the DeviceControl object acquired in step S121, and each App device 62 sends a SceneMode object to the DS 63.
  • the DS 63 can recognize the correspondence between the device 61, the App device 62, and SceneMode.
  • the DS 63 transmits a SceneMode object as operation instruction information to each device 61 based on the access information and operation instruction information supplied from each App device 62, and instructs the device 61 to operate. More specifically, the device 61A is instructed to operate in accordance with the device 61A-App device 62X-SceneMode correspondence and the device 61A-App device 62Y-SceneMode correspondence. The device 61B is instructed to operate in accordance with the device 61B-App device 62X-SceneMode correspondence, and the device 61C is instructed to operate in accordance with the device 61C-App device 62Y-SceneMode correspondence.
  • each device 61 executes an operation based on the SceneMode object, such as human detection or moving object detection, and transmits the detection result data using SetSceneData or SetSceneMark.
  • step S129 the DS 63 acquires the data sent from each device 61 and determines the App device 62 to which the data is to be sent, and in step S130, transmits the data to the determined App device 62 using SetSceneData or SetSceneMark.
  • the object that transmits the data such as SceneMark in FIG. 18 and DataSection in FIG. 19, contains operation instruction identification information that indicates which operation instruction (SceneMode object) the data was detected based on.
  • the second access control method by the data processing system 51 in the case of NICE Version 1.0.1 is performed as described above.
  • the management server 10 manages the device 11 and the App device 12 by linking them to a user account, but does not have information that directly links the device 11 and the App device 12. Therefore, the management server 60 that executes the second access control method manages the device 61 and the App device 62 by linking them to a user account, and also manages the device 61 and the App device 62 by linking them to each other. In other words, the management server 60 manages the correspondence between the device 61 and the App device 62 in the same way as in NICE Version 1.0.1.
  • the AppControl object and DeviceControl object provided from the management server 60 to each device 61 and each App device 62 are the same as those in the existing NICE Version 1.0.1.
  • the second access control method differs from the first access control method described above in that each App device 62 provides the DS 63 with a device list (DeviceList object) that is a list of devices 61 linked to the App device 62.
  • This device list is different from the DeviceList object supplied from the management server 60 to each App device 62 in the existing NICE Version 1.0.1.
  • DS63 refers to the device list (DeviceList object) provided by each App device 62, and requests access information to connect to that device 61 from the management server 60.
  • the management server 60 transmits to DS63 access information for DS63 to connect to device 61.
  • This access information corresponds to, for example, an AppControl object in NICE Version 1.0.1, and can be used by modifying an existing AppControl object.
  • the DPC 64 In response to a request from the device 61 or DS 63, the DPC 64 sends a SceneMode object, which is operation instruction information, to the device 61 or DS 63. At this time, the DPC 64 sends a SceneMode object to the DS 63 for each App device 62.
  • the management server 60 transmits control information to each entity, i.e., devices 61A to 61C, App devices 62X and 62Y, and DS 63, in response to a request from each entity.
  • a DeviceControl object is provided to devices 61A to 61C
  • an AppControl object is provided to App devices 62X and 62Y.
  • An AppControl object and a DeviceControl object are provided to DS 63.
  • the AppControl object provided to App devices 62X and 62Y includes not only information for App device 62 to communicate with DS 63, but also information for DS 63 to communicate with device 61, which is a subcontractor of App device 62.
  • step S141 the example of the AppControl object shown in FIG. 11 can be used as the AppControl object supplied as control information from the management server 60 to the App device 62X.
  • the example of the DeviceControl object shown in FIG. 15 or 16, which includes information for communicating with the Management I/F of each App device 62, can be used as the DeviceControl object supplied to the DS 63 from the management server 60.
  • step S142 the App device 62X sends to the DS 63 a device list (DeviceList object) which is a list of devices 61 for which authority is to be transferred to the DS 63.
  • the App device 62Y sends to the DS 63 a device list (DeviceList object) which is a list of devices 61 for which authority is to be transferred to the DS 63.
  • the device list from the App device 62X lists devices 61A and 61B, and the device list from the App device 62Y lists devices 61A and 61C.
  • the example of the DeviceList object shown in FIG. 25 can be used as the device list provided to the DS 63.
  • step S143 the DS 63 requests the management server 60 to issue access information for the device 61, which is the target of authority transfer and is listed in the device list.
  • the example of GetAppControl in Figure 12 described in the first access control process of NICE Version 1.0.1 can be applied to the request to issue access information in step S143.
  • step S144 the management server 60 refers to the linking information it manages, and confirms that the DS 63 to which authority is to be transferred and the device 61 to which the access information is requested, which are described in the access information issuance request command from the DS 63, are linked to the App device 62 from which authority is to be transferred.
  • the management server 60 then transmits the access information to be used between the DS 63 that made the request and the device 61 to which it is to be accessed.
  • step S145 the management server 60 transmits a DeviceControl object in response to a request from each device 61, thereby transmitting access information to each device 61 for each device 61 to communicate with the DS 63.
  • An example of the DeviceControl object supplied from the management server 60 to device 61A can be the example of the DeviceControl object in FIG. 17.
  • each device 61 requests a SceneMode object as operation instruction information from the DPC 64, and obtains the SceneMode object from the DPC 64.
  • the DPC 64 instructs the operation by sending a SceneMode object in response to the request from each device 61.
  • step S147 the DS 63 requests the DPC 64 to send a SceneMode object as operation instruction information, and acquires the SceneMode object from the DPC 64.
  • the DPC 64 instructs the operation by sending a SceneMode object in response to the request from the DS 63.
  • the DS 63 sends a SceneMode object for each App device 62.
  • the DS 63 acquires a SceneMode object for each App device 62 by sending a GetSceneMode specifying the App device 62 shown in FIG. 22 to the DPC 64.
  • the DS 63 can recognize the correspondence between the device 61, the App device 62, and the SceneMode by acquiring the control information from the management server 60 in step S141, the access information from each App device 62 in step S144, and the operation instruction information in step S147.
  • each device 61 executes an operation based on the SceneMode object, such as human detection or moving object detection, and transmits the detection result data using SetSceneData or SetSceneMark.
  • step S149 the DS 63 acquires the data transmitted from each device 61 and determines the App device 62 to which the data is to be sent, and in step S150 transmits the data to the determined App device 62 using SceneData or SceneMark.
  • the object transmitting the data such as SceneMark in FIG. 18 and DataSection in FIG. 19, contains operation instruction identification information indicating which operation instruction (SceneMode object) the data was detected based on.
  • the second access control method by the data processing system 51 in the case of NICE Version 1.1 is carried out as described above.
  • the DS 63 directly obtains from the management server 60 access information for the DS 63 to connect to the device 61 linked to the App device 62.
  • the DS 63 can recognize the device 61 linked to the App device 62 by obtaining a device list (DeviceList object) from the App device 62, recognizes the correspondence between the App device 62 and the device 61, and directly obtains from the management server 60 access information for the DS 63 to connect to the device 61.
  • a device list (DeviceList object)
  • FIG. 28 is a diagram for explaining a case where two DSs 63A and 63B are interposed between a device 61 and an App device 62 in the case of NICE Version 1.0.1, and control is performed by the first access control method described above.
  • the App device 62 acquires access information (AppControl object) of the device 61 and the App device 62 linked to itself from the management server 60, and transmits access information for the DS 63 to connect to the device 61 linked to itself from the App device 62 to the DS 63.
  • the App device 62 transmits a SceneMode object, which is operation instruction information, to the DS 63 to instruct the operation.
  • access information and operation instruction information of device 61 linked to App device 62 are provided to DS63A from App device 62X or 62Y by the AppControl object and SceneMode object.
  • access information and operation instruction information of device 61 linked to App device 62 are provided to DS63B from DS63A by the AppControl object and SceneMode object.
  • DS63B needs to be able to distinguish between data for App device 62X and data for App device 62Y from the data acquired from each device 61 and transmit the data to DS63A. Also, DS63A needs to be able to distinguish between data for App device 62X and data for App device 62Y from the data acquired from DS63B and transmit the data to App device 62X or App device 62Y.
  • FIG. 29 is a diagram for explaining a case where two DSs 63A and 63B are interposed between a device 61 and an App device 62 in the case of NICE Version 1.1, and control is performed by the first access control method described above.
  • the App device 62 acquires access information (AppControl object) of the device 61 and the App device 62 linked to itself from the management server 60, and transmits access information for the DS 63 to connect to the device 61 linked to itself from the App device 62 to the DS 63.
  • the SceneMode object which is operation instruction information, is supplied from the DPC 64 to the DS 63.
  • access information of device 61 linked to App device 62 is supplied to DS 63A from App device 62X or 62Y by the AppControl object.
  • access information of device 61 linked to App device 62 is supplied to DS 63B from DS 63A by the AppControl object.
  • operation instruction information is supplied to DS 63A from DPC 64 by the SceneMode object.
  • operation instruction information is supplied to DS 63B from DPC 64 by the SceneMode object.
  • DS63B needs to be able to distinguish between data for App device 62X and data for App device 62Y from the data acquired from each device 61 and transmit the data to DS63A. Also, DS63A needs to be able to distinguish between data for App device 62X and data for App device 62Y from the data acquired from DS63B and transmit the data to App device 62X or App device 62Y.
  • FIG. 30 is a diagram for explaining a case where two DSs 63A and 63B are interposed between a device 61 and an App device 62 in the case of NICE Version 1.0.1, and control is performed by the second access control method described above.
  • the App device 62 sends a device list (DeviceList object) that is a list of devices 61 linked to itself to the DS 63.
  • the App device 62 also sends a SceneMode object, which is operation instruction information, to the DS 63 to instruct the operation.
  • the DS 63 refers to the device list, requests access information from the management server 60, and obtains access information (AppControl object) from the management server 60 for the DS 63 to connect to the device 61.
  • a list of devices 61 is provided to DS63A by App apparatus 62X or 62Y using a DeviceList object, and a SceneMode object, which is operation instruction information, is provided.
  • access information (AppControl object) for DS63A to connect to device 61 is provided from management server 60 to DS63A.
  • a list of devices 61 is provided to DS63B by DS63A using a DeviceList object, and a SceneMode object, which is operation instruction information, is provided.
  • access information (AppControl object) for DS63B to connect to device 61 is provided from management server 60 to DS63B.
  • DS63B needs to be able to distinguish between data for App device 62X and data for App device 62Y from the data acquired from each device 61 and transmit the data to DS63A. Also, DS63A needs to be able to distinguish between data for App device 62X and data for App device 62Y from the data acquired from DS63B and transmit the data to App device 62X or App device 62Y.
  • FIG. 31 is a diagram for explaining a case where two DSs 63A and 63B are interposed between a device 61 and an App device 62 in the case of NICE Version 1.1, and control is performed by the second access control method described above.
  • the App device 62 provides the DS 63 with a device list (DeviceList object) that is a list of the devices 61 linked to the App device 62.
  • the DS 63 refers to the device list (DeviceList object) provided by each App device 62, requests access information (AppControl object) for connecting to the device 61 from the management server 60, and obtains it from the management server 60.
  • the SceneMode object which is operation instruction information, is supplied to the DS 63 from the DPC 64.
  • DS63A is supplied with a device list (DeviceList object) from App device 62X or 62Y, and is supplied with access information (AppControl object) from management server 60. Also, DS63A is supplied with operation instruction information from DPC 64 by a SceneMode object.
  • DS63B is supplied with a device list (DeviceList object) from DS63A, and is supplied with access information (AppControl object) from management server 60. Also, DS63B is supplied with operation instruction information from DPC 64 by a SceneMode object.
  • DS63B needs to be able to distinguish between data for App device 62X and data for App device 62Y from the data acquired from each device 61 and transmit the data to DS63A. Also, DS63A needs to be able to distinguish between data for App device 62X and data for App device 62Y from the data acquired from DS63B and transmit the data to App device 62X or App device 62Y.
  • Figure 32 is a table summarizing the sources from which access information (AppControl object) and operation instruction information (SceneMode object) are provided in the first access control method and the second access control method in NICE Version 1.0.1 and NICE Version 1.1, respectively.
  • the operation instruction information can be configured to include information identifying which App device 62 the information corresponds to, specifically whether it corresponds to App device 62X or App device 62Y.
  • AppInstanceID which is identification information (device identification information) that identifies the App device 62
  • DataPipelineID which is identification information (data pipeline identification information) of the data pipeline
  • each device 61 transmits data acquired by a sensor to the DS 63 either directly or after performing a predetermined data processing.
  • the DS 63 acquires linking information between the device 61 and the App device 62, determines a destination of data acquired from one or more devices 61 based on the acquired linking information, and transmits the data to one or more App devices 62 determined as the destination.
  • the linking information between the device 61 and the App device 62 is acquired from the App device 62.
  • the linking information between the device 61 and the App device 62 is acquired from the management server 60. This allows the DS 63 intervening between the device 61 and the App device 62 to appropriately provide data from the device 61 to the multiple App devices 62.
  • a data pipeline is configured in which data is transferred from the device 61 to the DS 63 and from the DS 63 to the App device 62.
  • the data pipeline is a data flow between entities by the Data API defined in the NICE standard.
  • the Data API is an API for data transfer, such as the above-mentioned SetSceneData and SetSceneMark.
  • the current NICE standard communications interface stipulates security measures including protection of the transmission path by TLS and client authentication by an OAuth2-based access token.
  • security measures including protection of the transmission path by TLS and client authentication by an OAuth2-based access token.
  • server authentication is performed; client authentication is not performed at the TLS layer, but is achieved by using an access token stipulated in the NICE application layer.
  • the access token is delivered to the sender by the SceneMode object, and the access token is set in the parameters of the Data APIs SetSceneMark and SetSceneData.
  • the server-side entity authenticates the client by checking the claims in the access token (descriptions of destination, sender, etc.).
  • FIG. 35 is a block diagram showing an example of the configuration of a data processing system according to a second embodiment of the present disclosure, which realizes an authentication method for two-way data communication.
  • the data processing system 200 shown in FIG. 35 includes a device 211, a DS 212, an App device 213, a management server 221, and a DPC 222.
  • Device 211, DS 212, and App device 213 are entities that make up the data pipeline, and correspond to device 61, DS 63, and App device 62 of data processing system 51 described above. However, they differ from the entities of data processing system 51 described above and the entities of the current NICE standard in that they realize authentication of both the client-side entity and the server-side entity (mutual authentication) during authentication when transmitting data between entities.
  • the management server 22 like the management server 60 described above, manages the device 61 and the App device 62 by linking them to user accounts.
  • the management server 221 also has a function to send a DeviceControl object to the device 211, a function to send an AppControl object and a DeviceControl object to the DS 212, and a function to send an AppControl object to the App device 213.
  • the AppControl object and the DeviceControl object are collectively referred to as a Control object.
  • the management server 221 has a function of issuing a set of certificates required for TLS (Transport Layer Security) communication to each entity of the device 211, the DS 212, and the App device 213. Specifically, as shown in FIG. 36, the management server 221 can issue its own TLS root certificate, TLS server certificate, and TLS client certificate.
  • the current NICE standard system has a mechanism for issuing X.509 certificates using public key cryptography, so this mechanism is expanded so that the management server 221 issues its own TLS root certificate, TLS server certificate, and TLS client certificate.
  • the management server 221 distributes its own TLS root certificate to each entity.
  • the management server 221 provides (sends) the issued TLS client certificate and TLS server certificate to the DPC 222.
  • the management server 60 has been described as corresponding to the NICE LA/AS (License Authority and NICE Account Service) in the NICE standard, but the management server 221 of the data processing system 200 need only be compatible with NICE AS. Of course, the management server 221 may also be compatible with NICE LA/AS.
  • NICE LA/AS Liense Authority and NICE Account Service
  • the DPC 222 instructs the operation of the device 211 and the DS 212 by sending a SceneMode object to the device 211 and the DS 212. Since the DPC 222 is in a position to instruct the operation, when two entities communicate data, it knows which of the two entities will be the client-side entity and which will be the server-side entity. Therefore, the DPC 222 distributes (sends) a TLS client certificate or a TLS server certificate obtained from the management server 221 according to the role of each entity. A TLS client certificate is distributed to a client-side entity, and a TLS server certificate is distributed to a server-side entity.
  • TLS client certificate and TLS server certificate are distributed. Once the role of the entity has been determined, data is transmitted from the client-side entity to the server-side entity using the Data APIs SetSceneMark and SetSceneData.
  • the distribution of a TLS certificate to an entity will be described using an example in which data communication is performed between the entities device 211 and DS 212.
  • data is sent from device 211 to DS 212.
  • Each of the device 211 and DS 212 entities connects to the management server 221 at startup and receives a Control object from the management server 221.
  • the client-side entity receives an AppControl object
  • the server-side entity receives a DeviceControl object, with regard to the Control object it receives.
  • the Control object has a property called AllowedTLSRootCertificates.
  • the management server 221 sets its own TLS root certificate in the AllowedTLSRootCertificates property of the Control object and sends it to the device 211 and DS 212, thereby distributing the TLS root certificate required for TLS communication to the device 211 and DS 212.
  • each entity of the device 211 and the DS 212 receives a SceneMode object from the DPC 222 to obtain an operation instruction.
  • the SceneMode object has a property called EndPoint for specifying the destination of data transmission.
  • the DPC 222 sets an identifier indicating the role of the client-side entity (TLS client) or server-side entity (TLS server) and a certificate corresponding to the role (i.e., a TLS server certificate or a TLS client certificate) in the EndPoint property and transmits it to the device 211 and the DS 212, thereby distributing the TLS server certificate or the TLS client certificate to the device 211 and the DS 212.
  • TLS client client-side entity
  • TLS server server-side entity
  • an identifier indicating the role of the client-side entity (TLS client) and a TLS client certificate are set in the EndPoint property of the SceneMode object of the device 211.
  • an identifier indicating the role of the server-side entity (TLS server) and a TLS server certificate are set in the EndPoint property of the SceneMode object of the DS 212.
  • a SceneMode object whose EndPoint property contains an identifier indicating the role of the client-side entity (TLS client) or server-side entity (TLS server) and a TLS server certificate or TLS client certificate corresponding to that role does not exist in the current NICE standard, so this is a new feature.
  • step S201 the management server 221 sends a DeviceControl object to the device 211 in response to a request from the device 211.
  • the AllowedTLSRootCertificates property of the DeviceControl object contains a TLS root certificate.
  • step S201 the management server 221 sends a DeviceControl object to the DS212 in response to a request from the DS212.
  • the AllowedTLSRootCertificates property of the DeviceControl object contains a TLS root certificate.
  • step S202 the DPC 222 sends a SceneMode object to the device 211 in response to a request from the device 211.
  • the EndPoint property of the SceneMode object sent to the device 211 contains an identifier indicating the role of the client-side entity (TLS client) and a TLS client certificate.
  • the DPC 222 sends a SceneMode object to the DS 212 in response to a request from the DS 212.
  • the EndPoint property of the SceneMode object sent to the DS 212 contains an identifier indicating the role of the server-side entity (TLS server) and a TLS server certificate.
  • step S203 the device 211 and the DPC 222 perform TLS mutual authentication using the TLS root certificate and the TLS client certificate or TLS server certificate that they hold. Specifically, the device 211, which is a TLS client, requests a server certificate from the DPC 222, verifies the acquired server certificate using the TLS root certificate, and authenticates the DPC 222. Next, the DPC 222, which is a TLS server, requests a TLS client certificate from the device 211, which is a TLS client, and verifies the acquired TLS client certificate using the TLS root certificate to authenticate the device 211.
  • TLS mutual authentication is completed and the device 211 and DPC 222 are mutually authenticated, data is sent from the client-side entity to the server-side entity using SetSceneMark and SetSceneData over a TLS communication channel encrypted with a common key.
  • two devices 211, device 211A and device 211B may be connected in series, and data may be transferred in the following order using SetSceneMark and SetSceneData: device 211A, device 211B, DS 212, and App device 213.
  • data communication may be performed bidirectionally between devices 211A and 211B.
  • DPC 222 can include two identifiers, an identifier indicating the role of a TLS client and an identifier indicating the role of a TLS server, as well as both a TLS client certificate and a TLS server certificate in the EndPoint property of the SceneMode object and send them to each of devices 211A and 211B. This makes it possible to realize bidirectional inter-device communication that is not specified in the current NICE standard.
  • the DPC 222 uses a SceneMode object to transmit at least one identifier for identifying the role of a TLS client or a TLS server, and a TLS certificate corresponding to the identifier, to two entities communicating data.
  • the two entities perform TLS mutual authentication using the TLS certificate included in the SceneMode object to authenticate the entities during data communication.
  • authentication is completed when a TLS session is established, and therefore client authentication using an OAuth2-based access token, which is currently performed in the NICE standard, is not required, and mutual authentication of two-way data communication between the entities is facilitated.
  • the current SceneMode object of the NICE standard is modified to store at least one of a TLS client certificate or a TLS server certificate, and at least one of an identifier indicating the role of the TLS client or TLS server in the SceneMode object and distribute it to entities.
  • the method of distributing the certificate and identifier is not limited to the SceneMode object, and other objects may be used.
  • a new object that stores and distributes the certificate and identifier of the TLS client or TLS server may be defined and used.
  • the management server 221 distributes the TLS root certificate
  • the DPC 222 distributes the TLS client certificate and the TLS server certificate.
  • a single device may distribute the TLS root certificate, the TLS client certificate, and the TLS server certificate.
  • the management server 221 and the DPC 222 may be physically configured as a single device.
  • FIG. 41 is a block diagram showing an example configuration of a device (device apparatus) 300 that can be used as device 61 of data processing system 51 or device 211 of data processing system 200.
  • the device 300 includes a sensor unit 321, a processing unit 322, a memory unit 323, and a communication unit 324.
  • the sensor unit 321 acquires sensing data and outputs the acquired sensing data to the processing unit 322.
  • the sensor unit 321 has an imaging optical system such as a photographing lens and a zoom lens that collect light emitted from a subject, and an imaging element such as a CCD (Charge Coupled Device) image sensor or a CMOS (Complementary Metal Oxide Semiconductor) image sensor.
  • an imaging optical system such as a photographing lens and a zoom lens that collect light emitted from a subject
  • an imaging element such as a CCD (Charge Coupled Device) image sensor or a CMOS (Complementary Metal Oxide Semiconductor) image sensor.
  • the sensor unit 321 may also be configured with an object recognition function. For example, if the object recognition function includes a function for recognizing the type of an imaged object, the sensor unit 321 may output information indicating the recognition result as sensing data. For example, the sensor unit 321 outputs text data indicating the type of recognized object as sensing data.
  • the object recognition function may include a function for counting the number of specified objects or a function for counting the number of people in a specific state (for example, the number of people who are talking). In this case, text data indicating the number of objects or people may be output as sensing data.
  • the sensor unit 321 may also include a ToF (Time of Flight) sensor as a depth sensor (distance measurement sensor).
  • the ToF sensor can directly or indirectly measure the return time of reflected light from the subject, thereby acquiring shape information (depth information/image) such as the distance between the ToF sensor and the subject and unevenness.
  • the sensor unit 321 may also include positioning sensors such as an IR (infrared) camera and a GNSS (Global Navigation Satellite System) sensor, a temperature sensor, a sound pickup device (microphone), an air pressure sensor, a humidity sensor, a wind direction and speed sensor, a sunshine sensor, a precipitation sensor, a water level sensor, a seismic intensity sensor (a sensor that detects the seismic intensity of an earthquake), etc.
  • the sensor unit 321 is not particularly limited as long as it can acquire sensing data from the surrounding environment (sensing environment).
  • the sensor unit 321 may be fixed within the device 300, or may be detachably attached to the device 300.
  • the processing unit 322 is configured, for example, by a microcomputer having processing circuits such as a CPU and a GPU (Graphics Processing Unit), a ROM, a RAM, etc.
  • This processing unit 322 functions as a control unit that performs overall control of the device 300 by executing processing based on a program stored in a storage device such as a ROM.
  • the processing unit 322 also has a function of processing the sensing data acquired by the sensor unit 321 and generating transmission data.
  • the memory unit 323 stores programs and information for the processing unit 322 to execute various processes, as well as information obtained by the processes.
  • the memory unit 323 can be used for temporary storage of information output by the sensor unit 321, such as sensing data.
  • the memory unit 323 is realized by a storage device such as an SSD (Solid State Drive) or HDD (Hard Disk Drive).
  • the communication unit 324 can send and receive data to and from an external device, which is another entity.
  • This communication unit 324 is, for example, a communication interface that has the function of sending and receiving data.
  • each functional unit such as the processing unit 322 may be configured with both or either of hardware and software.
  • each functional unit may be realized by a computer such as a CPU or MPU executing a program pre-stored in ROM using a RAM or the like as a working area.
  • each functional unit may be realized by an integrated circuit such as an ASIC or FPGA.
  • FIG. 42 is a block diagram showing an example of the hardware configuration of a computer 500 serving as an information processing device that can be used as the management server 60, App device 62, DS 63, or DPC 64 of the data processing system 51, or the DS 212, App device 213, management server 221, or DPC 222 of the data processing system 200.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • An input/output interface 505 is further connected to the bus 504.
  • An input unit 506, an output unit 507, a memory unit 508, a communication unit 509, and a drive 510 are connected to the input/output interface 505.
  • the input unit 506 includes a keyboard, mouse, microphone, etc.
  • the output unit 507 includes a display, speaker, etc.
  • the storage unit 508 includes a hard disk, non-volatile memory, etc.
  • the communication unit 509 includes a network interface, etc.
  • the drive 510 drives a removable recording medium 511 such as a magnetic disk, optical disk, magneto-optical disk, or semiconductor memory.
  • the CPU 501 loads, for example, a program stored in the storage unit 508 into the RAM 503 via the input/output interface 505 and the bus 504 and executes it, thereby carrying out the above-mentioned series of processes.
  • the CPU 501 functions as a control unit when the computer 500 operates as an information processing device.
  • the RAM 503 also stores data necessary for the CPU 501 to execute various processes as appropriate.
  • the program executed by the computer 500 can be provided by being recorded on a removable recording medium 511 such as a package medium, for example.
  • the program can also be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.
  • a program can be installed in storage unit 508 via input/output interface 505 by inserting removable recording medium 511 into drive 510.
  • the program can also be received by communication unit 509 via a wired or wireless transmission medium and installed in storage unit 508.
  • the program can be pre-installed in ROM 502 or storage unit 508.
  • the programs executed by computer 500 may be programs in which processing is performed chronologically in the order described in this specification, or may be programs in which processing is performed in parallel or at the required timing, such as when a call is made.
  • a system refers to a collection of multiple components (devices, modules (parts), etc.), regardless of whether all the components are in the same housing. Therefore, multiple devices housed in separate housings and connected via a network, and a single device in which multiple modules are housed in a single housing, are both systems.
  • the technology disclosed herein can be configured as cloud computing, in which a single function is shared and processed collaboratively by multiple devices over a network.
  • each step described in the above flowchart can be executed by one device, or can be shared and executed by multiple devices.
  • the multiple processes included in that one step can be executed by one device, or can be shared and executed by multiple devices.
  • An information processing device comprising: a control unit that acquires, for a plurality of application devices, linking information between a device that outputs data and an application device that performs a specified data processing using the data, determines a destination of the data acquired from one or more of the devices based on the acquired linking information, and controls transmission of the data to the one or more application devices determined as the destination.
  • a control unit acquires, for a plurality of application devices, linking information between a device that outputs data and an application device that performs a specified data processing using the data, determines a destination of the data acquired from one or more of the devices based on the acquired linking information, and controls transmission of the data to the one or more application devices determined as the destination.
  • the information processing device wherein the control unit acquires a device list of the devices associated with the application device from the application device, and acquires the association information from a server device that manages the association information based on the device list.
  • the information processing apparatus according to (7) or (8), wherein the application apparatus transmits the device list to the information processing apparatus based on access information for connecting to the application apparatus, the access information having been acquired from the server apparatus.
  • the information processing device according to any one of (1) to (9), wherein the access information for the information processing device to connect to the device includes data pipeline identification information for identifying a data pipeline.
  • the information processing device according to any one of (1) to (10), wherein access information for the application device to connect to the device linked to the application device includes data pipeline identification information for identifying a data pipeline.
  • the control unit acquires operation instruction information including device identification information for identifying the application device or data pipeline identification information for identifying a data pipeline, and determines a destination of the data based on the acquired operation instruction information.
  • control unit acquires operation instruction information, determines a destination of the data based on operation instruction identification information that identifies the operation instruction information contained in the data acquired from the device, and transmits the data to one or more application devices determined as the destination.
  • control unit acquires operation instruction information, determines a destination of the data based on operation instruction identification information that identifies the operation instruction information contained in the data acquired from the device, and transmits the data to one or more application devices determined as the destination.
  • the information processing device according to any one of (1) to (13), which is a Data Service of the NICE standard.
  • An information processing device An information processing method comprising: acquiring, for a plurality of application devices, linking information between a device that outputs data and an application device that performs a specified data processing using the data; determining a destination of the data acquired from one or more of the devices based on the acquired linking information; and transmitting the data to the one or more application devices determined as the destination.
  • a computer-readable recording medium having recorded thereon a program for executing a process of acquiring, for a plurality of application devices, linking information between a device that outputs data and an application device that performs a specified data processing using the data, determining a destination of the data acquired from one or more of the devices based on the acquired linking information, and transmitting the data to the one or more application devices determined as the destination.
  • An information processing device comprising: a control unit that performs control to transmit an identifier for identifying a role of a TLS client or a TLS server, and a TLS certificate corresponding to the identifier, to two entities that communicate data generated by the device.
  • the information processing device according to any one of (17) to (21), wherein the information processing device is a Data Pipeline Controller of the NICE standard.
  • the information processing device according to any one of (17) to (22), wherein at least one of the two entities is a device conforming to the NICE standard.
  • the information processing device according to any one of (17) to (23), wherein the two entities are devices conforming to the NICE standard.
  • the information processing device according to any one of (17) to (24), wherein the control unit acquires a TLS client certificate and a TLS server certificate issued by a management server and controls transmission of the certificate to each of the two entities.
  • the management server is a NICE AS of the NICE standard.
  • An information processing device An information processing method for transmitting an identifier for identifying the role of a TLS client or a TLS server, and a TLS certificate corresponding to the identifier, to two entities communicating data generated by the device.
  • An information processing device An information processing method for transmitting an identifier for identifying the role of a TLS client or a TLS server, and a TLS certificate corresponding to the identifier, to two entities communicating data generated by the device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Facsimiles In General (AREA)
  • Accessory Devices And Overall Control Thereof (AREA)
  • Computer And Data Communications (AREA)

Abstract

本開示は、デバイスとアプリケーション装置との間に介在する装置が、デバイスからのデータをアプリケーション装置に適切に提供できるようにする情報処理装置、情報処理方法、および記録媒体に関する。 DSは、データを出力するデバイスと、データを用いた所定のデータ処理を行うApp装置との紐づけ情報を、複数のApp装置について取得し、取得した紐づけ情報に基づいて、１つ以上のデバイスから取得したデータの送り先を決定し、送り先として決定された１つ以上のApp装置にデータを送信する制御を行う制御部を備える。本開示の技術は、例えば、NICE規格にしたがったデータ通信を行う装置等に適用できる。

Description

情報処理装置、情報処理方法、および記録媒体
　本開示は、情報処理装置、情報処理方法、および記録媒体に関し、特に、デバイスとアプリケーション装置との間に介在する装置が、デバイスからのデータをアプリケーション装置に適切に提供できるようにした情報処理装置、情報処理方法、および記録媒体に関する。
　監視カメラ等のデバイス（センサデバイス）と、デバイスで得られたデータを処理して所定のサービスを提供するアプリケーション装置（サービスサーバ）との間のインターフェースを構築することを目的として、NICE（Network of Intelligent Camera Ecosystem）と呼ばれる規格が策定されている。また、NICE規格に適用可能な、デバイスまたはアプリケーション装置に関する技術も提案され始めている（例えば、特許文献１参照）。
　NICE規格に準拠したシステムにおいては、デバイスとアプリケーション装置との間に、データサービス(以下、DSと称する。)と呼ばれる中継装置が介在する場合がある。DSは、アプリケーション装置の下請けとして、アプリケーション装置に代わってデバイスと通信を行う。
国際公開第２０２２／００４４１２号
　NICE規格では、DSとアプリケーション装置が１対１の場合が想定されているが、DSが複数のアプリケーション装置の仲介をすることが考えられる。DSが複数のアプリケーション装置の下請けとして動作しようとすると、現在のNICE規格では、アプリケーション装置毎に異なるデバイスのアクセス権限をDSに伝えることができない。そのため、アプリケーション装置の下請けとして働くDSは、デバイスからのデータを、どのアプリケーション装置に提供してよいのかわからない。
　本開示は、このような状況に鑑みてなされたものであり、デバイスとアプリケーション装置との間に介在する装置が、デバイスからのデータをアプリケーション装置に適切に提供できるようにするものである。
　本開示の第１の側面の情報処理装置は、
　データを出力するデバイスと、前記データを用いた所定のデータ処理を行うアプリケーション装置との紐づけ情報を、複数の前記アプリケーション装置について取得し、取得した紐づけ情報に基づいて、１つ以上の前記デバイスから取得した前記データの送り先を決定し、送り先として決定された１つ以上の前記アプリケーション装置に前記データを送信する制御を行う制御部
　を備える。
　本開示の第１の側面の情報処理方法は、
　情報処理装置が、
　データを出力するデバイスと、前記データを用いた所定のデータ処理を行うアプリケーション装置との紐づけ情報を、複数の前記アプリケーション装置について取得し、取得した紐づけ情報に基づいて、１つ以上の前記デバイスから取得した前記データの送り先を決定し、送り先として決定された１つ以上の前記アプリケーション装置に前記データを送信する。
　本開示の第１の側面の記録媒体は、
　コンピュータに、
　データを出力するデバイスと、前記データを用いた所定のデータ処理を行うアプリケーション装置との紐づけ情報を、複数の前記アプリケーション装置について取得し、取得した紐づけ情報に基づいて、１つ以上の前記デバイスから取得した前記データの送り先を決定し、送り先として決定された１つ以上の前記アプリケーション装置に前記データを送信する
　処理を実行させるためのプログラムを記録したコンピュータ読み取り可能なものである。
　本開示の第１の側面においては、データを出力するデバイスと、前記データを用いた所定のデータ処理を行うアプリケーション装置との紐づけ情報が、複数の前記アプリケーション装置について取得され、取得された紐づけ情報に基づいて、１つ以上の前記デバイスから取得した前記データの送り先が決定され、送り先として決定された１つ以上の前記アプリケーション装置に前記データが送信される。
　本開示の第２の側面の情報処理装置は、
　デバイスが生成したデータを通信する２つのエンティティに、TLSクライアントまたはTLSサーバの役割を識別する識別子と、その識別子に応じたTLS証明書を送信する制御を行う制御部
　を備える。
　本開示の第２の側面の情報処理方法は、
　情報処理装置が、
　デバイスが生成したデータを通信する２つのエンティティに、TLSクライアントまたはTLSサーバの役割を識別する識別子と、その識別子に応じたTLS証明書を送信する。
　本開示の第２の側面の記録媒体は、
　コンピュータに、
　デバイスが生成したデータを通信する２つのエンティティに、TLSクライアントまたはTLSサーバの役割を識別する識別子と、その識別子に応じたTLS証明書を送信する
　処理を実行させるためのプログラムを記録したコンピュータ読み取り可能なものである。
　本開示の第２の側面においては、デバイスが生成したデータを通信する２つのエンティティに、TLSクライアントまたはTLSサーバの役割を識別する識別子と、その識別子に応じたTLS証明書が送信される。
　通信とは、無線通信および有線通信は勿論、無線通信と有線通信とが混在した通信、即ち、ある区間では無線通信が行われ、他の区間では有線通信が行われるようなものであっても良い。さらに、ある装置から他の装置への通信が有線通信で行われ、他の装置からある装置への通信が無線通信で行われるようなものであっても良い。
　なお、本開示の第１及び第２の側面の情報処理装置は、コンピュータにプログラムを実行させることにより実現することができる。この情報処理装置を実現するために、コンピュータに実行させるプログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して、提供することができる。
　情報処理装置は、独立した装置であっても良いし、１つの装置を構成している内部ブロックであっても良い。
NICE　Version 1.0.1におけるアクセス制御を説明する図である。 DSが介在する場合のNICE　Version 1.0.1におけるアクセス制御を説明する図である。 NICE　Version 1.1におけるアクセス制御を説明する図である。 NICE　Version 1.0.1規格における基本動作シーケンスを説明する図である。 データ処理システムで実現したい構成例を示すブロック図である。 データ処理システムで実現したい構成例を示すブロック図である。 データ処理システムで実現したい構成例を示すブロック図である。 本開示の第１実施の形態に係るデータ処理システムの構成例を示すブロック図である。 NICE　Version 1.0.1の場合の第１のアクセス制御方法の概要を説明する図である。 NICE　Version 1.0.1の場合の第１のアクセス制御処理を説明するフローチャートである。 図１０のステップＳ５１におけるAppControlオブジェクトの例を示す図である。 図１０のステップＳ５２におけるアクセス情報発行要求コマンドの例を示す図である。 図１０のステップＳ５４におけるAppControlオブジェクトの例を示す図である。 図１０のステップＳ５１におけるAppControlオブジェクトの例を示す図である。 図１０のステップＳ５１におけるDeviceControlオブジェクトの例を示す図である。 図１０のステップＳ５１におけるDeviceControlオブジェクトの例を示す図である。 図１０のステップＳ５５におけるDeviceControlオブジェクトの例を示す図である。 図１０のステップＳ５８におけるSceneMarkオブジェクトの例を示す図である。 図１０のステップＳ５８におけるDataSectionオブジェクトの例を示す図である。 NICE　Version 1.1の場合の第１のアクセス制御方法の概要を説明する図である。 NICE　Version 1.1の場合の第１のアクセス制御処理を説明するフローチャートである。 図２１のステップＳ８７におけるGetSceneModeの例を示す図である。 NICE　Version 1.0.1の場合の第２のアクセス制御方法の概要を説明する図である。 NICE　Version 1.0.1の場合の第２のアクセス制御処理を説明するフローチャートである。 図２４のステップＳ１２２におけるDeviceListオブジェクトの例を示す図である。 NICE　Version 1.1の場合の第２のアクセス制御方法の概要を説明する図である。 NICE　Version 1.1の場合の第２のアクセス制御処理を説明するフローチャートである。 NICE　Version 1.0.1において２つのDSが介在する場合の第１のアクセス制御方法を説明する図である。 NICE　Version 1.1において２つのDSが介在する場合の第１のアクセス制御方法を説明する図である。 NICE　Version 1.0.1において２つのDSが介在する場合の第２のアクセス制御方法を説明する図である。 NICE　Version 1.1において２つのDSが介在する場合の第２のアクセス制御方法を説明する図である。 図２８ないし図３１のアクセス情報と動作指示情報の提供元を説明する図である。 ２つのDSが介在する場合のSceneModeオブジェクトの例を示す図である。 データパイプラインを説明する図である。 本開示の第２実施の形態に係るデータ処理システムの構成例を示すブロック図である。 管理サーバの証明書発行機能を説明する図である。 エンティティへのTLS証明書の配布を説明する図である。 第２実施の形態に係るデータ処理システムが行う認証処理を説明するフローチャートである。 データパイプラインの別の例を示す図である。 デバイス間で双方向にデータ通信を行う場合のTLS証明書の配布を説明する図である。 デバイスの構成例をブロック図である。 コンピュータのハードウェアの構成例を示すブロック図である。
　以下、添付図面を参照しながら、本開示の技術を実施するための形態（以下、実施の形態という）について説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。説明は以下の順序で行う。
１．NICE規格のアクセス制御処理
２．実現したいシステム構成
３．第１実施の形態に係るデータ処理システム
４．第１のアクセス制御方法（NICE　Version 1.0.1の場合）
５．第１のアクセス制御方法（NICE　Version 1.1の場合）
６．第２のアクセス制御方法（NICE　Version 1.0.1の場合）
７．第２のアクセス制御方法（NICE　Version 1.1の場合）
８．複数のDSが介在する場合
９.第１実施の形態に係るデータ処理システムのまとめ
１０.第２実施の形態に係るデータ処理システム
１１．認証処理のフローチャート
１２.第２実施の形態に係るデータ処理システムのまとめ
１３．ハードウェア構成例
＜１．NICE規格のアクセス制御処理＞
　本開示のデータ処理システムは、現在のNICE規格にしたがった制御では実現できないアクセス権限を授与する制御を含む。本開示のデータ処理システムを説明する前に、現在のNICE規格にしたがったアクセス制御について説明する。現在のNICE規格では、Version 1.0.1とVersion 1.1の少なくとも２つのバージョンが存在する。
＜NICE　Version 1.0.1（DSなし）＞
　図１は、NICE　Version 1.0.1におけるアクセス制御を説明する図である。
　図１に示されるデータ処理システム１は、管理サーバ１０と、複数のデバイス１１と、複数のApp装置１２とを含む。図１では、デバイス１１とApp装置１２については、説明の便宜上、３台のデバイス１１A,１１B,１１Wと、１台のApp装置１２Aのみが示されている。管理サーバ１０、デバイス１１、及び、App装置１２のそれぞれは、データ処理システム１のエンティティを構成する。
　管理サーバ１０は、所定のネットワーク上に配置された複数のデバイス１１と複数のApp装置１２に対してユーザごとにアクセス権限を適切に付与することで、各デバイス１１と各App装置１２のアクセス制御を行うサーバ装置である。具体的には、管理サーバ１０は、ユーザアカウントに紐づけてデバイス１１とApp装置１２を管理し、所定のユーザに対応するデバイス１１とApp装置１２とがデータを授受できるように制御するとともに、ユーザが異なるデバイス１１とApp装置１２とはデータを授受できないように制御する。
例えば、所定のユーザAに対応する装置として、デバイス１１A及びデバイス１１Bと、App装置１２Aとがネットワーク上にある場合、管理サーバ１０は、App装置１２Aが、同じユーザのデバイス１１A及びデバイス１１Bに対してはアクセスでき、データを授受可能に制御するが、他のユーザWのデバイス１１Wに対しては、アクセス及びデータの授受ができないように制御する。管理サーバ１０は、NICE　Version 1.0.1においては、例えば、NICE LA/AS（License Authority and NICE Account Service）に相当する。ネットワークとしては、有線または無線を問わず、例えば、公衆電話回線網、所謂４G回線や５G回線等の無線移動体用の広域通信網、WAN（Wide Area Network）、LAN（Local Area Network）、インターネットやホームネットワーク、衛星通信網等を用いることが可能である。
　デバイス１１は、例えば、監視カメラ等の撮像センサ、ToFセンサ、IR（赤外線）カメラ、GNSS（Global Navigation Satellite System）センサ等の測位センサや、温度センサ、収音装置（マイクロフォン）、気圧センサ、湿度センサ、風向風速センサ、日照センサ、降水量センサ、水位センサ、震度センサ（地震の震度を検出するセンサ）等のセンサを含む装置で構成される。デバイス１１は、センサにより取得されたデータをそのまま、あるいは、内部にあるCPU(Central Processing Unit)、MPU(MicroProccesing Unit)等の演算装置や、ASIC(Application Specific Integrated Circuit)やFPGA(Field-Programmable Gate Array)等の集積回路により所定のデータ処理を実行した後のデータを、対応するApp装置１２へ送信する。ToFセンサは、被写体からの反射光の戻り時間を直接的又は間接的に計測することにより、ToFセンサと被写体との間の距離及び凹凸等の形状情報（深度情報／画像）を取得するセンサである。なお、デバイス１１は、自宅や店舗等に設置された監視カメラのように固定して設置されてもよいし、移動体に搭載され、任意の場所を移動可能に設置されてもよい。移動体とは、例えば、自動車、電気自動車、ハイブリッド電気自動車、自動二輪車、自転車、パーソナルモビリティ、飛行機、ドローン、船舶、ロボット（移動ロボット）、建設機械、農業機械（トラクタ）等である。
　App装置１２は、CPU(Central Processing Unit)、ROM(Read Only Memory)、RAM(Random Access Memory)等のハードウエアを有し、デバイス１１から送信されてくるデータを用いた所定のデータ処理を行うアプリケーション（プログラム）が実行される装置（アプリケーション装置）である。App装置１２は、例えば、サーバ装置、スマートフォン、タブレット型PC(Personal Computer)、スマートウォッチ、携帯電話、ラップトップ型PC、ノート型PC等のモバイル端末、HMD(Head Mounted Display)等のウェアラブルデバイスであってもよい。また、App装置１２は、車両に搭載されたECU(Electronic Control Unit)やドローンやロボットなどを遠隔操作するコントローラなどであってもよい。さらに、App装置１２は、ユーザに向けて表示を行う表示部（図示省略）や、ユーザからの操作を受け付ける操作部（図示省略）や、ユーザに向けて音声出力を行うスピーカ（図示省略）等を有していてもよい。App装置１２は、NICE　Version 1.0.1においては、AppやServiceと呼ばれる。
　図１を参照して、所定のユーザAに対応するデバイス１１A及びデバイス１１BとApp装置１２Aとに対するアクセス制御を例に、NICE　Version 1.0.1におけるアクセス制御を説明する。
　管理サーバ１０は、ユーザに対応するデバイス１１及びApp装置１２を、各ユーザのユーザアカウントに紐づけて管理するとともに、デバイス１１毎に、そのデバイス１１を利用可能なApp装置１２を管理する。ユーザAのアカウントに対しては、デバイス１１A及び１１Bと、App装置１２Aが紐づけられており、デバイス１１A及び１１Bを利用可能なApp装置１２として、App装置１２Aが登録されている。
　管理サーバ１０は、App装置１２Aからのリクエストに応じてAppControlオブジェクトを送信することにより、App装置１２Aがデバイス１１A及び１１Bに接続する際に使用する、デバイス１１A及び１１Bに関するアクセスポイント情報をApp装置１２Aに送信する。このアクセスポイント情報には、通信相手のデバイス１１を識別するデバイスID(UUID)、公開鍵情報、アクセストークンなどが含まれる。アクセストークンには、送信元情報（sub: subject）と送信先情報（aud: audience）が含まれる。具体的には、デバイス１１Aに関するアクセスポイント情報には、デバイス１１AのデバイスIDと公開鍵情報が含まれ、アクセストークンの送信元（sub）はApp装置１２A、送信先（aud）はデバイス１１Aとなる。デバイス１１Bに関するアクセスポイント情報には、デバイス１１BのデバイスIDと公開鍵情報が含まれ、アクセストークンの送信元（sub）はApp装置１２A、送信先（aud）はデバイス１１Bとなる。
　なお、NICE規格において、デバイス１１及びApp装置１２の各々は、１つ以上のノードの集合体で構成され、アクセスポイント情報（接続情報）のレベルは、Management I/F（Interface）、Control I/F、Data I/Fの３つのクラスに分類されている。Management I/Fは、デバイス１１またはApp装置１２全体へ指示するレベルのクラスであり、Control I/FとData I/Fのアクセスポイント情報を含むことができる。Control I/Fは、ノードへ指示するレベルのクラスであり、ノード単位のControl I/Fのアクセスポイント情報を含む。Data I/Fは、データに関して指示するレベルのクラスであり、ノード単位のData I/Fの１つ以上のポートに関するアクセスポイント情報を含む。ポートとは、Data I/Fの通信先を示す概念であり、ノードは複数のポートを持つことができる。
　また、管理サーバ１０は、DeviceControlオブジェクトをデバイス１１Aへ送信することにより、デバイス１１AがApp装置１２Aに接続する際に使用する、App装置１２Aに関するアクセスポイント情報をデバイス１１Aに送信する。App装置１２Aに関するアクセスポイント情報には、App装置１２AのデバイスIDと公開鍵情報が含まれ、アクセストークンの送信元（sub）はデバイス１１A、送信先（aud）はApp装置１２Aとなる。管理サーバ１０は、図示が省略されているが、デバイス１１Bに対しても同様に、DeviceControlオブジェクトにより、App装置１２Aに関するアクセスポイント情報をデバイス１１Bに送信する。App装置１２Aに関するアクセスポイント情報には、App装置１２AのデバイスIDと公開鍵情報が含まれ、アクセストークンの送信元（sub）はデバイス１１B、送信先（aud）はApp装置１２Aとなる。DeviceControlオブジェクトには、App装置１２AのControl I/Fに対するアクセスポイント情報が含まれるが、Data I/Fに対するアクセスポイント情報は含まれない。Data I/Fに対するアクセスポイント情報は、後述するSceneModeオブジェクトに含まれる。
　管理サーバ１０からApp装置１２Aへ送信されるAppControlオブジェクトには、他のユーザに対応するデバイス１１Wに関するアクセスポイント情報は含まれないため、App装置１２Aは、デバイス１１Wへアクセスすることはできない。また、デバイス１１Wへ提供されるDeviceControlオブジェクトにも、App装置１２Aに関するアクセスポイント情報は含まれない。仮に、App装置１２Aがデバイス１１Wへアクセスした場合、デバイス１１Wは、App装置１２Aとの通信を拒否する。
　次に、App装置１２Aは、管理サーバ１０から取得したデバイス１１Aに関するアクセスポイント情報を使用してデバイス１１Aと通信し、SceneModeオブジェクトをデバイス１１Aへ送信することにより、データの送り先情報などを指定する。SceneModeオブジェクトは、動作指示情報としてのシーンモードを設定するオブジェクトである。デバイス１１Aは、SceneModeオブジェクトに含まれるData I/Fに対するアクセスポイント情報を使用して、シーンモードで設定された動作を実行して取得したデータを、App装置１２Aに送信する。Data I/Fに対するアクセスポイント情報のアクセストークンの送信元（sub）はデバイス１１A、送信先（aud）はApp装置１２Aとなる。App装置１２Aは、デバイス１１Bに対しても同様に、SceneModeオブジェクトをデバイス１１Bへ送信することにより、データの送り先情報などを指定する。
　以上のように、NICE　Version 1.0.1においては、管理サーバ１０が保持するデバイス１１－App装置１２の適切な紐づけ情報に基づいて、AppControlオブジェクト、DeviceControlオブジェクト、SceneModeオブジェクトにより、送信元（sub）及び送信先（aud）が指定され、アクセスが制御される。AppControlオブジェクト、DeviceControlオブジェクト、SceneModeオブジェクトは、設定情報を要求するリクエストを情報提供先へ送信することにより、情報提供先から取得することができるAPI（Application Programming Interface）オブジェクトである。
＜NICE　Version 1.0.1（DSあり）＞
　NICE　Version 1.0.1においては、図２に示されるように、デバイス１１とApp装置１２との間に、DS１３が介在する場合がある。DS１３は、データ処理システム１のエンティティの一つであり、複数のデバイス１１をとりまとめ、App装置１２の下請けとして動作する。DS１３を介在させることにより、App装置１２は、自身に紐づけられたデバイス１１が複数（多数）存在する場合に、各デバイス１１に個別にアクセスする必要がなくなる。DS１３は、NICE　Version 1.0.1においては、Data Serviceと呼ばれる。
　図２を参照して、NICE　Version 1.0.1において、DS１３が介在する場合のアクセス制御について説明する。
　管理サーバ１０は、App装置１２からのリクエストに応じてAppControlオブジェクトを送信することにより、App装置１２がDS１３に接続する際に使用する、DS１３に関するアクセスポイント情報をApp装置１２に送信する。アクセスポイント情報には、通信相手のDS１３を識別するデバイスID(UUID)、公開鍵情報、アクセストークンなどが含まれる。このアクセストークンの送信元（sub）はApp装置１２A、送信先（aud）はDS１３となる。
　DS１３は、下流（ネットワークのエッジ側）のデバイス１１A及び１１Bに対しては、図１で示したデバイス１１－App装置１２の２者間におけるApp装置１２に相当するエンティティとして振る舞う。一方、DS１３は、上流（ネットワークのクラウド側）のApp装置１２Aに対しては、図１で示したデバイス１１－App装置１２の２者間におけるデバイス１１に相当するエンティティとして振る舞う。
　具体的には、管理サーバ１０からDS１３に対して、App装置１２A相当のエンティティとしての処理を行うためのAppControlオブジェクトが、DS１３からのリクエストに応じて送信される。AppControlオブジェクトには、デバイス１１A向けのアクセスポイント情報と、デバイス１１B向けのアクセスポイント情報とが含まれる。デバイス１１A向けのアクセスポイント情報には、通信相手のデバイス１１Aを識別するデバイスID、公開鍵情報、アクセストークンなどが含まれる。デバイス１１A向けのアクセストークンの送信元（sub）はDS１３、送信先（aud）はデバイス１１Aとなる。デバイス１１B向けのアクセスポイント情報には、通信相手のデバイス１１Bを識別するデバイスID、公開鍵情報、アクセストークンなどが含まれる。デバイス１１B向けのアクセストークンの送信元（sub）はDS１３、送信先（aud）はデバイス１１Bとなる。
　また、管理サーバ１０からDS１３に対して、デバイス１１相当のエンティティとしての処理を行うためのDeviceControlオブジェクトが、DS１３へ送信される。DeviceControlオブジェクトには、App装置１２AのデバイスIDと公開鍵情報が含まれ、アクセストークンの送信元（sub）はDS１３、送信先（aud）はApp装置１２Aとなる。
　さらに、管理サーバ１０は、DeviceControlオブジェクトをデバイス１１Aへ送信することにより、デバイス１１AがDS１３に接続する際に使用する、DS１３に関するアクセスポイント情報をデバイス１１Aに送信する。デバイス１１A向けのDS１３に関するアクセスポイント情報には、DS１３のデバイスIDと公開鍵情報が含まれ、アクセストークンの送信元（sub）はデバイス１１A、送信先（aud）はDS１３となる。図示は省略されているが、管理サーバ１０は、デバイス１１Bに対しても同様に、DeviceControlオブジェクトにより、DS１３に関するアクセスポイント情報をデバイス１１Bに送信する。デバイス１１B向けのDS１３に関するアクセスポイント情報には、DS１３のデバイスIDと公開鍵情報が含まれ、アクセストークンの送信元（sub）はデバイス１１B、送信先（aud）はDS１３となる。
　DS１３は、管理サーバ１０から取得したデバイス１１Aに関するアクセスポイント情報を使用してデバイス１１Aと通信し、SceneModeオブジェクトをデバイス１１Aへ送信することにより、データの送り先情報などを指定する。また、DS１３は、管理サーバ１０から取得したデバイス１１Bに関するアクセスポイント情報を使用してデバイス１１Bと通信し、SceneModeオブジェクトをデバイス１１Bへ送信することにより、データの送り先情報などを指定する。
　デバイス１１Aは、SceneModeオブジェクトに含まれるData I/Fに対するアクセスポイント情報を使用して、シーンモードで設定された動作を実行して取得したデータを、DS１３に送信する。デバイス１１Bは、SceneModeオブジェクトに含まれるData I/Fに対するアクセスポイント情報を使用して、シーンモードで設定された動作を実行して取得したデータを、DS１３に送信する。DS１３は、SceneModeオブジェクトに含まれるData I/Fに対するアクセスポイント情報を使用して、デバイス１１Aまたはデバイス１１Bから取得したデータを、App装置１２Aに送信する。
　以上のように、DS１３が介在する場合には、デバイス１１－DS１３間、及び、DS１３－App装置１２間のそれぞれにおいて、上述したデバイス１１－App装置１２間と同様のアクセス制御がなされる。デバイス１１Aで取得されたデータは、デバイス１１AからDS１３、DS１３からApp装置１２Aの順で転送される。デバイス１１Bで取得されたデータは、デバイス１１BからDS１３、DS１３からApp装置１２Aの順で転送される。デバイス１１A －DS１３－App装置１２Aや、デバイス１１B－DS１３－App装置１２Aのような、DS１３を介したデータの一連の流れをデータパイプラインと称する。
　以上のように、NICE　Version 1.0.1では、AppControlオブジェクトまたはDeviceControlオブジェクトが、管理サーバ１０から、デバイス１１A及び１１B、App装置１２A、DS１３へ送信され、SceneModeオブジェクトは、上位のエンティティとなるApp装置１２AまたはDS１３から送信される。
　なお、図１のデバイス１１－App装置１２間、図２のデバイス１１－DS１３間、または、DS１３－App装置１２間それぞれの通信において、２者の間に、ブローカー（例えば、MQTTブローカー）が介在する場合もある。
＜NICE　Version 1.1＞
　次に、図３を参照して、NICE　Version 1.1におけるアクセス制御について、上述した例と同様に、所定のユーザAに対応するデバイス１１A及びデバイス１１BとApp装置１２Aとに対するアクセス制御を例に説明する。
　NICE　Version 1.1では、DS１３が必ず存在する。また、NICE　Version 1.1では、データパイプラインを管理（制御）するDPC（Data Pipeline Controller）１４がデータ処理システム１に新たに追加される。
　管理サーバ１０は、ユーザアカウントに紐づけてデバイス１１とApp装置１２を管理する。ただし、管理サーバ１０には、所定のユーザに対応するデバイス１１とApp装置１２とを直接紐づける情報は存在しない。
　DPC１４は、必要な情報を管理サーバ１０及びApp装置１２Aから取得することにより、データ処理に関する情報を有している。例えば、DPC１４は、デバイス１１A －DS１３－App装置１２Aや、デバイス１１B－DS１３－App装置１２Aのデータパイプライン情報や、SceneModeオブジェクトを送信するための設定情報を、管理サーバ１０またはApp装置１２Aから取得し、有している。
　管理サーバ１０は、App装置１２Aからのリクエストに応じてAppControlオブジェクトを送信することにより、App装置１２AがDS１３に接続する際に使用する、DS１３に関するアクセスポイント情報をApp装置１２Aに送信する。このアクセスポイント情報には、通信相手のDS１３を識別するデバイスID、公開鍵情報、アクセストークンなどが含まれる。このアクセストークンの送信元（sub）はApp装置１２A、送信先（aud）はDS１３となる。
　また、管理サーバ１０は、デバイス１１Aからのリクエストに応じてDeviceControlオブジェクトを送信することにより、デバイス１１AがDPC１４に接続する際に使用する、DPC１４に関するアクセスポイント情報をデバイス１１Aに送信する。デバイス１１A向けのDPC１４に関するアクセスポイント情報には、DPC１４のデバイスIDと公開鍵情報が含まれ、アクセストークンの送信元（sub）はデバイス１１A、送信先（aud）はDPC１４となる。管理サーバ１０は、同様にデバイス１１Bに対しても、DeviceControlオブジェクトを送信することにより、DPC１４に関するアクセスポイント情報をデバイス１１Bに送信する。デバイス１１B向けのDPC１４に関するアクセスポイント情報には、DPC１４のデバイスIDと公開鍵情報が含まれ、アクセストークンの送信元（sub）はデバイス１１B、送信先（aud）はDPC１４となる。NICE　Version 1.0.1では、DeviceControlオブジェクトは、各デバイス６１からのリクエストに応じて送信することもできるし、リクエストなしに送信することもできるが、NICE　Version 1.1では、DeviceControlオブジェクトは、常に、各デバイス６１からのリクエストに応じて送信される。
　管理サーバ１０は、App装置１２相当としての処理を行うためのAppControlオブジェクトを、DS１３からのリクエストに応じてDS１３へ送信する。AppControlオブジェクトには、デバイス１１A向けのアクセスポイント情報と、デバイス１１B向けのアクセスポイント情報とが含まれる。デバイス１１A向けのアクセスポイント情報には、通信相手のデバイス１１Aを識別するデバイスID、公開鍵情報、アクセストークンなどが含まれる。デバイス１１A向けのアクセストークンの送信元（sub）はDS１３、送信先（aud）はデバイス１１Aとなる。デバイス１１B向けのアクセスポイント情報には、通信相手のデバイス１１Bを識別するデバイスID、公開鍵情報、アクセストークンなどが含まれる。デバイス１１B向けのアクセストークンの送信元（sub）はDS１３、送信先（aud）はデバイス１１Bとなる。
　また、管理サーバ１０は、デバイス１１相当としての処理を行うためのDeviceControlオブジェクトを、DS１３からのリクエストに応じてDS１３へ送信する。DeviceControlオブジェクトには、DPC１４のデバイスIDと公開鍵情報が含まれ、アクセストークンの送信元（sub）はDS１３、送信先（aud）はDPC１４となる。
　DPC１４は、App装置１２Aと共有するデバイス１１Aに関するアクセスポイント情報を使用してデバイス１１Aと通信し、SceneModeオブジェクトをデバイス１１Aへ送信することにより、データの送り先情報などを指定する。また、DPC１４は、App装置１２Aと共有するデバイス１１Bに関するアクセスポイント情報を使用してデバイス１１Bと通信し、SceneModeオブジェクトをデバイス１１Bへ送信することにより、データの送り先情報などを指定する。さらに、DPC１４は、App装置１２Aと共有するDS１３に関するアクセスポイント情報を使用してDS１３と通信し、SceneModeオブジェクトをDS１３へ送信することにより、データの送り先情報などを指定する。
　以上のように、NICE　Version 1.1では、AppControlオブジェクトまたはDeviceControlオブジェクトが、管理サーバ１０から、デバイス１１A及び１１B、App装置１２A、DS１３へ送信される点は、NICE　Version 1.0.1と共通するが、SceneModeオブジェクトは、DPC１４から送信される点が異なる。また、NICE　Version 1.1では、アクセストークンについては、アプリケーションレイヤで規定され、WebAPIのみサポートされている。
＜NICE　基本動作シーケンス＞
　次に、図４を参照して、NICE　Version 1.0.1規格において２つのエンティティ間で行われる基本動作シーケンスについて説明する。
　図４は、NICE　Version 1.0.1規格における基本動作シーケンスの一例を示すシーケンス図である。なお、図４では、デバイス１１に対して指示を与える上位のエンティティであるApp装置１２またはDS１３を、まとめてApp装置１２/DS１３と称する。
　図４に示されるように、基本動作は、App装置１２/DS１３がデバイス１１の処理能力を取得する能力取得フェーズＰ１０と、デバイス１１にSceneModeオブジェクトを設定するモード設定フェーズＰ２０と、デバイス１１にSceneModeオブジェクトで指定した所定のデータ処理（例えばＡＩによる検出処理）を実行させる実行フェーズＰ３０と、デバイス１１に所定のデータ処理を終了させる終了フェーズＰ４０とから構成される。SceneModeオブジェクトでは、例えば、人検出や動体検出等のシーンモードを指定することができる。シーンモードには、例えば「1.Face、2.Human、3.Object Label、4.Animal、5.Text/Logo/QRCode、6.Vehicle、7.Custom」などがある。
（能力取得フェーズＰ１０）
　能力取得フェーズＰ１０では、まず、ステップＳ１１において、App装置１２/DS１３からデバイス１１へ、デバイス１１の処理能力をApp装置１２/DS１３へ報告させるための指示（コマンド）であるGetCapabilitiesが通知される。これに対し、デバイス１１は、ステップＳ１２において、自己の処理能力に関する情報（Capabilities）をApp装置１２/DS１３へ通知する。なお、各デバイス１１の処理能力に関する情報（Capabilities）は、能力取得フェーズＰ１０を事前に実施しておくことで、App装置１２/DS１３において事前に管理されていてもよい。
（モード設定フェーズＰ２０）
　モード設定フェーズＰ２０では、ステップＳ１３において、App装置１２/DS１３からデバイス１１へ、どのSceneModeオブジェクトを使用するかの指示であるSetSceneModeが通知される。
（実行フェーズＰ３０）
　実行フェーズＰ３０では、ステップＳ１４において、App装置１２/DS１３からデバイス１１へ、SetSceneModeで指定された所定のデータ処理を開始させるための指示であるStartSceneが通知される。StartSceneが通知されると、デバイス１１は、ステップＳ１５において、モード設定フェーズＰ２０でSceneModeオブジェクトにより指定されたデータ処理を実行する。そして、ステップＳ１６において、デバイス１１は、取得されたデータに基づく送信データを生成し、SetSceneMarkまたはSetSceneDataにより、App装置１２/DS１３へ送信する。SetSceneDataでは、画像や音声などのデータそのものが送信される。SetSceneMarkでは、画像や音声などに紐づいたメタデータが送信される。例えば、SceneModeオブジェクトとして人の検出が設定された場合には、人が現れたときのサムネイルやタイムスタンプ等の情報がSetSceneMarkで送信される。なお、SetSceneMark及びSetSceneDataによるデータの送信先は、App装置１２/DS１３に限定されず、他のデバイス１１等であってもよい。
（終了フェーズＰ４０）
　終了フェーズＰ４０では、ステップＳ１７において、App装置１２/DS１３からデバイス１１へ、SceneModeオブジェクトで指定した所定のデータ処理を終了させるための指示であるStopSceneが通知される。これに対し、デバイス１１は、SceneModeオブジェクトで指定された所定のデータ処理を終了する。
　NICE規格においては、以上のような基本動作シーケンスにより、デバイス１１で取得されたデータが、DS１３、App装置１２へと送信される。
＜２．実現したいシステム構成＞
　次に、以上のような現在のNICE規格を前提として、データ処理システム１において実現したい構成について説明する。
　図５は、データ処理システム１で実現したい構成例を示すブロック図である。
　図５のデータ処理システム１は、デバイス１１A、デバイス１１B、及び、デバイス１１Cの３つのデバイス１１と、DS１３と、App装置１２X及びApp装置１２Yの２つのApp装置１２とで構成される。
　App装置１２Xは、デバイス１１A及びデバイス１１Bから送信されてくるデータを処理する。App装置１２Yは、デバイス１１A及びデバイス１１Cから送信されてくるデータを処理する。
　デバイス１１Aは、App装置１２X及びApp装置１２Yの両者から、使用が許可されている。デバイス１１Bは、App装置１２Xから、使用が許可されている。デバイス１１Cは、App装置１２Yから、使用が許可されている。
　DS１３は、３つのデバイス１１A乃至Cと、２つのApp装置１２X及び１２Yとの間に介在し、App装置１２X及び１２Yの下請けとして、３つのデバイス１１A、１１B、及び１１Cから送信されてくるデータを、App装置１２Xまたは１２Yへ適切に振り分けて送信することが必要となる。
　具体的には、図６に示されるように、DS１３は、デバイス１１Aから送信されてきたデータについては、App装置１２X及び１２Yへ送信する。また、DS１３は、デバイス１１Bから送信されてきたデータについてはApp装置１２Xのみへ送信し、デバイス１１Cから送信されてきたデータについてはApp装置１２Yのみへ送信する。逆に言えば、DS１３は、デバイス１１Cから送信されてきたデータについてはApp装置１２Xへ送信せず、デバイス１１Bから送信されてきたデータについてはApp装置１２Yへ送信しないように制御することが必要となる。
　App装置１２X及び１２Yは、送信されてくるデータが、使用が許可されているどのデバイス１１からのデータであるのかを必要以上に意識することなく、送信されてきたデータを利用したい。ただし、送信されてくるデータが、どのデバイス１１からのデータであるかが必要な情報である場合は、正確に認識できる必要がある。
　DS１３は、データが送信されてきたデバイス１１や、送信先のApp装置１２に応じて、データに追加的な処理を実施した後で転送するなどを行ってもよいが、本処理では省略する。
　以上のように、DS１３が、１つのApp装置１２に対する下請けとしてではなく、２つ以上のApp装置１２の下請けとしての機能を実現しようとする場合、現在のNICE　Version 1.0.1の規格では、次のような問題が存在する。
　図７に示されるように、各App装置１２に提供されるAppControlオブジェクトには、DS１３にアクセスするためのアクセスポイント情報が含まれる。例えば、DS１３へのアクセスで必要となるアクセストークンが、各App装置１２に提供されるAppControlオブジェクトに含まれる。
　DS１３に提供されるDeviceControlオブジェクトには、App装置１２X及び１２Yにアクセスするためのアクセスポイント情報が含まれる。例えば、App装置１２Xへのアクセスで必要となるアクセストークンと、App装置１２Yへのアクセスで必要となるアクセストークンが、DS１３に提供されるDeviceControlオブジェクトに含まれる。
　一方、DS１３に提供されるAppControlオブジェクトには、デバイス１１A、１１B、及び１１Cにアクセスするためのアクセスポイント情報が含まれる。例えば、デバイス１１A、１１B、及び１１Cへのアクセスで必要となる計３個のアクセストークンが、DS１３に提供されるAppControlオブジェクトに含まれる。
　デバイス１１A、１１B、及び１１Cに提供されるDeviceControlオブジェクトには、DS１３にアクセスするためのアクセスポイント情報が含まれる。例えば、DS１３へのアクセスで必要となるアクセストークンが、デバイス１１A、１１B、及び１１Cに提供されるDeviceControlオブジェクトに含まれる。
　しかしながら、DS１３には、App装置１２とデバイス１１との適切な紐づけ（対応関係）については通知されないため、DS１３は、デバイス１１Cから送信されてきたデータを、App装置１２Xへ送信してはいけないことが分からない。同様に、DS１３は、デバイス１１Bから送信されてきたデータを、App装置１２Yへ送信してはいけないことが分からない。
　現在のNICE　Version 1.1の規格でも、同様の問題が存在する。すなわち、管理サーバ１０は、ユーザアカウントに紐づけてデバイス１１とApp装置１２を管理するが、デバイス１１とApp装置１２間を個別に紐づける情報は有していない。従って、１つのユーザアカウントに、複数のデバイス１１、または、複数のApp装置１２が紐づいている場合、App装置１２毎に使用可能なデバイス１１を指定することができない。
　以上のように、現在のNICE　Version 1.0.1及びVersion 1.1の規格にしたがったデータ処理システム１では、DS１３は、図５及び図６で説明したデータの適切な振り分けができない。
　そこで、以下では、NICE　Version 1.0.1（DSあり）及びVersion 1.1の規格を一部拡張し、DS１３が、２つ以上のApp装置１２の下請けとしての機能を実現する場合に、データを適切に振り分けて送信できるシステムについて説明する。
＜３．第１実施の形態に係るデータ処理システム＞
　図８は、本開示の第１実施の形態に係るデータ処理システムの構成例を示すブロック図である。
　図８に示されるデータ処理システム５１は、管理サーバ６０と、デバイス６１A乃至６１Cの３つのデバイス６１と、App装置６２X及び６２Yの２つのApp装置６２と、DS６３と、DPC６４とを有する。管理サーバ６０、デバイス６１、App装置６２、DS６３、及び、DPC６４の各々は、データ処理システム５１のエンティティを構成する。
　データ処理システム５１の管理サーバ６０、デバイス６１、App装置６２、DS６３、及び、DPC６４は、それぞれ、上述したデータ処理システム１の管理サーバ１０、デバイス１１、App装置１２、DS１３、及び、DPC１４に対応し、以下で説明する点以外については、同様の構成及び機能を有するものとする。換言すれば、データ処理システム５１の各エンティティは、図５ないし図８を参照して説明した問題点を解決する機能を備えている点以外については、現在のNICE　Version 1.0.1（DSあり）及びVersion 1.1の規格に準拠して動作する。
　管理サーバ６０は、ユーザアカウントに紐づけてデバイス６１とApp装置６２を管理する。管理サーバ６０は、AppControlオブジェクトを各App装置６２へ送信する機能、AppControlオブジェクト及びDeviceControlオブジェクトをDS６３へ送信する機能、DeviceControlオブジェクトを各デバイス６１へ送信する機能を備えている。
　また、NICE　Version 1.0.1では、動作指示情報としてのSceneModeオブジェクトが、上位のエンティティから提供され、NICE　Version 1.1では、SceneModeオブジェクトが、DPC６４から提供される点も同様である。なお、データ処理システム５１がNICE　Version 1.0.1に準拠した動作を行う場合、DPC６４は省略可能である。
　データ処理システム５１は、以下で説明する第１のアクセス制御方法と第２のアクセス制御方法のいずれかを選択的に実行することにより、デバイス６１からのデータを、App装置６２X及び６２Yの少なくとも一方へ適切に振り分けることができ、図５ないし図８を参照して説明した問題点を解決することができる。
＜４．第１のアクセス制御方法（NICE　Version 1.0.1の場合）＞
　図９を参照して、NICE　Version 1.0.1の場合にデータ処理システム５１が実行する第１のアクセス制御方法の概要を説明する。図９では、既存のNICE　Version 1.0.1からの変更点について説明する。
　管理サーバ６０は、App装置６２からの要求に応じて、App装置６２に紐づいているデバイス６１とApp装置６２のアクセス情報（AppControlオブジェクト）をApp装置６２へ送信する。また、管理サーバ６０は、App装置６２からの要求に応じて、App装置６２に紐づいているデバイス６１にDS６３が接続するためのアクセス情報をApp装置６２へ送信する。このアクセス情報は、例えば、NICE　Version 1.0.1におけるAppControlオブジェクトに相当し、既存のAppControlオブジェクトを変更して使用することができる。
　App装置６２は、管理サーバ６０から取得した、自身に紐づけられているデバイス６１にDS６３が接続するためのアクセス情報（AppControlオブジェクト）をDS６３へ送信する。App装置６２に紐づけられているデバイス６１のうち、一時停止中のデバイス６１など、使用されないデバイス６１のアクセス情報は省略してよい。このアクセス情報は、例えば、NICE　Version 1.0.1におけるAppControlオブジェクトに相当し、既存のAppControlオブジェクトを変更して使用することができる。
　また、App装置６２は、動作指示情報であるSceneModeオブジェクトをDS６３へ送信し、動作を指示する。この処理は、上述したNICE　Version 1.0.1と同様である。
　このように、第１のアクセス制御方法では、App装置６２が、自身に紐づいているデバイス６１とApp装置６２のアクセス情報を管理サーバ６０から取得し、自身に紐づけられているデバイス６１にDS６３が接続するためのアクセス情報を、App装置６２からDS６３へ送信する方法が採用される。これにより、DS６３は、App装置６２からアクセス情報が供給されたデバイス６１が、そのApp装置６２と紐づけられているデバイス６１であると認識することができ、App装置６２とデバイス６１との対応関係を認識することができる。
（NICE　Version 1.0.1の場合の第１のアクセス制御フロー）
　図１０のフローチャートを参照して、NICE　Version 1.0.1の場合のデータ処理システム５１による第１のアクセス制御処理を説明する。
　初めに、ステップＳ５１において、管理サーバ６０は、各エンティティからの要求に応じて、制御用情報を、各エンティティ、すなわち、デバイス６１A乃至６１C、App装置６２X及び６２Y、並びに、DS６３に送信する。具体的には、図２を参照して説明したように、デバイス６１A乃至６１CにはDeviceControlオブジェクトが提供され、App装置６２X及び６２YにはAppControlオブジェクトが提供される。DS６３には、AppControlオブジェクトとDeviceControlオブジェクトが提供される。ここで、App装置６２X及び６２Yに提供されるAppControlオブジェクトには、App装置６２がDS６３と通信するための情報だけでなく、DS６３が、App装置６２の下請けとして通信する相手であるデバイス６１と通信するための情報も含まれる。
　図１１は、ステップＳ５１において、管理サーバ６０からApp装置６２Xに対して制御用情報として供給されるAppControlオブジェクトの例を示している。
　ステップＳ５１において管理サーバ６０からApp装置６２Xに供給されるAppControlオブジェクトには、装置特定情報８１、コントロールI/F情報８２A乃至８２C、及び、データI/F情報８３A乃至８３Cが含まれる。
　装置特定情報８１は、App装置６２X自身またはApp装置６２Xのデータパイプラインを特定する情報である。装置特定情報８１には、例えば、バージョン情報“Version”が“1.0”であること、App装置６２Xの識別情報（装置識別情報）“AppID”が“Application1ID”であること、App装置６２上で実行されているインスタンスの識別情報（インスタンス識別情報）“AppInstanceID”が“AppInst1ID”であること、データパイプラインの識別情報（データパイプライン識別情報）“DataPipelineID”が“AppInst1DataPipelineID”であること特定されている。データパイプライン識別情報は、単一のApp装置６２が複数のデータパイプラインを利用する場合に、個々のデータパイプラインを識別するための情報である。単一のApp装置６２が１つのデータパイプラインを利用する場合には、インスタンス識別情報でデータパイプラインを識別できるため、データパイプライン識別情報は省略することができる。
　装置特定情報８１に続く“ControlEndPoints”: [・・・]には、App装置６２Xが通信相手のControl I/Fと通信するための情報が含まれ、図１１の例では、コントロールI/F情報８２A乃至８２Cが含まれる。
　コントロールI/F情報８２Aは、App装置６２XがDS６３のControl I/Fと通信するための情報である。コントロールI/F情報８２Aには、APIバージョン情報である“APIVersion”、通信相手を特定する情報（相手装置特定情報）である“EndPointID”、X.509証明書（公開鍵）である“X.509Certificate”、アクセストークンである“AccessToken”が含まれる。コントロールI/F情報８２Aでは、“APIVersion”は“1.0”、“EndPointID”は“DSInstID”、 “X.509Certificate”は“DSInstPublicKey”、 “AccessToken”は“DSInstControlAccessToken4AppInst1”とされている。
　コントロールI/F情報８２Bは、App装置６２Xがデバイス６１AのControl I/Fと通信するための情報である。コントロールI/F情報８２Bでは、“APIVersion”は“1.0”、“EndPointID”は“Device0ID”、 “X.509Certificate”は“Device0PublicKey”、 “AccessToken”は“Device0ControlAccessToken4AppInst1”とされている。このアクセストークン“Device0ControlAccessToken4AppInst1”は、App装置６２Xのためのアクセストークンであるため、DS６３は使用できない。
　コントロールI/F情報８２Cは、App装置６２Xがデバイス６１BのControl I/Fと通信するための情報である。コントロールI/F情報８２Cでは、“APIVersion”は“1.0”、“EndPointID”は“Device1ID”、 “X.509Certificate”は“Device1PublicKey”、 “AccessToken”は“Device1ControlAccessToken4AppInst1”とされている。このアクセストークン“Device1ControlAccessToken4AppInst1”は、App装置６２Xのためのアクセストークンであるため、DS６３は使用できない。
　“ControlEndPoints”: [・・・]に続く“DataEndPoints”: [・・・]には、App装置６２Xが通信相手のData I/Fと通信するための情報が含まれ、図１１の例では、データI/F情報８３A乃至８３Cが含まれる。
　データI/F情報８３Aは、App装置６２XがDS６３のData I/Fと通信するための情報である。データI/F情報８３Aには、APIバージョン情報である“APIVersion”、通信相手を特定する情報（相手装置特定情報）である“EndPointID”、X.509証明書（公開鍵）である“X.509Certificate”、アクセストークンである“AccessToken”が含まれる。図１１のデータI/F情報８３Aの例では、“APIVersion”は“1.0”、“EndPointID”は“DSInstID”、“X.509Certificate”は“DSInstPublicKey”、“AccessToken”は“DSInstDataAccessToken4AppInst1”とされている。
　データI/F情報８３Bは、App装置６２Xがデバイス６１AのData I/Fと通信するための情報である。データI/F情報８３Bでは、“APIVersion”は“1.0”、“EndPointID”は“Device0ID”、 “X.509Certificate”は“Device0InstPublicKey”、 “AccessToken”は“Device0DataAccessToken4AppInst1”とされている。このアクセストークン“Device0DataAccessToken4AppInst1”は、App装置６２Xのためのアクセストークンであるため、DS６３は使用できない。
　データI/F情報８３Cは、App装置６２Xがデバイス６１BのData I/Fと通信するための情報である。データI/F情報８３Cでは、“APIVersion”は“1.0”、“EndPointID”は“Device1ID”、 “X.509Certificate”は“Device1InstPublicKey”、 “AccessToken”は“Device1ControlAccessToken4AppInst1”とされている。このアクセストークン“Device1DataAccessToken4AppInst1”は、App装置６２Xのためのアクセストークンであるため、DS６３は使用できない。
　管理サーバ６０からApp装置６２Xに供給されるAppControlオブジェクトには、図１１の例のように、管理サーバ６０が管理するApp装置６２とデバイス６１との紐づけ情報に基づいて、App装置６２Xと紐づけられているデバイス６１A及び６１Bに接続するための情報も提供される。
　次に、図１０のステップＳ５２において、App装置６２Xは、DS６３に権限移譲したいデバイス６１に対するアクセス情報の発行を、管理サーバ６０に要求する。App装置６２Xは、デバイス６１A及び６１Bと紐づけられており、デバイス６１A及び６１Bとの通信をDS６３に依頼するので、デバイス６１A及び６１Bに対するDS６３用のアクセス情報の発行を、管理サーバ６０に要求する。同様に、App装置６２Yは、ステップＳ５２において、DS６３に権限移譲したいデバイス６１A及び６１Cに対するアクセス情報の発行を、管理サーバ６０に要求する。
　ステップＳ５２のアクセス情報の発行要求は、NICE　Version 1.0.1の規定にはないため、例えば、リクエスト情報付きでGetAppControlを呼ぶなど、新たなコマンド（アクセス情報発行要求コマンド）の追加が必要となる。
　図１２は、ステップＳ５２のアクセス情報発行要求コマンドGetAppControlの例であって、App装置６２Xが管理サーバ６０に対してDS用アクセス情報の発行を要求するGetAppControlの例を示している。
　GetAppControlのパラメータには、例えば、図１２に示されるように、バージョン情報“Version”、要求元情報“Requester”、データパイプライン識別情報“DataPipelineID”、権限移譲先情報“Delegate”、及び、アクセス情報要求対象情報“TargetEntities”が含まれる。
　App装置６２Xが要求する際のパラメータの例では、バージョン情報“Version”は“1.0”、要求元情報“Requester”はApp装置６２Xのインスタンス識別情報“AppInst1ID”、データパイプライン識別情報“DataPipelineID”は“AppInst1DataPipelineID”、権限移譲先情報“Delegate”はDS６３のインスタンス識別情報“DSInstID”、及び、アクセス情報要求対象情報“TargetEntities”は、デバイス６１A及び６１Bの識別情報“Device0ID”及び“Device1ID”となっている。データパイプライン識別情報“DataPipelineID”がなくてもデータパイプラインを識別可能である場合には、データパイプライン識別情報は省略してもよい。
　次に、図１０のステップＳ５３において、管理サーバ６０は、自身が管理している紐づけ情報を参照し、App装置６２からのアクセス情報発行要求コマンドに記載された、権限移譲先のDS６３と、アクセス情報要求対象のデバイス６１が、要求元のApp装置６２と紐づけられていることを確認する。そして、管理サーバ６０は、要求元のApp装置６２に、DS６３とデバイス６１間で使用するアクセス情報を送信する。より具体的には、App装置６２Xに対しては、DS６３がデバイス６１A及び６１Bとの通信で使用するアクセス情報が管理サーバ６０から送信され、App装置６２Yに対しては、DS６３がデバイス６１A及び６１Cとの通信で使用するアクセス情報が管理サーバ６０から送信される。仮に、App装置６２から、要求元のApp装置６２と紐づけられていないDS６３、デバイス６１のアクセス情報が要求された場合、そのアクセス情報発行の要求は拒絶される。
　ステップＳ５４において、App装置６２は、アクセス情報発行要求コマンドに応じて取得したDS６３用のアクセス情報を、DS６３からのリクエストに応じて、DS６３へ送信する。より具体的には、App装置６２Xが、DS６３がデバイス６１A及び６１Bとの通信で使用するアクセス情報をDS６３へ送信し、App装置６２Yが、DS６３がデバイス６１A及び６１Cとの通信で使用するアクセス情報をDS６３へ送信する。
　図１３は、App装置６２XからDS６３へ送信されるアクセス情報の例を示している。このアクセス情報は、例えばAppControlオブジェクトによって提供することができる。このAppControlオブジェクトは、NICE　Version 1.0.1におけるAppControlオブジェクトを変更して作成されたものである。
　App装置６２Xは、管理サーバ６０から取得したアクセス情報を、データパイプラインに合わせてデバイス６１を選択し、AppControlオブジェクトに格納してDS６３に送信する。
　App装置６２XからDS６３に供給されるAppControlオブジェクトには、装置特定情報９１、コントロールI/F情報９２A及び９２B、並びに、データI/F情報９３A及び９３Bが含まれる。
　装置特定情報９１は、DS６３自身またはDS６３のデータパイプラインを特定する情報である。装置特定情報９１には、例えば、バージョン情報“Version”として、“1.0”、装置識別情報“AppID”として、DS６３の識別情報である“DSID”、インスタンス識別情報“AppInstanceID”として、DS６３上で実行されているインスタンスの識別情報である“DSInstID”が含まれている。また、この例では省略されているが、データパイプラインの識別情報（データパイプライン識別情報）が必要な場合は、データパイプライン識別情報も含まれる。
　装置特定情報９１に続く“ControlEndPoints”: [・・・]には、DS６３が通信相手のコントロールI/Fと通信するための情報が含まれ、図１３の例では、コントロールI/F情報９２A及び９２Bが含まれる。
　コントロールI/F情報９２Aは、DS６３がデバイス６１AのControl I/Fと通信するための情報である。コントロールI/F情報９２Aには、APIバージョン情報である“APIVersion”、通信相手を特定する情報（相手装置特定情報）である“EndPointID”、X.509証明書（公開鍵）である“X.509Certificate”、アクセストークンである“AccessToken”が含まれる。コントロールI/F情報９２Aでは、“APIVersion”は“1.0”、“EndPointID”は“Device0ID”、 “X.509Certificate”は“Device0PublicKey”、 “AccessToken”は“Device0ControlAccessToken4DSInst”とされている。
　コントロールI/F情報９２Bは、DS６３がデバイス６１BのControl I/Fと通信するための情報である。コントロールI/F情報９２Bでは、“APIVersion”は“1.0”、“EndPointID”は“Device1ID”、“X.509Certificate”は“Device1PublicKey”、“AccessToken”は“Device1ControlAccessToken4AppInst”とされている。
　"ControlEndPoints": [・・・]に続く“DataEndPoints”: [・・・]には、DS６３が通信相手のデータI/Fと通信するための情報が含まれ、図１３の例では、データI/F情報９３A及び９３Bが含まれる。
　データI/F情報９３Aは、DS６３がデバイス６１AのData I/Fと通信するための情報である。データI/F情報９３Aには、APIバージョン情報である“APIVersion”、通信相手を特定する情報（相手装置特定情報）である“EndPointID”、X.509証明書（公開鍵）である“X.509Certificate”、アクセストークンである“AccessToken”が含まれる。図１３のデータI/F情報９３Aの例では、“APIVersion”は“1.0”、“EndPointID”は“Device0ID”、“X.509Certificate”は“Device0InstPublicKey”、“AccessToken”は“Device0DataAccessToken4DSInst”とされている。
　データI/F情報９３Bは、DS６３がデバイス６１BのData I/Fと通信するための情報である。データI/F情報９３Bでは、“APIVersion”は“1.0”、“EndPointID”は“Device1ID”、 “X.509Certificate”は“Device1InstPublicKey”、 “AccessToken”は“Device1DataAccessToken4AppInst”とされている。
　DS６３は、このようなアクセス情報をApp装置６２Xから取得することにより、App装置６２Xがデバイス６１A及び６１Bと紐づいていることを認識することができる。すなわち、このアクセス情報が、デバイス６１とApp装置６２の紐づけ情報に相当する。
　図１４は、App装置６２YからDS６３へ送信されるアクセス情報の例を示している。このアクセス情報は、AppControlオブジェクトによって提供することができる。このAppControlオブジェクトは、NICE　Version 1.0.1におけるAppControlオブジェクトを変更して作成されたものである。
　App装置６２Yは、管理サーバ６０から取得したアクセス情報を、データパイプラインに合わせてデバイス６１を選択し、AppControlオブジェクトに格納してDS６３に送信する。
　App装置６２YからDS６３に供給されるAppControlオブジェクトには、装置特定情報１０１、コントロールI/F情報１０２A及び１０２B、並びに、データI/F情報１０３A及び１０３Bが含まれる。
　装置特定情報１０１は、DS６３自身またはDS６３のデータパイプラインを特定する情報である。装置特定情報１０１には、例えば、バージョン情報“Version”として、“1.0”、装置識別情報“AppID”として、DS６３の識別情報である“DSID”、インスタンス識別情報“AppInstanceID”として、DS６３上で実行されているインスタンスの識別情報である“DSInstID”が含まれている。また、この例では省略されているが、データパイプラインの識別情報（データパイプライン識別情報）が必要な場合は、データパイプライン識別情報も含まれる。
　装置特定情報１０１に続く“ControlEndPoints”: [・・・]には、DS６３が通信相手のコントロールI/Fと通信するための情報が含まれ、図１４の例では、コントロールI/F情報１０２A及び１０２Bが含まれる。
　コントロールI/F情報１０２Aは、DS６３がデバイス６１AのControl I/Fと通信するための情報である。コントロールI/F情報１０２Aには、APIバージョン情報である“APIVersion”、通信相手を特定する情報（相手装置特定情報）である“EndPointID”、X.509証明書（公開鍵）である“X.509Certificate”、アクセストークンである“AccessToken”が含まれる。コントロールI/F情報１０２Aでは、“APIVersion”は“1.0”、“EndPointID”は“Device0ID”、“X.509Certificate”は“Device0PublicKey”、“AccessToken”は“Device0ControlAccessToken4DSInst”とされている。
　コントロールI/F情報１０２Bは、DS６３がデバイス６１CのControl I/Fと通信するための情報である。コントロールI/F情報１０２Bでは、“APIVersion”は“1.0”、“EndPointID”は“Device2ID”、“X.509Certificate”は“Device2PublicKey”、 “AccessToken”は“Device2ControlAccessToken4AppInst”とされている。
　“ControlEndPoints”: [・・・]に続く“DataEndPoints”: [・・・]には、DS６３が通信相手のデータI/Fと通信するための情報が含まれ、図１４の例では、データI/F情報１０３A及び１０３Bが含まれる。
　データI/F情報１０３Aは、DS６３がデバイス６１AのData I/Fと通信するための情報である。データI/F情報９３Aには、APIバージョン情報である“APIVersion”、通信相手を特定する情報（相手装置特定情報）である“EndPointID”、X.509証明書（公開鍵）である“X.509Certificate”、アクセストークンである“AccessToken”が含まれる。データI/F情報１０３Aでは、“APIVersion”は“1.0”、“EndPointID”は“Device0ID”、“X.509Certificate”は“Device0InstPublicKey”、“AccessToken”は“Device0DataAccessToken4DSInst”とされている。
　データI/F情報１０３Bは、DS６３がデバイス６１CのData I/Fと通信するための情報である。データI/F情報１０３Bでは、“APIVersion”は“1.0”、“EndPointID”は“Device2ID”、“X.509Certificate”は“Device2InstPublicKey”、“AccessToken”は“Device2DataAccessToken4DSInst”とされている。
　DS６３は、このようなアクセス情報をApp装置６２Yから取得することにより、App装置６２Yがデバイス６１A及び６１Cと紐づいていることを認識することができる。
　上述したステップＳ５４のアクセス情報の提供は、例えば、DS６３がステップＳ５１で管理サーバ６０から供給されたDeviceControlオブジェクトに列挙されている各App装置６２に対し、GetAppControlを呼ぶことによって行われる。この場合、DS６３には、各App装置６２のManagement I/Fと通信するための情報が必要となるため、DS６３が、管理サーバ６０から供給されるDeviceControlオブジェクトに、各App装置６２のManagement I/Fと通信するための情報が含まれている必要がある。
　図１５は、各App装置６２のManagement I/Fと通信するための情報を含む、管理サーバ６０からDS６３へ供給されるDeviceControlオブジェクトの例を示している。
　管理サーバ６０からDS６３へ供給されるDeviceControlオブジェクトには、装置特定情報１１１、マネージメントI/F情報１１２A及び１１２B、並びに、コントロールI/F情報１１３A及び１１３Bが含まれる。
　装置特定情報１１１は、DS６３自身を特定する情報である。装置特定情報１１１には、例えば、バージョン情報“Version”として、“1.0”、装置識別情報“DeviceID”として、DS６３の識別情報である“DSInstID”、TLSによる通信路を確立する上で無効なアクセストークンの情報（無効トークン情報）“RevokedJSONTokenIDs”として、“Token1”,“Token2”, ... 、TLSによる通信路を確立するためのTLSルート証明書の情報（TLSルート証明書情報）“AllowedTLSRootCertificates”として、“Cert1”,“Cert2”, ... 、が含まれている。
　装置特定情報１１１に続く“ManagementEndPoints”: [・・・]には、DS６３が通信相手のManagement I/Fと通信するための情報が含まれ、図１５の例では、マネージメントI/F情報１１２A及び１１２Bが含まれる。
　マネージメントI/F情報１１２Aは、DS６３がApp装置６２XのManagement I/Fと通信するための情報である。マネージメントI/F情報１１２Aには、APIバージョン情報である“APIVersion”、通信相手を特定する情報（相手装置特定情報）である“EndPointID”、X.509証明書（公開鍵）である“X.509Certificate”、アクセストークンである“AccessToken”が含まれる。マネージメントI/F情報１１２Aでは、“APIVersion”は“1.0”、“EndPointID”は“AppInst1ID”、 “X.509Certificate”は“AppInst1PublicKey”、 “AccessToken”は“AppInst1ManagementAccessToken”とされている。
　マネージメントI/F情報１１２Bは、DS６３がApp装置６２YのManagement I/Fと通信するための情報である。マネージメントI/F情報１１２Bでは、“APIVersion”は“1.0”、“EndPointID”は“AppInst2ID”、 “X.509Certificate”は“AppInst2PublicKey”、 “AccessToken”は“AppInst2ManagementAccessToken”とされている。
　“ManagementEndPoints”: [・・・]に続く“ControlEndPoints”: [・・・]には、DS６３が通信相手のControl I/Fと通信するための情報が含まれ、図１５の例では、コントロールI/F情報１１３A及び１１３Bが含まれる。
　コントロールI/F情報１１３Aは、DS６３がApp装置６２XのControl I/Fと通信するための情報である。コントロールI/F情報１１３Aには、APIバージョン情報である“APIVersion”、通信相手を特定する情報（相手装置特定情報）である“EndPointID”、X.509証明書（公開鍵）である“X.509Certificate”、アクセストークンである“AccessToken”が含まれる。コントロールI/F情報１１３Aの例では、“APIVersion”は“1.0”、“EndPointID”は“AppInst1ID”、“X.509Certificate”は“AppInst1PublicKey”、“AccessToken”は“AppInst1ControlAccessToken”とされている。
　コントロールI/F情報１１３Bは、DS６３がApp装置６２YのControl I/Fと通信するための情報である。コントロールI/F情報１１３Bでは、“APIVersion”は“1.0”、“EndPointID”は“AppInst2ID”、“X.509Certificate”は“AppInst2PublicKey”、 “AccessToken”は“AppInst2ControlAccessToken”とされている。
　図１５に示したDeviceControlオブジェクトは、NICE　Version 1.0.1で規定されているDeviceControlオブジェクトに、各App装置６２のManagement I/Fと通信するための情報を追加した構成であるが、Management I/Fと通信するための情報と、Control I/Fと通信するための情報は共通化できるため、共用するような記載も可能である。
　図１６は、Management I/Fと通信するための情報と、Control I/Fと通信するための情報を共用する場合のDeviceControlオブジェクトの例を示している。
　管理サーバ６０からDS６３へ供給されるDeviceControlオブジェクトには、装置特定情報１２１と、マネージメント・コントロール共通I/F情報１２２A及び１２２Bが含まれる。
　装置特定情報１２１は、図１５の装置特定情報１１１と同様であるので、説明は省略する。
　装置特定情報１２１に続く“EndPoints”: [・・・]に、DS６３が通信相手のManagement I/F及びControl I/Fと通信するため共通に使用される情報が含まれ、図１５の例では、マネージメント・コントロール共通I/F情報１２２A及び１２２Bが含まれる。
　マネージメント・コントロール共通I/F情報１２２Aは、DS６３がApp装置６２XのManagement I/F及びControl I/Fと通信するための情報である。マネージメント・コントロール共通I/F情報１２２Bは、DS６３がApp装置６２YのManagement I/F及びControl I/Fと通信するための情報である。各項目は、図１４と同様であるので説明は省略する。
　次に、図１０のステップＳ５５において、管理サーバ６０は、DeviceControlオブジェクトを各デバイス６１へ送信することにより、各デバイス６１がDS６３と通信するためのアクセス情報を各デバイス１１へ送信する。NICE　Version 1.0.1では、DeviceControlオブジェクトは、各デバイス６１からのリクエストに応じて送信することもできるし、リクエストなしに送信することもできる。
　図１７は、管理サーバ６０からデバイス６１Aへ供給されるDeviceControlオブジェクトの例を示している。
　管理サーバ６０からデバイス６１Aへ供給されるDeviceControlオブジェクトには、装置特定情報１３１と、コントロールI/F情報１３２とが含まれる。
　装置特定情報１３１は、デバイス６１A自身を特定する情報である。装置特定情報１３１には、例えば、バージョン情報“Version” として、“1.0”、装置識別情報“DeviceID”として、デバイス６１Aの識別情報である“Device0ID”、TLSによる通信路を確立する上で無効なアクセストークンの情報（無効トークン情報）“RevokedJSONTokenIDs”として、“Token1”,“Token2”, ... 、TLSによる通信路を確立するためのTLSルート証明書の情報（TLSルート証明書情報）“AllowedTLSRootCertificates”として、“Cert1”,“Cert2”, ... 、が含まれている。
　装置特定情報１３１に続く“ControlEndPoints”: [・・・]には、デバイス６１Aが通信相手のControl I/Fと通信するための情報が含まれ、図１７の例ではコントロールI/F情報１３２が含まれる。
　コントロールI/F情報１３２は、デバイス６１AがDS６３のControl I/Fと通信するための情報である。コントロールI/F情報１３２には、APIバージョン情報である“APIVersion”、通信相手を特定する情報（相手装置特定情報）である“EndPointID”、X.509証明書（公開鍵）である“X.509Certificate”、アクセストークンである“AccessToken”が含まれる。コントロールI/F情報１３２では、“APIVersion”は“1.0”、“EndPointID”は“DSInstID”、“X.509Certificate”は“DSInstPublicKey”、 “AccessToken”は“DSInstControlAccessToken4Device0”とされている。
　ステップＳ５３の後に実行されるステップＳ５４とＳ５５の処理は、どちらが先に実行されても良いし、同時に実行されてもよい。
　ステップＳ５４の後、各App装置６２は、ステップＳ５６において、DS６３に対し、動作指示情報としてのシーンモードを設定するSceneModeオブジェクトを送信し、動作を指示する。例えば、DS６３が、ステップＳ５１で取得したDeviceControlオブジェクトに列挙されている各App装置６２に対してGetAppControlを呼ぶことにより、各App装置６２は、動作指示情報としてのSceneModeオブジェクトをDS６３へ送信する。SceneModeオブジェクトの取得により、DS６３は、デバイス６１－App装置６２－SceneModeの対応関係を認識することができる。
　DS６３は、ステップＳ５７において、各App装置６２から供給されたアクセス情報、及び、動作指示情報に基づいて、各デバイス６１に対し、動作指示情報としてのシーンモードを設定するSceneModeオブジェクトを送信し、動作を指示する。より具体的には、デバイス６１Aに対しては、デバイス６１A－App装置６２X－SceneModeの対応関係と、デバイス６１A－App装置６２Y－SceneModeの対応関係に従った動作が指示される。デバイス６１Bに対しては、デバイス６１B－App装置６２X－SceneModeの対応関係に従った動作が指示され、デバイス６１Cに対しては、デバイス６１C－App装置６２Y－SceneModeの対応関係に従った動作が指示される。
　ステップＳ５８において、各デバイス６１は、SceneModeオブジェクトに基づく動作、例えば、人検出や動体検出等の動作を実行し、検出結果としてのデータを、SetSceneDataまたはSetSceneMarkを用いて送信する。
　ステップＳ５９において、DS６３は、各デバイス６１から送信されてきたデータを取得するとともに、データの送り先となるApp装置６２を決定し、ステップＳ６０において、決定したApp装置６２へ、SetSceneDataまたはSetSceneMarkを用いてデータを送信する。
　ステップＳ５９では、DS６３は、デバイス６１BからのデータについてはApp装置６２Xへ送信し、デバイス６１CからのデータについてはApp装置６２Xへ送信すればよいが、デバイス６１Aからのデータについては、App装置６２Xへ送信するデータか、または、App装置６２Yへ送信するデータかを判定する必要がある。そのため、データを送付するオブジェクトであるSetSceneDataやSetSceneMarkに、どの動作指示（SceneModeオブジェクト）に基づいて検出されたデータであるかを示す動作指示識別情報が含まれるように構成されている。
　図１８は、SetSceneMarkのSceneMarkオブジェクトに、動作指示識別情報が含まれるようにした場合の構成例を示す図である。
　例えば、図１８に示されるように、SceneMarkオブジェクトに、このデータを生成する元となった動作指示（SceneModeオブジェクト）を識別する動作指示識別情報１５１である“SceneModeIDs”が含まれる。“SceneModeID1”,“SceneModeID2”は、SceneModeオブジェクトを識別するシーンモード識別情報である。
　図１９は、SetSceneDataのDataSectionオブジェクトに、動作指示識別情報が含まれるようにした場合の構成例を示す図である。
　例えば、図１９に示されるように、DataSectionオブジェクトに、このデータを生成する元となった動作指示（SceneModeオブジェクト）を識別する動作指示識別情報１５２である“SceneModeIDs”が含まれる。
　図１８及び図１９の例では、動作指示識別情報１５２であるSceneModeIDs”が、[“SceneModeID1”,“SceneModeID2”,...]のように配列形式で表現されており、複数の動作指示を列挙可能とされている。一つの動作指示のみ指定すればよい場合には、配列形式ではなく、単一形式であってもよい。
　SceneDataオブジェクトやSceneMarkオブジェクトだけでなく、それらに関連するオブジェクトであるSceneDataManifestオブジェクトやSceneMarkManifestオブジェクトに関しても同様に、動作指示識別情報が含まれるようにすることができる。SceneDataManifest は、SceneDataを含むファイルへの参照とURIを含むデータのオブジェクトであり、SceneMarkManifestは、SceneMarkへの参照とURIを含むデータのオブジェクトである。DS６３は、動作指示情報としてのSceneDataオブジェクトやSceneMarkオブジェクトに含まれる動作指示識別情報に基づいて、データの送り先を決定し、送り先として決定されたApp装置６２にデータを送信する。
　NICE　Version 1.0.1の場合のデータ処理システム５１による第１のアクセス制御方法は、以上のように行われる。
＜５．第１のアクセス制御方法（NICE　Version 1.1の場合）＞
　次に、図２０を参照して、NICE　Version 1.1の場合の第１のアクセス制御方法について説明する。図２０では、既存のNICE　Version 1.1からの変更点について説明する。
　NICE　Version 1.1では、DPC（Data Pipeline Controller）６４が、データ処理システム５１に新たに追加される。
　既存のNICE　Version 1.1では、管理サーバ１０は、ユーザアカウントに紐づけてデバイス１１とApp装置１２を管理しているが、デバイス１１とApp装置１２とを直接紐づける情報は有していない。そこで、第１のアクセス制御方法を実行する管理サーバ６０は、ユーザアカウントに紐づけてデバイス６１とApp装置６２を管理するとともに、デバイス６１とApp装置６２とを紐づけて管理する。換言すれば、デバイス６１とApp装置６２との対応関係については、管理サーバ６０は、NICE　Version 1.0.1と同様に管理する。
　管理サーバ６０は、App装置６２からの要求に応じて、App装置６２に紐づいているデバイス６１とApp装置６２のアクセス情報（AppControlオブジェクト）をApp装置６２へ送信する。また、管理サーバ６０は、App装置６２からの要求に応じて、App装置６２に紐づいているデバイス６１にDS６３が接続するためのアクセス情報をApp装置６２へ送信する。管理サーバ６０からApp装置６２へのアクセス情報の提供は、上述したNICE　Version 1.0.1における場合と同様である。
　App装置６２は、管理サーバ６０から取得した、自身に紐づけられているデバイス６１に接続するためのアクセス情報（AppControlオブジェクト）をDS６３へ送信する。App装置６２に紐づけられているデバイス６１のうち、一時停止中のデバイス６１など、使用されないデバイス６１のアクセス情報は省略してよい。このApp装置６２からデバイス６１へのアクセス情報の提供は、上述したNICE　Version 1.0.1における場合と同様である。
　一方、上述したNICE　Version 1.0.1では、動作指示情報であるSceneModeオブジェクトは、App装置６２からDS６３へ送信されるが、NICE　Version 1.1では、DPC６４から、各デバイス６１及びDS６３に送信される。すなわち、DPC６４は、デバイス６１またはDS６３からの要求に応じて、動作指示情報であるSceneModeオブジェクトをデバイス６１またはDS６３へ送信する。このとき、DPC６４は、DS６３に対して、App装置６２毎にSceneModeオブジェクトを送信する。
（NICE　Version 1.1の場合の第１のアクセス制御フロー）
　図２１のフローチャートを参照して、NICE　Version 1.1におけるデータ処理システム５１による第１のアクセス制御処理を説明する。
　初めに、ステップＳ８１において、管理サーバ６０は、各エンティティからの要求に応じて、制御用情報を、各エンティティ、すなわち、デバイス６１A乃至６１C、App装置６２X及び６２Y、並びに、DS６３に送信する。具体的には、図２を参照して説明したように、デバイス６１A乃至６１CにはDeviceControlオブジェクトが提供され、App装置６２X及び６２YにはAppControlオブジェクトが提供される。DS６３には、AppControlオブジェクトとDeviceControlオブジェクトが提供される。ここで、App装置６２X及び６２Yに提供されるAppControlオブジェクトには、App装置６２がDS６３と通信するための情報だけでなく、DS６３が、App装置６２の下請けとして通信する相手であるデバイス６１と通信するための情報も含まれる。
　ステップＳ８１において、管理サーバ６０からApp装置６２Xに対して制御用情報として供給されるAppControlオブジェクトとして、図１１に示したAppControlオブジェクトの例が適用できる。DS６３が、管理サーバ６０から供給されるDeviceControlオブジェクトとして、各App装置６２のManagement I/Fと通信するための情報を含む図１５または図１６のDeviceControlオブジェクトの例が適用できる。
　ステップＳ８２において、App装置６２Xは、DS６３に権限移譲したいデバイス６１に対するアクセス情報の発行を、管理サーバ６０に要求する。App装置６２Xは、デバイス６１A及び６１Bと紐づけられており、デバイス６１A及び６１Bとの通信をDS６３に依頼するので、デバイス６１A及び６１Bに対するDS６３用のアクセス情報の発行を、管理サーバ６０に要求する。同様に、App装置６２Yは、ステップＳ５２において、DS６３に権限移譲したいデバイス６１A及び６１Cに対するアクセス情報の発行を、管理サーバ６０に要求する。ステップＳ８２のアクセス情報の発行要求には、NICE　Version 1.0.1の第１のアクセス制御処理で説明した図１２のGetAppControlの例が適用できる。
　ステップＳ８３において、管理サーバ６０は、自身が管理している紐づけ情報を参照し、App装置６２からのアクセス情報発行要求コマンドに記載された、権限移譲先のDS６３と、アクセス情報要求対象のデバイス６１が、要求元のApp装置６２と紐づけられていることを確認する。そして、管理サーバ６０は、要求元のApp装置６２に、DS６３とデバイス６１間で使用するアクセス情報を送信する。
　ステップＳ８４において、App装置６２は、アクセス情報発行要求コマンドに応じて取得したDS６３用のアクセス情報を、DS６３からのリクエストに応じて、DS６３へ送信する。App装置６２XからDS６３へ送信されるアクセス情報の例は、NICE　Version 1.0.1の第１のアクセス制御処理で説明した図１３のAppControlオブジェクトの例が適用できる。App装置６２YからDS６３へ送信されるアクセス情報の例は、図１４のAppControlオブジェクトの例が適用できる。
　次に、ステップＳ８５において、管理サーバ６０は、各デバイス６１からのリクエストに応じてDeviceControlオブジェクトを送信することにより、各デバイス６１がDS６３と通信するためのアクセス情報を各デバイス１１へ送信する。管理サーバ６０からデバイス６１Aへ供給されるDeviceControlオブジェクトの例は、NICE　Version 1.0.1の第１のアクセス制御処理で説明した図１７のDeviceControlオブジェクトの例が適用できる。
　ステップＳ８３の後に実行されるステップＳ８４とＳ８５の処理は、どちらが先に実行されても良いし、同時に実行されてもよい。
　ステップＳ８５の後、ステップＳ８６において、各デバイス６１は、動作指示情報としてのSceneModeオブジェクトをDPC６４にリクエストし、DPC６４からSceneModeオブジェクトを取得する。DPC６４は、各デバイス６１からのリクエストに応じてSceneModeオブジェクトを送信することにより、動作を指示する。
　続いて、ステップＳ８７において、DS６３は、動作指示情報としてのSceneModeオブジェクトをDPC６４にリクエストし、DPC６４からSceneModeオブジェクトを取得する。DPC６４は、DS６３からのリクエストに応じてSceneModeオブジェクトを送信することにより、動作を指示する。このとき、DS６３は、App装置６２毎にSceneModeオブジェクトを取得する必要がある。例えば、DS６３が、ステップＳ８１で取得したDeviceControlオブジェクトに列挙されているApp装置６２を指定してGetSceneModeを呼ぶことにより、DPC６４は、指定されたApp装置６２に応じたSceneModeオブジェクトをDS６３へ送信する。
　図２２は、App装置６２毎にSceneModeオブジェクトを取得するコマンドGetSceneModeの例であって、DPC６４に対してApp装置６２X向けの動作指示情報を要求するGetSceneModeの例を示している。
　GetSceneModeのパラメータには、例えば、図２２に示されるように、バージョン情報“Version”、App装置識別情報“AppInstID”、及び、動作指示対象情報“TargetInstanceID”が含まれる。図２２の例では、App装置識別情報“AppInstID”は、App装置６２Xのインスタンス識別情報“AppInst1ID”、動作指示対象情報“TargetInstanceID”は、DS６３のインスタンス識別情報“DSInstID”となっており、DS６３に対するApp装置６２X向けの動作指示情報を要求する例となっている。また、この例では省略されているが、データパイプラインの識別情報（データパイプライン識別情報）が必要な場合は、データパイプライン識別情報も含まれる。
　DS６３は、ステップＳ８１による管理サーバ６０からの制御用情報、ステップＳ８４における各App装置６２からのアクセス情報、及び、ステップＳ８７における動作指示情報を取得することにより、デバイス６１－App装置６２－SceneModeの対応関係を認識することができる。
　ステップＳ８８において、各デバイス６１は、SceneModeオブジェクトに基づく動作、例えば、人検出や動体検出等の動作を実行し、検出結果としてのデータを、SetSceneDataまたはSetSceneMarkを用いて送信する。
　ステップＳ８９において、DS６３は、各デバイス６１から送信されてきたデータを取得するとともに、データの送り先となるApp装置６２を決定し、ステップＳ９０において、決定したApp装置６２へ、SetSceneDataまたはSetSceneMarkを用いてデータを送信する。図１８のSceneMarkや図１９のDataSectionのように、データオブジェクトに、どの動作指示（SceneModeオブジェクト）に基づいて検出されたデータであるかを示す動作指示識別情報が含まれる点は、上述したNICE　Version 1.0.1と同様である。
　NICE　Version 1.1の場合のデータ処理システム５１による第１のアクセス制御方法は、以上のように行われる。
　以上のように、第１のアクセス制御方法では、App装置６２が、自身に紐づいているデバイス６１とApp装置６２のアクセス情報を管理サーバ６０から取得し、自身に紐づけられているデバイス６１にDS６３が接続するためのアクセス情報を、App装置６２からDS６３へ送信する方法が採用される。これにより、DS６３は、App装置６２からアクセス情報が供給されたデバイス６１が、そのApp装置６２と紐づけられているデバイス６１であると認識することができ、App装置６２とデバイス６１との対応関係を認識することができる。
＜６．第２のアクセス制御方法（NICE　Version 1.0.1の場合）＞
　次に、図２３を参照して、NICE　Version 1.0.1の場合にデータ処理システム５１が実行する第２のアクセス制御方法の概要を説明する。図２３では、上述した第１のアクセス制御方法との相違点を説明しつつ、既存のNICE　Version 1.0.1からの変更点について説明する。
　上述した第１のアクセス制御方法では、管理サーバ６０から各App装置６２へ、自身（App装置６２）のアクセス情報だけではなく、自身に紐づいているデバイス６１にDS６３が接続するためのアクセス情報が提供された。第１のアクセス制御方法では、管理サーバ６０は、DS６３がデバイス６１に接続するためのアクセス情報を、個々のDS６３に提供する必要はない。
　これに対して、第２のアクセス制御方法では、App装置６２に紐づいているデバイス６１にDS６３が接続するためのアクセス情報については、管理サーバ６０から各App装置６２へ提供されない。換言すれば、第２のアクセス制御方法において、管理サーバ６０から各App装置６２へ送信されるAppControlオブジェクトは、既存のNICE　Version 1.0.1における場合と同様である。
　DS６３が使用するためのデバイス６１へのアクセス情報については管理サーバ６０から各App装置６２へ提供されないため、App装置６２に紐づけられているデバイス６１にDS６３が接続するためのアクセス情報をApp装置６２からDS６３へ送信する処理も実行されない。
　一方、上述した第１のアクセス制御方法との相違点として、第２のアクセス制御方法では、各App装置６２は、自身に紐づいているデバイス６１の一覧であるデバイスリスト（DeviceListオブジェクト）をDS６３へ提供する。なお、このデバイスリストは、既存のNICE　Version 1.0.1において、管理サーバ６０から各App装置６２へ供給されるDeviceListオブジェクトとは異なるものである。App装置６２からDS６３へ提供されるデバイスリストは、自身（App装置６２）に紐づいているデバイス６１のうち、DS６３に処理を実行させたいデバイスが列挙されたデバイス一覧となる。
　DS６３は、各App装置６２から提供されるデバイスリスト（DeviceListオブジェクト）を参照し、そのデバイス６１に接続するためのアクセス情報を、管理サーバ６０へ要求する。管理サーバ６０は、DS６３からの要求に応じて、DS６３がデバイス６１へ接続するためのアクセス情報をDS６３へ送信する。このアクセス情報は、例えば、NICE　Version 1.0.1におけるAppControlオブジェクトに相当し、既存のAppControlオブジェクトを変更して使用することができる。
　第１のアクセス制御方法では、DS６３は、App装置６２に紐づいているデバイス６１へDS６３が接続するためのアクセス情報を、App装置６２を介して取得した。これに対して、第２のアクセス制御方法では、DS６３は、App装置６２に紐づいているデバイス６１へDS６３が接続するためのアクセス情報を、管理サーバ６０から直接取得する方法が採用される。DS６３は、App装置６２からデバイスリスト（DeviceListオブジェクト）を取得することにより、そのApp装置６２と紐づけられているデバイス６１を認識することができ、App装置６２とデバイス６１との対応関係を認識し、そのデバイス６１へDS６３が接続するためのアクセス情報を、管理サーバ６０から直接取得する。このアクセス情報が、デバイス６１とApp装置６２の紐づけ情報に相当する。
（NICE　Version 1.0.1の場合の第２のアクセス制御フロー）
　図２４のフローチャートを参照して、NICE　Version 1.0.1の場合のデータ処理システム５１による第２のアクセス制御処理を説明する。
　初めに、ステップＳ１２１において、管理サーバ６０は、各エンティティからの要求に応じて、制御用情報を、各エンティティ、すなわち、デバイス６１A乃至６１C、App装置６２X及び６２Y、並びに、DS６３に送信する。具体的には、図２を参照して説明したように、デバイス６１A乃至６１CにはDeviceControlオブジェクトが提供され、App装置６２X及び６２YにはAppControlオブジェクトが提供される。DS６３には、AppControlオブジェクトとDeviceControlオブジェクトが提供される。ここで、App装置６２X及び６２Yに提供されるAppControlオブジェクトには、App装置６２がDS６３と通信するための情報だけでなく、DS６３が、App装置６２の下請けとして通信する相手であるデバイス６１と通信するための情報も含まれる。
　ステップＳ１２１において、管理サーバ６０からApp装置６２Xに対して制御用情報として供給されるAppControlオブジェクトとして、図１１に示したAppControlオブジェクトの例が適用できる。DS６３が、管理サーバ６０から供給されるDeviceControlオブジェクトとして、各App装置６２のManagement I/Fと通信するための情報を含む図１５または図１６のDeviceControlオブジェクトの例が適用できる。
　ステップＳ１２２において、App装置６２Xは、DS６３に権限移譲したいデバイス６１の一覧であるデバイスリスト（DeviceListオブジェクト）をDS６３へ送信する。同様に、App装置６２Yは、ステップＳ１２２において、DS６３に権限移譲したいデバイス６１の一覧であるデバイスリスト（DeviceListオブジェクト）をDS６３へ送信する。App装置６２Xからのデバイスリストには、デバイス６１Aとデバイス６１Bが列挙され、App装置６２Yからのデバイスリストには、デバイス６１Aとデバイス６１Cが列挙される。
　例えば、DS６３が、ステップＳ１２１で取得したDeviceControlオブジェクトに列挙されている各App装置６２に対してGetAppControlを呼ぶことにより、DS６３が各App装置６２へデバイスリストをリクエストすると、各App装置６２からDS６３へDeviceListオブジェクトが送信されてくる。
　図２５は、App装置６２XからDS６３へ送信されたDeviceListオブジェクトの例を示している。
　DeviceListオブジェクトには、例えば、図２５に示されるように、バージョン情報“Version”、ユーザアカウント識別情報“AccountID”、及び、デバイス一覧情報“DeviceList”が含まれる。デバイス一覧情報“DeviceList”には、装置識別情報“DeviceID”と、そのデバイス６１との接続状態を示す“Status”の情報が、権限移譲したいデバイス６１について列挙される。図２５の例では、ユーザアカウント識別情報“AccountID”は、App装置６２Xのユーザアカウントに対応する“AppInstOwner'sAccountID”となっている。デバイス一覧情報“DeviceList”は、デバイス６１Aに対応する装置識別情報“DeviceID”である“Device0ID”及び接続状態“Status”である“Connected”と、デバイス６１Bに対応する装置識別情報“DeviceID”である“Device1ID”及び接続状態“Status”である“Connected”とが格納されている。また、この例では省略されているが、データパイプラインの識別情報（データパイプライン識別情報）が必要な場合は、データパイプライン識別情報も含まれる。
　ステップＳ１２３において、DS６３は、デバイスリストに記載された、権限移譲対象であるデバイス６１に対するアクセス情報の発行を、管理サーバ６０に要求する。ステップＳ１２３のアクセス情報の発行要求には、NICE　Version 1.0.1の第１のアクセス制御処理で説明した図１２のGetAppControlと同等のコマンドが適用できる。
　ステップＳ１２４において、管理サーバ６０は、自身が管理している紐づけ情報を参照し、DS６３からのアクセス情報発行要求コマンドに記載された、権限移譲先のDS６３と、アクセス情報要求対象のデバイス６１が、権限移譲元のApp装置６２と紐づけられていることを確認する。そして、管理サーバ６０は、要求元のDS６３と、そのアクセス先のデバイス６１間で使用するアクセス情報を送信する。ここで取得されるアクセス情報には、図１２及び図１３のAppControlオブジェクトと同様の例が適用できる。
　ステップＳ１２５において、管理サーバ６０は、DeviceControlオブジェクトを各デバイス６１へ送信することにより、各デバイス６１がDS６３と通信するためのアクセス情報を各デバイス１１へ送信する。管理サーバ６０からデバイス６１Aへ供給されるDeviceControlオブジェクトの例は、NICE　Version 1.0.1の第１のアクセス制御処理で説明した図１７のDeviceControlオブジェクトと同様の例が適用できる。
　各App装置６２は、ステップＳ１２６において、DS６３に対し、動作指示情報として、SceneModeオブジェクトを送信し、動作を指示する。例えば、DS６３が、ステップＳ１２１で取得したDeviceControlオブジェクトに列挙されている各App装置６２に対してGetAppControlを呼ぶことにより、各App装置６２は、SceneModeオブジェクトをDS６３へ送信する。SceneModeオブジェクトの取得により、DS６３は、デバイス６１－App装置６２－SceneModeの対応関係を認識することができる。
　DS６３は、ステップＳ１２７において、各App装置６２から供給されたアクセス情報、及び、動作指示情報に基づいて、各デバイス６１に対し、動作指示情報として、SceneModeオブジェクトを送信し、動作を指示する。より具体的には、デバイス６１Aに対しては、デバイス６１A－App装置６２X－SceneModeの対応関係と、デバイス６１A－App装置６２Y－SceneModeの対応関係に従った動作が指示される。デバイス６１Bに対しては、デバイス６１B－App装置６２X－SceneModeの対応関係に従った動作が指示され、デバイス６１Cに対しては、デバイス６１C－App装置６２Y－SceneModeの対応関係に従った動作が指示される。
　ステップＳ１２８において、各デバイス６１は、SceneModeオブジェクトに基づく動作、例えば、人検出や動体検出等の動作を実行し、検出結果としてのデータを、SetSceneDataまたはSetSceneMarkを用いて送信する。
　ステップＳ１２９において、DS６３は、各デバイス６１から送信されてきたデータを取得するとともに、データの送り先となるApp装置６２を決定し、ステップＳ１３０において、決定したApp装置６２へ、SetSceneDataまたはSetSceneMarkを用いてデータを送信する。
　図１８のSceneMarkや図１９のDataSectionのように、データを送信するオブジェクトに、どの動作指示（SceneModeオブジェクト）に基づいて検出されたデータであるかを示す動作指示識別情報が含まれる点は、上述した第１のアクセス制御方法と同様である。
　NICE　Version 1.0.1の場合のデータ処理システム５１による第２のアクセス制御方法は、以上のように行われる。
＜７．第２のアクセス制御方法（NICE　Version 1.1の場合）＞
　次に、図２６を参照して、NICE　Version 1.1の場合の第２のアクセス制御方法の概要について説明する。図２６では、既存のNICE　Version 1.1からの変更点について説明する。
　既存のNICE　Version 1.1では、管理サーバ１０は、ユーザアカウントに紐づけてデバイス１１とApp装置１２を管理しているが、デバイス１１とApp装置１２とを直接紐づける情報は有していない。そこで、第２のアクセス制御方法を実行する管理サーバ６０は、ユーザアカウントに紐づけてデバイス６１とApp装置６２を管理するとともに、デバイス６１とApp装置６２とを紐づけて管理する。換言すれば、デバイス６１とApp装置６２との対応関係については、管理サーバ６０は、NICE　Version 1.0.1と同様に管理する。
　第２のアクセス情報では、管理サーバ６０から各デバイス６１及び各App装置６２へ提供されるAppControlオブジェクトやDeviceControlオブジェクトについては、既存のNICE　Version 1.0.1と同様である。
　第２のアクセス制御方法では、上述した第１のアクセス制御方法との相違点として、各App装置６２は、自身に紐づけられているデバイス６１の一覧であるデバイスリスト（DeviceListオブジェクト）をDS６３へ提供する。このデバイスリストは、既存のNICE　Version 1.0.1において、管理サーバ６０から各App装置６２へ供給されるDeviceListオブジェクトとは異なるものである。
　DS６３は、各App装置６２から提供されるデバイスリスト（DeviceListオブジェクト）を参照し、そのデバイス６１に接続するためのアクセス情報を、管理サーバ６０へ要求する。管理サーバ６０は、DS６３からの要求に応じて、DS６３がデバイス６１へ接続するためのアクセス情報をDS６３へ送信する。このアクセス情報は、例えば、NICE　Version 1.0.1におけるAppControlオブジェクトに相当し、既存のAppControlオブジェクトを変更して使用することができる。
　DPC６４は、デバイス６１またはDS６３からの要求に応じて、動作指示情報であるSceneModeオブジェクトをデバイス６１またはDS６３へ送信する。このとき、DPC６４は、DS６３に対して、App装置６２毎にSceneModeオブジェクトを送信する。
（NICE　Version 1.1の場合の第２のアクセス制御フロー）
　図２７のフローチャートを参照して、NICE　Version 1.1の場合のデータ処理システム５１による第２のアクセス制御処理を説明する。
　初めに、ステップＳ１４１において、管理サーバ６０は、各エンティティからの要求に応じて、制御用情報を、各エンティティ、すなわち、デバイス６１A乃至６１C、App装置６２X及び６２Y、並びに、DS６３に送信する。具体的には、図２を参照して説明したように、デバイス６１A乃至６１CにはDeviceControlオブジェクトが提供され、App装置６２X及び６２YにはAppControlオブジェクトが提供される。DS６３には、AppControlオブジェクトとDeviceControlオブジェクトが提供される。ここで、App装置６２X及び６２Yに提供されるAppControlオブジェクトには、App装置６２がDS６３と通信するための情報だけでなく、DS６３が、App装置６２の下請けとして通信する相手であるデバイス６１と通信するための情報も含まれる。
　ステップＳ１４１において、管理サーバ６０からApp装置６２Xに対して制御用情報として供給されるAppControlオブジェクトとして、図１１に示したAppControlオブジェクトの例が適用できる。DS６３が、管理サーバ６０から供給されるDeviceControlオブジェクトとして、各App装置６２のManagement I/Fと通信するための情報を含む図１５または図１６のDeviceControlオブジェクトの例が適用できる。
　ステップＳ１４２において、App装置６２Xは、DS６３に権限移譲したいデバイス６１の一覧であるデバイスリスト（DeviceListオブジェクト）をDS６３へ送信する。同様に、App装置６２Yは、ステップＳ１４２において、DS６３に権限移譲したいデバイス６１の一覧であるデバイスリスト（DeviceListオブジェクト）をDS６３へ送信する。App装置６２Xからのデバイスリストには、デバイス６１Aとデバイス６１Bが列挙され、App装置６２Yからのデバイスリストには、デバイス６１Aとデバイス６１Cが列挙される。DS６３へ提供されるデバイスリストとして、図２５に示したDeviceListオブジェクトの例が適用できる。
　ステップＳ１４３において、DS６３は、デバイスリストに記載された、権限移譲対象であるデバイス６１に対するアクセス情報の発行を、管理サーバ６０に要求する。ステップＳ１４３のアクセス情報の発行要求には、NICE　Version 1.0.1の第１のアクセス制御処理で説明した図１２のGetAppControlの例が適用できる。
　ステップＳ１４４において、管理サーバ６０は、自身が管理している紐づけ情報を参照し、DS６３からのアクセス情報発行要求コマンドに記載された、権限移譲先のDS６３と、アクセス情報要求対象のデバイス６１が、権限移譲元のApp装置６２と紐づけられていることを確認する。そして、管理サーバ６０は、要求元のDS６３と、そのアクセス先のデバイス６１間で使用するアクセス情報を送信する。
　ステップＳ１４５において、管理サーバ６０は、各デバイス６１からのリクエストに応じてDeviceControlオブジェクトを送信することにより、各デバイス６１がDS６３と通信するためのアクセス情報を各デバイス１１へ送信する。管理サーバ６０からデバイス６１Aへ供給されるDeviceControlオブジェクトの例は、図１７のDeviceControlオブジェクトの例が適用できる。
　ステップＳ１４５の後、ステップＳ１４６において、各デバイス６１は、動作指示情報としてのSceneModeオブジェクトをDPC６４にリクエストし、DPC６４からSceneModeオブジェクトを取得する。DPC６４は、各デバイス６１からのリクエストに応じてSceneModeオブジェクトを送信することにより、動作を指示する。
　続いて、ステップＳ１４７において、DS６３は、動作指示情報としてのSceneModeオブジェクトをDPC６４にリクエストし、DPC６４からSceneModeオブジェクトを取得する。DPC６４は、DS６３からのリクエストに応じてSceneModeオブジェクトを送信することにより、動作を指示する。このとき、DS６３は、App装置６２毎にSceneModeオブジェクトを送信する。例えば、DS６３は、図２２で示したApp装置６２を指定したGetSceneModeをDPC６４へ送信することにより、App装置６２毎のSceneModeオブジェクトを取得する。
　DS６３は、ステップＳ１４１による管理サーバ６０からの制御用情報、ステップＳ１４４における各App装置６２からのアクセス情報、及び、ステップＳ１４７における動作指示情報を取得することにより、デバイス６１－App装置６２－SceneModeの対応関係を認識することができる。
　ステップＳ１４８において、各デバイス６１は、SceneModeオブジェクトに基づく動作、例えば、人検出や動体検出等の動作を実行し、検出結果としてのデータを、SetSceneDataまたはSetSceneMarkを用いて送信する。
　ステップＳ１４９において、DS６３は、各デバイス６１から送信されてきたデータを取得するとともに、データの送り先となるApp装置６２を決定し、ステップＳ１５０において、決定したApp装置６２へ、SceneDataまたはSceneMarkを用いてデータを送信する。図１８のSceneMarkや図１９のDataSectionのように、データを送信するオブジェクトに、どの動作指示（SceneModeオブジェクト）に基づいて検出されたデータであるかを示す動作指示識別情報が含まれる点は、上述したNICE　Version 1.0.1と同様である。
　NICE　Version 1.1の場合のデータ処理システム５１による第２のアクセス制御方法は、以上のように行われる。
　以上のように、第２のアクセス制御方法では、DS６３は、App装置６２に紐づいているデバイス６１へDS６３が接続するためのアクセス情報を、管理サーバ６０から直接取得する。DS６３は、App装置６２からデバイスリスト（DeviceListオブジェクト）を取得することにより、そのApp装置６２と紐づけられているデバイス６１を認識することができ、App装置６２とデバイス６１との対応関係を認識し、そのデバイス６１へDS６３が接続するためのアクセス情報を、管理サーバ６０から直接取得する。
＜８．複数のDSが介在する場合＞
　次に、デバイス６１とApp装置６２との間に介在するDS６３が、複数存在する場合について説明する。
　NICE規格では、デバイス６１とApp装置６２との間に介在するDS６３が、複数存在する場合も考えられる。そのような場合に、上述した第１のアクセス制御方法及び第２のアクセス制御方法において、どのように対応可能であるかについて説明する。
（NICE　Version 1.0.1の場合）
　図２８は、NICE　Version 1.0.1の場合に、デバイス６１とApp装置６２との間に、DS６３A及び６３Bの２つのDS６３が介在し、上述した第１のアクセス制御方法で制御する場合を説明する図である。
　NICE　Version 1.0.1の場合、上述した第１のアクセス制御方法では、App装置６２が、自身に紐づいているデバイス６１とApp装置６２のアクセス情報（AppControlオブジェクト）を管理サーバ６０から取得し、自身に紐づけられているデバイス６１にDS６３が接続するためのアクセス情報を、App装置６２からDS６３へ送信する。また、App装置６２は、動作指示情報であるSceneModeオブジェクトをDS６３へ送信し、動作を指示する。
　したがって、DS６３Aには、App装置６２Xまたは６２Yから、AppControlオブジェクト及びSceneModeオブジェクトにより、App装置６２に紐づけられているデバイス６１のアクセス情報及び動作指示情報が供給される。同様に、DS６３Bには、DS６３Aから、AppControlオブジェクト及びSceneModeオブジェクトにより、App装置６２に紐づけられているデバイス６１のアクセス情報及び動作指示情報が供給される。
　このとき、DS６３Bが、各デバイス６１から取得したデータを、App装置６２X用のデータと、App装置６２Y用のデータを識別して、DS６３Aに送信することができる必要がある。また、DS６３Aが、DS６３Bから取得したデータを、App装置６２X用のデータと、App装置６２Y用のデータを識別して、App装置６２XまたはApp装置６２Yに送信することができる必要がある。
（NICE　Version 1.1の場合）
　図２９は、NICE　Version 1.1の場合に、デバイス６１とApp装置６２との間に、DS６３A及び６３Bの２つのDS６３が介在し、上述した第１のアクセス制御方法で制御する場合を説明する図である。
　NICE　Version 1.1の場合、上述した第１のアクセス制御方法では、App装置６２が、自身に紐づいているデバイス６１とApp装置６２のアクセス情報（AppControlオブジェクト）を管理サーバ６０から取得し、自身に紐づけられているデバイス６１にDS６３が接続するためのアクセス情報を、App装置６２からDS６３へ送信する。また、動作指示情報であるSceneModeオブジェクトについては、DPC６４から、DS６３へ供給される。
　したがって、DS６３Aには、App装置６２Xまたは６２Yから、AppControlオブジェクトにより、App装置６２に紐づけられているデバイス６１のアクセス情報が供給される。同様に、DS６３Bには、DS６３Aから、AppControlオブジェクトにより、App装置６２に紐づけられているデバイス６１のアクセス情報が供給される。また、DS６３Aには、DPC６４から、SceneModeオブジェクトにより、動作指示情報が供給される。同様に、DS６３Bには、DPC６４から、SceneModeオブジェクトにより、動作指示情報が供給される。
　このとき、DS６３Bが、各デバイス６１から取得したデータを、App装置６２X用のデータと、App装置６２Y用のデータを識別して、DS６３Aに送信することができる必要がある。また、DS６３Aが、DS６３Bから取得したデータを、App装置６２X用のデータと、App装置６２Y用のデータを識別して、App装置６２XまたはApp装置６２Yに送信することができる必要がある。
（NICE　Version 1.0.1の場合）
　図３０は、NICE　Version 1.0.1の場合に、デバイス６１とApp装置６２との間に、DS６３A及び６３Bの２つのDS６３が介在し、上述した第２のアクセス制御方法で制御する場合を説明する図である。
　NICE　Version 1.0.1の場合、上述した第２のアクセス制御方法では、App装置６２が、自身に紐づけられているデバイス６１の一覧であるデバイスリスト（DeviceListオブジェクト）をDS６３に送信する。また、App装置６２は、動作指示情報であるSceneModeオブジェクトをDS６３へ送信し、動作を指示する。DS６３は、デバイスリストを参照して、アクセス情報を管理サーバ６０へ要求し、管理サーバ６０から、DS６３がデバイス６１へ接続するためのアクセス情報（AppControlオブジェクト）を取得する。
　したがって、DS６３Aには、App装置６２Xまたは６２Yから、DeviceListオブジェクトにより、デバイス６１の一覧が供給されるとともに、動作指示情報であるSceneModeオブジェクトが供給される。また、管理サーバ６０からDS６３Aへ、DS６３Aがデバイス６１へ接続するためのアクセス情報（AppControlオブジェクト）が供給される。同様に、DS６３Bには、DS６３Aから、DeviceListオブジェクトによりデバイス６１の一覧が供給されるとともに、動作指示情報であるSceneModeオブジェクトが供給される。また、管理サーバ６０からDS６３Bへ、DS６３Bがデバイス６１へ接続するためのアクセス情報（AppControlオブジェクト）が供給される。
　このとき、DS６３Bが、各デバイス６１から取得したデータを、App装置６２X用のデータと、App装置６２Y用のデータを識別して、DS６３Aに送信することができる必要がある。また、DS６３Aが、DS６３Bから取得したデータを、App装置６２X用のデータと、App装置６２Y用のデータを識別して、App装置６２XまたはApp装置６２Yに送信することができる必要がある。
（NICE　Version 1.1の場合）
　図３１は、NICE　Version 1.1の場合に、デバイス６１とApp装置６２との間に、DS６３A及び６３Bの２つのDS６３が介在し、上述した第２のアクセス制御方法で制御する場合を説明する図である。
　NICE　Version 1.1の場合、上述した第２のアクセス制御方法では、App装置６２は、自身に紐づけられているデバイス６１の一覧であるデバイスリスト（DeviceListオブジェクト）をDS６３へ提供する。DS６３は、各App装置６２から提供されるデバイスリスト（DeviceListオブジェクト）を参照し、そのデバイス６１に接続するためのアクセス情報（AppControlオブジェクト）を管理サーバ６０へ要求し、管理サーバ６０から取得する。また、動作指示情報であるSceneModeオブジェクトについては、DPC６４から、DS６３へ供給される。
　したがって、DS６３Aには、App装置６２Xまたは６２Yから、デバイスリスト（DeviceListオブジェクト）が供給され、管理サーバ６０からアクセス情報（AppControlオブジェクト）が供給される。また、DS６３Aには、DPC６４から、SceneModeオブジェクトにより動作指示情報が供給される。同様に、DS６３Bには、DS６３Aから、デバイスリスト（DeviceListオブジェクト）が供給され、管理サーバ６０からアクセス情報（AppControlオブジェクト）が供給される。また、DS６３Bには、DPC６４から、SceneModeオブジェクトにより動作指示情報が供給される。
　このとき、DS６３Bが、各デバイス６１から取得したデータを、App装置６２X用のデータと、App装置６２Y用のデータを識別して、DS６３Aに送信することができる必要がある。また、DS６３Aが、DS６３Bから取得したデータを、App装置６２X用のデータと、App装置６２Y用のデータを識別して、App装置６２XまたはApp装置６２Yに送信することができる必要がある。
　図３２は、NICE　Version 1.0.1とNICE　Version 1.1のそれぞれにおいて、第１のアクセス制御方法及び第２のアクセス制御方法でアクセス情報（AppControlオブジェクト）と動作指示情報（SceneModeオブジェクト）が提供される提供元をまとめたテーブルである。
　アクセス情報（AppControlオブジェクト）と動作指示情報（SceneModeオブジェクト）は、App装置６２Xに対応するものと、App装置６２Yに対応するものと２組が提供されるため、各App装置６２に対応するアクセス情報と動作指示情報の組み合わせを正しく保つことが必要となる。
　そこで、第１のアクセス制御方法及び第２のアクセス制御方法では、動作指示情報（SceneModeオブジェクト）に、その情報がどのApp装置６２に対応するものであるのか、具体的にはApp装置６２Xに対応するものであるのか、または、App装置６２Yに対応するものであるのかを識別する情報を含めて指示するように構成することができる。
　具体的には、図３３に示されるように、既存のSceneModeオブジェクトに、App装置６２を識別する識別情報（装置識別情報）である“AppInstanceID”と、データパイプラインの識別情報（データパイプライン識別情報）である“DataPipelineID”が追加される。単一のApp装置６２に対して、データパイプラインが１つしかない場合には、データパイプライン識別情報は省略することができ、装置識別情報のみでもよい。これにより、DS６３A及びDS６３Bは、App装置６２XまたはApp装置６２Yにどのようなデータを送信するのか認識することができるので、App装置６２X用のデータと、App装置６２Y用のデータを識別して、上位の装置へ送信することができる。
＜９.第１実施の形態に係るデータ処理システムのまとめ＞
　第１実施の形態に係るデータ処理システム５１において、各デバイス６１は、センサにより取得されたデータをそのまま、あるいは、所定のデータ処理を実行した後、DS６３へ送信する。DS６３は、デバイス６１とApp装置６２との紐づけ情報を取得し、取得した紐づけ情報に基づいて、１つ以上のデバイス６１から取得したデータの送り先を決定し、送り先として決定された１つ以上のApp装置６２に送信する。上述した第１のアクセス制御方法では、デバイス６１とApp装置６２との紐づけ情報が、App装置６２から取得される。一方、上述した第１のアクセス制御方法では、デバイス６１とApp装置６２との紐づけ情報が、管理サーバ６０から取得される。これにより、デバイス６１とApp装置６２との間に介在するDS６３が、デバイス６１からのデータを複数のApp装置６２に適切に提供することができる。
＜１０.第２実施の形態に係るデータ処理システム＞
　上述したデータ処理システム５１では、図３４に示されるように、デバイス６１からDS６３へデータが転送され、DS６３からApp装置６２へデータが転送されるデータパイプラインが構成されていた。データパイプラインとは、NICE規格で定義されたData APIにより、エンティティ間を流れるデータの流れである。Data APIとは、データ転送のためのAPIであり、上述したSetSceneDataやSetSceneMarkである。
　現在のNICE規格の通信インターフェースでは、セキュリティの対策として、TLSによる伝送路保護と、OAuth2ベースのアクセストークンによるクライアント認証が規定されている。具体的には、エンティティ間のTLS通信ではサーバ認証のみが行われ、クライアント認証についてはTLSのレイヤでは行わず、NICEのアプリケーションレイヤで規定されるアクセストークンを使用することで実現されている。アクセストークンは上述したようにSceneModeオブジェクトで送信側に配信され、Data APIであるSetSceneMarkやSetSceneDataのパラメータにアクセストークンがセットされる。サーバ側のエンティティは、アクセストークン内のクレーム（送信先、送信元等の記述内容）をチェックしてクライアントを認証する。
　しかしながら、Data APIであるSetSceneMarkやSetSceneDataを使用したデータ送信では、デバイス６１からApp装置６２またはDS６３への片方向のデータ通信しか定義されておらず、双方向のデータ通信の認証方法については明確に規定されていない。将来のNICE規格においては、双方向のデータ通信も必要になることが考えられるため、以下において、双方向のデータ通信の認証方法について提案する。
　図３５は、本開示の第２実施の形態に係るデータ処理システムであって、双方向のデータ通信の認証方法を実現するデータ処理システムの構成例を示すブロック図である。
　図３５に示されるデータ処理システム２００は、デバイス２１１、DS２１２、及び、App装置２１３と、管理サーバ２２１、及び、DPC２２２とを含む。
　デバイス２１１、DS２１２、及び、App装置２１３は、データパイプラインを構成するエンティティであり、上述したデータ処理システム５１のデバイス６１、DS６３、App装置６２に対応する。ただし、エンティティ間のデータ送信の際の認証において、クライアント側のエンティティと、サーバ側のエンティティの双方の認証（相互認証）を実現した点で、上述したデータ処理システム５１のエンティティや、現在のNICE規格のエンティティと異なる。
　管理サーバ２２１は、上述した管理サーバ６０と同様に、ユーザアカウントに紐づけてデバイス６１とApp装置６２を管理する。また、管理サーバ２２１は、DeviceControlオブジェクトをデバイス２１１へ送信する機能、AppControlオブジェクト及びDeviceControlオブジェクトをDS２１２へ送信する機能、AppControlオブジェクトをApp装置２１３へ送信する機能を備えている。以下では、AppControlオブジェクト及びDeviceControlオブジェクトを、Controlオブジェクトと総称する。
　さらに、管理サーバ２２１は、デバイス２１１、DS２１２、及び、App装置２１３の各エンティティに、TLS（Transport Layer Security）通信に必要な証明書群を発行する機能を有している。具体的には、図３６に示されるように、管理サーバ２２１は、自身のTLSルート証明書、TLSサーバ証明書、TLSクライアント証明書を発行することができる。現在のNICE規格のシステムは、公開鍵暗号を用いたX.509証明書を発行する仕組みを有しているため、この仕組みを拡張して、管理サーバ２２１が、自身のTLSルート証明書、TLSサーバ証明書、TLSクライアント証明書を発行する。管理サーバ２２１は、各エンティティに対して、自身のTLSルート証明書を配布する。また、管理サーバ２２１は、発行したTLSクライアント証明書及びTLSサーバ証明書をDPC２２２へ提供（送信）する。
　上述したデータ処理システム５１では、管理サーバ６０は、NICE規格におけるNICE LA/AS（License Authority and NICE Account Service）に対応するものとして説明したが、データ処理システム２００の管理サーバ２２１は、NICE ASのみに対応するものであればよい。勿論、管理サーバ２２１がNICE LA/ASに対応するものであってもよい。
　DPC２２２は、上述したDPC６４と同様に、デバイス２１１及びDS２１２にSceneModeオブジェクトを送信することにより、デバイス２１１及びDS２１２の動作を指示する。また、DPC２２２は、動作を指示する立場にあることから、２つのエンティティがデータの通信を行う場合に、２つのエンティティのどちらがクライアント側のエンティティとなり、どちらがサーバ側のエンティティとなるかを把握している。そのため、DPC２２２は、各エンティティの役割に応じて、管理サーバ２２１から取得したTLSクライアント証明書またはTLSサーバ証明書を配布（送信）する。クライアント側のエンティティに対してはTLSクライアント証明書が配布され、サーバ側のエンティティに対してはTLSサーバ証明書が配布される。エンティティがクライアント側とサーバ側の両方となり得る場合には、TLSクライアント証明書とTLSサーバ証明書の両方が配布される。エンティティの役割が決定されると、SetSceneMarkやSetSceneDataのData APIを使用して、データが、クライアント側のエンティティからサーバ側のエンティティへ送信される。
　図３７を参照して、デバイス２１１とDS２１２のエンティティ間でデータ通信を行う場合を例に、エンティティへのTLS証明書の配布を説明する。図３７の例では、データがデバイス２１１からDS２１２へ送信されることとする。
　デバイス２１１とDS２１２の各エンティティは、起動時に管理サーバ２２１に接続し、管理サーバ２２１からControlオブジェクトを受信する。受信するControlオブジェクトに関して、具体的には、クライアント側エンティティはAppControlオブジェクトを受信し、サーバ側エンティティはDeviceControlオブジェクトを受信する。Controlオブジェクトには、AllowedTLSRootCertificatesというプロパティが存在する。管理サーバ２２１は、ControlオブジェクトのAllowedTLSRootCertificatesプロパティに、自身のTLSルート証明書をセットし、デバイス２１１とDS２１２に送信することで、TLS通信に必要なTLSルート証明書をデバイス２１１とDS２１２に配布する。
　また、デバイス２１１とDS２１２の各エンティティは、DPC２２２から、SceneModeオブジェクトを受信することにより、動作指示を取得する。SceneModeオブジェクトには、データの送信先を指定するためのEndPointというプロパティが存在する。DPC２２２は、EndPointプロパティに、クライアント側エンティティ（TLSクライアント）またはサーバ側エンティティ（TLSサーバ）の役割を示す識別子と、その役割に応じた証明書（すなわちTLSサーバ証明書またはTLSクライアント証明書）をセットし、デバイス２１１とDS２１２に送信することで、TLSサーバ証明書またはTLSクライアント証明書をデバイス２１１とDS２１２に配布する。いまの例では、データはデバイス２１１からDS２１２へ送信されるので、デバイス２１１のSceneModeオブジェクトのEndPointプロパティには、クライアント側エンティティ（TLSクライアント）の役割を示す識別子と、TLSクライアント証明書がセットされる。一方、DS２１２のSceneModeオブジェクトのEndPointプロパティには、サーバ側エンティティ（TLSサーバ）の役割を示す識別子と、TLSサーバ証明書がセットされる。EndPointプロパティに、クライアント側エンティティ（TLSクライアント）またはサーバ側エンティティ（TLSサーバ）の役割を示す識別子と、その役割に応じたTLSサーバ証明書またはTLSクライアント証明書が含まれたSceneModeオブジェクトは、現在のNICE規格には存在しないため、新たな機能である。
＜１１．認証処理のフローチャート＞
　図３８のフローチャートを参照して、TLSサーバ証明書及びTLSクライアント証明書の配布と、配布された証明書を用いてTLS相互認証を行う認証処理について説明する。この処理は、例えば、デバイス２１１とDS２１２が起動したときに開始される。
　初めに、ステップＳ２０１において、管理サーバ２２１は、デバイス２１１からのリクエストに応じてDeviceControlオブジェクトをデバイス２１１に送信する。DeviceControlオブジェクトのAllowedTLSRootCertificatesプロパティには、TLSルート証明書が含まれている。また、ステップＳ２０１において、管理サーバ２２１は、DS２１２からのリクエストに応じてDeviceControlオブジェクトをDS２１２に送信する。DeviceControlオブジェクトのAllowedTLSRootCertificatesプロパティには、TLSルート証明書が含まれている。
　ステップＳ２０２において、DPC２２２は、デバイス２１１からのリクエストに応じてSceneModeオブジェクトをデバイス２１１に送信する。デバイス２１１へ送信されるSceneModeオブジェクトのEndPointプロパティには、クライアント側エンティティ（TLSクライアント）の役割を示す識別子とTLSクライアント証明書とが含まれている。また、ステップＳ２０２において、DPC２２２は、DS２１２からのリクエストに応じてSceneModeオブジェクトをDS２１２に送信する。DS２１２へ送信されるSceneModeオブジェクトのEndPointプロパティには、サーバ側エンティティ（TLSサーバ）の役割を示す識別子とTLSサーバ証明書とが含まれている。
　ステップＳ２０３において、デバイス２１１とDPC２２２は、自身が保持するTLSルート証明書と、TLSクライアント証明書またはTLSサーバ証明書とを用いて、TLS相互認証を行う。具体的には、TLSクライアントであるデバイス２１１は、DPC２２２に対してサーバ証明書を要求して、取得したサーバ証明書を、TLSルート証明書を用いて検証し、DPC２２２を認証する。次に、TLSサーバであるDPC２２２は、TLSクライアントであるデバイス２１１対してTLSクライアント証明書を要求して、取得したTLSクライアント証明書を、TLSルート証明書を用いて検証し、デバイス２１１を認証する。
　TLS相互認証が終了し、デバイス２１１とDPC２２２が互いに認証されると、共通鍵で暗号化されたTLS通信路で、クライアント側エンティティからサーバ側エンティティへ、SetSceneMarkやSetSceneDataを用いてデータが送信される。
　ところで、NICE規格におけるデータパイプラインの構成として、図３９に示されるように、デバイス２１１Aとデバイス２１１Bの２つのデバイス２１１が直列に接続され、SetSceneMarkやSetSceneDataを用いて、データが、デバイス２１１A、デバイス２１１B、DS２１２、App装置２１３の順に転送されるデータパイプラインの構成も取り得る。
　あるいはまた、図４０に示されるように、デバイス２１１Aとデバイス２１１Bのデバイス間で双方向にデータ通信を行う場合も考えられる。
　図４０に示されるように、デバイス２１１Aとデバイス２１１Bが双方向のデータ通信を行う場合、デバイス２１１Aとデバイス２１１Bの各々は、TLSクライアントとTLSサーバの両方の役割を持つことになる。デバイス２１１Aとデバイス２１１Bの各々がTLSクライアント及びTLSサーバのいずれにもなる場合、図３８で説明した認証処理のステップＳ２０２において、DPC２２２は、SceneModeオブジェクトのEndPointプロパティに、TLSクライアントの役割を示す識別子とTLSサーバの役割を示す識別子の合計２つの識別子と、TLSクライアント証明書とTLSサーバ証明書の両方を含めて、デバイス２１１A及び１１Bそれぞれに送信すればよい。これにより、現在のNICE規格では規定されていない双方向のデバイス間通信を実現することができる。
＜１２.第２実施の形態に係るデータ処理システムのまとめ＞
　以上のように、第２実施の形態に係るデータ処理システム２００では、DPC２２２が、データを通信する２つのエンティティに、SceneModeオブジェクトを用いて、TLSクライアントまたはTLSサーバの役割を識別する少なくとも一つの識別子と、その識別子に応じたTLS証明書を送信する。２つのエンティティは、データ通信の際のエンティティ間の認証に、SceneModeオブジェクトに含まれるTLS証明書を用いてTLS相互認証を行う。これにより、TLSのセッション確立時に認証が完了するため、現在のNICE規格で行われている、OAuth2ベースのアクセストークンにおるクライアント認証が不要となり、エンティティ間の双方向のデータ通信の相互認証が容易となる。
　なお、上述した例では、NICE規格の現在のSceneModeオブジェクトを変更して、TLSクライアント証明書またはTLSサーバ証明書の少なくとも一方と、TLSクライアントまたはTLSサーバの役割を示す識別子の少なくとも一方を、SceneModeオブジェクトに格納してエンティティに配布する例を説明した。しかしながら、証明書と識別子の配布方法は、SceneModeオブジェクトに限定されず、その他のオブジェクトを用いてもよい。例えば、TLSクライアントまたはTLSサーバの証明書と識別子を格納して配布するオブジェクトを新たに定義し、使用してもよい。
　データ処理システム２００において、管理サーバ２２１がTLSルート証明書を配布し、DPC２２２がTLSクライアント証明書及びTLSサーバ証明書を配布する構成としたが、一つの装置が、TLSルート証明書、TLSクライアント証明書、及び、TLSサーバ証明書を配布する構成としてもよい。換言すれば、管理サーバ２２１とDPC２２２は、物理的には一つの装置で構成してもよい。
＜１３．ハードウェア構成例＞
　次に、上述した第１実施の形態に係るデータ処理システム５１、または、第２実施の形態に係るデータ処理システム２００を構成するエンティティのハードウェア構成例について説明する。
　図４１は、データ処理システム５１のデバイス６１、または、データ処理システム２００のデバイス２１１として利用することができるデバイス（デバイス装置）３００の構成例を示すブロック図である。
　デバイス３００は、センサ部３２１と、処理部３２２と、記憶部３２３と、通信部３２４とを備えている。
　センサ部３２１は、センシングデータを取得し、取得したセンシングデータを処理部３２２に出力する。例えば、デバイス３００が撮像装置である場合、センサ部３２１は、被写体から発せられる光を集光する撮影レンズ及びズームレンズ等の撮像光学系、及び、CCD(Charge Coupled Device)イメージセンサやCMOS(Complementary Metal Oxide Semiconductor)イメージセンサ等の撮像素子を有する。
　また、センサ部３２１は、被写体認識機能を有して構成される場合もある。例えば、被写体認識機能として、撮像された物体の種類を認識する機能を有する場合には、センサ部３２１は、認識結果を示す情報をセンシングデータとして出力する場合もある。例えば、センサ部３２１は、認識した物体の種類を表すテキストデータをセンシングデータとして出力する。あるいは、被写体認識機能としては、指定された物体の数をカウントする機能や、特定の状態にある人物の数（例えば、話をしている状態の人物の数等）をカウントする機能を有してもよい。この場合には、センシングデータとして物体数や人数を表すテキストデータを出力してもよい。
　また、センサ部３２１としては、撮像装置の他にも、深度センサ（測距センサ）としてToF（Time of Flight）センサを含んでいてもよい。ToFセンサは、被写体からの反射光の戻り時間を直接的又は間接的に計測することにより、ToFセンサと被写体との間の距離及び凹凸等の形状情報（深度情報／画像）を取得することができる。
　また、センサ部３２１としては、IR(赤外線)カメラ、GNSS(GlobalNavigation Satellite System)センサ等の測位センサや、温度センサ、収音装置（マイクロフォン）、気圧センサ、湿度センサ、風向風速センサ、日照センサ、降水量センサ、水位センサ、震度センサ（地震の震度を検出するセンサ）等を含んでもよい。センサ部３２１は、周囲環境（センシング環境）からセンシングデータを取得することができれば、特に限定されるものではない。なお、センサ部３２１は、デバイス３００内に固定されて設けられてもよく、デバイス３００に対して脱着可能に設けられてもよい。
　処理部３２２は、例えば、CPUやGPU(Graphics Processing Unit)等の処理回路や、ROM、RAM等を有するマイクロコンピュータにより構成されている。この処理部３２２は、例えば、ROM等の記憶装置に記憶されたプログラムに基づく処理を実行することで、デバイス３００の全体制御を行う制御部として機能する。また、処理部３２２は、センサ部３２１が取得したセンシングデータを処理し、送信データを生成する機能を有している。
　記憶部３２３は、処理部３２２が各種処理を実行するためのプログラムや情報、また、処理によって得た情報を格納する。例えば、記憶部３２３は、センサ部３２１が出力する情報、一例として、センシングデータの一時的な記憶に用いることができる。なお、記憶部３２３は、例えば、SSD(Solid State Drive)やHDD(Hard Disk Drive)等の記憶装置により実現される。
　通信部３２４は、他のエンティティである外部装置との間でデータの送受信を行うことができる。この通信部３２４は、例えば、データの送受信を行う機能を有する通信インターフェースである。
　なお、処理部３２２等の各機能部は、前述のように、ハードウェア及びソフトウェアの両方又は一方により構成されてもよい。それらの構成は、特に限定されるものではない。例えば、前述の各機能部は、CPUやMPU等のコンピュータによって、ROMに予め記憶されたプログラムがRAM等を作業領域として実行されることにより実現されてもよい。また、各機能部は、例えば、ASICやFPGA等の集積回路により実現されてもよい。
　図４２は、データ処理システム５１の管理サーバ６０、App装置６２、DS６３、または、DPC６４や、データ処理システム２００のDS２１２、App装置２１３、管理サーバ２２１、または、DPC２２２として利用することができる情報処理装置としてのコンピュータ５００のハードウェアの構成例を示すブロック図である。
　コンピュータ５００において、CPU（Central Processing Unit）５０１、ROM（Read Only Memory）５０２、RAM（Random Access Memory）５０３は、バス５０４により相互に接続されている。バス５０４には、さらに、入出力インターフェース５０５が接続されている。入出力インターフェース５０５には、入力部５０６、出力部５０７、記憶部５０８、通信部５０９、及びドライブ５１０が接続されている。
　入力部５０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部５０７は、ディスプレイ、スピーカなどよりなる。記憶部５０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部５０９は、ネットワークインターフェースなどよりなる。ドライブ５１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体５１１を駆動する。
　以上のように構成されるコンピュータ５００では、CPU５０１が、例えば、記憶部５０８に記憶されているプログラムを、入出力インターフェース５０５及びバス５０４を介して、RAM５０３にロードして実行することにより、上述した一連の処理が行われる。CPU５０１は、コンピュータ５００が情報処理装置として動作する場合の制御部として機能する。RAM５０３にはまた、CPU５０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
　コンピュータ５００（のCPU５０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体５１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
　コンピュータ５００では、プログラムは、リムーバブル記録媒体５１１をドライブ５１０に装着することにより、入出力インターフェース５０５を介して、記憶部５０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部５０９で受信し、記憶部５０８にインストールすることができる。その他、プログラムは、ROM５０２や記憶部５０８に、あらかじめインストールしておくことができる。
　なお、コンピュータ５００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
　なお、本明細書において、フローチャートに記述されたステップは、記載された順序に沿って時系列的に行われる場合はもちろん、必ずしも時系列的に処理されなくとも、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで実行されてもよい。
　また、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
　本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の技術の要旨を逸脱しない範囲において種々の変更が可能である。
　例えば、上述した複数の実施の形態の全てまたは一部を組み合わせた形態を採用することができる。
　例えば、本開示の技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
　また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。
　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、本明細書に記載されたもの以外の効果があってもよい。
　なお、本開示の技術は、以下の構成を取ることができる。
（１）
　データを出力するデバイスと、前記データを用いた所定のデータ処理を行うアプリケーション装置との紐づけ情報を、複数の前記アプリケーション装置について取得し、取得した紐づけ情報に基づいて、１つ以上の前記デバイスから取得した前記データの送り先を決定し、送り先として決定された１つ以上の前記アプリケーション装置に前記データを送信する制御を行う制御部
　を備える情報処理装置。
（２）
　前記制御部は、前記アプリケーション装置から、前記紐づけ情報を取得する
　前記（１）に記載の情報処理装置。
（３）
　前記制御部は、前記アプリケーション装置に紐づいている前記デバイスに前記情報処理装置が接続するためのアクセス情報を、前記紐づけ情報として、前記アプリケーション装置から取得する
　前記（１）または（２）に記載の情報処理装置。
（４）
　前記アプリケーション装置は、前記情報処理装置が前記デバイスに接続するためのアクセス情報を、前記紐づけ情報を管理するサーバ装置から取得する
　前記（３）に記載の情報処理装置。
（５）
　前記アプリケーション装置は、自身に紐づいている前記デバイスに自身が接続するためのアクセス情報を、前記紐づけ情報を管理するサーバ装置から取得し、取得した自身が接続するためのアクセス情報に基づいて、前記情報処理装置が前記デバイスに接続するためのアクセス情報を、前記サーバ装置に要求して取得する
　前記（３）または（４）に記載の情報処理装置。
（６）
　前記制御部は、前記紐づけ情報を管理するサーバ装置から、前記紐づけ情報を取得する
　前記（１）に記載の情報処理装置。
（７）
　前記制御部は、前記アプリケーション装置に紐づいている前記デバイスのデバイスリストを前記アプリケーション装置から取得し、前記デバイスリストに基づいて、前記紐づけ情報を管理するサーバ装置から、前記紐づけ情報を取得する
　前記（６）に記載の情報処理装置。
（８）
　前記制御部は、前記アプリケーション装置に紐づいている前記デバイスのデバイスリストを前記アプリケーション装置から取得し、前記デバイスリストに基づいて、前記情報処理装置が前記デバイスに接続するためのアクセス情報を前記サーバ装置に要求して取得する
　前記（６）または（７）に記載の情報処理装置。
（９）
　前記アプリケーション装置は、前記サーバ装置から取得した、自身が接続するためのアクセス情報に基づいて、前記デバイスリストを前記情報処理装置に送信する
　前記（７）または（８）に記載の情報処理装置。
（１０）
　前記情報処理装置が前記デバイスに接続するためのアクセス情報は、データパイプラインを識別するデータパイプライン識別情報を含む
　前記（１）ないし（９）のいずれかに記載の情報処理装置。
（１１）
　前記アプリケーション装置に紐づいている前記デバイスに前記アプリケーション装置が接続するためのアクセス情報は、データパイプラインを識別するデータパイプライン識別情報を含む
　前記（１）ないし（１０）のいずれかに記載の情報処理装置。
（１２）
　前記制御部は、前記アプリケーション装置を識別する装置識別情報またはデータパイプラインを識別するデータパイプライン識別情報を含む動作指示情報を取得し、取得した前記動作指示情報に基づいて、前記データの送り先を決定する
　前記（１）ないし（１１）のいずれかに記載の情報処理装置。
（１３）
　前記制御部は、動作指示情報を取得し、前記デバイスから取得した前記データに含まれる前記動作指示情報を識別する動作指示識別情報に基づいて、前記データの送り先を決定し、送り先として決定された１つ以上の前記アプリケーション装置に前記データを送信する
　前記（１）ないし（１２）のいずれかに記載の情報処理装置。
（１４）
　前記情報処理装置は、NICE規格のData Serviceである
　前記（１）ないし（１３）のいずれかに記載の情報処理装置。
（１５）
　情報処理装置が、
　データを出力するデバイスと、前記データを用いた所定のデータ処理を行うアプリケーション装置との紐づけ情報を、複数の前記アプリケーション装置について取得し、取得した紐づけ情報に基づいて、１つ以上の前記デバイスから取得した前記データの送り先を決定し、送り先として決定された１つ以上の前記アプリケーション装置に前記データを送信する
　情報処理方法。
（１６）
　コンピュータに、
　データを出力するデバイスと、前記データを用いた所定のデータ処理を行うアプリケーション装置との紐づけ情報を、複数の前記アプリケーション装置について取得し、取得した紐づけ情報に基づいて、１つ以上の前記デバイスから取得した前記データの送り先を決定し、送り先として決定された１つ以上の前記アプリケーション装置に前記データを送信する
　処理を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
（１７）
　デバイスが生成したデータを通信する２つのエンティティに、TLSクライアントまたはTLSサーバの役割を識別する識別子と、その識別子に応じたTLS証明書を送信する制御を行う制御部
　を備える情報処理装置。
（１８）
　前記２つのエンティティは、前記情報処理装置から送信された前記TLS証明書を用いてTLS相互認証を行う
　前記（１７）に記載の情報処理装置。
（１９）
　前記制御部は、前記２つのエンティティそれぞれに、TLSクライアントの役割とTLSサーバの役割を識別する２つの識別子と、TLSクライアント証明書とTLSサーバ証明書を送信する制御を行う
　前記（１７）または（１８）に記載の情報処理装置。
（２０）
　前記識別子と前記TLS証明書は、SceneModeオブジェクトに含まれて送信される
　前記（１７）ないし（１９）のいずれかに記載の情報処理装置。
（２１）
　前記識別子と前記TLS証明書は、SceneModeオブジェクトのEndPointプロパティに含まれて送信される
　前記（１７）ないし（２０）のいずれかに記載の情報処理装置。
（２２）
　前記情報処理装置は、NICE規格のData Pipeline Controllerである
　前記（１７）ないし（２１）のいずれかに記載の情報処理装置。
（２３）
　前記２つのエンティティ少なくとも１つは、NICE規格のデバイスである
　前記（１７）ないし（２２）のいずれかに記載の情報処理装置。
（２４）
　前記２つのエンティティは、NICE規格のデバイスである
　前記（１７）ないし（２３）のいずれかに記載の情報処理装置。
（２５）
　前記制御部は、管理サーバが発行するTLSクライアント証明書とTLSサーバ証明書を取得し、前記２つのエンティティそれぞれに送信する制御を行う
　前記（１７）ないし（２４）のいずれかに記載の情報処理装置。
（２６）
　前記管理サーバは、NICE規格のNICE ASである
　前記（２５）に記載の情報処理装置。
（２７）
　情報処理装置が、
　デバイスが生成したデータを通信する２つのエンティティに、TLSクライアントまたはTLSサーバの役割を識別する識別子と、その識別子に応じたTLS証明書を送信する
　情報処理方法。
（２８）
　コンピュータに、
　デバイスが生成したデータを通信する２つのエンティティに、TLSクライアントまたはTLSサーバの役割を識別する識別子と、その識別子に応じたTLS証明書を送信する
　処理を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
　５１　データ処理システム，　６０　管理サーバ，　６１　デバイス，　６２　App装置，　６３　デバイス，　１５１　動作指示識別情報，　１５２　動作指示識別情報，　２００　データ処理システム，　２１１　デバイス，　２１３　App装置，　２２１　管理サーバ，　３００　デバイス，　３２１　センサ部，　３２２　処理部，　３２３　記憶部，　３２４　通信部，　５００　コンピュータ，　５０２　ROM，　５０４　バス，　５０５　入出力インターフェース，　５０６　入力部，　５０７　出力部，　５０８　記憶部，　５０９　通信部，　５１０　ドライブ，　５１１　リムーバブル記録媒体

Claims (28)

  1. 　データを出力するデバイスと、前記データを用いた所定のデータ処理を行うアプリケーション装置との紐づけ情報を、複数の前記アプリケーション装置について取得し、取得した紐づけ情報に基づいて、１つ以上の前記デバイスから取得した前記データの送り先を決定し、送り先として決定された１つ以上の前記アプリケーション装置に前記データを送信する制御を行う制御部
    　を備える情報処理装置。
  2. 　前記制御部は、前記アプリケーション装置から、前記紐づけ情報を取得する
    　請求項１に記載の情報処理装置。
  3. 　前記制御部は、前記アプリケーション装置に紐づいている前記デバイスに前記情報処理装置が接続するためのアクセス情報を、前記紐づけ情報として、前記アプリケーション装置から取得する
    　請求項１に記載の情報処理装置。
  4. 　前記アプリケーション装置は、前記情報処理装置が前記デバイスに接続するためのアクセス情報を、前記紐づけ情報を管理するサーバ装置から取得する
    　請求項３に記載の情報処理装置。
  5. 　前記アプリケーション装置は、自身に紐づいている前記デバイスに自身が接続するためのアクセス情報を、前記紐づけ情報を管理するサーバ装置から取得し、取得した自身が接続するためのアクセス情報に基づいて、前記情報処理装置が前記デバイスに接続するためのアクセス情報を、前記サーバ装置に要求して取得する
    　請求項３に記載の情報処理装置。
  6. 　前記制御部は、前記紐づけ情報を管理するサーバ装置から、前記紐づけ情報を取得する
    　請求項１に記載の情報処理装置。
  7. 　前記制御部は、前記アプリケーション装置に紐づいている前記デバイスのデバイスリストを前記アプリケーション装置から取得し、前記デバイスリストに基づいて、前記紐づけ情報を管理するサーバ装置から、前記紐づけ情報を取得する
    　請求項６に記載の情報処理装置。
  8. 　前記制御部は、前記アプリケーション装置に紐づいている前記デバイスのデバイスリストを前記アプリケーション装置から取得し、前記デバイスリストに基づいて、前記情報処理装置が前記デバイスに接続するためのアクセス情報を前記サーバ装置に要求して取得する
    　請求項６に記載の情報処理装置。
  9. 　前記アプリケーション装置は、前記サーバ装置から取得した、自身が接続するためのアクセス情報に基づいて、前記デバイスリストを前記情報処理装置に送信する
    　請求項７に記載の情報処理装置。
  10. 　前記情報処理装置が前記デバイスに接続するためのアクセス情報は、データパイプラインを識別するデータパイプライン識別情報を含む
    　請求項１に記載の情報処理装置。
  11. 　前記アプリケーション装置に紐づいている前記デバイスに前記アプリケーション装置が接続するためのアクセス情報は、データパイプラインを識別するデータパイプライン識別情報を含む
    　請求項１に記載の情報処理装置。
  12. 　前記制御部は、前記アプリケーション装置を識別する装置識別情報またはデータパイプラインを識別するデータパイプライン識別情報を含む動作指示情報を取得し、取得した前記動作指示情報に基づいて、前記データの送り先を決定する
    　請求項１に記載の情報処理装置。
  13. 　前記制御部は、動作指示情報を取得し、前記デバイスから取得した前記データに含まれる前記動作指示情報を識別する動作指示識別情報に基づいて、前記データの送り先を決定し、送り先として決定された１つ以上の前記アプリケーション装置に前記データを送信する
    　請求項１に記載の情報処理装置。
  14. 　前記情報処理装置は、NICE規格のData Serviceである
    　請求項１に記載の情報処理装置。
  15. 　情報処理装置が、
    　データを出力するデバイスと、前記データを用いた所定のデータ処理を行うアプリケーション装置との紐づけ情報を、複数の前記アプリケーション装置について取得し、取得した紐づけ情報に基づいて、１つ以上の前記デバイスから取得した前記データの送り先を決定し、送り先として決定された１つ以上の前記アプリケーション装置に前記データを送信する
    　情報処理方法。
  16. 　コンピュータに、
    　データを出力するデバイスと、前記データを用いた所定のデータ処理を行うアプリケーション装置との紐づけ情報を、複数の前記アプリケーション装置について取得し、取得した紐づけ情報に基づいて、１つ以上の前記デバイスから取得した前記データの送り先を決定し、送り先として決定された１つ以上の前記アプリケーション装置に前記データを送信する
    　処理を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
  17. 　デバイスが生成したデータを通信する２つのエンティティに、TLSクライアントまたはTLSサーバの役割を識別する少なくとも一つの識別子と、その識別子に応じたTLS証明書を送信する制御を行う制御部
    　を備える情報処理装置。
  18. 　前記２つのエンティティは、前記情報処理装置から送信された前記TLS証明書を用いてTLS相互認証を行う
    　請求項１７に記載の情報処理装置。
  19. 　前記制御部は、前記２つのエンティティそれぞれに、TLSクライアントの役割とTLSサーバの役割を識別する２つの識別子と、TLSクライアント証明書とTLSサーバ証明書を送信する制御を行う
    　請求項１７に記載の情報処理装置。
  20. 　前記識別子と前記TLS証明書は、SceneModeオブジェクトに含まれて送信される
    　請求項１７に記載の情報処理装置。
  21. 　前記識別子と前記TLS証明書は、SceneModeオブジェクトのEndPointプロパティに含まれて送信される
    　請求項１７に記載の情報処理装置。
  22. 　前記情報処理装置は、NICE規格のData Pipeline Controllerである
    　請求項１７に記載の情報処理装置。
  23. 　前記２つのエンティティ少なくとも１つは、NICE規格のデバイスである
    　請求項１７に記載の情報処理装置。
  24. 　前記２つのエンティティは、NICE規格のデバイスである
    　請求項１７に記載の情報処理装置。
  25. 　前記制御部は、管理サーバが発行するTLSクライアント証明書とTLSサーバ証明書を取得し、前記２つのエンティティそれぞれに送信する制御を行う
    　請求項１７に記載の情報処理装置。
  26. 　前記管理サーバは、NICE規格のNICE ASである
    　請求項２５に記載の情報処理装置。
  27. 　情報処理装置が、
    　デバイスが生成したデータを通信する２つのエンティティに、TLSクライアントまたはTLSサーバの役割を識別する少なくとも一つの識別子と、その識別子に応じたTLS証明書を送信する
    　情報処理方法。
  28. 　コンピュータに、
    　デバイスが生成したデータを通信する２つのエンティティに、TLSクライアントまたはTLSサーバの役割を識別する少なくとも一つの識別子と、その識別子に応じたTLS証明書を送信する
    　処理を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
PCT/JP2023/032951 2022-09-28 2023-09-11 情報処理装置、情報処理方法、および記録媒体 Ceased WO2024070609A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022155345 2022-09-28
JP2022-155345 2022-09-28

Publications (1)

Publication Number Publication Date
WO2024070609A1 true WO2024070609A1 (ja) 2024-04-04

Family

ID=90477498

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/032951 Ceased WO2024070609A1 (ja) 2022-09-28 2023-09-11 情報処理装置、情報処理方法、および記録媒体

Country Status (2)

Country Link
TW (1) TW202418811A (ja)
WO (1) WO2024070609A1 (ja)

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005027352A (ja) * 2004-10-01 2005-01-27 Ntt Docomo Inc ハンドオーバ方法及び移動局
JP2010136272A (ja) * 2008-12-08 2010-06-17 Oki Electric Ind Co Ltd ゲートウェイ装置
JP2012249124A (ja) * 2011-05-30 2012-12-13 Mitsubishi Electric Corp 端末装置およびサーバ装置および電子証明書発行システムおよび電子証明書受信方法および電子証明書送信方法およびプログラム
JP2015226212A (ja) * 2014-05-28 2015-12-14 シャープ株式会社 中継装置、機器連携システム、中継方法、プログラム、及び記録媒体
WO2017188417A1 (ja) * 2016-04-28 2017-11-02 Ｎｅｃソリューションイノベータ株式会社 データ転送システム、データ転送装置、データ転送方法、及びコンピュータ読み取り可能な記録媒体
WO2017212586A1 (ja) * 2016-06-08 2017-12-14 三菱電機株式会社 ゲートウェイ装置および転送方法
WO2019069957A1 (ja) * 2017-10-03 2019-04-11 日本電気株式会社 サーバ装置、ニオイセンサデータ解析方法、及びコンピュータ読み取り可能な記録媒体
JP2020123786A (ja) * 2019-01-29 2020-08-13 株式会社東芝 通信制御ユニット
WO2020174606A1 (ja) * 2019-02-27 2020-09-03 三菱電機株式会社 センサ情報収集システム、センサ情報収集方法、データ取得端末、及び、プログラム
JP2020145531A (ja) * 2019-03-05 2020-09-10 ソニー株式会社 情報処理装置、情報処理方法及びプログラム
WO2022070781A1 (ja) * 2020-09-29 2022-04-07 ソニーセミコンダクタソリューションズ株式会社 情報処理システム及び情報処理方法

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005027352A (ja) * 2004-10-01 2005-01-27 Ntt Docomo Inc ハンドオーバ方法及び移動局
JP2010136272A (ja) * 2008-12-08 2010-06-17 Oki Electric Ind Co Ltd ゲートウェイ装置
JP2012249124A (ja) * 2011-05-30 2012-12-13 Mitsubishi Electric Corp 端末装置およびサーバ装置および電子証明書発行システムおよび電子証明書受信方法および電子証明書送信方法およびプログラム
JP2015226212A (ja) * 2014-05-28 2015-12-14 シャープ株式会社 中継装置、機器連携システム、中継方法、プログラム、及び記録媒体
WO2017188417A1 (ja) * 2016-04-28 2017-11-02 Ｎｅｃソリューションイノベータ株式会社 データ転送システム、データ転送装置、データ転送方法、及びコンピュータ読み取り可能な記録媒体
WO2017212586A1 (ja) * 2016-06-08 2017-12-14 三菱電機株式会社 ゲートウェイ装置および転送方法
WO2019069957A1 (ja) * 2017-10-03 2019-04-11 日本電気株式会社 サーバ装置、ニオイセンサデータ解析方法、及びコンピュータ読み取り可能な記録媒体
JP2020123786A (ja) * 2019-01-29 2020-08-13 株式会社東芝 通信制御ユニット
WO2020174606A1 (ja) * 2019-02-27 2020-09-03 三菱電機株式会社 センサ情報収集システム、センサ情報収集方法、データ取得端末、及び、プログラム
JP2020145531A (ja) * 2019-03-05 2020-09-10 ソニー株式会社 情報処理装置、情報処理方法及びプログラム
WO2022070781A1 (ja) * 2020-09-29 2022-04-07 ソニーセミコンダクタソリューションズ株式会社 情報処理システム及び情報処理方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Nice Data Pipeline Specification, Version 1.0.1", 20 December 2019 (2019-12-20), pages 1 - 114, XP093152042, Retrieved from the Internet <URL:https://www.nicealliance.org/wp-content/uploads/2020/02/nice-data-pipeline-specification-v1.0.1.pdf> *

Also Published As

Publication number Publication date
TW202418811A (zh) 2024-05-01

Similar Documents

Publication Publication Date Title
CN112055024B (zh) 权限校验方法及装置、存储介质和电子设备
US10990840B2 (en) Configuring data pipelines with image understanding
US20170111350A1 (en) Controlled Token Distribution to Protect Against Malicious Data and Resource Access
CN107784221B (zh) 权限控制方法、服务提供方法、装置、系统及电子设备
US20110265157A1 (en) One step security system in a network storage system
US11706202B2 (en) Distributed encryption
US10708769B2 (en) Cloud assisted accessory pairing
US12177213B2 (en) Method and system for securing communications between a lead device and a secondary device
US20190230721A1 (en) Automatic update of connection to a movable object
US20130121541A1 (en) Method And Apparatus To Authenticate User
US20260075045A1 (en) Initial accessory setup
JP4547210B2 (ja) クライアント端末、サービス提供装置及びサービス発見方法
WO2019084742A1 (zh) 数据的传输方法、服务器、存储系统、终端设备及系统
WO2024070609A1 (ja) 情報処理装置、情報処理方法、および記録媒体
KR20200111032A (ko) 신뢰현실 서비스 방법 및 장치
US11895196B1 (en) Efficient update mechanism in IoT event driven architectures
US20240388629A1 (en) Vehicle data access
CN112953986A (zh) 一种边缘应用的管理方法及装置
US10659385B2 (en) Provisioning insight services in a data provider landscape
US11495073B2 (en) Decentralized virtual trustless database for access control
CN116954693A (zh) 状态协同方法、装置、计算机设备及存储介质
US20250379914A1 (en) Techniques for synchronizing data
US20250247901A1 (en) Techniques for communicating data
US20240407020A1 (en) Techniques for communicating data
US20240134953A1 (en) Subsequent accessory setup

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: 23871845

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 23871845

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP