JP2015015668A - 名前解決装置及び方法、名前解決システム、並びにコンピュータ・プログラム - Google Patents

Abstract

【課題】 コンテンツの所在変更に対応することを可能としつつ、端末がコンテンツの所在情報を得るまでの効率が良く、また、実現可能性も高い名前解決装置などを提供する。【解決手段】 本発明の名前解決装置は、コンテンツの名前情報と、前記コンテンツの所在情報と、前記名前情報と前記所在情報とを対応付けたキャッシュに対する有効期限時刻情報とを含むリソースレコードテーブルと、前記所在情報の変更予定を含む変更予定情報を取得し、前記変更予定情報に従って、前記リソースレコードテーブルを更新し、前記変更予定情報に含まれる変更予定時刻情報が更新前のリソースレコードテーブルに含まれる前記有効期限時刻情報より前だった場合、期限前変更報告を所定の方法で提示するリソースレコード管理手段と、名前解決要求を受け付ける名前解決要求受信手段と、ＴＴＬ計算手段と、前記名前解決要求の送信者に対して名前解決応答を送信する名前解決応答送信手段とを備える。【選択図】 図１

Description

本発明は、コンテンツの名前から通信ネットワークにおける所在情報を検索する技術に関する。

近年、インターネットを通じて、テキスト、画像動画などの様々なコンテンツが流通している。例えば、そのようなコンテンツにＷｅｂブラウザを介してアクセスする場合、ユーザは、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）と呼ばれる、インターネットにおけるコンテンツを一意に特定するための情報を、端末において動作するＷｅｂブラウザに入力する。ユーザが、例えば「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ」というＵＲＬをＷｅｂブラウザに入力した場合、Ｗｅｂブラウザは、「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」で指定されるホストに対し、「ｉｎｄｅｘ．ｈｔｍｌ」というコンテンツを要求する。ホストを指定する「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」の部分は、「ＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）」（以下本願では、「ホスト情報」または「名前」とも称す）と呼ばれる。

インターネットにおける通信はＩＰアドレスを利用して行われるので、ホストに接続したい端末は、ＵＲＬで指定されたホスト情報をＩＰアドレスに変換する必要がある。このホスト情報（名前）をＩＰアドレス（所在情報）に変換する作業は、「名前解決」と呼ばれる。

名前解決のシステムとしては、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）が一般に良く知られている。ＤＮＳを利用する場合、ホスト情報に対応するＩＰアドレスを知りたい端末は、ＤＮＳサーバに対して、当該ホスト情報を含む名前解決要求を送信することにより問い合わせる。名前解決要求を受け取ったＤＮＳサーバは、指定されたホスト情報をＩＰアドレスに変換し、そのＩＰアドレスを示す情報を含む名前解決応答を端末に返送する。

多数の端末から名前解決要求を受け取ることによる負荷を軽減するため、ＤＮＳサーバは、名前解決応答を送信する際に、ＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）と呼ばれるＩＰアドレス情報の有効期間を示す情報をも名前解決応答に含めて送信する。ホスト情報の問い合わせを行った端末は、名前解決応答を受け取った後、応答の内容を含む情報をキャッシュとして保持する。その後、同じホスト情報に対する名前解決が必要になった際、ＴＴＬで指定された有効期間内であれば、端末は、ＤＮＳサーバに名前解決要求を発行せず、キャッシュを利用することによって名前解決を行う。このようにして、端末がＤＮＳサーバへ名前解決要求を送信する回数が減少するので、ＤＮＳサーバの負荷が低減できる。

しかし、ホスト情報に対応するＩＰアドレスが変更された場合、ＴＴＬで指定された期間、端末は名前解決要求による問い合わせを行わないので、端末が、アドレス変更された当該ホストへ一時的にアクセスできない事態が発生する可能性があるという課題がある。

このような課題に対する技術として、特許文献１には、オブジェクトを通信ネットワーク内で一意に認識するリファレンス情報を管理するネームサーバを設け、リファレンス情報が更新された際に、そのネームサーバがキャッシュを持つ端末へ変更を通知する方法が開示されている。この特許文献１に記載された方法において、端末は、ネームサーバから、変更前のリファレンス情報とそのリファレンス情報に対するオペレーションの内容（変更あるいは消去）とを含む通知を受けたことに対応して、端末に記録されているキャッシュを更新する。これにより、端末は、ネットワークにおけるオブジェクトの所在を含むリファレンス情報が変更された後でも、変更後のリファレンス情報によって更新されたキャッシュを用いることができるので、オブジェクトに切れ目なくアクセスすることが可能となる。

また、特許文献２には、サービスを提供する複数の処理サーバと、窓口サーバとを設け、クライアントからのサービス要求を窓口サーバにおいて受け付ける方法が開示されている。この特許文献２に記載された方法において、クライアントは、まず、窓口サーバにサービス要求を送信する。窓口サーバは、要求されたサービスに対応する処理サーバをテーブルから選択し、選択された処理サーバの情報（アドレス）をクライアントに送信する。クライアントは、窓口サーバから知らされたアドレスを用いて、改めて処理サーバにアクセスする。すなわち、窓口サーバが、クライアントからのサービス要求に対して、処理サーバのアドレスを紹介する。これにより、処理サーバの所在の変更に対しては、窓口サーバが参照するテーブルを書き換えるだけで、クライアントは所在が変更された処理サーバに切れ目なくアクセスすることが可能となる。

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

しかしながら、特許文献１に開示された方法においては、ＤＮＳなどの一般的な名前解決のシステムに適用する場合、端末のソフトウェアを改修する必要があるという問題がある。上述したように、ＤＮＳを利用可能な一般的な端末の動作には、ＤＮＳサーバからキャッシュの変更の通知を受けて、その通知に応じてキャッシュを更新するという動作は含まれない。したがって、広範に利用されているＤＮＳを利用可能な端末ソフトウェアに対して、それらの動作に対応するための改修が必要となるので、特許文献１に開示された方法は、実現可能性が低いと言える。

また、特許文献２に開示された方法においては、コンテンツの所在情報を得るまでの時間が掛かるという問題がある。すなわち、特許文献２に記載された方法において、コンテンツに対する名前解決の要求者は、まず、ＤＮＳサーバに対して窓口サーバの名前解決を要求することにより、窓口サーバの所在情報を取得する。そして、当該要求者は、取得した所在情報を用いて窓口サーバに接続した後、さらに、本来所望するコンテンツの所在を窓口サーバに対して問い合わせるという２段階の検索が必要である。このように、コンテンツの名前解決を１段階で行うＤＮＳや特許文献１などに比べて、特許文献２に記載された方法においては、端末がコンテンツの所在情報を得るまでの時間が掛かるので効率が悪い。

本発明の一つの目的は、コンテンツの所在変更に対応することを可能としつつ、端末がコンテンツの所在情報を得るまでの効率が良く、また、実現可能性も高い名前解決装置などを提供することにある。

上記の目的を達成すべく、本発明に係る名前解決装置は、以下の構成を備えることを特徴とする。

すなわち、本発明に係る名前解決装置は、
コンテンツの名前を表す名前情報と、前記コンテンツの所在を表す所在情報と、前記名前情報と前記所在情報とを対応付けた情報であるキャッシュに対する有効期限を表す有効期限時刻情報とを含むリソースレコードテーブルと、
前記所在情報を変更する時刻を表す変更予定時刻情報と、変更対象を表す名前情報と、変更した後の所在情報を表す変更後の所在情報と、変更した後の有効期限時刻を表す変更後の有効期限時刻情報とを含む変更予定情報を取得し、前記変更予定情報に従って、前記リソースレコードテーブルを更新し、前記変更予定時刻情報が更新前のリソースレコードテーブルに含まれる前記有効期限時刻情報より前だった場合、期限前変更報告を所定の方法で提示するリソースレコード管理手段と、
所望の名前情報を含む名前解決要求を受け付ける名前解決要求受信手段と、
前記所望の名前情報に対応する有効期限時刻情報を前記リソースレコードテーブルから取得し、取得した前記有効期限時刻情報に基づいて、前記キャッシュの有効期間を示すＴＴＬを計算するＴＴＬ計算手段と、
前記所望の名前情報に対応する所在情報を前記リソースレコードテーブルから取得し、取得した所在情報と、前記所望の名前情報と、前記ＴＴＬを示すＴＴＬ情報とを含む名前解決応答を生成し、前記名前解決要求の送信者に対して前記名前解決応答を送信する名前解決応答送信手段とを備える
ことを特徴とする。

また、上記の同目的を達成すべく、本発明に係る名前解決方法は、情報処理装置を用いて、
コンテンツの所在情報を変更する時刻を表す変更予定時刻情報と、変更対象であるコンテンツを表す名前情報と、変更した後の所在情報を表す変更後の所在情報と、変更した後の有効期限時刻を表す変更後の有効期限時刻情報とを含む変更予定情報を取得し、
前記変更予定情報に従って、前記コンテンツの名前を表す名前情報と、前記コンテンツの所在を表す所在情報と、前記名前情報と前記所在情報とを対応付けた情報であるキャッシュに対する有効期限を表す有効期限時刻情報とを含むリソースレコードテーブルを更新し、
前記変更予定時刻情報が更新前のリソースレコードテーブルに含まれる前記有効期限時刻情報より前だった場合、期限前変更報告を所定の方法で提示し、
所望の名前情報を含む名前解決要求を受け付けた場合に、
前記所望の名前情報に対応する有効期限時刻情報を前記リソースレコードテーブルから取得し、
取得した前記有効期限時刻情報に基づいて、前記キャッシュの有効期間を示すＴＴＬを計算し、
前記所望の名前情報に対応する所在情報を前記リソースレコードテーブルから取得し、
取得した所在情報と、前記所望の名前情報と、前記ＴＴＬを示すＴＴＬ情報とを含む名前解決応答を生成し、
前記名前解決要求の送信者に対して前記名前解決応答を送信する
ことを特徴とする。

また、同目的は、上記の各構成を有する名前解決装置、並びに対応する方法を、コンピュータによって実現するコンピュータ・プログラム、及びそのコンピュータ・プログラムが格納されている、コンピュータ読み取り可能な記憶媒体によっても達成される。

本発明には、コンテンツの所在変更に対応することを可能としつつ、端末がコンテンツの所在情報を得るまでの効率が良く、また、実現可能性も高いという効果がある。

本発明の第１の実施形態に係る名前解決装置１の構成を示すブロック図である。 本発明の第２の実施形態に係る名前解決システムの構成を示すブロック図である。 第２の実施形態に係る名前解決システムにおける通信環境の一例を示す構成図である。 第２の実施形態においてＤＮＳサーバ１００が名前解決要求に対して行う動作を示すフローチャートである。 第２の実施形態においてコンテンツ管理サーバ２００とＤＮＳサーバ１００とがコンテンツ所在情報の変更に関して行う動作を示すフローチャートである。 第２の実施形態においてＤＮＳサーバ１００が保有するリソースレコードテーブル３の一例を示す図である。 第２の実施形態において端末３００が保有するキャッシュの一例を示す図である。 第２の実施形態においてＤＮＳサーバ１００が保有するリソースレコードテーブル３の状態遷移の一例を示す図である。 第２の実施形態においてＤＮＳサーバ１００が保有するリソースレコードテーブル３の一例を示す図である。 本発明の各実施形態、および、その変形例に係る名前解決システムに適用可能なコンピュータ（情報処理装置）の構成を例示する図である。

次に、本発明の実施形態について図面を参照して詳細に説明する。

＜第１の実施形態＞
図１は、本発明の第１の実施形態に係る名前解決装置１の構成を示すブロック図である。

図１を参照すると、本実施形態に係る名前解決装置１は、名前解決要求受信部２、リソースレコードテーブル３、ＴＴＬ計算部４、名前解決応答送信部５、記憶装置６、および、リソースレコード管理部７を有する。

名前解決装置１は、プログラム制御により動作する一般的なコンピュータ（情報処理装置）によって構成されても良いし、専用のハードウェアで構成されても良い。なお、この名前解決装置１のハードウェア構成例については、図１０を参照して後述する。

名前解決要求受信部２は、インターネットや構内ＬＡＮ（ローカルエリアネットワーク）等の通信ネットワーク（図示せず。以下、単に「ネットワーク」と略称する）を介して、コンテンツの名前情報を含む名前解決要求１０を受け付ける。

リソースレコードテーブル３は、コンテンツの名前と、コンテンツの所在とを対応づけるリソースレコードを含む。具体的には、リソースレコードは、コンテンツの名前を表す名前情報、コンテンツの所在を表す所在情報、および、キャッシュに対する有効期限（以下、「有効期限時刻」とも称す）を表す有効期限時刻情報を含む。上述したように、キャッシュとは、名前解決要求１０を送信した端末（図示せず）などが、名前解決要求１０に対する結果として得た名前解決応答１１の内容に関して保持した情報である。すなわち、キャッシュとは、コンテンツの名前情報と、コンテンツの所在情報とを対応付けた情報であるとも言える。また、リソースレコードには、上記の他に名前情報に関する属性を表す情報などを含めてもよい。

ＴＴＬ計算部４は、リソースレコードテーブル３に含まれる有効期限時刻情報に基づいて、名前解決要求１０に含まれていた名前情報に対応するコンテンツに関するキャッシュの有効期間（ＴＴＬ）を計算する。

名前解決応答送信部５は、受け付けた名前解決要求１０に対する名前解決応答１１を生成し、名前解決要求１０を送信した端末（以下、「名前解決の要求者」とも称す）に対して、生成した名前解決応答１１を送信する。名前解決応答送信部５は、リソースレコードテーブル３に登録された情報と、ＴＴＬ計算部４が計算したＴＴＬとに基づいて、名前解決応答１１を生成する。名前解決応答１１は、名前解決要求１０に含まれていた名前情報に対応するコンテンツの所在情報およびＴＴＬを示すＴＴＬ情報を含む。

記憶装置６は、リソースレコードテーブル３を格納する。記憶装置６は、例えば、半導体メモリ装置やディスク装置により実現される。

リソースレコード管理部７は、コンテンツの所在情報を変更する予定を表す変更予定情報１２を取得し、その変更予定情報１２に従って、リソースレコードテーブル３を更新する。変更予定情報１２は、変更対象を表す「名前情報」と、変更した後の所在情報を表す「変更後の所在情報」と、変更する予定の時刻（以下、「変更予定時刻」とも称す）に関する「変更予定時刻情報」と、変更した後のコンテンツの新たな有効期限時刻を表す「変更後の有効期限時刻情報」を含む。

また、リソースレコード管理部７は、取得した変更予定情報１２に含まれる変更予定時刻が、リソースレコードテーブル３に登録された現在（変更前）の有効期限時刻情報より前だった場合、所定の方法で期限前変更報告１３を提示する。すなわち、リソースレコード管理部７は、リソースレコードテーブル３に現在登録されている有効期限時刻に至るまでの期間、現在登録されている所在情報をキャッシュとして保持している端末がいる可能性を、期限前変更報告１３によって通知する。期限前変更報告１３は、コンテンツの名前情報など、報告対象であるコンテンツを示す情報、リソースレコードテーブル３に登録されている変更前の有効期限時刻情報、または、変更前の所在情報などを含んでも良い。

リソースレコード管理部７は、例えば、記憶装置６に格納されたファイルから変更予定情報１２を読み込んで取得してもよいし、名前解決装置１に接続されたディスプレイ（図示せず）とキーボード（図示せず）とを介してユーザからの入力情報として変更予定情報１２を取得しても良い。

リソースレコード管理部７は、例えば、期限前変更報告１３を所定の宛先にメールで送信しても良いし、画面に期限前変更報告１３の内容を表示しても良い。

このように、本実施形態によれば、コンテンツの所在情報の変更によって一時的にアクセスできない端末が発生する可能性への対処を取るための情報を提供することができる。

その理由は、リソースレコード管理部７が、取得した変更予定情報１２に含まれる変更予定時刻が、リソースレコードテーブル３に登録された現在の有効期限時刻情報より前だった場合、所定の方法で期限前変更報告１３を提示するからである。すなわち、期限前変更報告１３が提示されたことにより、例えば、コンテンツ管理者が、コンテンツにアクセスできない端末の発生を回避する対策の必要性を知ることができるからである。したがって、コンテンツ管理者は、本実施形態によって提供される情報に基づいて、見直した変更予定時刻を再登録することにより、コンテンツに一時的にアクセスできない端末が発生することを回避するなどの対策が可能となる。

また、本実施形態によれば、コンテンツの所在情報を効率よく提供することができる。

その理由は、名前解決要求２が受け付けた名前解決要求１０に対して、名前解決応答送信部５がコンテンツ所在地を示す所在情報を含む名前解決応答１１を送信するからである。すなわち、本実施形態において、コンテンツに対する名前解決の際に、名前解決の要求者が行うことは、コンテンツの名前情報を含む名前解決要求１０を名前解決装置１に送信することだけでよいからである。

また、本実施形態によれば、ＤＮＳなどの一般的な名前解決システムに対応可能な端末ソフトウェアを改修する必要がない。

その理由は、名前解決装置１は、上記の一般的な端末ソフトウェアが含む機能以外に、特別な機能を端末ソフトウェアに対して要求しないからである。

＜第２の実施形態＞
次に、上述した第１の実施形態を基本とする第２の実施形態について説明する。以下では、第２の実施形態に係る特徴的な部分を中心に説明し、第１の実施形態と同様な構成を有する第２の実施形態の構成要素には、第１の実施形態で付した参照符号と同一の参照符号を付し、その構成要素について重複する詳細な説明は省略する。

図２を参照して、本実施形態と、上述した第１の実施形態との構成における主な相違点を説明する。図２は、本発明の第２の実施形態に係る名前解決システムの構成を示すブロック図である。

図２を参照すると、本実施形態では、コンテンツ所在管理装置３１を含む点が第１の実施形態と異なる。コンテンツ所在管理装置３１は、名前解決装置２１に対して変更予定情報１２を送信する。また、本実施形態では、名前解決装置２１は、変更予定情報１２の送信者であるコンテンツ所在管理装置３１に対して期限前変更報告１３を送信する。期限前変更報告１３を受信した場合、コンテンツ所在管理装置３１は、期限前変更報告１３に応じた対策を取ることができる。

以上が、本実施形態に係る名前解決システムと第１の実施形態との構成における主な相違点である。

次に、図３を参照して、以下に本実施形態のシステム構成を説明する。図３は、第２の実施形態に係る名前解決システムにおける通信環境の一例を示す構成図である。

図３を参照すると、本実施形態は、名前解決装置２１を含むＤＮＳサーバ１００と、コンテンツ所在管理装置３１を含むコンテンツ管理サーバ２００と、端末３００と、コンテンツ配信サーバ４００〜４０２とを含む。

ＤＮＳサーバ１００、コンテンツ管理サーバ２００、端末３００、およびコンテンツ配信サーバ４００〜４０２は、インターネットや構内ＬＡＮ（ローカルエリアネットワーク）等の通信ネットワーク１０００を介して通信可能である。

ＤＮＳサーバ１００、コンテンツ管理サーバ２００、端末３００、およびコンテンツ配信サーバ４００〜４０２は、プログラム制御により動作する一般的なコンピュータ（情報処理装置）によって構成されても良いし、専用のハードウェアで構成されても良い。なお、ＤＮＳサーバ１００、コンテンツ管理サーバ２００、端末３００、およびコンテンツ配信サーバ４００〜４０２のハードウェア構成例については、図１０を参照して後述する。

ＤＮＳサーバ１００は、名前解決装置２１を含む。名前解決装置２１の詳細な構成については、図２を参照して、以下に説明する。

図２を参照すると、名前解決装置２１は、名前解決要求受信部２、リソースレコードテーブル３、ＴＴＬ計算部４、名前解決応答送信部５、記憶装置６、および、リソースレコード管理部２７を有する。

名前解決要求受信部２、リソースレコードテーブル３、ＴＴＬ計算部４、名前解決応答送信部５、および記憶装置６の各構造と内容は、上述した第１の実施形態と同様であるため、本実施形態における詳細な説明は省略する。

リソースレコード管理部２７は、第１の実施形態におけるリソースレコード管理部７に対応する。リソースレコード管理部２７は、上述したように、変更予定情報１２をコンテンツ所在管理装置３１から受信することにより取得する。また、リソースレコード管理部２７は、期限前変更報告１３を提示する際に、変更予定情報１２の送信者（すなわち、コンテンツ所在管理装置３１）に対して期限前変更報告１３を送信することにより提示する。上記以外のリソースレコード管理部２７の構造と機能については、第１の実施形態におけるリソースレコード管理部７と同様であるため、本実施形態における詳細な説明は省略する。

図３を用いた説明に戻る。

コンテンツ管理サーバ２００は、コンテンツ所在管理装置３１を含む。また、コンテンツ管理サーバ２００は、コンテンツ配信サーバ４００〜４０２を管理する。例えば、コンテンツ管理サーバ２００は、コンテンツ配信サーバ４００〜４０２において提供されるコンテンツの移動や複製の生成などを、各コンテンツ配信サーバ４００〜４０２に対して指示する。コンテンツ所在管理装置３１の構成については、図２を参照して、以下に説明する。

図２を参照すると、コンテンツ所在管理装置３１は、コンテンツ所在情報管理部３２と、対処部３３とを含む。

コンテンツ所在情報管理部３２は、コンテンツの所在情報を変更する予定を示す変更予定情報１２を生成し、その変更予定情報１２を名前管理装置２１に送信する。

対処部３３は、名前管理装置２１から期限前変更報告１３を受信し、その期限前変更報告１３に応じた対策を取る。

図３を用いた説明に戻る。

端末３００は、コンテンツ配信サーバ４００〜４０２において提供されるコンテンツにアクセスする。端末３００は、アクセスしたいコンテンツの所在情報を得る際に、ＤＮＳサーバ１００に対して、名前解決要求を送信する。端末３００は、ＤＮＳサーバ１００から名前解決応答を受け取った後、応答の内容を端末３００のデータ記憶領域（図示せず）にキャッシュとして保持する。キャッシュには、名前解決応答に含まれていた名前情報と、所在情報と、ＴＴＬ情報を含む。なお、キャッシュは、ＴＴＬ情報を有効期限時刻に換算した情報のように異なる形式で保存しても良いし、上記以外の情報を含んでも良い。端末３００がキャッシュを利用する方法に関しては、背景技術の欄において記載したとおりであるので、本実施形態における詳細な説明は省略する。

コンテンツ配信サーバ４００〜４０２は、コンテンツを保存し、そのコンテンツを端末３００に配信する。コンテンツは、コンテンツ配信サーバ４００〜４０２のデータ記憶領域（図示せず）に記憶されている。

次に、上述した構成を備える本実施形態の動作について詳細に説明する。

初めに、以下の説明における前提条件を述べる。

まず、本実施形態の動作説明開始時点において、コンテンツ配信サーバ４００〜４０２が保存しているコンテンツは、図３に示すとおりである。すなわち、コンテンツ配信サーバ４００は、コンテンツＣＡ４１０を保存している。また、コンテンツ配信サーバ４０１は、コンテンツＣＢ４１１とコンテンツＣＣ４１２とを保存している。さらに、コンテンツ配信サーバ４０２は、コンテンツＣＤ４１３を保存している。

また、本実施形態において、名前情報は、ＦＱＤＮとする。コンテンツＣＡ４１０には、「ＣＡ．ｃｄｎ．ｃｏｍ」というＦＱＤＮ（名前）が付与されている。以下同様に、コンテンツＣＢ４１１には、「ＣＢ．ｃｄｎ．ｃｏｍ」というＦＱＤＮが付与されている。コンテンツＣＣ４１２には、「ＣＣ．ｃｄｎ．ｃｏｍ」というＦＱＤＮが付与されている。コンテンツＣＤ４１３には、「ＣＤ．ｃｄｎ．ｃｏｍ」というＦＱＤＮが付与されている。

また、本実施形態において、所在情報は、ＩＰアドレスとする。コンテンツ配信サーバ４００のＩＰアドレスは、「１２３．１２３．１２３．１０１」とする。以下同様に、コンテンツ配信サーバ４０１のＩＰアドレスは、「１２３．１２３．１２３．１０２」とする。コンテンツ配信サーバ４０２のＩＰアドレスは、「１２３．１２３．１２３．１０３」とする。

また、コンテンツ管理サーバ２００は、コンテンツＣＡ４１１、コンテンツＣＢ４１１、コンテンツＣＣ４１２、およびコンテンツＣＤ４１３の所在情報を、あらかじめＤＮＳサーバ１００に登録していることとする。ＤＮＳサーバ１００は、コンテンツ管理サーバ２００から登録されたコンテンツの所在情報をリソースレコードテーブル３に含めて保存する。図６は、第２の実施形態においてＤＮＳサーバ１００が保有するリソースレコードテーブル３の一例を示す図である。図６に示すとおり、本実施形態におけるリソースレコードテーブル３は、コンテンツの名前情報（ＦＱＤＮ）を含む「ＦＱＤＮ」欄と、コンテンツの所在情報（ＩＰアドレス）を含む「ＩＰアドレス」欄と、キャッシュの有効期限時刻情報を含む「有効期限時刻」欄を含む。

また、端末３００は、「２０１３／１／１ ０：００：００」の時点でコンテンツＣＡ４１１、コンテンツＣＢ４１１、コンテンツＣＣ４１２、およびコンテンツＣＤ４１３にそれぞれアクセスを行い、その結果として、図７に示す情報を含むキャッシュを保有していることとする。図７は、第２の実施形態において端末３００が保有するキャッシュの一例を示す図である。すなわち、本実施形態において、キャッシュは、名前情報を含む「ＦＱＤＮ」欄と、所在情報を含む「ＩＰアドレス」欄と、ＴＴＬ情報を含む「ＴＴＬ」欄を含む。なお、図７における「ＴＴＬ」欄の値は、ＤＮＳサーバ１００が端末３００から各コンテンツに関する名前解決要求を受けた際、ＴＴＬ計算部４が、名前解決要求の受信時刻と、図６における「有効期限時刻」欄の情報とを基に計算した値である。

こうした前提条件における本実施形態の詳細な動作を説明する。なお、本実施形態の動作には、名前解決要求に対する処理、およびコンテンツの所在変更に対する処理の２つがある。

まず、端末３００から発信された名前解決要求に対する処理について、図４を参照して、ＤＮＳサーバ１００の詳細な動作を説明する。図４は、第２の実施形態においてＤＮＳサーバ１００が名前解決要求に対して行う動作を示すフローチャートである。なお、ＤＮＳサーバ１００における各構成要素の動作に関しては、図２における名称を用いて説明する。

以下は、端末３００が、「２０１３／１／１ ０：００：００」の時刻において、コンテンツＣＡ４１１の名前解決を要求したときの動作である。

まず、端末３００が、コンテンツＣＡ４１１を示す名前情報である「ＣＡ．ｃｄｎ．ｃｏｍ」を含む名前解決要求をＤＮＳサーバ１００に対して送信する。

ＤＮＳサーバ１００においては、名前解決要求受信部２が端末１００から送信された名前解決要求を受け付ける（ステップＳ１００）。

次に、ＴＴＬ計算部４が、リソースレコードテーブル３から、受け付けた名前解決要求に含まれるコンテンツの名前情報に対応する有効期限時刻情報を取得する。すなわち、ＴＴＬ計算部４は、リソースレコードテーブル３において、「ＣＡ．ｃｄｎ．ｃｏｍ」という情報を持つ「ＦＱＤＮ」欄に対応する「有効期限時刻」欄を検索し、当該「有効期限時刻」欄に保持された「２０１３／１／２ １２：００：００」という情報を取得する。そして、ＴＴＬ計算部４は、取得した有効期限時刻と、名前解決要求を受け付けた時刻との差から、ＴＴＬを計算する。具体的には、ＴＴＬ計算部４は、有効期限時刻である「２０１３／１／２ １２：００：００」と、受信した時刻である「２０１３／１／１ ０：００：００」との差を計算し、その値を秒単位で表した「１２９６００」をＴＴＬとする（ステップＳ１０１）。

次に、名前解決応答送信部５が、名前解決応答を生成する。具体的には、名前解決応答送信部５は、リソースレコードテーブル３から、受信した名前解決要求に含まれるコンテンツの名前情報に対応する所在情報である「１２３．１２３．１２３．１０１」を取得し、ＴＴＬ計算部４によって計算されたＴＴＬを示すＴＴＬ情報と併せて、名前解決応答に含める。そして、名前解決応答送信部５は、生成された名前解決応答を、端末３００に送信する（ステップＳ１０２）。

このようにして、名前解決装置２１は、コンテンツＣＡ４１１を保存しているコンテンツ配信サーバ４００のＩＰアドレスと、ＴＴＬとを含む名前解決応答を端末３００に提供することができる。

端末３００は、受信した名前解決応答からコンテンツＣＡ４１１のＩＰアドレスを得て、そのＩＰアドレスが指すコンテンツ配信サーバ４００に対してコンテンツＣＡ４１１へのアクセスを要求する。また、端末３００は、受信した名前解決応答の内容を含む情報をキャッシュに保存する。

なお、ステップＳ１０１において、ＴＴＬ計算部４は、リソースレコードテーブル３から取得した有効期限時刻情報が、名前解決要求を受け付けた時刻より前であった場合（以下、「有効期限時刻が経過していた場合」と称す）、ＴＴＬを「０」としても良い。有効期限時刻が経過していた場合、ＴＴＬ計算部４は、リソースレコードテーブル３の当該有効期限時刻情報を含む「有効期限時刻」欄を、事前に設定された値、または、所定の値などを、元の有効期限時刻情報に加えた時刻によって更新してから、ＴＴＬを計算しても良い。

以上が、名前解決要求に対する処理である。

次に、４つのコンテンツの所在変更（以下では、「移動」とも称す）に対する処理について、図５を参照して、本実施形態における詳細な動作を説明する。図５は、第２の実施形態においてコンテンツ管理サーバ２００とＤＮＳサーバ１００とがコンテンツ所在情報の変更に関して行う動作を示すフローチャートである。なお、ＤＮＳサーバ１００、およびコンテンツ管理サーバ２００における各構成要素の動作に関しては、図２における名称を用いて説明する。また、以下の動作は、コンテンツ管理サーバ２００が、各コンテンツの移動を実行する前に行ったこととする。

まず、初めに、コンテンツ管理サーバ２００が、コンテンツＣＤ４１２を、コンテンツ配信サーバ４０２（ＩＰアドレスは「１２３．１２３．１２３．１０３」）からコンテンツ配信サーバ４００（ＩＰアドレスは「１２３．１２３．１２３．１０１」）へ移動させる例について説明する。このときの変更予定時刻は、「２０１３／１／１ １０：００：００」とする。また、ＤＮＳサーバ１００におけるリソースレコードテーブル３は、図６に示す状態であるとする。

まず、コンテンツ管理サーバ２００においてコンテンツ所在情報管理部３２が、コンテンツＣＤ４１２の所在変更に関する変更予定情報１２を生成する。具体的には、コンテンツ所在情報管理部３２は、変更対象であるコンテンツＣＤ４１２の名前情報を「ＣＤ．ｃｄｎ．ｃｏｍ」とし、変更後の所在情報を「１２３．１２３．１２３．１０１」とし、変更予定時刻情報を「２０１３／１／１ １０：００：００」とし、変更後の有効期限時刻情報を「２０１３／１／２ １２：００：００」とした変更予定情報１２を生成する。そして、コンテンツ所在情報管理部３２は、ＤＮＳサーバ１００に対して、生成した変更予定情報１２を送信する（ステップＡ２００）。

ＤＮＳサーバ１００においては、リソースレコード管理部２７が、コンテンツ管理サーバ２００からの変更予定情報１２を受け付ける（ステップＢ２１０）。

リソースレコード管理部２７は、まず、受け付けた変更予定情報１２に従って、リソースレコードテーブル３を更新する。ここで、図８を参照して、リソースレコード管理部２７がリソースレコードを更新する際の動作を詳細に説明する。図８は、第２の実施形態においてＤＮＳサーバ１００が保有するリソースレコードテーブル３の状態遷移の一例を示す図である。

まず、リソースレコード管理部２７は、リソースレコードテーブル３の「ＦＱＤＮ」欄において、変更予定情報１２に含まれる名前情報に一致する情報を含むリソースレコードを選択する。リソースレコード管理部２７に選択されたリソースレコードの状態は、図８における状態５００に示すとおりである。

このとき、リソースレコード管理部２７は、変更予定情報１２に含まれる変更予定時刻情報が、選択されたリソースレコードにおける現在の有効期限時刻情報より前の時刻を示しているかどうかを確認する（ステップＢ２１１）。具体的には、図８の状態５００に示すとおり、現在の有効期限時刻情報は「２０１３／１／１ １２：００：００」であるため、変更予定時刻情報の方が、より前の時刻を示している。

変更予定時刻が現在の有効期限時刻情報より前だった場合、期限前変更であることをコンテンツ管理サーバ２００に報告する（ステップＢ２１２）。例えば、リソースレコード管理部７は、コンテンツＣＤ４１２の名前情報である「ＣＤ．ｃｄｎ．ｃｏｍ」と、変更前（現在）の有効期限時刻情報である「２０１３／１／１ １２：００：００」という情報を含む期限前変更報告１３をコンテンツ管理サーバ２００に送信してもよい。なお、期限前変更報告１３に含める情報は、上記に限定されない。すなわち、期限前変更報告１３は、少なくともコンテンツ管理サーバ２００が送信した変更予定情報１２のいずれに対応する報告であるかを識別可能であればよい。

次に、リソースレコード管理部２７は、選択されたリソースレコードにおいて、変更予定情報１２に含まれる変更予定時刻情報によって「有効期限時刻」欄を上書きする（ステップＢ２１３）。具体的には、リソースレコード管理部２７は、「２０１３／１／１ １０：００：００」という情報を、選択されたリソースレコードの「有効期限時刻」欄に書き込む。リソースレコード管理部２７によって更新された後のリソースレコードの状態は、図８における状態５０１に示すとおりである。

この後、リソースレコード管理部２７は、変更予定時刻情報に到達した際に、選択されたリソースレコードにおける所在情報と有効期限時刻情報とを、変更予定情報１２に含まれる情報によって更新する（ステップＢ２１４）。具体的には、リソースレコード管理部２７は、図８における状態５０１の状態であるリソースレコードの「ＩＰアドレス」欄に、変更後の所在情報である「１２３．１２３．１２３．１０１」を書き込む。さらに、リソースレコード管理部２７は、「有効期限時刻」欄に、変更後の有効期限時刻情報である「２０１３／１／２ １２：００：００」を書き込む。これにより、リソースレコード管理部２７は、コンテンツＣＤ４１２が移動された時刻に、コンテンツＣＤ４１２に対応するリソースレコードを図８の状態５０２に示すとおりに更新する。

一方、コンテンツ管理サーバ２００においては、期限前変更報告１３を受信した場合、対処部３３が、期限前変更に関する対処を実施してもよい（ステップＡ２０１、およびステップＡ２０２）。対処とは、コンテンツＣＤ４１２の移動前の所在情報をキャッシュとして保持している端末がいることへの対処である。例えば、端末３００が、キャッシュの有効期限時刻を迎える前の「２０１３／１／１ １１：００」に、コンテンツＣＤ４１２へアクセスする場合、端末３００は、キャッシュされている移動前の所在であるコンテンツ配信サーバ４０２を示す所在情報を使用する。すると、コンテンツＣＤ４１２は既にコンテンツ配信サーバ４００へ移動しているため、端末３００は、コンテンツＣＤ４１２にアクセスできないことになる。なお、このようなアクセスができないという問題は、変更前の有効期限時刻を過ぎて、端末３００のキャッシュが使用されなくなるまで、発生する可能性がある。すなわち、端末３００が、変更前の有効期限時刻である「２０１３／１／２ １２：００」を経過後にコンテンツＣＤ４１２にアクセスする場合、ＤＮＳサーバ１００へ名前解決要求を送信するので、移動後の所在であるコンテンツ配信サーバ４００のＩＰアドレスを取得可能である。

そこで、対処部３３は、期限前変更報告１３を受けた後、このような事態を避けるための対処を行ってもよい。例えば、コンテンツ配信サーバ４０２に対して、コンテンツＣ４１２へのアクセス要求を受けた場合に、要求した端末をコンテンツ配信サーバ４００へリダイレクトすることを指示しても良い。これにより、端末３００は、コンテンツＣ４１２の移動後にも、途切れることなくコンテンツＣ４１２へのアクセスが可能となる。なお、端末をリダイレクトすることの指示、およびリダイレクトを実行する方法は、特許文献２に記載された方法などの一般的な技術を採用することができるので、本実施形態における詳細な説明は省略する。

次に、コンテンツ管理サーバ２００が、コンテンツＣＡ４１０を、コンテンツ配信サーバ４００（ＩＰアドレスは「１２３．１２３．１２３．１０１」）からコンテンツ配信サーバ４０１（ＩＰアドレスは「１２３．１２３．１２３．１０２」）へ移動させる例について説明する。このときの変更予定時刻は、「２０１３／１／２ ０：００：００」とする。また、このときの変更後の有効期限時刻情報は、「２０１３／１／３ １２：００：００」とする。

コンテンツ管理サーバ２００におけるステップＡ２００と、ＤＮＳサーバ１００における動作については、上述したコンテンツＣＤ４１２の移動の場合と同様であるため、詳細な説明は省略する。

このコンテンツＣＡ４１０の移動の場合においても、変更前の有効期限時刻は「２０１３／１／２ １２：００：００」であるため、期限前変更報告１３が、ＤＮＳサーバ１００からコンテンツ管理サーバ２００に対して送信される。

期限前変更報告１３を受けて、対処部３３は、上述した対処とは異なる回避策を実行しても良い。例えば、対処部３３は、コンテンツ配信サーバ４０１へのコンテンツＣＡ４１０の移動ではなく、コンテンツＣＡ４１０の複製に切り替えてもよい。すなわち、対処部３３は、コンテンツ配信サーバ４０１に対して、コンテンツＣＡ４１０の複製を作成し、変更予定時刻から当該複製の提供を開始するよう指示する。一方、対処部３３は、コンテンツ配信サーバ４００に対して、変更予定時刻の後もコンテンツＣＡ４１０の提供を継続し、変更前の有効期限時刻である「２０１３／１／２ １２：００：００」において、コンテンツＣＡ４１０を削除するよう指示する。これにより、端末３００は、途切れることなくコンテンツＣＡ４１０へのアクセスが可能となる。なお、コンテンツの複製の作成、およびコンテンツの削除の指示、並びに実行の方法については、一般的な技術を採用することができるので、本実施形態における詳細な説明は省略する。

次に、コンテンツ管理サーバ２００が、コンテンツＣＣ４１２を、コンテンツ配信サーバ４０１（ＩＰアドレスは「１２３．１２３．１２３．１０２」）からコンテンツ配信サーバ４０２（ＩＰアドレスは「１２３．１２３．１２３．１０３」）へ移動させる例について説明する。このときの変更予定時刻は、「２０１３／１／２ １２：００：００」とする。また、このときの変更後の有効期限時刻情報は、「２０１３／１／３ ０：００：００」とする。

コンテンツ管理サーバ２００におけるステップＡ２００と、ＤＮＳサーバ１００におけるステップＢ２１０とについては、上述したコンテンツＣＤ４１２の移動の場合と同様であるため、詳細な説明は省略する。

ＤＮＳサーバ１００において、リソースレコード管理部２７が、受け付けた変更予定情報１２に従って、リソースレコードテーブル３を更新する動作についても、以下の点を除き、コンテンツＣＤ４１２の移動の場合と同様である。すなわち、このコンテンツＣＣ４１２の移動が上述した例と異なる点は、変更前（現在）の有効期限時刻は「２０１３／１／２ ０：００：００」であるため、変更予定時刻より後だということである（ステップＶ２１１）。

リソースレコード管理部２７は、期限前変更報告１３の送信を行わずに、選択されたリソースレコードにおいて、変更予定情報１２に含まれる変更予定時刻情報によって「有効期限時刻」欄を上書きする（ステップＢ２１３）。すなわち、リソースレコード管理部２７は、有効期限時刻を、変更予定時刻情報の示す時刻まで延長する。なお、リソースレコード管理部２７は、このタイミングで「有効期限時刻」欄の上書き（ステップＢ２１３）以降の動作を行わずに、変更前の有効期限時刻に達するまで待ってから実施しても良い。

コンテンツ管理サーバ２００は、期限前変更の報告を受信しないので、そのまま動作を終了する（ステップＡ２０１）。

この場合、コンテンツＣＣ４１２の移動の時点で、コンテンツＣＣ４１２の移動前の所在情報をキャッシュとして保持したままとなる端末は存在しない。したがって、特に対処の必要なく、端末３００は、コンテンツＣＣ４１２の移動後も、途切れることなくコンテンツＣＣ４１２へのアクセスが可能である。

最後に、コンテンツ管理サーバ２００が、コンテンツＣＢ４１１を、コンテンツ配信サーバ４０１（ＩＰアドレスは「１２３．１２３．１２３．１０２」）からコンテンツ配信サーバ４００（ＩＰアドレスは「１２３．１２３．１２３．１０１」）へ移動させる例について説明する。このときの変更予定時刻は、「２０１３／１／１ １２：００：００」とする。また、このときの変更後の有効期限時刻情報は、「２０１３／１／５ ０：００：００」とする。

コンテンツ管理サーバ２００におけるステップＡ２００と、ＤＮＳサーバ１００における動作については、上述したコンテンツＣＤ４１２の移動の場合と同様であるため、詳細な説明は省略する。

このコンテンツＣＡ４１１の移動の場合においても、変更前の有効期限時刻は「２０１３／１／３ １４：００：００」であるため、期限前変更報告１３が、ＤＮＳサーバ１００からコンテンツ管理サーバ２００に対して送信される。

期限前変更報告１３を受けて、対処部３３は、上述した対処とは異なる回避策を実行しても良い。例えば、対処部３３は、期限前変更報告１３に含まれる変更前の有効期限時刻情報に基づいて、端末がアクセスできない問題を回避するためにコンテンツＣＡ４１１の変更予定時刻を再登録しても良い。すなわち、対処部３３は、コンテンツＣＡ４１１の移動処理を、変更前の有効期限時刻情報が示す「２０１３／１／３ １４：００：００」以降に繰り延べ、新たな変更予定時刻を含む変更予定情報１２を、ＤＮＳサーバ１００へ送信してもよい。これにより、端末３００は、途切れることなくコンテンツＣＡ４１１へのアクセスが可能となる。

上述した４つのコンテンツの所在変更の結果、ＤＮＳサーバ１００が保持するリソースレコードテーブル３は、図９に示す状態となる。図９は、第２の実施形態においてＤＮＳサーバ１００が保有するリソースレコードテーブル３の一例を示す図である。

以上、説明したように、本実施形態には、上述した第１の実施形態と同様の効果に加えて、さらに、コンテンツの所在情報の変更によって一時的にアクセスできない端末が発生する可能性への対処を取ることができるという効果もある。

その理由は、リソースレコード管理部２７が送信した期限前変更報告１３に基づいて、対処部３３が、コンテンツの所在情報の変更によって一時的にアクセスできない端末が発生しないように対策を実行するからである。

また、本実施形態によれば、コンテンツの移動に合わせて、コンテンツごとにＴＴＬを制御することができるという効果もある。これにより、ホストごとにＴＴＬを制御する場合に比べて、本実施形態によれば、名前解決装置（ＤＮＳサーバ）が多数の端末から名前解決要求を受け取ることによる負荷をより効果的に軽減することが可能になる。なお、現在一般的なＤＮＳでは、ホストごとにＴＴＬを制御しているため、この技術を適用することによって効果が得られる範囲は大変広いことが期待できる。

その理由は、名前解決装置２１においてリソースレコードテーブル３をＦＱＤＮとＴＴＬとが一対一対応するように構成しているからである。

例えば、本実施形態においては、図９に示すように、同じコンテンツ配信サーバ４００に保存されているコンテンツＣＢ４１１とコンテンツＣＤ４１３とが、異なる有効期限時刻（ＴＴＬ）を持つことが可能である。しかし、一般的なＤＮＳサーバでは、ＩＰアドレスに紐付けしてＴＴＬを設けているため、コンテンツごとに分けることはできない。すなわち、一般的なＤＮＳでは、コンテンツＣＢ４１１は、より長いＴＴＬを付与することができるにもかかわらず、最もＴＴＬが短いコンテンツＣＤ４１３に合わせて制御されるという問題がある。

なお、本実施形態では、コンテンツ所在情報管理部３２と対処部３３とを、同じホストに含めて実現したが、これに限定されるものではない。すなわち、コンテンツ所在情報管理部３２と対処部３３とをそれぞれ別のホストに配置してもよい。このとき、名前解決装置２１におけるリソースレコード管理部２７は、ステップＢ２１２において、対処部３３が動作するホストへ期限前変更報告１３を送信する。

また、コンテンツ所在情報管理部３２と対処部３３とは、一方だけを利用することが可能である。すなわち、コンテンツ所在管理装置３１において、対処部３３を含まず、コンテンツ所在情報管理部３２だけを用いてもよいし、その逆でもよい。

また、対処部３３は、上述したとおり様々な対処を実行可能であるが、それらの対処のうち所定の一つだけを実行してもよいし、複数の対処を組み合わせて実行しても良い。また、対処部３３は、予め与えられたルールに基づいて、対処を動的に選択して実行しても良い。

なお、上述した各実施形態において図１乃至図３に示した各部は、ソフトウェアプログラムの機能（処理）単位（ソフトウェアモジュール）と捕らえることができる。ただし、これらの図面に示した各部の区分けは、説明の便宜上の構成であり、実装に際しては、様々な構成が想定され得る。このような場合のハードウェア環境の一例を図１０を参照して説明する。図１０は、本発明の各実施形態、および、その変形例に係る名前解決システムに適用可能なコンピュータ（情報処理装置）の構成を例示する図である。すなわち、図１０は、上述した各実施形態における名前解決装置１、名前解決装置２１、コンテンツ所在管理装置３１、ＤＮＳサーバ１００、コンテンツ管理サーバ２００、端末３００、およびコンテンツ配信サーバ４００〜４０２の少なくとも何れかを実現可能コンピュータの構成であって、上述した各実施形態における各機能を実現可能なハードウェア環境を示す。

図１０に示したコンピュータ９００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９０１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９０２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９０３、通信インタフェース（Ｉ／Ｆ）９０４、ディスプレイ９０５、及びハードディスク装置（ＨＤＤ）９０６を備え、これらがバス９０７を介して接続された構成を有する。なお、図１０に示したコンピュータが名前解決装置１、名前解決装置２１、コンテンツ所在管理装置３１、ＤＮＳサーバ１００、コンテンツ管理サーバ２００、およびコンテンツ配信サーバ４００〜４０２として機能する場合、ディスプレイ９０５は常時設けられる必要はない。また、通信インタフェース９０４は、上述した各実施形態において、当該各コンピュータ間における通信を実現する一般的な通信手段である。ハードディスク装置９０６には、プログラム群９０６Ａと、各種の記憶情報９０６Ｂとが格納されている。プログラム群９０６Ａは、例えば、上述した図１および図２に示した各ブロック（各部）に対応する機能を実現するためのコンピュータ・プログラムである。各種の記憶情報９０６Ｂは、例えば、図１および図２に示したリソースレコードテーブル３などである。このようなハードウェア構成において、ＣＰＵ９０１は、コンピュータ９００の全体の動作を司る。

そして、上述した各実施形態を例に説明した本発明は、各実施形態の説明において参照したブロック構成図（図１乃至図３）あるいはフローチャート（図４および図５）の各機能を実現可能なコンピュータ・プログラムを供給した後、そのコンピュータ・プログラムを、当該ハードウェアのＣＰＵ９０１に読み出して実行することによって達成される。また、このコンピュータ内に供給されたコンピュータ・プログラムは、読み書き可能な一時記憶メモリ９０３またはハードディスク装置９０６などの不揮発性の記憶デバイス（記憶媒体）に格納すれば良い。

また、前記の場合において、当該各装置内へのコンピュータ・プログラムの供給方法は、フロッピーディスク（登録商標）やＣＤ−ＲＯＭ等の各種記録媒体を介して当該装置内にインストールする方法や、インターネット等の通信ネットワーク１０００を介して外部よりダウンロードする方法等のように、現在では一般的な手順を採用することができる。そして、このような場合において、本発明は、係るコンピュータ・プログラムを構成するコード、或いは係るコードが記録されたところの、コンピュータ読み取り可能な記憶媒体によって構成されると捉えることができる。

１ 名前解決装置
２ 名前解決要求受信部
３ リソースレコードテーブル
４ ＴＴＬ計算部
５ 名前解決応答送信部
６ 記憶装置
７ リソースレコード管理部
１０ 名前解決要求
１１ 名前解決応答
１２ 変更予定情報
１３ 期限前変更報告
２１ 名前解決装置
２７ リソースレコード管理部
３１ コンテンツ所在管理装置
３２ コンテンツ所在情報管理部
３３ 対処部
１００ ＤＮＳサーバ
２００ コンテンツ管理サーバ
３００ 端末
４００〜４０２ コンテンツ配信サーバ
４１０ コンテンツＣＡ
４１１ コンテンツＣＢ
４１２ コンテンツＣＣ
４１３ コンテンツＣＤ
５００〜５０２ コンテンツＣＡ４１０に関するリソースレコードの状態
９００ 情報処理装置（コンピュータ）
９０１ ＣＰＵ
９０２ ＲＯＭ
９０３ ＲＡＭ
９０４ 通信インタフェース（Ｉ／Ｆ）
９０５ ディスプレイ
９０６ ハードディスク装置（ＨＤＤ）
９０６Ａ プログラム群
９０６Ｂ 各種の記憶情報
９０７ バス
１０００ ネットワーク（通信ネットワーク）

Claims (10)

1. コンテンツの名前を表す名前情報と、前記コンテンツの所在を表す所在情報と、前記名前情報と前記所在情報とを対応付けた情報であるキャッシュに対する有効期限を表す有効期限時刻情報とを含むリソースレコードテーブルと、
   前記所在情報を変更する時刻を表す変更予定時刻情報と、変更対象を表す名前情報と、変更した後の所在情報を表す変更後の所在情報と、変更した後の有効期限時刻を表す変更後の有効期限時刻情報とを含む変更予定情報を取得し、前記変更予定情報に従って、前記リソースレコードテーブルを更新し、前記変更予定時刻情報が更新前のリソースレコードテーブルに含まれる前記有効期限時刻情報より前だった場合、期限前変更報告を所定の方法で提示するリソースレコード管理手段と、
   所望の名前情報を含む名前解決要求を受け付ける名前解決要求受信手段と、
   前記所望の名前情報に対応する有効期限時刻情報を前記リソースレコードテーブルから取得し、取得した前記有効期限時刻情報に基づいて、前記キャッシュの有効期間を示すＴＴＬを計算するＴＴＬ計算手段と、
   前記所望の名前情報に対応する所在情報を前記リソースレコードテーブルから取得し、取得した所在情報と、前記所望の名前情報と、前記ＴＴＬを示すＴＴＬ情報とを含む名前解決応答を生成し、前記名前解決要求の送信者に対して前記名前解決応答を送信する名前解決応答送信手段と
   を備える名前解決装置。
2. 前記リソースレコードテーブルは、前記コンテンツごとに前記有効期限時刻情報を付与する
   ことを特徴とする請求項１記載の名前解決装置。
3. 請求項１または請求項２に記載の名前解決装置が有する前記リソースレコード管理手段から前記期限前変更報告を受信し、受信した前記期限前変更報告に応じて、所定の対処を実施する対処手段を備える
   ことを特徴とするコンテンツ所在管理装置。
4. 前記変更予定情報を生成し、請求項１または請求項２に記載の名前解決装置が有する前記リソースレコード管理手段に対して、前記変更予定情報を送信するコンテンツ所在情報管理手段を備える
   ことを特徴とするコンテンツ所在管理装置。
5. 請求項１または請求項２に記載の名前解決装置と、請求項３に記載のコンテンツ所在管理装置とを含むことを特徴とする名前解決システム。
6. 請求項１または請求項２に記載の名前解決装置と、請求項４に記載のコンテンツ所在管理装置とを含むことを特徴とする名前解決システム。
7. 情報処理装置を用いて、
   コンテンツの所在情報を変更する時刻を表す変更予定時刻情報と、変更対象であるコンテンツを表す名前情報と、変更した後の所在情報を表す変更後の所在情報と、変更した後の有効期限時刻を表す変更後の有効期限時刻情報とを含む変更予定情報を取得し、
   前記変更予定情報に従って、前記コンテンツの名前を表す名前情報と、前記コンテンツの所在を表す所在情報と、前記名前情報と前記所在情報とを対応付けた情報であるキャッシュに対する有効期限を表す有効期限時刻情報とを含むリソースレコードテーブルを更新し、
   前記変更予定時刻情報が更新前のリソースレコードテーブルに含まれる前記有効期限時刻情報より前だった場合、期限前変更報告を所定の方法で提示し、
   所望の名前情報を含む名前解決要求を受け付けた場合に、
   前記所望の名前情報に対応する有効期限時刻情報を前記リソースレコードテーブルから取得し、
   取得した前記有効期限時刻情報に基づいて、前記キャッシュの有効期間を示すＴＴＬを計算し、
   前記所望の名前情報に対応する所在情報を前記リソースレコードテーブルから取得し、
   取得した所在情報と、前記所望の名前情報と、前記ＴＴＬを示すＴＴＬ情報とを含む名前解決応答を生成し、
   前記名前解決要求の送信者に対して前記名前解決応答を送信する名前解決方法。
8. 前記リソースレコードテーブルは、前記コンテンツごとに前記有効期限時刻情報を付与する
   ことを特徴とする請求項７記載の名前解決方法。
9. コンテンツの所在情報を変更する時刻を表す変更予定時刻情報と、変更対象であるコンテンツを表す名前情報と、変更した後の所在情報を表す変更後の所在情報と、変更した後の有効期限時刻を表す変更後の有効期限時刻情報とを含む変更予定情報を取得し、前記変更予定情報に従って、前記コンテンツの名前を表す名前情報と、前記コンテンツの所在を表す所在情報と、前記名前情報と前記所在情報とを対応付けた情報であるキャッシュに対する有効期限を表す有効期限時刻情報とを含むリソースレコードテーブルを更新し、前記変更予定時刻情報が更新前のリソースレコードテーブルに含まれる前記有効期限時刻情報より前だった場合、期限前変更報告を所定の方法で提示するリソースレコード管理処理と、
   所望の名前情報を含む名前解決要求を受け付ける名前解決要求受信処理と、
   前記所望の名前情報に対応する有効期限時刻情報を前記リソースレコードテーブルから取得し、取得した前記有効期限時刻情報に基づいて、前記キャッシュの有効期間を示すＴＴＬを計算するＴＴＬ計算処理と、
   前記所望の名前情報に対応する所在情報を前記リソースレコードテーブルから取得し、取得した所在情報と、前記所望の名前情報と、前記ＴＴＬを示すＴＴＬ情報とを含む名前解決応答を生成し、前記名前解決要求の送信者に対して前記名前解決応答を送信する名前解決応答送信処理とをコンピュータに実行させるコンピュータ・プログラム。
10. 前記リソースレコードテーブルは、前記コンテンツごとに前記有効期限時刻情報を付与する
    ことを特徴とする請求項９記載のコンピュータ・プログラム。

Images