IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ BizMobile株式会社の特許一覧

特許7027650IoT接続システム、情報処理方法およびコンピュータプログラム
<>
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図1
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図2
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図3
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図4
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図5
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図6
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図7
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図8
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図9
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図10
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図11
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図12
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図13
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図14
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図15
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図16
  • 特許-IoT接続システム、情報処理方法およびコンピュータプログラム 図17
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-02-21
(45)【発行日】2022-03-02
(54)【発明の名称】IoT接続システム、情報処理方法およびコンピュータプログラム
(51)【国際特許分類】
   H04L 41/085 20220101AFI20220222BHJP
   H04L 12/46 20060101ALI20220222BHJP
   H04L 12/66 20060101ALI20220222BHJP
【FI】
H04L41/085
H04L12/46 Z
H04L12/66
【請求項の数】 10
(21)【出願番号】P 2020023198
(22)【出願日】2020-02-14
(65)【公開番号】P2021129227
(43)【公開日】2021-09-02
【審査請求日】2021-09-06
【新規性喪失の例外の表示】特許法第30条第2項適用 ・2019年5月29日 場所:パレスホテル東京 ・2019年6月 6日 URL:https://www.iis.u-tokyo.ac.jp/ja/news/3110/ ・2020年1月27日 刊行物:電気新聞
【早期審査対象出願】
(73)【特許権者】
【識別番号】509266125
【氏名又は名称】IoT-EX株式会社
(74)【代理人】
【識別番号】100185971
【弁理士】
【氏名又は名称】高梨 玲子
(72)【発明者】
【氏名】松村 淳
【審査官】木村 雅也
(56)【参考文献】
【文献】国際公開第2018/163087(WO,A1)
【文献】特表2020-500346(JP,A)
【文献】相互接続IoTプラットフォーム,シーテック 2019,日本,2019年10月15日,第1頁-第2頁
(58)【調査した分野】(Int.Cl.,DB名)
H04L 41/085
H04L 12/46
H04L 12/66
(57)【特許請求の範囲】
【請求項1】
クラウド上で実現されるIoTハブ、および、ローカルにあり前記IoTハブと接続されるIoTルータを備えるIoT接続システムであって、
前記IoTハブは、第一のデバイスが接続可能なプライベートクラウドと当該IoTハブとを接続するための第一のドライバ、または、第二のデバイスと当該IoTハブとを接続するための第二のドライバの少なくとも一方を有し、
前記IoTルータは、第三のデバイスと当該IoTルータとを接続するための第三のドライバを有し、
前記IoTハブは、
前記第一のデバイス、前記第二のデバイスおよび前記第三のデバイスならびに前記IoTハブを介して利用可能なIoTサービスを相互に常時接続させるための常時接続機能と、
前記第一のデバイス、前記第二のデバイスおよび前記第三のデバイスならびに前記IoTサービスを相互に連携させるためのディレクトリ機能であって、連携元のデバイスにより指定された連携先のデバイスを、デバイスの識別情報、ドライバの識別情報および接続界面の識別情報に基づいて特定するディレクトリ機能
を実現するIoT接続システム。
【請求項2】
前記ディレクトリ機能は、
前記第一のデバイス、前記第二のデバイスまたは前記第三のデバイスあるいは前記IoTサービスを特定し、かつ、前記第一のデバイス、前記第二のデバイスまたは前記第三のデバイスあるいは前記IoTサービスに指示することを特徴とする請求項1に記載のIoT接続システム。
【請求項3】
前記ディレクトリ機能は、さらに、前記連携先のデバイスを、前記IoTハブの識別情報に基づいて特定することを特徴とする請求項1または2に記載のIoT接続システム。
【請求項4】
前記デバイスの識別情報、前記ドライバの識別情報および前記接続界面の識別情報は、所定の記憶装置に記憶され、
前記記憶装置は、さらに、
接続を許可しない接続元デバイスの識別情報および/またはデバイスの機能をホワイトリストとして記憶することを特徴とする請求項1、2または3に記載のIoT接続システム。
【請求項5】
前記第一のドライバ、前記第二のドライバおよび前記第三のドライバの少なくとも一つは、
前記第一のデバイス、前記第二のデバイスまたは前記第三のデバイスを仮想的に再現する仮想デバイス機能を実現することを特徴とする請求項1から4のいずれか一項に記載のIoT接続システム。
【請求項6】
前記IoTハブは、さらに、
IoTアプリケーションを利用するためのWebAPIを有することを特徴とする請求項1から5のいずれか一項に記載のIoT接続システム。
【請求項7】
前記第一のデバイス、前記第二のデバイスまたは前記第三のデバイスから取得される情報は、前記IoTハブでは保存されないことを特徴とする請求項1から6のいずれか一項に記載のIoT接続システム。
【請求項8】
前記IoTルータは、管理者装置により遠隔操作が可能であることを特徴とする請求項1から7のいずれか一項に記載のIoT接続システム。
【請求項9】
クラウド上で実現されるIoTハブ、および、ローカルにあり前記IoTハブと接続されるIoTルータを備えるIoT接続システムにおける情報処理方法であって、
前記IoTハブは、第一のデバイスが接続可能なプライベートクラウドと当該IoTハブとを接続するための第一のドライバ、または、第二のデバイスと当該IoTハブとを接続するための第二のドライバの少なくとも一方を有し、
前記IoTルータは、第三のデバイスと当該IoTルータとを接続するための第三のドライバを有し、
前記IoTハブは、
前記第一のデバイス、前記第二のデバイスおよび前記第三のデバイスならびに前記IoTハブを介して利用可能なIoTサービスを相互に常時接続させる常時接続ステップと、
前記第一のデバイス、前記第二のデバイスおよび前記第三のデバイスならびに前記IoTサービスを相互に連携させるディレクトリステップであって、連携元のデバイスにより指定された連携先のデバイスを、デバイスの識別情報、ドライバの識別情報および接続界面の識別情報に基づいて特定するディレクトリステップ
を実行する情報処理方法。
【請求項10】
クラウド上で実現されるIoTハブ、および、ローカルにあり前記IoTハブと接続されるIoTルータを備えるIoT接続システムで実行されるコンピュータプログラムであって、
前記IoTハブは、第一のデバイスが接続可能なプライベートクラウドと当該IoTハブとを接続するための第一のドライバ、または、第二のデバイスと当該IoTハブとを接続するための第二のドライバの少なくとも一方を有し、
前記IoTルータは、第三のデバイスと当該IoTルータとを接続するための第三のドライバを有し、
前記IoTハブに、
前記第一のデバイス、前記第二のデバイスおよび前記第三のデバイスならびに前記IoTハブを介して利用可能なIoTサービスを相互に常時接続させるための常時接続機能と、
前記第一のデバイス、前記第二のデバイスおよび前記第三のデバイスならびに前記IoTサービスを相互に連携させるためのディレクトリ機能であって、連携元のデバイスにより指定された連携先のデバイスを、デバイスの識別情報、ドライバの識別情報および接続界面の識別情報に基づいて特定するディレクトリ機能
を実現させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、IoT接続システム、情報処理方法およびコンピュータプログラムに関する。
【背景技術】
【0002】
近年、インターネットに接続して様々なサービスを受けることが可能なデバイスが増加し始めている。このようなデバイスは、IoT(Internet of Things)デバイスと呼ばれる。
【0003】
このようなIoTデバイスは、それぞれが専用のプライベートクラウドに接続されるのが一般的であるため、通常、異なるメーカにより製造された、仕様の異なるIoTデバイスは同じプライベートクラウドには接続することができない。
【0004】
近年では、クラウドへの接続のためのAPI(Application Programing Interface)を公開したり、SDK(Software Development kit)等を提供したりすることで、様々なメーカのIoTデバイスを接続させることが可能なIoTハブと呼ばれるIoTクラウドサービスも提供されている(非特許文献1、非特許文献2等)。
【先行技術文献】
【非特許文献】
【0005】
【文献】“Azure IoT Hub”、Microsoft社、[令和1年6月2日検索]、インターネット<https://azure.microsoft.com/ja-jp/services/iot-hub/>
【文献】“AWS IoT”、Amazon Web Services社、[令和1年6月2日検索]、インターネット<https://aws.amazon.com/jp/iot/>
【発明の概要】
【発明が解決しようとする課題】
【0006】
上記のようなIoTクラウドサービスは存在するものの、各サービス間での連携は限られており、IoTデバイスの事業者はサービス毎に異なる専用の接続用プログラムを開発し、デバイスに組み込む必要があった。
【0007】
そのため、本開示の目的は、プライベートクラウドごとにサイロ化状態になっている暮らしのIoTを、インターネットを介して自由に相互接続して魅力的なサービスを提供することを目的とする。
【課題を解決するための手段】
【0008】
本開示の実施形態におけるIoT接続システムは、クラウド上で実現されるIoTハブ、および、ローカルにありIoTハブと接続されるIoTルータを備えるIoT接続システムであって、IoTハブは、第一のデバイスが接続可能なプライベートクラウドと当該IoTハブとを接続するための第一のドライバ、または、第二のデバイスと当該IoTハブとを接続するための第二のドライバの少なくとも一方を有し、IoTルータは、第三のデバイスと当該IoTルータとを接続するための第三のドライバを有し、IoTハブは、第一のデバイス、第二のデバイスおよび第三のデバイスならびにIoTハブを介して利用可能なIoTサービスを相互に常時接続させるための常時接続機能と、第一のデバイス、第二のデバイスおよび第三のデバイスならびにIoTサービスを相互に連携させるためのディレクトリ機能とを実現することを特徴とする。
【0009】
ディレクトリ機能は、第一のデバイス、第二のデバイスまたは第三のデバイスあるいはIoTサービスを特定し、かつ、第一のデバイス、第二のデバイスまたは第三のデバイスあるいはIoTサービスに指示することができる。
【0010】
ディレクトリ機能は、連携元のデバイスにより指定された連携先のデバイスを、デバイスの識別情報、ドライバの識別情報および接続界面の識別情報に基づいて特定することができる。
【0011】
ディレクトリ機能は、さらに、連携先のデバイスを、IoTハブの識別情報に基づいて特定することができる。
【0012】
デバイスの識別情報、ドライバの識別情報および接続界面の識別情報は、所定の記憶装置に記憶され、記憶装置は、さらに、接続を許可しない接続元デバイスの識別情報および/またはデバイスの機能をホワイトリストとして記憶することができる。
【0013】
第一のドライバ、第二のドライバおよび第三のドライバの少なくとも一つは、第一のデバイス、第二のデバイスまたは第三のデバイスを仮想的に再現する仮想デバイス機能を実現することができる。
【0014】
IoTハブは、さらに、IoTアプリケーションを利用するためのWebAPIを有することができる。
【0015】
第一のデバイス、第二のデバイスまたは第三のデバイスから取得される情報は、IoTハブでは保存されないものとすることができる。
【0016】
IoTルータは、管理者装置により遠隔操作が可能とすることができる。
【0017】
本開示の実施形態における情報処理方法は、クラウド上で実現されるIoTハブ、および、ローカルにありIoTハブと接続されるIoTルータを備えるIoT接続システムにおける情報処理方法であって、IoTハブは、第一のデバイスが接続可能なプライベートクラウドと当該IoTハブとを接続するための第一のドライバ、または、第二のデバイスと当該IoTハブとを接続するための第二のドライバの少なくとも一方を有し、IoTルータは、第三のデバイスと当該IoTルータとを接続するための第三のドライバを有し、IoTハブは、第一のデバイス、第二のデバイスおよび第三のデバイスならびにIoTハブを介して利用可能なIoTサービスを相互に常時接続させる常時接続ステップと、第一のデバイス、第二のデバイスおよび第三のデバイスならびにIoTサービスを相互に連携させるディレクトリステップとを実行することを特徴とする。
【0018】
本開示の実施形態におけるコンピュータプログラムは、クラウド上で実現されるIoTハブ、および、ローカルにありIoTハブと接続されるIoTルータを備えるIoT接続システムで実行されるコンピュータプログラムであって、IoTハブは、第一のデバイスが接続可能なプライベートクラウドと当該IoTハブとを接続するための第一のドライバ、または、第二のデバイスと当該IoTハブとを接続するための第二のドライバの少なくとも一方を有し、IoTルータは、第三のデバイスと当該IoTルータとを接続するための第三のドライバを有し、IoTハブに、第一のデバイス、第二のデバイスおよび第三のデバイスならびにIoTハブを介して利用可能なIoTサービスを相互に常時接続させるための常時接続機能と、第一のデバイス、第二のデバイスおよび第三のデバイスならびにIoTサービスを相互に連携させるためのディレクトリ機能とを実現させることを特徴とする。
【発明の効果】
【0019】
本開示によれば、プライベートクラウドごとにサイロ化状態になっている暮らしのIoTを、インターネットを介して自由に相互接続して魅力的なサービスを提供することができる。
【0020】
本開示の一実施形態によれば、直接接続されたIoTデバイス同士のみならず、従来のプライベートクラウドに接続されたIoTデバイス同士も、容易に相互接続させることが可能となる。
【0021】
また、本開示の一実施形態によれば、停電等においてIoTデバイスがネットワークに接続できない状態であっても、サービスの継続が可能なIoT接続システム、コンピュータプログラムおよび情報処理方法を提供することができる。
【図面の簡単な説明】
【0022】
図1】本開示の実施形態に係るIoT接続システムの構成の一例を示したシステム構成図である。
図2】本開示の実施形態に係るIoT接続システムの複数のプライベートクラウドの一例を示したイメージ図である。
図3】本開示の実施形態に係るIoT接続システムのプライベートクラウドに接続される複数の第一のデバイスの一例を示したイメージ図である。
図4】本開示の実施形態に係るIoT接続システムで提供されるサービスの流れの一例を示したイメージ図である。
図5】本開示の実施形態にかかるIoTルータのハードウェア構成を示すハードウェア構成図である。
図6】本開示の実施形態に係るIoT接続システムで提供されるサービスの流れの一例を示したイメージ図である。
図7】本開示の実施形態に係るIoT接続システムの接続界面を説明するためのイメージ図である。
図8】本開示の実施形態に係るIoT接続システムで提供されるサービスの流れの他の例を示したイメージ図である。
図9】本開示の実施形態に係るIoT接続システムで提供される仮想ドライバ機能の流れの一例を示したイメージ図である。
図10】本開示の実施形態に係るIoT接続システムで提供される仮想ドライバ機能の流れの他の例を示したイメージ図である。
図11】本開示の実施形態に係る情報処理方法のフローの一例を示したフロー図である。
図12】本開示の実施形態に係るIoTルータの構成および回路構成を示す構成図である。
図13】本開示の他の実施形態に係るサポートシステムの構成の一例を示したシステム構成図である。
図14】本開示の他の実施形態に係るサポート方法のフローの一例を示したフロー図である。
図15】本開示の他の実施形態に係るメニュー票の一例を示した概念図である。
図16】本開示の他の実施形態に係るメニュー票の一例を示した概念図である。
図17】本開示の他の実施形態に係るメニュー票の一例を示した概念図である。
【発明を実施するための形態】
【0023】
初めに、本開示の実施形態におけるIoT接続システムの実施形態について、図面を参照しながら説明する。
【0024】
図1に示すように、本開示の実施形態におけるIoT接続システム100は、IoTハブ200およびIoTルータ300を備えるものとする。
【0025】
IoTハブ200は、クラウド上で実現されるものとする。具体的には、IoTハブ200は、クラウド内でホストされているマネージドサービスであり、IoTアプリケーション(以下「IoTアプリ」という。)とIoTデバイスとの間の双方向通信に対する中継器として機能する。
【0026】
IoTルータ300は、ローカルにあり、IoTハブ200とWAN(Wide Area Network)により接続されるものとする。
【0027】
具体的には、IoTルータ300は、宅内ネットワークなどインターネットに接続されていないIoTデバイスがIoTハブ200に接続することを実現するものである。
【0028】
そして、IoTハブ200は、第一のドライバ210または第二のドライバ220の少なくとも一方を有する。
【0029】
第一のドライバ210および第二のドライバ220は、各IoTデバイスのメーカごとの仕様の違いを吸収するものである。
【0030】
第一のドライバ210は、第一のデバイス410が接続可能なプライベートクラウド400と当該IoTハブ200とを接続するためのものである
【0031】
一例として、第一のデバイス410とプライベートクラウド400とはLAN(Local Area Network)による接続とし、プライベートクラウド400と第一のドライバ210とはWANによる接続とするのが好ましい。
【0032】
プライベートクラウド400は、第一のデバイス410の事業者により提供されるものである。図1ではプライベートクラウド400が一つである場合が示されているが、この数は一つに限られるものではなく、複数のプライベートクラウド400がIoTハブ200に接続されることができる。また、IoTハブ200は、複数の第一のドライバ210を有してもよい。
【0033】
図2は、異なる事業者A,Bにより提供される2つのプライベートクラウド400A,400Bの詳細を示したものである。図2に示されるように、プライベートクラウド400Aは、事業者Aが提供するアプリケーションA(以下、「アプリA」とする。)と接続され、第一のデバイス410に対してアプリAによるサービスを提供するものである。
【0034】
同様に、プライベートクラウド400Bは、事業者Bが提供するアプリケーションB(以下、「アプリB」とする。)と接続され、第一のデバイス410に対してアプリBによるサービスを提供するものである。
【0035】
なお、図1、2ではプライベートクラウド400に第一のデバイス410が一つだけ接続されている例が示されているが、図3に示すように、一つのプライベートクラウド400に複数の第一のデバイス410が接続されてもよい。
【0036】
第一のデバイス410は、事業者がプライベートクラウドを提供しているデバイスとすることができる。一例として、リモートロック機能を有する電子錠、AIスピーカ、リモート操作が可能な介護ベッドなどが挙げられるが、特にこれらに限定されるものではない。
【0037】
図1に戻り、第二のドライバ220は、第二のデバイス510とIoTハブ200とを直接接続するためのものである。
【0038】
第二のデバイス510は、インターネット上にあるIoTハブ200とWANにより接続されることができる(LAN経由でもよい)。
【0039】
なお、図1では第二のドライバ220に第二のデバイス510が一つだけ接続されている例が示されているが、一つの第二のドライバ220に複数の第二のデバイス510が接続されてもよい。また、IoTハブ200は複数の第二のドライバ220を有してもよい。
【0040】
第二のデバイス510は、事業者がプライベートクラウドを提供していないデバイスとすることができる。一例として、扇風機、エアコン、窓、カーテン、照明などとすることができるが、特にこれらに限定されるものではない。
【0041】
そして、IoTルータ300は、第三のドライバ310を有する。また、IoTルータ300は、複数の第三のドライバ310を有してもよい。
【0042】
第三のドライバ310は、第三のデバイス610と当該IoTルータ300とを接続するためのものである。
【0043】
一例として、第三のデバイス610と第三のドライバ310とはLANによる接続とし、IoTルータ300とIoTハブ200とはWANによる接続とするのが好ましい。
【0044】
第三のデバイス610は、上述したとおり、宅内ネットワークなどインターネットに接続されていないIoTデバイスとすることができる。また、第三のデバイス610は、セキュリティ、プライバシーおよびセーフティ上の観点で、直接IoTハブ200と接続すべきでないデバイスとすることができる。一例として、ガスコンロ、顔認証デバイス、センサ情報収集用データロガーなどとすることができるが、特にこれに限定されるものではない。ただし、後述する災害時のリスク低減の観点から、どのようなデバイスであっても第三のデバイス610としてIoTルータ300へ接続させるようにしてもよい。
【0045】
このように、本発明のIoT接続システム100は、すべてのデバイスをクラウド上のIoTハブ200に直接的に接続させるものではなく、一部のデバイスをローカル上のIoTルータ300に接続させるハイブリッドタイプのIoT接続システムである。
【0046】
以上によれば、直接接続されたIoTデバイス同士のみならず、従来のプライベートクラウドに接続されたIoTデバイス同士も、容易に相互接続させることが可能となる。
【0047】
これにより、決まったメーカのIoTデバイス同士しか繋がっていなかった従来とは異なり、様々なメーカのIoTデバイスを容易に相互接続させることができる。また、様々なメーカのIoTデバイスを相互接続させることにより、従来にはなかったユニークなサービスを創造することができるようになる。
【0048】
例えば、本発明のIoT接続システム100によれば、図4に示すように、外部のサーバからの緊急地震速報を受信したら、ガスコンロに消火信号を送り、玄関ドアのカギを解錠するといったサービスを実現することも容易に可能である。
【0049】
ここで、図5を用いて、情報処理端末(IoTハブ)200のハードウェア構成について説明する。情報処理端末200は、プロセッサ201と、メモリ202と、ストレージ203と、入出力インターフェース(入出力I/F)204と、通信インターフェース(通信I/F)205とを含むことができる。各構成要素は、バスBを介して相互に接続される。
【0050】
情報処理端末200は、プロセッサ201と、メモリ202と、ストレージ203と、入出力I/F204と、通信I/F205との協働により、本実施形態に記載される機能、方法を実現することができる。
【0051】
プロセッサ201は、ストレージ203に記憶されるプログラムに含まれるコード又は命令によって実現する機能、及び/又は、方法を実行する。プロセッサ201は、例えば、中央処理装置(CPU)、MPU(Micro Processing Unit)、GPU(Graphics Processing Unit)、マイクロプロセッサ(microprocessor)、プロセッサコア(processor core)、マルチプロセッサ(multiprocessor)、ASIC(Application-Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)等を含み、集積回路(IC(Integrated Circuit)チップ、LSI(Large Scale Integration))等に形成された論理回路(ハードウェア)や専用回路によって各実施形態に開示される各処理を実現してもよい。また、これらの回路は、1又は複数の集積回路により実現されてよく、各実施形態に示す複数の処理を1つの集積回路により実現されることとしてもよい。また、LSIは、集積度の違いにより、VLSI、スーパーLSI、ウルトラLSI等と呼称されることもある。
【0052】
メモリ202は、ストレージ203からロードしたプログラムを一時的に記憶し、プロセッサ201に対して作業領域を提供する。メモリ202には、プロセッサ201がプログラムを実行している間に生成される各種データも一時的に格納される。メモリ202は、例えば、RAM(Random Access Memory)、ROM(Read Only Memory)等を含む。
【0053】
ストレージ203は、プログラムを記憶する。ストレージ203は、例えば、HDD(Hard Disk Drive)、SSD(Solid State Drive)、フラッシュメモリ等を含む。
【0054】
通信I/F205は、ネットワークアダプタ等のハードウェアや通信用ソフトウェア、及びこれらの組み合わせとして実装され、ネットワークを介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F205は、ネットワークを介して、他の情報処理装置との通信を実行する。通信I/F205は、各種データをプロセッサ201からの指示に従って、他の情報処理装置に送信する。また、通信I/F205は、他の情報処理装置から送信された各種データを受信し、プロセッサ201に伝達する。
【0055】
入出力I/F204は、情報処理端末200に対する各種操作を入力する入力装置、及び、情報処理端末200で処理された処理結果を出力する出力装置を含む。入出力I/F304は、入力装置と出力装置が一体化していてもよいし、入力装置と出力装置とに分離していてもよい。
【0056】
入力装置は、ユーザからの入力を受け付けて、当該入力に係る情報をプロセッサ201に伝達できる全ての種類の装置のいずれか、又は、その組み合わせにより実現される。入力装置は、例えば、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ(画像を介した操作入力)、マイク(音声による操作入力)を含む。
【0057】
出力装置は、プロセッサ201で処理された処理結果を出力する。出力装置は、例えば、タッチパネル、スピーカ等を含む。
【0058】
上記IoTルータ300についても、上記IoTハブ200と同様のハードウェア構成とすることができる。
【0059】
また、IoTルータ300は、所定の基地局と通信可能な情報処理端末とするのが好ましい。
【0060】
所定の基地局と通信可能な情報処理端末は、一例として、スマートフォンやタブレット端末などのSIMカードを挿入して用いる情報処理端末である。IoTルータ300とIoTハブ200との間の通信容量はひと月に100Mバイト以下の低容量であることから、IoTルータ300には通信容量が少ない低額なSIMカードを挿入すれば足りる。
【0061】
また、IoTルータ300は、バッテリを含むものとする。かかるバッテリは、充電することにより電力を蓄えることができるものである。IoTルータ300は、満充電から3日程度は、電源に接続せずに本開示における機能を実現することができる。平常時(後述する特定の状況下に無い場合)には、IoTルータ300は、電源に接続して使用されるものとする。
【0062】
そして、第三のデバイス610は、特定の状況下において、IoTルータ300が備えるテザリング機能によりIoTハブ200に接続されることができる。
【0063】
特定の状況は、第三のデバイス610と所定の無線/有線LANとの接続が途絶えた状況などとすることができるが、これに限られるものではない。
【0064】
この特定の状況に陥る原因としては、停電が挙げられるが、これに限られるものではなく、Wi-Fi(登録商標)ルータの故障や接続不良等などが原因である場合もある。
【0065】
また、テザリング機能としては公知の技術を用いることができ、Wi-Fiテザリング、Bluetooth(登録商標)テザリング、USBテザリングなどの手法を用いることができる。
【0066】
以上の構成によれば、プライベートクラウドごとにサイロ化状態になっている暮らしのIoTを、インターネットを介して自由に相互接続して魅力的なサービスを提供することができる。
【0067】
具体的には、本開示によれば、直接接続されたIoTデバイス同士のみならず、従来のプライベートクラウドに接続されたIoTデバイス同士も、容易に相互接続させることが可能となる。
【0068】
また、以上の構成によれば、第三のデバイス610が、特定の状況下において、IoTルータ300が備えるテザリング機能によりIoTハブ200に接続されることで、災害等においてIoTデバイスがネットワークに接続できない状態であっても、サービスを継続して利用することができるようになる。
【0069】
また、IoTルータ300は、管理者装置によりRemote Control(遠隔操作)が可能なものとするのが好ましい。かかる構成によれば、IoTルータの一つ一つをフルサポートすることができるようになる。
【0070】
なお、上記遠隔操作は、管理者装置およびIoTルータ300の双方に専用のアプリケーションをインストールしておくことで実現される。なお、遠隔操作のサポートのし易さを考慮して、IoTルータ300としての情報処理端末は、Android端末を用いるのが好ましい。
【0071】
また、IoTルータ300は、管理者装置によりCDM(Connected Device Management:多様なデバイス管理)されるものとするのが好ましい。かかるCDMは、既知のMDM(Mobile Device Management)の手法を用いて実現されることができる。かかる構成によれば、膨大数の世帯に設置されるIoTルータを即時に一元管理し、遠隔監視・更新することができるようになる。また、CDMにより、デバイスの設定やアプリの配布、更新を遠隔監視制御することができるようになる。これにより、コスト削減と業務効率化を実現することができる。
【0072】
また、IoTハブ200へは認証されたアプリやデバイスしか接続できないが、IoTルータ300は、IoTハブ200をローカル(宅内等)に延長し、ローカルでなければ実現できないリアルタイム性、セキュリティやプライバシーの確保、通信量の削減などに対応させることができる。
【0073】
また、IoTルータ300を情報処理端末とすることで、顧客のスマートフォンや家庭内のインターネット回線線を使用する必要がなくなり、想定外のトラブルが発生するリスクを低減させることができる。
【0074】
また、本発明のIoT接続システム100は、第一のドライバ210、第二のドライバ220および第三のドライバ310を作成するのにユーザが記述すべき情報は、デバイス定義およびコマンド定義に関する情報に限られてもよい。
【0075】
ここで、第一のドライバ210、第二のドライバ220および第三のドライバ310を作成する方法について説明を行う。なお、作成者は、IoTデバイスの製造開発に関するユーザ、あるいは、本発明のIoT接続システムの提供に関するユーザとすることができる。
【0076】
なお、第一のドライバ210および第二のドライバ220と、第三のドライバ310とは、同内容の情報が記述されればよく、プログラミング言語が異なるものであってもよい。
【0077】
初めに、作成者は、デバイス定義として、利用機器一覧を定義する。一例として、利用機器として「気象センサ」、「屋内センサ」、「屋外センサ」、「不審者センサ」、「承認センサ」、「電力センサ」を定義する場合には、これらの名称およびそのIDとなる「weather」、「inhouse」、「outdoor」、「security」、「approve」、「power」を記述する。
【0078】
続いて、作成者は、コマンド定義として、利用可能コマンドを定義する。一例として、「屋外センサ」の利用可能コマンドを定義する場合には、センサ値の観測コマンドを記述する。観測コマンドは、一例として、「観測」,「ゲット」,「屋外を観測します」などとすることができる。
【0079】
以上のデバイス適宜およびコマンド定義に関する情報を、作成者が穴埋め形式でプログラムに埋めていくことにより、第一のドライバ210、第二のドライバ220、第三のドライバ310を完成させることができる。その他の部分については、SDKとして提供者から提供されることができる。
【0080】
SDK部分は、受信したコマンドでのデバイス操作処理に関する部分、収集したセンサデータ/操作結果データの前処理に関する部分、IoTハブへのデータ送信処理に関する部分を含むものとする。
【0081】
以上の構成によれば、様々な形態のIoTデバイスに対するドライバを簡易に完成させることができるため、IoTデバイスを柔軟にかつ容易に接続可能なIoT接続システムを実現することが可能となる。
【0082】
通常、デバイスの開発に係るエンジニアは、Web開発のエンジニアとは取得している技術の分野が異なり、デバイスをIoTハブに繋ぐことができる技術レベルを有していない者も多い。
【0083】
そのため、本開示のように、どのドライバ用プログラムに対しても共通の穴埋め形式の簡易な手法で作成が可能であることは、非常に有益である。これにより、IoTデバイスのIoTハブへの接続に係る開発コストや開発期間を従来よりも抑えることができる。
【0084】
また、開発コストの低減により、扇風機とエアコンのように掛けられるコストの許容値に差がある場合であっても、平等にIoTハブへの接続を実現することができる。
【0085】
続いて、本開示におけるIoT接続システム100に係るIoTハブ200とIoTアプリとの接続について説明する。
【0086】
図1に示されているように、IoTハブ200は、IoTアプリ700を利用するためのWebAPI230を有することができる。なお、図1に示すように、IoTアプリ700はサービスの数だけ接続されることができ、それぞれがWebAPI230を使用して接続されることができる。
【0087】
IoTアプリ700は、アプリ内にIoTデバイス(センサ)からのデータ取得ロジックおよび/またはIoTデバイスの操作ロジックを記述することで作成される。
【0088】
データ取得ロジックは、取得したセンサデータの前処理を行う部分と、IoTハブ200のAPIへの送信を行う部分とで構成される。必要な情報は、IoT接続システム100の運営者から提供される接続先URL、運営者から提供されるAPIキー、デバイス情報および実行コマンドである。
【0089】
デバイスの操作ロジックは、操作したいデバイスコマンドの前処理を行う部分と、IoTハブ200のAPIへの送信を行う部分とで構成される。必要な情報は、IoT接続システム100の運営者から提供される接続先URL、運営者から提供されるAPIキー、デバイス情報および実行コマンドである。
【0090】
図6は、IoTサービス利用者(エンドユーザ)が、IoTデバイス事業者により提供されたIoTデバイスを用いて、IoTサービス提供事業者からIoTサービスの提供を受けるフローを示した図である。図6に示すように、初めに第一のデバイス410からイベントの通知があると、プライベートクラウド400、第一のドライバ210、WebAPI230、IoTアプリ700を介してエンドユーザにイベントが通知される。
【0091】
続いて、エンドユーザがアクションを決定すると、IoTアプリ700、WebAPI230、第二のドライバ220を介して第二のデバイス510にアクションの実行が指示される。
【0092】
IoTデバイスの連携は、「~がこうなったら〇〇する」といったイベント駆動型のプログラムで表現することができる。そして、この処理をマイクロサービスとして部品化し、共通化して使えるようにしたうえで、FaaS(Function as a Service)の関数として実装することができる。
【0093】
ところで、上述したIoTデバイスである第一のデバイス~第三のデバイスは、近年のIoT分野の発展により様々なメーカにより開発・製造されることとなった。しかしながら、デバイスまたはIoTアプリとの常時接続は、Google社またはApple社等の大手ベンダーが提供するプッシュ通知用サービスのためのサーバに接続可能なデバイスに限られるという問題があった。
【0094】
本開示におけるIoTハブ200は、すべてのIoTデバイスの連携を目的として、常時接続機能と、ディレクトリ機能とを実現することを特徴とする。
【0095】
常時接続機能は、第一のデバイス410、第二のデバイス510および第三のデバイス610ならびにIoTハブ200を介して利用可能なIoTサービス(IoTアプリ700)を相互に常時接続させるものである。
【0096】
ただし、IoTハブに接続されるIoTデバイスには、常時接続が必須でないものと、必須なものの2種類がある。前者には、定期的または不定期的に情報を発信するセンサ系のデバイスが含まれる。後者には、リモコン操作を行う必要がある制御可能装置のようなデバイスが含まれる。よって、本開示における上記常時接続機能は、後者の常時接続が必須のIoTデバイスに対しては常時接続を、前者の常時接続が必須でないIoTデバイスに対しては求められた時に限定した接続を実現すればよい。
【0097】
常時接続機能は、本開示におけるIoTハブ200と第一のデバイス410、第二のデバイス510および第三のデバイス610ならびにIoTサービス700とを、IoT向けのMQTT(Message Queue Telemetry Transport)等の通信プロトコルを用いることで実現することができる。
【0098】
また、ディレクトリ機能は、第一のデバイス410、第二のデバイス510および第三のデバイス610ならびにIoTサービスを相互に連携させる。
【0099】
すなわち、ディレクトリ機能は、あるモノ(デバイス)からあるサービスへ、あるサービスからあるモノへ、あるモノからあるモノへ、モノまたはサービスを特定し、モノまたはサービスへ指示する機能を実現するものである。
【0100】
そして、ディレクトリ機能は、連携元のデバイスにより指定された連携先のデバイスを、デバイスの識別情報、ドライバの識別情報および接続界面の識別情報に基づいて特定することができる。
【0101】
デバイスの識別情報は、IoTデバイスのUUID(Universally Unique Identifier)である。ドライバの識別情報は、ドライバのIDである。接続界面の識別情報は、ドライバとIoTハブとの界面であるR界面を特定するための情報である。
【0102】
また、ディレクトリ機能は、さらに、連携先のデバイスを、IoTハブ200の識別情報に基づいて特定することができる。
【0103】
なお、デバイスの識別情報、ドライバの識別情報および接続界面の識別情報は、所定の記憶装置に記憶され、当該記憶装置は、さらに、接続を許可しない接続元デバイスの識別情報および/またはデバイスの機能をホワイトリストとして記憶することができる。かかるリストについては、後述するサポート方法のメニュー票を利用することができる。
【0104】
図7は、本開示におけるIoT接続システムにおける相互接続インフラの構造を示した概念図である。図7に示すように、アプリケーションとして示されるIoTアプリとIoTハブとの接続面はP界面であるが、WebAPI(α、β、γ)を使用して接続することで標準化されたQ界面持つことができる。
【0105】
同様に、IoTデバイスとIoTハブとの接続面はS界面であるが、ドライバ(A~Z)を使用して接続することで標準化されたR界面を持つことができる。
【0106】
従来、IoTアプリはIoTデバイスの組み込みアプリと情報の授受を行うために、IoTアプリ側で宛先となるIoTデバイスを指定する必要があるとともに、IoTデバイス側でもIoTアプリから指定が可能な識別情報を持つ必要があった。
【0107】
一方、本開示のIoT接続システムにおいて、上記宛先の指定はIoTハブにより実現されるディレクトリ機能により行われる。
【0108】
例えば、IoTデバイスの追加や交換は、IoTハブにドライバを追加して接続先を追加または切り替えることのみで対応可能となり、IoTアプリ自体を修正する必要がない。
【0109】
すなわち、IoTアプリにおいて必要であったIoTデバイスを指定する宛先部分、および、IoTデバイスにおいて必要であったIoTアプリから指定が可能な識別情報部分は、いずれのIoTハブに集約されることができる。
【0110】
そのため、IoTデバイスの追加や交換は、アプリ開発者の工数を増やすことはなく、コストの低減につながる。
【0111】
このように、本開示におけるIoT接続システムによれば、IoTデバイスの製造メーカや機種が異なっても、IoTハブに接続されることでプロトコルフリーな相互接続を実現することが可能となる。
【0112】
また、図8に示すように、本発明のIoTハブ200は、関所エンジン800と接続されることができる。この関所エンジン800は、IoTハブ200がデバイスに指示する内容をチェックし、不適切なアクションが実行されることを防ぐためのものである。
【0113】
例えば、“外気が爽やかなら、エアコンを止めて窓を開ける”、といったIoTサービスを提供する場合、直後にゲリラ豪雨に見舞われると室内が濡れてしまうおそれがあるが、上記関所エンジン800は、このようなIoT由来の脅威を未然に防ぐためのものである。
【0114】
また、本発明の第一のドライバ210、第二のドライバ220および第三のドライバ310の少なくとも一つは、仮想デバイス機能を実現することができる。
【0115】
この仮想デバイス機能は、第一のデバイス410、第二のデバイス510または第三のデバイス610を仮想的に再現するものである。
【0116】
図9は、本発明の第二のドライバ220が仮想デバイス機能を実現する例を示したものである。図9に示すように、第二のドライバ220に、第二のデバイス510のコマンドの送受信を再現可能な仮想デバイス900を設けることにより、仮に第二のデバイス510が接続されていなくても、第二のデバイス510を用いるIoTアプリの開発が可能となる。また、動作不良があった場合、現地に赴かずとも第二のデバイス510とIoTハブ200のどちらが故障しているのか故障切り分けを容易に行うことができる。
【0117】
また、本発明では、図10に示すように、ドライバではなくIoTハブ200に仮想デバイス機能を実現させてもよい。これは、ローカルに存在するIoTルータ300に接続される第三のデバイス610の故障切り分けに有効な手段である。
【0118】
上述したとおり、本開示におけるIoTハブは、異なる通信プロトコルを使用するクラウド間であっても、ドライバと呼ばれるインターフェースによって、それらの相互接続を可能とするプロトコルフリーのインフラである。また、ディレクトリ機能によって、複数のアプリやIoTデバイスを複雑に組み合わせて接続をすることも可能である。
【0119】
一例として、本開示におけるIoTハブは、電気自動車の充電サービスに適用することも可能である。
【0120】
近年、家庭で太陽光発電を行い、余剰となった発電を電気自動車に充電するということが一般的に行われている。通勤等で使用されている電気自動車は、車庫に帰還した際にユーザが所定の充電プラグを挿すことにより充電が開始される。
【0121】
しかしながら、通常は昼間帯に発生する余剰発電発生の時点において、ユーザは電気自動車とともに自宅にはいない場合が多く、適切なタイミングで電気自動車を充電することは難しいという課題がある。
【0122】
そのため、街中に設置された充電スポット等で電気自動車を充電することが可能であるが、自宅で余剰発電が発生しているにも関わらず、充電スポットで電気を購入しなくてはならないという不都合が生じることになる。
【0123】
かかる不都合は、本開示のIoT接続システムの適用により解消が可能である。具体的には、自宅の発電システムに余剰発電を検知するIoTセンサを設置する。かかるIoTセンサにより余剰発電が検知された場合、本開示におけるIoTハブを介して、他の充電装置に接続された電気自動車の充電が開始される。
【0124】
このように、本開示のIoT接続システムによれば、異なる事業者により提供される太陽光発電システムと電気自動車の充電サービスのようなサービスを連携させることができるようになる。
【0125】
続いて、本開示における情報処理方法の実施形態について図面を参照しながら説明する。
【0126】
本開示における情報処理方法は、図11に示されるように、クラウド上で実現されるIoTハブ、および、ローカルにありIoTハブと接続されるIoTルータを備えるIoT接続システムにおける情報処理方法であって、IoTハブに、常時接続ステップS240と、ディレクトリステップS250とを実行させることを特徴とする。
【0127】
IoTハブは、図1に示したように、第一のデバイスが接続可能なプライベートクラウドと当該IoTハブとを接続するための第一のドライバ、または、第二のデバイスと当該IoTハブとを接続するための第二のドライバの少なくとも一方を有し、IoTルータは、第三のデバイスと当該IoTルータとを接続するための第三のドライバを有する。
【0128】
常時接続ステップS240では、第一のデバイス、第二のデバイスおよび第三のデバイスならびにIoTハブを介して利用可能なIoTサービスを相互に常時接続させる。
【0129】
ディレクトリステップS250では、第一のデバイス、第二のデバイスおよび第三のデバイスならびにIoTサービスを相互に連携させる。
【0130】
以上によれば、直接接続されたIoTデバイス同士のみならず、従来のプライベートクラウドに接続されたIoTデバイス同士も、容易に相互接続させることが可能となる。
【0131】
続いて、本開示におけるコンピュータプログラムの実施形態について図面を参照しながら説明する。
【0132】
本開示におけるコンピュータプログラムは、クラウド上で実現されるIoTハブ、および、ローカルにありIoTハブと接続されるIoTルータを備えるIoT接続システムで実行されるコンピュータプログラムであって、IoTハブに、常時接続機能と、ディレクトリ機能とを実現させることを特徴とする。
【0133】
IoTハブは、第一のデバイスが接続可能なプライベートクラウドと当該IoTハブとを接続するための第一のドライバ、または、第二のデバイスと当該IoTハブとを接続するための第二のドライバの少なくとも一方を有する。
【0134】
IoTルータは、第三のデバイスと当該IoTルータとを接続するための第三のドライバを有する。
【0135】
常時接続機能は、第一のデバイス、第二のデバイスおよび第三のデバイスならびにIoTハブを介して利用可能なIoTサービスを相互に常時接続させる。
【0136】
ディレクトリ機能は、第一のデバイス、第二のデバイスおよび第三のデバイスならびにIoTサービスを相互に連携させる。
【0137】
以上によれば、直接接続されたIoTデバイス同士のみならず、従来のプライベートクラウドに接続されたIoTデバイス同士も、容易に相互接続させることが可能となる。
【0138】
上記機能は、図12に示す常時接続回路1240、ディレクトリ回路1250により実現されることができる。
【0139】
また、本発明のIoT接続システム100において、第一のデバイス410、第二のデバイス510または第三のデバイス610から取得される情報は、IoTハブ200では保存されないものとすることができる。
【0140】
本発明のIoT接続システム100は、電気通信事業者により運営されることを想定している。電気通信事業者は、通信の秘密を遵守する義務が課せられるため、各種デバイスから取得される情報を、他の利活用を目的として保存することはしない。
【0141】
これら情報は有益な情報であるため、各社のプライベートクラウドではかかる情報を独占的に取得すべく、IoTデバイスの囲い込みを行うのが通常である。
【0142】
一方で、本発明のIoT接続システム100は、運営を電気通信事業者が行うことにより、各IoTデバイスおよびIoTアプリを中立の立場で相互接続させ、IoTビジネスを促進させることができる。
【0143】
また、IoT相互接続サービスの継続性は利用する企業のIoTサービスの継続性に影響するため、利用企業が共同で相互接続インフラを共有するのが好ましい。
【0144】
また、本発明のIoT接続システム100において、IoTハブ200に接続できるのはAPIキーと認証スキームにより許可されたデバイスやIoTアプリのみとすることができる。すなわち、本発明のIoT接続システム100は、インターネット上にIoT通信専用の閉域網を構築することができる。また、通信経路も暗号化され、MDM(Mobile Device Management)の手法を用いてIoTルータも管理するため、新たな攻撃方法やOSやアプリの脆弱性対応も可能とする。
【0145】
また、IoT化されていないデバイスをIoTハブ200に接続するには、BaaS(Backend as a service)やSDKを活用することで、短期間での開発を行うことができる。
【0146】
また、IoT接続システム100の提供者は、IoTデバイスの相互接続支援サービスを提案することができる。具体的には、ビジネスマッチング、コンサルティングサービスを提供することができる。すなわち、付加価値を追加するために、必要な相手を探し、価値創出パターンとベストプラクティスを紹介するなどを行うことができる。
【0147】
また、他社のデバイスやアプリと組み合わせることで魅力的なサービスを創出し、付加価値を訴求することでビジネスを拡大することができる。
【0148】
続いて、本開示における他の実施形態であるサポート方法の実施形態について、説明する。
【0149】
本開示の他の実施形態におけるサポート方法は、複数のデバイスが接続されたIoTハブを介して、複数のデバイスの機能を組み合わせた新たなサービスの創造をサポートするサポート方法である。
【0150】
上記サポート方法は、図13に示すサポートシステムにおいて実行される。図13に示すサポートシステム1000は、情報処理装置1110と、ユーザ側端末1120と、管理者側端末1130とを備えることができる。
【0151】
以下、連携の申し込みを行う接続事業者(B社)を第一のユーザ、当該第一のユーザが連携を申し込む先の接続事業者(A社)を第二のユーザ、これら第一のユーザおよび第二のユーザの間を仲介する事業者(C社)を第三のユーザとして説明を行う。
【0152】
一例として、第一のユーザは顔認証デバイスを提供するユーザであり、第二のユーザは電子錠デバイスを提供するユーザであるものとする。
【0153】
そして、第一のユーザは、顔認証デバイスの機能である顔認証機能と、電子錠デバイスの機能である扉の錠の開閉機能とを連携させて、顔認証機能により許可された際に扉の錠を開ける、というサービスを創造しようとしている者とする。
【0154】
ここで、本発明のサポート方法は、図14に示すように、情報処理装置1110に抽出ステップS1を実行させる。
【0155】
抽出ステップS1は、IoTハブに接続された複数のデバイスの中から、ユーザ(第一のユーザ)が求める機能を実現可能な少なくとも一のデバイスを抽出する。
【0156】
例えば、第一のユーザが求める機能が扉の錠の開閉機能である場合には、かかる機能を備えるデバイス、例えば第二のユーザの電子錠デバイスを抽出する。なお、扉の錠の開閉機能を備えるデバイスとして複数のデバイスが抽出されてもよい。
【0157】
そして、上記抽出を行うために、情報処理装置1110が有するまたは当該情報処理装置1110と接続された記憶装置に、デバイス情報に関するデータベースを記憶しておくものとする。
【0158】
上記データベースには、デバイス情報としてデバイスのID、名称、機能、提供者などの情報が互いに関連付けられているものとする。なお、デバイス情報に含まれる情報はこれらに限られるものではなく、様々な情報をデバイス情報として関連付けておくことができる。
【0159】
また、第一のユーザによる求める機能の入力は、予め準備された提供可能な機能項目から選択させてもよい。かかる機能項目は、上記データベースに基づいて自動的に生成されることができる。
【0160】
あるいは、抽出ステップS1は、IoTハブに接続された複数のデバイスの中から、ユーザからの指定に基づいて少なくとも一のデバイスを抽出するものとする。
【0161】
上記構成は、第一のユーザが予め連携を希望するデバイスを特定している場合に効果的である。
【0162】
そして、本発明のサポート方法は、図14に示されるように、さらに、一覧出力ステップS2と、選択受付ステップS3と、選択出力ステップS4と、可否受付ステップS5と、入力出力ステップS6と、回答受付ステップS7と、送信ステップS8とを含む。
【0163】
一覧出力ステップS2は、抽出ステップS1において抽出されたデバイスの操作項目の一覧を、ユーザが確認可能に出力する。
【0164】
図15は、操作項目の一覧を含む連携項目メニュー票兼申込書1140(以下、「メニュー票1140」と呼ぶ。)のイメージを示したものである。かかるメニュー票1140は、ユーザが確認可能なユーザ側端末1120に出力され、当該ユーザ側端末1120の表示画面に表示されるものとするが、紙媒体に出力して用いることも可能である。図15において、第一のユーザはB社、第二のユーザはA社、第三のユーザはC社として示されている。
【0165】
そして、図15において、操作項目の一覧は「操作・取得項目」の欄に記載されている。なお、「取得項目」とは、情報を取得するという操作として本発明における操作項目に含まれるものとする。
【0166】
また、操作項目に関連付けて、かかる項目が「操作」に関するものか「情報取得」に関するものかも記載される。また、連携時に必要となる「コマンド名称」または「コマンドコード」も予め記載されていてもよい。
【0167】
そして、選択受付ステップS3は、一覧出力ステップS2において出力された操作項目の一覧の中からのユーザによる少なくとも一の操作項目の選択の入力を受け付ける。
【0168】
一例として、ユーザは、図15に示すように、メニュー票1140における連携申込欄に「〇」または「×」の入力を行う。かかる入力は、ユーザ側端末1120に対する操作により行われることもできるし、出力された紙媒体に記入することにより行われることもできる。後者の場合には、紙媒体に記入された選択は、第三のユーザにより情報処理装置1110に入力されるのが好ましい。
【0169】
選択出力ステップS4は、選択受付ステップS3において受け付けられた入力に基づいて、ユーザにより選択された少なくとも一の操作項目を、抽出ステップにおいて抽出されたデバイスの管理者が確認可能に出力する。
【0170】
一例として、図15に示す連携申込欄が記入済みのメニュー票1140は、管理者が確認可能な管理者側端末1130に出力され、管理者側端末1130の表示画面に表示されるものとするが、紙媒体に出力して用いることも可能である。
【0171】
可否受付ステップS5は、選択出力ステップS4において出力された選択に対する、管理者による使用可否の入力を受け付ける。
【0172】
一例として、管理者は、図16に示すように、メニュー票1140における許諾判定欄に「Y(YES)」、「N(NO)」または「n/a(not available)」の入力を行う。かかる入力は、管理者側端末1130に対する操作により行われることもできるし、出力された紙媒体に記入することにより行われることもできる。後者の場合には、紙媒体に記入された選択は、第三のユーザにより情報処理装置1110に入力されるのが好ましい。
【0173】
入力出力ステップS6は、可否受付ステップS5において受け付けられた入力を、ユーザが確認可能に出力する。
【0174】
一例として、図16に示す許諾判定欄が記入済みのメニュー票1140は、ユーザが確認可能なユーザ側端末1120に出力され、ユーザ側端末1120の表示画面に表示されるものとするが、紙媒体に出力して用いることも可能である。
【0175】
回答受付ステップS7は、入力出力ステップS6において出力された入力に対する複数の回答の選択肢の中からの、ユーザによる一の回答の入力を受け付ける。
【0176】
一例として、ユーザは、「<甲>:判定結果のとおり連携実施」、「<乙>:申込内容を変えて再協議」または「<丙>:協議打ち切り」の中から回答を選択する。かかる選択の入力は、ユーザ側端末1120に対する操作により行われることができるし、出力された紙媒体に記入することにより行われることもできる。このとき、紙媒体に記入された選択は、第三のユーザにより情報処理装置1110に入力されるのが好ましい。
【0177】
送信ステップS8は、回答受付ステップS7において受け付けられた回答を管理者に確認可能に出力する。
【0178】
一例として、図17に示す回答が記入済みのメニュー票1140は、管理者が確認可能な管理者側端末1130に出力され、管理者側端末1130の表示画面に表示されるものとするが、紙媒体に出力して用いることも可能である。
【0179】
以上の構成によれば、上述した従来技術の問題の少なくとも一部を解決又は緩和する技術的な改善を提供することができる。また、以上の構成によれば、複数のデバイスの機能を組み合わせた新たなサービスの創造を効率的に行うことができるようになる。
【0180】
また、抽出ステップS1が、IoTハブに接続された複数のデバイスの中から、ユーザ(第一のユーザ)が求める機能を実現可能な少なくとも一のデバイスを自動的に抽出することで、連携先のデバイスを抽出する作業負担を軽減することができ、新たなサービスの創造を効率的に行うことができるようになる。
【0181】
また、情報処理装置(第三のユーザ)がメニュー票を仲介することで、契約に係る作業負担も軽減することができ、新たなサービスの創造を効率的に行うことができるようになる。
【0182】
また、本発明の一実施形態として、上述したように、一覧出力ステップS2は、情報処理装置が、抽出ステップにおいて抽出されたデバイスの操作項目の一覧を、ユーザが確認可能なユーザ側端末に出力してもよい。
【0183】
また、選択受付ステップS3は、情報処理装置1110が、一覧出力ステップS2において出力された操作項目の一覧の中からのユーザによる少なくとも一の操作項目の選択の入力をユーザ側端末1120から受け付けてもよい。
【0184】
また、入力出力ステップS6は、情報処理装置1110が、可否受付ステップS5において受け付けられた入力を、ユーザが確認可能なユーザ側端末1120に出力してもよい。
【0185】
また、回答受付ステップS7は、情報処理装置1110が、入力出力ステップS6において出力された入力に対する複数の回答の選択肢の中からの、ユーザによる一の回答の入力をユーザ側端末1120を介して受け付けてもよい。
【0186】
また、選択出力ステップS4は、情報処理装置1110が、選択受付ステップS3において受け付けられた入力に基づいて、ユーザにより選択された少なくとも一の操作項目を、抽出ステップS1において抽出されたデバイスの管理者が確認可能な管理者側端末1130に出力してもよい。
【0187】
また、可否受付ステップS5は、情報処理装置1110が、選択出力ステップS4において出力された選択に対する、管理者による使用可否の入力を管理者側端末1130から受け付けてもよい。
【0188】
また、送信ステップS8は、情報処理装置1110が、回答受付ステップS7において受け付けられた回答を管理者が確認可能な管理者側端末1130に出力してもよい。
【0189】
以上の構成によれば、上述した従来技術の問題の少なくとも一部を解決又は緩和する技術的な改善を提供することができる。また、以上の構成によれば、複数のデバイスの機能を組み合わせた新たなサービスの創造を効率的に行うことができるようになる。
【0190】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【0191】
また、実施形態に記載した手法は、計算機(コンピュータ)に実行させることができるプログラムとして、例えば磁気ディスク(フロッピー(登録商標)ディスク、ハードディスク等)、光ディスク(CD-ROM、DVD、MO等)、半導体メモリ(ROM、RAM、フラッシュメモリ等)等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウェア手段(実行プログラムのみならずテーブルやデータ構造も含む)を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウェア手段を構築し、このソフトウェア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスクや半導体メモリ等の記憶媒体を含むものである。記憶部は、例えば主記憶装置、補助記憶装置、又はキャッシュメモリとして機能してもよい。
【符号の説明】
【0192】
100 IoT接続システム
200 IoTハブ
210 第一のドライバ
220 第二のドライバ
230 WebAPI
300 IoTルータ
310 第三のドライバ
400 プライベートクラウド
410 第一のデバイス
510 第二のデバイス
610 第三のデバイス
700 IoTアプリ
800 関所エンジン
900 仮想デバイス

図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17