(57)【要約】【課題】あるアイデアを実現する際に、実現したい機能を有するデバイスやＡＰＩの最適な組み合わせを効率的に見つける。【解決手段】情報処理装置１は、所定のアイデアを実現するシステムに必要な複数の機能を取得し、取得された各機能を有するデバイスまたはＡＰＩを、機能とデバイスおよび機能とＡＰＩとをそれぞれ対応付けた機能情報から検索し、複数の機能を有するデバイスまたはＡＰＩの組み合わせを複数生成し、複数生成された組み合わせごとに、組み合わせを特定の要素で重み付けした評価関数を用いて評価し、評価された評価値に基づいて、所定の評価を有する前記組み合わせを提示する。【選択図】図１
2018194900.tif 000002
【特許請求の範囲】
【請求項１】
所定のアイデアを実現するシステムに必要な複数の機能を取得する取得部と、
前記取得部によって取得された各機能を有するデバイスまたはＡＰＩを、機能とデバイスおよび機能とＡＰＩとをそれぞれ対応付けた機能情報から検索する検索部と、
前記複数の機能を有するデバイスまたはＡＰＩの組み合わせを複数生成する生成部と、
前記生成部によって複数生成された組み合わせごとに、組み合わせを特定の要素で重み付けした評価関数を用いて評価する評価部と、
前記評価部によって評価された評価値に基づいて、所定の評価を有する前記組み合わせを提示する提示部と、
を有することを特徴とする情報処理装置。
【請求項２】
前記評価関数に組み込まれる特定の要素は、前記デバイスまたはＡＰＩのペアの利用頻度、前記組み合わせに含まれるデバイスまたはＡＰＩのペアの数および前記ペアの通信インタフェースの少なくとも１つを含む
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記検索部によって特定の機能を有するデバイスまたはＡＰＩが検索されない場合または検索されたデバイスまたはＡＰＩが所定の品質特性を満たさない場合には、前記特定の機能を、前記特定の機能と異なる他の機能に変換する機能変換部を有し、
前記生成部は、前記機能変換部によって変換された他の機能を有するデバイスまたはＡＰＩを含むデバイスまたはＡＰＩの組み合わせを複数生成する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記機能変換部は、変換前の第１の機能と変換後の第２の機能とを対応付けた変換情報を用いて、前記検索部によって検索される、前記第１の機能から変換された前記第２の機能を有するデバイスまたはＡＰＩが所定の品質特性を満たすまで、再帰的に、前記特定の機能を、前記特定の機能と異なる他の機能に変換する
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記機能変換部は、前記特定の機能を構成する単語の抽象化を用いて、前記特定の機能を前記特定の機能と異なる他の機能に変換する
ことを特徴とする請求項３に記載の情報処理装置。
【請求項６】
前記機能変換部は、前記特定の機能および前記他の機能のそれぞれの過去に利用された頻度情報を用いて、頻度が低い他の機能を経由する機能の機能変換を省略する
ことを特徴とする請求項３から請求項５のいずれか１つに記載の情報処理装置。
【請求項７】
コンピュータに、
所定のアイデアを実現するシステムに必要な複数の機能を取得し、
該取得された各機能を有するデバイスまたはＡＰＩを、機能とデバイスおよび機能とＡＰＩとをそれぞれ対応付けた機能情報から検索し、
前記複数の機能を有するデバイスまたはＡＰＩの組み合わせを複数生成し、
複数生成された組み合わせごとに、組み合わせを特定の要素で重み付けした評価関数を用いて評価し、
該評価された評価値に基づいて、所定の評価を有する前記組み合わせを提示する
処理をコンピュータに実行させることを特徴とする情報処理プログラム。
【請求項８】
コンピュータが、
所定のアイデアを実現するシステムに必要な複数の機能を取得し、
該取得された各機能を有するデバイスまたはＡＰＩを、機能とデバイスおよび機能とＡＰＩとをそれぞれ対応付けた機能情報から検索し、
前記複数の機能を有するデバイスまたはＡＰＩの組み合わせを複数生成し、
複数生成された組み合わせごとに、組み合わせを特定の要素で重み付けした評価関数を用いて評価し、
該評価された評価値に基づいて、所定の評価を有する前記組み合わせを提示する
各処理を実行することを特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置などに関する。
【背景技術】
【０００２】
あるアイデアを実現するためにシステムが開発される場合に、そのアイデアが備える機能を有するデバイスやＡＰＩ（Application  Program  Interface）が探索され、探索されたデバイスやＡＰＩを組み合わせて開発されることがある。かかるデバイスやＡＰＩを探索する方法として、ユーザが機能に関するキーワードを入力し、Ｗｅｂ検索するＷｅｂ検索システムが知られている。かかるＷｅｂ検索システムには、例えば、ＧｏｏｇｌｅのＷｅｂ検索システムが挙げられる。
【０００３】
また、ユーザの要求に応じてユーザの要求を満足するデバイスの情報を提供するデバイス情報提供システムが開示されている（例えば、特許文献１参照）。かかるシステムでは、ユーザの検索要求で指定された所望の出力結果を取得可能な処理モジュールを処理モジュールＤＢから抽出する。そして、システムでは、抽出された処理モジュールの入力要件と、各デバイスの出力要件とを比較することによって、抽出された処理モジュールの入力として利用可能な出力をもつ１または複数のデバイスをデバイスＤＢから抽出する。そして、システムでは、抽出した１又は複数のデバイスと抽出した処理モジュールの組み合わせからなる仮想デバイスを生成し、仮想デバイスの情報を検索結果としてユーザに提供する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１４−１５３７９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来の技術では、あるアイデアを実現する際に、このアイデアが備える機能を有するデバイスやＡＰＩの最適な組み合わせを見つけるのが難しいという問題がある。
【０００６】
例えば、Ｗｅｂ検索システムでは、Ｗｅｂ上のあらゆるＷｅｂページを検索するため、不必要なＷｅｂページが検索されることが多く、目的に合ったデバイスやＡＰＩの組み合わせを見つけるのが難しい。加えて、デバイスやＡＰＩのそれぞれの入出力などの仕様を比較したり、組み合わせの相性を調べたりすることが必要であり、最適な組み合わせを見つけるのが難しい。
【０００７】
また、デバイス情報提供システムであっても、デバイスやＡＰＩのそれぞれの入出力などの仕様を比較したり、組み合わせの相性を調べたりすることが必要であり、最適な組み合わせを見つけるのが難しい。
【０００８】
本発明は、１つの側面では、あるアイデアを実現する際に、このアイデアが備える機能を有するデバイスやＡＰＩの最適な組み合わせを効率的に見つけることを目的とする。
【課題を解決するための手段】
【０００９】
１つの態様では、情報処理装置は、所定のアイデアを実現するシステムに必要な複数の機能を取得する取得部と、前記取得部によって取得された各機能を有するデバイスまたはＡＰＩを、機能とデバイスおよび機能とＡＰＩとをそれぞれ対応付けた機能情報から検索する検索部と、前記複数の機能を有するデバイスまたはＡＰＩの組み合わせを複数生成する生成部と、前記生成部によって複数生成された組み合わせごとに、組み合わせを特定の要素で重み付けした評価関数を用いて評価する評価部と、前記評価部によって評価された評価値に基づいて、所定の評価を有する前記組み合わせを提示する提示部と、を有する。
【発明の効果】
【００１０】
１実施態様によれば、あるアイデアを実現する際に、このアイデアが備える機能を有するデバイスやＡＰＩの最適な組み合わせを効率的に見つけることができる。
【図面の簡単な説明】
【００１１】
【図１】図１は、実施例１に係る情報処理装置の構成を示す機能ブロック図である。
【図２Ａ】図２Ａは、実施例１に係る情報処理装置が実施する処理の概要を示す図（１）である。
【図２Ｂ】図２Ｂは、実施例１に係る情報処理装置が実施する処理の概要を示す図（２）である。
【図３】図３は、機能ＤＢのデータ構造の一例を示す図である。
【図４】図４は、デバイスＤＢのデータ構造の一例を示す図である。
【図５】図５は、ＡＰＩＤＢのデータ構造の一例を示す図である。
【図６】図６は、デバイス−機能ＤＢのデータ構造の一例を示す図である。
【図７】図７は、ＡＰＩ−機能ＤＢのデータ構造の一例を示す図である。
【図８】図８は、デバイス・ＡＰＩ間重みＤＢのデータ構造の一例を示す図である。
【図９】図９は、デバイス・ＡＰＩ間の重み算出の一例を示す図である。
【図１０】図１０は、実施例１に係る重み算出処理のフローチャートの一例を示す図である。
【図１１】図１１は、実施例１に係る組み合わせ判定処理のフローチャートの一例を示す図である。
【図１２】図１２は、実施例２に係る情報処理装置の構成を示す機能ブロック図である。
【図１３】図１３は、実施例２に係る代替機能検索処理の概要を示す図である。
【図１４】図１４は、機能変換ＤＢのデータ構造の一例を示す図である。
【図１５】図１５は、代替機能検索の別の例を示す図である。
【図１６】図１６は、実施例２に係る代替機能検索処理を含む組み合わせ判定処理のフローチャートの一例を示す図である。
【図１７】図１７は、実施例３に係る情報処理装置の構成を示す機能ブロック図である。
【図１８】図１８は、実施例３に係る代替機能検索調整の概要を示す図である。
【図１９】図１９は、実施例３に係る代替機能検索調整処理のフローチャートの一例を示す図である。
【図２０】図２０は、情報処理プログラムを実行するコンピュータの一例を示す図である。
【発明を実施するための形態】
【００１２】
以下に、本願の開示する情報処理装置、情報処理プログラムおよび情報処理方法の実施例を図面に基づいて詳細に説明する。なお、本発明は、実施例により限定されるものではない。
【実施例１】
【００１３】
［実施例１に係る情報処理装置の構成］
図１は、実施例１に係る情報処理装置の構成を示す機能ブロック図である。図１に示す情報処理装置１は、アイデアを実現するためにシステムが開発される場合に、このアイデアが備える各機能を有するデバイスやＡＰＩの組み合わせを特定の要素で重み付けするような評価関数を基に最適な組み合わせを提示する。ここでいうアイデアとは、例えば、「室温が２９度以上のときに、指で丸を描いたら、エアコンがＯＮになるシステム」、「位置に応じて、音楽を重畳して、音楽を再生するシステム」などが挙げられる。ここでいう評価関数とは、例えば、デバイスとデバイス、デバイスとＡＰＩ、ＡＰＩとＡＰＩのペアごとに特定の要素で重み付けした重み値をデバイスやＡＰＩの組み合わせごとに累計する関数のことをいう。なお、特定の要素の説明は、後述する。
【００１４】
ここで、実施例１に係る情報処理装置１が実施する処理の概要を図２Ａおよび図２Ｂを参照して説明する。図２Ａおよび図２Ｂは、実施例１に係る情報処理装置が実施する処理の概要を示す図である。なお、図２Ａは、入力データとしてアイデアデータを入力した場合の入力データに対するデバイスおよび機能の繋がりを示した模式図であり、グラフ構造により示している。ここでは、入力データとして入力したアイデアデータは、「室温が２９度以上のときに、指で丸を描いたら、エアコンがＯＮになるシステム」であるとする。そして、この模式図は、後述する各種ＤＢによって表現できるものとする。
【００１５】
図２Ａに示すように、情報処理装置１は、アイデアデータから複数の機能を抽出する。ここでは、アイデアデータが備える「温度を取得」，「ジェスチャ認識」，「エアコントロール」の各機能が抽出される。
【００１６】
そして、情報処理装置１は、抽出された各機能を有するデバイスまたはＡＰＩを検索する。ここでは、「温度を取得」の機能を有するデバイスまたはＡＰＩとして気象情報をセンサで取得するデバイスを示す「Ｎｅｔａｔｍｏ」と「温度センサ」とが取得される。「ジェスチャ認識」の機能を有するデバイスまたはＡＰＩとして指輪型ウェアラブル端末を示す「Ｒｉｎｇ」とジェスチャ認識のＡＰＩを示す「Ｋｉｎｅｃｔ」と「加速度センサ」とが取得される。「エアコントロール」の機能を有するデバイスまたはＡＰＩとしてＷｉＦｉ機能付きの赤外線リモコンデバイスを示す「ＩＲＫｉｔ」が取得される。
【００１７】
図２Ｂに示すように、情報処理装置１は、アイデアを実現するためにシステムが開発される場合に、このアイデアが備える各機能を有するデバイスやＡＰＩの組み合わせを探索する。ここでは、例えば、組み合わせＡとして、「温度を取得」の機能を備えるペアとして「ＰＣ」と「Ｎｅｔａｔｍｏ」、「ジェスチャ認識」の機能を備えるペアとして「ＰＣ」と「Ｒｉｎｇ」、「エアコントロール」の機能を備えるペアとして「ＰＣ」と「ＩＲＫｉｔ」が探索される。例えば、組み合わせＢとして、「温度を取得」の機能を備えるペアとして「ＰＣ」と「Ｎｅｔａｔｍｏ」、「ジェスチャ認識」の機能を備えるペアとして「ＰＣ」と「Ｋｉｎｅｃｔ」、「エアコントロール」の機能を備えるペアとして「ＰＣ」と「ＩＲＫｉｔ」が探索される。
【００１８】
そして、情報処理装置１は、組み合わせごとに、各組み合わせを特定の要素で重み付けするような評価関数により評価値を算出する。ここでは、評価関数は、デバイスとデバイス、デバイスとＡＰＩ、ＡＰＩとＡＰＩのペアをそれぞれ特定の要素で重み付けした重み値を組み合わせごとに累計する関数であるとする。特定の要素は、例えば、過去に利用されたペアの利用回数である。重み値は、例えば、特定の要素（過去に利用されたペアの利用回数）の要素値の逆数を重みとした値であるとする。つまり、ペアに対して利用回数が多い程、ペアの重み値が小さくなる。したがって、組み合わせに対する評価関数の評価値が小さい程、組み合わせに対する評価が高くなる。なお、過去に利用された利用回数は、例えば、ＩｏＴ系のＤＩＹサイトを用いて過去に利用されたデバイスやＡＰＩのペアの数をカウントすれば良い。一例として、ＰＣとＩＲＫｉｔのペアに対する重みは１／８０、ＰＣとＮｅｔａｔｍｏのペアに対する重みは１／２００、ＰＣとＲｉｎｇのペアに対する重みは１／１００であるとする。ＰＣとＫｉｎｅｃｔのペアに対する重みは１／５０、ＰＣとＡｒｄｕｉｎｏのペアに対する重みは１／２００、Ａｒｄｕｉｎｏと温度センサのペアに対する重みは１／２００であるとする。
【００１９】
すると、組み合わせＡに対する評価値は、１／８０と１／１００と１／２００とを加算して得られる２２／８００と計算される。組み合わせＢに対する評価値は、１／８０と１／５０と１／２００と１／２００とを加算して得られる３４／８００と計算される。
【００２０】
そして、情報処理装置１は、評価関数を基に最適な組み合わせを提示する。ここでは、組み合わせＡが組み合わせＢより評価値が小さいので、組み合わせＡが最適な組み合わせであることを見つける。そして、情報処理装置１は、組み合わせＡを最適な組み合わせとして提示する。
【００２１】
このようにして、情報処理装置１は、実現を所望するアイデアが備える機能を有するデバイスやＡＰＩの最適な組み合わせを効率的に見つけることができる。
【００２２】
図１に戻って、情報処理装置１は、制御部１０と、記憶部２０とを有する。
【００２３】
制御部１０は、ＣＰＵ（Central  Processing  Unit）などの電子回路に対応する。そして、制御部１０は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１０は、重み算出部１１、機能検索部１２、デバイス検索部１３、ＡＰＩ検索部１４、組み合わせ判定処理部１５および出力部１６を有する。
【００２４】
記憶部２０は、例えば、ＲＡＭ、フラッシュメモリ（Flash  Memory）などの半導体メモリ素子、または、ハードディスク、光ディスクなどの記憶装置である。記憶部２０は、機能ＤＢ（DataBase）２１、デバイスＤＢ２２、ＡＰＩＤＢ２３、デバイス−機能ＤＢ２４、ＡＰＩ−機能ＤＢ２５およびデバイス・ＡＰＩ間重みＤＢ２６を有する。機能ＤＢ２１は、アイデアに備わると予想される機能に関する情報を記憶する。デバイスＤＢ２２は、機能を有するデバイスの情報を記憶する。ＡＰＩＤＢ２３は、機能を有するＡＰＩの情報を記憶する。デバイス−機能ＤＢ２４は、デバイスと機能との対応付けを記憶する。ＡＰＩ−機能ＤＢ２５は、ＡＰＩと機能との対応付けを記憶する。デバイス・ＡＰＩ間重みＤＢ２６は、デバイスとデバイス、デバイスとＡＰＩ、ＡＰＩとＡＰＩのそれぞれのペアに対する重みを記憶する。
【００２５】
ここで、各種ＤＢのデータ構造の一例を、図３〜図７を参照して説明する。
【００２６】
図３は、機能ＤＢのデータ構造の一例を示す図である。図３に示すように、機能ＤＢ２１は、ＩＤ（Identifier）２１ａ、機能名２１ｂおよび特性２１ｃを対応付けて記憶する。ＩＤ２１ａは、機能を識別する識別子である。機能名２１ｂは、機能の名称である。特性２１ｃには、機能に対する各種の特性が記憶される。ここでは、一例として、特性２１ｃには、機能からレコメンドされたデバイスやＡＰＩを利用した回数が特性として記憶される。機能を経由して別の代替機能を選んだ回数が特性として記憶される。特性２１ｃに記憶される内容は、これに限定されることはない。なお、実施例１では、特性２１ｃは用いられないので省略されても良い。また、機能ＤＢ２１は、運用前に生成される。
【００２７】
一例として、ＩＤ２１ａが「ｆｅａｔ１」である場合に、機能名２１ｂとして「人の存在検知」を記憶している。ＩＤ２１ａが「ｆｅａｔ２」である場合に、機能名２１ｂとして「ドアの開閉検知」を記憶している。
【００２８】
図４は、デバイスＤＢのデータ構造の一例を示す図である。図４に示すように、デバイスＤＢ２２は、ＩＤ２２ａ、デバイス名２２ｂおよび特性２２ｃを対応付けて記憶する。ＩＤ２２ａは、デバイスを識別する識別子である。デバイス名２２ｂは、デバイスの名称である。特性２２ｃには、デバイスに対する各種の特性が記憶される。ここでは、一例として、特性２２ｃには、デバイスに対する価格、重さ、データ更新間隔やＩｎｐｕｔ／Ｏｕｔｐｕｔの種類が特性として記憶される。特性２２ｃに記憶される内容は、これに限定されることはない。なお、デバイスＤＢ２２は、運用前に生成される。
【００２９】
一例として、ＩＤ２２ａが「ｄｅｖ１」である場合に、デバイス名２２ｂとして「人検知ガジェットＡ」を記憶している。ＩＤ２２ａが「ｄｅｖ２」である場合に、デバイス名２２ｂとして「加速度センサ」を記憶している。
【００３０】
図５は、ＡＰＩＤＢのデータ構造の一例を示す図である。図５に示すように、ＡＰＩＤＢ２３は、ＩＤ２３ａ、ＡＰＩ名２３ｂおよび特性２３ｃを対応付けて記憶する。ＩＤ２３ａは、ＡＰＩを識別する識別子である。ＡＰＩ名２３ｂは、ＡＰＩの名称である。特性２３ｃには、ＡＰＩに対する各種の特性が記憶される。ここでは、一例として、特性２３ｃには、ＡＰＩを提供するサービスのＵＲＬ（uniform  resource  locator）を示すサービスＵＲＬが特性として記憶される。なお、実施例１では、特性２３ｃは用いられないので省略されても良い。また、ＡＰＩＤＢ２３は、運用前に生成される。
【００３１】
一例として、ＩＤ２３ａが「ａｐｉ１」である場合に、ＡＰＩ名２３ｂとして「オンライン決済ＡＰＩ」を記憶している。ＩＤ２３ａが「ａｐｉ２」である場合に、ＡＰＩ名２３ｂとして「天気予想ＡＰＩ」を記憶している。
【００３２】
図６は、デバイス−機能ＤＢのデータ構造の一例を示す図である。図６に示すように、デバイス−機能ＤＢ２４は、ＩＤ２４ａ、デバイスＩＤ２４ｂおよび機能ＩＤ２４ｃを対応付けて記憶する。ＩＤ２４ａは、デバイス−機能を識別する識別子である。デバイス−機能とは、デバイスと機能との対応付けを示し、このデバイスがこの機能を有することを意味する。デバイスＩＤ２４ｂは、デバイスのＩＤである。機能２４ｃは、機能のＩＤである。なお、デバイス−機能ＤＢ２４は、運用前に生成される。
【００３３】
一例として、ＩＤ２４ａが「ｄｅｖ１−ｆｅａｔ１」である場合に、デバイスＩＤ２４ｂとして「ｄｅｖ１」、機能ＩＤ２４ｃとして「ｆｅａｔ１」を記憶している。
【００３４】
図７は、ＡＰＩ−機能ＤＢのデータ構造の一例を示す図である。図７に示すように、ＡＰＩ−機能ＤＢ２５は、ＩＤ２５ａ、ＡＰＩＩＤ２５ｂおよび機能ＩＤ２５ｃを対応付けて記憶する。ＩＤ２５ａは、ＡＰＩ−機能を識別する識別子である。ＡＰＩ−機能とは、ＡＰＩと機能との対応付けを示し、このＡＰＩがこの機能を有することを意味する。ＡＰＩＩＤ２５ｂは、ＡＰＩのＩＤである。機能２５ｃは、機能のＩＤである。なお、ＡＰＩ−機能ＤＢ２５は、運用前に生成される。
【００３５】
一例として、ＩＤ２５ａが「ａｐｉ１−ｆｅａｔ７」である場合に、ＡＰＩＩＤ２５ｂとして「ａｐｉ１」、機能ＩＤ２５ｃとして「ｆｅａｔ７」を記憶している。
【００３６】
図８は、デバイス・ＡＰＩ間重みＤＢのデータ構造の一例を示す図である。図８に示すように、デバイス・ＡＰＩ間重みＤＢ２６は、ＩＤ２６ａ、デバイス・ＡＰＩのＩＤ２６ｂ、デバイス・ＡＰＩのＩＤ２６ｃ、利用回数２６ｄおよび重み２６ｅを対応付けて記憶する。ＩＤ２６ａは、デバイス・ＡＰＩとデバイス・ＡＰＩとのペアを識別する識別子である。「デバイス・ＡＰＩ」とは、便宜上、デバイスまたはＡＰＩを示すものとする。デバイス・ＡＰＩのＩＤ２６ｂは、ペアのうち一方のデバイス・ＡＰＩのＩＤである。デバイス・ＡＰＩのＩＤ２６ｃは、ペアのうち他方のデバイス・ＡＰＩのＩＤである。利用回数２６ｄは、ペアが過去に利用された利用回数である。重み２６ｅは、ペアに対する重み付けを示す重み値である。重み２６ｅは、一例として、利用回数の逆数である。なお、デバイス・ＡＰＩ間重みＤＢ２６は、運用前に重み算出部１１によって生成されるが、運用後に定期的または不定期的に再生成されても良い。過去に利用された利用回数は、例えば、ＩｏＴ系のＤＩＹサイトを用いて過去に利用されたデバイスやＡＰＩのペアの数をカウントすれば良い。
【００３７】
一例として、ＩＤ２６ａが「ｄｅｖ１−ｄｅｖ４」である場合に、デバイス・ＡＰＩのＩＤ２６ｂとして「ｄｅｖ１」、デバイス・ＡＰＩのＩＤ２６ｃとして「ｄｅｖ４」を記憶している。利用回数２６ｄとして「１００」、重み２６ｅとして「１／１００」を記憶している。
【００３８】
図１に戻って、重み算出部１１は、デバイスまたはＡＰＩとデバイスまたはＡＰＩとのペアに対する重みを算出する。例えば、重み算出部１１は、ＩｏＴ系のＤＩＹサイトをクローリングし、ＤＩＹサイトのあるプロジェクトで使われているデバイスおよびＡＰＩを取得する。重み算出部１１は、取得したデバイスおよびＡＰＩを用いて、デバイスまたはＡＰＩとデバイスまたはＡＰＩとのペアを生成する。そして、重み算出部１１は、生成したペアごとに、プロジェクトで利用された数をカウントする。そして、重み算出部１１は、生成したペアごとに、カウントの逆数を重みとして算出する。
【００３９】
また、重み算出部１１は、ペアごとに、一方のデバイスまたはＡＰＩ、他方のデバイスまたはＡＰＩ、カウント値および重み値を対応付けてデバイス・ＡＰＩ間重みＤＢ２６に格納する。
【００４０】
機能検索部１２は、アイデアに含まれる複数の機能を入力すると、入力した複数の機能がそれぞれ機能ＤＢ２１に登録されているか否かを検索する。例えば、機能検索部１２は、入力した機能と機能ＤＢ２１の機能名２１ｂとを照合し、合致するか否かを判定する。合致には、完全に合致する場合のみならず部分的に合致する場合や意味合いが類似する場合も含まれる。入力した複数の機能ごとに判定される。そして、機能検索部１２は、入力した複数の機能が全て合致する場合には、入力した複数の機能をデバイス検索部１３およびＡＰＩ検索部１４に出力する。なお、機能検索部１２は、アイデアに含まれる機能を受け付けると説明したが、これに限定されず、アイデアそのものを受け付ける場合であっても良い。アイデアそのものを受け付ける場合には、機能検索部１２は、受け付けたアイデアから形態素解析などの言語解析を用いてアイデアに含まれる機能を取得しても良い。
【００４１】
デバイス検索部１３は、機能を有するデバイスを検索する。例えば、デバイス検索部１３は、機能検索部１２から出力された機能に対応するデバイスをデバイス−機能ＤＢ２４から検索する。
【００４２】
ＡＰＩ検索部１４は、機能を有するＡＰＩを検索する。例えば、ＡＰＩ検索部１４は、機能検索部１２から出力された機能に対応するＡＰＩをＡＰＩ−機能ＤＢ２５から検索する。
【００４３】
組み合わせ判定処理部１５は、アイデアを実現するために用いられるデバイスおよびＡＰＩの組み合わせを判定する。
【００４４】
例えば、組み合わせ判定処理部１５は、デバイス検索部１３によって検索された機能に対応するデバイスおよびＡＰＩ検索部１４によって検索された機能に対応するＡＰＩを用いて、デバイスまたはＡＰＩとデバイスまたはＡＰＩとのペアを生成する。組み合わせ判定処理部１５は、生成したペアの中で接続可能なペアを記憶部２０の一時領域に保持する。一例として、組み合わせ判定処理部１５は、ペアの中で、ペアのデバイスまたはＡＰＩとデバイスまたはＡＰＩとがそれぞれインタフェース、プラットフォームやソフトウェア開発キット（ＳＤＫ：Softwere  Development  Kit）などの観点で接続可能なペアを抽出し、抽出したペアを保持する。これらデバイスまたはＡＰＩに対応するインタフェース、プラットフォームやＳＤＫは、特性としてＤＢに設定されれば良い。すなわち、デバイスの場合には、デバイスＤＢ２２の特性２２ｃに設定されれば良い。ＡＰＩの場合には、ＡＰＩＤＢ２３の特性２３ｃに設定されれば良い。そして、組み合わせ判定処理部１５は、デバイス・ＡＰＩ間重みＤＢ２６を参照し、接続可能なペアに対応する重みを取得する。
【００４５】
また、組み合わせ判定処理部１５は、アイデアに含まれる各機能を有するデバイスやＡＰＩの組み合わせを生成する。組み合わせ判定処理部１５は、生成した組み合わせごとに、各組み合わせに含まれるペアに対応する重みを合計する。そして、組み合わせ判定処理部１５は、各組み合わせの重みの合計を比較し、重みの合計が小さい組み合わせから順に並べ替える。すなわち、組み合わせ判定処理部１５は、アイデアに備えられる各機能を有するデバイスまたはＡＰＩの組み合わせに対して、組み合わせを特定の要素で重み付けするような評価関数を基に評価値（重みの合計値）が最小の組み合わせを最適な組み合わせと判定する。
【００４６】
出力部１６は、組み合わせ判定処理部１５によって判定された組み合わせを出力する。例えば、出力部１６は、重みの合計が小さい組み合わせから順に出力する。すなわち、出力部１６は、最適な組み合わせから順に提示する。なお、出力部１６は、重みの合計が小さい組み合わせだけを提示しても良い。
【００４７】
［デバイス・ＡＰＩ間の重み算出の一例］
ここで、デバイス・ＡＰＩ間の重み算出の一例を、図９を参照して説明する。図９は、デバイス・ＡＰＩ間の重み算出の一例を示す図である。
【００４８】
図９上図に示すように、ＩｏＴ系のＤＩＹサイト上の各プロジェクトページに、過去に利用されたデバイスのリストや過去に利用されたＡＰＩのリストが登録されているとする。ここでは、プロジェクト名が「プロジェクトＡ」である場合に、利用されたデバイスとして「ｄｅｖ１，ｄｅｖ４，ｄｅｖ５」が登録されている。利用されたＡＰＩとして「ａｐｉ１」が登録されている。プロジェクト名が「プロジェクトＢ」である場合に、利用されたデバイスとして「ｄｅｖ３，ｄｅｖ４」が登録されている。利用されたＡＰＩとして「ａｐｉ１，ａｐｉ２」が登録されている。
【００４９】
図９下図に示すように、重み算出部１１は、ＩｏＴ系のＤＩＹサイトをクローリングし、ＤＩＹサイトのプロジェクトで使われているデバイスおよびＡＰＩを取得する。重み算出部１１は、取得したデバイスおよびＡＰＩを用いて、デバイスまたはＡＰＩとデバイスまたはＡＰＩとのペアを生成する。ここでは、プロジェクトＡについて、「ｄｅｖ１−ｄｅｖ４」、「ｄｅｖ１−ｄｅｖ５」、「ｄｅｖ４−ｄｅｖ５」、「ｄｅｖ１−ａｐｉ１」、「ｄｅｖ４−ａｐｉ１」、「ｄｅｖ５−ａｐｉ１」のペアが生成される。
【００５０】
そして、重み算出部１１は、生成したペアごとに、プロジェクトで利用された数をカウントする。ここでは、一例として、重み算出部１１は、生成したペア「ｄｅｖ１−ｄｅｖ４」の数を１インクリメントした値を、デバイス・ＡＰＩ間重みＤＢ２６の「ｄｅｖ１−ｄｅｖ４」に対応する利用回数２６ｄに設定する。別の例として、重み算出部１１は、生成したペア「ｄｅｖ１−ａｐｉ１」の数を１インクリメントした値を、デバイス・ＡＰＩ間重みＤＢ２６の「ｄｅｖ１−ａｐｉ１」に対応する利用回数２６ｄに設定する。
【００５１】
そして、重み算出部１１は、生成したペアごとに、利用回数の逆数を重みとして算出する。ここでは、重み算出部１１は、「ｄｅｖ１−ｄｅｖ４」について、利用回数２６ｄが「１００」であるので、利用回数の逆数「１／１００」を重みとして算出し、デバイス・ＡＰＩ間重みＤＢ２６の重み２６ｅに設定する。重み算出部１１は、「ｄｅｖ１−ａｐｉ１」について、利用回数２６ｄが「２５」であるので、利用回数の逆数「１／２５」を重みとして算出し、デバイス・ＡＰＩ間重みＤＢ２６の重み２６ｅに設定する。
【００５２】
［重み算出処理のフローチャート］
次に、実施例１に係る重み算出処理のフローチャートを、図１０を参照して説明する。図１０は、実施例１に係る重み算出処理のフローチャートの一例を示す図である。なお、図１０では、ペアに対応する重みの算出は、ＩｏＴ系のＤＩＹサイトを利用して行われるものとする。
【００５３】
図１０に示すように、重み算出要求を受け付けた重み算出部１１は、ＩｏＴ系のＤＩＹサイトでクローリングしていないプロジェクトが他にあるか否かを判定する（ステップＳ１１）。他にあると判定した場合には（ステップＳ１１；Ｙｅｓ）、重み算出部１１は、他のプロジェクトを選択する（ステップＳ１２）。そして、重み算出部１１は、選択した他のプロジェクトで使われているデバイスおよびＡＰＩを取得する（ステップＳ１３）。
【００５４】
そして、重み算出部１１は、取得したデバイスおよびＡＰＩでペアにしていないものが他にあるか否かを判定する（ステップＳ１４）。ペアにしていないものが他にあると判定した場合には（ステップＳ１４；Ｙｅｓ）、重み算出部１１は、取得したデバイスおよびＡＰＩでペアを生成し、生成したペアの数をカウントする（ステップＳ１５）。すなわち、重み算出部１１は、生成したペアについて１だけインクリメントする。例えば、重み算出部１１は、デバイス・ＡＰＩ間重みＤＢ２６の該当するペアに対する利用回数２６ｄに１だけインクリメントした回数を設定する。そして、重み算出部１１は、ペアにしていないものを判定すべく、ステップＳ１４に移行する。
【００５５】
一方、ペアにしていないものが他にないと判定した場合には（ステップＳ１４；Ｎｏ）、重み算出部１１は、他のプロジェクトを判定すべく、ステップＳ１１に移行する。
【００５６】
ステップＳ１１において、クローリングしていないプロジェクトが他にないと判定した場合には（ステップＳ１１；Ｎｏ）、重み算出部１１は、ペアに対する重みを算出する（ステップＳ１６）。例えば、重み算出部１１は、デバイス・ＡＰＩ間重みＤＢ２６の各ペア（ＩＤ２６ａ）について、利用回数２６ｄの逆数を重み２６ｅに設定する。ただし、重み算出部１１は、利用回数２６ｄが０の場合には、０を重み２６ｅに設定する。そして、重み算出部１１は、重み算出処理を終了する。
【００５７】
［組み合わせ判定処理のフローチャート］
次に、実施例１に係る組み合わせ判定処理のフローチャートを、図１１を参照して説明する。図１１は、実施例１に係る組み合わせ判定処理のフローチャートの一例を示す図である。
【００５８】
図１１に示すように、アイデアに含まれる複数の機能の入力を受け付けた機能検索部１２は、入力された全ての機能を機能ＤＢ２１で検索したか否かを判定する（ステップＳ２１）。入力された全ての機能を機能ＤＢ２１で検索していないと判定した場合には（ステップＳ２１；Ｎｏ）、機能検索部１２は、入力された機能が機能ＤＢ２１に登録されているかを検索する（ステップＳ２２）。そして、機能検索部１２は、入力された機能を判定すべく、ステップＳ２１に移行する。
【００５９】
一方、入力された全ての機能を機能ＤＢ２１で検索したと判定した場合には（ステップＳ２１；Ｙｅｓ）、デバイス検索部１３は、入力された全ての機能それぞれに対し、デバイスを検索したか否かを判定する。加えて、ＡＰＩ検索部１４は、入力された全ての機能それぞれに対し、ＡＰＩを検索したか否かを判定する（ステップＳ２３）。すなわち、デバイス検索部１３は、全ての機能それぞれについて、機能を有するデバイスをデバイス−機能ＤＢ２４から検索する。ＡＰＩ検索部１４は、全ての機能それぞれについて、機能を有するＡＰＩをＡＰＩ−機能ＤＢ２５から検索する。
【００６０】
入力された全ての機能それぞれに対し、デバイスまたはＡＰＩを検索していないと判定した場合には（ステップＳ２３；Ｎｏ）、デバイス検索部１３は、該当機能を有するデバイスを検索する。加えて、ＡＰＩ検索部１４は、該当機能を有するＡＰＩを検索する（ステップＳ２４）。そして、ＡＰＩ検索部１４は、未処理の機能に対して検索すべく、ステップＳ２３に移行する。
【００６１】
一方、入力された全ての機能それぞれに対し、デバイスまたはＡＰＩを検索したと判定した場合には（ステップＳ２３；Ｙｅｓ）、組み合わせ判定処理部１５は、各機能に対応するデバイス・ＡＰＩで、組み合わせていないものがあるか否かを判定する（ステップＳ２５）。組み合わせていないものがあると判定した場合には（ステップＳ２５；Ｙｅｓ）、組み合わせ判定処理部１５は、組み合わせていないデバイス・ＡＰＩを組み合わせる（ステップＳ２６）。
【００６２】
そして、組み合わせ判定処理部１５は、接続可能なデバイス・ＡＰＩ同士の組み合わせを記憶部２０の一時領域に格納する（ステップＳ２７）。すなわち、組み合わせ判定処理部１５は、接続可能なデバイスまたはＡＰＩとデバイスまたはＡＰＩとのペアを記憶部２０に格納する。接続可能か否かは、例えば、デバイスＤＢ２２の特性２２ｃおよびＡＰＩＤＢ２３の特性２３ｃを用いて判定されれば良い。そして、組み合わせ判定処理部１５は、ステップＳ２８に移行する。
【００６３】
ステップＳ２８において、組み合わせ判定処理部１５は、接続可能なデバイス・ＡＰＩのペアの中で重みを取得していないペアがあるか否かを判定する（ステップＳ２８）。重みを取得していないペアがあると判定した場合には（ステップＳ２８；Ｙｅｓ）、組み合わせ判定処理部１５は、デバイス・ＡＰＩのペアに対する重みをデバイス・ＡＰＩ間重みＤＢ２６から取得する（ステップＳ２９）。そして、組み合わせ判定処理部１５は、組み合わせに対する重みの取得判定をすべく、ステップＳ２８に移行する。
【００６４】
一方、重みを取得していないペアがないと判定した場合には（ステップＳ２８；Ｎｏ）、組み合わせ判定処理部１５は、全ての機能を用いた組み合わせについて、各ペアの重みを合計する（ステップＳ３０）。そして、組み合わせ判定処理部１５は、デバイス・ＡＰＩを組み合わせるべく、ステップＳ２５に移行する。
【００６５】
ステップＳ２５において、組み合わせていないものがないと判定した場合には（ステップＳ２５；Ｎｏ）、組み合わせ判定処理部１５は、各組み合わせの重みの合計を比較する。そして、組み合わせ判定処理部１５は、重みの合計が小さい組み合わせから順に組み合わせ結果をソートする（ステップＳ３１）。
【００６６】
そして、出力部１６は、デバイス・ＡＰＩの組み合わせ結果を出力する（ステップＳ３２）。そして、出力部１６は、組み合わせ判定処理を終了する。
【００６７】
なお、評価関数は、デバイスとデバイス、デバイスとＡＰＩ、ＡＰＩとＡＰＩのペアを特定の要素で重み付けした重み値を組み合わせごとに累計する関数であるとすると説明した。そして、特定の要素は、例えば、過去に利用されたペアの利用回数であると説明した。しかしながら、特定の要素は、これに限定されない。特定の要素は、例えば、過去３ヶ月に利用されたペアの利用回数としても良い。また、特定の要素は、同じ種類のＳＤＫやプログラミング言語であるか否かの情報、同じプラットフォームやＳＤＫであるか否かの情報、同じ種類の通信インタフェースであるか否かの情報としても良い。また、特定の要素は、値段、大きさ（サイズ、重さ）、設置場所、防水か否か、開発の難易度や複雑度、レスポンス速度の情報であっても良い。また、特定の要素は、これらの要素を組み合わせても良い。
【００６８】
また、評価関数は、組み合わせを特定の要素で重み付けするような関数であっても良い。ここでいう特定の要素は、例えば、組み合わせに含まれるデバイスやＡＰＩの数である。すなわち、組み合わせに含まれるデバイスやＡＰＩの数が増加するにしたがって、組み合わせをレコメンドされにくくなるような重みが付けられるようにすれば良い。
【００６９】
［実施例１の効果］
このようにして、上記実施例１では、情報処理装置１は、所定のアイデアを実現するシステムに必要な複数の機能を取得する。情報処理装置１は、取得された各機能を有するデバイスまたはＡＰＩを、デバイス−機能ＤＢ２４およびＡＰＩ−機能ＤＢ２５から検索する。情報処理装置１は、複数の機能を有するデバイスまたはＡＰＩの組み合わせを複数生成する。情報処理装置１は、複数生成された組み合わせごとに、組み合わせを特定の要素で重み付けした評価関数を用いて評価する。そして、情報処理装置１は、評価された評価値に基づいて、所定の評価を有する組み合わせを提示する。かかる構成によれば、情報処理装置１は、あるアイデアを実現する際に、実現したい機能を有するデバイスやＡＰＩの最適な組み合わせを効率的に見つけることができる。
【００７０】
また、上記実施例１では、情報処理装置１は、複数生成された組み合わせごとに、組み合わせを、デバイスまたはＡＰＩのペアの利用頻度、組み合わせに含まれるデバイスまたはＡＰＩのペアの数およびペアのインタフェースの少なくとも１つを含む特定の要素で重み付けした評価関数を用いて評価する。かかる構成によれば、情報処理装置１は、デバイスまたはＡＰＩの組み合わせを特定の要素で重み付けした評価関数を用いて評価することで、最適な組み合わせを効率的に見つけることができる。
【実施例２】
【００７１】
ところで、実施例１では、情報処理装置１が、アイデアが備える各機能を有するデバイスまたはＡＰＩを検索し、検索したデバイスおよびＡＰＩの組み合わせを判定すると説明した。しかしながら、機能を有するデバイスまたはＡＰＩを検索できなかったり、機能を有するデバイスまたはＡＰＩを検索できても品質特性に収まらなかったりする場合がある。かかる場合には、情報処理装置１は、検索で用いられる特定の機能を別の機能に変換し、変換した別の機能を有するデバイスまたはＡＰＩを検索するようにしても良い。なお、別の機能を有するデバイスまたはＡＰＩがない場合には、情報処理装置１は、別の機能をさらに別の機能に変換し、機能を再帰的に変換するようにすれば良い。
【００７２】
そこで、実施例２では、情報処理装置１が、検索で用いられる特定の機能を別の機能に変換し、変換した別の機能を有するデバイスまたはＡＰＩを検索する場合について説明する。
【００７３】
［実施例２に係る情報処理装置の構成］
図１２は、実施例２に係る情報処理装置の構成を示す機能ブロック図である。なお、図１に示す情報処理装置１と同一の構成については同一符号を示すことで、その重複する構成および動作の説明については省略する。実施例１と実施例２とが異なるところは、代替機能検索部３１および機能変換ＤＢ３２を追加した点にある。
【００７４】
代替機能検索部３１は、特定の機能を有するデバイスまたはＡＰＩが検索されない場合または特定の機能を有するデバイスまたはＡＰＩが検索されても検索されたデバイスまたはＡＰＩが所定の品質特性を満たさない場合には、以下の処理を行う。すなわち、代替機能検索部３１は、機能変換ＤＢ３２を用いて、特定の機能を、特定の機能と異なる他の機能に変換する。
【００７５】
ここで、実施例２に係る代替機能検索処理の概要を、図１３を参照して説明する。図１３は、実施例２に係る代替機能検索処理の概要を示す図である。なお、図１３は、入力データとしてアイデアデータを入力した場合の入力データに対するデバイスおよび機能の繋がりを示した模式図であり、グラフ構造により示している。この模式図は、各種ＤＢによって表現される。
【００７６】
ここでは、予算が「５０００円」である場合に、「人の存在を検知」という機能を有するデバイスを検索するものとする。ここでいう予算は、品質特性のことである。なお、デバイスＤＢ２２には、デバイス名２２ｂが「人検知ガジェット」である場合に、特性２２ｃの価格として「１００００円」が記憶されている。デバイス名２２ｂが「加速度センサ」である場合に、特性２２ｃの価格として「２００円」が記憶されている。デバイス名２２ｂが「焦電型人感センサ」は記憶されていないとする。そして、デバイス−機能ＤＢ２４には、デバイスとして「人検知ガジェット」、機能として「人の存在を検知」が対応付けられている。デバイスとして「加速度センサ」、機能として「加速度を取得」が対応付けられている。
【００７７】
このような状況の下、デバイス検索部１３は、「人の存在を検知」するという機能を有するデバイスを検索する。ここでは、「人検知ガジェット」は、デバイスＤＢ２２に記憶されている。「人検知ガジェット」は、デバイス−機能ＤＢ２４に記憶され、「人の存在を検知」するという機能を有するデバイスである。したがって、「人検知ガジェット」が「人の存在を検知」するという機能を有するデバイスとして検索される。なお、「焦電型人感センサ」は、デバイスＤＢ２２に記憶されていないので、「焦電型人感センサ」が仮に「人の存在を検知」するという機能を有していても、検索されない。
【００７８】
ところが、検索できたデバイス「人検知ガジェット」は、値段が「１００００円」であり、予算「５０００円」を満たさない。
【００７９】
そこで、代替機能検索部３１は、「人の存在を検知」という特定の機能を有するデバイスが検索されても検索されたデバイスが品質特性を満たさない場合であるので、機能変換ＤＢ３２を用いて、特定の機能を、特定の機能と異なる他の機能に変換する。ここでは、機能変換ＤＢ３２は、変換前の機能として「ドアの開閉を検知」および変換後の機能として「人の存在を検知」を対応付ける。すなわち、「ドアの開閉を検知」から「人の存在を検知」に変換可能であることを示す。また、機能変換ＤＢ３２は、変換前の機能として「加速度を取得」および変換後の機能として「ドアの開閉を検知」を対応付ける。すなわち、「加速度を取得」から「ドアの開閉を検知」に変換可能であることを示す。したがって、代替機能検索部３１は、機能変換ＤＢ３２を用いて、特定の機能「人の存在を検知」から「ドアの開閉を検知」、「ドアの開閉を検知」から「加速度を取得」と辿って特定の機能と異なる他の機能に変換する。
【００８０】
そして、デバイス検索部１３は、変換された他の機能を有するデバイスをデバイス−機能ＤＢ２４から検索する。ここでは、「加速度を取得」という機能を有するデバイスとして「加速度センサ」が検索される。検索できたデバイス「加速度センサ」は、値段が「２００円」であり、予算「５０００円」を満たす。
【００８１】
このようにして、情報処理装置１は、特定の機能を有するデバイスが検索されなかったり、検索されても品質特性を満たさなかったりした場合であっても、特定の機能を他の機能に代替することで、他の機能を有するデバイスを特定の機能を有するデバイスとして提示（レコメンド）することが可能となる。
【００８２】
図１４は、機能変換ＤＢのデータ構造の一例を示す図である。図１４に示すように、機能変換ＤＢ３２は、ＩＤ３２ａ、変換前機能ＩＤ３２ｂ、変更後機能ＩＤ３２ｃおよび特性３２ｄを対応付けて記憶する。ＩＤ３２ａは、変換前機能−変換後機能を識別する識別子である。変換前機能−変換後機能とは、変換前機能と変換後機能との対応付けを示し、変換後機能から変換前機能に変換可能であることを意味する。変換前機能ＩＤ３２ｂは、変換前機能のＩＤである。変換後機能ＩＤ３２ｃは、変換後機能のＩＤである。特性３２ｄには、機能変換に対する各種の特性が記憶される。特性３２ｄには、例えば、変換モジュールＵＲＬが含まれる。変換モジュールＵＲＬとは、機能を変換する際の変換モジュールのＵＲＬを意味する。すなわち、機能「歩数を取得」を機能「加速度を取得」に変換する際、「加速度」から「歩数」に変換するモジュール（プログラム）が公開されたＵＲＬのことを意味する。なお、機能変換ＤＢ３２は、運用前に生成される。
【００８３】
一例として、ＩＤ３２ａが「ｆｅａｔ２−ｆｅａｔ１」である場合に、変換前機能ＩＤ３２ｂとして「ｆｅａｔ２」、変換後機能ＩＤ３２ｃとして「ｆｅａｔ１」を記憶している。具体的には、ｆｅａｔ２を示す「ドアの開閉を検知」およびｆｅａｔ１を示す「人の存在を検知」の対応付けを記憶している。
【００８４】
なお、代替機能検索部３１は、特定の機能を有するデバイスまたはＡＰＩが検索されない場合または特定の機能を有するデバイスまたはＡＰＩが検索されても検索されたデバイスまたはＡＰＩが所定の品質特性を満たさない場合には、機能変換ＤＢ３２を用いて、特定の機能を、特定の機能と異なる他の機能に変換すると説明した。しかしながら、代替機能検索部３１は、特定の機能を有するデバイスまたはＡＰＩが検索されない場合または特定の機能を有するデバイスまたはＡＰＩが検索されても検索されたデバイスまたはＡＰＩが所定の品質特性を満たさない場合には、特定の機能を構成する単語の抽象化を考慮することで、特定の機能を、特定の機能と異なる他の機能に変換しても良い。ここでいう「単語の抽象化」とは、具体的な単語の上位概念の単語への抽象化を意味する。
【００８５】
［代替機能検索の別の例］
ここで、代替機能検索の別の例として、代替機能検索部３１が、特定の機能を構成する単語の抽象化を考慮することで、特定の機能を、特定の機能と異なる他の機能に変換する場合について説明する。図１５は、代替機能検索の別の例を示す図である。なお、図１５は、入力データとしてアイデアデータを入力した場合の入力データに対するデバイスおよび機能の繋がりを示した模式図であり、グラフ構造により示している。この模式図は、各種ＤＢによって表現される。
【００８６】
ここでは、予算が「２，０００円」およびサイズが「コンパクトなモノ」である場合に、「水を吸い上げる」という機能を有するデバイスを検索するものとする。ここでいう予算およびサイズが品質特性のことである。なお、デバイスＤＢ２２には、デバイス名２２ｂが「水中ポンプ」である場合に、特性２２ｃの価格として「１５，０００円」、特性２２ｃのサイズとして「３０ｃｍ×３０ｃｍ×３０ｃｍ」が記憶されている。デバイス名２２ｂが「灯油ポンプ」である場合に、特性２２ｃの価格として「８００円」、特性２２ｃのサイズとして「２ｃｍ×５ｃｍ×１５ｃｍ」が記憶されている。そして、デバイス−機能ＤＢ２４には、デバイスとして「水中ポンプ」、機能として「水を吸い上げる」が対応付けられている。また、デバイスとして「灯油ポンプ」、機能として「灯油を吸い上げる」が対応付けられている。
【００８７】
このような状況の下、デバイス検索部１３は、「水を吸い上げる」という機能を有するデバイスを検索する。ここでは、「水中ポンプ」は、デバイスＤＢ２２に記憶されている。「水中ポンプ」は、デバイス−機能ＤＢ２４に記憶され、「水を吸い上げる」という機能を有するデバイスである。したがって、「水中ポンプ」が「水を吸い上げる」という機能を有するデバイスとして検索される。
【００８８】
ところが、検索できたデバイス「水中ポンプ」は、値段が「１５，０００円」であり、予算「２，０００円」を満たさない。
【００８９】
そこで、代替機能検索部３１は、「水を吸い上げる」という特定の機能を構成する単語の抽象化を考慮することで、特定の機能を、特定の機能と異なる他の機能に変換する。ここでは、具体的な単語「水」および「灯油」が上位概念の単語「液体」へ抽象化されるとする。かかる単語の抽象化は、予めＤＢに登録しておけば良い。したがって、代替機能検索部３１は、単語の抽象化から「水」を「灯油」にして、「水を吸い上げる」という特定の機能を「灯油を吸い上げる」という他の機能に変換する。
【００９０】
そして、デバイス検索部１３は、変換された他の機能を有するデバイスをデバイス−機能ＤＢ２４から検索する。ここでは、「灯油を吸い上げる」という機能を有するデバイスとして「灯油ポンプ」が検索される。検索できたデバイス「灯油ポンプ」は、値段が「８００円」であり、予算「２，０００円」を満たす。さらに、「水中ポンプ」より「灯油ポンプ」の方がサイズが小さく、サイズ「コンパクトなモノ」を満たす。
【００９１】
このようにして、情報処理装置１は、特定の機能を有するデバイスが検索されなかったり、検索されても品質特性を満たさなかったりした場合であっても、特定の機能を他の機能に代替することで、他の機能を有するデバイスを特定の機能を有するデバイスとして提示（レコメンド）することが可能となる。
【００９２】
［組み合わせ判定処理のフローチャート］
次に、代替機能検索処理を含む組み合わせ判定処理のフローチャートを、図１６を参照して説明する。図１６は、実施例２に係る代替機能検索処理を含む組み合わせ判定処理のフローチャートの一例を示す図である。
【００９３】
図１６に示すように、アイデアに含まれる複数の機能の入力を受け付けた機能検索部１２は、入力された全ての機能を機能ＤＢ２１で検索したか否かを判定する（ステップＳ４１）。入力された全ての機能を機能ＤＢ２１で検索していないと判定した場合には（ステップＳ４１；Ｎｏ）、機能検索部１２は、入力された機能が機能ＤＢ２１に登録されているかを検索する（ステップＳ４２）。そして、機能検索部１２は、入力された機能を判定すべく、ステップＳ４１に移行する。
【００９４】
一方、入力された全ての機能を機能ＤＢ２１で検索したと判定した場合には（ステップＳ４１；Ｙｅｓ）、デバイス検索部１３は、入力された全ての機能それぞれに対し、デバイスを検索したか否かを判定する。加えて、ＡＰＩ検索部１４は、入力された全ての機能それぞれに対し、ＡＰＩを検索したか否かを判定する（ステップＳ４３）。すなわち、デバイス検索部１３は、全ての機能それぞれについて、機能を有するデバイスをデバイス−機能ＤＢ２４から検索する。ＡＰＩ検索部１４は、全ての機能それぞれについて、機能を有するＡＰＩをＡＰＩ−機能ＤＢ２５から検索する。
【００９５】
入力された全ての機能それぞれに対し、デバイスまたはＡＰＩを検索していないと判定した場合には（ステップＳ４３；Ｎｏ）、デバイス検索部１３は、該当機能を有するデバイスを検索する。加えて、ＡＰＩ検索部１４は、該当機能を有するＡＰＩを検索する（ステップＳ４４Ａ）。
【００９６】
デバイス検索部１３およびＡＰＩ検索部１４は、検索したデバイス・ＡＰＩが品質特性に収まっているか否かを判定する（ステップＳ４４Ｂ）。検索したデバイス・ＡＰＩが品質特性に収まっていると判定した場合には（ステップＳ４４Ｂ；Ｙｅｓ）、デバイス検索部１３およびＡＰＩ検索部１４は、未処理の機能に対して検索すべく、ステップＳ４３に移行する。
【００９７】
一方、検索したデバイス・ＡＰＩが品質特性に収まっていないと判定した場合には（ステップＳ４４Ｂ；Ｎｏ）、代替機能検索部３１は、機能変換ＤＢ３２に代替機能があるか否かを判定する（ステップＳ４４Ｃ）。機能変換ＤＢ３２に代替機能がないと判定した場合には（ステップＳ４４Ｃ；Ｎｏ）、代替機能検索部３１は、未処理の機能に対して検索すべく、ステップＳ４３に移行する。
【００９８】
一方、機能変換ＤＢ３２に代替機能があると判定した場合には（ステップＳ４４Ｃ；Ｙｅｓ）、代替機能検索部３１は、現在の機能を代替機能に更新する（ステップＳ４４Ｄ）。すなわち、代替機能検索部３１は、機能変換ＤＢ３２を用いて、現在の機能を、現在の機能と異なる他の機能に変換する。そして、代替機能検索部３１は、代替機能を有するデバイス・ＡＰＩを検索させるべく、ステップＳ４４Ａに移行する。
【００９９】
ステップＳ４３において、入力された全ての機能それぞれに対し、デバイスまたはＡＰＩを検索したと判定した場合には（ステップＳ４３；Ｙｅｓ）、組み合わせ判定処理部１５は、各機能に対応するデバイス・ＡＰＩで、組み合わせていないものがあるか否かを判定する（ステップＳ４５）。組み合わせていないものがあると判定した場合には（ステップＳ４５；Ｙｅｓ）、組み合わせ判定処理部１５は、組み合わせていないデバイス・ＡＰＩを組み合わせる（ステップＳ４６）。
【０１００】
そして、組み合わせ判定処理部１５は、接続可能なデバイス・ＡＰＩ同士の組み合わせを記憶部２０の一時領域に格納する（ステップＳ４７）。すなわち、組み合わせ判定処理部１５は、接続可能なデバイスまたはＡＰＩとデバイスまたはＡＰＩとのペアを記憶部２０に格納する。接続可能か否かは、例えば、デバイスＤＢ２２の特性２２ｃおよびＡＰＩＤＢ２３の特性２３ｃを用いて判定されれば良い。そして、組み合わせ判定処理部１５は、ステップＳ４８に移行する。
【０１０１】
ステップＳ４８において、組み合わせ判定処理部１５は、接続可能なデバイス・ＡＰＩのペアの中で重みを取得していないペアがあるか否かを判定する（ステップＳ４８）。重みを取得していないペアがあると判定した場合には（ステップＳ４８；Ｙｅｓ）、組み合わせ判定処理部１５は、デバイス・ＡＰＩのペアに対する重みをデバイス・ＡＰＩ間重みＤＢ２６から取得する（ステップＳ４９）。そして、組み合わせ判定処理部１５は、組み合わせに対する重みの取得判定をすべく、ステップＳ４８に移行する。
【０１０２】
一方、重みを取得していないペアがないと判定した場合には（ステップＳ４８；Ｎｏ）、組み合わせ判定処理部１５は、全ての機能を用いた組み合わせについて、各ペアの重みを合計する（ステップＳ５０）。そして、組み合わせ判定処理部１５は、デバイス・ＡＰＩを組み合わせるべく、ステップＳ４５に移行する。
【０１０３】
ステップＳ４５において、組み合わせていないものがないと判定した場合には（ステップＳ４５；Ｎｏ）、組み合わせ判定処理部１５は、各組み合わせの重みの合計を比較する。そして、組み合わせ判定処理部１５は、重みの合計が小さい組み合わせから順に組み合わせ結果をソートする（ステップＳ５１）。
【０１０４】
そして、出力部１６は、デバイス・ＡＰＩの組み合わせ結果を出力する（ステップＳ５２）。そして、出力部１６は、組み合わせ判定処理を終了する。
【０１０５】
［実施例２の効果］
このようにして、上記実施例２では、情報処理装置１は、特定の機能を有するデバイスまたはＡＰＩが検索されない場合または検索されたデバイスまたはＡＰＩが所定の品質特性を満たさない場合には、特定の機能を、特定の機能と異なる他の機能に変換する。そして、情報処理装置１は、変換された他の機能を有するデバイスまたはＡＰＩを含むデバイスまたはＡＰＩの組み合わせを複数生成する。かかる構成によれば、情報処理装置１は、あるアイデアを実現する際に、実現したい機能を有するデバイスまたはＡＰＩがなかったり、品質特性を満たさなかったりしても、機能を代替させることで、実現したい機能を有するデバイスやＡＰＩの組み合わせを効率的に見つけることができる。
【０１０６】
また、上記実施例２では、情報処理装置１は、機能変換ＤＢ３２を用いて、第２の機能から変換された第１の機能を有するデバイスまたはＡＰＩが品質特性を満たすまで、再帰的に、特定の機能を、特定の機能と異なる他の機能に変換する。かかる構成によれば、情報処理装置１は、特定の機能を他の機能に再帰的に変換することで、特定の機能として品質特性を満たすデバイスまたはＡＰＩを提示することが可能となる。
【０１０７】
また、上記実施例２では、情報処理装置１は、特定の機能を構成する単語の抽象化を用いて、特定の機能を特定の機能と異なる他の機能に変換する。かかる構成によれば、情報処理装置１は、単語の抽象化を用いて特定の機能を他の機能に変換することで、特定の機能として品質特性を満たすデバイスまたはＡＰＩを提示することが可能となる。
【実施例３】
【０１０８】
ところで、実施例１では、情報処理装置１が、アイデアが備える各機能を有するデバイスまたはＡＰＩを検索し、検索したデバイスおよびＡＰＩの組み合わせを判定すると説明した。また、実施例２では、情報処理装置１は、機能を有するデバイスまたはＡＰＩを検索できなかったり、検索できても品質特性に収まらなかったりする場合には、以下の処理を行うと説明した。すなわち、情報処理装置１は、機能変換ＤＢ３２を用いて、機能を別の機能に変換（代替）する処理を再帰的に行う。しかしながら、情報処理装置１は、代替可能な機能が増加するに従い、実現したいアイデアの内容から実際には使用されない代替機能も網羅的に検索することとなるので、検索処理に負荷や時間がかかる。したがって、情報処理装置１は、過去に利用された利用頻度が低い代替機能の場合には、この代替機能に続く再帰的な代替処理を継続しないようにしても良い。
【０１０９】
そこで、実施例３では、情報処理装置１が、過去に利用された利用頻度が低い代替機能の場合には、この代替機能に続く再帰的な代替処理を継続しない場合について説明する。
【０１１０】
［実施例３に係る情報処理装置の構成］
図１７は、実施例３に係る情報処理装置の構成を示す機能ブロック図である。なお、図１２に示す情報処理装置１と同一の構成については同一符号を示すことで、その重複する構成および動作の説明については省略する。実施例２と実施例３とが異なるところは、代替機能検索調整部４１を追加した点にある。
【０１１１】
代替機能検索調整部４１は、代替機能検索処理を調整する。例えば、代替機能検索調整部４１は、代替機能検索部３１によって現在の機能が他の機能に変換される場合には、現在の機能から検索されたデバイスまたはＡＰＩが過去に利用された回数を取得する。加えて、代替機能検索調整部４１は、現在の機能を経由して代替機能が選ばれた回数を取得する。そして、代替機能検索調整部４１は、取得した回数のうち最も大きい回数を示す機能を選択する。代替機能検索調整部４１は、選択した機能が現在の機能でない場合には、代替機能を現在の機能に更新し、引き続き、代替機能検索の調整を行う。また、代替機能検索調整部４１は、選択した機能が現在の機能である場合には、デバイス検索部１３およびＡＰＩ検索部１４に現在の機能に対する検索を行わせる。つまり、代替機能検索調整部４１は、代替機能の利用頻度が低い場合には、この代替機能に続く再帰的な代替処理を継続しない。
【０１１２】
なお、現在の機能から検索されたデバイスまたはＡＰＩが過去に利用された回数や現在の機能を経由して代替機能が選ばれた回数は、機能ＤＢ２１の特性２１ｃにそれぞれ記憶されれば良い（図３を参照）。
【０１１３】
ここで、実施例３に係る代替機能検索調整の概要を、図１８を参照して説明する。図１８は、実施例３に係る代替機能検索調整の概要を示す図である。なお、機能ＤＢ２１には、機能名２１ｂが「人の存在検知」である場合に、特性２１ｃにおける機能から検索されたデバイスを利用した回数として「３」、特性２１ｃにおける機能を経由して別の代替機能を選んだ回数として「３７」を記憶している。機能名２１ｂが「ドアの開閉検知」である場合に、特性２１ｃにおける機能から検索されたデバイスを利用した回数として「５」、特性２１ｃにおける機能を経由して別の代替機能を選んだ回数として「１２」を記憶している。機能名２１ｂが「床マット圧力取得」である場合に、特性２１ｃにおける機能から検索されたデバイスを利用した回数として「２０」、特性２１ｃにおける機能を経由して別の代替機能を選んだ回数として「０」を記憶している。
【０１１４】
このような状況の下、代替機能検索部３１は、現在の機能「人の存在検知」を有するデバイスまたはＡＰＩが検索されても検索されたデバイスまたはＡＰＩが所定の品質特性を満たさなかったとする。すると、代替機能検索部３１は、機能変換ＤＢ３２を用いて、現在の機能「人の存在検知」を、現在の機能と異なる他の機能に変換する。ここでは、代替機能検索部３１は、現在の機能「人の存在検知」を「ドアの開閉検知」に変換する。代替機能検索部３１は、現在の機能「人の存在検知」を「床マット圧力取得」に変換する。
【０１１５】
そして、代替機能検索調整部４１は、現在の機能「人の存在検知」から検索されたデバイスまたはＡＰＩが過去に利用された回数を取得する。ここでは、「３」が取得される。加えて、代替機能検索調整部４１は、現在の機能「人の存在検知」を経由して代替機能が選ばれた回数を取得する。ここでは、「３７」が取得される。そこで、代替機能検索調整部４１は、現在の機能の回数「３」が代替機能の回数「３７」より小さい場合であるので、代替機能「ドアの開閉検知」および代替機能「床マット圧力取得」をそれぞれ現在の機能に更新し、引き続き、代替機能検索の調整を行う。
【０１１６】
現在の機能が「ドアの開閉検知」である場合には、代替機能検索調整部４１は、現在の機能から検索されたデバイスまたはＡＰＩが過去に利用された回数を取得する。ここでは、「５」が取得される。加えて、代替機能検索調整部４１は、現在の機能を経由して代替機能が選ばれた回数を取得する。ここでは、「１２」が取得される。現在の機能が「床マット圧力取得」である場合には、代替機能検索調整部４１は、現在の機能から検索されたデバイスまたはＡＰＩが過去に利用された回数を取得する。ここでは、「２０」が取得される。加えて、代替機能検索調整部４１は、現在の機能を経由して代替機能が選ばれた回数を取得する。ここでは、「０」が取得される。そして、代替機能検索調整部４１は、取得した回数のうち最も大きい回数を示す機能を選択する。ここでは、現在の機能としての「床マット圧力取得」が最も大きい回数を示す機能として選択される。そこで、代替機能検索調整部４１は、選択した機能「床マット圧力取得」が現在の機能であるので、デバイス検索部１３およびＡＰＩ検索部１４に現在の機能「床マット圧力取得」に対する検索を行わせる。つまり、代替機能検索調整部４１は、現在の機能としての「ドアの開閉検知」およびその機能を経由する代替機能に対する検索を省略する。
【０１１７】
これにより、代替機能検索調整部４１は、過去に利用された利用頻度が低い代替機能に続く再帰的な代替処理を継続しないことで、利用頻度が低い代替機能に続く代替処理を省略することができ、代替機能の検索処理に負荷や時間がかかることを抑制できる。
【０１１８】
［代替機能検索調整処理のフローチャート］
次に、代替機能検索調整処理のフローチャートを、図１９を参照して説明する。図１９は、実施例３に係る代替機能検索調整処理のフローチャートの一例を示す図である。なお、代替機能検索部３１は、現在の機能を有するデバイスが検索されるが、検索されたデバイスが品質特性を満たさなかったとする。
【０１１９】
図１９に示すように、代替機能検索部３１は、機能変換ＤＢ３２に、現在の機能に対応する代替機能があるか否かを判定する（ステップＳ６１）。代替機能がないと判定した場合には（ステップＳ６１；Ｎｏ）、代替機能検索調整部４１は、代替機能検索調整処理を終了する。
【０１２０】
一方、代替機能があると判定した場合には（ステップＳ６１；Ｙｅｓ）、代替機能検索調整部４１は、機能ＤＢ２１を参照し、現在の機能から検索されたデバイス・ＡＰＩが過去利用された回数を取得する（ステップＳ６２）。加えて、代替機能検索調整部４１は、機能ＤＢ２１を参照し、現在の機能を経由して代替機能が選ばれた回数を取得する（ステップＳ６３）。
【０１２１】
代替機能検索調整部４１は、取得回数が最も大きい機能を選択する（ステップＳ６４）。そして、代替機能検索調整部４１は、選択した機能が現在の機能であるか否かを判定する（ステップＳ６５）。選択した機能が現在の機能でないと判定した場合には（ステップＳ６５；Ｎｏ）、代替機能検索調整部４１は、現在の機能を、選択した代替機能に更新する（ステップＳ６６）。そして、代替機能検索調整部４１は、現在の機能を他の機能に変換すべく、ステップＳ６１に移行する。
【０１２２】
一方、選択した機能が現在の機能であると判定した場合には（ステップＳ６５；Ｙｅｓ）、代替機能検索調整部４１は、代替機能検索調整処理を終了する。
【０１２３】
［実施例３の効果］
このようにして、上記実施例３では、情報処理装置１は、現在の機能および他の機能を過去に利用された利用頻度を用いて、利用頻度が低い他の機能を経由する当該他の機能と異なる他の機能の機能変換を省略する。かかる構成によれば、情報処理装置１は、代替機能の機能変換を省略することで、代替機能の機能変換処理に負荷や時間がかかることを抑制できる。
【０１２４】
［その他］
なお、実施例３では、代替機能検索調整部４１は、現在の機能および他の機能を過去に利用された利用頻度を用いて、利用頻度が低い他の機能を経由する当該他の機能と異なる他の機能の機能変換を省略すると説明した。しかしながら、代替機能検索調整部４１は、これに限定されず、機能と機能との間の移植性や機能と機能との間の理解容易性を用いて、機能変換を省略しても良い。機能と機能との間の移植性とは、特定の機能の固有の能力を他の機能に有効的且つ効率的に移植できるかの度合いのことをいう。例えば、「ドアの開閉」から「人の存在検知」へ機能変換する場合を説明する。「ドアの開閉」は、人以外にも動物や風によって起こるため、「ドアの開閉」から有効的に「人の存在検知」を行うことができない。したがって、「ドアの開閉」から「人の存在検知」へ機能変換する場合には、機能と機能との間の移植性は低い。すなわち、代替機能検索調整部４１は、機能と機能との間の移植性を用いて、移植性が低い機能変換を省略しても良い。機能と機能との間の移植性は、例えば、機能変換ＤＢ３２の特性３２ｄ内のPortability  Weightの欄に記憶されれば良い。設定値は、任意に入力されるが、一例として、「１」が移植性が高く、「３」が移植性が低いという意味で設定されても良い。また、機能と機能との間の理解容易性とは、特定の機能から他の機能に変換するときのソフトウェア的、またはハードウェア的な処理の理解のし易さや難しさの度合いのことをいう。すなわち、代替機能検索調整部４１は、機能と機能との間の理解容易性を用いて、理解容易性が難しい機能変換を省略しても良い。機能と機能との間の理解容易性は、例えば、機能変換ＤＢ３２の特性３２ｄ内のUnderstandability  Weightの欄に記憶されれば良い。設定値は、任意に入力されるが、一例として、「１」が理解容易であり、「３」が難しいという意味で設定されても良い。
【０１２５】
また、図示した情報処理装置１の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、情報処理装置１の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、デバイス検索部１３およびＡＰＩ検索部１４を１つの部として統合しても良い。また、記憶部２０を情報処理装置１の外部装置としてネットワーク経由で接続するようにしても良い。
【０１２６】
また、上記実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１に示した情報処理装置１と同様の機能を実現する情報処理プログラムを実行するコンピュータの一例を説明する。図２０は、情報処理プログラムを実行するコンピュータの一例を示す図である。
【０１２７】
図２０に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ２０３と、ユーザからのデータの入力を受け付ける入力装置２１５と、表示装置２０９を制御する表示制御部２０７とを有する。また、コンピュータ２００は、記憶媒体からプログラムなどを読取るドライブ装置２１３と、ネットワークを介して他のコンピュータとの間でデータの授受を行う通信制御部２１７とを有する。また、コンピュータ２００は、各種情報を一時記憶するメモリ２０１と、ＨＤＤ２０５を有する。そして、メモリ２０１、ＣＰＵ２０３、ＨＤＤ２０５、表示制御部２０７、ドライブ装置２１３、入力装置２１５、通信制御部２１７は、バス２１９で接続されている。
【０１２８】
ドライブ装置２１３は、例えばリムーバブルディスク２１１用の装置である。ＨＤＤ２０５は、情報処理プログラム２０５ａおよび情報処理関連情報２０５ｂを記憶する。
【０１２９】
ＣＰＵ２０３は、情報処理プログラム２０５ａを読み出して、メモリ２０１に展開し、プロセスとして実行する。かかるプロセスは、情報処理装置１の各機能部に対応する。情報処理関連情報２０５ｂは、機能ＤＢ２１、デバイスＤＢ２２、ＡＰＩＤＢ２３、デバイス−機能ＤＢ２４、ＡＰＩ−機能ＤＢおよびデバイス・ＡＰＩ間重みＤＢ２６に対応する。そして、例えばリムーバブルディスク２１１が、情報処理プログラム２０５ａなどの各情報を記憶する。
【０１３０】
なお、情報処理プログラム２０５ａについては、必ずしも最初からＨＤＤ２０５に記憶させておかなくても良い。例えば、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に当該プログラムを記憶させておく。そして、コンピュータ２００がこれらから情報処理プログラム２０５ａを読み出して実行するようにしても良い。
【符号の説明】
【０１３１】
１  情報処理装置
１０  制御部
１１  重み算出部
１２  機能検索部
１３  デバイス検索部
１４  ＡＰＩ検索部
１５  組み合わせ判定処理部
１６  出力部
２０  記憶部
２１  機能ＤＢ
２２  デバイスＤＢ
２３  ＡＰＩＤＢ
２４  デバイス−機能ＤＢ
２５  ＡＰＩ−機能ＤＢ
２６  デバイス・ＡＰＩ間重みＤＢ
【図１】
2018194900.tif 000003
【図２Ａ】
2018194900.tif 000004
【図２Ｂ】
2018194900.tif 000005
【図３】
2018194900.tif 000006
【図４】
2018194900.tif 000007
【図５】
2018194900.tif 000008
【図６】
2018194900.tif 000009
【図７】
2018194900.tif 000010
【図８】
2018194900.tif 000011
【図９】
2018194900.tif 000012
【図１０】
2018194900.tif 000013
【図１１】
2018194900.tif 000014
【図１２】
2018194900.tif 000015
【図１３】
2018194900.tif 000016
【図１４】
2018194900.tif 000017
【図１５】
2018194900.tif 000018
【図１６】
2018194900.tif 000019
【図１７】
2018194900.tif 000020
【図１８】
2018194900.tif 000021
【図１９】
2018194900.tif 000022
【図２０】
2018194900.tif 000023