JP2019118148A - 情報提供装置、及び情報提供方法 - Google Patents

Abstract

【課題】複数の異なるデバイスを制御するためのアプリケーションソフトを、統一的に開発することを支援する技術を提供する。【解決手段】複数のデバイス３のうち少なくとも一つのデバイスを制御するために通信端末２が実行するアプリケーションソフトで用いられるＡＰＩの仕様を提供する情報提供装置において、送信部１３４は、所定の機能を制御対象のデバイス３に実現させるために制御対象のデバイス３が解釈可能な制御情報に対応するＡＰＩの仕様を問い合わせ元に送信する。ここで、アプリケーションソフトで用いられるＡＰＩは、アプリケーションソフトが制御対象とする複数のデバイス３に共通する形式のＡＰＩである。【選択図】図３

Description

本発明は、情報提供装置、及び情報提供方法に関する。

従来、ネットワークを介して、スマートフォン等の通信端末から家電機器を制御する方法が知られている。特許文献１には、家電機器を制御するためのアプリケーションプログラムを携帯端末にダウンロードすることにより、アプリケーションプログラムを用いて家電機器を制御することができるシステムが開示されている。

特開２０１５−０５６７７９号公報

従来、家電機器を制御するためには、制御する対象となる家電機器専用のアプリケーションソフトが通信端末にインストールされていなければならなかった。例えば、ユーザが、家の外からＡ社製の照明機器を制御したい場合、ユーザは、Ａ社から提供されるＡ社製の照明機器用のアプリケーションソフトがインストールされた通信端末を用いてＡ社製の照明機器を制御しなければならなかった。

このように、制御する対象となる家電機器専用のアプリケーションソフトを通信端末にインストールする必要がある場合、制御する対象となる家電機器をユーザが買い替えた際に、新たな家電機器専用のアプリケーションソフトをインストールし直す必要があった。

一つのアプリケーションソフトで複数の異なるデバイスが制御できると便利であるが、メーカーが異なればアプリケーションソフト開発のために提供されているプログラミングインタフェースの書式は一般に異なる。このため、いわゆるサードパーティーの開発者は、アプリケーションソフトの制御対象となる家電機器等のデバイスごとに、プログラミングインタフェースを学び直す必要に迫られる。

そこで、本発明はこれらの点に鑑みてなされたものであり、複数の異なるデバイスを制御するためのアプリケーションソフトを統一的に開発することを支援する技術を提供することを目的とする。

本発明の第１の態様は、複数のデバイスのうち少なくとも一つのデバイスを制御するために通信端末が実行するアプリケーションソフトで用いられるＡＰＩ（Application Programming Interface）の仕様を提供する情報提供装置である。この装置は、所定の機能を制御対象のデバイスに実現させるために前記制御対象のデバイスが解釈可能な制御情報に対応する前記ＡＰＩの仕様を問い合わせ元に送信する送信部を備える。ここで、前記アプリケーションソフトで用いられるＡＰＩは、前記アプリケーションソフトが制御対象とする複数のデバイスに共通する形式のＡＰＩである。

前記アプリケーションソフトで用いられるＡＰＩは、前記アプリケーションソフトが前記所定の機能を実現するように制御する制御対象とする複数のデバイスに共通する形式のＡＰＩであってもよい。

前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれ型名が異なるデバイスであってもよい。

前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれメーカーが異なるデバイスであってもよい。

前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれ型名が異なり、かつ種別が同一であるデバイスであってもよい。

前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれメーカーが異なり、かつ種別が同一であるデバイスであってもよい。

前記所定の機能を制御対象のデバイスに実現させるために前記制御対象のデバイスが解釈可能な制御情報は、前記制御対象のデバイスに固有のＡＰＩであってもよい。

前記送信部は、前記送信部が送信するＡＰＩに対応する制御対象を解釈可能なデバイスの一覧情報を送信してもよい。

前記送信部は、前記通信端末のユーザによって登録されたデバイスの種別ごとに関連付けられているユーザの数を前記デバイスの種別ごとに記載した一覧情報を送信してもよい。

前記送信部は、前記ユーザの数に基づいて前記デバイスが種別ごとに整列された前記一覧情報を送信してもよい。

本発明の第２の態様は、情報提供方法である。この方法において、複数のデバイスのうち少なくとも一つのデバイスを制御するために通信端末が実行するアプリケーションソフトで用いられるＡＰＩであって、前記アプリケーションソフトが制御対象とする複数のデバイスに共通する形式のＡＰＩの仕様を提供する情報提供装置が、所定の機能を制御対象のデバイスに実現させるために前記制御対象のデバイスが解釈可能な制御情報に対応する前記ＡＰＩの仕様を問い合わせ元に送信するステップを実行する。

前記アプリケーションソフトで用いられるＡＰＩは、前記アプリケーションソフトが前記所定の機能を実現するように制御する制御対象とする複数のデバイスに共通する形式のＡＰＩであってもよい。

前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれ型名が異なるデバイスであってもよい。

前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれメーカーが異なるデバイスであってもよい。

前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれ型名が異なり、かつ種別が同一であるデバイスであってもよい。

前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれメーカーが異なり、かつ種別が同一であるデバイスであってもよい。

前記所定の機能を制御対象のデバイスに実現させるために前記制御対象のデバイスが解釈可能な制御情報は、前記制御対象のデバイスに固有のＡＰＩであってもよい。

前記情報提供方法において、情報提供装置は、前記送信するＡＰＩに対応する制御対象を解釈可能なデバイスの一覧情報を送信するステップをさらに実行してもよい。

前記情報提供方法において、情報提供装置は、前記通信端末のユーザによって登録されたデバイスの種別ごとに関連付けられているユーザの数を前記デバイスの種別ごとに記載した一覧情報を送信するステップをさらに実行してもよい。

本発明によれば、複数の異なるデバイスを制御するためのアプリケーションソフトを、統一的に開発することを支援する技術を提供することができる。

第１の実施形態のデバイス制御システムの概要について説明するための図である。 通信端末の画面の一例である。 デバイス制御装置の構成を示す図である。 ユーザ記憶部が記憶しているユーザ情報ＤＢの一例を示す図である。 制御情報について説明するための図である。 通信端末によりデバイスを制御する際のデータの流れを示す図である。 ＡＰＩ記憶部が記憶しているＡＰＩデータベースの一例を示す図である。 通信端末を用いて制御する対象となるデバイスを新たに登録する際の手順について説明するための図である。 デバイス制御装置がデバイスを制御する際の動作シーケンスを示す図である。 第１制御情報の問い合わせフォームの一例を示す図である。 変形例１におけるユーザ情報ＤＢの例を示す図である。 変形例１において通信端末から送信される第１制御情報の例を示す図である。 第２の実施の形態のデバイス制御システムについて説明するための図である。 第３の実施形態のデバイス制御システムについて説明するための図である。

＜第１の実施形態＞
［デバイス制御システムＳの概要］
図１は、第１の実施形態のデバイス制御システムＳの概要について説明するための図である。デバイス制御システムＳは、デバイス制御装置１と、通信端末２（２ａ，２ｂ）と、デバイス３（３ａ，３ｂ，３ｃ）と、ルータ４と、開発者端末６とを有する。デバイス制御装置１、通信端末２及びルータ４は、有線通信回線又は無線通信回線を介してネットワークＮに接続されている。デバイス制御装置１はまた、ネットワークＮを介して開発者端末６とも接続されている。

ネットワークＮには、インターネット、携帯電話網及びＷｉ−Ｆｉ（登録商標）回線等が含まれる。図１には、２台の通信端末２が示され、３台のデバイス３が示されているが、デバイス制御装置１は、より多くの通信端末２及びデバイス３との間でデータを送受信することができる。

デバイス制御装置１は、例えば、ＣＰＵ（Central Processing Unit）及び記憶媒体を有するコンピュータである。デバイス制御装置１は、ネットワークＮを介して、通信端末２及びデバイス３との間、及び開発者端末６との間で通信することができる。

通信端末２は、例えば、無線通信機能を有する携帯端末である。通信端末２は、例えばスマートフォン、タブレット、ファブレット、ノートＰＣ（Personal Computer）、又はデスクトップＰＣ等である。通信端末２は、アプリケーションソフトを実行することにより、デバイス３を制御するための第１制御情報をデバイス制御装置１に対して送信する。図１において、通信端末２ａは、デバイス３が設置されたユーザの自宅の外にあり、通信端末２ｂは、デバイス３が設置された自宅内にある。通信端末２は、場所によらず、ネットワークＮを介してデバイス制御装置１との間で通信をすることができる。

デバイス３は、通信機能を有する装置であり、例えば、通信端末２のユーザの自宅に設置されている電気機器である。図１に示す例において、デバイス３ａは照明器具（以下、ライトという）、デバイス３ｂはエアコン、デバイス３ｃはビデオレコーダであるが、デバイス３には、デバイス制御装置１からデータを受信できる任意の装置が含まれる。ルータ４は、ネットワークＮに接続されており、デバイス制御装置１から受信したデータをデバイス３ａ、デバイス３ｂ又はデバイス３ｃのいずれかに転送する。

開発者端末６は、通信端末２がデバイス３を制御するために実行するアプリケーションソフトの開発者Ｄが利用する端末である。開発者端末６は、通信端末２が実行するアプリケーションソフトの開発用に、デバイス制御装置１の運用者が開発者Ｄに提供したＳＤＫ（Software Development Kit）を実行する端末である。開発者端末６は、例えばノートＰＣやデスクトップＰＣ等の計算機である。開発者端末６も、通信端末２と同様に、通信機能を有する装置であり、ネットワークＮを介してデバイス制御装置１と情報をやり取りすることができる。例えば、開発者端末６は、ネットワークＮを介してデバイス制御装置１からＳＤＫをダウンロードできる。

デバイス制御装置１は、アプリケーションソフトを実行した通信端末２から送信された、デバイス３を制御するための第１制御情報を受信すると、受信した第１制御情報の内容に基づいて、複数のデバイス３から、制御する対象となるデバイス３を選択し、選択したデバイス３を制御するための第２制御情報を生成する。第１制御情報は、デバイス３に依存しない汎用的な形式のＡＰＩ（Application Programming Interface）に基づいて作成されたアプリケーションソフトにより生成される情報であり、制御する対象となるデバイス３に対する制御内容を含む情報である。第２制御情報は、特定のデバイス３を制御するためのデバイス専用の形式であるＡＰＩに則って記述された情報であり、第１制御情報が示す制御内容をデバイス３に実現させるための、デバイス３が解釈可能な情報である。第２制御情報は、例えば、デバイス３のメーカー及び型名ごとに異なる形式の情報である。

アプリケーションソフトは、特定の種別のデバイス３（例えば、ライト）を制御するための汎用的なソフトウェアであり、メーカーや型名を問わず、同じ種別のデバイス３を制御するための第１制御情報をデバイス制御装置１に送信することができる。アプリケーションソフトを実行した通信端末２が出力する第１制御情報は、第２制御情報と形式が異なるので、通信端末２は、デバイス３を直接制御することができない。しかし、デバイス制御システムＳにおいては、デバイス制御装置１が、第１制御情報に基づいて第２制御情報を生成し、通信端末２のユーザが制御する対象のデバイス３に対して第２制御情報を送信する。したがって、ユーザは、汎用的なアプリケーションソフトがインストールされた通信端末２を用いて、各種のデバイス３を制御することができる。

図２は、通信端末２の画面の一例である。通信端末２には、さまざまな種別のデバイス３を制御するための各種のアプリケーションソフトがインストールされている。図２（ａ）に示す例においては、エアコンを制御するためのエアコンアプリ、ライトを制御するためのライトアプリ、ビデオレコーダを制御するためのレコーダアプリ、監視カメラを制御するためのカメラアプリ、冷蔵庫を制御するための冷蔵庫アプリ及び洗濯機を制御するための洗濯機アプリ等がインストールされており、それぞれに対応するアイコンが表示されている。

ユーザは、例えば自宅に設置されたデバイス３のいずれかを制御したい場合、制御対象となるデバイス３に対応するアプリケーションソフトを起動することにより、自宅から離れた場所において、所望のデバイス３を制御することができる。図２（ａ）においては、デバイス３の種別ごとにアプリケーションソフトがインストールされている例を示しているが、図２（ｂ）に示すように、一つのアプリケーションソフトが、制御可能なデバイス３の一覧を表示し、ユーザが制御する対象のデバイス３を選択することによって、通信端末２からデバイス３を制御できるものとしてもよい。この場合、通信端末２が一つのアプリケーションソフトを実行することにより、例えばライト用の第１制御情報及びエアコン用の第１制御情報を出力することになる。

なお、通信端末２には、ユーザが制御することができるデバイス３の一覧を表示することができる統合アプリケーションがインストールされていてもよい。ユーザが、統合アプリケーションを起動して所定の操作をすることにより、各デバイスを制御するためのアプリケーションソフトを起動するための図２（ｂ）に示すような画面が表示されるものとしてもよい。

［デバイス制御装置１の構成］
図３は、デバイス制御装置１の構成を示す図である。デバイス制御装置１は、通信部１１と、記憶部１２と、制御部１３とを有する。

通信部１１は、例えばＬＡＮ（Local Area Network）コントローラを有する。通信部１１は、ネットワークＮを介して通信端末２及びデバイス３との間でデータを送受信する。

記憶部１２は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、及びハードディスク等の記憶媒体を含んでいる。記憶部１２は、制御部１３が実行するプログラムを記憶する。また、記憶部１２は、制御部１３が動作する際に使用するデータ及び制御部１３が生成するデータを記憶する。

記憶部１２は、制御部１３が使用するデータを記憶する領域として、ユーザ記憶部１２１及びＡＰＩ記憶部１２２を有する。ユーザ記憶部１２１は、通信端末２のユーザを識別するためのユーザ識別情報（以下、ユーザＩＤという）に関連付けて、ユーザが制御する対象として予め登録されたデバイス３の識別情報（以下、デバイスＩＤという）を記憶している。また、ＡＰＩ記憶部１２２は、通信端末２から送信された第１制御情報の内容に基づいて制御部１３が第２制御情報を生成するために用いる情報を記憶している。第２制御情報を生成するために用いられる情報は、例えば、メーカー又はデバイスの型名ごとに定められたＡＰＩである。

図４は、ユーザ記憶部１２１が記憶しているユーザ情報データベース（以下、ユーザ情報ＤＢという）の一例を示す図である。ユーザ情報ＤＢにおいては、ユーザＩＤと、ユーザが制御可能なデバイス３の種別、デバイスＩＤ、メーカー名及びアドレスとが関連付けられている。

ユーザＩＤは、ユーザに固有の識別情報であり、例えば、ユーザの通信端末２が使用する通信回線を提供する通信会社との契約情報に関連付けられている。
デバイス種別は、デバイス３が有する機能の種別を示す情報であり、ライト、エアコン、レコーダー、監視カメラ又は時計等の種別を特定するために用いられる。通信端末２にインストールされている、デバイス３を制御するためのアプリケーションソフトは、デバイス種別ごとに作成されている。

デバイスＩＤは、ユーザが通信端末２を用いた制御の対象とするデバイス３に割り当てられた識別情報であり、例えば、商品の型名を含んでいる。図４に示す例においては、ユーザＩＤ０００１のユーザが所有するＣ社のライトのように、ユーザが複数の同一の型名のデバイス３を有している場合、型名にシリアル番号を付加した情報をデバイスＩＤとしている。
メーカー名は、各デバイス３の製造者名であり、デバイスＩＤとメーカー名との組み合わせにより、デバイス３が特定される。

アドレスは、デバイス３に第２制御情報を送信する宛先を示す情報であり、例えばグローバルＩＰアドレス又はＭＡＣアドレスのようにデバイス３に固有の情報である。ルータ４にグローバルＩＰアドレスが割り当てられており、デバイス制御装置１が、ユーザに関連付けてルータ４のアドレスを記憶している場合、第１制御情報に含まれるアドレスは、ローカルＩＰアドレスであってもよい。あるいは、デバイス３がＳＩＭ（Subscriber Identity Module）スロットを備えており、ＳＩＭカードが挿入されているような場合には、ＳＩＭカードに記録されている電話番号等の固有情報をアドレスとしてもよい。

図３に戻って、制御部１３の詳細について説明する。制御部１３は、例えばＣＰＵである。制御部１３は、記憶部１２に記憶されたプログラムを実行することにより、取得部１３１、デバイス特定部１３２、情報生成部１３３、送信部１３４及び課金部１３５として機能する。

取得部１３１は、サービスの提供を受けることができるユーザの通信端末２から、デバイス制御装置１に予め登録されたデバイス３を制御するための第１制御情報を取得する。第１制御情報は、通信端末２にインストールされたアプリケーションソフトを用いてユーザが制御可能な種別のデバイス３を制御するための情報である。

図５は、制御情報について説明するための図である。図５（ａ）は、通信端末２からデバイス制御装置１に送信される第１制御情報に含まれる内容を示している。図５（ｂ）は、デバイス制御装置１からデバイス３に送信される第２制御情報に含まれる内容を示している。なお、第１制御情報から第２制御情報への変換の詳細は後述する。

図６は、通信端末２によりデバイス３を制御する際のデータの流れを示す図である。通信端末２ａは、ライト制御用のＡＰＩに則った形式で記述された「点灯」、「消灯」、「留守モード設定」、「タイマー設定」等の制御内容を含む第１制御情報を送信する。デバイス制御装置１は、第１制御情報を受信すると、デバイス３ａを制御するためのＡＰＩを用いて記述された第２制御情報を生成し、ネットワークＮ、ルータ４を介してデバイス３ａに送信する。

図５（ａ）に示すように、取得部１３１が取得する第１制御情報には、アプリＩＤ、デバイス特定情報、及び制御内容情報が含まれている。アプリＩＤは、第１制御情報の種別を示す情報であり、制御の対象とするデバイスの種別を特定するために用いられる。アプリＩＤは、例えば、ユーザが使用したアプリケーションソフトが、エアコン制御用であるかライト制御用であるかなどを特定するための情報である。

デバイス特定情報は、図４に示したユーザ情報ＤＢに含まれているデバイスＩＤを含む情報である。
制御内容情報は、デバイスＩＤで指定されたデバイス３をどのように制御するかを示す情報である。図６は、図４におけるユーザＩＤが「０００１」、アプリＩＤが「ライトアプリ」、デバイスＩＤが「ＬＢ０００２」の第１制御情報においては、ライトの明るさを５に設定するという制御内容が示されている場合におけるデータの流れを示している。制御内容情報は、デバイス３の型名によらず、デバイス種別ごとに定められた形式となっている。したがって、アプリケーションソフトの開発者Ｄは、デバイス３の型名を意識することなく、共通のＡＰＩを用いてアプリケーションソフトを開発できる。

図３に戻って、デバイス特定部１３２〜課金部１３５について説明する。
デバイス特定部１３２は、第１制御情報に基づいて制御対象デバイスを特定する。デバイス特定部１３２は、第１制御情報に含まれているユーザＩＤに対応するユーザのユーザ情報ＤＢを参照し、第１制御情報に含まれているデバイス特定情報に対応するデバイスＩＤを有するデバイス３を、制御対象デバイスとして特定する。デバイス特定部１３２は、特定したデバイス３の型名を情報生成部１３３に通知し、特定したデバイス３のアドレスを送信部１３４に通知する。

図７は、ＡＰＩ記憶部１２２が記憶しているＡＰＩデータベース（以下、ＡＰＩＤＢという）の一例を示す図である。ＡＰＩＤＢにおいては、各デバイス３を特定するデバイスＩＤごとに、そのデバイス３が実現可能な機能、すなわちそのデバイス３に対する制御内容と、それを実現するためのデバイス３に固有のＡＰＩである第２制御情報とが格納されている。ＡＰＩＤＢにはさらに、デバイス３に対する制御内容に対応する第１制御情報が汎用ＡＰＩの書式で格納されている。

情報生成部１３３は、取得部１３１が取得した第１制御情報に含まれる制御内容と、デバイス特定部１３２が第１制御情報に基づいて特定したデバイスＩＤとを用いて、ＡＰＩＤＢを参照することによって第２制御情報を生成する。図７に示す例において、デバイスＩＤがＬＡ００５０で特定されるデバイス３と、ＬＣ００２０で特定されるデバイス３とは、ともにライトである。しかしながら、図７に示すように、デバイスＩＤがＬＡ００５０で特定されるデバイス３を点灯させるための第２制御情報と、デバイスＩＤがＬＣ００２０で特定されるデバイス３を点灯させるための第２制御情報とは異なる。

一方、デバイスＩＤがＬＡ００５０で特定されるデバイス３を点灯させるための第１制御情報と、ＬＣ００２０で特定されるデバイス３を点灯させるための第１制御情報とは、同じ書式である。情報生成部１３３は、第１制御情報に含まれている制御内容を、デバイス特定部１３２が特定したデバイス３の型名に対応するＡＰＩに入れ込むことにより第２制御情報を生成する。これにより、情報生成部１３３は、図５（ｂ）に示すように、第１制御情報を、デバイス３のメーカーや型名ごとに異なる形式の第２制御情報に変換することができる。

ここで図５（ｂ）のＬＢ０００２用の第２制御情報を参照すると、第１制御情報においては制御内容が「点灯」となっているにもかかわらず、第２制御情報においては「明るさ＝５」とされている。ライトによっては、「点灯」、「消灯」を制御するＡＰＩに対応しておらず、明るさを指定することにより制御するＡＰＩにより作成された第２制御情報でなければ制御できない場合がある。このような場合に、情報生成部１３３は、第１制御情報に含まれている制御内容をデバイス３の専用ＡＰＩの形式で記述することで、第２制御情報を生成する。このようにすることで、アプリケーションソフトの開発者が、デバイス３ごとに異なる専用ＡＰＩを意識しないでアプリケーションソフトを開発できるとともに、ユーザは、単一のアプリケーションソフトを用いて異なる型名のデバイス３を制御できる。

送信部１３４は、デバイス特定部１３２から通知された制御対象デバイスのアドレスに対して、第１制御情報が示す制御内容を実行させるための第２制御情報を送信する。
課金部１３５は、ユーザが通信端末２を利用してデバイス３を制御したことに応じて、ユーザに対する課金額を算出する。課金部１３５は、算出した課金額をユーザＩＤに関連付けて記憶部１２に記憶させる。課金部１３５は、課金額を、通信端末２の使用料を管理する通信会社のサーバに送信してもよい。このようにすることで、通信端末２の使用料と合算してサービス使用料をユーザに請求することができるので、請求処理を効率化することができる。

また、課金部１３５は、ユーザが通信端末２にインストールされたアプリケーションソフトを用いてデバイス３を制御した場合に、アプリケーションソフトを提供する業者に対して課金してもよい。例えば、課金部１３５は、アプリケーションソフトを用いて通信端末２から送信された第１制御情報に基づいて情報生成部１３３が第２制御情報を生成した回数に応じた額を、アプリケーションソフトを提供する業者に対して課金する。

［制御対象デバイスを登録する際の手順］
図８は、ユーザが、通信端末２を用いて制御する対象となるデバイス３を新たに登録する際の手順について説明するための図である。図８（ａ）は、デバイス制御サービスを利用するためのログイン画面である。ユーザは、予め設定されたユーザＩＤを入力することにより、制御対象デバイスを新たに追加したり、設定内容を変更したりすることができる。

図８（ｂ）は、ログイン後の画面である。ユーザが、既にエアコンを登録済であることが表示されている。ユーザは、「追加登録」のアイコンにタッチすることで、新たな制御対象デバイスを登録するための画面を表示することができる。

図８（ｃ）は、新たな制御対象デバイスを登録するための画面である。ユーザが、この画面に表示されているアイコンのうち、登録する対象のデバイス３の種別に対応するアイコンにタッチすることにより、通信端末２は、登録する対象のデバイス３を探索する。具体的には、通信端末２は、例えばＢｌｕｅｔｏｏｔｈ（登録商標）等の無線通信方式を用いて通信可能なデバイス３を探索する。通信端末２は、ユーザにより選択された種別のデバイス３が見つかった場合に、デバイス３を登録するための画面を表示する。この時点で、通信端末２は、各デバイス３から取得した型名情報、メーカー名及びＭＡＣ（Media Access Control）アドレスをメモリに記憶する。

図８（ｄ）は、探索により見つかったデバイス３を登録するための画面である。ユーザは、登録したいデバイス３に名称（例えば「リビング」、「玄関」等の設置場所）を入力してから登録ボタンにタッチすることで、デバイス３を登録することができる。通信端末２は、デバイス３から取得した型名情報を含むデバイスＩＤを生成し、ユーザにより入力された名称と関連付けてデバイスＩＤを内部のメモリに記憶する。また、通信端末２は、通信端末２を使用するユーザのユーザＩＤ、デバイスＩＤ、メーカー名、ＭＡＣアドレスをデバイス制御装置１に送信する。このようにすることで、ユーザは、制御対象デバイスをデバイス制御装置１に登録することができる。

［デバイス３を制御する際の動作シーケンス］
図９は、デバイス制御装置１がデバイス３を制御する際の動作シーケンスを示す図である。まず、ユーザが、通信端末２において、制御対象デバイスを制御するためのアプリケーションソフトを起動すると（Ｓ１１）、通信端末２は、ユーザが入力した制御内容を取得する（Ｓ１２）。通信端末２は、取得した制御内容を含む第１制御情報を生成し、ネットワークＮを介してデバイス制御装置１に第１制御情報を送信する（Ｓ１３）。

デバイス制御装置１は、第１制御情報を受信すると、デバイス特定部１３２において、受信した第１制御情報に基づいて制御対象のデバイス３を特定する（Ｓ１４）。続いて、情報生成部１３３が、ＡＰＩＤＢを参照して制御対象のデバイス３に対応する第２制御情報を生成し、送信部１３４が第２制御情報を制御対象のデバイス３に送信する（Ｓ１５）。

デバイス３は、第２制御情報を受信すると、第２制御情報に含まれている制御内容に応じた動作を実行する（Ｓ１６）。デバイス３は、動作を実行すると、デバイス３自身の状態を示す第１状態情報をデバイス制御装置１に送信する（Ｓ１７）。例えばデバイス３がライトであり、制御内容が「点灯」である場合、デバイス３は、点灯が完了したことを示す第１状態情報を送信する。また、デバイス３がエアコンであり、制御内容が「温度を２５℃に設定」である場合、デバイス３は、第２制御情報を受信してから制御内容が示す温度に達するまでの間、定期的に室温を測定し、測定した室温示す第１状態情報をデバイス制御装置１に送信する。ここで、第１状態情報は、デバイス３ごとに異なる形式で作成された情報であるものとする。

デバイス制御装置１においては、取得部１３１が第１状態情報を取得すると、情報生成部１３３が、通信端末２のアプリケーションソフトが認識できる、同一の種別のデバイス３に共通する形式の第２状態情報に第１状態情報を変換する（Ｓ１８）。送信部１３４は、情報生成部１３３が変換して生成した第２状態情報を、ネットワークＮを介して通信端末２に送信する（Ｓ１９）。通信端末２は、第２状態情報を受信すると、第２状態情報が示すデバイス３の状態を画面に表示する（Ｓ２０）。
以上の手順により、ユーザは、通信端末２を操作することにより所望のデバイス３を制御したり、デバイス３の状態を確認したりすることができる。

［アプリケーションソフトの開発者Ｄに提供する情報］
以上、デバイス制御装置１、通信端末２、及びデバイス３の３者間におけるデータの流れについて主に説明した。次に、デバイス制御装置１と開発者端末６との間におけるデータの流れについて説明する。
より具体的には、デバイス制御装置１は、開発者Ｄからの要求に応じて、アプリケーションソフトの開発に利用可能な情報を提供することができる。この観点から見ると、デバイス制御装置１は情報提供装置として機能する。

図１０は、第１制御情報の問い合わせフォームの一例を示す図である。アプリケーションソフト開発用のＳＤＫ（以下、単に「ＳＤＫ」と記載する）は、開発者端末６の表示部にＡＰＩ問い合わせ用のＧＵＩ（Graphical User Interface）を表示することができる。図１０に示すように、開発者Ｄは、ＳＤＫを実行する開発者端末６において、アプリケーションソフトの制御対象とするデバイス３と、そのデバイスに実現させる機能を選択する。開発者Ｄが問い合わせフォームにおける「問い合わせアイコン」を押下すると、ＳＤＫはデバイス３を特定するためのデバイスＩＤと開発者Ｄが選択した機能とを、ネットワークＮを介してデバイス制御装置１に送信する。

取得部１３１は、アプリケーションソフトを開発する開発者端末６から、デバイス３のデバイスＩＤとそのデバイス３に実現させる機能の指定とを取得する。情報生成部１３３は、ＡＰＩＤＢを参照して、開発者端末６が指定した機能をデバイスＩＤで特定されるデバイス３に実現させるための第２制御情報に対応する第１制御情報を、アプリケーションソフトが用いるＡＰＩの仕様として生成する。送信部１３４は、情報生成部１３３が生成したＡＰＩの仕様を、問い合わせ元の開発者端末６に送信する。これにより、開発者Ｄのアプリケーションソフトの開発効率を向上することができる。

図１０に示すように、開発者Ｄは、指定した機能を実現させるためのデバイス３を具体的に指定することができる。このため、取得部１３１は、開発者端末６から指定された機能を実現させるデバイス識別情報ＩＤを取得することができるので、情報生成部１３３は、デバイスＩＤで特定されるデバイス３で解釈可能な第２制御情報に対応するＡＰＩの仕様を生成することができる。この結果、例えば照度調整機能を持たないライトが指定された場合には、情報生成部１３３は照度指定のためのパラメータをＡＰＩから削除して生成する。第２制御情報はデバイス３に非依存の汎用的なＡＰＩであるが、開発者Ｄに提示されるＡＰＩには開発対象とするデバイス３で実現できない機能に関するパラメータは削除されているため、開発者Ｄのアプリケーションソフトの開発効率を向上することができる。

なお開発者Ｄは、図１０に示すＧＵＩにおいて、デバイスの種別と機能のみを選択し、メーカー及び型番を省略してデバイス制御装置１に問い合わせることもできる。この場合、情報生成部１３３は、特定のデバイス３の機能に依存しない一般的な機能を実現するためのＡＰＩをＡＰＩＤＢから抽出する。

ここで、デバイス制御装置１のＡＰＩＤＢにどのようなデバイス３のＡＰＩが格納されているかを予め知ることができれば、開発者ＤはＡＰＩ問い合わせの際のデバイスＩＤの指定に便利である。
そこで情報生成部１３３は、ＡＰＩＤＢに格納されているデバイス３の一覧情報、すなわち情報生成部１３３が生成する第２制御情報を解釈可能なデバイス３の一覧情報を生成する。送信部１３４は、取得部１３１が開発者端末６から一覧情報の提供要求を取得することを契機として、その開発者端末６にデバイス３の一覧情報を送信する。これにより、開発者Ｄは、開発対象とするアプリケーションソフトの制御対象とするデバイスの候補を把握することができる。

開発者Ｄが開発しようとするアプリケーションソフトの制御対象のデバイス３は、そのアプリケーションソフトを利用する可能性のあるユーザの数が多い方が、開発者Ｄのソフト開発に対する意欲が高まると考えられる。そこで情報生成部１３３は、デバイス３の種別ごとに、そのデバイス３に関連付けらえているユーザの数を集計し、集計したユーザの数をデバイス３の種別ごとに記載して一覧情報を生成することもできる。情報生成部１３３はさらに、集計したユーザの数に基づいてデバイス３の種別を、例えば降順に整列させて一覧情報を生成することもできる。これにより開発者Ｄは、多くのユーザが利用するデバイス３対象としてアプリケーションソフトを開発することができる。

開発者Ｄが図２（ｂ）に示すような統合アプリケーションを開発しようとする場合には、どのようなデバイス３の組み合わせをそのアプリケーションソフトの制御対象とするかを選択する必要がある。
そこで情報生成部１３３は、ユーザ情報ＤＢにおいて一つのユーザＩＤに複数のデバイスＩＤが関連付けられている場合、その複数のデバイスＩＤの組み合わせのパターンごとにその数を集計した組み合わせ情報を生成する。この組み合わせ情報は、ユーザ情報ＤＢに登録されているユーザが、異なるデバイス３をどのような組み合わせのパターンで所持しているかを示す情報である。情報生成部１３３はまた、複数のデバイスＩＤの組み合わせのパターンごとに集計した数に基づいて、そのパターンを例えば降順で整列させて組み合わせ情報を生成することもできる。

送信部１３４は、取得部１３１が開発者端末６から組み合わせ情報の提供要求を取得することを契機として、開発者端末６に組み合わせ情報を送信する。これにより開発者Ｄは、組み合わせのパターンを把握することができる。より多くのユーザが所持するデバイス３の組み合わせパターンを選択してそのパターンに含まれるデバイス３を制御するための統合アプリケーションを開発することにより、開発者Ｄは、より多くのユーザが利用する可能性のある統合アプリケーションを開発することができる。

［変形例１］
図５においては、第１制御情報に含まれるデバイス特定情報としてデバイスＩＤが用いられる例について説明したが、これに限らない。ユーザ情報ＤＢにおいて、ユーザが所有しているデバイス種別ごとに、ユーザが所有している同一種別のデバイス３のうち、何番目のデバイス３であるかを示すシリアル番号がデバイス３の型名に関連付けられていれば、第１制御情報におけるデバイス特定情報は、シリアル番号であってもよい。シリアル番号は、例えば、図８（ｄ）に示した「リビング」、「玄関」等のように、デバイス３の設置場所を示す情報に関連付けられており、デバイス制御装置１に登録された順番に割り当てられた番号である。

図１１は、変形例１におけるユーザ情報ＤＢの例を示す図である。図１２は、変形例１において通信端末２から送信される第１制御情報の例を示す図である。図１１に示すユーザ情報ＤＢにおいては、デバイスＩＤはデバイスの型名を示しており、ユーザが同一の型名のデバイス３を複数所有している場合、デバイスＩＤは同一の内容になっている。デバイス特定部１３２は、第１制御情報に含まれているアプリＩＤ及びデバイス特定情報としてのシリアル番号に基づいて、同一の型名のデバイス３のうち、どのデバイス３に対して第２制御情報を送信する必要があるかを特定することができる。なお、デバイス特定情報が、ＭＡＣアドレスのようにデバイス３に固有の情報を含む場合、第１制御情報にユーザＩＤが含まれていなくてもよい。

［変形例２］
上記の説明においては、１台の通信端末２がデバイス３を制御する場合について説明したが、複数の通信端末２がデバイス３を制御できるようにしてもよい。例えば、デバイス制御システムＳは、通信端末２ｂが、通信端末２ａの通信料金と合算して通信料金を支払う対象になっている家族の通信端末２であれば、通信端末２ａにおいて登録されたデバイス３を、通信端末２ｂを用いて制御できるようにしてもよい。

このように複数の通信端末２がデバイス３を制御できるようにするために、記憶部１２は、複数のユーザの複数のユーザＩＤを互いに関連付けて記憶する。例えば、取得部１３１が、通信会社において管理されるサーバから、通信料金を合算して支払う対象となっている複数のユーザＩＤを取得して、取得した複数のユーザＩＤを記憶部１２に記憶させる。

デバイス特定部１３２は、取得部１３１が取得した第１制御情報に第１ユーザＩＤが含まれている場合、第１ユーザＩＤに関連付けて記憶部１２に記憶されている第２ユーザＩＤに対応するユーザ情報ＤＢが記憶部１２に記憶されているかどうかを確認する。第２ユーザＩＤに対応するユーザ情報ＤＢが記憶部１２に記憶されている場合、デバイス特定部１３２は、このユーザ情報ＤＢにおいて第２ユーザＩＤに関連付けられたデバイスＩＤを特定することにより、制御対象デバイスを特定する。

［変形例３］
上記の説明においては、デバイス制御装置１が開発者端末６からの要求に応じてＡＰＩ情報等の生成及び送信を実行する場合について説明した。これに代えて、開発者端末６からの問い合わせに応じるための、デバイス制御装置１とは異なる専用の情報提供装置（不図示）を設けてもよい。デバイス制御装置１は、第１制御情報を第２制御情報に変換する処理に専念できるため、デバイス制御装置１の処理効率を向上させることができる。

このように、複数の通信端末２からデバイス３を制御可能にする場合、課金部１３５は、複数のユーザのうち、代表者として登録されているユーザに対して課金してもよい。すなわち、課金部１３５は、第２ユーザＩＤに対応するユーザに対して、第１ユーザＩＤに対応する通信端末２から第１制御情報が送信されたことに対する費用を課金してもよい。このようにすることで、通信料金を支払う第１ユーザＩＤのユーザが、デバイス制御サービスの使用料も通信料金と合算して支払うことができるので、他のユーザが個別にサービス使用料を支払う手間がかからない。

［第１の実施形態のデバイス制御システムＳによる効果］
以上説明したように、デバイス制御システムＳにおいては、通信端末２にインストールされた、同一の種別の型名が異なる複数のデバイスを制御することができるアプリケーションソフトを用いてユーザが操作することにより、デバイスの種別ごとに共通する形式の第１制御情報がデバイス制御装置１に送信される。デバイス制御装置１は、受信した第１制御情報に基づいて、デバイス専用のＡＰＩを用いた第２制御情報を生成して、第１制御情報において指定されたデバイス３に第２制御情報を送信する。

このようにすることで、ユーザは、デバイスごとに異なるアプリケーションソフトをインストールすることなく、一つのアプリケーションソフトを用いて各種のデバイス３を制御できるので、デバイス３を買い替えた際にアプリケーションソフトを入れ替える必要がない。また、デバイス３の製造者は、新たなデバイス３の販売を開始するたびにアプリケーションソフトを提供する必要がなく、ＡＰＩを公開するだけでよいので、開発費を抑えることができる。

また、デバイス制御装置１は、例えば通信料金を合算して支払うユーザが、共通のデバイス３を制御できるようにする。このようにすることで、家族のうちの一人が制御対象とするデバイス３を登録しておくことで、他のユーザがデバイス３を制御できるので、登録の手間が省ける。
さらに、通信料金を合算して支払うユーザがサービスを利用した場合の費用は、合算して課金されるので、ユーザごとに個別にサービス使用料を支払う手間がかからない。

また開発者Ｄは、第２制御情報、すなわち各デバイス３に固有のＡＰＩを使用せずに、デバイス３を制御するためのアプリケーションソフトを開発することができる。これは例えばデバイス３の製造者が、第２制御情報をデバイス制御装置１の運用者を含む限定された範囲にのみ公開しており、開発者Ｄがその第２制御情報を知ることができない場合であってもアプリケーションソフトを開発できる点で有用である。
開発者Ｄは、ユーザ情報ＤＢに登録されている複数のデバイス３のうち、所持しているユーザの数が多いデバイス３又はデバイスの種別を取得することができる。このため、より多くのユーザに使われる可能性のあるアプリケーションソフトを開発することができるので、開発者Ｄのソフト開発の意欲を高めることができる。

＜第２の実施形態＞
図１３は、第２の実施形態のデバイス制御システムＳについて説明するための図である。第２の実施形態においては、サーバ５ａ及びサーバ５ｂのように、他のサービス提供者のサーバを介してデバイス３を制御するという点で、第１の実施形態と異なる。サーバ５ａ及びサーバ５ｂは、例えば、デバイス３のメーカーが、自社のデバイス３を制御するサービスを提供するためのデバイスサーバであり、制御対象デバイスに、第２制御情報に基づく制御信号を送信する。この場合、情報生成部１３３は、通信端末２から第１制御情報を受信すると、第１制御情報に含まれている制御内容に基づいて、サーバ５に制御対象デバイスを制御させるための第２制御情報を生成する。そして、送信部１３４は、情報生成部１３３が生成した第２制御情報を、デバイスサーバとしてのサーバ５に送信する。デバイスサーバとしてのサーバ５は第２制御情報を解釈可能である。

本実施形態の記憶部１２は、デバイス３を制御するサービスの提供者に関連付けて、それぞれのサービス提供者のサーバ５のＡＰＩを記憶している。情報生成部１３３は、例えば、記憶部１２に記憶されているサーバ５のＡＰＩに基づいて第２制御情報を生成する。具体的には、情報生成部１３３は、第１制御情報に含まれている制御内容を、第１制御情報と異なる形式の第２制御情報に変換する。第２制御情報には、第１制御情報に含まれていたユーザＩＤ及びデバイス特定情報等が含まれている。

デバイス制御システムＳを用いてサービスを提供する企業と、サーバ５ａ又はサーバ５ｂを用いてサービスを提供する企業との間では、予めユーザＩＤが共通化されている。サーバ５ａ又はサーバ５ｂは、第２制御情報に含まれているユーザＩＤ及びデバイス特定情報等に基づいて、通信端末２における操作に応じたデバイス３を制御することができる。

なお、図１３に示すように、デバイス３を制御するサービスを提供するサーバ５が複数ある場合、デバイス制御装置１のユーザ記憶部１２１は、ユーザが、サーバ５ａを用いたサービス又はサーバ５ｂを用いたサービスのうち、どのサービスを利用しているかを示す利用サービス情報を記憶している。情報生成部１３３は、利用サービス情報を参照し、ユーザが利用しているサービスに対応するＡＰＩに対応する第２制御情報を生成する。

デバイス制御システムＳを用いてサービスを提供する企業と、サーバ５ａを用いてサービスを提供する企業と、サーバ５ｂを用いてサービスを提供する企業との間でユーザＩＤが共通化されていない場合には、デバイス制御装置１がユーザＩＤを変換してもよい。この場合、デバイス制御システムＳのユーザＩＤとサーバ５ａ及びサーバ５ｂを用いたサービスのユーザＩＤとを関連付けて記憶するユーザＤＢ（不図示）を記憶部１２に設ける。情報生成部１３３が利用サービス情報を用いてユーザＤＢを参照し、ユーザＩＤを変換すればよい。

サーバ５ａ、サーバ５ｂ（以下、サーバ５）は、ネットワークを介して接続されたデバイス制御装置１から第２制御情報を受信すると、その内容が制御対象のデバイス３への動作指示を含む場合には、デバイス３への動作指示を示す情報（信号）をデバイス３へ送信する。一方、受信した第２制御情報が、デバイス３が取得したデータの要求を含む場合には、サーバ５は、デバイス３から予め取得していたデバイス３の動作データや収集データ等をデバイス制御装置１に送信する。なお、サーバ５がデバイス３の動作データや収集データ等を予め取得しておらずデバイス３内に蓄積されている場合には、サーバ５は、受信した第２制御情報に基づいて、デバイス３から動作データや収集データ等の要求を行い、取得したデータをサーバ５からデバイス制御装置１に送信してもよい。

このように、第２の実施形態においては、サーバ５ａ及びサーバ５ｂのように、他のサービス提供者のサーバを介してデバイス３を制御するという点で、第１の実施形態と異なる。しかしながら、ユーザ及び開発者Ｄの関連から見ると、ネットワークＮ上に存在するサーバの数は認識できず、ネットワークＮ上にあるサーバに仲介させて通信端末２からデバイス３を利用するという点では変わらない。この意味で、第２の実施の形態に係るデバイス制御システムＳは、第１の実施の形態に係るデバイス制御装置１の機能を、物理的に異なるサーバに分離して実装した形態と見ることもできる。

［第２の実施形態のデバイス制御システムＳによる効果］
以上説明したように、第２の実施形態のデバイス制御装置１は、デバイス３を制御する他のサーバ５のＡＰＩに対応する第２制御情報を生成する。このようにすることで、ユーザが、既にサーバ５を介してデバイス３を制御するサービスの提供を受けている場合であっても、通信端末２にインストールされた任意のアプリケーションソフトを用いてデバイス３を制御することができる。

＜第３の実施形態＞
図１４は、第２の実施形態のデバイス制御システムＳについて説明するための図である。第２の実施形態においては、制御対象デバイスがユーザの自宅にある電気機器ではなく、企業等が情報を配信するサーバ７であるという点で、第１の実施形態と異なる。

サーバ７ａは、ユーザが投稿したレストランの情報を提供するサービスで用いられているサーバである。サーバ７ｂは、ユーザが投稿した各種商品の価格情報を提供するサービスで用いられているサーバである。ユーザは、通信端末２にインストールされたアプリケーションソフトを用いて、他の人に伝えたい情報をサーバ７にアップロードすることができる。

サーバ７ａ，７ｂは、情報を受信するためのインタフェースとして、それぞれ異なる形式のインタフェースを有している。したがって、サーバ７ａ，７ｂに情報をアップロードするためには、それぞれのサーバに適した形式に情報を加工してから送信する必要がある。しかし、ユーザが、それぞれのサービスのサイトに情報を提供する際に、サーバ７ａ及びサーバ７ｂのそれぞれに専用のアプリケーションソフトを用いる必要があると不便である。

そこで、本実施形態に係るデバイス制御装置１は、通信端末２においては、さまざまな情報提供サービスのサーバ７に情報をアップロードするためのアプリケーションソフトがインストールされている。アプリケーションソフトにおいては、情報を提供する対象となるサービスに対応するアイコンが表示されており、ユーザが、情報を提供したいサービスに対応するアイコンにタッチしてから情報を入力すると、通信端末２は、入力された情報とユーザが選択したサービスを特定する情報を含む第１制御情報をデバイス制御装置１に送信する。

デバイス制御装置１においては、デバイス特定部１３２が、第１制御情報に基づいて、第１制御情報に含まれるコンテンツを送信する先のサーバ７を特定する。デバイス特定部１３２は、例えば、第１制御情報に含まれる、サービスを特定する情報に基づいて、サーバ７を特定する。デバイス特定部１３２は、ユーザが作成したコンテンツに含まれているキーワードに基づいて、コンテンツを送信する対象となるサーバ７を特定してもよい。そして、情報生成部１３３が、特定されたサーバ７に対応する形式の第２制御情報を生成し、送信部１３４が、生成された第２制御情報をサーバ７に送信する。

なお、本実施形態における課金部１３５は、ユーザが通信端末２を用いてサーバ７にアクセスした回数又はサーバ７との間で送受信したデータ量に基づいて課金額を決定してもよい。この場合、課金部１３５は、決定した課金額の一部を、サーバ７を運用する企業等に支払う額として算出してもよい。

なお、第３の実施形態に係るデバイス制御装置１も、第１の実施形態及びだ２の実施形態に係るデバイス制御装置１と同様に、開発者Ｄの開発者端末６からの要求に応じて、ＡＰＩの書式で第１制御情報を提供することができる。

［第３の実施形態のデバイス制御システムＳによる効果］
本実施形態におけるデバイス制御システムＳは、第１制御情報に基づいて、第１制御情報に含まれるコンテンツを送信する先のサーバ７を特定し、サーバ７に対応する形式の第２制御情報をサーバ７に送信する。このようにすることで、サーバ７を運用する企業等は、サーバ７にアクセスするためのインタフェースを広く一般に公開する必要がなく、デバイス制御装置１の運用者にのみ公開すればよい。その結果、サーバ７を運用する企業がインタフェースを公開する手間がかからない。

また、デバイス制御システムＳは、課金部１３５が、ユーザに対する課金額を算出し、その一部の額を、サーバ７を運用する企業等に還元することができる。このようにすることで、ユーザがサーバ７を利用したことに対する料金の請求を、サーバ７を運営する企業等の代わりにデバイス制御装置１を運営する通信キャリア等の運営者が一元的に行うことができるので、ユーザにとってもサーバ７を運営する企業等にとっても手間を省くことができる。

以上、本発明をいくつかの実施の形態をもとに説明した。これらの任意の組み合わせによって生じる新たな実施の形態も、本発明の実施の形態に含まれる。組み合わせによって生じる新たな実施の形態の効果は、もとの実施の形態の効果を合わせ持つ。

また、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。特に、装置の分散・統合の具体的な実施形態は以上に図示するものに限られず、その全部又は一部について、種々の付加等に応じて、又は、機能負荷に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

１ デバイス制御装置
２ 通信端末
３ デバイス
４ ルータ
５ サーバ
６ 開発者端末
１１ 通信部
１２ 記憶部
１３ 制御部
１２１ ユーザ記憶部
１２２ ＡＰＩ記憶部
１３１ 取得部
１３２ デバイス特定部
１３３ 情報生成部
１３４ 送信部
１３５ 課金部
Ｓ デバイス制御システム

Claims (19)

1. 複数のデバイスのうち少なくとも一つのデバイスを制御するために通信端末が実行するアプリケーションソフトで用いられるＡＰＩ（Application Programming Interface）の仕様を提供する情報提供装置であって、
   所定の機能を制御対象のデバイスに実現させるために前記制御対象のデバイスが解釈可能な制御情報に対応する前記ＡＰＩの仕様を問い合わせ元に送信する送信部を備え、
   前記アプリケーションソフトで用いられるＡＰＩは、前記アプリケーションソフトが制御対象とする複数のデバイスに共通する形式のＡＰＩである、
   情報提供装置。
2. 前記アプリケーションソフトで用いられるＡＰＩは、前記アプリケーションソフトが前記所定の機能を実現するように制御する制御対象とする複数のデバイスに共通する形式のＡＰＩである、
   請求項１に記載の情報提供装置。
3. 前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれ型名が異なるデバイスである、
   請求項１又は２に記載の情報提供装置。
4. 前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれメーカーが異なるデバイスである、
   請求項１又は２に記載の情報提供装置。
5. 前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれ型名が異なり、かつ種別が同一であるデバイスである、
   請求項１又は２に記載の情報提供装置。
6. 前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれメーカーが異なり、かつ種別が同一であるデバイスである、
   請求項１又は２に記載の情報提供装置。
7. 前記所定の機能を制御対象のデバイスに実現させるために前記制御対象のデバイスが解釈可能な制御情報は、前記制御対象のデバイスに固有のＡＰＩである、
   請求項１から６のいずれか１項に記載の情報提供装置。
8. 前記送信部は、前記送信部が送信するＡＰＩに対応する制御対象を解釈可能なデバイスの一覧情報を送信する、
   請求項１から７のいずれか１項に記載の情報提供装置。
9. 前記送信部は、前記通信端末のユーザによって登録されたデバイスの種別ごとに関連付けられているユーザの数を前記デバイスの種別ごとに記載した一覧情報を送信する、
   請求項１から８のいずれか１項に記載の情報提供装置。
10. 前記送信部は、前記ユーザの数に基づいて前記デバイスが種別ごとに整列された前記一覧情報を送信する、
    請求項９に記載の情報提供装置。
11. 複数のデバイスのうち少なくとも一つのデバイスを制御するために通信端末が実行するアプリケーションソフトで用いられるＡＰＩであって、前記アプリケーションソフトが制御対象とする複数のデバイスに共通する形式のＡＰＩの仕様を提供する情報提供装置が、所定の機能を制御対象のデバイスに実現させるために前記制御対象のデバイスが解釈可能な制御情報に対応する前記ＡＰＩの仕様を問い合わせ元に送信するステップを実行する、情報提供方法。
12. 前記アプリケーションソフトで用いられるＡＰＩは、前記アプリケーションソフトが前記所定の機能を実現するように制御する制御対象とする複数のデバイスに共通する形式のＡＰＩである、
    請求項１１に記載の情報提供方法。
13. 前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれ型名が異なるデバイスである、
    請求項１１又は１２に記載の情報提供方法。
14. 前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれメーカーが異なるデバイスである、
    請求項１１又は１２に記載の情報提供方法。
15. 前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれ型名が異なり、かつ種別が同一であるデバイスである、
    請求項１１又は１２に記載の情報提供方法。
16. 前記アプリケーションソフトが制御対象とする前記複数のデバイスは、それぞれメーカーが異なり、かつ種別が同一であるデバイスである、
    請求項１１又は１２に記載の情報提供方法。
17. 前記所定の機能を制御対象のデバイスに実現させるために前記制御対象のデバイスが解釈可能な制御情報は、前記制御対象のデバイスに固有のＡＰＩである、
    請求項１１から１６のいずれか１項に記載の情報提供方法。
18. 前記情報提供方法において、情報提供装置は、前記送信するＡＰＩに対応する制御対象を解釈可能なデバイスの一覧情報を送信するステップをさらに実行する、
    請求項１１から１７のいずれか１項に記載の情報提供方法。
19. 前記情報提供方法において、情報提供装置は、前記通信端末のユーザによって登録されたデバイスの種別ごとに関連付けられているユーザの数を前記デバイスの種別ごとに記載した一覧情報を送信するステップをさらに実行する、
    請求項１１から１８のいずれか１項に記載の情報提供方法。

Images