ネットワーク事業者と開発者とを仲介する装置
複数のネットワーク事業者と１以上の開発者とを仲介する装置が提供される。この装置は、各ネットワーク事業者により要求されるコンピュータ・プログラムに関する要件を取得する取得部と、取得された要件のうち相互に関連する要件を一つの要件に統合する統合部と、統合された要件を実装するコンピュータ・プログラムの開発の必要性に関する情報を生成する生成部と、１以上の開発者に統合された要件と必要性に関する情報とを提示する提示部とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のネットワーク事業者と１以上の開発者とを仲介する装置に関する。
【背景技術】
【０００２】
多くの通信事業者及びインターネット・サービス・プロバイダが、ユーザのホーム・ネットワークとのインタフェースのために、自身のネットワークにおいてＤＳＬモデム、Ｏ／Ｅコンバータ、ＰＰＰｏＥターミネータのようなゲートウェイを配置している。ゲートウェイの従来の機能は、ゲートウェイによる仲介なしにはネットワークへアクセスできないデバイスのためのプロトコル変換を管理することである。
【０００３】
これらのゲートウェイは今日ではＪａｖａ（登録商標）についての動的モジュール・システムであるＯＳＧｉフレームワークのようなソフトウェア実行環境を含むようになってきている。ＯＳＧｉフレームワークはＪａｖａ仮想マシンを再起動することなく動的にソフトウェア・モジュールをその上に追加／削除することを可能にする。このようなソフトウェア・モジュールはＯＳＧｉの用語ではバンドルと呼ばれる。リモート管理プロトコルと組み合わせることによって、ＯＳＧｉフレームワークはリモートから管理され、動的且つオンデマンドに新たなソフトウェア・モジュールを配置することができる。
【０００４】
このようなソフトウェア実行環境を利用することによって、パーソナル・ネットワーク内のデバイスを発見してこれらのデバイスのための制御ＡＰＩを公開するゲートウェイ上のソフトウェアをネットワーク事業者が実行することが可能となり、その結果としてネットワーク事業者はユーザのためにデバイスにアクセスして制御することができる。これは、管理されたゲートウェイを利用することによって、パーソナル・ネットワーク内のデバイスを監視して制御することによって達成される各種のケアテイキング・サービス、例えばＷｉｆｉアクセスポイント自動構成サービス、ホーム・オートメイション及び家庭エネルギー管理をネットワーク事業者が提供できることを意味する。事業者がこのようなサービスを提供しようとする場合に、幅広いデバイスのためのプログラムを制御して監視する必要がある。なぜなら、パーソナル・ネットワークは様々なプロトコル・セットを用いるかもしれない幅広いデバイスを含み得るからである。一部のデバイスはリモート制御のために用いられ得るＵＰｎＰのような標準プロトコルをサポートする。しかしながら、制御及び構成のための独自仕様のプロトコルを用いる必要のある大量のデバイスが存在する。例えば、ＵＰｎＰをサポートしないがＷｅｂＧＵＩだけをサポートするＷｉｆｉアクセスポイントを遠隔から構成するために、ゲートウェイは、特定のＨＴＴＰ ＵＲＬを伴うことに基づくコマンド・セットを実装する必要がある。
【０００５】
一つのネットワーク事業者にとって、パーソナル・ネットワーク内のすべてのデバイスに対してこのようなプロトコル固有の通信ソフトウェア又はデバイス固有のプログラムを実装することは現実的ではない。この種のコンピュータ・プログラムはデバイス固有ソフトウェア（ＤＳＳ）と呼ばれる。一つの解決策はサードパーティにＤＳＳの開発を依頼することであろうが、これは費用がかさむ。複数のネットワーク事業者が連合（フェデレーション）を形成し、一緒にＤＳＳのための使用を策定し、ＤＳＳの作成をサードパーティに命じた場合に、各事業者のコストは分担することで軽減されるだろう。連合マーケットプレイスに関するこのようなアイデアに関して、特許文献１は宣伝のための連合マーケットプレイスを導入する。しかしながら、このような連合を作ることは以下のような問題を生じる。複数のネットワーク事業者間で合意と仕様とを策定することは多大なコストと努力とを必要とする。また、各ネットワーク事業者は他のネットワーク事業者へ要件を公開する必要があり、すなわち連合内のネットワーク事業者は他のネットワーク事業者がユーザに何を提供しようとしているかを推測することができる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許出願公開２００８／１０３７９５号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従って、各通信事業者がコンピュータ・プログラムの要件を秘密にしつつ、ネットワーク事業者により要求されるコンピュータ・プログラムの必要性及び要件を開発者が判定できる技術が望まれる。
【課題を解決するための手段】
【０００８】
本発明の一つの側面によれば、複数のネットワーク事業者と１以上の開発者とを仲介する装置が提供される。この装置は、各ネットワーク事業者により要求されるコンピュータ・プログラムに関する要件を取得する取得部と、前記取得された要件のうち相互に関連する要件を一つの要件に統合する統合部と、前記統合された要件を実装するコンピュータ・プログラムの開発の必要性に関する情報を生成する生成部と、前記１以上の開発者に前記統合された要件と前記必要性に関する情報とを提示する提示部とを備える。
【０００９】
本発明の更なる特徴は添付の図面を参照する以下の例示的な実施形態の説明から明らかになるだろう。
【図面の簡単な説明】
【００１０】
【図１】ＦＢＳ１００を含む例示的な環境を説明する。
【図２】ＦＢＳ１００の例示的なブロック図を説明する。
【図３】ＦＢＳ１００の例示的な動作を説明する。
【図４】例示的なテンプレートＡＰＩリスト４００を説明する。
【図５】例示的なサービス・ディスクリプション５００を説明する。
【図６】例示的なサービス・ディスクリプション・リスト６００を説明する。
【図７】例示的な要求ＤＳＳリスト７００を説明する。
【図８】例示的な適応プログラム８００を説明する。
【発明を実施するための形態】
【００１１】
本発明の実施形態が添付の図面を参照しつつ以下に説明される。以下に説明される各実施形態は汎用のものからより具体的なものまで多様な概念の理解に役立つだろう。本発明の技術的範囲は特許請求の範囲によって規定され、以下に説明される各実施形態には限定されないことに留意されたい。さらに、実施形態で説明される機能のすべての組み合わせが本発明に常に必要不可欠であるとは限らない。
【００１２】
図１は本発明の実施形態に係る連合仲介サーバ（ＦＢＳ）１００を含む例示の環境を説明する。ＦＢＳ１００は事業者ネットワーク１０１ａ−１０１ｎと開発者１０２ａ−１０２ｎとに接続される。事業者ネットワーク１０１ａはネットワーク事業者Ａによって運営され、事業者ネットワーク１０１ｂはネットワーク事業者Ｂによって運営され、以下同様である。つまり、事業者ネットワーク１０１ａ−１０１ｎは相異なるネットワーク事業者によって運営される。本実施形態では複数の開発者１０２ａ−１０２ｎが存在するものの、本発明は一人だけの開発者が存在する場合にも適用される。事業者ネットワーク１０１ａ−１０１ｎは集合的に事業者ネットワーク（群）１０１と表され、開発者１０２ａ−１０２ｎは集合的に開発者（群）１０２と表される。本実施形態は事業者ネットワーク１０１ａと開発者１０２ａとの観点から説明されるが、この説明は他の事業者ネットワーク１０１ｂ−１０１ｎと開発者１０２ｂ−１０２ｎとにも適用される。
【００１３】
事業者ネットワーク１０１ａはパーソナル・ネットワーク１０３に接続される。パーソナル・ネットワーク１０３は、パーソナル・ネットワーク１０３の所有者のまわりのデバイスが論理ネットワークを構成するように互いに相互接続されているネットワークである。デバイスはサードパーティのサービス・プロバイダと他のユーザのパーソナル・ネットワークに広域ネットワークを介して公開されている。パーソナル・ネットワーク１０３は本発明が適用されるローカル・ネットワークの一例である。ローカル・ネットワークの他の例は、ローカルエリアネットワーク（ＬＡＮ）、パーソナルエリアネットワーク（ＰＡＮ）、カー・ネットワークなどである。パーソナル・ネットワーク１０３内のデバイスは、パーソナル・ネットワーク要素（ＰＮＥ）１０６と呼ばれる。パーソナル・ネットワーク１０３はまたゲートウェイ（Ｇ／Ｗ）１０５を備え、ゲートウェイ１０５を通じてＰＮＥ１０６と事業者ネットワーク１０１ａとが互いに通信する。ゲートウェイ１０５はＰＮＥ１０６を制御するための制御ＡＰＩを公開する。
【００１４】
事業者ネットワーク１０１ａはパーソナル・ネットワーク・アプリケーション・サーバ（ＰＮＡＳ）１０４を備える。ＰＮＡＳはＰＮＥ１０６のコンテンツ情報を引き出して広める集約ポイントとして用いられる装置であり、このコンテンツ情報はデバイス・プレゼンスと能力情報とを含む。
【００１５】
ネットワーク事業者ＡはＰＮＥ１０６を監視して制御することによって様々なサービスをパーソナル・ネットワーク１０３のユーザへ提供する。ネットワーク事業者Ａによって提供されるサービスの例は以下である。
‐パーソナル・ネットワークのための自動構成：ＩＰルータやＷｉｆｉアクセスポイントのようなネットワーク機器を通常の人々が構成することは難しい作業である。トラブルシューティングも人々にとって難しいタスクである。従って、リモートから構成を監視して管理することによってネットワーク事業者Ａがこのような作業をサポートする。
‐自動ライト制御：例えばユーザがリビングルームにいて映画が始まる場合に明かりを暗くするというように、ＰＮＡＳ１０４はＰＮＥ１０６を介してユーザの位置と活動とを監視してユーザの周りのライトを制御する。
【００１６】
ネットワーク事業者Ａは各サービスに対してサービス・ディスクリプションを有する。サービス・ディスクリプションは対応するサービスを実行するための動作を記載している。サービス・ディスクリプションの例は後述される。ネットワーク事業者Ａは、ＰＮＥ１０６に対する動作を実行するために必要となるコンピュータ・プログラム（ＤＳＳ）の作成を依頼するために、ＦＢＳ１００へサービス・ディスクリプションを提供する。本発明によれば、サービス・ディスクリプション内の要件はＡＰＩの形式で記載される。しかしながら、要件を参照して開発者１０２がコンピュータ・プログラムを開発できさえすれば、本発明はどのような形式で記載された要件にも適用できる。
【００１７】
ＦＢＳ１００はネットワーク事業者と開発者１０２とを仲介する。ＦＢＳ１００はネットワーク事業者からサービス・ディスクリプションを取得する。各デバイスは固有の機能集合のみを有するため、同一カテゴリ内のデバイスはデバイスに対する同一又は類似のＡＰＩをネットワーク事業者が要求し、従って、ネットワーク事業者からの要求ＡＰＩのリストは重複しがちであると想定することは合理的である。相異なるネットワーク事業者が、入出力値の単位、パス名のような各ＡＰＩに対するわずかに異なる要件を有することは容易に生じる。後述されるように、ＦＢＳ１００はテンプレートＡＰＩをネットワーク事業者へ提供することによる問題を解決する。
【００１８】
開発者１０２ａはＦＢＳ１００により提示されたコンピュータ・プログラムを開発する。開発者１０２ａはサードパーティの開発者であってもよいし、オープンソースの開発者であってもよいし、フリー・プログラマであってもよい。
【００１９】
図２は本実施形態に係るＦＢＳ１００の例示的なブロック図を説明する。ＦＢＳ１００は、ＣＰＵ２０１、メモリ２０２、事業者Ｉ／Ｆ２０３、記憶装置２０４、統合部２０５、生成部２０６、開発者Ｉ／Ｆ２０７、検証部２０８、取得部２０９、提示部２１０、及び収集部２１１を備える。ＣＰＵ２０１はＦＢＳ１００の全体的な動作を制御する。図２において、ＣＰＵ２０１から各部への線は省略されている。メモリ２０２はＦＢＳ１００の動作のために用いられるコンピュータ・プログラムとデータとを記憶する。事業者Ｉ／Ｆ２０３はネットワーク事業者とＦＢＳ１００との間のインタフェースである。開発者Ｉ／Ｆ２０７は開発者とＦＢＳ１００との間のインタフェースである。記憶装置２０４は統計データ、テンプレートＡＰＩリスト４００、サービス・ディスクリプション・リスト６００、要求ＤＳＳリスト７００、及びＤＳＳレポジトリを備え、これらの詳細は後述される。記憶装置は例えばＨＤＤで実装される。他のユニットはＦＢＳ１００の動作を通じて後で説明される。
【００２０】
図３は本発明の実施形態に係るＦＢＳ１００の例示的な動作を説明する。ＣＰＵ２０１はこれらのステップを実行するために、メモリ２０２に記憶されたコンピュータ・プログラムを実行する。
【００２１】
ステップＳ３０１で、収集部２１１は事業者ネットワーク１０１内のＰＮＡＳ１０４からＰＮＥ１０６に関する統計を収集する。収集部２１１は記憶装置２０４内の統計データベースに収集された統計を登録する。統計は各デバイス・タイプについて、各事業者ネットワークに接続されたパーソナル・ネットワーク１０３に含まれるデバイス数を含んでもよい。
【００２２】
ステップＳ３０２で、取得部２０９はネットワーク事業者Ａからサービス・ディスクリプションを取得する。上述のように、サービス・ディスクリプションはＤＳＳに対する要件をＡＰＩの形式で含む。ネットワーク事業者ＡはステップＳ３０２に先立って、ＦＢＳ１００の所有者と合意された形式でサービス・ディスクリプションを準備する。提示部は、ネットワーク事業者Ａによるサービス・ディスクリプションの生成を支援するために、ネットワーク事業者ＡにテンプレートＡＰＩを提示してもよい。図４は例示的なテンプレートＡＰＩリスト４００を記載する。リスト４００の各エントリはデバイスに対する所定の動作を実行するためのテンプレートＡＰＩを規定する。列「デバイス・カテゴリ」４０１はデバイスのカテゴリを記載する。ＷｉＦＩアクセスポイントのような同一のカテゴリに含まれるデバイスはＳＳＩＤの取得のような同一又は類似の動作を有する傾向にある。これにより、デバイスの固有のデバイス・タイプが異なっていたとしても、同一のカテゴリ内のデバイスに対する動作を同一の方法で実行できるという利点を生む。列「動作カテゴリ」４０２は、デバイス内のパラメータの設定又は取得に用いられる「パラメータ処理」、デバイスへのコマンドの実行に用いられる「コマンド実行」、デバイスの特定のイベントの検出に用いられる「イベント検出」のような、所定の動作のカテゴリを記載する。列「ＡＰＩ名」４０３は所定の動作に対する名称を記載する。列「テンプレートＡＰＩ」４０４は所定の動作を実現するために要求されるテンプレートＡＰＩの詳細を記載する。例えば、リスト４００の１番目のエントリは、カテゴリがＷｉｆｉアクセスポイントであるデバイスのＳＳＩＤを取得するためのテンプレートＡＰＩを規定する。テンプレートＡＰＩは変更可能な属性を含んでもよい。例えば、リスト４００内の１番目のエントリでは、「パス」が変更可能である。この変更可能な属性は、相異なるネットワーク事業者の間の相異なる要件を調整するために有用である。その結果として、テンプレートＡＰＩリスト４００は相異なるネットワーク事業者からの幅広いユースケースをカバーできる。ＡＰＩに対するＤＳＳが開発された後にＦＢＳ１００が属性を変更可能な場合にＦＢＳ１００は属性を変更可能として設定する。本実施形態によれば、開発されたＤＳＳ内の属性をネットワーク事業者Ａからの要件に従って調整する補足的なコンピュータ・プログラムをＦＢＳ１００が作成可能な場合に、ＦＢＳ１００は属性を変更可能に設定する。これにより、一つのＤＳＳがわずかに異なる要件をカバーでき、それによってＤＳＳの価値が向上するという利点を生む。
【００２３】
ネットワーク事業者ＡはテンプレートＡＰＩのリスト４００を用いてサービス・ディスクリプションを記述してもよい。図５は例示的なサービス・ディスクリプション５００を説明する。サービス・ディスクリプション５００の各エントリは所定のサービスを実行するための要件を規定する。列「サービス名」５０１はネットワーク事業者Ａが実行するサービスの名称を記載する。列５０２、５０３は図４の列４０１、４０３と同じである。列「優先度」５０４は動作のための優先度を記載する。例えば、要求ＡＰＩがサービスに必須である場合に優先度は「高」に設定されてもよく、一方で、要求ＡＰＩがサービスにオプションである場合に優先度は「低」に設定されてもよい。列「要求ＡＰＩ」は動作を実行するために要求されたＡＰＩの詳細を記載する。ネットワーク事業者Ａはネットワーク事業者Ａの要件を満たすテンプレートＡＰＩを選択し、要求ＡＰＩにテンプレートＡＰＩを調整するように変更可能な属性を変更する。例えば、ネットワーク事業者Ａは図５の「パス」属性を設定する。
【００２４】
ステップＳ３０２で、取得部２０９は取得されたサービス・ディスクリプションを記憶装置２０４に記憶する。ネットワーク事業者から取得されたサービス・ディスクリプションはサービス・ディスクリプション・リストとして保持される。図６は例示的なサービス・ディスクリプション・リスト６００を説明する。リスト６００の各エントリは各ネットワーク事業者から取得された要求ＡＰＩを記載する。列「事業者名」６０１は要求ＡＰＩが取得されたネットワーク事業者の名称を記載する。列６０２−６０４、６０６は図５の対応する列と同じである。列「ＡＰＩ ＩＤ」はリスト６００のエントリを識別するＩＤである。「ＡＰＩ ＩＤ」６０５は要求ＡＰＩと統合ＡＰＩとの間の関係性を追跡するために用いられる。ステップＳ３０３で、取得部２０９はサービス・ディスクリプション・リスト６００が更新されたことを統合部２０５に通知する。
【００２５】
ステップＳ３０４で、統合部２０５は相互に関連する要求ＡＰＩを一つのＡＰＩに統合する。本実施形態によれば、ＡＰＩを統合するために、統合部２０５は要求ＡＰＩとテンプレートＡＰＩとを比較する。サービス・ディスクリプション・リスト６００内の二つ以上の要求ＡＰＩが同一のテンプレートＡＰＩに対応する場合に、統合部２０５はこれらの要求ＡＰＩが相互に関連すると判定し、これらの要求ＡＰＩを一つの統合ＡＰＩに統合する。例えば、サービス・ディスクリプション・リスト６００内の１番目のエントリと５番目のエントリとはテンプレートＡＩＰリスト４００内の１番目のエントリに対応し、従って統合部２０５はこれらの要求ＡＰＩを統合する。
【００２６】
統合部２０５は統合ＡＰＩを要求ＤＳＳリストに登録する。図７は例示的な要求ＤＳＳリスト７００を説明する。要求ＤＳＳリスト７００の各エントリは開発されるべき要求ＤＳＳを記載する。列７０１、７０２は図６の列６０２、６０３と同じである。列「統合ＡＰＩ」７０３は統合ＡＰＩの詳細を記載する。列７０４、７０５は後述する。サービス・ディスクリプション・リスト６００内の１番目のエントリと５番目のエントリとは要求ＤＳＳリスト７００の１番目のエントリに統合される。統合部２０５は１番目のエントリ内の「パス」属性をデフォルト値に置き換えることに留意されたい。このように、統合部２０５は統合ＡＰＩ内の変更可能な属性をデフォルト値に置き換え、次いで統合ＡＰＩを要求ＤＳＳリスト７００に登録する。ステップＳ３０５で、統合部２０５は要求ＤＳＳリスト７００が更新されたことを生成部２０６に通知する。
【００２７】
ステップＳ３０６で、生成部２０６は統合ＡＰＩを実装するＤＳＳの開発の必要性に関する情報を生成する。本実施形態によれば、生成部２０６は統計データベースに記憶されている各デバイス・タイプについて必要性を判定する。生成部２０６は図７に示されるように、各統合ＡＰＩについてすべてのデバイス・タイプを登録する。この例では、統計データベースはデバイスＩＤが「ＡＡ００１０」、「ＢＢ００２０」である「Ｗｉｆｉアクセスポイント」カテゴリ内の二つのデバイス・タイプを含む。列「デバイスＩＤ」７０４はＤＳＳが開発されることが要求されるデバイスのデバイスＩＤを記載する。次いで、生成部２０６は各デバイスＩＤについて必要性を判定する。生成部２０６は例えば統計データベースに記憶された統計と要求ＡＰＩの重要度との少なくとも一方に基づいて必要性を判定する。生成部２０６は統合ＡＰＩが高い優先度を有する場合に必要性に対してより大きな値を設定する。なぜなら、ネットワーク事業者はＤＳＳのためにより高い金額を払うだろうからである。これに加えて又はこれに代えて、生成部２０６は所定のデバイスＩＤについてのデバイス数が多い場合に必要性に対してより大きな値を設定する。例えば、ＩＤが「ＡＡ００１０」であるデバイスの数が、ＩＤが「ＢＢ００２０」であるデバイスの数の２倍である場合に、生成部２０６は「ＡＡ００１０」のための値が「ＢＢ００２０」のための値の２倍になるように必要性を設定する。必要性の値はＤＳＳの開発に対する推定支払額に対応してもよい。生成部２０６はＤＳＳにすでに記憶されているＤＳＳの必要性をゼロに設定してもよい。ステップＳ３０７で、生成部２０６は要求ＤＳＳリスト７００が更新されたことを提示部２１０に通知する。
【００２８】
ステップＳ３０８で、提示部２１０は開発者１０２へ要求ＤＳＳリスト７００を開発者Ｉ／Ｆ２０７を介して提示する。要求ＤＳＳリスト７００が個々のネットワーク事業者に関する情報を一切示していないことに留意されたい。すなわち、各ネットワーク事業者は、ネットワーク事業者がサービスを提供する自身のサービス・ディスクリプションとデバイス数とを他のネットワーク事業者及び開発者１０２から秘密にすることができる。
【００２９】
ステップＳ３０９で、開発者１０２ａは要求ＤＳＳリスト７００を参照してＤＳＳを開発する。開発者１０２ａはより高い必要性を有するＤＳＳを開発するだろう。ステップＳ３１０で、取得部２０９は開発されたＤＳＳを開発者１０２ａから開発者Ｉ／Ｆ２０７を介して取得する。ステップＳ３１１で、取得部２０９は取得されたＤＳＳを検証部２０８へ転送する。
【００３０】
ステップＳ３１２で、検証部２０８は取得されたＤＳＳを検証する。例えば、検証部２０８はＤＳＳが悪意のあるコードを含むかをＪａｖａのサンドボックス技術を用いて調べる。ＤＳＳを調べた後に、検証部２０８はＤＳＳレポジトリにＤＳＳを登録する。検証部２０８は個別のデバイスに対してＤＳＳを調べなくてもかまわない。なぜなら、ＤＳＳを広範に配布する前にＤＳＳをどのようにテストするかはネットワーク事業者しだいだからである。ステップＳ３１３で、検証部２０８はＤＳＳレポジトリが更新されたことを提示部２１０へ通知する。
【００３１】
ステップＳ３１４で、提示部２１０は更新されたＤＳＳレポジトリを事業者Ｉ／Ｆ２０３を介してネットワーク事業者へ提示する。ステップＳ３１５で、ネットワーク事業者ＡはＤＳＳレポジトリ内のＤＳＳを、例えばゲートウェイ１０５へＤＳＳを配信するために又は自身のアプリケーションストアに置くために要求する。ＦＢＳ１００はＤＳＳについてネットワーク事業者に課金してもよい。
【００３２】
ステップＳ３１６で、事業者Ｉ／Ｆ２０３はどのＤＳＳがネットワーク事業者Ａから要求されたかを統合部２０５へ通知する。
【００３３】
ステップＳ３１７で、統合部２０５は適合プログラムを生成する。上述のように、サービス・ディスクリプション５００におけるＡＰＩと要求ＤＳＳリスト６００におけるＡＰＩとは異なる。すなわち、開発されたＤＳＳは適合プログラムなしには動作しない。例えば、ネットワーク事業者Ａが名称が「Ｇｅｔ ＳＳＩＤ」であるＡＰＩについてのＳＤＤを要求した場合に、統合部２０５はサービス・ディスクリプション・リスト６００を参照して、ネットワーク事業者Ａから取得された要求ＡＰＩを見つける。次いで、統合部２０５は図８に記載されたような適合プログラム８００を作成する。統合部２０５は最終配信プログラムとして提供するようにこれらのプログラムを結合してもよい。
【００３４】
ステップＳ３１８で、統合部２０５は適合プログラムが作成されたことを提示部２１０へ通知する。
【００３５】
ステップＳ３１９で、提示部２１０は要求されたＤＳＳとこれに対応する適合プログラムとを事業者Ｉ／Ｆ２０３を介してネットワーク事業者Ａへ提供する。
【００３６】
本実施形態によれば、各ネットワーク事業者がコンピュータ・プログラムへの要件を秘密にしつつ、開発者がネットワーク事業者により要求されたコンピュータ・プログラムへの必要性を判定できる。各ネットワーク事業者はコンピュータ・プログラムを取得するためのコストを低減できる。各ネットワーク事業者は互いに要件を共有する必要がなく、また特定のＤＳＳに対する仕様を共同で開発する必要もない。
【００３７】
本発明は例示的な実施形態を参照して説明されてきたが、本発明は開示した例示の実施形態に限定されないと理解されるべきである。以下の特許請求の範囲はこのような修正及び均等な構造及び機能をすべて包含するような最も広い解釈に一致する。
【技術分野】
【０００１】
本発明は、複数のネットワーク事業者と１以上の開発者とを仲介する装置に関する。
【背景技術】
【０００２】
多くの通信事業者及びインターネット・サービス・プロバイダが、ユーザのホーム・ネットワークとのインタフェースのために、自身のネットワークにおいてＤＳＬモデム、Ｏ／Ｅコンバータ、ＰＰＰｏＥターミネータのようなゲートウェイを配置している。ゲートウェイの従来の機能は、ゲートウェイによる仲介なしにはネットワークへアクセスできないデバイスのためのプロトコル変換を管理することである。
【０００３】
これらのゲートウェイは今日ではＪａｖａ（登録商標）についての動的モジュール・システムであるＯＳＧｉフレームワークのようなソフトウェア実行環境を含むようになってきている。ＯＳＧｉフレームワークはＪａｖａ仮想マシンを再起動することなく動的にソフトウェア・モジュールをその上に追加／削除することを可能にする。このようなソフトウェア・モジュールはＯＳＧｉの用語ではバンドルと呼ばれる。リモート管理プロトコルと組み合わせることによって、ＯＳＧｉフレームワークはリモートから管理され、動的且つオンデマンドに新たなソフトウェア・モジュールを配置することができる。
【０００４】
このようなソフトウェア実行環境を利用することによって、パーソナル・ネットワーク内のデバイスを発見してこれらのデバイスのための制御ＡＰＩを公開するゲートウェイ上のソフトウェアをネットワーク事業者が実行することが可能となり、その結果としてネットワーク事業者はユーザのためにデバイスにアクセスして制御することができる。これは、管理されたゲートウェイを利用することによって、パーソナル・ネットワーク内のデバイスを監視して制御することによって達成される各種のケアテイキング・サービス、例えばＷｉｆｉアクセスポイント自動構成サービス、ホーム・オートメイション及び家庭エネルギー管理をネットワーク事業者が提供できることを意味する。事業者がこのようなサービスを提供しようとする場合に、幅広いデバイスのためのプログラムを制御して監視する必要がある。なぜなら、パーソナル・ネットワークは様々なプロトコル・セットを用いるかもしれない幅広いデバイスを含み得るからである。一部のデバイスはリモート制御のために用いられ得るＵＰｎＰのような標準プロトコルをサポートする。しかしながら、制御及び構成のための独自仕様のプロトコルを用いる必要のある大量のデバイスが存在する。例えば、ＵＰｎＰをサポートしないがＷｅｂＧＵＩだけをサポートするＷｉｆｉアクセスポイントを遠隔から構成するために、ゲートウェイは、特定のＨＴＴＰ ＵＲＬを伴うことに基づくコマンド・セットを実装する必要がある。
【０００５】
一つのネットワーク事業者にとって、パーソナル・ネットワーク内のすべてのデバイスに対してこのようなプロトコル固有の通信ソフトウェア又はデバイス固有のプログラムを実装することは現実的ではない。この種のコンピュータ・プログラムはデバイス固有ソフトウェア（ＤＳＳ）と呼ばれる。一つの解決策はサードパーティにＤＳＳの開発を依頼することであろうが、これは費用がかさむ。複数のネットワーク事業者が連合（フェデレーション）を形成し、一緒にＤＳＳのための使用を策定し、ＤＳＳの作成をサードパーティに命じた場合に、各事業者のコストは分担することで軽減されるだろう。連合マーケットプレイスに関するこのようなアイデアに関して、特許文献１は宣伝のための連合マーケットプレイスを導入する。しかしながら、このような連合を作ることは以下のような問題を生じる。複数のネットワーク事業者間で合意と仕様とを策定することは多大なコストと努力とを必要とする。また、各ネットワーク事業者は他のネットワーク事業者へ要件を公開する必要があり、すなわち連合内のネットワーク事業者は他のネットワーク事業者がユーザに何を提供しようとしているかを推測することができる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許出願公開２００８／１０３７９５号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従って、各通信事業者がコンピュータ・プログラムの要件を秘密にしつつ、ネットワーク事業者により要求されるコンピュータ・プログラムの必要性及び要件を開発者が判定できる技術が望まれる。
【課題を解決するための手段】
【０００８】
本発明の一つの側面によれば、複数のネットワーク事業者と１以上の開発者とを仲介する装置が提供される。この装置は、各ネットワーク事業者により要求されるコンピュータ・プログラムに関する要件を取得する取得部と、前記取得された要件のうち相互に関連する要件を一つの要件に統合する統合部と、前記統合された要件を実装するコンピュータ・プログラムの開発の必要性に関する情報を生成する生成部と、前記１以上の開発者に前記統合された要件と前記必要性に関する情報とを提示する提示部とを備える。
【０００９】
本発明の更なる特徴は添付の図面を参照する以下の例示的な実施形態の説明から明らかになるだろう。
【図面の簡単な説明】
【００１０】
【図１】ＦＢＳ１００を含む例示的な環境を説明する。
【図２】ＦＢＳ１００の例示的なブロック図を説明する。
【図３】ＦＢＳ１００の例示的な動作を説明する。
【図４】例示的なテンプレートＡＰＩリスト４００を説明する。
【図５】例示的なサービス・ディスクリプション５００を説明する。
【図６】例示的なサービス・ディスクリプション・リスト６００を説明する。
【図７】例示的な要求ＤＳＳリスト７００を説明する。
【図８】例示的な適応プログラム８００を説明する。
【発明を実施するための形態】
【００１１】
本発明の実施形態が添付の図面を参照しつつ以下に説明される。以下に説明される各実施形態は汎用のものからより具体的なものまで多様な概念の理解に役立つだろう。本発明の技術的範囲は特許請求の範囲によって規定され、以下に説明される各実施形態には限定されないことに留意されたい。さらに、実施形態で説明される機能のすべての組み合わせが本発明に常に必要不可欠であるとは限らない。
【００１２】
図１は本発明の実施形態に係る連合仲介サーバ（ＦＢＳ）１００を含む例示の環境を説明する。ＦＢＳ１００は事業者ネットワーク１０１ａ−１０１ｎと開発者１０２ａ−１０２ｎとに接続される。事業者ネットワーク１０１ａはネットワーク事業者Ａによって運営され、事業者ネットワーク１０１ｂはネットワーク事業者Ｂによって運営され、以下同様である。つまり、事業者ネットワーク１０１ａ−１０１ｎは相異なるネットワーク事業者によって運営される。本実施形態では複数の開発者１０２ａ−１０２ｎが存在するものの、本発明は一人だけの開発者が存在する場合にも適用される。事業者ネットワーク１０１ａ−１０１ｎは集合的に事業者ネットワーク（群）１０１と表され、開発者１０２ａ−１０２ｎは集合的に開発者（群）１０２と表される。本実施形態は事業者ネットワーク１０１ａと開発者１０２ａとの観点から説明されるが、この説明は他の事業者ネットワーク１０１ｂ−１０１ｎと開発者１０２ｂ−１０２ｎとにも適用される。
【００１３】
事業者ネットワーク１０１ａはパーソナル・ネットワーク１０３に接続される。パーソナル・ネットワーク１０３は、パーソナル・ネットワーク１０３の所有者のまわりのデバイスが論理ネットワークを構成するように互いに相互接続されているネットワークである。デバイスはサードパーティのサービス・プロバイダと他のユーザのパーソナル・ネットワークに広域ネットワークを介して公開されている。パーソナル・ネットワーク１０３は本発明が適用されるローカル・ネットワークの一例である。ローカル・ネットワークの他の例は、ローカルエリアネットワーク（ＬＡＮ）、パーソナルエリアネットワーク（ＰＡＮ）、カー・ネットワークなどである。パーソナル・ネットワーク１０３内のデバイスは、パーソナル・ネットワーク要素（ＰＮＥ）１０６と呼ばれる。パーソナル・ネットワーク１０３はまたゲートウェイ（Ｇ／Ｗ）１０５を備え、ゲートウェイ１０５を通じてＰＮＥ１０６と事業者ネットワーク１０１ａとが互いに通信する。ゲートウェイ１０５はＰＮＥ１０６を制御するための制御ＡＰＩを公開する。
【００１４】
事業者ネットワーク１０１ａはパーソナル・ネットワーク・アプリケーション・サーバ（ＰＮＡＳ）１０４を備える。ＰＮＡＳはＰＮＥ１０６のコンテンツ情報を引き出して広める集約ポイントとして用いられる装置であり、このコンテンツ情報はデバイス・プレゼンスと能力情報とを含む。
【００１５】
ネットワーク事業者ＡはＰＮＥ１０６を監視して制御することによって様々なサービスをパーソナル・ネットワーク１０３のユーザへ提供する。ネットワーク事業者Ａによって提供されるサービスの例は以下である。
‐パーソナル・ネットワークのための自動構成：ＩＰルータやＷｉｆｉアクセスポイントのようなネットワーク機器を通常の人々が構成することは難しい作業である。トラブルシューティングも人々にとって難しいタスクである。従って、リモートから構成を監視して管理することによってネットワーク事業者Ａがこのような作業をサポートする。
‐自動ライト制御：例えばユーザがリビングルームにいて映画が始まる場合に明かりを暗くするというように、ＰＮＡＳ１０４はＰＮＥ１０６を介してユーザの位置と活動とを監視してユーザの周りのライトを制御する。
【００１６】
ネットワーク事業者Ａは各サービスに対してサービス・ディスクリプションを有する。サービス・ディスクリプションは対応するサービスを実行するための動作を記載している。サービス・ディスクリプションの例は後述される。ネットワーク事業者Ａは、ＰＮＥ１０６に対する動作を実行するために必要となるコンピュータ・プログラム（ＤＳＳ）の作成を依頼するために、ＦＢＳ１００へサービス・ディスクリプションを提供する。本発明によれば、サービス・ディスクリプション内の要件はＡＰＩの形式で記載される。しかしながら、要件を参照して開発者１０２がコンピュータ・プログラムを開発できさえすれば、本発明はどのような形式で記載された要件にも適用できる。
【００１７】
ＦＢＳ１００はネットワーク事業者と開発者１０２とを仲介する。ＦＢＳ１００はネットワーク事業者からサービス・ディスクリプションを取得する。各デバイスは固有の機能集合のみを有するため、同一カテゴリ内のデバイスはデバイスに対する同一又は類似のＡＰＩをネットワーク事業者が要求し、従って、ネットワーク事業者からの要求ＡＰＩのリストは重複しがちであると想定することは合理的である。相異なるネットワーク事業者が、入出力値の単位、パス名のような各ＡＰＩに対するわずかに異なる要件を有することは容易に生じる。後述されるように、ＦＢＳ１００はテンプレートＡＰＩをネットワーク事業者へ提供することによる問題を解決する。
【００１８】
開発者１０２ａはＦＢＳ１００により提示されたコンピュータ・プログラムを開発する。開発者１０２ａはサードパーティの開発者であってもよいし、オープンソースの開発者であってもよいし、フリー・プログラマであってもよい。
【００１９】
図２は本実施形態に係るＦＢＳ１００の例示的なブロック図を説明する。ＦＢＳ１００は、ＣＰＵ２０１、メモリ２０２、事業者Ｉ／Ｆ２０３、記憶装置２０４、統合部２０５、生成部２０６、開発者Ｉ／Ｆ２０７、検証部２０８、取得部２０９、提示部２１０、及び収集部２１１を備える。ＣＰＵ２０１はＦＢＳ１００の全体的な動作を制御する。図２において、ＣＰＵ２０１から各部への線は省略されている。メモリ２０２はＦＢＳ１００の動作のために用いられるコンピュータ・プログラムとデータとを記憶する。事業者Ｉ／Ｆ２０３はネットワーク事業者とＦＢＳ１００との間のインタフェースである。開発者Ｉ／Ｆ２０７は開発者とＦＢＳ１００との間のインタフェースである。記憶装置２０４は統計データ、テンプレートＡＰＩリスト４００、サービス・ディスクリプション・リスト６００、要求ＤＳＳリスト７００、及びＤＳＳレポジトリを備え、これらの詳細は後述される。記憶装置は例えばＨＤＤで実装される。他のユニットはＦＢＳ１００の動作を通じて後で説明される。
【００２０】
図３は本発明の実施形態に係るＦＢＳ１００の例示的な動作を説明する。ＣＰＵ２０１はこれらのステップを実行するために、メモリ２０２に記憶されたコンピュータ・プログラムを実行する。
【００２１】
ステップＳ３０１で、収集部２１１は事業者ネットワーク１０１内のＰＮＡＳ１０４からＰＮＥ１０６に関する統計を収集する。収集部２１１は記憶装置２０４内の統計データベースに収集された統計を登録する。統計は各デバイス・タイプについて、各事業者ネットワークに接続されたパーソナル・ネットワーク１０３に含まれるデバイス数を含んでもよい。
【００２２】
ステップＳ３０２で、取得部２０９はネットワーク事業者Ａからサービス・ディスクリプションを取得する。上述のように、サービス・ディスクリプションはＤＳＳに対する要件をＡＰＩの形式で含む。ネットワーク事業者ＡはステップＳ３０２に先立って、ＦＢＳ１００の所有者と合意された形式でサービス・ディスクリプションを準備する。提示部は、ネットワーク事業者Ａによるサービス・ディスクリプションの生成を支援するために、ネットワーク事業者ＡにテンプレートＡＰＩを提示してもよい。図４は例示的なテンプレートＡＰＩリスト４００を記載する。リスト４００の各エントリはデバイスに対する所定の動作を実行するためのテンプレートＡＰＩを規定する。列「デバイス・カテゴリ」４０１はデバイスのカテゴリを記載する。ＷｉＦＩアクセスポイントのような同一のカテゴリに含まれるデバイスはＳＳＩＤの取得のような同一又は類似の動作を有する傾向にある。これにより、デバイスの固有のデバイス・タイプが異なっていたとしても、同一のカテゴリ内のデバイスに対する動作を同一の方法で実行できるという利点を生む。列「動作カテゴリ」４０２は、デバイス内のパラメータの設定又は取得に用いられる「パラメータ処理」、デバイスへのコマンドの実行に用いられる「コマンド実行」、デバイスの特定のイベントの検出に用いられる「イベント検出」のような、所定の動作のカテゴリを記載する。列「ＡＰＩ名」４０３は所定の動作に対する名称を記載する。列「テンプレートＡＰＩ」４０４は所定の動作を実現するために要求されるテンプレートＡＰＩの詳細を記載する。例えば、リスト４００の１番目のエントリは、カテゴリがＷｉｆｉアクセスポイントであるデバイスのＳＳＩＤを取得するためのテンプレートＡＰＩを規定する。テンプレートＡＰＩは変更可能な属性を含んでもよい。例えば、リスト４００内の１番目のエントリでは、「パス」が変更可能である。この変更可能な属性は、相異なるネットワーク事業者の間の相異なる要件を調整するために有用である。その結果として、テンプレートＡＰＩリスト４００は相異なるネットワーク事業者からの幅広いユースケースをカバーできる。ＡＰＩに対するＤＳＳが開発された後にＦＢＳ１００が属性を変更可能な場合にＦＢＳ１００は属性を変更可能として設定する。本実施形態によれば、開発されたＤＳＳ内の属性をネットワーク事業者Ａからの要件に従って調整する補足的なコンピュータ・プログラムをＦＢＳ１００が作成可能な場合に、ＦＢＳ１００は属性を変更可能に設定する。これにより、一つのＤＳＳがわずかに異なる要件をカバーでき、それによってＤＳＳの価値が向上するという利点を生む。
【００２３】
ネットワーク事業者ＡはテンプレートＡＰＩのリスト４００を用いてサービス・ディスクリプションを記述してもよい。図５は例示的なサービス・ディスクリプション５００を説明する。サービス・ディスクリプション５００の各エントリは所定のサービスを実行するための要件を規定する。列「サービス名」５０１はネットワーク事業者Ａが実行するサービスの名称を記載する。列５０２、５０３は図４の列４０１、４０３と同じである。列「優先度」５０４は動作のための優先度を記載する。例えば、要求ＡＰＩがサービスに必須である場合に優先度は「高」に設定されてもよく、一方で、要求ＡＰＩがサービスにオプションである場合に優先度は「低」に設定されてもよい。列「要求ＡＰＩ」は動作を実行するために要求されたＡＰＩの詳細を記載する。ネットワーク事業者Ａはネットワーク事業者Ａの要件を満たすテンプレートＡＰＩを選択し、要求ＡＰＩにテンプレートＡＰＩを調整するように変更可能な属性を変更する。例えば、ネットワーク事業者Ａは図５の「パス」属性を設定する。
【００２４】
ステップＳ３０２で、取得部２０９は取得されたサービス・ディスクリプションを記憶装置２０４に記憶する。ネットワーク事業者から取得されたサービス・ディスクリプションはサービス・ディスクリプション・リストとして保持される。図６は例示的なサービス・ディスクリプション・リスト６００を説明する。リスト６００の各エントリは各ネットワーク事業者から取得された要求ＡＰＩを記載する。列「事業者名」６０１は要求ＡＰＩが取得されたネットワーク事業者の名称を記載する。列６０２−６０４、６０６は図５の対応する列と同じである。列「ＡＰＩ ＩＤ」はリスト６００のエントリを識別するＩＤである。「ＡＰＩ ＩＤ」６０５は要求ＡＰＩと統合ＡＰＩとの間の関係性を追跡するために用いられる。ステップＳ３０３で、取得部２０９はサービス・ディスクリプション・リスト６００が更新されたことを統合部２０５に通知する。
【００２５】
ステップＳ３０４で、統合部２０５は相互に関連する要求ＡＰＩを一つのＡＰＩに統合する。本実施形態によれば、ＡＰＩを統合するために、統合部２０５は要求ＡＰＩとテンプレートＡＰＩとを比較する。サービス・ディスクリプション・リスト６００内の二つ以上の要求ＡＰＩが同一のテンプレートＡＰＩに対応する場合に、統合部２０５はこれらの要求ＡＰＩが相互に関連すると判定し、これらの要求ＡＰＩを一つの統合ＡＰＩに統合する。例えば、サービス・ディスクリプション・リスト６００内の１番目のエントリと５番目のエントリとはテンプレートＡＩＰリスト４００内の１番目のエントリに対応し、従って統合部２０５はこれらの要求ＡＰＩを統合する。
【００２６】
統合部２０５は統合ＡＰＩを要求ＤＳＳリストに登録する。図７は例示的な要求ＤＳＳリスト７００を説明する。要求ＤＳＳリスト７００の各エントリは開発されるべき要求ＤＳＳを記載する。列７０１、７０２は図６の列６０２、６０３と同じである。列「統合ＡＰＩ」７０３は統合ＡＰＩの詳細を記載する。列７０４、７０５は後述する。サービス・ディスクリプション・リスト６００内の１番目のエントリと５番目のエントリとは要求ＤＳＳリスト７００の１番目のエントリに統合される。統合部２０５は１番目のエントリ内の「パス」属性をデフォルト値に置き換えることに留意されたい。このように、統合部２０５は統合ＡＰＩ内の変更可能な属性をデフォルト値に置き換え、次いで統合ＡＰＩを要求ＤＳＳリスト７００に登録する。ステップＳ３０５で、統合部２０５は要求ＤＳＳリスト７００が更新されたことを生成部２０６に通知する。
【００２７】
ステップＳ３０６で、生成部２０６は統合ＡＰＩを実装するＤＳＳの開発の必要性に関する情報を生成する。本実施形態によれば、生成部２０６は統計データベースに記憶されている各デバイス・タイプについて必要性を判定する。生成部２０６は図７に示されるように、各統合ＡＰＩについてすべてのデバイス・タイプを登録する。この例では、統計データベースはデバイスＩＤが「ＡＡ００１０」、「ＢＢ００２０」である「Ｗｉｆｉアクセスポイント」カテゴリ内の二つのデバイス・タイプを含む。列「デバイスＩＤ」７０４はＤＳＳが開発されることが要求されるデバイスのデバイスＩＤを記載する。次いで、生成部２０６は各デバイスＩＤについて必要性を判定する。生成部２０６は例えば統計データベースに記憶された統計と要求ＡＰＩの重要度との少なくとも一方に基づいて必要性を判定する。生成部２０６は統合ＡＰＩが高い優先度を有する場合に必要性に対してより大きな値を設定する。なぜなら、ネットワーク事業者はＤＳＳのためにより高い金額を払うだろうからである。これに加えて又はこれに代えて、生成部２０６は所定のデバイスＩＤについてのデバイス数が多い場合に必要性に対してより大きな値を設定する。例えば、ＩＤが「ＡＡ００１０」であるデバイスの数が、ＩＤが「ＢＢ００２０」であるデバイスの数の２倍である場合に、生成部２０６は「ＡＡ００１０」のための値が「ＢＢ００２０」のための値の２倍になるように必要性を設定する。必要性の値はＤＳＳの開発に対する推定支払額に対応してもよい。生成部２０６はＤＳＳにすでに記憶されているＤＳＳの必要性をゼロに設定してもよい。ステップＳ３０７で、生成部２０６は要求ＤＳＳリスト７００が更新されたことを提示部２１０に通知する。
【００２８】
ステップＳ３０８で、提示部２１０は開発者１０２へ要求ＤＳＳリスト７００を開発者Ｉ／Ｆ２０７を介して提示する。要求ＤＳＳリスト７００が個々のネットワーク事業者に関する情報を一切示していないことに留意されたい。すなわち、各ネットワーク事業者は、ネットワーク事業者がサービスを提供する自身のサービス・ディスクリプションとデバイス数とを他のネットワーク事業者及び開発者１０２から秘密にすることができる。
【００２９】
ステップＳ３０９で、開発者１０２ａは要求ＤＳＳリスト７００を参照してＤＳＳを開発する。開発者１０２ａはより高い必要性を有するＤＳＳを開発するだろう。ステップＳ３１０で、取得部２０９は開発されたＤＳＳを開発者１０２ａから開発者Ｉ／Ｆ２０７を介して取得する。ステップＳ３１１で、取得部２０９は取得されたＤＳＳを検証部２０８へ転送する。
【００３０】
ステップＳ３１２で、検証部２０８は取得されたＤＳＳを検証する。例えば、検証部２０８はＤＳＳが悪意のあるコードを含むかをＪａｖａのサンドボックス技術を用いて調べる。ＤＳＳを調べた後に、検証部２０８はＤＳＳレポジトリにＤＳＳを登録する。検証部２０８は個別のデバイスに対してＤＳＳを調べなくてもかまわない。なぜなら、ＤＳＳを広範に配布する前にＤＳＳをどのようにテストするかはネットワーク事業者しだいだからである。ステップＳ３１３で、検証部２０８はＤＳＳレポジトリが更新されたことを提示部２１０へ通知する。
【００３１】
ステップＳ３１４で、提示部２１０は更新されたＤＳＳレポジトリを事業者Ｉ／Ｆ２０３を介してネットワーク事業者へ提示する。ステップＳ３１５で、ネットワーク事業者ＡはＤＳＳレポジトリ内のＤＳＳを、例えばゲートウェイ１０５へＤＳＳを配信するために又は自身のアプリケーションストアに置くために要求する。ＦＢＳ１００はＤＳＳについてネットワーク事業者に課金してもよい。
【００３２】
ステップＳ３１６で、事業者Ｉ／Ｆ２０３はどのＤＳＳがネットワーク事業者Ａから要求されたかを統合部２０５へ通知する。
【００３３】
ステップＳ３１７で、統合部２０５は適合プログラムを生成する。上述のように、サービス・ディスクリプション５００におけるＡＰＩと要求ＤＳＳリスト６００におけるＡＰＩとは異なる。すなわち、開発されたＤＳＳは適合プログラムなしには動作しない。例えば、ネットワーク事業者Ａが名称が「Ｇｅｔ ＳＳＩＤ」であるＡＰＩについてのＳＤＤを要求した場合に、統合部２０５はサービス・ディスクリプション・リスト６００を参照して、ネットワーク事業者Ａから取得された要求ＡＰＩを見つける。次いで、統合部２０５は図８に記載されたような適合プログラム８００を作成する。統合部２０５は最終配信プログラムとして提供するようにこれらのプログラムを結合してもよい。
【００３４】
ステップＳ３１８で、統合部２０５は適合プログラムが作成されたことを提示部２１０へ通知する。
【００３５】
ステップＳ３１９で、提示部２１０は要求されたＤＳＳとこれに対応する適合プログラムとを事業者Ｉ／Ｆ２０３を介してネットワーク事業者Ａへ提供する。
【００３６】
本実施形態によれば、各ネットワーク事業者がコンピュータ・プログラムへの要件を秘密にしつつ、開発者がネットワーク事業者により要求されたコンピュータ・プログラムへの必要性を判定できる。各ネットワーク事業者はコンピュータ・プログラムを取得するためのコストを低減できる。各ネットワーク事業者は互いに要件を共有する必要がなく、また特定のＤＳＳに対する仕様を共同で開発する必要もない。
【００３７】
本発明は例示的な実施形態を参照して説明されてきたが、本発明は開示した例示の実施形態に限定されないと理解されるべきである。以下の特許請求の範囲はこのような修正及び均等な構造及び機能をすべて包含するような最も広い解釈に一致する。
【特許請求の範囲】
【請求項１】
複数のネットワーク事業者（１０１）と１以上の開発者（１０２）とを仲介する装置（１００）であって、
各ネットワーク事業者（１０１）により要求されるコンピュータ・プログラムに関する要件を取得する取得部（２０９）と、
前記取得された要件のうち相互に関連する要件を一つの要件に統合する統合部（２０５）と、
前記統合された要件を実装するコンピュータ・プログラムの開発の必要性に関する情報を生成する生産部（２０６）と、
前記１以上の開発者（１０２）に前記統合された要件と前記必要性に関する情報とを提示する提示部（２１０）と
を備えることを特徴とする装置（１００）。
【請求項２】
前記必要性に関する情報は、前記コンピュータ・プログラムの開発についての推定支払額を含むことを特徴とする請求項１に記載の装置（１００）。
【請求項３】
各ネットワーク事業者（１０１）はローカル・ネットワーク（１０３）に接続されており、
前記ネットワーク事業者（１０１）により要求された前記コンピュータ・プログラムは前記ローカル・ネットワーク（１０３）内のデバイス（１０６）のために用いられるコンピュータ・プログラムである
ことを特徴とする請求項１又は２に記載の装置（１００）。
【請求項４】
前記ローカル・ネットワーク（１０３）内のデバイス（１０６）の統計を収集する収集部（２１１）をさらに備え、
前記必要性に関する情報が前記統計に基づいて生成される
ことを特徴とする請求項３に記載の装置（１００）。
【請求項５】
前記統計は開発されるべき前記コンピュータ・プログラムが用いられる対象のデバイス（１０６）の数を含むことを特徴とする請求項４に記載の装置（１００）。
【請求項６】
前記相互に関連する要件は同一のカテゴリ内のデバイス（１０６）についての同一の動作に対する要件であることを特徴とする請求項３乃至５のいずれか１項に記載の装置（１００）。
【請求項７】
前記デバイス（１０６）についての前記動作はパラメータ処理とコマンド実行とイベント検出とのうちの少なくとも一つを含むことを特徴とする請求項６に記載の装置（１００）。
【請求項８】
前記提示部（２１０）は、前記複数のネットワーク事業者（１０１）へ、要件を記述するために前記ネットワーク事業者（１０１）によって用いられる要件のパターンをさらに提示し、
前記統合部（２０５）は、前記同一のパターンを用いて記載された要件を一つの要件に統合する
ことを特徴とする請求項１乃至７のいずれか１項に記載の装置（１００）。
【請求項９】
前記取得部（２０９）は、前記１以上の開発者により開発されたコンピュータ・プログラムをさらに取得し、
前記提示部（２１０）は、前記複数のネットワーク事業者（１０１）へ前記開発されたコンピュータ・プログラムをさらに提示する
ことを特徴とする請求項１乃至８のいずれか１項に記載の装置（１００）。
【請求項１０】
前記統合部（２０５）は、前記開発されたコンピュータ・プログラムを前記ネットワーク事業者（１０１）により要求されたコンピュータ・プログラムに適合するための補助的なコンピュータ・プログラムをさらに生成することを特徴とする請求項９に記載の装置（１００）。
【請求項１】
複数のネットワーク事業者（１０１）と１以上の開発者（１０２）とを仲介する装置（１００）であって、
各ネットワーク事業者（１０１）により要求されるコンピュータ・プログラムに関する要件を取得する取得部（２０９）と、
前記取得された要件のうち相互に関連する要件を一つの要件に統合する統合部（２０５）と、
前記統合された要件を実装するコンピュータ・プログラムの開発の必要性に関する情報を生成する生産部（２０６）と、
前記１以上の開発者（１０２）に前記統合された要件と前記必要性に関する情報とを提示する提示部（２１０）と
を備えることを特徴とする装置（１００）。
【請求項２】
前記必要性に関する情報は、前記コンピュータ・プログラムの開発についての推定支払額を含むことを特徴とする請求項１に記載の装置（１００）。
【請求項３】
各ネットワーク事業者（１０１）はローカル・ネットワーク（１０３）に接続されており、
前記ネットワーク事業者（１０１）により要求された前記コンピュータ・プログラムは前記ローカル・ネットワーク（１０３）内のデバイス（１０６）のために用いられるコンピュータ・プログラムである
ことを特徴とする請求項１又は２に記載の装置（１００）。
【請求項４】
前記ローカル・ネットワーク（１０３）内のデバイス（１０６）の統計を収集する収集部（２１１）をさらに備え、
前記必要性に関する情報が前記統計に基づいて生成される
ことを特徴とする請求項３に記載の装置（１００）。
【請求項５】
前記統計は開発されるべき前記コンピュータ・プログラムが用いられる対象のデバイス（１０６）の数を含むことを特徴とする請求項４に記載の装置（１００）。
【請求項６】
前記相互に関連する要件は同一のカテゴリ内のデバイス（１０６）についての同一の動作に対する要件であることを特徴とする請求項３乃至５のいずれか１項に記載の装置（１００）。
【請求項７】
前記デバイス（１０６）についての前記動作はパラメータ処理とコマンド実行とイベント検出とのうちの少なくとも一つを含むことを特徴とする請求項６に記載の装置（１００）。
【請求項８】
前記提示部（２１０）は、前記複数のネットワーク事業者（１０１）へ、要件を記述するために前記ネットワーク事業者（１０１）によって用いられる要件のパターンをさらに提示し、
前記統合部（２０５）は、前記同一のパターンを用いて記載された要件を一つの要件に統合する
ことを特徴とする請求項１乃至７のいずれか１項に記載の装置（１００）。
【請求項９】
前記取得部（２０９）は、前記１以上の開発者により開発されたコンピュータ・プログラムをさらに取得し、
前記提示部（２１０）は、前記複数のネットワーク事業者（１０１）へ前記開発されたコンピュータ・プログラムをさらに提示する
ことを特徴とする請求項１乃至８のいずれか１項に記載の装置（１００）。
【請求項１０】
前記統合部（２０５）は、前記開発されたコンピュータ・プログラムを前記ネットワーク事業者（１０１）により要求されたコンピュータ・プログラムに適合するための補助的なコンピュータ・プログラムをさらに生成することを特徴とする請求項９に記載の装置（１００）。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２０１３−５２０７１３（Ｐ２０１３−５２０７１３Ａ）
【公表日】平成２５年６月６日（２０１３．６．６）
【国際特許分類】
【出願番号】特願２０１２−５２８１７６（Ｐ２０１２−５２８１７６）
【出願日】平成２２年２月１９日（２０１０．２．１９）
【国際出願番号】ＰＣＴ／ＪＰ２０１０／０５３０１３
【国際公開番号】ＷＯ２０１１／１０２０００
【国際公開日】平成２３年８月２５日（２０１１．８．２５）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２５年６月６日（２０１３．６．６）
【国際特許分類】
【出願日】平成２２年２月１９日（２０１０．２．１９）
【国際出願番号】ＰＣＴ／ＪＰ２０１０／０５３０１３
【国際公開番号】ＷＯ２０１１／１０２０００
【国際公開日】平成２３年８月２５日（２０１１．８．２５）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]