特許 7546421 仮想ＩｏＴ制御方法および物理デバイスの仮想化システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-29

(45)【発行日】2024-09-06

(54)【発明の名称】仮想ＩｏＴ制御方法および物理デバイスの仮想化システム

(51)【国際特許分類】

   H04L 41/06 20220101AFI20240830BHJP

   H04L 67/00 20220101ALI20240830BHJP

   H04L 69/40 20220101ALI20240830BHJP

   H04Q 9/00 20060101ALI20240830BHJP

【ＦＩ】

H04L41/06

H04L67/00

H04L69/40

H04Q9/00 311W

【請求項の数】 8

(21)【出願番号】P 2020152172

(22)【出願日】2020-09-10

(65)【公開番号】P2022046234

(43)【公開日】2022-03-23

【審査請求日】2023-08-28

【国等の委託研究の成果に係る記載事項】（出願人による申告）令和２年度、総務省、令和２年度におけるスマートシティアプリケーションに拡張性と相互運用性をもたらす仮想ＩｏＴ－クラウド連携基盤の研究開発の委託事業［総務省ＳＣＯＰＥ（国際標準獲得型）ＪＰＪ０００５９５］、産業技術力強化法第１７条の適用を受ける特許出願

(73)【特許権者】

【識別番号】000005821

【氏名又は名称】パナソニックホールディングス株式会社

(74)【代理人】

【識別番号】110001379

【氏名又は名称】弁理士法人大島特許事務所

(72)【発明者】

【氏名】上杉 充

【審査官】吉田 歩

(56)【参考文献】

【文献】再公表特許第２０１８／１４２５９８（ＪＰ，Ａ１）

【文献】特開２０１８－１５２０６４（ＪＰ，Ａ）

【文献】特開２０１７－１４２６５４（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １３／００

Ｈ０４Ｌ ４１／０６

Ｈ０４Ｌ ６７／００

Ｈ０４Ｌ ６９／４０

Ｈ０４Ｑ ９／００

(57)【特許請求の範囲】

【請求項1】

ユーザシステムが、仮想デバイスを制御する仮想ＩｏＴシステムに対してデータを要求し、
前記仮想ＩｏＴシステムが、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴ制御方法であって、
前記仮想ＩｏＴシステムが、
前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、
前記物理デバイスの不備として、既存の前記物理デバイスの仕様が、前記ユーザシステムが要求するデータを仮想デバイスにより生成する上で十分でない旨を前記ユーザシステムに報告し、
前記ユーザシステムが、
既存の前記物理デバイスの仕様が十分でない場合に、要求するデータの仕様を緩和して、前記仮想ＩｏＴシステムに対して再度データを要求することを特徴とする仮想ＩｏＴ制御方法。

【請求項2】

ユーザシステムが、仮想デバイスを制御する仮想ＩｏＴシステムに対してデータを要求し、
前記仮想ＩｏＴシステムが、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴ制御方法であって、
前記仮想ＩｏＴシステムが、
前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、
前記物理デバイスの不備の詳細内容として、既存の前記物理デバイスの仕様を前記ユーザシステムに報告し、
前記ユーザシステムが、
既存の前記物理デバイスの仕様に適合するように、要求するデータの仕様を緩和して、前記仮想ＩｏＴシステムに対して再度データを要求することを特徴とする仮想ＩｏＴ制御方法。

【請求項3】

前記ユーザシステムが、
前記仮想ＩｏＴシステムから前記物理デバイスの不備の報告を受け取ると、
不備のある前記物理デバイスの整備をユーザに促す出力を行うことを特徴とする請求項１に記載の仮想ＩｏＴ制御方法。

【請求項4】

ユーザシステムが、仮想デバイスを制御する仮想ＩｏＴシステムに対してデータを要求し、
前記仮想ＩｏＴシステムが、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴ制御方法であって、
前記仮想ＩｏＴシステムが、
前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、その物理デバイスの不備を前記ユーザシステムに報告し、
前記ユーザシステムが、
前記仮想ＩｏＴシステムから前記物理デバイスの不備の報告を受け取ると、代行者システムに対して、不備のある前記物理デバイスの整備を要求し、
前記代行者システムが、
前記ユーザシステムからの前記物理デバイスの整備の要求に基づいて、前記物理デバイスの整備の可否を判定し、
前記物理デバイスの整備が必要である場合には、
不備のある前記物理デバイスの整備を代行者に促す出力を行うことを特徴とする仮想ＩｏＴ制御方法。

【請求項5】

前記代行者システムが、
前記ユーザシステムからの前記物理デバイスの整備の要求の件数が所定のしきい値に達した場合に、前記物理デバイスの整備が必要であると判定することを特徴とする請求項４に記載の仮想ＩｏＴ制御方法。

【請求項6】

前記代行者システムが、
複数の前記ユーザシステムの各々からの前記物理デバイスの整備の要求で指定された前記物理デバイスの仕様のうちで最もレベルが高い仕様を選択することを特徴とする請求項４に記載の仮想ＩｏＴ制御方法。

【請求項7】

ユーザシステムが、仮想デバイスを制御する仮想ＩｏＴシステムに対してデータを要求し、
前記仮想ＩｏＴシステムが、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴ制御方法であって、
前記仮想ＩｏＴシステムが、
前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、
代行者システムに対して、不備のある前記物理デバイスの整備を要求し、
前記代行者システムが、
前記ユーザシステムからの前記物理デバイスの整備の要求に基づいて、前記物理デバイスの整備の可否を判定し、
前記物理デバイスの整備が必要である場合には、
不備のある前記物理デバイスの整備を代行者に促す出力を行うことを特徴とする仮想ＩｏＴ制御方法。

【請求項8】

ユーザシステムからのデータの要求に応じて、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴシステムを含む、物理デバイスの仮想化システムであって、
前記仮想ＩｏＴシステムが、
前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、
代行者システムに対して、不備のある前記物理デバイスの整備を要求し、
前記代行者システムが、
前記ユーザシステムからの前記物理デバイスの整備の要求に基づいて、前記物理デバイスの整備の可否を判定し、
前記物理デバイスの整備が必要である場合には、
不備のある前記物理デバイスの整備を代行者に促す出力を行うことを特徴とする物理デバイスの仮想化システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、ユーザが要求するデータを仮想デバイスにより生成して、そのデータをユーザシステムに提供する仮想ＩｏＴ制御方法および仮想ＩｏＴシステムに関するものである。

【背景技術】

【0002】

近年、ＩｏＴ（モノのインターネット：Internet of Things）の技術が注目されている。このＩｏＴは、世の中に存在する様々な物理デバイス（ＩｏＴデバイス）をセンサとして活用して、その物理デバイスから収集された種々のデータを、インターネットを利用して、多数のユーザで共有できるようにするものである。

【0003】

一方、ＩｏＴデバイスを仮想化する技術が知られている（特許文献１参照）。このＩｏＴデバイスの仮想化の技術では、１つの物理デバイスのデータ、あるいは複数の物理デバイスのデータを加工することで、実際には存在しないＩｏＴデバイス（仮想デバイス）のデータを生成することができる。このようなＩｏＴデバイスの仮想化の技術により、元になる物理デバイスとしてのカメラは同一でも、カメラで検出されたデータ（撮影画像）に対して所要の画像解析を行うことで、例えば、あるユーザでは、人物検知装置として認識され、別のユーザでは、混雑度検知装置として認識され、さらに別のユーザでは、獣害回避のための野生動物検知装置として認識されるようになる。

【先行技術文献】

【特許文献】

【0004】

【文献】特表２０１８－５２７６５１号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、ＩｏＴデバイスの仮想化の技術では、仮想デバイスによりユーザが要求するデータを生成するにあたり、必要な物理デバイスのデータがなければ、ユーザが要求するデータを仮想デバイスのデータとして生成することができないという問題があった。

【0006】

例えば、ある地点に設置されたカメラのデータ（撮影画像）に基づいて、仮想デバイスとしての人物検知装置のデータ、すなわち、人物検知結果のデータを生成することができる。この場合に、ユーザが、例えば２つの地点における人物検知結果のデータを要望しているが、１つの地点にはカメラが設置されているものの、もう１つの地点にはカメラが設置されていないと、ユーザは１つの地点の人物検知結果のデータしか取得できない。

【0007】

また、複数の物理デバイスのデータに基づいて、ユーザが要求するデータを仮想デバイスのデータとして生成することができる。この場合、仮想デバイスのデータは、必要な複数の物理デバイスのデータが揃って初めて得られるものであり、必要な複数の物理デバイスのうちの１つが欠けていただけでも得られない。例えば、仮想デバイスのデータとして、温度および風力から算出される体感温度を生成する場合、元になる物理デバイスとしての温度計および風力計のいずれかが欠けていると、仮想デバイスのデータとして体感温度を取得することができない。

【0008】

そこで、本発明は、物理デバイスの不備、すなわち、ユーザが要求するデータを生成する仮想デバイスに必要な物理デバイスが整備されていない状態を、仮想ＩｏＴシステムから提供されるデータを利用するユーザや、対象エリアの管理者などに認識させて、必要な物理デバイスの整備を促進することができる仮想ＩｏＴ制御方法および仮想ＩｏＴシステムを提供することを主な目的とする。

【課題を解決するための手段】

【0009】

本発明の仮想ＩｏＴ制御方法は、ユーザシステムが、仮想デバイスを制御する仮想ＩｏＴシステムに対してデータを要求し、前記仮想ＩｏＴシステムが、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴ制御方法であって、前記仮想ＩｏＴシステムが、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、前記物理デバイスの不備として、既存の前記物理デバイスの仕様が、前記ユーザシステムが要求するデータを仮想デバイスにより生成する上で十分でない旨を前記ユーザシステムに報告し、前記ユーザシステムが、既存の前記物理デバイスの仕様が十分でない場合に、要求するデータの仕様を緩和して、前記仮想ＩｏＴシステムに対して再度データを要求する構成とする。

【0010】

また、本発明の物理デバイスの仮想化システムは、ユーザシステムからのデータの要求に応じて、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴシステムを含む、物理デバイスの仮想化システムであって、前記仮想ＩｏＴシステムが、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、代行者システムに対して、不備のある前記物理デバイスの整備を要求し、前記代行者システムが、前記ユーザシステムからの前記物理デバイスの整備の要求に基づいて、前記物理デバイスの整備の可否を判定し、前記物理デバイスの整備が必要である場合には、不備のある前記物理デバイスの整備を代行者に促す出力を行う構成とする。

【発明の効果】

【0011】

本発明によれば、仮想デバイス部が、物理デバイスの不備を検知する。このため、物理デバイスの不備を、仮想ＩｏＴシステムから提供されるデータを利用するユーザや、対象エリアの管理者などが認識できるようになる。これにより、ユーザや管理者などに、必要な物理デバイスの整備を促すことができる。

【図面の簡単な説明】

【0012】

【図1】第１実施形態に係る仮想ＩｏＴ制御方法の概要を示すブロック図

【図2】物理デバイス２の不備の一例を示す説明図

【図3】物理デバイス２の不備の一例を示す説明図

【図4】第１実施形態に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【図5】第１実施形態に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【図6】第２実施形態に係る仮想ＩｏＴ制御方法の概要を示すブロック図

【図7】第２実施形態に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【図8】第２実施形態に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【図9】第２実施形態の第１変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【図10】第２実施形態の第２変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【図11】第３実施形態に係る仮想ＩｏＴ制御方法の概要を示すブロック図

【図12】第３実施形態に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【図13】第３実施形態の第１変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【図14】第３実施形態の第２変形例に係る仮想ＩｏＴ制御方法の概要を示すブロック図

【図15】第３実施形態の第２変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【図16】第３実施形態の第３変形例に係る仮想ＩｏＴ制御方法の概要を示すブロック図

【図17】第３実施形態の第３変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【図18】第４実施形態に係る仮想ＩｏＴ制御方法の概要を示すブロック図

【図19】第４実施形態に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【図20】第４実施形態の変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図

【発明を実施するための形態】

【0013】

前記課題を解決するためになされた第１の発明は、ユーザシステムが、仮想デバイスを制御する仮想ＩｏＴシステムに対してデータを要求し、前記仮想ＩｏＴシステムが、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴ制御方法であって、前記仮想ＩｏＴシステムが、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、前記物理デバイスの不備として、既存の前記物理デバイスの仕様が、前記ユーザシステムが要求するデータを仮想デバイスにより生成する上で十分でない旨を前記ユーザシステムに報告し、前記ユーザシステムが、既存の前記物理デバイスの仕様が十分でない場合に、要求するデータの仕様を緩和して、前記仮想ＩｏＴシステムに対して再度データを要求する構成とする。

【0014】

これによると、仮想デバイス部が、物理デバイスの不備を検知する。このため、物理デバイスの不備を、仮想ＩｏＴシステムから提供されるデータを利用するユーザや、対象エリアの管理者などが認識できるようになる。これにより、ユーザや管理者などに、必要な物理デバイスの整備を促すことができる。また、これによると、既存の物理デバイスの仕様が、ユーザが要求するデータを仮想デバイスにより生成する上で十分でないことを、ユーザが認識することができる。そして、ユーザが、データの仕様の緩和を許容できる場合には、ユーザシステムが、データの仕様を緩和した上でデータの要求を再度行うことで、必要なデータを許容範囲内の仕様で取得することができる。

【0019】

また、第２の発明は、ユーザシステムが、仮想デバイスを制御する仮想ＩｏＴシステムに対してデータを要求し、前記仮想ＩｏＴシステムが、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴ制御方法であって、前記仮想ＩｏＴシステムが、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、前記物理デバイスの不備の詳細内容として、既存の前記物理デバイスの仕様を前記ユーザシステムに報告し、前記ユーザシステムが、既存の前記物理デバイスの仕様に適合するように、要求するデータの仕様を緩和して、前記仮想ＩｏＴシステムに対して再度データを要求する構成とする。

【0020】

これによると、ユーザシステムが、仕様を緩和したデータの再要求を１度行うだけで、ユーザが必要とするデータを取得することができる。

【0021】

また、第５の発明は、前記ユーザシステムが、前記仮想ＩｏＴシステムから前記物理デバイスの不備の報告を受け取ると、不備のある前記物理デバイスの整備をユーザに促す出力を行う構成とする。

【0022】

これによると、物理デバイスに不備がある場合に、速やかにユーザ自身が必要な物理デバイスの整備に着手することができる。

【0025】

また、第４の発明は、ユーザシステムが、仮想デバイスを制御する仮想ＩｏＴシステムに対してデータを要求し、前記仮想ＩｏＴシステムが、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴ制御方法であって、前記仮想ＩｏＴシステムが、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、その物理デバイスの不備を前記ユーザシステムに報告し、前記ユーザシステムが、前記仮想ＩｏＴシステムから前記物理デバイスの不備の報告を受け取ると、代行者システムに対して、不備のある前記物理デバイスの整備を要求し、前記代行者システムが、前記ユーザシステムからの前記物理デバイスの整備の要求に基づいて、前記物理デバイスの整備の可否を判定し、前記物理デバイスの整備が必要である場合には、不備のある前記物理デバイスの整備を代行者に促す出力を行う構成とする。

【0026】

これによると、物理デバイスに不備がある場合に、速やかに代行者が必要な物理デバイスの整備に着手することができる。

【0027】

また、第８の発明は、前記代行者システムが、前記ユーザシステムからの前記物理デバイスの整備の要求の件数が所定のしきい値に達した場合に、前記物理デバイスの整備が必要であると判定する構成とする。

【0028】

これによると、ユーザシステムからの物理デバイス整備要求の件数が多い、すなわち、物理デバイスの需要が高くなったところで、物理デバイスが整備されるため、整備された物理デバイスの有効活用を図ることができる。

【0029】

また、第９の発明は、前記代行者システムが、複数の前記ユーザシステムの各々からの前記物理デバイスの整備の要求で指定された前記物理デバイスの仕様のうちで最もレベルが高い仕様を選択する構成とする。

【0030】

これによると、ユーザから要求された仕様のうちで最もレベルが高い仕様で物理デバイスの整備が行われるため、ユーザが満足する仕様のデータを全てのユーザに提供することができる。

【0039】

また、第７の発明は、ユーザシステムが、仮想デバイスを制御する仮想ＩｏＴシステムに対してデータを要求し、前記仮想ＩｏＴシステムが、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴ制御方法であって、前記仮想ＩｏＴシステムが、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、代行者システムに対して、不備のある前記物理デバイスの整備を要求し、前記代行者システムが、前記ユーザシステムからの前記物理デバイスの整備の要求に基づいて、前記物理デバイスの整備の可否を判定し、前記物理デバイスの整備が必要である場合には、不備のある前記物理デバイスの整備を代行者に促す出力を行う構成とする。

【0040】

これによると、仮想デバイス部が、代行者システムに物理デバイスの整備を要求する。このため、代行者に、必要な物理デバイスの整備を促すことができる。なお、代行者は、ユーザに代わって物理デバイスの整備を行うものであり、例えば対象エリアの管理者などである。

【0041】

また、第８の発明は、ユーザシステムからのデータの要求に応じて、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、前記ユーザシステムが要求するデータを仮想デバイスにより生成して、そのデータを前記ユーザシステムに提供する仮想ＩｏＴシステムを含む、物理デバイスの仮想化システムであって、前記仮想ＩｏＴシステムが、前記ユーザシステムが要求するデータを前記仮想デバイスにより生成するために必要な前記物理デバイスの不備を検知すると、代行者システムに対して、不備のある前記物理デバイスの整備を要求し、前記代行者システムが、前記ユーザシステムからの前記物理デバイスの整備の要求に基づいて、前記物理デバイスの整備の可否を判定し、前記物理デバイスの整備が必要である場合には、不備のある前記物理デバイスの整備を代行者に促す出力を行う構成とする。

【0042】

これによると、仮想ＩｏＴシステムが、代行者システムに物理デバイスの整備を要求するため、代行者に、必要な物理デバイスの整備を促すことができる。なお、代行者は、ユーザに代わって物理デバイスの整備を行うものであり、例えば対象エリアの管理者などである。

【0043】

以下、本発明の実施の形態を、図面を参照しながら説明する。

【0044】

（第１実施形態）
図１は、第１実施形態に係る仮想ＩｏＴ制御方法の概要を示すブロック図である。

【0045】

本実施形態では、仮想ＩｏＴシステム１が、スマートシティなどの対象エリアに設置された物理デバイス２（ＩｏＴデバイス）から収集されたデータに基づいて、ユーザが要求するデータを仮想デバイスにより生成して、そのデータをユーザシステム３に提供する。

【0046】

物理デバイス２は、例えばカメラや温度計などのセンサデバイスである。この物理デバイス２で検出されたデータが、仮想ＩｏＴシステム１により収集される。

【0047】

ユーザシステム３は、スマートフォンやパソコンなどのユーザデバイス（ユーザ端末）などにより構成される。ユーザシステム３には、ユーザのユースケースに応じて、ユーザアプリケーションが導入される。ユーザシステム３は、仮想ＩｏＴシステム１に対して、自身のユースケースに応じたデータの提供を要求し、これに応じて、必要なデータを仮想ＩｏＴシステム１から取得する。ユーザのユースケースとしては、例えば、駐車場の監視および利用者への案内などを行うシステムや、ゴミ収集場の監視などを行うシステムや、野生動物の被害対策として野生動物の監視などを行うシステムや、安否確認のための人物検知などを行うシステムなどがある。

【0048】

仮想ＩｏＴシステム１は、仮想サイロ１１（インタフェース部）と、ブローカー１２（中継制御部）と、シングバイザー１３（仮想デバイス部）と、ルートデータドメイン１４（データ収集部）と、を備えている。

【0049】

仮想サイロ１１は、ユーザ個別のインタフェースとして機能し、ユーザが要求するデータを、ユーザ固有のデータフォーマットでユーザシステム３に提供する。この仮想サイロ１１は、ユーザシステム３からのデータ提供の要求に応じて、ユーザのユースケースごとに作成される。

【0050】

ブローカー１２は、シングバイザー１３と仮想サイロ１１とを中継し、仮想サイロ１１から受け取ったユーザの要求内容に応じたシングバイザー１３を作成し、また、シングバイザー１３で生成された仮想デバイスのデータを仮想サイロ１１に提供する。このブローカー１２は、例えば、Ｆｅｄ４ＩｏＴ（仮想ＩｏＴ－クラウド連携基盤）や、ＭＱＴＴ（Message Queuing Telemetry Transport）などのＩｏＴプラットフォームや、情報指向ネットワーク（ＩＣＮ：Information Centric Network）などで運用される。

【0051】

シングバイザー１３は、ルートデータドメイン１４で収集された物理デバイス２のデータの管理および加工を行う。具体的には、シングバイザー１３は、ルートデータドメイン１４から取得した物理デバイス２のデータに基づいて、仮想デバイスとして、ユーザが要求する仕様（属性）のデータを生成する。このシングバイザー１３は、仮想サイロ１１と同様に、ユーザシステム３からのデータ提供の要求に応じて、ユーザのユースケースごとに作成される。

【0052】

ルートデータドメイン１４は、対象エリアに設置された物理デバイス２の検出結果としてのデータを収集する。このルートデータドメイン１４は、例えば、ｏｎｅＭ２Ｍや、ＦＩＷＡＲＥなどのクラウドプラットフォームである。なお、複数のルートデータドメイン１４がゲートウェイを介して相互に接続されて、別のルートデータドメイン１４に接続された物理デバイス２のデータを収集できるようにしてもよい。

【0053】

次に、第１実施形態に係るシングバイザー１３で検知される物理デバイス２の不備について説明する。図２，図３は、物理デバイス２の不備の一例を示す説明図である。

【0054】

仮想ＩｏＴシステム１のシングバイザー１３は、仮想デバイスとして、物理デバイス２から収集したデータに基づいて、ユーザが要求するデータを生成して、その仮想デバイスのデータをユーザシステム３に提供する。このとき、必要な物理デバイス２に不備があると、仮想デバイスにより、ユーザが要求するデータを生成することができない。

【0055】

図２（Ａ－１），（Ａ－２）に示す例は、物理デバイス２としてのカメラで検出されたデータ（撮影画像）に基づいて、仮想デバイスとしての人物検知装置のデータ、すなわち、人物検知結果のデータを生成する場合である。また、ユーザは、２つの地点における人物検知結果のデータを要望している。

【0056】

ここで、図２（Ａ－１）に示す例では、２つの地点にカメラが設置されているため、ユーザは２つの地点の人物検知結果のデータを取得することができる。一方、図２（Ａ－２）に示す例では、１つの地点にカメラが設置されているものの、もう１つの地点にはカメラが設置されていない。このため、ユーザは１つの地点の人物検知結果のデータしか取得できない。

【0057】

図２（Ｂ－１），（Ｂ－２）に示す例は、ユーザが、ある地点の体感温度のデータを収集したい場合である。体感温度は、温度および風力から算出されるため、物理デバイス２としての温度計および風力計から、仮想デバイスとしての体感温度計を作成すればよい。

【0058】

ここで、図２（Ｂ－１）に示す例では、温度計と風速計との両方が設置されているため、仮想ＩｏＴシステム１のシングバイザー１３は、温度計および風速計のデータから仮想デバイスとしての体感温度計のデータを生成することができる。一方、図２（Ｂ－２）に示す例では、温度計は設置されているものの、風速計が設置されていないため、仮想ＩｏＴシステム１のシングバイザー１３は、体感温度計のデータを生成することができない。

【0059】

図３（Ａ）に示す例は、ユーザが、スマートシティを対象エリアとして、その対象エリア内の温度を知りたい場合である。ここで、スマートシティでは、物理デバイス２としての温度計が１つも設置されていない。このため、仮想ＩｏＴシステム１のシングバイザー１３は、温度のデータを取得できない。

【0060】

図３（Ｂ）に示す例は、図３（Ａ）に示す例と同様に、ユーザが、スマートシティを対象エリアとして、温度の分布状況を把握するために、温度を１０ｍ刻みで知りたい場合である。ここで、スマートシティでは、物理デバイス２としての温度計が１００ｍおきにしか設置されていない。このため、仮想ＩｏＴシステム１のシングバイザー１３は、ユーザが要求する精度（密度）で温度のデータを取得できない。

【0061】

図３（Ｃ）に示す例は、ユーザが、スマートシティを対象エリアとして、体感温度の分布状況を把握するために、体感温度を１０ｍ刻みで知りたい場合である。ここで、スマートシティでは、物理デバイス２としての温度計が１０ｍおきに設置されているものの、風力計が設置されていない。このため、仮想ＩｏＴシステム１のシングバイザー１３は、仮想デバイスとしての体感温度計のデータを取得できない。

【0062】

そこで、本実施形態では、ユーザシステム３が、仮想ＩｏＴシステム１に対してデータの提供を要求した際に、ユーザが要求したデータを取得するために必要な物理デバイス２に不備がある場合に、その物理デバイス２の不備をシングバイザー１３が検知してユーザシステム３に報告する。ユーザシステム３は、シングバイザー１３からの物理デバイス不備の報告を受け取ると、データの仕様を緩和した上でデータの要求を再度行うようにユーザに促す。また、ユーザシステム３は、ユーザがデータの仕様を緩和できない場合には、ユーザ自らが物理デバイス２の整備を行うようにユーザに促す。

【0063】

ここで、物理デバイス２の不備とは、まず、ユーザが要求するデータの仕様（属性）に基づいて必要な地点に必要な物理デバイス２が設置されていない場合である。この場合、シングバイザー１３が、物理デバイス２の不備として、物理デバイス２が不足していることを検知して、その旨をユーザシステム３に報告する。また、物理デバイス２の整備としては、必要な地点に必要な物理デバイス２が新規に設置される。

【0064】

また、物理デバイス２の不備には、ユーザが要求するデータの仕様に対して、対象エリアにある既存の物理デバイス２だけでは密度が不足する場合も含まれる。この場合、シングバイザー１３が、物理デバイス２の不備として、物理デバイス２が不足していることを検知して、その旨をユーザシステム３に報告する。また、物理デバイス２の整備としては、対象エリアに物理デバイス２を新規に設置して物理デバイス２の密度を高くする措置が講じられる。

【0065】

また、物理デバイス２の不備には、必要な種類の物理デバイス２が存在するが、その物理デバイス２の仕様が、ユーザが要求する仕様（属性）のデータを生成する上で十分でない場合も含まれる。この場合、シングバイザー１３が、物理デバイス２の不備として、既存の物理デバイス２の仕様（属性）が十分でないことを検知して、その旨をユーザシステム３に報告する。また、物理デバイス２の整備としては、既存の物理デバイス２の仕様の高度化、すなわち、仕様のレベルを上げる措置が講じられる。ここで、物理デバイス２の仕様の高度化とは、具体的には、既存の物理デバイス２を改修したり、既存の物理デバイス２のパラメーターを調整したり、既存の物理デバイス２を例えばより高性能な別の物理デバイス２に置き換えたりすることである。

【0066】

図２（Ａ－２）に示す例では、シングバイザー１３が、物理デバイス２の不備として、指定された地点にカメラが設置されていない旨をユーザシステム３に報告する。また、図２（Ｂ－２）に示す例では、シングバイザー１３が、物理デバイス２の不備として、風速計が設置されていない旨をユーザシステム３に報告する。

【0067】

また、図３（Ａ）に示す例では、シングバイザー１３が、物理デバイス２の不備として、温度計が設置されていない旨をユーザシステム３に報告する。また、図３（Ｂ）に示す例では、シングバイザー１３が、物理デバイス２の不備として、温度計が設置されているものの、ユーザが要求する仕様で温度のデータを取得できない旨をユーザシステム３に報告する。図３（Ｃ）に示す例では、シングバイザー１３が、物理デバイス２の不備として、風力計が設置されていない旨をユーザシステム３に報告する。

【0068】

次に、第１実施形態に係る仮想ＩｏＴ制御方法の手順について説明する。図４，図５は、第１実施形態に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図である。図４は、ユーザが要求するデータの取得に必要な物理デバイス２に不備がない場合の手順を示す。図５は、ユーザが要求するデータの取得に必要な物理デバイス２に不備がある場合の手順を示す。

【0069】

図４に示すように、仮想ＩｏＴシステム１では、ルートデータドメイン１４が、物理デバイス２による検出結果のデータを物理デバイス２から収集（サブスクライブ）する。図４に示す例では、ルートデータドメイン１４が、＃１，＃２の物理デバイス２からデータを収集する。

【0070】

一方、ユーザシステム３は、仮想ＩｏＴシステム１に対して、自身のユースケースに応じたデータの提供を要求する。すなわち、ユーザシステム３は、ユーザが要求するデータを提供する仮想サイロ１１の作成を要求する。この要求には、ユーザが要求するデータの仕様（属性）、具体的には、対象エリアやデータの内容やデータの精度などに関する情報が含まれる。仮想ＩｏＴシステム１は、ユーザシステム３からの要求に応じて、ユーザのユースケースに応じた専用の仮想サイロ１１を作成する。

【0071】

仮想サイロ１１は、ブローカー１２に対して、ユーザが要求するデータを要求する。

【0072】

ブローカー１２は、ユーザが要求するデータを生成する仮想デバイスとして機能するシングバイザー１３を作成する。

【0073】

シングバイザー１３は、まず、ユーザが要求したデータを仮想デバイスにより生成するために必要な物理デバイス２およびその仕様（属性）を取得する。次に、シングバイザー１３は、ルートデータドメイン１４に対して、必要な物理デバイス２のデータを検索して、その検索結果に基づいて、物理デバイス２の不備を検知する。すなわち、必要な物理デバイス２のデータがルートデータドメイン１４にある場合には、シングバイザー１３は物理デバイス２に不備がないと判定する。一方、必要な物理デバイス２のデータがルートデータドメイン１４にない場合には、シングバイザー１３は物理デバイス２に不備があると判定する。

【0074】

このとき、シングバイザー１３は、物理デバイス２の不備として、物理デバイス２の不足（未設置）、すなわち、ユーザが要求するデータを生成する仮想デバイスに必要な種類の物理デバイス２が存在しないことを検知する。また、シングバイザー１３は、物理デバイス２の不備として、ユーザが要求するデータを生成する仮想デバイスに必要な物理デバイス２が存在するものの、その物理デバイス２が、ユーザが要求するデータの仕様（データの精度など）を満たしていないことを検知する。

【0075】

ここで、シングバイザー１３が、物理デバイス２に不備がないと判定すると、該当する物理デバイス２のデータをルートデータドメイン１４から取得する。このとき、単一の物理デバイス２のデータのみ必要であれば、その物理デバイス２のデータのみを取得する。また、複数の物理デバイス２のデータが必要であれば、その複数の物理デバイス２のデータを取得する。

【0076】

次に、シングバイザー１３が、仮想デバイスとして、物理デバイス２のデータに基づいて、ユーザが要求するデータを生成して、その仮想デバイスのデータを、ブローカー１２および仮想サイロ１１を経由してユーザシステム３に提供する。

【0077】

一方、図５に示すように、シングバイザー１３が、物理デバイス２の不備を検知すると、ブローカー１２および仮想サイロ１１を経由してユーザシステム３に対して、物理デバイス２の不備を報告する。

【0078】

このように本実施形態では、シングバイザー１３が、ユーザシステム３に対して、物理デバイス不備の報告を行うため、ユーザが、物理デバイス２の不備、すなわち、ユーザが要求するデータを仮想デバイスにより生成するために必要な物理デバイス２が整備されていないことを認識することができる。

【0079】

また、本実施形態では、シングバイザー１３が、ユーザシステム３に対する物理デバイス不備の報告として、必要な物理デバイス２が整備されていない旨を報告する他に、物理デバイス２の不備の詳細内容を報告する。

【0080】

ここで、物理デバイス２の不備として、物理デバイス２が不足している場合には、詳細内容として、不足している物理デバイス２の種類がユーザに報告される。また、物理デバイス２の不備として、必要な種類の物理デバイス２が存在するものの、その物理デバイス２の仕様が、ユーザが要求する仕様（属性）のデータを生成する上で十分でない場合には、その旨が詳細内容としてユーザに報告される。また、詳細内容として、既存の物理デバイス２の仕様がユーザに報告されるようにしてもよい。

【0081】

なお、シングバイザー１３が物理デバイス２の不備を検知した場合に、物理デバイス２に不備があることのみをユーザシステム３に報告する、すなわち、詳細内容を含まない物理デバイス不備の報告を行うようにしてもよい。

【0082】

このように本実施形態では、物理デバイス２の不備の詳細内容をユーザシステム３に報告するため、既存の物理デバイス２の仕様が、ユーザが要求するデータを仮想デバイスにより生成する上で十分でないことを、ユーザが認識することができる。

【0083】

また、本実施形態では、ユーザシステム３が、物理デバイス不備の報告をシングバイザー１３から受け取ると、ユーザがデータの仕様を初期のレベルから緩和できる場合には、データの仕様を緩和した上で、仮想ＩｏＴシステム１に対して再度データを要求する。

【0084】

ここで、データの仕様を緩和するとは、データの種類を変更したり、データの精度を下げたりすることである。例えば、データの初期の仕様として、データの種類が体感温度と指定されていたが、物理デバイス２としての風速計が設置されていないことから、温度計と風速計とを組み合わせた体感温度を検出する仮想デバイスの構築ができない場合には、データの種類が体感温度から気温に変更される。また、データの初期の仕様として、データの種類が温度と指定されると共に、データの精度が１０ｍ刻みと指定されていたが、物理デバイス２としての温度計が１０ｍ間隔で設置されていないことから、１０ｍ刻みの精度を確保ができない場合には、データの精度が１０ｍ刻みから１００ｍ刻みに変更される。

【0085】

また、ユーザシステム３が、仮想ＩｏＴシステム１に対して、データの仕様を緩和してデータの再要求を行っても、物理デバイス不備の報告を受け取る場合がある。この場合、ユーザシステム３は、データの仕様をさらに緩和してデータの再要求を行うようにしてもよい。また、データの仕様を緩和したデータの再要求を、物理デバイス不備の報告がなくなるまで繰り返すようにしてもよい。

【0086】

このように本実施形態では、ユーザが、データの仕様の緩和を許容できる場合には、ユーザシステム３が、データの仕様を緩和した上でデータの要求を再度行うことで、必要なデータを許容範囲内の仕様で収集することができる。

【0087】

また、シングバイザー１３が、ユーザシステム３に対して物理デバイス不備の報告を行う際に、物理デバイス２の不備の詳細内容として、既存の物理デバイス２の仕様をユーザシステム３に報告すると、ユーザシステム３が、既存の物理デバイス２の仕様を具体的に確認することができる。

【0088】

ここで、ユーザが、既存の物理デバイス２の仕様に適合するようにデータの仕様を緩和できる場合には、ユーザシステム３は、既存の物理デバイス２の仕様に適合したデータの仕様に変更した上で、仮想ＩｏＴシステム１に対してデータの再要求を行ってよい。これにより、ユーザシステム３は、データの再要求を１度行うだけで、所要のデータを収集することができる。

【0089】

また、本実施形態では、ユーザシステム３が、シングバイザー１３からの物理デバイス不備の報告を受け取ると、不備のある物理デバイス２の整備をユーザに促す出力を行う。例えば、ユーザシステム３を構成するスマートフォンに、不備のある物理デバイス２の整備を促す画面を表示する。これにより、物理デバイス２に不備がある場合に、速やかにユーザが自身で必要な物理デバイス２の整備に着手することができる。

【0090】

なお、ユーザがデータの仕様を初期のレベルから緩和できない場合には、ユーザ自身が必要な物理デバイス２を整備するようにすればよい。また、前記のように、データの仕様を緩和してデータを再要求しても、シングバイザー１３から物理デバイス不備の報告を受け取った場合には、ユーザは既存の物理デバイス２を利用して所要のデータを取得することを断念して、ユーザ自身が必要な物理デバイス２を整備するようにすればよい。

【0091】

また、このようにユーザ自身が必要な物理デバイス２を整備した場合、その物理デバイス２で検出されたデータを、他のユーザにも使用できるようにするとよい。その場合、物理デバイス２を整備したユーザに対してインセンティブを与える、例えば、クーポンを発行したり、デバイス利用に応じた利用料を徴収したり、他のユーザが設置した物理デバイス２のデータを使用する権限を付与したりすると、整備された物理デバイス２のデータの公開を促進できる。

【0092】

（第２実施形態）
次に、第２実施形態について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図６は、第２実施形態に係る仮想ＩｏＴ制御方法の概要を示すブロック図である。図７，図８は、第２実施形態に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図である。図７は、ユーザからの物理デバイス整備の要求に対して代行者が初期の仕様のままで物理デバイス２の整備を承諾した場合である。図８は、ユーザからの物理デバイス整備の要求に対して代行者が条件付きで物理デバイス２の整備を承諾した場合である。

【0093】

第１実施形態では、ユーザが要求したデータの取得に必要な物理デバイス２に不備がある場合に、データの仕様を緩和した上でデータの要求を再度行うものとした。また、ユーザがデータの仕様を緩和できない場合には、ユーザ自らが物理デバイス２の整備を行うものとした。

【0094】

一方、本実施形態では、図６に示すように、代行者が物理デバイス２の整備を行う。この代行者は、ユーザに代わって必要な物理デバイス２を整備する者であり、例えば、対象となる物理デバイス２が設置される場所（スマートシティなど）の管理者などである。

【0095】

図７に示すように、ユーザシステム３は、シングバイザー１３からの物理デバイス不備の報告を受け取ると、代行者システム５（代行者が運用するシステム）に対して直接、必要な物理デバイス２の整備を要求する。図７に示す例では、物理デバイス２の整備として、＃２の物理デバイス２の新設を代行者システム５に要求する。

【0096】

代行者システム５は、ユーザシステム３から物理デバイス整備の要求を受け取ると、不備のある物理デバイス２の整備を代行者に促す出力を行う。例えば、ユーザシステム３を構成するスマートフォンに、不備のある物理デバイス２の整備を促す画面を表示する。これにより、物理デバイス２に不備がある場合に、速やかに代行者が必要な物理デバイス２の整備に着手することができる。

【0097】

代行者は、ユーザからの物理デバイス整備の要求を承諾した場合には、その物理デバイス２の整備を実行する。このとき、物理デバイス２が未設置であれば、物理デバイス２の整備として、その物理デバイス２を新規に設置する。また、物理デバイス２の仕様が、ユーザが要求するデータの仕様を満たさない場合には、物理デバイス２の仕様のレベルを上げる改修を行う。

【0098】

なお、ユーザシステム３と代行者システム５との間のやり取りは、仮想ＩｏＴシステム１とは独立した通信媒体、例えば通常のＩＰネットワークで行うようにすればよい。また、ユーザシステム３が、物理デバイス２の整備をユーザに促す出力を行い、これに応じてユーザが、代行者に対して電子メールや電話で物理デバイス２の整備を依頼するようにしてもよい。

【0099】

このように本実施形態では、ユーザが代行者に必要な物理デバイス２の整備を要請することができるため、ユーザが自ら物理デバイス２を整備することが難しい場合でも、必要な物理デバイス２が整備されて、ユーザが必要とするデータを取得することができる。

【0100】

また、本実施形態では、図８に示すように、代行者システム５が、ユーザシステム３からの物理デバイス整備の要求で指定された物理デバイス２の整備が困難な場合に、ユーザシステム３に対して、物理デバイス２の仕様の緩和を条件にして物理デバイス２の整備を承諾する旨の条件付き整備承諾の通知を行うことができる。図８に示す例では、＃２の物理デバイス２の仕様の緩和を条件にして＃２の物理デバイス２の整備を承諾する旨がユーザシステム３に対して通知される。

【0101】

これにより、ユーザが要求するデータの初期の仕様では、代行者にとって、整備が必要な物理デバイス２の仕様のレベルが高すぎて、物理デバイス２の整備が困難な場合でも、ユーザが要求するデータの仕様が緩和されることで、整備が必要な物理デバイス２の仕様のレベルが代行者の許容範囲まで下がると、代行者による物理デバイス２の整備が可能となる。

【0102】

一方、ユーザシステム３は、代行者システム５からの条件付き整備承諾の通知を受け取った際に、データの仕様を初期のレベルから緩和できない場合には、物理デバイス２の整備を代行者に依頼することを断念して、ユーザ自身で物理デバイス２の整備を行うか、あるいはデータ提供そのものを断念してもよい。

【0103】

また、ユーザシステム３は、要求するデータの仕様を緩和する余地がある場合には、データの仕様を緩和した上で、代行者システム５に対して、再度、物理デバイス整備の要求を行う。代行者は、ユーザシステム３から提示された緩和された仕様で物理デバイス２の整備が可能であれば、物理デバイス２の整備に着手する。また、このとき、物理デバイス整備の報告（条件なしの整備承諾の通知）をユーザシステム３に対して行うようにしてもよい。

【0104】

このとき、ユーザシステム３が、代行者システム５から物理デバイス整備の報告を受け取るまで、代行者システム５からの条件付き整備承諾の通知に応じて、データの仕様を徐々に緩和して物理デバイス整備の要求を繰り返すようにてもよい。ここで、許容できる範囲内でデータの仕様を緩和しても、代行者システム５から物理デバイス整備の報告を受け取ることができない場合には、物理デバイス２の整備を代行者に依頼することを断念して、ユーザ自身で物理デバイス２の整備を行うか、あるいはデータ提供そのものを断念する。

【0105】

また、代行者システム５が、ユーザシステム３に対して、条件付き整備承諾の通知として、代行者が整備可能な物理デバイス２の仕様をユーザに提案するようにしてもよい。この場合、ユーザシステム３は、代行者システム５からの提案内容を受け入れることができる場合には、その提案内容の仕様、すなわち、代行者が整備可能な物理デバイス２の仕様で物理デバイス整備の要求を行えばよい。

【0106】

（第２実施形態の第１変形例）
次に、第２実施形態の第１変形例について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図９は、第２実施形態の第１変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図である。

【0107】

第２実施形態では、代行者システム５が、ユーザシステム３からの物理デバイス整備の要求を受け取ると、代行者に対して物理デバイス２の整備を促す出力を行うものとした。

【0108】

一方、本変形例では、代行者システム５が、ユーザシステム３からの物理デバイス整備の要求に基づいて、物理デバイス２の整備の可否を判定（整備判定）する。特に本変形例では、物理デバイス２の整備を行うための条件（整備条件）として、ユーザシステム３からの物理デバイス整備の要求の件数が所定のしきい値に達した場合に、物理デバイス２の整備が行われるようにする。ユーザシステム３からの物理デバイス整備の要求の件数がしきい値に達しない場合には、物理デバイス２の整備が保留される。

【0109】

図９に示す例では、物理デバイス整備の要求の件数に関するしきい値を３件としている。また、代行者システム５が、＃１，＃２，＃３のユーザシステム３から、＃２の物理デバイス整備の要求を順次受け取る。

【0110】

ここで、代行者システム５は、まず、＃１のユーザシステム３からの物理デバイス整備の要求を受け取るが、この段階では物理デバイス整備の要求が１件だけなので、物理デバイス２の整備は保留される。次に、代行者システム５が、＃２のユーザシステム３からの物理デバイス整備の要求を受け取るが、この段階でも物理デバイス整備の要求がまだ２件なので、物理デバイス２の整備は保留される。次に、代行者システム５が、＃３のユーザシステム３からの物理デバイス整備の要求を受け取ると、物理デバイス整備の要求が３件となり、物理デバイス整備の要求の件数がしきい値に達するので、物理デバイス２の整備が行われる。

【0111】

なお、代行者システム５は、物理デバイス２の整備が必要であると判定すると、不備のある物理デバイス２の整備を代行者に促す出力を行い、これに応じて代行者が、物理デバイス２の整備に着手する。

【0112】

このように本変形例では、物理デバイス整備の要求の件数が多い、すなわち、物理デバイス２の需要が高くなったところで、物理デバイス２が整備されるため、物理デバイス２の有効活用を図ることができる。

【0113】

また、本変形例では、代行者システム５が、複数のユーザシステム３の各々からの物理デバイス整備の要求で指定された物理デバイス２の仕様のうちで最もレベルが高い仕様（データ精度が最も高いなど）を選択（仕様決定）し、その選択された仕様で代行者により物理デバイス２の整備が行われるようにする。

【0114】

図９に示す例では、＃１のユーザシステム３からの物理デバイス整備の要求では、中レベルの仕様で＃２の物理デバイス２の整備が要求される。また、＃２のユーザシステム３からの物理デバイス整備の要求では、高レベルの仕様で＃２の物理デバイス２の整備が要求される。また、＃３のユーザシステム３からの物理デバイス整備の要求では、低レベルの仕様で＃２の物理デバイス２の整備が要求される。したがって、代行者は、＃２のユーザシステム３から要求された高レベルの仕様で＃２の物理デバイス２の整備を行う。なお、ここでは、レベルが高い仕様を高レベルの仕様、レベルの低い仕様を低レベルの仕様、高レベルの仕様と低レベルの仕様の間のレベルの仕様を中レベルの仕様と呼ぶ。また、以下でも、同様の内容の仕様を高レベルの仕様、低レベルの仕様および中レベルの仕様と呼ぶことがある。

【0115】

このように本変形例では、ユーザから要求された仕様のうちで最もレベルが高い仕様で物理デバイス２の整備が行われるため、全てのユーザに対して満足できるデータを提供することができる。

【0116】

（第２実施形態の第２変形例）
次に、第２実施形態の第２変形例について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図１０は、第２実施形態の第２変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図である。なお、図１０において、代行者システム５が＃１，＃２，＃３のユーザシステム３から物理デバイス整備の要求を順次受け取った後に整備判定を行う手順までは第２実施形態の第１変形例（図９参照）と同様である。

【0117】

第２実施形態の第１変形例では、代行者システム５が、複数のユーザシステム３の各々からの物理デバイス整備の要求で指定された物理デバイス２の仕様のうちで最もレベルが高い仕様を選択（仕様決定）して、物理デバイス２の整備が行われるものとした。

【0118】

一方、本変形例では、代行者システム５が、複数のユーザシステム３の各々からの物理デバイス整備の要求で指定された物理デバイス２の仕様のうちで最もレベルが高い仕様で物理デバイス２の整備ができるか否かを代行者に問い合わせ、最もレベルが高い仕様で物理デバイス２の整備ができない場合には、最もレベルが高い仕様からレベルを下げて整備が可能な仕様を選択（仕様決定）して、物理デバイス２の整備が行われる。

【0119】

図１０に示す例では、＃１，＃２，＃３のユーザシステム３の各々からの物理デバイス整備の要求で指定された物理デバイス２の仕様のうちで、＃２のシングバイザー１３から要求された高レベルの仕様が最もレベルが高い仕様となるが、この最もレベルが高い仕様で物理デバイス２の整備ができないため、中レベルの仕様で物理デバイス２の整備が行われる。

【0120】

このように本変形例では、最もレベルが高い仕様で物理デバイス２の整備ができない場合に、整備が可能な低いレベルの仕様で物理デバイス２の整備が行われるため、＃２のユーザシステム３にとってはレベルが不十分ではあるものの、必要な物理デバイス２の整備は促進することができる。

【0121】

また、本変形例では、代行者システム５が、最もレベルが高い仕様から整備が可能なレベルに下げた仕様を選択した場合、ユーザシステム３に対して、要求したデータの取得に必要となる物理デバイス２を整備した旨の物理デバイス整備の報告と、整備した物理デバイス２の仕様を、ユーザシステム３が要求した仕様より低いレベルの仕様に変更した旨の仕様変更の報告とを行う。

【0122】

このユーザシステム３に対する物理デバイス整備の報告および仕様変更の報告は、整備された物理デバイス２の仕様が要求したレベルより低いユーザシステム３を対象にして行われる。図１０に示す例では、高レベルの仕様で物理デバイス２の整備を要求した＃２のユーザシステム３に対して、代行者システム５が物理デバイス整備の報告と仕様変更の報告とを行う。

【0123】

このように本変形例では、代行者システム５が、ユーザシステム３に対して物理デバイス整備の報告を行うため、ユーザシステム３が要求したデータに必要となる物理デバイス２が整備されたことをユーザが把握することができる。また、代行者システム５が、ユーザシステム３に対して仕様変更の報告を行うため、整備した物理デバイス２の仕様が、ユーザシステム３が要求した仕様より低いレベルの仕様に変更されたことをユーザが把握することができる。

【0124】

（第３実施形態）
次に、第３実施形態について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図１１は、第３実施形態に係る仮想ＩｏＴ制御方法の概要を示すブロック図である。図１２は、第３実施形態に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図である。

【0125】

第２実施形態では、ユーザシステム３が、代行者システム５に対して、物理デバイス２の整備を要求するものとした。

【0126】

一方、本実施形態では、ブローカー１２が、代行者システム５に対して、物理デバイス整備の要求を行う。

【0127】

また、本実施形態では、ブローカー１２が、シングバイザー１３からの物理デバイス不備の報告に基づいて、代行者システム５に対する物理デバイス整備の要求の可否を判定（整備判定）する。特に本変形例では、物理デバイス２の整備を行うための条件（整備条件）として、シングバイザー１３からの物理デバイス不備の報告の件数が所定のしきい値に達した場合に、代行者システム５に対する物理デバイス整備の要求を行う。シングバイザー１３からの物理デバイス不備の報告の件数がしきい値に達しない場合には、物理デバイス整備の要求が保留される。なお、この処理は、第２実施形態の第１変形例と略同様である。

【0128】

図１２に示す例では、物理デバイス不備の報告の件数に関するしきい値を３件としている。また、ブローカー１２が、＃１，＃２，＃３のシングバイザー１３から、＃２の物理デバイス２に関する物理デバイス不備の報告を順次受け取る。

【0129】

ここで、ブローカー１２は、まず、＃１のシングバイザー１３からの物理デバイス不備の報告を受け取るが、この段階では物理デバイス不備の報告が１件だけなので、物理デバイス整備の要求は保留される。次に、ブローカー１２が、＃２のシングバイザー１３からの物理デバイス不備の報告を受け取るが、この段階でも物理デバイス不備の報告がまだ２件なので、物理デバイス整備の要求は保留される。次に、ブローカー１２が、＃３のシングバイザー１３からの物理デバイス不備の報告を受け取ると、物理デバイス不備の報告が３件となり、物理デバイス不備の報告の件数がしきい値に達するので、物理デバイス整備の要求が行われる。

【0130】

このように本実施形態では、物理デバイス不備の報告の件数が多い、すなわち、物理デバイス２の需要が高くなったところで、物理デバイス２が整備されるため、整備された物理デバイス２の有効活用を図ることができる。

【0131】

また、本実施形態では、ブローカー１２が、シングバイザー１３からの物理デバイス不備の報告を受け取ると、関係するユーザシステム３に対して、物理デバイス不備の報告を行う。

【0132】

また、本実施形態では、ブローカー１２が、所定の整備条件を満足しない場合、すなわち、シングバイザー１３からの物理デバイス不備の報告の件数が所定のしきい値に達していない場合には、代行者システム５に対する物理デバイス整備の要求を保留すると共に、関係するユーザシステム３に対して、物理デバイス不備の報告が所定件数揃えば代行者に対して物理デバイス整備の要求を行う旨の物理デバイス整備の予告を行う。

【0133】

また、本実施形態では、ブローカー１２が、シングバイザー１３からの物理デバイス不備の報告の件数がしきい値に達した場合には、代行者システム５に対して物理デバイス整備の要求を行うと共に、関係するユーザシステム３に対して、代行者システム５に対して物理デバイス整備の要求を行った旨の物理デバイス整備要求の報告を行う。

【0134】

図１２に示す例では、ブローカー１２が、まず、＃１のシングバイザー１３からの物理デバイス不備の報告を受け取るが、この段階では物理デバイス不備の報告が１件だけなので、物理デバイス整備の要求は保留される。このとき、ブローカー１２が、＃１のシングバイザー１３に関係する＃１のユーザシステム３に対して、＃２の物理デバイス２が不足している旨の物理デバイス不備の報告と、シングバイザー１３からの物理デバイス不備の報告があと２件揃えば代行者に対して物理デバイス２の整備を要求する旨の物理デバイス整備の予告とを行う。

【0135】

次に、ブローカー１２が、＃２のシングバイザー１３からの物理デバイス不備の報告を受け取るが、この段階でも物理デバイス不備の報告がまだ２件なので、物理デバイス整備の要求は保留される。このとき、＃２のシングバイザー１３に関係する＃２のユーザシステム３に対して、＃２の物理デバイス２が不足している旨の物理デバイス不備の報告と、物理デバイス不備の報告があと１件揃えば代行者に対して物理デバイス整備の要求を行う旨の物理デバイス整備の予告とを行う。また、ブローカー１２が、＃１のユーザシステム３に対して、物理デバイス不備の報告があと１件揃えば代行者に対して物理デバイス整備の要求を行う旨の物理デバイス整備の予告を行う。

【0136】

次に、ブローカー１２が、＃３のシングバイザー１３からの物理デバイス不備の報告を受け取ると、物理デバイス不備の報告が合計で３件となり、物理デバイス不備の報告の件数がしきい値に達するので、物理デバイス整備の要求が行われる。このとき、＃１，＃２のユーザシステム３に対して、物理デバイス不備の報告が３件揃ったので代行者に対して物理デバイス整備の要求を行った旨の物理デバイス整備要求の報告を行う。また、＃３のユーザシステム３に対して、物理デバイス不備の報告と、シングバイザー１３からの物理デバイス不備の報告が３件揃ったので代行者に対して物理デバイス整備の要求を行った旨の物理デバイス整備要求の報告とを行う。

【0137】

このように本実施形態では、ユーザシステム３に対して物理デバイス不備の報告が行われるため、物理デバイス２に不備があることをユーザが確認することができる。また、ユーザシステム３に対して物理デバイス整備の予告が行われるため、物理デバイス２の整備が行われる可能性があることをユーザが確認することができる。また、ユーザシステム３に対して物理デバイス整備の報告が行われるため、代行者に対して物理デバイス整備の要求を行ったことをユーザが確認することができる。

【0138】

また、本実施形態では、ブローカー１２が、複数のシングバイザー１３から物理デバイス不備の報告を受け取ると、関係する複数のユーザシステム３の各々から要求されたデータの仕様に対応する物理デバイス２の仕様のうちで最もレベルが高い仕様（データ精度が最も高いなど）を選択（仕様決定）して、代行者システム５に対して物理デバイス整備の要求を行う。なお、この処理は、第２実施形態の第１変形例と略同様である。

【0139】

図１２に示す例では、＃１のユーザシステム３から要求されたデータの仕様では、中レベルの仕様で＃２の物理デバイス２の整備が必要である。また、＃２のユーザシステム３から要求されたデータの仕様では、高レベルの仕様で＃２の物理デバイス２の整備が必要である。また、＃３のユーザシステム３から要求されたデータの仕様では、低レベルの仕様で＃２の物理デバイス２の整備が必要である。したがって、ブローカー１２は、＃２のユーザシステム３から要求されたデータの仕様に対応する高レベルの仕様で物理デバイス２の整備を行うように、代行者システム５に対して物理デバイス整備の要求を行う。

【0140】

このように本変形例では、ユーザから要求された仕様のうちで最もレベルが高い仕様で物理デバイス２の整備が行われるため、全てのユーザの要望を満足できるデータをユーザに提供することができる。

【0141】

また、本実施形態では、ブローカー１２が、関係するシングバイザー１３に対して、代行者システム５に対して物理デバイス整備の要求を行った旨の物理デバイス整備要求の報告を行う。なお、整備された物理デバイス２のデータがルートデータドメイン１４により収集（サブスクライブ）されれば、物理デバイス２が整備されたことをシングバイザー１３が認識できるようになるので、シングバイザー１３に対する物理デバイス整備要求の報告は省略されてもよい。

【0142】

なお、ブローカー１２が、代行者システム５に対して、物理デバイス整備の要求を行う際に、物理デバイス２の整備に関して代行者にインセンティブ（クーポンの発行など）を与えるようにしてもよい。これにより、必要な物理デバイス２の整備が促進される。

【0143】

（第３実施形態の第１変形例）
次に、第３実施形態の第１変形例について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図１３は、第３実施形態の第１変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図である。なお、図１３において、ブローカー１２が＃１，＃２，＃３のシングバイザー１３から物理デバイス不備の報告を順次受け取った後に整備判定を行う手順までは第３実施形態（図１２参照）と同様である。

【0144】

第３実施形態では、ブローカー１２が、複数のユーザシステム３の各々から要求されたデータの仕様に対応する物理デバイス２の仕様のうちで最もレベルが高い仕様を選択（仕様決定）して、代行者システム５に対して、物理デバイス整備の要求を行うものとした。また、代行者システム５は、ブローカー１２から要求された最もレベルが高い仕様で物理デバイス２の整備を行うように代行者を促すものとした。

【0145】

一方、本変形例では、代行者システム５が、ブローカー１２から要求された最もレベルが高い仕様で物理デバイス２の整備ができるか否かを代行者に問い合わせ、最もレベルが高い仕様で物理デバイス２の整備ができない場合には、最もレベルが高い仕様からレベルを下げて整備が可能な仕様を選択（仕様決定）して、物理デバイス２の整備が行われる。

【0146】

図１３に示す例では、＃１，＃２，＃３のユーザシステム３の各々から要求されたデータの仕様に対応する物理デバイス２の仕様のうちで、＃２のユーザシステム３から要求されたデータの仕様に対応する高レベルの仕様が最もレベルが高い仕様となり、ブローカー１２が、高レベルの仕様で物理デバイス２を整備するように物理デバイス整備の要求を代行者システム５に対して行う。そして、代行者システム５が、高レベルの仕様で物理デバイス２を整備できるか否かを代行者に問い合わせ、高レベルの仕様で物理デバイス２を整備できない場合には、＃１のユーザシステム３から要求されたデータの仕様に対応する中レベルの仕様で物理デバイス２の整備が行われるようにする。

【0147】

このように本変形例では、最もレベルが高い仕様で物理デバイス２の整備ができない場合に、整備が可能な低いレベルの仕様で物理デバイス２の整備を行うため、＃２のユーザシステム３にとってはレベルが不十分ではあるものの、物理デバイス２の整備は促進することができる。

【0148】

また、本変形例では、代行者システム５が、ブローカー１２から要求された最もレベルが高い仕様からレベルを下げて整備が可能な仕様を選択した場合、ブローカー１２に対して、ブローカー１２が要求した物理デバイス２の整備を行う旨の物理デバイス整備の報告と、整備した物理デバイス２の仕様を、ブローカー１２が要求した仕様より低いレベルの仕様に変更した旨の仕様変更の報告とを行う。

【0149】

ブローカー１２は、代行者システム５からの物理デバイス整備の報告と仕様変更の報告とを受け取ると、関係するユーザシステム３に対して、物理デバイス整備の報告と仕様変更の報告とを行う。

【0150】

図１３に示す例では、代行者システム５が、物理デバイス整備の報告と仕様変更の報告とをブローカー１２に対して行う。また、ブローカー１２が、物理デバイス整備の報告と仕様変更の報告とを＃１，＃２，＃３のユーザシステム３に対して行う。

【0151】

このように本実施形態では、代行者システム５が、ブローカー１２を経由してユーザシステム３に対して、物理デバイス整備の報告と仕様変更の報告とを行うため、ユーザシステム３が要求したデータを仮想デバイスにより生成するために必要な物理デバイス２を整備したことをユーザが把握することができ、また、整備した物理デバイス２の仕様が、ユーザシステム３が要求した仕様より低いレベルの仕様に変更されたことをユーザが把握することができる。

【0152】

（第３実施形態の第２変形例）
次に、第３実施形態の第２変形例について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図１４は、第３実施形態の第２変形例に係る仮想ＩｏＴ制御方法の概要を示すブロック図である。図１５は、第３実施形態の第２変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図である。なお、図１５において、ブローカー１２が＃１，＃２，＃３のシングバイザー１３から物理デバイス不備の報告を順次受け取った後に整備判定を行う手順までは第３実施形態（図１２参照）と同様である。

【0153】

第３実施形態では、ブローカー１２が、物理デバイス２の整備を行うための条件（整備条件）が満たされる、すなわち、シングバイザー１３からの物理デバイス不備の報告の件数が所定のしきい値（例えば３件）に達すると、代行者システム５に対して物理デバイス２の整備を要求するものとした。

【0154】

一方、本変形例では、ブローカー１２が、整備条件が満たされると、必要な物理デバイス２を整備する代行者を公募し、公募に応えた立候補者の中から代行者を選定して、その代行者が運用する代行者システム５に対して物理デバイス２の整備を要求する。なお、公募に応えた立候補者や、立候補者の中から代行者に選定された者に対して、何らかのインセンティブが与えられるようにすると、立候補を促進することができる。

【0155】

特に本変形例では、ＷＥＢシステム７を利用して代行者を公募し、ブローカー１２が、ＷＥＢシステム７に対して代行者公募の依頼を行う。この代行者公募の依頼には、整備を要求する物理デバイス２の仕様などが含まれる。このＷＥＢシステム７は、代行者を公募するサイトを運用し、立候補者システム８（立候補者が運用するシステム）がＷＥＢシステム７にアクセスすることで、代行者を公募するサイトを立候補者が閲覧することができる。

【0156】

図１５に示す例では、ブローカー１２が、シングバイザー１３からの物理デバイス不備の報告の件数がしきい値（３件）に達したので、ＷＥＢシステム７に対して代行者公募の依頼を行う。

【0157】

ＷＥＢシステム７は、ブローカー１２からの代行者公募の依頼を受け取ると、代行者の公募を行う。この公募では、必要な物理デバイス２の仕様を提示して立候補者を募集する。なお、本実施形態では、ＷＥＢシステム７を利用して代行者の公募を行うようにしたが、このような構成に限定されず、その他のシステムを利用して代行者の公募を行うようにしてもよい。

【0158】

立候補者システム８は、立候補者が公募に応募する場合、ブローカー１２に対して、立候補の通知を行う。

【0159】

ブローカー１２は、立候補者システム８からの立候補の通知を受け取ると、所定の選定基準に基づいて、立候補者を代行者に選定する。そして、ブローカー１２は、立候補者システム８に対して、代行者として物理デバイス２の整備を行うように依頼する旨の物理デバイス整備の要求を行う。

【0160】

ここで、立候補者が複数あれば、ブローカー１２は、最も条件のよい立候補者を代行者に選定する。このとき、物理デバイス２の整備に係る費用や、物理デバイス２の整備に要する期間や、物理デバイス２の整備および保守に関する実績や、整備される物理デバイス２の品質などに基づいて、代行者の選定が行われる。

【0161】

なお、立候補者が代行者に選定されると、立候補者システム８は代行者システム５として扱われ、ブローカー１２からの物理デバイス整備の要求を受け取る。

【0162】

このように本変形例では、ブローカー１２にとって代行者が不明なために、代行者に対して物理デバイス２の整備を要請できない場合でも、公募により代行者を見つけ出して、物理デバイス２の整備を要請することができる。また、特定者しか物理デバイス２を設置できない環境でない場合に、公募により代行者を見つけ出すことで、最良の条件で物理デバイス２の整備を要請することができる。

【0163】

（第３実施形態の第３変形例）
次に、第３実施形態の第３変形例について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図１６は、第３実施形態の第３変形例に係る仮想ＩｏＴ制御方法の概要を示すブロック図である。図１７は、第３実施形態の第３変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図である。

【0164】

第３実施形態では、ブローカー１２が、代行者システム５に対する物理デバイス整備の要求の可否を判定して、整備条件として、シングバイザー１３からの物理デバイス不備の報告の件数が所定のしきい値に達した場合に、代行者システム５に対する物理デバイス整備の要求を行うものとした。

【0165】

一方、本変形例では、ユーザシステム３が、共通する物理デバイス２の整備を必要とする他のユーザシステム３との間で、代行者システム５に対する物理デバイス整備の要求の可否に関する調整を行い、その調整結果に基づいて、代行者システム５に対する物理デバイス整備の要求を行う。

【0166】

このとき、代行者システム５に対して物理デバイス整備の要求を行うための条件（例えば、関係するユーザ数）や、代行者システム５に対して物理デバイス整備の要求を行う主体となるユーザシステム３の選定や、物理デバイス整備の要求の相手となる代行者システム５の選定や、要求する物理デバイス２の仕様（例えば、高、中、低のいずれかのレベル）などに関して、関係する複数のユーザシステム３間で調整が行われる。

【0167】

なお、ユーザシステム３間で行われる調整は、ユーザが介在せずにユーザシステム３自体が他のユーザシステム３との間での調整処理を行うようにしてもよいが、ユーザ同士が電子メールや電話などの適宜な通信手段を用いて調整を行い、その調整結果をユーザが各自のユーザシステム３に入力するものとしてもよい。

【0168】

また、本変形例では、ブローカー１２が、複数のユーザシステム３が、共通する物理デバイス２の整備を必要とする場合に、各ユーザシステム３に対して、他のユーザシステム３の連絡先（例えば、メールアドレスなど）を通知する。

【0169】

図１７に示す例では、ブローカー１２が、まず、＃１のシングバイザー１３からの物理デバイス不備の報告を受け取るが、この段階では、関係するユーザシステム３が＃１のユーザシステム３の１つだけである。そこで、ブローカー１２が、物理デバイス２に不備がある旨の物理デバイス不備の報告を、＃１のユーザシステム３のみに対して行う。

【0170】

次に、ブローカー１２が、＃２のシングバイザー１３からの物理デバイス不備の報告を受け取ると、関係するユーザシステム３が＃１のユーザシステム３と＃２のユーザシステム３との２つとなる。そこで、ブローカー１２が、＃２のユーザシステム３に関する連絡先の通知を、＃１のユーザシステム３に対して行う。また、ブローカー１２が、物理デバイス２に不備がある旨の物理デバイス不備の報告と、＃１のユーザシステム３に関する連絡先の通知とを、＃２のユーザシステム３に対して行う。これにより、＃１のユーザシステム３および＃２のユーザシステム３が、相互に連絡先を把握することができるので、２者間で代行者システム５に対する物理デバイス整備の要求の可否に関する調整を行うことができる。ここでは、＃１のユーザシステム３と＃２のユーザシステム３とで調整を行った結果、もう１人揃うまで、代行者システム５に対する物理デバイス整備の要求を待つものとする。

【0171】

次に、ブローカー１２が、＃３のシングバイザー１３からの物理デバイス不備の報告を受け取ると、関係するユーザシステム３が＃１のユーザシステム３と＃２のユーザシステム３と＃３のユーザシステム３との３つとなる。そこで、ブローカー１２が、＃３のユーザシステム３に関する連絡先の通知を、＃１のユーザシステム３に対して行う。また、ブローカー１２が、＃３のユーザシステム３に関する連絡先の通知を、＃２のユーザシステム３に対して行う。また、ブローカー１２が、物理デバイス２に不備がある旨の物理デバイス不備の報告と、＃１のユーザシステム３および＃２のユーザシステム３に関する連絡先の通知とを、＃３のユーザシステム３に対して行う。これにより、＃１のユーザシステム３、＃２のユーザシステム３および＃３のユーザシステム３が、相互に連絡先を把握することができるので、３者間で代行者システム５に対する物理デバイス整備の要求の可否に関する調整を行うことができる。ここでは、＃１のユーザシステム３と＃２のユーザシステム３と＃３のユーザシステム３とで調整を行った結果、代行者システム５に対する物理デバイス整備の要求を＃２のユーザシステム３が行うものとする。

【0172】

なお、本変形例では、ユーザが、関係する他のユーザとの間で調整を行い、その調整結果に基づいて、代行者に対して物理デバイス整備を要請するものとしたが、ユーザ間での調整により、共通する物理デバイス２の整備を必要とするユーザ自身が物理デバイス２を整備するものとしてもよい。この場合、複数のユーザのうちの１人が単独で物理デバイス２を整備するものとしてもよく、また、複数のユーザが共同で物理デバイス２を整備するものとしてもよい。

【0173】

このように本変形例では、ユーザシステム３が、共通する物理デバイス２の整備を必要とする他のユーザシステム３との間で、物理デバイス２の整備に関する調整を行うため、必要な物理デバイス２の整備が円滑に行われる。また、ブローカー１２が、ユーザシステム３に対して、関係する他のユーザシステム３の連絡先を通知するため、関係する複数のユーザシステム３が、相互に連絡先を把握して調整を円滑に行うことができる。

【0174】

（第４実施形態）
次に、第４実施形態について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図１８は、第４実施形態に係る仮想ＩｏＴ制御方法の概要を示すブロック図である。図１９は、第４実施形態に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図である。

【0175】

第２実施形態では、ユーザシステム３が、代行者システム５に対して、物理デバイス２の整備を要求するものとした。また、第３実施形態では、ブローカー１２が、代行者システム５に対して、物理デバイス２の整備を要求するものとした。

【0176】

一方、本実施形態では、シングバイザー１３が、代行者システム５に対して、物理デバイス２の整備を要求する。代行者システム５は、シングバイザー１３からの物理デバイス整備の要求を受け取ると、その要求で指定された仕様で物理デバイス２の整備を行うように代行者を促す出力を行う。

【0177】

ここで、物理デバイス不備の報告は、単に物理デバイス２に不備がある旨の情報だけを含むものとしてもよいが、不備のある物理デバイス２に関係する情報、すなわち、不備のある物理デバイス２の種類（温度計など）、必要な物理デバイス２が設置されていない区域、既設の物理デバイス２の仕様上の不備（精度不足や密度不足など）などに関する情報を含むようにしてもよい。

【0178】

また、本実施形態では、代行者システム５が、シングバイザー１３からの物理デバイス整備の要求に基づいて、物理デバイス２の整備の可否を判定（整備判定）する。特に本実施形態では、物理デバイス２の整備を行うための条件（整備条件）として、シングバイザー１３からの物理デバイス整備の要求の件数が所定のしきい値に達した場合に、物理デバイス２の整備が行われるようにする。シングバイザー１３からの物理デバイス整備の要求の件数がしきい値に達しない場合には、物理デバイス２の整備が保留される。なお、この処理は、第２実施形態の第１変形例と同様である。

【0179】

図１９に示す例では、物理デバイス整備の要求の件数に関するしきい値を３件としている。また、代行者システム５が、＃１，＃２，＃３のシングバイザー１３から、＃２の物理デバイス２に関する物理デバイス整備の要求を順次受け取る。

【0180】

ここで、代行者システム５は、まず、＃１のシングバイザー１３からの物理デバイス整備の要求を受け取るが、この段階では物理デバイス整備の要求が１件だけなので、物理デバイス２の整備は保留される。次に、代行者システム５が、＃２のシングバイザー１３からの物理デバイス整備の要求を受け取るが、この段階でも物理デバイス整備の要求がまだ２件なので、物理デバイス２の整備は保留される。次に、代行者システム５が、＃３のシングバイザー１３からの物理デバイス整備の要求を受け取ると、物理デバイス整備の要求が３件となり、物理デバイス整備の要求の件数がしきい値に達するので、物理デバイス２の整備が行われる。

【0181】

このように本実施形態では、物理デバイス整備の要求の件数が多い、すなわち、物理デバイス２の需要が高くなったところで、物理デバイス２が整備されるため、物理デバイス２の有効活用を図ることができる。

【0182】

また、本実施形態では、代行者システム５が、複数のシングバイザー１３の各々からの物理デバイス整備の要求で指定された物理デバイス２の仕様のうちで最もレベルが高い仕様を選択（仕様決定）し、その選択された仕様で代行者により物理デバイス２の整備が行われるようにする。この処理は、第２実施形態の第１変形例と同様である。

【0183】

図１９に示す例では、＃１のシングバイザー１３からの物理デバイス整備の要求では、中レベルの仕様で＃２の物理デバイス２の整備が要求される。また、＃２のシングバイザー１３からの物理デバイス整備の要求では、高レベルの仕様で＃２の物理デバイス２の整備が要求される。また、＃３のシングバイザー１３からの物理デバイス整備の要求では、低レベルの仕様で＃２の物理デバイス２の整備が要求される。したがって、代行者は、＃２のシングバイザー１３から要求された高レベルの仕様で物理デバイス２の整備を行う。

【0184】

このように本実施形態では、ユーザから要求された仕様のうちで最もレベルが高い仕様で物理デバイス２の整備が行われるため、全てのユーザに対して満足できるデータを提供することができる。

【0185】

（第４実施形態の変形例）
次に、第４実施形態の変形例について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図２０は、第４実施形態の変形例に係る仮想ＩｏＴ制御方法の手順を示すシーケンス図である。なお、図２０において、代行者システム５が、＃１，＃２，＃３のシングバイザー１３からの物理デバイス整備の要求を順次受け取った後に整備判定を行う手順までは第４実施形態（図１９参照）と同様である。

【0186】

第４実施形態では、代行者システム５が、複数のシングバイザー１３の各々からの物理デバイス整備の要求で指定された物理デバイス２の仕様のうちで最もレベルが高い仕様を選択（仕様決定）して、物理デバイス２の整備が行われるものとした。

【0187】

一方、本変形例では、代行者システム５が、複数のシングバイザー１３の各々からの物理デバイス整備の要求で指定された物理デバイス２の仕様のうちで最もレベルが高い仕様で物理デバイス２の整備ができるか否かを代行者に問い合わせ、最もレベルが高い仕様で物理デバイス２の整備ができない場合には、最もレベルが高い仕様からレベルを下げて整備が可能な仕様を選択（仕様決定）して、物理デバイス２の整備が行われる。この処理は、第２実施形態の第２変形例と同様である。

【0188】

また、本変形例では、代行者システム５が、最もレベルが高い仕様からレベルを下げた仕様で物理デバイス２の整備を行う場合に、要求元の各シングバイザー１３に対して、要求した物理デバイス２を整備した旨の物理デバイス整備の報告と、整備した物理デバイス２の仕様を、シングバイザー１３から要求された最もレベルが高い仕様より低いレベルの仕様に変更した旨の仕様変更の報告とを行う。

【0189】

図２０に示す例では、代行者システム５が、要求元の＃１，＃２，＃３の各シングバイザー１３に対して、物理デバイス整備の報告と仕様変更の報告とを行う。

【0190】

さらに、本変形例では、シングバイザー１３が、ユーザシステム３に対して、要求したデータの取得に必要となる物理デバイス２を整備した旨の物理デバイス整備の報告と、整備した物理デバイス２の仕様を、ユーザシステム３が要求した仕様より低いレベルの仕様に変更した旨の仕様変更の報告とを行う。

【0191】

このユーザシステム３に対する物理デバイス整備の報告および仕様変更の報告は、整備された物理デバイス２の仕様が要求したレベルより低いユーザシステム３を対象にして行われる。図２０に示す例では、高レベルの仕様で物理デバイス２の整備を要求した＃２のユーザシステム３に対して、＃２のシングバイザー１３が物理デバイス整備の報告と仕様変更の報告とを行う。

【0192】

なお、実際に整備される物理デバイス２の仕様が、ユーザシステム３が要求したレベル以上であるユーザシステム３、図２０に示す例では、＃１，＃３のユーザシステム３に対しても、物理デバイス整備の報告および仕様変更の報告を行うものとしてもよい。

【0193】

このように本実施形態では、レベルを下げた仕様で物理デバイス２の整備が行われることから、一部のユーザの要望が満たされない場合があるが、その要望が満たされないユーザに対して、レベルを下げた仕様で物理デバイス２の整備が行われる旨の報告が行われるため、ユーザ自身が要望した仕様より低いレベルの仕様で物理デバイス２の整備が行われることを、ユーザが確認することができる。

【0194】

以上のように、本出願において開示する技術の例示として、実施形態を説明した。しかしながら、本開示における技術は、これに限定されず、変更、置き換え、付加、省略などを行った実施形態にも適用できる。また、上記の実施形態で説明した各構成要素を組み合わせて、新たな実施形態とすることも可能である。

【産業上の利用可能性】

【0195】

本発明に係る仮想ＩｏＴ制御方法および仮想ＩｏＴシステムは、物理デバイスの不備、すなわち、ユーザが要求するデータを生成する仮想デバイスに必要な物理デバイスが整備されていない状態を、仮想ＩｏＴシステムから提供されるデータを利用するユーザや、対象エリアの管理者などに認識させて、必要な物理デバイスの整備を促進することができる効果を有し、ＩｏＴを構成する物理デバイスから収集されたデータに基づいて、ユーザが要求するデータを仮想デバイスにより生成して、そのデータをユーザシステムに提供する仮想ＩｏＴ制御方法および仮想ＩｏＴシステムなどとして有用である。

【符号の説明】

【0196】

１ 仮想ＩｏＴシステム
２ 物理デバイス
３ ユーザシステム
５ 代行者システム
７ ＷＥＢシステム
８ 立候補者システム
１１ 仮想サイロ（インタフェース部）
１２ ブローカー（中継制御部）
１３ シングバイザー（仮想デバイス部）
１４ ルートデータドメイン（データ収集部）

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】