特開 2015-232890 サービス要求をハンドリングするための方法、デバイス、システムおよびネットワーク・アーキテクチャ

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】特開2015-232890(P2015-232890A)

(43)【公開日】2015年12月24日

(54)【発明の名称】サービス要求をハンドリングするための方法、デバイス、システムおよびネットワーク・アーキテクチャ

(51)【国際特許分類】

   G06F 13/00 20060101AFI20151201BHJP

   H04L 12/66 20060101ALI20151201BHJP

   H04L 12/46 20060101ALI20151201BHJP

【ＦＩ】

   G06F13/00 520C

   H04L12/66 A

   H04L12/46 E

【審査請求】有

【請求項の数】13

【出願形態】ＯＬ

【外国語出願】

【全頁数】17

(21)【出願番号】特願2015-143027(P2015-143027)

(22)【出願日】2015年7月17日

(62)【分割の表示】特願2013-545414(P2013-545414)の分割

【原出願日】2011年12月22日

(31)【優先権主張番号】10196719.8

(32)【優先日】2010年12月23日

(33)【優先権主張国】EP

(71)【出願人】

【識別番号】512287702

【氏名又は名称】コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ

(71)【出願人】

【識別番号】508351406

【氏名又は名称】ネダーランゼ・オルガニサティ・フォーア・トゥーゲパスト−ナトゥールヴェテンシャッペリーク・オンデルゾエク・ティーエヌオー

(74)【代理人】

【識別番号】100140109

【弁理士】

【氏名又は名称】小野 新次郎

(74)【代理人】

【識別番号】100075270

【弁理士】

【氏名又は名称】小林 泰

(74)【代理人】

【識別番号】100101373

【弁理士】

【氏名又は名称】竹内 茂雄

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100173565

【弁理士】

【氏名又は名称】末松 亮太

(72)【発明者】

【氏名】シュトッキング，ハンス・マールテン

(72)【発明者】

【氏名】クラメール，エールコ

(72)【発明者】

【氏名】ハルトフ，デン・フランク

【テーマコード（参考）】

5B084

5K030

5K033

【Ｆターム（参考）】

5B084AA02

5B084AA12

5B084AA29

5B084AA33

5B084AB16

5B084AB18

5B084AB21

5B084AB30

5B084BB01

5B084CD04

5B084DB02

5B084DC06

5K030HC01

5K030HC14

5K030HD03

5K030JA11

5K030JT02

5K030LB05

5K033BA01

5K033CB08

5K033DA05

5K033DB18

(57)【要約】      （修正有）

【課題】サービス要求をローカル・エリア・ネットワーク内でハンドリングする。
【解決手段】最初に、サービス要求をユーザ・デバイスから受け取る。このサービス要求は、サービスを実施するのに必要とされる１以上の要件に関する情報を含む。次いで、サービス要求内の情報に基づいてコンピュータ実行可能情報を取得するために、公衆ネットワーク内の位置特定サービス手段によってダウンロード位置を位置特定する。次いで、ダウンロード位置からサービスを実施するためにコンピュータ実行可能情報を抽出し、ローカル・エリア・ネットワーク内のネットワーク・デバイスについてコンピュータ実行可能情報のインストールをアレンジする。そして最後に、ローカル・エリア・ネットワーク内の前記サービスの可用性に関するメッセージをユーザ・デバイスに送る。
【選択図】図１

【特許請求の範囲】

【請求項1】

サービス要求をローカル・エリア・ネットワーク内でハンドリングする方法であって、
サービス要求をユーザ・デバイスから受け取るステップであって、前記サービス要求が、サービスを実施するのに必要とされる１以上の要件に関する情報を含む、ステップと、
前記サービス要求内の前記情報に基づいてコンピュータ実行可能情報を取得するために、公衆ネットワーク内の位置特定サービス手段によってダウンロード位置を位置特定するステップと、
前記ダウンロード位置から前記サービスを実施するためにコンピュータ実行可能情報を抽出し、前記ローカル・エリア・ネットワーク内のネットワーク・デバイスへの前記コンピュータ実行可能情報のインストールをアレンジするステップと、
前記ローカル・エリア・ネットワーク内の前記サービスの可用性に関するメッセージを前記ユーザ・デバイスに送るステップと、
を含む、方法。

【請求項2】

請求項１記載の方法であって、更に、前記サービス要求を受け取るステップの後に、前記サービスが前記ローカル・エリア・ネットワーク内で利用可能かを検査するステップであって、前記位置特定、ダウンロード、およびインストールは、前記サービスが利用不可能なときに実行され、これらのアクションは前記サービスが利用可能であるときに省略される、方法。

【請求項3】

請求項２記載の方法において、前記検査するステップが、前記サービス要求を前記ローカル・エリア・ネットワーク内のデバイスに転送して、所定の時間期間の間、前記デバイスのうちの１つからの、前記サービスが利用可能であると確認する応答メッセージを待つステップであって、前記所定の時間期間内に確認応答メッセージを受け取らなかった場合に、前記サービスが利用不可能であるとみなされる、ステップを含む、方法。

【請求項4】

請求項２記載の方法において、前記ローカル・エリア・ネットワークが前記ネットワーク内で利用可能なサービスのリストを含んだサービス・レジストリを含み、前記検査するステップが前記サービス・レジストリを参照するステップを含む、方法。

【請求項5】

請求項１から４のいずれか一項記載の方法において、ダウンロード位置を位置特定するステップが、
前記要求されたサービスを前記位置特定サービスからダウンロードするのに適切な複数の位置を受け取るステップと、
前記ダウンロード位置を選択するステップと、
を含む、方法。

【請求項6】

前記ダウンロード位置の選択が所定の基準に基づく、請求項５記載の方法。

【請求項7】

請求項６記載の方法において、前記ダウンロード位置を選択するステップが、
前記要求されたサービスをダウンロードするのに適切な前記複数の位置を前記ユーザ・デバイスに転送するステップと、
これに応答して、選択されたダウンロード位置を前記ユーザ・デバイスから受け取るステップと、
を含む方法。

【請求項8】

請求項１から７のいずれか一項記載の方法であって、更に、前記サービス要求を受け取るステップの後に、前記ゲートウェイ・システムの性能に関する付加情報を前記サービス要求に付加するステップを含み、前記位置特定するステップが、前記付加情報に更に基づく、方法。

【請求項9】

プロセッサによって実行する際に、請求項１から８のいずれか一項記載のサービス要求をハンドリングするための方法を実行するためのコンピュータ可読媒体。

【請求項10】

サービス要求をローカル・エリア・ネットワーク内でハンドリングするためのデバイスＳＰＢであって、
ローカル・エリア・ネットワークＬＡＮおよびワイド・エリア・ネットワークＷＡＮの間の通信インターフェイスを提供するインターフェイス・デバイスＧＷと、
コンピュータ実行可能情報を前記ローカル・エリア・ネットワークＬＡＮ内にインストールするのを可能にするネットワーク・デバイスＳＷＥＸと、
に通信可能に接続するように構成され、
請求項１から８のいずれか一項に記載の方法を実行するように構成される、デバイス。

【請求項11】

サービス要求をハンドリングするためのシステムＧＷＳであって、
ローカル・エリア・ネットワークＬＡＮおよびワイド・エリア・ネットワークＷＡＮの間の通信インターフェイスを提供するインターフェイス・デバイスＧＷと、
コンピュータ実行可能情報を前記ローカル・エリア・ネットワークＬＡＮ内にインストールするのを可能にするネットワーク・デバイスＳＷＥＸと、
請求項１０記載のデバイスをハンドリングするサービス要求と、
を備える、システム。

【請求項12】

請求項１０記載のシステムであって、更に、前記ローカル・エリア・ネットワーク内で利用可能なサービスを登録するためのサービス・レジストリを備える、システム。

【請求項13】

サービス要求をハンドリングするためのネットワーク・アーキテクチャであって、
少なくとも１つのユーザ・デバイスＵＥを備えるローカル・エリア・ネットワークＬＡＮと、
サービス位置について位置特定するためのサービス・ロケータ・システムＳＬＯＣ、およびサービスを実施するためのコンピュータ実行可能情報を格納するためのサービス・レポジトリを備えるワイド・エリア・ネットワークＷＡＮと、
請求項１１または１２記載のシステムと、
を備える、ネットワーク・アーキテクチャ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ローカル・エリア・ネットワーク内でサービス要求をハンドリングする方法に関するものである。本発明はまた、プロセッサによって実施するときに、このような方法を実行するためのコンピュータ可読媒体に関するものである。本発明は更に、サービス要求をハンドリングするデバイス、およびこのようなデバイスを含むシステムに関するものである。最後に、本発明は、サービス要求をハンドリングするためのネットワーク・アーキテクチャに関し、ここではネットワークはこのようなゲートウェイ・システムを含む。

【従来技術】

【0002】

近年、ローカル・エリア・ネットワーク、例えばホーム・ネットワークまたはオフィス・ネットワークは、通常、ゲートウェイを介して公衆ネットワークに接続される様々をデバイスを含み、このゲートウェイは、ホーム・ゲートウェイまたは住宅用ゲートウェイと称される。ネットワーク・デバイスの例には、パーソナル・コンピュータ、ラップトップ、パーソナル・デジタル・アシスタント、スマートフォン、タブレット、セット・トップ・ボックス、メディア・プレーヤ、アラーム・システム、ライトニング・システム、およびホーム・オートメーション・センサが含まれるが、これに限定されるものではない。

【0003】

ホーム・ゲートウェイは、外界への接続のために用いられるが、これはまた、ローカル・ネットワークに使用するためのホスト・サービスに用いることもでき、更に、ソフトウェア・モジュールをロードおよびアンロードすることができるプラットフォームとして機能させることもできる。ホーム・ゲートウェイの使用例には、オープン・サービス・ゲートウェイ・イニシアティブ（ＯＳＧｉ）プラットフォームがあり、例えばＪａｖａ（登録商標）モジュールのようなソフトウェア・モジュールがホーム・ゲートウェイを再起動(reboot)することなくオンザフライで(on-the-fly)インストールすることができる。

【0004】

ホーム・ゲートウェイは、ローカル・エリア・ネットワークにおいて他のデバイスにサービスを提供することができる。このことは、時には、ソフトウェアをダウンロードできるという意味でサービスをデリバすることを意味することになる。多くの場合、ホーム・ゲートウェイは、外界すなわち公衆ネットワークへの接続を可能にする。ホーム・ゲートウェイにより提供される接続サービスは、ルーティング・サービスに限定されることもあるが、しばしば他のサービスも同様に含む。サービスの例として、ホーム・ゲートウェイにより提供される接続サービスの一部としてもよく、ネットワーク・アドレス変換（ＮＡＴ）サービス、ファイア・ウォール・サービス、サービス品質管理(a quality of service management )サービス、およびアクセス制御サービスを含むが、これに限定されるものではない。加えて、ホーム・ゲートウェイは、ローカル・ネットワーク内において特定の機能性を有するシステムとしてしばしばサービス提供する。例えば、ホーム・ゲートウェイは、家庭用電話システムとして、メディア・ストリームのトランスレーション／トランスコーディング・デバイスとして、ローカル・エリア・ネットワークのための記憶装置として、および／またはプリンタ制御機構ユニットとしてサービス提供することができる。

【0005】

ローカル・エリア・ネットワーク内のネットワーク・デバイスはまた、同一のローカル・エリア・ネットワーク内の他のデバイスに対してサービス提供することもできる。このようなサービスは、メディア・サーバ、メディア・プレーヤ、プリント・サービス、例えば遠隔ランプ制御やサーモスタット・サービスのようなライトニング・サービスなどを含むことができ、またソフトウェア・ダウンロード・サービスを含むこともできる。

【0006】

ホーム・ゲートウェイは、更に、サービス・レジストリを備えることができ、すなわちローカル・エリア・ネットワーク内でこのようなサービス・レジストリに通信可能に(communicatively)接続することができる。サービス・レジストリは、ローカル・エリア・ネットワーク内に展開されたデバイスについての位置情報および更なる情報を登録する。

【0007】

[0007]ユーザ・デバイスは、人がネットワーク・デバイスによって提供を受けるサービスにアクセスするのに用いるデバイスである。ユーザ・デバイスとしては、例えば、ラップトップ・コンピュータ、スマートフォン、タブレットＰＣまたは一般的な入出力デバイスとすることができる。

【0008】

ユーザ・デバイスがネットワーク・デバイスからサービスを要求とするときには、ユーザ・デバイスは、所謂サービス・ディスカバリを用いることで、このようなービスを取得できる。この手順では、規格化されたプロトコル、例えばユニバーサル・プラグ・アンド・プレイ（ＵＰｎＰ）、サービス・ロケーション・プロトコル（ＳＬＰ）、ジーニー(Jini)またはユニバーサル・ディスクリプション・ディスカバリ・アンド・インテグレーション（ＵＤＤＩ）を使用して実行することができ、ユーザは、サービス・ディスカバリ・メッセージをレジストリに送りサービスに関する情報を要求することによって、サービス・ディスカバリを開始する。これに応じて、レジストリは、ユーザに位置情報および更なる情報を提供する。この更なる情報により、レジストリから取得される情報を用いてデバイスがサービスを要求することを可能にする。

【0009】

ローカル・エリア・ネットワーク内において必要とされるサービスが展開(deploy)されておらず、および／または任意のネットワーク・デバイス上でもランされていないときには、ユーザ・デバイスはサービス・ディスカバリを通じてデバイスを見つけることができない。このような場合には、ユーザ・デバイスは、直接的にまたはホーム・ゲートウェイを介して、公衆ネットワーク、すなわちインターネットのようなワイド・エリア・ネットワーク上でサービスをサーチすることができる。見つけられた場合には、サービスは、次いでユーザ・デバイスに対し直接ネットワークを跨って遠隔提供される。

【0010】

しかしながら、外部ネットワークを跨った遠隔サービス提供と組み合わせたサービス・ディスカバリについてのこの選択肢は制限される。ローカル・エリア・ネットワークは、プライベート・インターネット・プロトコル（ＩＰ）アドレス範囲およびホーム・ゲートウェイ上のＮＡＴをしばしば用いる。これら環境下では、遠隔に、すなわちローカル・エリア・ネットワークの外側で提供されるときには、サービスは適切に機能することができない。加えて、公衆ネットワークを介した通信がしばしばＩＰベースであるのに対し、ローカル・エリア・ネットワーク内の通信は、例えばアラーム・システムまたはホーム・オートメーションのために使用される異なるネットワーク・プロトコルにしばしば基づいている。ホーム・ゲートウェイがデバイスを仲介および／または変換するものとして使用されることがあるにも拘わらず、遠隔提供されるサービスは誤って解釈される(misinterpret)かまたは誤って理解される(misunderstand)こともある。更に、多くのローカル・エリア・ネットワークは、サービス品質の点で、例えばホーム・ゲートウェイによって制御される。良好なサービス品質を確実なものにするために、帯域幅可用性、ノードの数および位置、並びに輻輳などの観点からネットワークのローカル・ビューが必要となる。ローカル・エリア・ネットワークにおけるこのようなローカル・ビューは、通常、遠隔提供されるサービスには利用できない。更に、ユーザ・デバイスは、ネットワーク・デバイスによって提供されないサービスにアクセスするために、例えばＵＰｎＰのようなプロトコルによっては提供されることのない、特定のソフトウェアおよび機能をしばしば要求する。

【0011】

サービスが展開されておらず、および／またはローカル・エリア・ネットワーク内のデバイス上でランしていないときに、そのサービスの提供のみしかできない状況を回避するために、１以上のサービスが、例えばアップロード位置を含むリストの形態で、ホーム・ゲートウェイに対してアップロードされることができよう。しかしながら、通常は、１つのインターネット・サービス・プロバイダだけがサービスをアップロードすることが可能であり、より数多くのサービス・プロバイダ（必らずしもインターネット・サービス・プロバイダとは限らない）であれば、ローカル・エリア・ネットワーク内のユーザ・デバイス上でランできるサービスを提供することができよう。加えて、新規サービスが、時間とともに出現することになる。事前に任意のおよび全ての利用可能なサービスをホーム・ゲートウェイ上に構成することは不可能である。

【発明の概要】

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

【0012】

本発明の目的は、ローカル・エリア・ネットワーク内におけるユーザ・デバイスによって要求されたときに、サービスのローカルなデリバリを、ローカル・エリア・ネットワーク内でのこのようなサービスの現在の可用性とは独立して可能とすることである。

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

【0013】

この目的のために、本発明は、サービス要求をローカル・エリア・ネットワーク内でハンドリングする方法に関し、以下のステップを含む。すなわち、サービス要求をユーザ・デバイスから受け取るステップであって、サービス要求が、サービスを実施するのに必要とされる１以上の要件に関する情報を含むもの、サービス要求内の情報に基づいてコンピュータ実行可能情報を取得するために、公衆ネットワーク内の位置特定サービス手段によってダウンロード位置を位置特定するステップ、ダウンロード位置からのサービスを実施するためにコンピュータ実行可能情報を抽出し、ローカル・エリア・ネットワーク内のネットワーク・デバイスにコンピュータ実行可能情報のインストールをアレンジするステップ、および、ローカル・エリア・ネットワーク内のサービスの可用性に関するメッセージをユーザ・デバイスに送るステップである。

【0014】

本発明の実施形態の中には、プロセッサによって実行する際、上記方法を実行するためのコンピュータ可読媒体に関するものもある。

【0015】

本発明の実施形態の中には、サービス要求をローカル・エリア・ネットワーク内でハンドリングするためのデバイスに関するものもある。当該デバイスは、ローカル・エリア・ネットワークおよびワイド・エリア・ネットワークの間の通信インターフェイスを提供するインターフェイス・デバイス、および、コンピュータ実行可能情報をローカル・エリア・ネットワーク内にインストールするのを可能にするネットワーク・デバイスに通信可能に接続するように構成され、当該デバイスは、上記の方法を実行するように構成される。

【0016】

本発明の実施形態の中には、サービス要求をハンドリングするためのシステムに関するものもある。当該システムは、以下のものを備える。すなわち、ローカル・エリア・ネットワークおよびワイド・エリア・ネットワークの間の通信インターフェイスを提供するインターフェイス・デバイス、コンピュータ実行可能情報をローカル・エリア・ネットワーク内にインストールするのを可能にするネットワーク・デバイス、および、上記サービス要求ハンドリング・デバイスである。

【0017】

最後に、本発明の実施形態の中には、サービス要求をハンドリングするためのネットワーク・アーキテクチャに関するものもあり、以下のものを備える。すなわち、少なくとも１つのユーザ・デバイスを備えるローカル・エリア・ネットワーク、サービス位置について位置特定するためのサービス・ロケータ・システムとサービスを実施するためのコンピュータ実行可能情報を格納するためのサービス・レポジトリとを備えるワイド・エリア・ネットワーク、および、上記サービス要求ハンドリング・システムである。

【0018】

本願発明の原理は、様々な方法で実行に移すことができることが明らかであろう。

【0019】

これより実施形態について添付の概略図を参照しながら、例示のみによる説明を行う。

【図面の簡単な説明】

【0020】

【図1】図１は、本発明の一実施形態によるサービス要求をハンドリングするためのネットワーク・アーキテクチャについて概略的に示している。

【図2】図２ａ、２ｂおよび２ｃは、図１のネットワーク・アーキテクチャで用いるために考えられる２つのゲートウェイ・システム・アーキテクチャについて概略的に示している。

【図3a】図３ａは、本発明の一実施形態により、図１のアーキテクチャにおいてサービス要求をハンドリングする方法の信号フローについて概略的に示している。

【図3b】図３ｂは、本発明の他の実施形態により、図１のアーキテクチャにおいてサービス要求をハンドリングする方法についての信号フローの一部について概略的に示している。

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

【0021】

本発明の様々な実施形態について、例示のみにより、図面を参照しながら以下に説明する。

【0022】

図１は、本発明の一実施形態によるサービス配給(service provisioning)のためのネットワーク・アーキテクチャを概略的に示している。このアーキテクチャは、ゲートウェイ・システムＧＷＳを通じてワイド・エリア・ネットワーク（ＷＡＮ）に結合されるローカル・エリア・ネットワーク（ＬＡＮ）を備えたネットワーク構成に関する。ＬＡＮは、任意のプライベート・ネットワークを含んでもよく、ホーム・ネットワーク、オフィス・ネットワーク、自動車ネットワーク、個人領域ネットワーク、および特定の地理的位置にあるネットワークを含むが、これに限定されるものではない。ローカル・エリア・ネットワークＬＡＮはまた、数多くの地理的位置にわたり分散される論理ネットワークでもよい。ワイド・エリア・ネットワークＷＡＮは、広域にある複数のインターフェイス・デバイスへの接続性を供給する。例えば、ワイド・エリア・ネットワークは、インターネットとして公知であるグローバル・ネットワークとしてもよく、またはこれを含んでも良い。ゲートウェイ・システムＧＷＳは、例えばモデムまたはルータのようなインターフェイス・デバイスを含んでもよい。モデムの例として、非対称デジタル加入者ライン（ＡＤＳＬ）モデム、極めて高ビット・レートのデジタル加入者ライン（ＶＤＳＬ）モデム、例えばＤＯＣＳＩＳモデムのケーブルモデム、およびファイバ・モデムを含んでもよいが、これに限定されるものではない。ルータの例には、ワイヤレス・ファディリティ（ＷｉＦｉ）ルータまたはＩＰルータがある。

【0023】

ＬＡＮは、複数のデバイス、すなわちＵＥ１、ＵＥ２およびＵＥ３として表されるユーザ機器をゲートウェイ・システムＧＷＳと通信可能に接続するように配置される。装置の例として、ボイス・オーバＩＰ（ＶｏＩＰ）ゲートウェイ、ＩＰ電話、ＰＣ、ラップトップ、ウェブパッドその他コンピューティング・パッド・デバイス、スマートフォン、ネットワーク領域記憶デバイス、ＩＰビデオ・ストリーミング・デバイス、およびテレビ・セット・トップ・ボックスを含むが、これに限定されるものではない。更には、ヒーティング、ベンチレーション、エア・コンディショニング、ライトニング、オーディオ、ビデオ、およびセキュリティのための個人領域ネットワーク・デバイスが、ユーザ・デバイスのタイプとしてみなすことができる。

【0024】

ネットワーク・アーキテクチャは、更に、サービス・レポジトリＳＲＥＰおよびサービス・ロケータＳＬＯＣを備えることができる。サービス・レポジトリＳＲＥＰおよびサービス・ロケータＳＬＯＣは、ワイド・エリア・ネットワークＷＡＮを通じてゲートウェイ・システムＧＷＳに接続する。ＧＷＳは、ＳＬＯＣの存在および位置を識別しているものの、ＳＲＥＰの存在および位置を識別していなくてもよい。説明を簡単にするため、１つのみのＳＲＥＰおよび１つのみのＳＬＯＣが示される。当業者にとって、ネットワーク・アーキテクチャが複数のリポジトリおよびサービス・ロケータを備えることができるということが理解されるであろう。更には、サービス・レポジトリおよび／またはサービス・ロケータは、ＬＡＮにも同様にホストすることができる。

【0025】

サービス・レポジトリＳＲＥＰは、サービスを格納するための記憶ユニットを備える。サービスは、任意の種類のコンピュータ実行可能コードとして定義することができ、電子デバイスに対し機能性を付加することができる。コンピュータ実行可能コードの種類の例として、完全なソフトウェア・パッケージ、ソフトウェア・パッケージ・アップデート、ソフトウェア設定、および、ソフトウェア・パッケージにより使用される量のデータを含むが、これに限定されるものではない。記憶装置は、一つ以上のデータベースを備えることができる。本願全体を通じて、「データベース」なる表現は、その如何なるエントリおよび参照を含んだシステムに関連する。

【0026】

サービス・ロケータＳＬＯＣは、通常はネットワーク内の位置サービスの形態を取り、ここで、この位置サービスは共に協働する複数のエレメントにより実施することができる。協働は、階層的なものとしてもよく、例えばドメイン・ネーム・システム（ＤＮＳ）と類似のものとしてもよい。しかしながら、他の方法の協働もまた可能である。例えば、ＳＬＯＣは分散ハッシュ・テーブル（ＤＨＴ）を使用することができ、または、ピア・ツー・ピア・ネットワークを使用することができる。

【0027】

図２ａ，２ｂ，２ｃは、図１のネットワーク・アーキテクチャにおいて使用するためのサブ・ネットワーク・アーキテクチャを概略的に示している。サブ・ネットワーク・アーキテクチャは、インターフェイス・デバイスＧＷ、例えばモデムまたはルータを含み、ゲートウェイ・システムＧＷＳとも称される。また、ゲートウェイ・システムＧＷＳは、サービス・プロビジョニング・ブローカＳＰＢおよびソフトウェア実行環境ＳＷＥＸを備える。図２ａ，２ｂに示すように、ゲートウェイ・システムＧＷＳは、更に、サービス・レジストリＳＲＥＧを含むことができる。

【0028】

サービス・プロビジョニング・ブローカＳＰＢは、ローカル・エリア・ネットワーク内でユーザ機器から発出するサービス要求をハンドリングするように構成される。ＳＰＢは、図２ａに概略的に示されるように、ＧＷと同一の物理デバイス上の同じ場所に配置することができる論理コンポーネントである。また、サービス・プロビジョニング・ブローカＳＰＢの使用に関する詳細については、図３ａ，３ｂに概略的に示される信号フローを参照して検討することになる。

【0029】

サービス実行コンピュータ環境ＳＷＥＸは、サービスを実施するためのソフトウェアとも称される、コンピュータ実行可能情報をインストールするのに用いることができる。ＳＷＥＸは、ソフトウェア・モジュールが動的に、例えば「オンザフライ」でインストールされることができる任意のプラットフォームとしてもよい。ＳＷＥＸは、例えばＯＳＧｉベース・プラットフォーム、Ｌｉｎｕｘ（登録商標）プラットフォーム、またはＷｉｎｄｏｗｓ（登録商標）プラットフォームといったソフトウェアをランすることができる。ソフトウェアが動的に処理されることができる如何なるプラットフォーム（ここでは「処理される」という表現は、インストールされる、設定される、適合される、変更される、管理される内少なくとも１つに関連する）も、本発明の文脈ではＳＷＥＸとしてみなすことができる。ＳＷＥＸ内で利用可能な情報は、ユーザ機器が使用することができ、ファイア・ウォールの形態やローカル・ネットワークへの直接アクセスによる等といった限定がなされることなく、ローカル・ネットワーク内の所望のサービスを実施することができる。更に、好ましい実施形態では、ＳＷＥＸにインストールされる情報は、インストールの後、ゲートウェイ・システムを再起動する必要なく、直接抽出することができ、ローカル・エリア・ネットワーク内で対応するサービスの実施を可能にする。複数のＳＷＥＸがローカル・エリア・ネットワーク内にあってもよいことに留置すべきである。

【0030】

ローカル・エリア・ネットワーク内で利用可能なサービスを登録するために、サービス・レジストリＳＲＥＧを使用することができる。ＳＲＥＧは、例えばより多く登録されたデバイスがローカル・エリア・ネットワーク内に存在する場合に、全てのサービスまたはサービスの一部を登録することができる。ローカル・エリア・ネットワーク内で利用可能なサービスのリストをゲートウェイ・システムＧＷＳの中央位置で用いることにより、要求されたサービスがローカル・エリア・ネットワークＬＡＮ内ですでに利用可能か否かについて、ゲートウェイ・システムＧＷＳによる簡単な検査を可能にする。

【0031】

図２ａのゲートウェイ・システムＧＷＳでは、上記全てのコンポーネントは、単一モジュール内に位置する。単一モジュール内で全ての機能性を有することにより、ネットワークの複雑さを緩和させる。また、ネットワーク全体にわたるエネルギー消費を、削減することもできる。

【0032】

図２ｂでは、インターフェイス・デバイスＧＷは別個のモジュールを形成し、このモジュールは、他のコンポーネントと通信可能に結合され、この場合は単一モジュール内にグループ化される。図２ｃでは、インターフェイス・デバイスＧＷは、より複雑なモジュールの一部であり、更に、ソフトウェア実行可能環境ＳＷＥＸおよびサービス・レジストリＳＲＥＧを含んでいる。このモジュールは、別個のモジュールでＳＰＢに通信可能に結合される。図２ｂ、２ｃの構成は、ローカル・エリア・ネットワークが既に適当な位置にゲートウェイ・システムを有する場合に有用となり得る。次いで、ゲートウェイ・システムの機能性を拡張することが、所望の機能モジュールの単なる追加によって確立することができる。基本ゲートウェイ・システムＧＷＳが、制限られた性能、例えば単なるルーティング性能を有するインターフェイス・デバイスＧＷを含む場合には、この追加は、図２ｂに示すように比較的複雑なモジュールＳＨを含むことができる。しかしながら、ゲートウェイ・システムＧＷＳが既に図２ｃに示すようにより多くの機能性を含む場合には、ゲートウェイ・システムの性能拡張は、図２ｃに示すようにＳＴＢを備えるモジュールへの通信可能な結合を追加することによって確立することができる。

【0033】

サービス・プロビジョニング・ブローカの機能性に関する更なる詳細について、図３ａおよび図３bを参照して検討する。図２ａから２ｃに概略的に示した選択肢に加えて、異なる数のモジュールを有するゲートウェイ・システムを同様に見込むことができることに留意すべきである。例えば、ネットワーク・アーキテクチャはインターフェイス・デバイスＧＷについての別個のモジュール、サービス・プロビジョニング・ブローカＳＰＢについての別個のモジュール、およびソフトウェア実行環境ＳＷＥＸについての別個のモジュールを含むことができる。全てのモジュールは、ローカル・エリア・ネットワークＬＡＮに跨って相互に通信することができる。任意のサービス・レジストリＳＲＥＧは、更に別のモジュールに位置してもよい。更にまた、機能性は、複数のモジュールによって共有してもよい。例えば、ＳＷＥＸは、通信可能に結合される複数のモジュールにわたり広げることができる。

【0034】

図３ａは、図１、図２ａおよび図２ｂを参照して説明したアーキテクチャにおいてサービス要求をハンドリングする方法についての例示的な信号フローを示している。この信号フローでは、エンティティは一般的な意味で表されており、すなわち、ＬＡＮ内のネットワーク・デバイスによって提供されることになるサービスを要求するユーザ機器をＵＥと称する。具体的には、ユーザ機器ＵＥは、図１のアーキテクチャにおけるデバイスＵＥ１、ＵＥ２，ＵＥ３のいずれか一つに対応することになる。加えて、この信号フローでは、要求されたサービスがサービス・レポジトリＳＲＥＰに格納され、また、サービスの位置がサービス・ロケータＳＬＯＣに知られた位置に格納されるという想定がなされる。

【0035】

最初に動作１１では、ユーザ機器ＵＥは、サービス要求をサービス・プロビジョニング・ブローカＳＰＢに送って、サービスを実施するために、更にソフトウェアと称されるコンピュータ実行可能情報を取得する。サービス要求は、マルチキャストまたはユニキャストのメッセージングを用いて送ることができる。サービス要求は、サービスが必要であるという認識に応じて、ＵＥによって直接送ることができる。あるいは、サービス要求は、ローカル・エリア・ネットワーク内でサービス・ディスカバリが上手くいかなかった後に送ることができる。

【0036】

サービス要求は、サービス・パラメータに関する情報を含む。サービス要求に含まれるサービス・パラメータは、全てのサービス機能(feature)、サービス要件、およびサービス選択肢を含み、これらは、少なくともＵＥによって要求され、要求されたサービスによりサポートされる。

【0037】

例えば、プリンタ・サービスの場合、このような情報は、サービス・タイプ情報、すなわちプリンタを含むだけではなく、所望の紙のサイズ、所望の紙の色、およびプリント後の所望の紙のバインド法、例えばワイヤ・ステッチといった他のパラメータも含むことができる。

【0038】

他の例では、サービス要求をサービス・プロバイダ特有のものとすることになろう。例えば、ユーザ・デバイスは、Ａｐｐｌｅ社のｉＰｈｏｎｅとしてもよい。ｉＰｈｏｎｅは、次いで、Ａｐｐｌｅ社のｉＴｕｎｅｓストアからサービスを要求することができる。このような場合、サービス要求は、サービスが、要求されたサービスに責任のあるサービス・プロバイダ、すなわちＡｐｐｌｅ社によって認定された位置からダウンロード可能としなければならない。

【0039】

任意には、ＳＰＢは、動作１２においてサービスがローカル・エリア・ネットワーク内で利用可能かを検査する。特に、検査が多くの時間および労力を有しない場合に、ローカル・エリア・ネットワーク内でサービス可用性を検査することは、サービス要求のパフォーマンスを向上させる。何故ならば、少なくとも動作１３から２０を省略することができるからである。サービスがローカル・エリア・ネットワーク内ですでに利用可能である場合は、サービス・デリバリは、公知の方法で、例えば作動している標準ＵＰｎＰを用いることで、実行することができる。

【0040】

サービス要求を受け取った後に、または、検査が実行される場合には要求されたサービスがローカル・エリア・ネットワーク内で利用可能でないと判定した後に、ＳＰＢは、動作１４においてサービス・ロケータＳＬＯＣにサービス要求を転送するか、またはサービス要求に収容された情報に基づいてローカライゼーション要求を実行する。ＳＰＢ、すなわちＧＷＳ内の他の如何なるコンポーネントも、実際はサービス要求で求められる如何なるナレッジも有していることが必ずしも必要とされないことに留意すべきである。ＳＰＢは、サービスが要求されるということを単に知ることができるだけである。

【0041】

動作１４での転送の前に、ＳＰＢは、付加情報を動作１３のサービス要求に付加することができる。付加情報は、ソフトウェアがインストールされることになるゲートウェイ・システムＧＷＳの性能、またはソフトウェアが他にインストールされることになる場合の他のデバイスの性能に関するものである。また、例えばＬＡＮネットワーク性能（速度、遅延、使用する技術）、または他の利用可能なデバイスおよびサービス（例えばネットワーク・アタッチ・ストレージ(Network Attached Storage)の入手可能性、特定のソフトウェア・ライブラリ等の可用性）といった他の性能についても付加することができる。この情報の付加は、サービス・ロケータＳＬＯＣがそのサーチを改善するのを支援する。何故ならば、ＧＷＳの性能と互換不能なソフトウェア・ダウンロードが早期の段階で破棄されるからである。

【0042】

サービス・タイプおよび１以上の要件に関する情報に基づいて、ＳＬＯＣは、次いで、動作１５において、要求されたサービスが、公衆ネットワーク、例えばワイド・エリア・ネットワークＷＡＮ内でダウンロードを使用可能である位置について、位置特定、換言すれば識別する。この例では、ＳＬＯＣは、要求されたサービスに関連するソフトウェアを、サービス・レポジトリにおいて他のものの中に見つけることができるということがわかる。

【0043】

「ダウンロード位置」という表現は、単にＩＰアドレスのような特定アドレスに関連するのを意味するだけではない。そのアドレスにおいてサービスに関連したソフトウェアをダウンロードすることができる。「ダウンロード位置」という表現はまた、特定のダウンロード・アドレスを導き出す(deduce)するのに十分な他の情報にも関連する。いくつかの実施形態では、このダウンロード位置は、特定アドレス、例えばＩＰアドレスがＤＮＳ解決(rsolution)によって解決することがきるユニフォーム・リソース・ロケータ（ＵＲＬ）の形態に関する情報として与えられるものもある。他の「ダウンロード位置」は、．ｔｏｒｒｅｎｔファイル、ｅ２ｄｋリンク、またはＧｏｏｇｌｅ Ｄｏｃｓ共有リンクのような特定ＵＲＬ（例えば関連を共有している）とすることができる。

【0044】

ダウンロード位置を見つけた後に、この位置は、動作１６においてＳＬＯＣからＳＰＢに転送(transfer)される。動作１５の間、ＳＬＯＣが複数のダウンロード位置を識別することが公平に十分可能であることに留意すべきである。このような場合には、これらの全てのダウンロード位置は、ＳＰＢに転送ことができる。

【0045】

動作１８において、ＳＰＢは、ダウンロード要求メッセージを、識別したダウンロード位置、すなわちサービス・リポジトリＳＲＥＰに送る。複数のダウンロード位置を受け取る場合には、ＳＰＢは、動作１７でのダウンロード位置を選択する。ＳＰＢによる適切なダウンロード位置の選択は、速い選択時間という結果をもたらす。更にまた、この選択は、ゲートウェイ・システム優先(preference)および／またはワイド・エリア・ネットワークのナレッジに基づいてもよい。例えば、この選択は、ダウンロード位置とワイド・エリア・ネットワークを介したゲートウェイ・システムとの間で予測される接続品質に基づいてもよい。更に別の例では、この選択は、好適なダウンロード位置（例えば好適なサービスプロバイダから）に基づいてもよい。

【0046】

このダウンロード要求メッセージに応答して、ＳＲＥＰは、アクセスをサービスに関連したソフトウェアに提供する。ＳＰＢは、これより、動作１９においてサービス関連のソフトウェアを抽出することができる。多くの実施形態では、ソフトウェアの抽出は、ソフトウェア・ダウンロード・アクションを含む。ダウンロード・アクションは、ＦＴＰ（ファイル転送プロトコル）、ＨＴＴＰ（ハイパーテキスト転送プロトコル）、ＳＭＴＰ（シンプル・メール転送プロトコル）およびＴＲ―０６９を用いることによるソフトウェア転送を含むが、これに限定されるものではない。他の実施形態の中には、ソフトウェア抽出は、適切なディスクまたはＵＳＢスティック（ユニバーサル・シリアル・バス）のような物理的なコンピュータ可読媒体上に格納されたソフトウェアを転送するというように、オフラインによる方法を用いてなされることができるものもある。

【0047】

ダウンロードされたソフトウェアは、動作２０においてネットワーク・デバイス上にインストールされる。このことは、ゲートウェイ・システムＧＷＳ内で、または、ＧＷＳにアクセス可能なローカル・エリア・ネットワーク内の他の位置でなされることができる。ＧＷＳ内でのソフトウェアのインストールは、動作１２に示される検査手順が用いられる場合に、このような検査が短い時間期間内で実施することができるという利点を有する。

【0048】

特に、ＧＷＳ内で、サービス関連のソフトウェアは、ソフトウェア実行デバイスＳＷＥＸ上にインストールすることができる。ソフトウェアのＳＷＥＸへのインストールは、インストールの後にローカル・エリア・ネットワーク内でサービスの実行を可能にするために、再起動が何ら必要でないという利点を有する。サービス・タイプのようなサービス情報、およびソフトウェアがダウンロードされるためのサービスに関連する要件情報は、サービス・レジストリに格納することができる。このような登録は、ローカル・エリア・ネットワーク内で利用可能なサービスについてのナレッジを増やす。

【0049】

サービスのインストールの後に、ＳＰＢは、動作２１でサービスがローカル・エリア・ネットワーク内で利用可能であるということをユーザ機器ＵＥに通知する。ユーザ機器ＵＥは、これよりこのサービスを、例えばＵＰｎＰサービス利用と互換性のある、ローカル・エリア・ネットワーク内で利用可能な任意の他のサービスのようにまさに利用することができる。

【0050】

図３ａに示したサービス要求をハンドリンする方法は、デバイスによる要求に応じてローカル・エリア・ネットワーク内でソフトウェアを動的にインストールすることを可能にする。ローカル・エリア・ネットワーク内でのソフトウェアの有効性は、ローカル・エリア・ネットワーク内でのユーザ・デバイスの信頼性を改善させる。通常遠隔でランするサービスがこれよりローカルに使用されることができ、例えばワイド・エリア・ネットワークおよびローカル・エリア・ネットワークにおいて、または、フリー通信バリア、例えばファイア・ウォールの存在に対して、異なる方法のアドレス指定による、トランスペアレンシの欠如に関係した如何なるリスクをも回避する。更にまた、図３ａを参照して説明した方法の使用は、ゲートウェイ・システム内で如何なる全ての利用可能なサービスの事前設定の必要性を回避する。これは、毎日利用可能とする新たなサービスの観点で、および例えば如何なる全ての利用可能なサービスをインストールするメモリのような物理リソースの欠如により、達成するのが困難である。

【0051】

任意には、ゲートウェイ・システムＧＷＳは、サービス要求に応答して、要求元ユーザ・デバイスＵＥに暫定的な(provisional)応答メッセージを送る。暫定的な応答メッセージは、要求したサービスの可用性に対しより確実性を得るに必要な予測時間に関する情報、および／または（ダウンロード後に）サービスを利用可能にするのに必要とする時間に関する情報を含むことができる。実施形態の中には、暫定的な応答は、サービスの可用性に関し、予備的なアナウンスを含むことができる。暫定的な応答メッセージの使用はネットワークのタイムアウトの機会を低減させる。何故ならば、何を予測すべきかについてのユーザ・デバイスのナレッジを改良するからである。暫定的な反応が送られない場合、たとえサービスが即座ではないが利用可能であるとしても、デバイスＵＥはサービスが利用可能ではないと考えることができ、そのサービス要求を終了することができる。暫定的な応答の場合は、デバイスＵＥはサービス要求を終了しないうちにその待ち時間を延長することができ、そして、最初に所望されたのよりもいくらか後に提供される場合に、サービスの利用を可能にする。

【0052】

図３ｂは、図１，２ａ，２ｂを参照して説明したアーキテクチャのサービス要求をハンドリングする方法の他の実施態様における例示的な信号フローの一部を概略的に示している。この実施形態による方法は、動作１６までは図３ａを参照して説明した方法と同様である。この実施形態では、複数のダウンロード位置は、動作１５で見つけられ、動作１６で好ましくは利用可能なサービスの詳細を含むＳＰＢへ転送される。しかしながら、選択動作１７の代わりに、これよりＳＰＢは、複数のダウンロード位置が動作２７において受け取られたことを単に識別するだけである。

【0053】

複数のダウンロード位置の識別に応じて、ＳＰＢは、動作２８において、選択要求メッセージをＵＥに送る。次いで、ＵＥは、例えばサービス要求にはない付加的な基準に基づいて、好適なダウンロード位置を動作２９で選択する。選択の後に、動作３０において、ＵＥは、選択したダウンロード位置を収容する選択応答メッセージをＳＰＢに送る。選択応答メッセージを受け取りに応じて、ＳＰＢは、動作１８を実行することにより、更には図３ａを参照して説明したように、進行する。

【0054】

ＵＥによるダウンロード位置の選択は、最適なサービスを選択することができるという利点を有する。サービス要求が最小の要件を収容することができる場合には、ダウンロード位置の選択は付加的な基準に基づいてもよい。例えば、プリンタがＡ３の紙フォーマットをハンドリングできるべきという基準によってプリンタ・サービスが要求された場合には、複数のプリンタに対応するダウンロード位置を見つけるとよい。図３ｂに示される信号フローによる本方法は、好適なオプション、例えばフルカラーで印刷することをハンドリングできるプリンタをＵＥが選択することを可能にする。プリンタのうち１台のみがＡ３フォーマットの紙を印刷することができる場合には、ＵＥはこの特定のプリンタを選択することができる。

【0055】

サービス・プロビジョニング・ブローカは、周辺機器を有するプロセッサを備えたコンピュータ・システムとして実装することができる。プロセッサは、指示およびデータを格納する１つ以上のメモリ・ユニット、１つ以上の読取ユニット、１つ以上の入力デバイス、例えばキーボード、タッチ・スクリーンまたはマウス、並びに１つ以上の出力デバイス、たとえばモニタと接続することができる。更に、ネットワーク入力／出力（Ｉ／Ｏ）デバイスは、ネットワークへの接続のために提供することができる。

【0056】

当業者には知られていているように、プロセッサは、並行して、または１つのプロセッサによって制御されて機能するいくつかの処理ユニットを備えることができ、遠隔に、或いはローカル・エリア・ネットワークを介して分散して相互に配置することができる。本発明の機能性は、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントの組合せによって実現することができる。アナログまたはデジタルのいずれかであるハードウェア・コンポーネントは、プロセッサ内に存在してもよく、または、プロセッサとインターフェイスされる別個の回路として存在してもよい。更に、当業者にとって、プロセッサにより実行可能であるソフトウェア・コンポーネントはプロセッサのメモリ領域に存在してもよいものと認められる。

【0057】

本方法の実施形態では、ローカル・エリア・ネットワーク内でサービス要求をハンドリングする方法の実施形態を、プロセッサによって実行されるときに実施するために、例えばＤＶＤまたはＵＳＢスティックのコンピュータ可読媒体に格納することができる。格納したデータは、コンピュータ・プログラムの形態とすることができる。そして、コンピュータ・プログラムをコンピュータ可読媒体からコンピュータ・システムにロードした後にコンピュータ・システムによって実行されるときには、当該コンピュータ・プログラムは、本方法の実施形態を実施するようにプログラムされる。

【0058】

当業者にとって、本発明について代替のおよび均等の実施形態を考案し、また、本発明の要旨を逸脱しない範囲で実行に減少させることができ、そして、本発明の範囲が添付の特許請求の範囲によってのみ限定されることは明らかである。

【0059】

略記
ＡＤＳＬ：非対称型デジタル加入者線(Asymmetric Digital Subscriber Line)
ＤＨＴ：分散ハッシュ・テーブル(Distributed Hash Table)
ＤＮＳ：ドメイン・ネーム・システム(Domain Naming System)
ＤＯＣＳＩＳ：データ・オーバ・ケーブル・サービス・インターフェイス仕様(Data Over Cable Service Interface Specification)
ＤＶＤ：デジタル・ビデオ・ディスク(Digital Video Disc)
ＦＴＰ：ファイル転送プロトコル(File Transfer Protocol)
ＨＴＴＰ：ハイパーテキスト転送プロトコル(Hyper Text Transfer Protocol)
Ｉ／Ｏ：入力／出力(Input / Output)
ＩＰ：インターネット・プロトコル(Internet Protocol)
ＬＡＮ：ローカル・エリア・ネットワーク(Local Area Network)
ＯＳＧｉ：オープン・サービス・ゲートウェイ・イニシアティブ(Open Service Gateway initiative)
ＳＭＴＰ：シンプル・メール転送プロトコル(Simple Mail Transfer Protocol)
ＵＥ：ユーザ機器(User Equipment)
ＵＰｎＰ：ユニバーサル・プラグ・アンド・プレイ(Universal Plug and Play)
ＵＲＬ：単一リソース・ロケータ(Uniform Resource Locator)
ＵＳＢ：ユニバーサル・シリアル・バス(Universal Serial Bus)
ＶＤＳＬ：極めて高ビット・レートのデジタル加入者ライン(Very high bit rate Digital Subscriber Line)
ＶｏＩＰ：ボイス・オーバ・インターネット・プロトコル(Voice over Internet Protocol)
ＷＡＮ：ワイド・エリア・ネットワーク(Wide Area Network)
ＷｉＦｉ：無線フィデリティ(Wireless Fidelity)
ＸＭＬ：拡張マークアップ言語(Extensible Markup Language)

【図1】

【図2】

【図3a】

【図3b】

【外国語明細書】

2015232890000001.pdf