特許第6620761号(P6620761)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

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

▶ 日本電気株式会社の特許一覧

特許6620761情報処理装置、情報処理方法、及び、プログラム
<>
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000002
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000003
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000004
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000005
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000006
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000007
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000008
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000009
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000010
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000011
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000012
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000013
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000014
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000015
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000016
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000017
  • 特許6620761-情報処理装置、情報処理方法、及び、プログラム 図000018
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6620761
(24)【登録日】2019年11月29日
(45)【発行日】2019年12月18日
(54)【発明の名称】情報処理装置、情報処理方法、及び、プログラム
(51)【国際特許分類】
   G06F 13/00 20060101AFI20191209BHJP
【FI】
   G06F13/00 520C
   G06F13/00 520D
   G06F13/00 520F
【請求項の数】9
【全頁数】33
(21)【出願番号】特願2016-563508(P2016-563508)
(86)(22)【出願日】2015年12月8日
(86)【国際出願番号】JP2015006114
(87)【国際公開番号】WO2016092831
(87)【国際公開日】20160616
【審査請求日】2018年11月15日
(31)【優先権主張番号】特願2014-249058(P2014-249058)
(32)【優先日】2014年12月9日
(33)【優先権主張国】JP
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100109313
【弁理士】
【氏名又は名称】机 昌彦
(74)【代理人】
【識別番号】100124154
【弁理士】
【氏名又は名称】下坂 直樹
(72)【発明者】
【氏名】小倉 一峰
(72)【発明者】
【氏名】山崎 康広
【審査官】 安藤 一道
(56)【参考文献】
【文献】 米国特許出願公開第2014/0237085(US,A1)
【文献】 特開2002−342240(JP,A)
【文献】 特開2013−187664(JP,A)
【文献】 特開2009−277234(JP,A)
【文献】 欧州特許出願公開第2798816(EP,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 13/00
(57)【特許請求の範囲】
【請求項1】
コンテンツを保存するコンテンツ保存手段と、
コンテンツを要求する要求元を示す情報と、要求の対象であるコンテンツを判定するための条件であるリクエスト条件と、前記要求元が保存しているコンテンツの情報を含む要求元保存済コンテンツとを含むリクエストメッセージを受信及び送信する通信手段と、
前記コンテンツ保存手段に保存されているコンテンツにおいて、前記リクエスト条件を満足し、かつ、前記要求元保存済コンテンツに含まれないコンテンツを判定するリクエスト判定手段と、
前記要求元保存済コンテンツに含まれないコンテンツがあると判定された場合、前記判定されたコンテンツに関する情報を前記要求元保存済コンテンツに追加して前記リクエストメッセージを更新し、前記判定されたコンテンツを前記要求元に送信し、前記更新したリクエストメッセージを他の装置に送信し、
コンテンツがないと判定された場合、前記リクエストメッセージを更新しないで他の装置に送信するリクエストメッセージ処理手段と
を含む情報処理装置。
【請求項2】
前記リクエスト判定手段が、
前記通信手段を介して、前記判定したコンテンツを前記要求元に送信する
請求項1に記載の情報処理装置。
【請求項3】
前記リクエスト判定手段が、
前記リクエスト条件の所定の一部を用いて判定する
請求項1又は2に記載の情報処理装置。
【請求項4】
前記リクエストメッセージ処理手段が、
前記通信手段を介して、前記更新したリクエストメッセージを送信する
請求項1ないし3のいずれか1項に記載の情報処理装置。
【請求項5】
前記通信手段が
前記コンテンツを受信する
請求項1ないし4のいずれか1項に記載の情報処理装置。
【請求項6】
前記リクエストメッセージが、
前記リクエストメッセージが転送された装置を示す情報を含み、
前記リクエストメッセージ処理手段が、
前記転送された装置を示す情報に、自装置に関する情報を追加し、
前記通信手段が、
前記転送された装置を示す情報を基に、前記リクエストメッセージを転送する装置を決定する
請求項1ないし5のいずれか1項に記載の情報処理装置。
【請求項7】
自装置が担当装置であるか否かを判定する担当装置判断手段をさらに含み、
前記リクエストメッセージが、
コンテンツを必ず保存する担当装置に関する情報を含み、
前記リクエストメッセージ処理手段が、
前記担当装置判断手段の判断の結果、自装置が前記担当装置の場合に、前記リクエストメッセージを転送しない
請求項1ないし6のいずれか1項に記載の情報処理装置。
【請求項8】
コンテンツを要求する要求元を示す情報と、要求の対象であるコンテンツを判定するための条件であるリクエスト条件と、前記要求元が保存しているコンテンツの情報を含む要求元保存済コンテンツとを含むリクエストメッセージを受信し、
前記保存されているコンテンツにおいて、前記リクエスト条件を満足し、かつ、前記要求元保存済コンテンツに含まれないコンテンツを判定し、
前記要求元保存済コンテンツに含まれないコンテンツがあると判定された場合、前記判定されたコンテンツに関する情報を前記要求元保存済コンテンツに追加して前記リクエストメッセージを更新し、前記判定されたコンテンツを前記要求元に送信し、前記更新したリクエストメッセージを他の装置に送信し、
コンテンツがないと判定された場合、前記リクエストメッセージを更新しないで他の装置に送信する
情報処理方法。
【請求項9】
コンテンツを要求する要求元を示す情報と、要求の対象であるコンテンツを判定するための条件であるリクエスト条件と、前記要求元が保存しているコンテンツの情報を含む要求元保存済コンテンツとを含むリクエストメッセージを受信する処理と、
前記保存されているコンテンツにおいて、前記リクエスト条件を満足し、かつ、前記要求元保存済コンテンツに含まれないコンテンツを判定する処理と、
前記要求元保存済コンテンツに含まれないコンテンツがあると判定された場合、前記判定されたコンテンツに関する情報を前記要求元保存済コンテンツに追加して前記リクエストメッセージを更新し、前記判定されたコンテンツを前記要求元に送信し、前記更新したリクエストメッセージを他の装置に送信する処理と、
コンテンツがないと判定された場合、前記リクエストメッセージを更新しないで他の装置に送信する処理
をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報の通信に関し、特に複数の装置を経由して情報を通信する情報処理装置、情報処理方法、及び、プログラムに関する。
【背景技術】
【0002】
近年、ネットワークの規模が、拡大している。そのため、ネットワークに接続しているユーザの装置(以下、単に「ユーザ」と呼ぶ場合もある)において、コンテンツ等のデータを取得するための時間が、増大している。
【0003】
そこで、ユーザの装置がコンテンツを取得するまでの時間を短縮するための技術が、提案されている。このような技術として、コンテンツを複数のサーバに配置して、局所的なトラフィック集中を緩和するCDN(Contents Delivery Network)がある(例えば、特許文献1を参照)。あるいは、このような技術として、キャッシュを利用したコンテンツ取得が可能なCCN(Content-Centric Networking)の技術が、提案されている(例えば、非特許文献1を参照)。
【0004】
CDNは、地理的に離れた場所に、複数のサーバを配置する。そして、それらサーバが、コンテンツを、複数、かつ、分散配置するように、保存(ミラーリング)する。そして、所定の管理サーバは、ユーザの装置から、コンテンツの要求を受信した場合、コンテンツを保持するサーバの中で、ユーザの装置に、地理的又はネットワーク的に最も近いサーバを、コンテンツの取得先として、指定する。CDNは、このような動作を基に、ユーザの装置における高速なコンテンツの取得を可能とする。このように、CDNでは、管理サーバが、コンテンツの配置場所を把握している。
【0005】
一般的に、コンテンツの取得の動作は、コンテンツを保存するサーバを検索し、そのサーバに対してコンテンツの要求を送信する動作となる。また、IP(Internet Protocol)ネットワークにおいて、一般的に、ルータが、IPアドレスに対応する出力ポートを示すルーティングテーブルを保持し、経路制御を実行している。
【0006】
これに対し、CCNにおけるコンテンツの取得は、コンテンツ名を用いて実現されている。CCNにおけるルータは、コンテンツ名に対応する出力ポートを示すFIB(Forwarding Information Base)テーブルを保持する。例えば、CCNのルータは、コンテンツ名の冒頭の文字がAならば出力ポート1、コンテンツ名の冒頭の文字がBならば出力ポート2という対応情報を含むFIBテーブルを保持し、経路制御を実行している。
【0007】
CCNは、ルータ及びサーバなどで構成されたネットワークである。CCNでは、コンテンツを要求する装置が、CCNに、コンテンツに対応するコンテンツ名を通知する。そして、CCNが、コンテンツ名を基にアドレスを解決し、コンテンツを要求した装置にアドレス情報を送信する。
【0008】
また、CCNにおいて、コンテンツのキャッシング機能を持つルータは、コンテンツを中継した場合に、中継したコンテンツをキャッシングする。そして、そのルータは、キャッシングしたコンテンツの取得の要求を受信した場合、コンテンツを要求した装置に対して、キャッシュしているコンテンツを送信する。この動作を基に、CCNにおいて、一度キャッシュされたコンテンツは、そのコンテンツが、存在していた場所(サーバ)より、ユーザに近い場所(中継ルータ)から送信される。そのため、コンテンツを供給した装置は、コンテンツが本来存在する場所からの送信より、早期にコンテンツを取得できる。つまり、CCNは、コンテンツ取得時間を短縮できる。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開2009−054182号公報
【非特許文献】
【0010】
【非特許文献1】Van Jacobson, Mark Mosko, Diana Smetters, and JJ Garcia-Luna, "Content-centric networking", Palo Alto Research Center, Whitepaper, January 30, 2007.
【発明の概要】
【発明が解決しようとする課題】
【0011】
特許文献1に記載の技術(CDN)のように、所定の管理サーバがコンテンツを保存している装置を管理する技術では、管理サーバにコンテンツを保持する装置の配置場所を登録しておくことが、必要である。
【0012】
管理サーバに新しくコンテンツを保存した装置を登録するためには、新たにコンテンツを保存した装置が、管理サーバに、コンテンツを保存したことを通知する必要がある。あるいは、コンテンツを登録する装置が、管理サーバに、コンテンツを保存した装置の配置場所を通知する必要がある。そのため、コンテンツを保存する装置及び保存されるコンテンツの増加に伴い、コンテンツに関する情報の通知及びコンテンツの管理において、複雑の度合いが、増加する。さらに、管理サーバが、機能しなくなった場合(例えば、装置のダウン)、コンテンツを利用する装置は、コンテンツを取得ができなくなる。
【0013】
このように、特許文献1に記載の技術(CDN)は、コンテンツを保存する装置に加え、管理用のサーバなど他の装置が必要であるという問題点があった。さらに、特許文献1に記載の技術は、コンテンツの管理が複雑となり、コンテンツを保持する装置に加え、その他の装置(管理用のサーバ)の故障時にも、コンテンツを取得できなくなるという問題点があった。
【0014】
また、非特許文献1に記載の技術(CCN)には、次に詳細に説明するように、非効率的になるという問題点があった。
【0015】
図17に示されているネットワーク構成を参照して、CCNにおける問題点を説明する。
【0016】
図17に示されているネットワークは、複数の端末(NないしN)と、要求端末(S)と、端末を接続する通信リンクとで構成されている。また、説明に用いるコンテンツ(CないしC)は、位置情報が付与されている。要求端末Sは、コンテンツの要求として、コンテンツを指定する条件(例えば、位置情報としてのエリア(範囲又は領域))を指定する。そして、要求端末Sは、そのような条件を含む要求を用いて、指定したエリア内の位置情報が付与されたコンテンツを取得する。
【0017】
例えば、要求端末Sは、「中心座標の位置(x,y)から半径rの略円となるエリアA内のコンテンツ」との条件を用いて、コンテンツを要求する。
【0018】
ここで、指定したエリアA内に位置情報が付与されたコンテンツは、コンテンツC、C、C、C、及びCとする。そして、コンテンツ(CないしC)は、図17に示されているように、通信端末N、N及びNに、分散配置されているとする。ここで、通信端末Nが、オリジナルのコンテンツ(CないしC)を保持する端末とする。つまり、分散配置に基づくキャッシュ機能が働かない場合、要求端末Sは、全てのコンテンツを通信端末Nから取得する必要がある。
【0019】
また、要求端末Sは、どの端末がどのコンテンツを保存しているか、コンテンツとして何があるのか、及び、コンテンツが幾つ存在しているかなどが、分からない。そのため、要求端末Sにとって、コンテンツの要求は、不特定多数のコンテンツを対象とする要求となる。
【0020】
CCNでは、コンテンツ自体が、コンテンツの配置場所(アドレス)に関する情報を含む。例えば、コンテンツ(CないしC)を、コンテンツの種類(一例として「data」とする)と、エリア(一例として「A」とする)と、コンテンツ名とを用いた構造化として表すと、コンテンツは、それぞれ、次のように表される。コンテンツCは、「/data/A/C」である。コンテンツCは、「/data/A/C」である。コンテンツCは、「/data/A/C」である。コンテンツCは、「/data/A/C」である。コンテンツCは、「/data/A/C」である。
【0021】
そして、要求端末Sは、コンテンツの要求として、コンテンツの範囲として「/data/A」に含まれるコンテンツを要求するInterestメッセージを用いる。つまり、要求端末Sは、リクエストメッセージを送信して、コンテンツを取得する。
【0022】
ここで、Interestメッセージの通信経路(転送経路)は、通信端末N、N、及びNの順とする。
【0023】
キャッシュ機能を用いない場合、要求端末Sが送信するリクエストメッセージ(Interestメッセージ)は、「S→N→N→N」と送信される。そして、リクエストメッセージに対応するコンテンツは、「N→N→N→S」と送信される。つまり、通信経路は、「S→N→N→N→N→N→S」となる。
【0024】
これに対し、例えば、端末Nが、対象となる全てのコンテンツ(例えば、コンテンツC)を保存している場合、端末Nは、要求端末Sに、リクエストメッセージに対応したコンテンツを返送する。この場合、通信経路は、「S→N→S」となる。このように、CCNは、本来、「S→N→N→N→N→N→S」となる通信経路を、「S→N→S」と短縮し、要求端末Sにおけるコンテンツ取得時間を短縮する。
【0025】
しかし、通信経路の途中の端末(例えば、N)は、要求の対象となる全てのコンテンツではなく、一部のコンテンツを保存(キャッシュ)している場合がある。この場合でも、その端末は、保存しているコンテンツを要求端末Sに送信する。例えば、図17に示されているように、端末Nが、コンテンツC及びCを保存している場合、端末Nは、コンテンツC及び/又はCを含むコンテンツの要求に対し、コンテンツC及び/又はCを、要求端末Sに送信する。そして、コンテンツを送信した場合、その端末(例えば、N)は、リクエストメッセージを、通信経路における次の端末(例えば、N)に転送しない。
【0026】
端末がリクエストメッセージを転送しない理由は、次のとおりである。コンテンツの一部を転送した端末Nが、コンテンツを送信し、かつ、リクエストメッセージを転送した場合、転送済みのコンテンツを保存する端末Nが、リクエストメッセージを受信する可能性がある。その場合、転送済みコンテンツを保持する端末Nは、リクエストメッセージに対応して、転送済みのコンテンツを送信する。例えば、端末Nがリクエストメッセージを受信した場合、端末Nは、コンテンツCないしCを、要求端末Sに送信する。その結果、要求端末Sは、コンテンツC及びCを重複受信する。このように、コンテンツを送信した端末が、リクエストメッセージを転送する場合、要求端末Sは、経路上にあるコンテンツを保存する全ての端末からコンテンツを重複受信することになる。このような重複受信を防ぐため、端末は、コンテンツを送信した場合、リクエストメッセージを転送しない。
【0027】
つまり、コンテンツの一部がキャッシュされた場合、要求端末Sは、キャッシュされた一部のコンテンツしか取得できない。
【0028】
このように、コンテンツが、複数の装置に、不均一に分散配置されている場合、CCNには、適切に機能しないという問題点があった。
【0029】
また、CCNは、例えば、「/data/A/*(*は、ワイルドカードを示す)」のような、複数のコンテンツをリクエストする手段を備えていない。
【0030】
なお、CCNは、Interestメッセージにexcludeフィールドを備えている。excludeフィールドに含まれるコンテンツは、取得の対象外となる。そこで、要求端末Sは、Interestメッセージのexcludeフィールドを用いて、複数のコンテンツを取得することができる。
【0031】
すなわち、要求端末Sは、コンテンツを取得後、既に取得済みのコンテンツの情報をexcludeフィールドに追加する。そして、要求端末Sは、再度、Interestメッセージ(リクエストメッセージ)を送信する。その結果、要求端末Sは、excludeフィールドに記載がないコンテンツを取得できる。要求端末Sは、コンテンツを取得できなくなるまでこの動作を繰り返して、リクエストメッセージの対象であるネットワーク内の全てのコンテンツを取得できる。
【0032】
しかし、この動作は、要求端末Sが、リクエストメッセージを複数回送信する必要である。そのため、この動作は、非常に、非効率な動作である。
【0033】
このように、非特許文献1に記載の技術(CCN)には、動作が非効率的になるという問題点があった。
【0034】
本発明の目的は、上記問題点を解決し、管理サーバなどを必要とせずに、複数のコンテンツを効率的に取得する情報処理装置、情報処理方法、及び、プログラムを提供することにある。
【課題を解決するための手段】
【0035】
本発明の一形態における情報処理装置は、コンテンツを保存するコンテンツ保存手段と、コンテンツを要求する要求元を示す情報と、要求の対象であるコンテンツを判定するための条件であるリクエスト条件と、要求元が保存しているコンテンツの情報を含む要求元保存済コンテンツとを含むリクエストメッセージを受信及び送信する通信手段と、コンテンツ保存手段に保存されているコンテンツにおいて、リクエスト条件を満足し、かつ、要求元保存済コンテンツに含まれないコンテンツを判定するリクエスト判定手段と、判定されたコンテンツに関する情報を要求元保存済コンテンツに追加してリクエストメッセージを更新するリクエストメッセージ処理手段とを含む。
【0036】
本発明の一形態におけるデータ処理方法は、コンテンツを保存し、コンテンツを要求する要求元を示す情報と、要求の対象であるコンテンツを判定するための条件であるリクエスト条件と、要求元が保存しているコンテンツの情報を含む要求元保存済コンテンツとを含むリクエストメッセージを受信し、保存されているコンテンツにおいて、リクエスト条件を満足し、かつ、要求元保存済コンテンツに含まれないコンテンツを判定し、判定されたコンテンツに関する情報を要求元保存済コンテンツに追加してリクエストメッセージを更新する。
【0037】
本発明の一形態における記録媒体は、コンテンツを保存する処理と、コンテンツを要求する要求元を示す情報と、要求の対象であるコンテンツを判定するための条件であるリクエスト条件と、要求元が保存しているコンテンツの情報を含む要求元保存済コンテンツとを含むリクエストメッセージを受信する処理と、保存されているコンテンツにおいて、リクエスト条件を満足し、かつ、要求元保存済コンテンツに含まれないコンテンツを判定する処理と、判定されたコンテンツに関する情報を要求元保存済コンテンツに追加してリクエストメッセージを更新する処理とをコンピュータに実行させるプログラムをコンピュータ読み取り可能に記録する。

【発明の効果】
【0038】
本発明に基づけば、管理サーバなどを必要とせずに、複数のコンテンツを効率的に取得するとの効果を奏することができる。
【図面の簡単な説明】
【0039】
図1図1は、本発明における第1の実施形態に係る情報処理装置を含むネットワークの一例を示すブロック図である。
図2図2は、第1の実施形態に係る情報処理装置の構成の一例を示すブロック図である。
図3図3は、第1の実施形態に係るリクエストメッセージのフォーマットの一例を示す図である。
図4図4は、第1の実施形態に係るリクエストメッセージの一例を示す図である。
図5図5は、第1の実施形態に係るリクエストメッセージの一例を示す図である。
図6図6は、第1の実施形態に係るリクエストメッセージの一例を示す図である。
図7図7は、第1の実施形態に係るリクエストメッセージの一例を示す図である。
図8図8は、第1の実施形態に係る情報処理装置の動作の一例を示すフローチャートである。
図9図9は、第1の実施形態に係る情報処理装置の動作の一例を示すフローチャートである。
図10図10は、第1の実施形態の変形例に係る情報処理装置の構成の一例を示すブロック図である。
図11図11は、第2の実施形態に係る情報処理装置の構成の一例を示すブロック図である。
図12図12は、第2の実施形態に係るリクエストメッセージのフォーマットの一例を示す図である。
図13図13は、第3の実施形態に係る情報処理装置の構成の一例を示すブロック図である。
図14図14は、第3の実施形態に係るリクエストメッセージのフォーマットの一例を示す図である。
図15図15は、第3の実施形態に係る情報処理装置の動作の一例を示すフローチャートである。
図16図16は、第3の実施形態に係る情報処理装置の動作の別の一例を示すフローチャートである。
図17図17は、背景技術の説明に用いるネットワーク構成を示す図である。
【発明を実施するための形態】
【0040】
次に、本発明の実施形態について図面を参照して説明する。
【0041】
なお、各図面は、本発明の実施形態を説明するものである。ただし、本発明は、各図面の記載に限られるわけではない。また、各図面の同様の構成には、同じ番号を付し、その繰り返しの説明を、省略する場合がある。
【0042】
また、以下の説明に用いる図面において、本発明の実施形態に関係しない周知の部分の構成については、記載を省略し、図示しない場合もある。
【0043】
<第1の実施形態>
本発明における第1の実施形態について、図面を参照して説明する。
【0044】
[説明の前提]
まず、以下の説明における前提について説明する。
【0045】
図1は、本発明における第1の実施形態に係る情報処理装置200を含むネットワーク250の構成の一例を示すブロック図である。
【0046】
ネットワーク250は、所定の通信手段(リンク)で接続された複数の情報処理装置200を含む。ここで、いずれかの情報処理装置200が、他の情報処理装置200が保存するデータ(以下、「コンテンツ」と呼ぶ)を要求(リクエスト)するためのメッセージ(以下、「リクエストメッセージ」と呼ぶ)を送信する。以下、最初にリクエストメッセージを送信する情報処理装置200を「要求元」と呼ぶ。なお、リクエストメッセージは、クエリーとも呼ばれる。
【0047】
また、情報処理装置200は、所定の経路に沿って、他の情報処理装置200(以下、「前の装置」と呼ぶ)からリクエストメッセージを受信した場合、リクエストメッセージの対応した処理を実行する。そして、情報処理装置200は、必要に応じて、その経路における次の情報処理装置200(以下、「次の装置」と呼ぶ)にリクエストメッセージを転送する。
【0048】
また、以下の説明において、ネットワーク250におけるリクエストメッセージの転送経路は、特に制限されない。情報処理装置200は、いずれの情報処理装置200から、リクエストメッセージを受信してもよい。また、情報処理装置200は、いずれの情報処理装置200にリクエストメッセージを送信してよい。
【0049】
なお、図1においてネットワーク250が含む情報処理装置200の数は、一例であり、本実施形態は、これに限られない。例えば、ネットワーク250は、6台未満の情報処理装置200を含んでもよく、6台を超える情報処理装置200を含んでもよい。
【0050】
また、ネットワーク250の通信手段(リンク)は、特に制限されない。ネットワーク250の通信手段(リンク)は、無線、又は、有線でもよい。さらに、ネットワーク250は、複数の種類の通信手段を含んでもよい。また、ネットワーク250は、1対1の通信ではなく、1対多通信、又は、多対多通信を用いてもよい。
【0051】
また、ネットワーク250における転送の経路は、固定でもよく、動的に変化してもよい。さらに、ネットワーク250における転送の経路は、情報処理装置200が、リクエストメッセージを重複して受信するように設定されてもよい。つまり、情報処理装置200がリクエストメッセージを受信する回数は、特に制限されない。情報処理装置200は、リクエストメッセージを、複数回受信してもよい。また、ネットワーク250は、リクエストメッセージを受信しない情報処理装置200を、含んでもよい。
【0052】
また、ネットワーク250における転送経路の選択の方法は、特に制限されない。例えば、選択方法は、ネットワーク250内からランダムに転送先の装置を選択する処理を繰り返す方法でもよい。このような経路選択方法の一例として、ルーティングプロトコルが、ある。あるいは、選択方法は、ネットワーク250が有線ネットワークの場合、RIP(Routing Information Protocol)又はOSPF(Open Shortest Path First)でもよい。また、選択方法は、ネットワーク250が無線ネットワークの場合、OLSR(Optimized Link State Routing)又はAODV(Ad-hoc On Demand distance Vector)でもよい。また、選択された経路は、1本に限らず、複数本の経路のパスを含んでもよい。
【0053】
本実施形態の説明では、一例として、経路は、図1に示されているように、左側下の情報処理装置200から、時計回りに、左側中央、左側上、右側上、右側中央、及び、右側下の情報処理装置200の順とする。ただし、この経路は、説明に用いるための一例である。情報処理装置200は、上記のとおり、各種の手法を用いて、リクエストメッセージの送信先を決めてもよい。
【0054】
また、情報処理装置200は、自装置以外の情報処理装置200(以下、「他の装置」と呼ぶ)が保存するコンテンツを知らない。
【0055】
なお、ネットワーク250に含まれる情報処理装置200は、いずれも、同様の動作が可能であり、特に区別はない。ただし、以下の説明の便宜のため、次のような前提を用いる。
【0056】
要求元は、図1における左側下の情報処理装置200(二重丸の情報処理装置200)とする。そして、要求元である情報処理装置200は、例えば、自装置で動作するアプリケーション又は図示しない装置から、コンテンツCないしCの5つのコンテンツに対する取得の要求を受信する。その結果、要求元である情報処理装置200は、コンテンツCないしCを取得する。ただし、要求元の情報処理装置200は、コンテンツCを保存している。したがって、要求元の情報処理装置200は、実際の取得動作として、コンテンツCないしCを取得すればよい。
【0057】
また、左側中央の情報処理装置200(灰色の円の情報処理装置200)は、コンテンツC及びCを保存している。また、右側中央の情報処理装置200は、コンテンツC及びCを保存している。また、右側上の情報処理装置200(黒塗り円の情報処理装置200)は、コンテンツCないしCを保存している。つまり、この情報処理装置200が、コンテンツの保存元の装置である。
【0058】
また、以下の説明において、コンテンツの送信及び受信の手法は、特に制限されない。そこで、以下では、一例として、本実施形態は、CCNに用いられているようなコンテンツ名を用いるとする。この場合、例えば、コンテンツ名が、ネットワーク250内の装置間で既知のコンテンツの場合、コンテンツの要求元である情報処理装置200は、コンテンツ名を含むリクエストメッセージを用いて、コンテンツを保存する装置にコンテンツを要求する。
【0059】
さらに、情報処理装置200は、リクエストメッセージの送信及び転送に加え、コンテンツのネットワーク250内での冗長度を大きくするために、他の装置にコンテンツを送信する場合もある。つまり、ネットワーク250内の少なくとも一部の情報処理装置200は、少なくとも一部のコンテンツを共有する。さらに、コンテンツには、全装置で共有されるコンテンツが、あってもよい。つまり、図1に示されているように、少なくとも一部のコンテント又はコンテンツは、ネットワーク250内の情報処理装置200に分散配置されている。
【0060】
このように、本実施形態のネットワーク250は、コンテンツの配置場所を管理する管理サーバを含まない。
【0061】
なお、本実施形態は、既に説明した通り、CCNにおけるコンテンツ名を用いる必要はない。しかし、本実施形態がCCNのおけるコンテンツ名を用いる場合、本実施形態は、例えば、次のように動作してもよい。
【0062】
コンテンツは、それぞれ、位置情報を含む。そして、コンテンツは、位置情報を用いて、識別される。コンテンツの要求元の装置は、要求の対象となるコンテンツの位置に関する情報を含むリクエストメッセージを送信する。例えば、リクエストメッセージは、「所定の位置を中心とした所定の範囲(例えば、エリアA)内の位置情報を持つコンテンツ」との情報を含む。なお、上記の「エリアAの位置情報を持つコンテンツ」とのリクエストメッセージは、配置が特定されてない複数のコンテンツ(不特定多数のコンテンツ)を対象とするリクエストメッセージとなる。
【0063】
不特定多数のコンテンツを対象とするリクエストメッセージは、コンテンツを識別する識別子を構成する要素の数に対応して、指定方法が、異なる。
【0064】
コンテンツの識別子が、複数の要素に基づいて構成される場合、リクエストメッセージは、少なくとも一部の要素を用いてコンテンツを指定する。
【0065】
例えば、コンテンツを識別する要素が「[コンテンツ名]+[生成者]」の場合を想定する。その場合、リクエストメッセージに含まれるコンテンツを指定する条件は、「コンテンツの生成者(又は生成装置名)が「mm」のコンテンツ」、「コンテンツ名が「nn」のコンテンツ」となる。さらに、コンテンツを指定する条件は、「コンテンツの生成者が「mm」、かつ、コンテンツ名が「nn」のコンテンツ」でもよい。なお、「mm」及び「nn」が、任意の名称である。
【0066】
一方、コンテンツの識別子が、1つの要素で構成される場合、その要素の値は、所定の値(閾値)との大小比較が可能である。そこで、情報処理装置200は、所定の閾値を含むリクエストメッセージを用いて、コンテンツを指定してもよい。あるいは、情報処理装置20は、コンテンツの値(上記の1つの要素に対応する値)を含むリクエストメッセージを用いて、コンテンツを指定してもよい。
【0067】
例えば、コンテンツを識別する要素が、「生成時間」の場合、リクエストは、「時刻t以降に生成されたコンテンツ」となる。あるいは、リクエストは、「時刻tから時刻tまでに生成されたコンテンツ」となる。
【0068】
また、コンテンツを識別する要素は、例えば、コンテンツ名若しくは種類などのコンテンツに関する情報、生成時間若しくは更新時間などの時間に関する情報、又は、生成装置若しくは更新装置などの装置に関する情報などでもよい。このように、コンテンツを識別する要素は、コンテンツを識別できるものであれば、特に制限されない。例えば、コンテンツを識別する要素は、利用者などが独自に定義した要素でもよい。
【0069】
なお、以下の説明において、上記のような要求対象のコンテンツを指定する条件を、「リクエスト条件」と呼ぶ。
【0070】
[構成の説明]
次に、本発明における第1の実施形態に係る情報処理装置200の構成について、図面を参照して説明する。
【0071】
図2は、第1の実施形態に係る情報処理装置200の構成の一例を示すブロック図である。ただし、図面中の矢印の方向は、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
【0072】
図2に示されているように、情報処理装置200は、通信部201と、コンテンツ保存部202と、リクエスト判定部203と、リクエストメッセージ処理部204とを含む。
【0073】
通信部201は、ネットワーク250を介した情報(例えば、コンテンツ及びリクエストメッセージ)の送信及び受信を行なう。より詳細には、通信部201は、次のような動作(機能)を実行する。
【0074】
通信部201は、他の装置との間で、情報を通信する。例えば、通信部201は、テキスト、画像又は映像を含むコンテンツを送信又は受信する。
【0075】
また、通信部201は、他の装置から受信したコンテンツをコンテンツ保存部202に保存する。
【0076】
また、通信部201は、リクエスト判定部203から、コンテンツと、コンテンツの要求元の情報(以下、「識別子」とする)とを受け取り、コンテンツを要求元に送信する。
【0077】
また、通信部201は、他の装置との間で、コンテンツの要求(リクエストメッセージ)を送信及び受信する。
【0078】
また、通信部201は、受信したリクエストメッセージを、リクエストメッセージ処理部204に渡す。
【0079】
ここで、リクエストメッセージは、1つ又は複数のフィールドを含む。各フィールドは、フィールド情報として、フィールド番号121と、パラメータ名122と、その値(パラメータ値123)とを含む。なお、リクエストメッセージは、以下で説明するフィールド以外のフィールドを含んでもよい。
【0080】
図3は、以下の説明に用いるリクエストメッセージの作成に用いられるリクエストメッセージのフォーマット110の一例を示す図である。
【0081】
図3に示されているように、リクエストメッセージのフォーマット110は、リクエストメッセージのフィールドを示すフィールド番号121と、そのフィールドの名称であるパラメータ名122とを含む。図3に示されているリクエストメッセージのフォーマット110は、フィールドとして、リクエストメッセージを要求(送信)した装置(以下、「要求元」と呼ぶ)を識別する情報(識別子)と、リクエスト条件と、要求元保存済コンテンツとを含む。
【0082】
フィールド番号121がFのフィールド(以下、「フィールドF」と呼ぶ。他のフィールドも同様とする。)は、リクエストメッセージを要求(送信)した装置(要求元)を識別する情報(識別子)である。要求元の識別子は、要求元に対するコンテンツの送信を実行できる情報であれば、特に制限されない。例えば、要求元の識別子は、要求元の装置のポート番号、IPアドレス、MAC(Media Access Control)アドレス、又は、独自に設定したアドレス若しくは名称でもよい。
【0083】
フィールドF及びFは、リクエストの対象となるコンテンツの範囲を示す情報(リクエスト条件)である。図3は、一例として、コンテンツを範囲(例えば、関心の対象となるリクエストが存在する範囲(エリア)の中心位置と有効範囲)を示す。ただし、リクエスト条件は、これに限られる必要はない。例えば、リクエスト条件は、コンテンツ名とコンテンツの生成装置との組合せでもよい。さらに、リクエスト条件は、2つのフィールドに限られる必要はない。リクエスト条件のフィールドは、1つでもよく、2つを超えてもよい。
【0084】
フィールドFは、要求元が既に所有(保存)しているコンテンツの情報を示す情報(要求元保存済コンテンツ)である。要求元保存済コンテンツは、一般的に複数となる場合が多いため、フィールドFは、複数の情報を保存できる形式を備えることが望ましい。例えば、フィールドFは、表(リスト)形式又はデータベース形式のデータである。以下では、このフィールドFのリストは、コンテンツの識別子のリストとする。また、要求元保存済コンテンツに含まれるコンテンツの情報は、コンテンツを一意に識別できればよい。例えば、コンテンツの情報は、コンテンツの識別子でもよい。つまり、要求元保存済コンテンツは、コンテンツ識別子のリストでもよい。
【0085】
図2を参照した説明に戻る。
【0086】
通信部201は、リクエストメッセージ処理部204が生成又は更新したリクエストメッセージを、転送経路における次の装置に送信する。
【0087】
なお、既に説明したが、本実施形態における転送経路は、特に制限されない。そのため、通信部201は、例えば、リクエストメッセージを転送する装置を、ネットワーク250内からランダムに選択してもよい。あるいは、通信部201は、所定の範囲内の装置からランダムに、リクエストメッセージを転送する装置を選択してもよい。
【0088】
コンテンツ保存部202は、コンテンツを保存する。より詳細には、コンテンツ保存部202は、次のように、コンテンツを保存する。
【0089】
コンテンツ保存部202は、通信部201が受信したコンテンツ(コンテンツの実体)を、保存する。コンテンツ保存部202は、コンテンツ(コンテンツの実体)とコンテンツの識別子とを関連付けて保存することが望ましい。
【0090】
また、コンテンツ保存部202は、リクエスト判定部203からの依頼に対し、保存しているコンテンツ又はコンテンツの識別子を渡す。コンテンツ保存部202は、複数のコンテンツ又はコンテンツ識別子を渡す場合、リスト形式を用いてもよい。
【0091】
リクエスト判定部203は、コンテンツ保存部202が保持するコンテンツにおいて、リクエストメッセージに含まれるリクエスト条件を満足するコンテンツがあるか否かを判定する。より詳細には、リクエスト判定部203は、次のような動作(機能)を実行する。
【0092】
リクエスト判定部203は、リクエストメッセージ処理部204から、リクエストメッセージに含まれる要求元の識別子と、リクエスト条件と、要求元保存済コンテンツとを受け取る。
【0093】
そして、リクエスト判定部203は、コンテンツ保存部202が保存するコンテンツに、リクエスト条件を満たし、かつ、要求元保存済コンテンツに含まれないコンテンツがあるか否かを判定する。
【0094】
コンテンツがある場合、リクエスト判定部203は、そのコンテンツと、要求元の識別子とを通信部201に渡す。さらに、リクエスト判定部203は、そのコンテンツを示す情報(例えば、識別子)をリクエストメッセージ処理部204に返す。
【0095】
ただし、リクエスト判定部203は、そのコンテンツの情報を、要求元保存済コンテンツに追加(更新)して、要求元保存済コンテンツをリクエストメッセージ処理部204に返してもよい。この場合、リクエストメッセージ処理部204は、後ほど説明する要求元保存済コンテンツを更新する処理を省略できる。
【0096】
コンテンツがない場合、リクエスト判定部203は、リクエストメッセージ処理部204に、コンテンツがないことを通知する。なお、リクエスト判定部203が、要求元保存済コンテンツを更新する場合、リクエスト判定部203は、受信した要求元保存済コンテンツを更新しないでリクエストメッセージ処理部204に返却する。
【0097】
リクエスト判定部203の動作について、より具体的な動作の例を用いて説明する。
【0098】
なお、以下の説明の前提として、リクエスト判定部203は、要求元の識別子として「S」、リクエスト条件の一例として「中心位置=(x,y)、有効範囲=r」、要求元保存済コンテンツとして「C」を受信したとする。また、コンテンツ保存部202は、条件を満足するコンテンツとして、コンテンツC及びCを保存しているとする。
【0099】
リクエスト判定部203は、リクエストメッセージ処理部204から、上記の情報を受けると、コンテンツ保存部202からリクエスト条件を満たすコンテンツを取り出す。
【0100】
ここで、まず、リクエスト条件の判定について説明する。
【0101】
一例として、リクエスト判定部203におけるリクエスト条件「中心位置=(x,y)、有効範囲=r」を満たすか否かの判定の処理を説明する。
【0102】
ここで、i番目のコンテンツCの位置を(x,y)とする。すると、コンテンツCがリクエスト条件を満足する場合、次に示す数式1が成立する。つまり、リクエスト判定部203は、数式1を用いて、コンテンツCがリクエスト条件を満足するか否かを判定できる。
【0103】
[数式1]
(x−x+(y−y≦r
ただし、リクエスト条件は、上記の例に限る必要はない。リクエスト条件は、例えば、コンテンツ名若しくは種類などコンテンツに関する情報、生成時間若しくは更新時間などの時間に関する情報、又は、生成装置若しくは更新装置などの装置に関する情報などでもよい。
【0104】
例えば、リクエスト条件が、コンテンツの生成時間の場合について説明する。リクエスト条件が、時刻tからtまでに生成されたコンテンツとする。そして、コンテンツCの生成時間がtとする。この場合、リクエスト判定部203は、tが、次に示す数式2を満足するか否かを基に、コンテンツCがリクエスト条件を満足するか否かを判定できる。
【0105】
[数式2]
≦t≦t
また、リクエスト条件は、複数の条件を含んでもよい。リクエスト条件が複数の条件を含む場合、リクエスト判定部203は、リクエスト条件に含まれる全ての条件を満足(完全マッチング)するコンテンツを、リクエスト条件を満足するコンテンツと判定してもよい。あるいは、リクエスト判定部203は、一つ又は一部の条件を満足するコンテンツを、条件を満足するコンテンツと判定してもよい。
【0106】
そして、リクエスト判定部203は、上記のような動作を基に、リクエスト条件を満たすコンテンツを、コンテンツC及びCと判定する(図1を参照)。そこで、リクエスト判定部203は、コンテンツ保存部202から、コンテンツC及びCを取り出す。
【0107】
そして、リクエスト判定部203は、取り出したコンテンツC及びCが、要求元保存済コンテンツに含まれるか否かを判定する。
【0108】
今の場合、コンテンツC及びCは、どちらも要求元保存済コンテンツ(C)と一致しない。
【0109】
そこで、リクエスト判定部203は、コンテンツC及びCと、要求元の識別子とを、通信部201に渡す。通信部201は、コンテンツC及びCを、要求元に送信する。
【0110】
また、リクエスト判定部203は、コンテンツC及びCに関する情報(例えば、コンテンツの識別子)をリクエストメッセージ処理部204に戻す。なお、リクエスト判定部203は、要求元保存済コンテンツにコンテンツC及びCに関する情報を更新(追加)して、更新後の要求元保存済コンテンツをリクエストメッセージ処理部204に戻してもよい。
【0111】
リクエストメッセージ処理部204は、リクエストメッセージを生成又は更新する。より詳細には、リクエストメッセージ処理部204は、次のような動作(機能)を実行する。
【0112】
要求元の装置の場合、リクエストメッセージ処理部204は、自装置の識別子と、リクエスト条件と、コンテンツ保存部202内に保存済のコンテンツとを基に、リクエストメッセージを作成(生成)する。リクエストメッセージ処理部204は、コンテンツ保存部202内に保存済みのコンテンツに関する情報の取得を、リクエスト判定部203に依頼してもよい。つまり、本実施形態に係るリクエストメッセージ処理部204は、保存済みのコンテンツに関する情報を含むリクエストメッセージを作成(生成)する。そして、リクエストメッセージ処理部204は、作成したリクエストメッセージを通信部201に渡す。通信部201は、作成されたリクエストメッセージを転送経路の次の装置に送信する。
【0113】
要求元の装置でない場合、つまり、中継装置の場合、リクエストメッセージ処理部204は、次に説明するように、受信したリクエストメッセージを更新する。
【0114】
すなわち、リクエストメッセージ処理部204は、リクエスト判定部203に、受信したリクエストメッセージに含まれる要求元の識別子と、リクエスト条件と、要求元保存済コンテンツとを渡す。
【0115】
そして、リクエストメッセージ処理部204は、リクエスト判定部203からの応答を待つ。
【0116】
リクエスト判定部203から、コンテンツがないとの応答を受信した場合、リクエストメッセージ処理部204は、受信したリクエストメッセージを更新しないで、通信部201に送る。この場合、通信部201は、受信したリクエストメッセージを、更新しないで、次の装置に送信する。つまり、要求元に送信するコンテンツ(リクエストメッセージに含まれるリクエスト条件を満足し、かつ、要求元に保存されていないコンテンツ)を保存していない場合、情報処理装置200は、リクエストメッセージを転送経路の次の装置に転送する。
【0117】
リクエスト判定部203から、コンテンツに関する情報(例えば、識別子)を受信した場合、リクエストメッセージ処理部204は、リクエスト判定部203から受信したコンテンツに関する情報(例えば、識別子)を、要求元保存済コンテンツに加える。つまり、リクエストメッセージ処理部204は、リクエストメッセージを更新する。
【0118】
そして、リクエストメッセージ処理部204は、更新後のリクエストメッセージを通信部201に送る。通信部201は、リクエストメッセージを次の装置に送信する。
【0119】
つまり、自装置が保存するコンテンツを要求元に送信しても、リクエストメッセージ処理部204は、次の装置に、更新後のリクエストメッセージを転送する。
【0120】
次に、図面を参照して、リクエストメッセージ処理部204の具体的な動作の一例を説明する。
【0121】
まず、要求元(図1に示されている二重丸の情報処理装置200)の場合について説明する。
【0122】
リクエストメッセージ処理部204は、自装置上で動作するアプリケーション、又は、図示しない外部の装置から、コンテンツの要求を受信する。リクエストメッセージ処理部204は、要求を基にリクエストメッセージを作成(生成)する。ここでは、一例として、リクエストメッセージ処理部204は、既に説明した図3に示されているリクエストメッセージのフォーマット110を基に、リクエストメッセージを作成する。また、リクエストメッセージの各フィールドの値として、要求元の識別子を「S」、リクエスト条件を「(x,y)」及び「r」とする。また、コンテンツ保存部202が、リクエスト条件を満足するコンテンツとして、コンテンツCを含むとする。
【0123】
図4は、今の場合に、情報処理装置200が、最初に作成するリクエストメッセージ111の一例を示す図である。リクエストメッセージ111は、既に説明した通り、フィールド番号121と、パラメータ名122と、パラメータ値123とを含む。
【0124】
次に、リクエストメッセージ処理部204は、リクエスト判定部203に、要求元の識別子と、リクエスト条件と、要求元保存済コンテンツ(今の場合、空リスト)とを渡す。
【0125】
そして、リクエストメッセージ処理部204は、リクエスト判定部203から、要求元保存済コンテンツに追加するコンテンツCを受信する。そして、リクエストメッセージ処理部204は、要求元保存済コンテンツにCを追加して、リクエストメッセージを更新する。
【0126】
図5は、このときのリクエストメッセージ112の一例を示す図である。
【0127】
リクエストメッセージ処理部204は、図5に示されているリクエストメッセージ112を通信部201に渡す。通信部201は、リクエストメッセージ112を、次の装置に送信する。
【0128】
次に、リクエストメッセージを受信した情報処理装置200(図1の灰色の円の情報処理装置200)の場合について説明する。
【0129】
今の場合、コンテンツ保存部202は、リクエスト条件を満足するコンテンツとして、コンテンツC及びCとを含む。
【0130】
リクエストメッセージ処理部204は、通信部201を介して、図5に示されているリクエストメッセージ112を受信する。そして、リクエストメッセージ処理部204は、リクエスト判定部203に、図5に示されている要求元の識別子と、リクエスト条件と、要求元保存済コンテンツとを渡す。そして、リクエストメッセージ処理部204は、リクエスト判定部203から、コンテンツC及びCの情報を受信する。リクエストメッセージ処理部204は、リクエストメッセージの要求元保存済コンテンツにコンテンツC及びCの情報を追加して、リクエストメッセージを更新する。
【0131】
図6は、このときのリクエストメッセージ113の一例を示す図である。
【0132】
リクエストメッセージ処理部204は、図6に示されているリクエストメッセージ113を、通信部201に渡す。通信部201は、リクエストメッセージ113を次の装置に送信する。
【0133】
また、通信部201は、コンテンツを要求元に送信する。
【0134】
つまり、情報処理装置200は、要求元が保持していないコンテンツを保持する場合、そのコンテンツを要求元に送信する。そして、情報処理装置200は、送信したコンテンツをリクエストメッセージの保存済コンテンツに追加して、リクエストメッセージを更新する。そして、情報処理装置200は、更新したリクエストメッセージを次の装置に転送する。
【0135】
例えば、図1の黒塗り円の情報処理装置200は、残りのコンテンツC及びCを含む。そのため、この情報処理装置200(図1の黒塗り円の情報処理装置200)が、リクエストメッセージを受信すると、コンテンツC及びCに関する情報をリクエストメッセージの要求元保存済コンテンツリストに追加する。
【0136】
図7は、このときのリクエストメッセージ114の一例を示す図である。リクエストメッセージ114は、要求元保存済コンテンツに、全てのコンテンツ(CないしC)の識別子を含む。
【0137】
一方、要求元が保持していないコンテンツを保持していない場合、情報処理装置200は、リクエストメッセージを更新せず、受信したリクエストメッセージを次の装置に転送する。
【0138】
例えば、図1の左側上の情報処理装置200は、受信したリクエストメッセージをそのまま転送する。
【0139】
あるいは、コンテンツC及びCを送信後にリクエストメッセージを受信した場合、左側中央の情報処理装置200は、要求元に送信すべきコンテンツがなくなっているため、受信したリクエストメッセージをそのまま転送する。
【0140】
[動作の説明]
次に、図面を参照して、情報処理装置200の動作について説明する。
【0141】
まず、情報処理装置200が、要求元の場合について説明する。
【0142】
図8は、第1の実施形態に係る情報処理装置200が要求元の場合の動作の一例を示すフローチャートである。
【0143】
情報処理装置200の通信部201は、図示しない外部の装置、又は、自装置上で動作するアプリケーションなどから、コンテンツの要求を受信する。この要求は、少なくとも要求元の識別子(今の場合、自装置)とリクエスト条件とを含む。通信部201は、リクエストをリクエストメッセージ処理部204に送信する。
【0144】
リクエストメッセージ処理部204は、リクエストを基に、リクエストメッセージを作成(生成)する(ステップS301)。
【0145】
リクエストメッセージ処理部204は、リクエストメッセージに含まれる要求元の識別子と、リクエスト条件と、要求元保存済リクエストとを、リクエスト判定部203に送信する。リクエスト判定部203は、リクエスト条件を満足するコンテンツの情報を、リクエストメッセージ処理部204に戻す。つまり、リクエストメッセージ処理部204は、リクエスト判定部203から、要求元が要求したコンテンツの情報を取得する(ステップS302)。
【0146】
リクエストメッセージ処理部204は、受信したコンテンツの情報を基に、ステップS301で作成したリクエストメッセージを更新する(ステップS303)。なお、リクエスト条件を満足するコンテンツがない場合、リクエストメッセージ処理部204は、リクエストメッセージを更新しない。つまり、リクエストメッセージ処理部204は、要求元保存済コンテンツを、空のままとする。
【0147】
そして、リクエストメッセージ処理部204は、通信部201に更新したリクエストメッセージを渡す。通信部201は、次の通信端末にリクエストメッセージを送信する(ステップS304)。
【0148】
なお、情報処理装置200は、ステップS301とステップS302の順番を入れ替えてもよい。あるいは、情報処理装置200は、ステップS301とステップS302と動作を並列に実行してもよい。
【0149】
次に、情報処理装置200が、リクエストメッセージを中継する場合について説明する。
【0150】
図9は、第1の実施形態に係る情報処理装置200がリクエストメッセージを中継する場合の動作の一例を示すフローチャートである。
【0151】
情報処理装置200のリクエストメッセージ処理部204は、通信部201を介してリクエストメッセージを受信する(ステップS305)。
【0152】
リクエストメッセージ処理部204は、リクエスト判定部203に、要求元の識別子と、リクエスト条件と、要求元保存済コンテンツとを送る。リクエスト判定部203は、リクエスト条件を満足し、要求元が保存していないコンテンツがあるか否かを判定する(ステップS306)。
【0153】
コンテンツがない場合(ステップS306でNo)、情報処理装置200は、ステップS309に進む。
【0154】
コンテンツがある場合(ステップS306でYes)、リクエスト判定部203は、通信部201を介して、コンテンツを要求元に送信する(ステップS307)。
【0155】
次に、リクエストメッセージ処理部204が、リクエストメッセージを更新する(ステップS308)。
【0156】
そして、リクエストメッセージ処理部204は、通信部201を介して、リクエストメッセージを次の端末に送信(転送)する(ステップS309)。
【0157】
次に、図1に示されているネットワーク250の全体の動作を説明する。
【0158】
要求元は、図1の左側下の二重丸の情報処理装置200(以下、「第1の装置」と呼ぶ)とする。第1の装置(要求元)は、コンテンツをリクエストするため、リクエストメッセージを作成(生成)する(図4)。さらに、第1の装置は、自装置が保持するコンテンツを基にリクエストメッセージを更新する(図5)。そして、第1の装置は、更新されたリクエストメッセージを、次の装置に送信する。今の場合、次の装置は、左側中央の灰色の円の情報処理装置200(以下、「第2の装置」と呼ぶ)とする。なお、今の場合、第1の装置は、コンテンツCを保存している。そのため、ここで送信されるコンテンツリクエストは、図5に示されているように、要求元保存済コンテンツにコンテンツCを含む。
【0159】
第2の装置は、受信したリクエストメッセージに対応したコンテンツを保存しているか否かを判定する。今の場合、第2の装置は、コンテンツC及びCを保存している。そこで、第2の装置は、コンテンツC及びCを要求元(第1の装置)に送信する。さらに、第2の装置は、送信したコンテンツC及びCを基に、リクエストメッセージを更新する(図6)。そして、第2の装置は、更新されたリクエストメッセージを次の装置に転送する。今の場合、次の装置は、左側上の情報処理装置200(以下、「第3の装置」と呼ぶ)とする。
【0160】
第3の装置は、受信したリクエストメッセージに対応したコンテンツを保存しているか否かを判定する。今の場合、第3の装置は、コンテンツを保存していない。そこで、第3の装置は、リクエストメッセージを次の装置に転送する。今の場合、次の装置は、右側上の黒塗り円の情報処理装置200(以下、「第4の装置」と呼ぶ)とする。
【0161】
第4の装置は、受信したリクエストメッセージに対応したコンテンツを保存しているか否かを判定する。今の場合、コンテンツCないしCが対応する。ただし、C、C及びCは、要求元保存済コンテンツに含まれる。そこで、第4の装置は、保存しているコンテンツCないしCにおいて、コンテンツC及びCを要求元(第1の装置)に送信する。そして、第4の装置は、リクエストメッセージを更新する(図7)。そして、第4の装置は、更新したリクエストメッセージを次の装置に転送する。今の場合、次の装置は、右側中央の情報処理装置200(以下、「第5の装置」と呼ぶ)とする。
【0162】
第5の装置は、コンテンツC及びCを保存する。しかし、コンテンツC及びCは、要求元保存済コンテンツに含まれる。つまり、第5の装置は、要求元(第1の装置)に送信するコンテンツを保存していないため、リクエストメッセージを次の装置に転送する。今の場合、次の装置は、右側下の情報処理装置200(以下、「第6の装置」と呼ぶ)とする。
【0163】
第6の装置は、要求元(第1の装置)に送信するコンテンツを保存していない。そのため、第6の装置は、リクエストメッセージを次の装置に転送する。今の場合、次の装置は、例えば、左側下の情報処理装置200(要求元)である。
【0164】
なお、後ほど説明するように、本実施形態において、リクエストメッセージは、所定の時点で廃棄される。それまでは、リクエストメッセージは、要求元を含め、ネットワーク250に含まれる情報処理装置200において転送される。そのため、要求元が、リクエストメッセージを受信した場合、要求元は、リクエストメッセージを次の装置に転送する。このように、情報処理装置200は、要求元となった場合でも、リクエストメッセージの受信、及び、中継を実行する。
【0165】
このように、本実施形態の情報処理装置200を基に構成されているネットワーク250に含まれる要求元は、コンテンツを受信できる。さらに、要求元は、各コンテンツに関して、最大でも各1回の受信動作を基に受信できる。ここで最大でも各1回となるのは、1回の受信動作で複数のコンテンツを受信する場合もあるためである。つまり、要求元の受信動作の回数は、コンテンツの数より少ない場合もあるからである。
【0166】
なお、第2の装置及び第4の装置が、要求元にコンテンツを送信する経路は、リクエストメッセージの転送経路と同じでもよく、異なっていてもよい。
【0167】
リクエストメッセージは、所定の時点で廃棄される必要がある。さもないと、不必要なリクエストメッセージが、長期に、ネットワーク上を行き来することとなる。ただし、本実施形態の情報処理装置200が、リクエストメッセージを廃棄する必要はない。例えば、図示しない装置が、リクエストメッセージの寿命(例えば、インターネットプロトコルにおけるホップ数)を判定して、リクエストメッセージを廃棄してもよい。あるいは、図示しない装置が、要求元がリクエストメッセージを送信してからの時間を基に、リクエストメッセージを廃棄してもよい。あるいは、図示しない装置が、リクエストメッセージに含まれるコンテンツ条件と要求元保存済コンテンツとを基に、必要がなくなったリクエストメッセージを廃棄してもよい。
【0168】
ただし、本実施形態に係る情報処理装置200が、上記の判定を基に、リクエストメッセージを廃棄してよい。
【0169】
[効果の説明]
第1の実施形態の効果について説明する。
【0170】
上記の説明のように、第1の実施形態に係る情報処理装置200は、複数のコンテンツを効率的に取得するとの効果を奏する。あるいは、情報処理装置200は、効率的に、複数のコンテンツを要求元に送信できるとの効果を奏する。
【0171】
その理由は、次のとおりである。
【0172】
情報処理装置200のリクエスト判定部203は、コンテンツ保存部202に保存されているコンテンツから、通信部201を介して受信したリクエストメッセージに含まれるリクエスト条件を満足するコンテンツを抽出する。さらに、リクエスト判定部203は、抽出したコンテンツの中で、リクエストメッセージに含まれる要求元保存済コンテンツに含まれないコンテンツを判定し、抽出する。ここで、要求元保存済コンテンツは、その時点で要求元が保存しているコンテンツを示す。つまり、リクエスト判定部203は、要求元が保存済みのコンテンツを送信しないようにコンテンツを判定する。そして、リクエスト判定部203は、リクエストメッセージに含まれる要求元の識別子を基に、通信部201を介して、判定結果である抽出したコンテンツを要求元に送信する。
【0173】
さらに、リクエストメッセージ処理部204が、リクエスト判定部203が判定したコンテンツを、要求元保存済コンテンツに加えてリクエストメッセージを更新する。そして、リクエストメッセージ処理部204が、更新したリクエストメッセージを、次の装置に転送する。つまり、情報処理装置200は、自装置が対象となるコンテンツを要求元に送信した場合でも、リクエストメッセージを次の装置に転送できる。
【0174】
そのため、要求元は、リクエストメッセージを1回送信すれば、各コンテンツを1回ずつ受信できる。このように、要求元は、効率的にコンテンツを取得できる。
【0175】
また、本実施形態の情報処理装置200を含むネットワーク250は、コンテンツの配置場所を管理するサーバを必要としない効果を奏する。
【0176】
その理由は、情報処理装置200は、自装置のコンテンツ保存部202が保存するコンテンツを基に動作できるためである。
【0177】
[変形例]
以上で説明した情報処理装置200は、次のように構成される。
【0178】
例えば、情報処理装置200の各構成部は、ハードウェア回路で構成されてもよい。
【0179】
また、情報処理装置200において、各構成部は、ネットワークを介して接続した複数の装置を用いて、構成されてもよい。
【0180】
また、情報処理装置200において、複数の構成部は、1つのハードウェアで構成されてもよい。
【0181】
また、情報処理装置200は、CPU(Central Processing Unit)と、ROM(Read Only Memory)と、RAM(Random Access Memory)とを含むコンピュータ装置として実現されてもよい。情報処理装置200は、上記構成に加え、さらに、入出力接続回路(IOC:Input / Output Circuit)と、ネットワークインターフェース回路(NIC:Network Interface Circuit)とを含むコンピュータ装置として実現されてもよい。
【0182】
図10は、本変形例に係る情報処理装置600の構成の一例を示すブロック図である。
【0183】
情報処理装置600は、CPU610と、ROM620と、RAM630と、内部記憶装置640と、IOC650と、NIC680とを含み、コンピュータ装置を構成している。
【0184】
CPU610は、ROM620からプログラムを読み込む。そして、CPU610は、読み込んだプログラムに基づいて、RAM630と、内部記憶装置640と、IOC650と、NIC680とを制御する。そして、CPU610を含むコンピュータは、これらの構成を制御し、図2に示されている、通信部201と、コンテンツ保存部202と、リクエスト判定部203と、リクエストメッセージ処理部204としての各機能を実現する。
【0185】
CPU610は、各機能を実現する際に、RAM630又は内部記憶装置640を、プログラムの一時記憶として使用してもよい。
【0186】
また、CPU610は、コンピュータで読み取り可能にプログラムを記憶した記憶媒体700が含むプログラムを、図示しない記憶媒体読み取り装置を用いて読み込んでもよい。あるいは、CPU610は、NIC680を介して、図示しない外部の装置からプログラムを受け取り、RAM630に保存して、保存したプログラムを基に動作してもよい。
【0187】
ROM620は、CPU610が実行するプログラム及び固定的なデータを記憶する。ROM620は、例えば、P−ROM(Programmable-ROM)又はフラッシュROMである。
【0188】
RAM630は、CPU610が実行するプログラム及びデータを一時的に記憶する。RAM630は、例えば、D−RAM(Dynamic-RAM)である。
【0189】
内部記憶装置640は、情報処理装置600が長期的に保存するデータ及びプログラムを記憶する。また、内部記憶装置640は、CPU610の一時記憶装置として動作してもよい。内部記憶装置640は、例えば、ハードディスク装置、光磁気ディスク装置、SSD(Solid State Drive)又はディスクアレイ装置である。内部記憶装置640は、コンテンツ保存部202として動作する。
【0190】
ここで、ROM620と内部記憶装置640は、不揮発性(non-transitory)の記憶媒体である。一方、RAM630は、揮発性(transitory)の記憶媒体である。そして、CPU610は、ROM620、内部記憶装置640、又は、RAM630に記憶されているプログラムを基に動作可能である。つまり、CPU610は、不揮発性記憶媒体又は揮発性記憶媒体を用いて動作可能である。
【0191】
IOC650は、CPU610と、入力機器660及び表示機器670とのデータを仲介する。IOC650は、例えば、IOインターフェースカード又はUSB(Universal Serial Bus)カードである。
【0192】
入力機器660は、情報処理装置600の操作者からの入力指示を受け取る機器である。入力機器660は、例えば、キーボード、マウス又はタッチパネルである。
【0193】
表示機器670は、情報処理装置600の操作者に情報を表示する機器である。表示機器670は、例えば、液晶ディスプレイである。
【0194】
NIC680は、ネットワークを介した図示しない外部の装置とのデータのやり取りを中継する。NIC680は、例えば、LAN(Local Area Network)カードである。NIC680は、通信部201として動作する。
【0195】
このように構成された情報処理装置600は、情報処理装置200と同様の効果を得ることができる。
【0196】
その理由は、情報処理装置600のCPU610が、プログラムに基づいて情報処理装置200と同様の機能を実現できるためである。
【0197】
<第2の実施形態>
第1の実施形態において、情報処理装置200は、他の装置が保存するコンテンツを知らない。そして、情報処理装置200は、リクエストメッセージを、重複して受信してもよい。つまり、情報処理装置200は、要求元がコンテンツを取得するまで、複数回、リクエストメッセージを受信する場合がある。
【0198】
しかし、既にリクエストメッセージを受け取った情報処理装置200は、コンテンツ保存部202が保存するコンテンツに変更がない場合、再度リクエストメッセージを受信する必要がない。そこで、本実施形態に係る情報処理装置400は、次の装置(転送先の装置)として、既にリクエストメッセージを受け取った情報処理装置400を選択しない仕組みを備えている。
【0199】
なお、本実施形態の情報処理装置400は、リクエストメッセージを複数回受信してもよい。つまり、情報処理装置200と情報処理装置400とは、ネットワーク250において、共存可能である。
【0200】
[構成の説明]
まず、本実施形態に係る情報処理装置400の構成を説明する。
【0201】
図11は、本実施形態に係る情報処理装置400の構成の一例を示すブロック図である。ただし、図面中の矢印の方向は、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
【0202】
図11に示されているように、情報処理装置400は、情報処理装置200と比較して、通信部201及びリクエストメッセージ処理部204に換えて、通信部401及びリクエストメッセージ処理部404を含む点で異なる。なお、情報処理装置400は、図10に示されているコンピュータを用いて構成されてもよい。
【0203】
図12は、第2の実施形態に係る情報処理装置400が用いるリクエストメッセージのフォーマット115の一例を示す図である。
【0204】
つまり、情報処理装置400は、リクエストメッセージのフォーマットとして、図3に示されるフォーマット110に換えて、図12に示されているフォーマット115を用いる。
【0205】
以下、第1の実施形態の同様の構成及び動作の説明を省略し、本実施形態に特有の構成及び動作を説明する。
【0206】
図12に示されているように、本実施形態に係るリクエストメッセージのフォーマット115は、フォーマット110のフィールドに加え、転送済装置に関するフィールド(以下、「フィールドF」と呼ぶ)を含む。
【0207】
通信部401は、第1の実施形態に係る通信部201と同様に動作する。ただし、通信部401は、次の装置を選択する場合に、選択範囲にリクエストメッセージのフィールドFに含まれる転送済装置に含まれる情報処理装置400を含めない。つまり、通信部401は、転送済装置以外の装置に、リクエストメッセージを転送する。
【0208】
リクエストメッセージ処理部404は、第1の実施形態のリクエストメッセージ処理部204と同様に動作する。さらに、リクエストメッセージ処理部404は、リクエストメッセージの転送済装置(フィールドF)に自装置を示す情報(例えば、自装置の識別子)を追加する。
【0209】
つまり、情報処理装置400は、転送するリクエストメッセージに自装置を示す情報を追加する。そして、情報処理装置400は、リクエストメッセージに含まれている装置を除いて、リクエストメッセージを転送する装置を選択し、リクエストメッセージを転送する。
【0210】
なお、リクエストメッセージ処理部404は、転送済装置のフィールドを含まないリクエストメッセージを受信した場合、転送済装置のフィールドを追加して、リクエストメッセージを更新してもよい。あるいは、リクエストメッセージ処理部404は、フィールドを追加しないで、第1の実施形態と同様に動作してもよい。
【0211】
また、情報処理装置400は、次の装置として選択できる全ての装置が、転送済装置に含まれる場合、リクエストメッセージを転送しなくてもよい。つまり、その場合、情報処理装置400は、リクエストメッセージを廃棄してもよい。
【0212】
あるいは、情報処理装置400は、転送済装置の中から所定の手順(例えば、ランダム又はラウンドロビン)を用いて、転送先となる次の装置を選択してもよい。この処理を用いると、情報処理装置400は、コンテンツ条件に含まれるコンテンツが変化する可能性がある場合にも対応可能となる。
【0213】
[効果の説明]
第2の実施形態の効果について説明する。
【0214】
以上のとおり、第2の実施形態に係る情報処理装置400は、第1の実施形態の情報処理装置200の効果に加え、より効率的な動作を実現する効果を奏する。
【0215】
その理由は、次のとおりである。情報処理装置400は、リクエストメッセージの処理を実行した際に、自装置の情報をリクエストメッセージに含めて転送する。そして、情報処理装置400は、リクエストメッセージを転送する際に、処理済みの装置を避けて、リクエストメッセージを転送する。そのため、リクエストメッセージを処理した情報処理装置400は、それ以降は、リクエストメッセージの受信をしないためである。つまり、情報処理装置400は、まだ要求元に送信されていないコンテンツを保存する可能性がある情報処理装置400に、リクエストメッセージを転送するためである。言い換えると、情報処理装置400は、不必要なリクエストメッセージの転送を削減するためである。
【0216】
<第3の実施形態>
第1の実施形態の情報処理装置200及び第2の実施形態の情報処理装置400は、コンテンツを保存する他の装置を知らなかった。これに対し、図13に示す第3の実施形態では、要求元となる情報処理装置500は、コンテンツリクエストのリクエスト条件を満たすコンテンツの保存を担当する装置を知っている。つまり、情報処理装置500は、予め、コンテンツの配置方法又は次に説明する担当装置を知っている。ただし、本実施形態においても、コンテンツは、キャッシュ機能を実現するために、担当装置以外の装置に保存されてもよい。
【0217】
本実施形態において、コンテンツ配置方法は、予め、以下に示すルールに基づいて決められている。
【0218】
[コンテンツの配置ルール]
(1)所定の条件を満たすコンテンツは、そのコンテンツを担当する情報処理装置500(以下、「担当装置」と呼ぶ)が決まっている。
【0219】
(2)担当装置は、上記の所定の条件を満たすコンテンツを、必ず保存している。
【0220】
要求元は、このルールを基に、コンテンツリクエストのリクエスト条件を満たすコンテンツを保存する担当装置を識別できる。
【0221】
次に、上記のルールを満たすルールの一例を示す。
【0222】
[ルール1]
コンテンツは、コンテンツの生成位置に最も近い位置の情報処理装置500に配置されている。ただし、コンテンツは、コンテンツの生成位置の情報を含む。なお、位置情報は、ある程度の範囲の誤差を含む。そのため、最も近い位置の情報処理装置500が、複数となる場合もある。その場合、最も近い位置となる全ての情報処理装置500が、コンテンツを保持してもよい。あるいは、いずれか1台又は一部の情報処理装置500が、コンテンツを保持してもよい。
【0223】
つまり、このルールに従うと、全ての位置に対して、少なくとも1台の担当装置が決定される。そして、生成されたコンテンツは、必ず、少なくとも生成された位置の最も近い担当装置に保存されている。
【0224】
なお、以下の説明において、全ての情報処理装置500において、予め、担当装置の位置情報が、共有されているとする。さらに、リクエストメッセージの転送経路は、要求元から、担当装置までの経路となる。そして、情報処理装置500は、少なくとも、転送元がリクエストメッセージを送信する前に、転送経路を共有している。
【0225】
なお、本実施形態のルールは、上記ルール1に限る必要はない。例えば、コンテンツは、位置情報として、生成位置情報ではなく、ランダムに選択された位置情報を含んでもよい。
【0226】
また、ルールは、位置情報に限らず、コンテンツの名若しくは種類などコンテンツに関する情報、生成時間若しくは更新時間などの時間に関する情報、又は、生成装置若しくは更新装置などの装置に関する情報などを用いてもよい。
【0227】
例えば、ルールは、「コンテンツの生成装置が担当装置」というルールでもよい。このルールにおいても、各コンテンツに対して、必ず1台の担当装置(コンテンツ生成装置)が、決まり、少なくともその担当装置が、コンテンツを保存している。また、ルールは、「所定の時間帯に生成されたコンテンツは、所定の担当装置が保存する」というルールでもよい。このルールの場合、時刻帯を指定すると、担当端末が、特定される。
【0228】
なお、本実施形態の情報処理装置500は、情報処理装置200及び情報処理装置400と、ネットワーク250に共存可能である。
【0229】
[構成の説明]
次に、第3の実施形態に係る情報処理装置500の構成について説明する。
【0230】
図13は、第3の実施形態に係る情報処理装置500の構成の一例を示すブロック図である。ただし、図面中の矢印の方向は、一例を示すものであり、ブロック間の信号の向きを限定するものではない。
【0231】
図13に示されているように、情報処理装置500は、情報処理装置200と比較して、通信部201及びリクエストメッセージ処理部204に換えて、通信部501及びリクエストメッセージ処理部504を含む点で異なる。さらに、情報処理装置500は、担当装置判断部505を含む。なお、情報処理装置500は、図10に示されているコンピュータを用いて構成されてもよい。また、情報処理装置500は、第2の実施形態におけるリクエストメッセージの転送済装置に対応する機能を含んでもよい。
【0232】
図14は、第3の実施形態に係る情報処理装置500が用いるリクエストメッセージのフォーマット116の一例を示す図である。
【0233】
情報処理装置500は、リクエストメッセージのフォーマットとして、図3に示されるフォーマット110に換えて、図14に示されているフォーマット116を用いる。
【0234】
図14に示されているように、本実施形態に係るリクエストメッセージのフォーマット116は、フォーマット110のフィールドに加え、担当装置に関するフィールド(以下、「フィールドF」と呼ぶ)を含む。
【0235】
以下、第1及び第2の実施形態と同様の構成及び動作の説明を省略し、本実施形態に特有の構成及び動作を説明する。
【0236】
通信部501は、第1の実施形態の通信部201と同様に動作する。ただし、通信部501は、リクエストメッセージを次の装置に送信する際に、既に説明した担当装置までの転送経路に沿って、次の装置を選択する。なお、次の装置を決める方法の一例として、担当装置を宛先としたルーティングテーブルにおける予め決められた次の装置(「Next hop」)を選択する方法がある。
【0237】
リクエストメッセージ処理部504は、第1の実施形態のリクエストメッセージ処理部204の動作に加え、担当装置(フィールドF)に対応した動作を実行する。
【0238】
要求元としてリクエストメッセージを作成する場合、リクエストメッセージ処理部504は、リクエストメッセージの中に、第1の実施形態のフィールドに加え、担当装置の情報(例えば、識別子)を保存するフィールド(フィールドF)を作成する。そして、リクエストメッセージ処理部504は、作成したフィールドFに担当装置の情報を設定する。
【0239】
情報処理装置500が、リクエストメッセージを受信した場合、リクエストメッセージ処理部504は、担当装置の情報を担当装置判断部505に送信し、自装置が、担当装置であるか否かの判定を依頼する。
【0240】
自装置が担当装置でない場合、リクエストメッセージ処理部504は、第1の実施形態のリクエストメッセージ処理部204と同様に動作する。
【0241】
一方、自装置が担当装置の場合、リクエストメッセージ処理部504は、リクエストメッセージを転送しない。これは、自装置が、担当装置の場合、対象となるコンテンツを保存しているためである。
【0242】
担当装置判断部505は、リクエストメッセージ処理部504の依頼を基に、自装置が、担当装置であるか否かを判断する。担当装置判断部505は、この判断に、既に説明したルールを用いればよい。
【0243】
なお、リクエストメッセージ処理部504は、担当装置のフィールドを含まないリクエストメッセージを受信した場合、第1の実施形態と同様に動作すればよい。
【0244】
[動作の説明]
次に、第3の実施形態に動作について、図面を参照して説明する。
【0245】
なお、第1の実施形態と同様の動作については、説明を省略する。
【0246】
図8を参照して説明した要求元としての動作は、フィールドが追加されていることを除いて、第1の実施形態と同様のため、詳細な動作の説明を省略する。
【0247】
図15は、情報処理装置500がリクエストメッセージを中継する場合の動作の一例を示すフローチャートである。図15において、図9と同じ動作には同じ符号を付し、その詳細な説明を省略する。また、図15のステップS708及びS709と、図9のステップS308及びS309との差は、取り扱うリクエストメッセージが含むフィールドが異なる点である。そして、これらのステップは、そのフィールドの情報を操作しない。つまり、図15のステップS708及びS709は、図9のステップS308及びS309と同様に動作する。そのため、ステップS708及びS709の詳細な説明を省略する。
【0248】
リクエストメッセージ処理部504は、リクエストメッセージを受信(ステップS305)すると、担当装置判断部505を用いて、自装置が、リクエストメッセージに含まれる担当装置であるか否かを判断する(ステップS710)。
【0249】
自装置が担当装置でない場合(ステップS710でNo)、リクエストメッセージ処理部504は、既に説明したように、第1の実施形態の同様の動作を実行する。
【0250】
自装置が担当装置の場合(ステップS710でYes)、情報処理装置500は、図9のステップS306と同様に、通信部501から送信する対象となるコンテンツを保存しているか否かを判定する。
【0251】
コンテンツがない場合(ステップS306でNo)、情報処理装置500は、動作を終了する。
【0252】
コンテンツがある場合(ステップS306でYes)、情報処理装置500は、図9のステップS307と同様にコンテンツを送信する。そして、情報処理装置500は、処理を終了する。
【0253】
なお、情報処理装置500は、ステップS710における担当装置の判断を、コンテンツの判定の後に、実行してもよい。
【0254】
図16は、第3の実施形態の情報処理装置500の動作の別の一例を示すフローチャートとである。
【0255】
図16において、情報処理装置500は、コンテンツの処理の後に、担当装置の判断を実行する。
【0256】
[効果の説明]
第3の実施形態の効果について説明する。
【0257】
以上の説明のように、第3の実施形態に係る情報処理装置500は、第1の実施形態の効果に加え、より効率的な動作を実現する効果を奏する。
【0258】
その理由は、次のとおりである。情報処理装置500は、対象となるコンテンツの担当装置を基に決定された転送経路に沿って、リクエストメッセージを転送する。つまり、情報処理装置500は、コンテンツの所得に適した転送経路を用いる。そのため、情報処理装置500は、コンテンツの取得までの時間を短縮する。
【0259】
また、情報処理装置500は、担当装置の場合に、リクエストメッセージの転送を行わないためである。つまり、情報処理装置500は、不必要なリクエストメッセージの転送を削減するためである。
【0260】
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成及び詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【0261】
この出願は、2014年12月9日に出願された日本出願特願2014−249058を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【0262】
110 フォーマット
111 リクエストメッセージ
112 リクエストメッセージ
113 リクエストメッセージ
114 リクエストメッセージ
115 フォーマット
116 フォーマット
121 フィールド番号
122 パラメータ名
123 パラメータ値
200 情報処理装置
201 通信部
202 コンテンツ保存部
203 リクエスト判定部
204 リクエストメッセージ処理部
250 ネットワーク
400 情報処理装置
401 通信部
404 リクエストメッセージ処理部
500 情報処理装置
501 通信部
504 リクエストメッセージ処理部
505 担当装置判断部
600 情報処理装置
610 CPU
620 ROM
630 RAM
640 内部記憶装置
650 IOC
660 入力機器
670 表示機器
680 NIC
700 記憶媒体
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17