特開 2023-135657 エニーキャストＣＤＮルーティングにおけるローカルプリファレンス

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

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

(11)【公開番号】P2023135657

(43)【公開日】2023-09-28

(54)【発明の名称】エニーキャストＣＤＮルーティングにおけるローカルプリファレンス

(51)【国際特許分類】

   H04L 67/1021 20220101AFI20230921BHJP

   H04L 67/288 20220101ALI20230921BHJP

   H04L 67/563 20220101ALI20230921BHJP

【ＦＩ】

H04L67/1021

H04L67/288

H04L67/563

【審査請求】有

【請求項の数】20

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2023040473

(22)【出願日】2023-03-15

(31)【優先権主張番号】17/695,581

(32)【優先日】2022-03-15

(33)【優先権主張国・地域又は機関】US

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡ

２．ＳＭＡＬＬＴＡＬＫ

(71)【出願人】

【識別番号】504399716

【氏名又は名称】ディズニー エンタープライゼス インコーポレイテッド

(74)【代理人】

【識別番号】100101502

【弁理士】

【氏名又は名称】安齋 嘉章

(72)【発明者】

【氏名】エリック シー フレデリック

(72)【発明者】

【氏名】ロバート ジー コラントゥオーニ

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

【課題】要求されたオブジェクトをユーザに配信するために使用するコンテンツ配信ネットワーク（ＣＤＮ）内のキャッシュを選択するためのロードバランサを識別する方法、サーバ及び非一時的なコンピュータ可読媒体を提供する。
【解決手段】方法は、ユーザデバイスが、ＤＮＳルックアップを実行して、ＣＤＮ内の複数のロードバランサのエニーキャストＩＰアドレスを識別し、エニーキャストＩＰアドレスを使用してエニーキャストルーティングを開始し、最も近いロードバランサを自動的に識別する。識別されたロードバランサは、キャッシュを選択すると、ユーザデバイスとのエニーキャスト接続を閉鎖し、ＨＴＴＰリダイレクトを使用して、選択したキャッシュへのユニキャスト経路をユーザデバイスに提供する。次に、ユーザデバイスは、キャッシュとのユニキャスト接続を確立して、オブジェクトを取得（例えば、ストリーミング）する。
【選択図】図３

【特許請求の範囲】

【請求項1】

コンテンツ配信ネットワーク（ＣＤＮ）に関連付けられたロードバランサとＣＤＮからのオブジェクトを要求するユーザデバイスとの間にエニーキャスト接続を確立する工程と、
ロードバランサにおいて、ＣＤＮ内の複数のキャッシュから第１キャッシュを選択して、１つ以上のロードバランシング基準に基づいてオブジェクトに対する要求を満たす工程と、
ロードバランサからユーザデバイスにＨＴＴＰリダイレクトを送信し、エニーキャスト接続を閉鎖する工程を含み、ＨＴＴＰリダイレクトは、ユーザデバイスと第１キャッシュの間のユニキャスト接続を確立して、第１キャッシュからオブジェクトを取り出すための情報を含む方法。

【請求項2】

ロードバランサは、ＣＤＮに関連付けられた複数のロードバランサの１つであり、複数のロードバランサの各々は、同じエニーキャストＩＰアドレスを有する、請求項１に記載の方法。

【請求項3】

複数のロードバランサ及び複数のキャッシュが異なる地理的領域に分散され、複数のロードバランサのうちの少なくとも１つ及び複数のキャッシュのうちの少なくとも１つが地理的領域の各々に共存する、請求項２に記載の方法。

【請求項4】

エニーキャスト接続を確立することは、ユーザデバイスがドメインネームシステム（ＤＮＳ）ルックアップを実行し、ロードバランサとエニーキャスト接続を確立するために使用されるエニーキャストＩＰアドレスを識別した後に実行される、請求項２に記載の方法。

【請求項5】

ロードバランサは、ネットワークを介してユーザデバイスまでの全ての複数のロードバランサの最短経路を有する、請求項２に記載の方法。

【請求項6】

エニーキャスト接続は、ネットワーク内の基礎となるルーティングプロトコルに依存して最短経路を識別する、請求項５に記載の方法。

【請求項7】

ＨＴＴＰリダイレクトは、ＨＴＴＰ応答ステータスコード３０２を含む、請求項１に記載の方法。

【請求項8】

ロードバランサでのエニーキャスト接続中に、オブジェクトへのフルパスとユーザデバイスのＩＰアドレスを受信する、請求項１に記載の方法。

【請求項9】

１つ以上のコンピュータプロセッサの操作によって実行されると、オペレーションを実行するコンピュータプログラムコードを含む非一時的なコンピュータ可読媒体であって、オペレーションは、
ＣＤＮに関連付けられたロードバランサとＣＤＮからのオブジェクトを要求するユーザデバイスとの間にエニーキャスト接続を確立する工程と、
ロードバランサにおいて、ＣＤＮ内の複数のキャッシュから第１キャッシュを選択して、１つ以上のロードバランシング基準に基づいてオブジェクトに対する要求を満たす工程と、
ロードバランサからユーザデバイスにＨＴＴＰリダイレクトを送信し、エニーキャスト接続を閉鎖する工程を含み、ＨＴＴＰリダイレクトは、ユーザデバイスと第１キャッシュの間のユニキャスト接続を確立して、第１キャッシュからオブジェクトを取り出すための情報を工程を含む、コンピュータ可読媒体。

【請求項10】

ロードバランサは、ＣＤＮに関連付けられた複数のロードバランサの１つであり、複数のロードバランサの各々は、同じエニーキャストＩＰアドレスを有する、請求項９に記載の非一時的なコンピュータ可読媒体。

【請求項11】

複数のロードバランサ及び複数のキャッシュが異なる地理的領域に分散され、複数のロードバランサのうちの少なくとも１つ及び複数のキャッシュのうちの少なくとも１つが地理的領域の各々に共存する、請求項１０に記載の非一時的なコンピュータ可読媒体。

【請求項12】

エニーキャスト接続を確立することは、ユーザデバイスがドメインネームシステム（ＤＮＳ）ルックアップを実行し、ロードバランサとエニーキャスト接続を確立するために使用されるエニーキャストＩＰアドレスを識別した後に実行される、請求項１０に記載の非一時的なコンピュータ可読媒体。

【請求項13】

ロードバランサは、ネットワークを介してユーザデバイスまでの全ての複数のロードバランサの最短経路を有する、請求項１０に記載の非一時的なコンピュータ可読媒体。

【請求項14】

ＨＴＴＰリダイレクトは、ＨＴＴＰ応答ステータスコード３０２を含む、請求項９に記載の非一時的なコンピュータ可読媒体。

【請求項15】

サーバであって、
プロセッサと、
プロセッサの作用により実行されると、オペレーションを実行するコンピュータプログラムコードを格納するメモリを含み、オペレーションは、
サーバとＣＤＮからのオブジェクトを要求するユーザデバイスとの間にエニーキャスト接続を確立する工程と、
ＣＤＮ内の複数のキャッシュから第１キャッシュを選択して、１つ以上のロードバランシング基準に基づいてオブジェクトに対する要求を満たす工程と、
ユーザデバイスにＨＴＴＰリダイレクトを送信し、エニーキャスト接続を閉鎖する工程を含み、ＨＴＴＰリダイレクトは、ユーザデバイスと第１キャッシュの間のユニキャスト接続を確立して、第１キャッシュからオブジェクトを取り出すための情報を工程を含む、サーバ。

【請求項16】

サーバは、ＣＤＮに関連付けられた複数のサーバの１つであり、複数のサーバの各々は、同じエニーキャストＩＰアドレスを有する、請求項１５に記載のサーバ。

【請求項17】

複数のサーバ及び複数のキャッシュが異なる地理的領域に分散され、複数のサーバのうちの少なくとも１つ及び複数のキャッシュのうちの少なくとも１つが地理的領域の各々に共存する、請求項１６に記載のサーバ。

【請求項18】

エニーキャスト接続を確立することは、ユーザデバイスがドメインネームシステム（ＤＮＳ）ルックアップを実行し、サーバとエニーキャスト接続を確立するために使用されるエニーキャストＩＰアドレスを識別した後に実行される、請求項１６に記載のサーバ。

【請求項19】

サーバは、ネットワークを介してユーザデバイスまでの全ての複数のサーバの最短経路を有する、請求項１６に記載のサーバ。

【請求項20】

ＨＴＴＰリダイレクトは、ＨＴＴＰ応答ステータスコード３０２を含む、請求項１５に記載のサーバ。

【発明の詳細な説明】

【背景】

【0001】

コンテンツディストリビューション／デリバリ（配信）ネットワーク（ＣＤＮ）は、キャッシュが地理的に分散した大規模なネットワークである。これらのキャッシュは、ビデオやその他のＷｅｂコンテンツ（一般に、「オブジェクト」と称する）を視聴者に配信する。オブジェクトをユーザに配信するために使用する最適なキャッシュを選択するのは難しい作業である。ほとんどのＣＤＮは通常、２つの手法を使用して、オブジェクトの配信に使用する最適なキャッシュを特定する。第１に、ドメインネームシステム（ＤＮＳ）ロードバランシング（負荷分散）を使用して、最適なキャッシュを選択することができる。ＤＮＳサーバが最適なキャッシュを選択すると、ＣＤＮはキャッシュ（又はキャッシュクラスタ）のＩＰアドレスを使用して、ユーザからのＤＮＳルックアップに応答する。しかし、ＤＮＳロードバランシングには幾つかの課題がある。第１に、真のクライアントＩＰアドレス（ジオロケーション／マッピングに使用される）は、多くの場合、ＣＤＮのＤＮＳサーバには表示されない。代わりに、ＤＮＳサーバは、ユーザが使用するインターネットサービスプロバイダ（ＩＳＰ）のリゾルバ（又は、更に悪いことに、クラウドベースのパブリックＤＮＳリゾルバ）のＩＰアドレスを認識する。真のクライアントＩＰアドレスがなければ、キャッシュのローカリゼーションはより困難になる。更に、ＤＮＳルックアップには、要求されているコンテンツに関する情報が含まれていない。従って、ＣＤＮは、キャッシュのローカリゼーション中にアセットレベルのロードバランシングポリシーを使用することができない。例えば、アセットレベルポリシーでは、コンテンツが既にキャッシュにあることがわかっている特定のキャッシュ又はクラスターをターゲットにすることができる。最後に、有効期限（ＴＴＬ）が非常に短い場合でも、ロードバランサ（負荷分散装置）の応答がある程度キャッシュされる。これはロードが高い場合には有効であるが、最終的にはＤＮＳサーバがユーザの場所を特定する能力が低下する。

【0002】

ユーザに最も近いキャッシュを選択するために使用される第２の戦略は、エニーキャストルーティングである。エニーキャストでは、多くのホストが同じＩＰアドレスをアドバタイズすることができる。レイヤー３スイッチ又はルータは、ホップごとに、パケットの最小コスト経路を決定する。これにより、クライアントが最も近いロジカルＣＤＮキャッシュにローカライズされる。しかし、ルーティングの変更により、パケットが別のホストに配信されると、接続がリセットされる危険性があるため、接続が中断される可能性がある。エニーキャストは、従来、ユーザデータグラムプロトコル（ＵＤＰ）、又はエクストリームショートライブドトランスミッション制御プロトコル（ＴＣＰ）接続に使用されてきた。

【図面の簡単な説明】

【0003】

上記の態様が達成され、詳細に理解できるように、添付図面を参照することにより、上記で簡単に要約した、本明細書に記載の実施形態のより具体的な説明を行うことができる。

【0004】

ただし、添付図面は典型的な実施形態を示しており、従って限定と見なされるべきではないことに留意すべきである。他の同等に有効な実施形態が考えられる。

【図1】一実施形態による、通信システムのブロック図である。

【図2】一実施形態による、ＣＤＮからオブジェクトを取得するためのタイミングチャートである。

【図3】一実施形態による、ロードバランサを識別するためエニーキャストルーティングを使用するフローチャートである。

【図4】一実施形態による、地理的に分散されたロードバランサ及びキャッシュを有するＣＤＮを示す。

【図5】一実施形態による、ＨＴＴＰリダイレクトを使用してＣＤＮキャッシュへのユニキャスト経路をユーザデバイスに提供するロードバランサを示す。

【詳細な説明】

【0005】

本明細書の実施形態はＣＤＮについて説明する。ここで、エニーキャストルーティングが使用され、オブジェクトをユーザに配信するために使用するＣＤＮ内のキャッシュを選択するためのロードバランサ（トラフィックルータとも称される）を特定する。一実施形態では、ユーザはＤＮＳルックアップを実行して、ＣＤＮ内の複数のロードバランサのエニーキャストＩＰアドレスを特定する。次に、ユーザは、エニーキャストＩＰアドレスを使用してエニーキャストルーティングを開始し、エニーキャストＩＰアドレスを共有する複数のロードバランサの中で最も近いロジカルロードバランサを自動的に特定することができる。好都合なことに、ロードバランサは、オブジェクト（例えば、映画、テレビ番組、ライブパフォーマンス等）のフルパスだけでなく、ユーザデバイスのＩＰアドレスも見れる。これは、実際のユーザＩＰがＤＮＳ要求を行うリゾルバの背後に隠され、ＤＮＳルックアップが要求されているオブジェクトを示さない多くのタイプのＤＮＳルックアップとは異なる。この情報を使用して、ロードバランサはユーザデバイスの正確な場所を特定し、１つ以上のロードバランシング基準を使用して最適なＣＤＮキャッシュを選択することができる。

【0006】

キャッシュが選択されると、ロードバランサはユーザデバイスとのエニーキャスト接続を閉鎖し、ＨＴＴＰリダイレクト（例えば、ＨＴＴＰ応答ステータスコード３０２等）を使用し、ユーザデバイスに選択したキャッシュへのユニキャスト経路を提供することができる。その後、ユーザデバイスはキャッシュとのユニキャスト接続を確立し、オブジェクトを取得することができる。好都合なことに、ロードバランサへのエニーキャスト接続はしばしば非常に短く（例えば、１００～３００ミリ秒）、ネットワーク障害（例えば、回線の切断、切断されたルータ等）によってエニーキャストルートが他のロードバランサに変更される可能性を低減する。ロードバランシングが完了すると、ユーザデバイスはＨＴＴＰリダイレクトにより提供されるユニキャスト経路を使用し、キャッシュを取得する。これは通常、はるかに長い接続（例えば、セグメントの転送に５～８秒）であり、エニーキャストルーティングによって引き起こされる潜在的なネットワーク障害の影響を受けない。このように、本明細書の実施形態は、ＤＮＳルックアップよりも正確な情報を提供する最も近いロードバランサを自動的に特定するエニーキャストルーティングの利点を享受すると共に、ユニキャスト接続を使用してＣＤＮキャッシュからオブジェクトを取得し、ネットワーク障害に対するエニーキャスト接続を使用することの影響を避けることができる。

【0007】

図１は一実施形態による通信システム１００のブロック図である。システム１００は、ユーザデバイス１０５、ＤＮＳサーバ１３０、ネットワーク１５０（例えば、インターネット等のパブリックネットワーク）、エッジサーバ１５５、ＣＤＮ１７０、及びストリーミングサーバ１９０を含む。ユーザデバイス１０５は、ＣＤＮ１７０内のキャッシュ１８０からオブジェクト１８５を取り出すことができる任意のデバイスであってもよい。この実施形態では、ユーザデバイス１０５はディスプレイ１２５を含み、ＣＤＮ１７０（例えば、スマートフォン、タブレット、ラップトップ、スマートテレビ等）からのメディアプレゼンテーションを表示（例えば、出力）することができる。しかし、他の実施形態では、ユーザデバイス１０５はディスプレイを含まなくてもよく、代わりに、出力デバイス（テレビ等）に結合されたストリーミングプレーヤー又はメディアプレーヤーであってもよい。

【0008】

いずれの場合にも、ユーザデバイス１０５はプロセッサ１１０及びメモリ１１５を含む。プロセッサ１１０は、任意の数のプロセスコアを含むことができる任意の数のプロセス要素を表す。一般に、プロセッサ１１０は、メモリ１１５に格納されたプログラミング命令を取り出し、実行する。メモリ１１５は、揮発性メモリ要素、不揮発性メモリ要素、及びそれらの組み合わせを含むことができる。具体的には、メモリ１１５は、オブジェクト１８５を選択し、ＣＤＮ１７０から取り出すことができるストリーミングアプリケーション１２０（例えば、ソフトウェアアプリケーション）を含む。例えば、ストリーミングアプリケーション１２０は、複数の異なるメディアプレゼンテーション（例えば、映画、ライブイベント、テレビエピソード等）をリストするグラフィカルユーザインターフェース（ディスプレイ１２５又は個別の電子デバイス（例えば、テレビ）を使用）を出力することができる。次いで、ユーザはインターフェースを使用し、特定のメディアプレゼンテーションを選択し、ユーザデバイス１０５又は接続された出力デバイスで見ることができる。

【0009】

ユーザがメディアプレゼンテーションを選択したことに応答して、ユーザデバイス１０５は、メディアプレゼンテーションに対応するユニフォームリソースロケーション（ＵＲＬ）を求める要求をストリーミングサーバ１９０に送信することができる。ストリーミングサーバ１９０は、ＣＤＮ１７０に格納されている各々のオブジェクト（例えば、メディアプレゼンテーション）ごとに異なるオブジェクトＵＲＬ１９５を格納することができる。オブジェクトＵＲＬ１９５は、メディアプレゼンテーションのネーム（例えば、ＨＴＴＰ:／／...AdventureShowEpisode１Season２..等）を含むことができる。このようにして、ストリーミングサーバ１９０内のＵＲＬ１９５は、ユーザによって要求されたメディアプレゼンテーション（又は他のオブジェクト）にアクセスするためのＵＲＬを提供する。

【0010】

次に、ユーザデバイス１０５は、オブジェクトＵＲＬ１９５を使用してＤＮＳルックアップを実行することができる。ＤＮＳルックアップは、オブジェクトＵＲＬ１９５をネットワーク１５０で使用することができるＩＰアドレスに変換し、要求されたメディアプレゼンテーションを取り出す（又はストリーミングする）場所を識別する。この場合、システム１００は複数のＤＮＳサーバ１３０を含むが、他の実施形態では、１つのＤＮＳサーバ１３０のみを含むことができる。ユーザデバイス１０５はユニキャストルーティング又はエニーキャストルーティングのいずれかを使用して、ＤＮＳルックアップを実行するためにＤＮＳサーバ１３０を識別することができる。エニーキャストルーティングを使用する利点は、ネットワーク１５０を介してユーザデバイス１０５への最短ルートでＤＮＳサーバ１３０を自動的に識別でき、ＤＮＳルックアップの実行に使用される時間を潜在的に短縮できることである。しかし、本明細書の実施形態では、ユニキャストルーティングを使用してＤＮＳルックアップを実行することも可能である。

【0011】

ＤＮＳサーバ１３０は、ＤＮＳルックアップに応答して、ＩＰアドレスをユーザデバイス１０５に提供する。しかし、オブジェクトを検索するためにユーザデバイスにキャッシュ１８０へのＩＰアドレスを提供するのではなく、幾つかの実施形態では、ＤＮＳサーバ１３０はエニーキャストＩＰアドレスをエッジサーバ１５５に提供する。より具体的には、ＤＮＳサーバ１３０はエニーキャストＩＰアドレスをエッジサーバ１５５内にホストされたロードバランサ１６０（例えば、ソフトウエアアプリケーション）に到達するように提供する。一実施形態では、エッジサーバ１５５の各々は、同じエニーキャストＩＰアドレスを有する。従って、ＤＮＳサーバ１３０がエニーキャストＩＰアドレスをユーザデバイス１０５に提供すると、そのアドレスを用いたエニーキャストルーティングの実行は、ユーザデバイス１０５への最短経路で、エッジサーバ１５５及びロードバランサ１６０を自動的に識別する。即ち、エニーキャストルーティングは基礎となるルーティングプロトコル（例えば、ボーダーゲートウェイプロトコル（ＢＧＰ）等）を用い、同じエニーキャストＩＰアドレスの複数のネットワークデバイス（例えば、エッジサーバ１５５）の１つへの最短経路を識別する。

【0012】

次に、エニーキャストルーティングから識別されたエッジサーバ１５５内のロードバランサ１６０は、１つ以上のロードバランシング基準を使用して、要求されたメディアプレゼンテーション（例えば、オブジェクト１８５）を配信するのに最適なキャッシュ１８０を決定することができる。本明細書の実施形態は特定のロードバランシング基準に限定されない。非限定的な例には、識別されたエッジサーバ１５５と同じ場所にある（又は最も近い）キャッシュ１８０を使用すること、特定のキャッシュ１８０のロードが確実に閾値を超えないこと、最小量の要求が各々のキャッシュ１８０に確実に送信されること、保守のために間もなく取り除かれるキャッシュ１８０から要求をルーティングしないこと等を含む。

【0013】

キャッシュ１８０を選択するため、エッジサーバ１５５でＤＮＳサーバ１３０ではなくロードバランサ１６０を使用することには幾つかの利点がある。１つの利点は、ユーザデバイス１０５とロードバランサ１６０の間のＴＣＰ通信は、ユーザデバイス１０５とロードバランサ１６０の間のＤＮＳルックアップより多くの情報を有する。例えば、ロードバランサ１６０への通信は要求されたオブジェクト１８５へのフルパスを含むことができるが、ＤＮＳルックアップはこの情報を有しない。従って、ロードバランサ１６０はユーザが要求しているオブジェクト１８５を認識し、それに応じてキャッシュ１８０を選択することができるが、この情報はＤＮＳサーバからは隠されている。例えば、ＣＤＮ１７０内の幾つかのキャッシュ１８０は要求されたオブジェクトを有することができるが、他のキャッシュは有しない場合がある。

【0014】

更に、ユーザデバイス１０５からロードバランサ１６０へのＨＴＴＰ通信はユーザデバイス１０５の真のＩＰアドレスを含むことができるが、ＤＮＳルックアップは、リゾルバ（ユーザデバイス１０５の地理的位置にない又は近接しない場合がある）のＩＰアドレスを含むことができる。従って、キャッシュ１８０を選択するときにロードバランサ１６０によって実行されるジオロケーション機能は、ＤＮＳサーバ１３０によって実行されるジオロケーション機能よりも正確であることができる。

【0015】

上述のように、ユーザデバイス１０５とロードバランサ１６０の間の通信は、ユーザデバイス１０５に最も近いロードバランサ１６０を自動的に識別するエニーキャスト接続とすることができる。また、上述のように、エニーキャスト接続は、接続を変更する可能性があるネットワーク障害の影響を受けやすい。例えば、回線が切断されたり、ルータが保守のために停止したりすることにより、最短経路が、例えばロードバランサ１６０Ａからロードバランサ１６０Ｂに変わることがある。この場合、ロードバランサ１６０Ｂは、ユーザデバイス１０５によってロードバランサ１６０Ａに既に提供された情報のいずれも有しないため、プロセスをリピート又はリセットしなければならない。しかし、ロードバランサ１６０とユーザデバイス１０５の間の通信は、単一のＨＴＴＰ要求／応答ペア（ＴＣＰハンドシェーク、ＴＬＫハンドシェーク（（オプション）、ＨＴＴＰ要求／応答自体を含むことができる）を交換するデバイスにより典型的に非常に短い（例えば、２００～３００ミリ秒）。ロードバランサ１６０及びユーザデバイスは、５～１０個のＴＣＰセグメントの間で交換することができる。従って、ユーザデバイス１０５とロードバランサ１６０の間のエニーキャスト接続中にネットワーク障害が発生するリスクは小さい。

【0016】

ロードバランサ１６０が、ユーザデバイス１０５が要求したオブジェクト１８５（例えば、要求されたメディアプレゼンテーション）を取得又はストリーミングするために使用するキャッシュ１８０を選択すると、ロードバランサ１６０は、ＨＴＴＰリダイレクトをユーザデバイス１０５に送信することができる（例えば、ステータスコード３０２を含むＨＴＴＰ応答）。これにより、ユーザデバイス１０５が選択されたキャッシュ１８０にリダイレクトされる。別の言い方をすれば、ロードバランサ１６０はエニーキャスト接続を閉鎖し、ユーザデバイス１０５をキャッシュ１８０にリダイレクトする。ＨＴＴＰリダイレクトはユニキャストを含むことができ、これにより、ユーザデバイス１０５は、ＨＴＴＰリダイレクトに応答してキャッシュ１８０へのユニキャスト接続を確立することができる。３０２ステータスコードを使用するＨＴＴＰリダイレクトについて説明したが、実施形態はこれに限定されず、現在又は将来の任意のリダイレクトＨＴＴＰ機構（例えば、３０１ステータスコード又はＡｌｔ－Ｓｖｃ）を使用することができる。

【0017】

ユーザデバイス１０５とキャッシュ１８０の間の接続は、オブジェクト１８５を検索するために、ユーザデバイス１０５とキャッシュ１８０の間のユニキャスト接続を使用するユーザデバイス１０５とロードバランサ１６０の間の接続よりも、通常、はるかに長いので、エニーキャスト接続の脆弱性を回避する。即ち、ユーザデバイス１０５とキャッシュ１８０の間のユニキャスト経路に沿ってネットワーク障害が発生した場合、ユーザデバイス１０５は、ネットワーク１５０を介した異なるルート又は経路を使用するにもかかわらず、依然として同じキャッシュ１８０に接続する。従って、ユーザデバイス１０５とロードバランサ１６０の間のエニーキャスト接続により、システム１００は、ジオロケーションを実行するためＤＮＳサーバ１３０に依存するよりも正確に、ユーザデバイス１０５に最も近いロードバランサ１６０を自動的に識別することができる。更に、ＨＴＴＰリダイレクトを使用して、ロードバランサ１６０とのエニーキャスト接続を閉鎖し又は終了し、選択されたキャッシュ１８０へのユニキャスト接続を確立することにより、オブジェクト１８５を取得又はストリーミングするために長いエニーキャスト接続を使用するリスクを回避することができる。

【0018】

図１は、キャッシュ１８０のみがＣＤＮ１７０内にあることを示すが、他の実施形態では、ＤＮＳサーバ１３０及びエッジサーバ１５５は、ロードバランサ１６０と共に、ＣＤＮ１７０の一部とみなすことができる。

【0019】

更に、ストリーミングサーバ１９０、ＤＮＳサーバ１３０、エッジサーバ１５５、及びキャッシュ１８０は、本明細書に列挙された機能を実行するために、１つ以上のプロセッサ、メモリ、ソフトウェアアプリケーション、入出力インターフェース等を含むことができる。

【0020】

図２は、一実施形態による、ＣＤＮからオブジェクトを取得するためのタイミングチャート２００である。タイミングチャート２００は、ユーザデバイス１０５と、ストリーミングサーバ１９０、ＤＮＳサーバ１３０、ロードバランサ１６０、及びＣＤＮ内のキャッシュ１８０の間の様々な通信を示す。矢印２０５は、ＣＤＮから取り出す又はストリーミングするオブジェクトの選択を行うユーザデバイス１０５を示す。この選択はストリーミングサーバ１９０に通信される。ユーザの選択は、ストリーミングサーバ１９０へのサービスコールと呼ぶことができる。これに応答して、矢印２１０は、ストリーミングサーバ１９０が要求されたオブジェクトにＵＲＬ（例えば、図１のオブジェクトＵＲＬ）を提供することを示す。ＵＲＬは、要求されたオブジェクトの名前、説明、又はＩＤを含むことができる。

【0021】

オブジェクトＵＲＬに対応するＩＰアドレスを識別するため、矢印２１５は、ＤＮＳサーバ１３０を使用してＤＮＳルックアップを実行するユーザデバイス１０５を示す。ユーザデバイス１０５は、ユニキャスト接続又はエニーキャスト接続のいずれかを使用して、ＣＤＮに関連付けられた複数のＤＮＳサーバ１３０の１つを選択することができる。例えば、ユーザデバイス１０５がＤＮＳルックアップを実行するためにどのＤＮＳサーバを使用すべきかを既知である可能性があり、その場合、ユニキャスト接続を使用することができる。対照的に、ユーザデバイス１０５はエニーキャスト接続を使用することができ、基礎となるネットワークプロトコルがユーザデバイス１０５への最短経路を有するＤＮＳサーバ１３０を自動的に識別する。本明細書の実施形態はいずれの状況にも限定されない。

【0022】

この例では、ＤＮＳサーバ１３０が、オブジェクトを取得するためにキャッシュ１８０へのＩＰアドレスをユーザデバイスに提供する代わりに、ＤＮＳサーバ１３０は、矢印２２０に示されるように、ＣＤＮによって使用されるロードバランサ１６０の１つに到達するためのエニーキャストアドレスをユーザデバイス１０５に提供する。一実施形態では、ＣＤＮ内のロードバランサ１６０の各々は、同じエニーキャストＩＰアドレスに対応する。ＤＮＳサーバ１３０は、ロードバランサ１６０のエニーキャストＩＰアドレスをユーザデバイス１０５に提供することによって、ＣＤＮ内のコンテンツに対する任意のＤＮＳルックアップに応答するように構成することができる。

【0023】

矢印２２５は、エニーキャストＩＰアドレスを使用してエニーキャストルーティングを実行し、ユーザデバイス１０５への最短経路を有するロードバランサ１６０（及びエッジサーバ）を自動的に識別するユーザデバイス１０５を示す。即ち、エニーキャストルーティングは、ネットワーク内で基礎となるルーティングプロトコル（例えば、ＢＧＰ）を使用し、ネットワーク内でユーザデバイス１０５への最短経路を有する複数のロードバランサのうちのロードバランサ１６０を識別する。

【0024】

次に、ロードバランサ１６０は、１つ以上のロードバランシング基準を使用して、ＣＤＮ内の複数のキャッシュからキャッシュ１８０を選択することができる。ＤＮＳルックアップとは異なり、エニーキャスト接続を確立すると、ロードバランサは要求されたオブジェクトへのフルパスとユーザの真のＩＰを受け取ることができる。従って、この情報により、ロードバランサ１６０は、ＤＮＳサーバがキャッシュを選択する任務を負った場合よりも、様々なロードバランシング戦略を実行し、ユーザデバイス１０５のより正確なジオロケーションを実行することが可能になる。

【0025】

矢印２３０は、ロードバランサ１６０がＨＴＴＰリダイレクトをユーザデバイス１０５に送信して、ユーザデバイス１０５を選択されたキャッシュ１８０にリダイレクトすることを示す。一実施形態では、ＨＴＴＰリダイレクトは、ユーザデバイス１０５とロードバランサの間のエニーキャスト接続を閉鎖するか又は終了させる。更に、ＨＴＴＰリダイレクトは、矢印２３５に示されるように、ユーザデバイス１０５がキャッシュ１８０とのユニキャスト接続を確立できるように情報を提供する。

【0026】

矢印２４０は、要求されたオブジェクトをデバイス１０５に送信するためにユニキャスト接続を使用するキャッシュ１８０を示す。ユーザデバイス１０５とキャッシュ１８０の間の接続は、通常、オブジェクトを取り出すために、ユーザデバイス１０５とロードバランサ１６０の間の接続よりもずっと長い。従って、ユーザデバイス１０５とキャッシュ１８０の間のユニキャスト接続を使用して、エニーキャスト接続がネットワーク障害から受ける影響を回避する。即ち、ユーザデバイス１０５とキャッシュ１８０の間のユニキャスト経路に沿ってネットワーク障害が発生した場合、ユーザデバイス１０５は依然として同じキャッシュ１８０に接続する。ＨＴＴＰリダイレクトを使用して、ロードバランサとのエニーキャスト接続を閉鎖し又は終了し、選択されたキャッシュ１８０へのユニキャスト接続を確立することにより、長いエニーキャスト接続を使用して要求されたオブジェクトを取得又はストリーミングするリスクを回避することができる。

【0027】

タイミングチャート２００を使用して、ユーザデバイス１０５とキャッシュ１８０の間の接続を初期化し、オブジェクトを検索又はストリーミングすることができる。タイミングチャート２００は、オブジェクトをストリーミングする最初の要求の初期化を示すが、チャート２００を使用して、何らかの理由で中断された、既に開始されているストリームを初期化することもできる。例えば、ユーザデバイス１５０がタイミングチャート２００に示される全てのタスクを既に実行し、キャッシュ１８０からオブジェクトのストリーミングを開始していると仮定する。しかし、ユーザデバイス１５０は、ストリーリングのためセルラーネットワークの使用からＷｉ－Ｆｉネットワークの使用に切り替えられたスマートフォンであった。この切り替えにより、ユーザデバイス１０５はストリームを再初期化する必要が生じる可能性がある。次に、ユーザデバイス１０５は、矢印２２５～２４０によって表されるタスクを繰り返して、ストリームを再開することができる。ユーザデバイス１０５はオブジェクトのＩＰアドレス（即ち、ロードバランサ１６０のエニーキャストＩＰアドレス）を既知であるため、矢印２０５及び２２０によって表されるタスクを繰り返す必要はない。それにもかかわらず、ユーザデバイスが現在別のネットワークを使用する場合、ロードバランシングを繰り返して、別のキャッシュ１８０がオブジェクトをストリーミングするのにより適しているかどうかを判断することができる。また、前のキャッシュ１８０に障害が発生したか、メンテナンスのために停止したために再初期化が発生する場合がある。いずれの場合でも、ユーザデバイス１０５は、ロードバランサ１６０（又は異なるロードバランサ１６０）とのエニーキャスト接続を再度確立し、オブジェクトのストリームを再開するために使用する最適なキャッシュ１８０を識別することができる。従って、本明細書の実施形態は、オブジェクトを最初に要求する際にストリームを初期化するときと、前のストリームが中断されたときにストリームを初期化するときの両方に使用することができる。

【0028】

図３は、一実施形態による、ロードバランサを識別するため、エニーキャストルーティングを使用する方法３００のフローチャートである。方法３００は、ＣＤＮから取り出す又はストリーミングするオブジェクトをユーザが選択することに応答して開始することができる。ブロック３０５で、ユーザデバイスはＤＮＳルックアップを実行し、複数のロードバランサのため、エニーキャストＩＰアドレスを受信する。即ち、ロードバランサは同じエニーキャストＩＰアドレスを共有する。

【0029】

ブロック３０５は図２の矢印２１５に対応することができ、ユーザデバイスはユニキャスト接続又はエニーキャスト接続のいずれかを使用し、ＣＤＮに関連付けられた複数のＤＮＳサーバ１３０の１つを選択することができる。例えば、ユーザデバイスは事前に選択されたＤＮＳサーバを使用し、ユニキャスト接続を使用してＤＮＳルックアップを実行することができる。対照的に、ユーザデバイスはエニーキャスト接続を使用して、ユーザデバイスへの最短経路を有するＤＮＳサーバを識別することができる。

【0030】

ブロック３１０で、ユーザデバイスはエニーキャストルーティングを実行し、ＣＤＮに対応する複数のロードバランサの１つへエニーキャスト接続を確立する。即ち、ユーザデバイスは、ＤＮＳサーバから提供されたエニーキャストＩＰアドレスを使用し、エニーキャストルーティングを実行し、ユーザデバイスへの最短経路を有するロードバランサを特定することができる。ユーザデバイスはエニーキャスト接続を使用し、オブジェクトのフルパス名をロードバランサに提供することができる。また、ロードバランサはユーザデバイスの真のＩＰアドレスを受け取ることができるため、バランサは、必要に応じて、ジオロケーションサービスを実行することができる。

【0031】

ブロック３１５で、ロードバランサは複数のキャッシュからキャッシュを決定又は選択し、ロードバランシング基準に基づいてＣＤＮからオブジェクトを取り出す。ロードバランシング基準の非限定的な例は、キャッシュを使用してロードバランサと同じ場所にある（又は最も近い）要求を満たすこと、特定のキャッシュの負荷が閾値を超えないようにすること、要求の最小量が各々のキャッシュに確実に送信されること、メンテナンスのためにすぐに削除されるキャッシュからリクエストをルーティングしないことを含む。他の例では、ロードバランサはオブジェクトの経路名を使用し、どのＣＤＮキャッシュのオブジェクトが既にメモリに格納されているかを判断することができる。しかし、本明細書の実施形態は、特定のロードバランシング技術に限定されない。

【0032】

一実施形態では、ロードバランサは非標準シグナリングを使用し、ユーザデバイスがオブジェクトを取得するために接続を試みる複数のキャッシュを示すことができる。これらのキャッシュは、順序付けされ、重み付けされ、又は他の特定の再試行ポリシーを指定することができる。従って、ロードバランサは、複数のキャッシュから複数のキャッシュを決定又は選択することができる。

【0033】

ブロック３２０で、ロードバランサはＨＴＴＰリダイレクトを開始し、エニーキャスト接続を閉鎖し、ユーザデバイスにキャッシュへのユニキャスト経路を提供する。図２の矢印２３０で示されるように、ロードバランサはＨＴＴＰリダイレクトをユーザデバイスに送信し、ブロック３１５で識別されたキャッシュにユーザデバイスをリダイレクトすることができる。一実施形態では、ＨＴＴＰリダイレクトはユーザデバイスとロードバランサの間のエニーキャスト接続を閉鎖又は終了する。更に、ＨＴＴＰリダイレクトは、ユーザデバイスがキャッシュとのユニキャスト接続を確立できるように、情報（例えば、ユニキャスト経路）を提供する。

【0034】

ブロック３２５で、ユーザデバイスはキャッシュとユニキャスト接続を確立し、オブジェクトを取得する。幾つかの実施形態では、ブロック３１０で、ユーザデバイスとＣＤＮキャッシュの間のユニキャスト接続は、ユーザデバイスとロードバランサの間のエニーキャスト接続よりもはるかに長く確立される。例えば、ユーザデバイスがコンテンツをストリーミングするとき、エニーキャスト接続は１００～３００ミリ秒間継続するのに対し、ユニキャスト接続は（それ以上ではないにしても）数秒間継続する場合がある。従って、ユニキャスト接続を使用してキャッシュからオブジェクトをストリーミングすることにより、最短経路が別のキャッシュに切り替わり、接続の再初期化が強制される可能性があるネットワーク障害に対するエニーキャスト接続の脆弱性が回避される。

【0035】

図４は、一実施形態による、地理的に分散されたロードバランサ及びキャッシュを有するＣＤＮを示す。この例では、ＣＤＮは、領域Ａ、Ｂ、及びＣを含む地理的エリア４００に分散される。各々の地理的領域は、より多くのロードバランサ（ＬＢ）１６０及びキャッシュ１８０を含む。例えば、各領域は、異なる町、州、国、大陸等でＣＤＮによりオペレートされる異なるデータセンタを有することができる。ＬＢ１６０及びキャッシュ１８０は、これらのデータセンタで実行することができる。人口密度が高い又は需要が大きい領域は、複数のデータセンタ、複数のＬＢ１６０及びキャッシュ１８０を有することができる。この例では、ＬＢ１６０は、特定の地域でキャッシュ１８０と同じ場所に配置される（例えば、同じデータセンタによってホストされる）。

【0036】

また、図４は、領域ＢのＬＢ１６０Ｂとのエニーキャスト接続４０５を確立するためにエニーキャストルーティングを使用するユーザデバイス１０５を示す。即ち、図４は、ユーザデバイス１０５がＣＤＮから取り出すオブジェクトを選択し、ＤＮＳルックアップを実行してエニーキャストＩＰアドレスを受信する時点を示す（例えば、図２の矢印２０５～２２０及び図３のブロック３０５）。図示されているように、図４の全てのＬＢ１６０は同じエニーキャストＩＰアドレス、即ち、エニーキャストアドレスＡを有する。エニーキャストアドレスＡを使用したエニーキャストルーティングを実行すると、ネットワークは、ネットワークを介してユーザデバイス１０５に到達する最短の経路を有するものとして、ＬＢ１６０を特定する。例えば、ユーザデバイス１０５は領域Ｂに位置することもできる。従って、ユーザデバイス１０５は、ＬＢ１６０Ｂとのエニーキャスト接続４０５を確立する。

【0037】

この例では、ＬＢ１６０Ｂは、キャッシュ１８０Ｂを、ユーザデバイス１０５が要求されたオブジェクトを取り出し又はストリーミングするための最適なキャッシュとして選択する。例えば、ＬＢ１６０Ｂは、デフォルトで、ＬＢ１６０Ｂと同じ場所に配置されたキャッシュ１８０Ｂをユーザデバイス１０５に最適なキャッシュとして選択することができる。これは、このキャッシュ１８０Ｂもユーザデバイス１０５と同じ領域にあるからである。これに応答して、ＬＢ１６０Ｂは、エニーキャスト接続４０５を終了し、キャッシュ１８０Ｂとのユニキャスト接続４１０Ａを確立するユーザデバイス１０５にＨＴＴＰリダイレクト（図示せず）を送信することができる。ユーザデバイス１０５は、ユニキャスト接続４１０Ａを使用してキャッシュ１８０Ｂからオブジェクトを取り出すことができる。

【0038】

また、図４は、ＬＢ１６０Ｂが代わりに領域Ｃのキャッシュ１８０Ｃをユーザデバイス１０５に最適なキャッシュとして選択することができる代替的実施形態を示す。ユーザデバイスが領域Ｂにあるとしても、キャッシュ１８０Ｃが使用するのに最適なキャッシュである場合がある（例えば、キャッシュ１８０Ｂがメンテナンスのために停止しようとしている、現在過負荷である、又は要求されたオブジェクトを持っていない等の幾つかの理由で）。従って、ＬＢ１６０Ｂは、代わりに、キャッシュ１８０Ｃとのユニキャスト接続４１０Ｂを確立するＨＴＴＰリダイレクトを送信することができる。

【0039】

別の例では、ＬＢ１６０Ｂは、オブジェクトをストリーミングするための最適なキャッシュとして最初にキャッシュ１８０Ｂを選択することができるが、その後変更してキャッシュ１８０Ｃをより良い選択肢として選択することができる。例えば、キャッシュ１８０Ｂからオブジェクトをストリーミングしている最中に、キャッシュ１８０Ｂは、ユニキャスト接続４１０Ａを中断させるエラー又は誤動作に遭遇する場合がある。この場合、ユーザデバイス１０５は、ＬＢ１６０Ｂとのエニーキャスト接続４０５を確立することによって初期化プロセスを繰り返すことができる。ＬＢ１６０Ｂは、キャッシュ１８０Ｂ内のエラーについて通知又は検出されている場合があり、代わりにキャッシュ１８０Ｃを新しいキャッシュとして選択する。ＬＢ１６０Ｂは、ユーザデバイス１０５にキャッシュ１８０Ｃとのユニキャスト接続４１０Ｂを確立させ、ストリームを再開させるＨＴＴＰリダイレクトを提供することができる。好都合なことに、ユーザデバイス１０５は、キャッシュ１８０Ｂを使用したストリームが中断された場所でキャッシュ１８０Ｃを使用してストリームを再開することができる（キャッシュ１８０Ｂ及び１８０Ｃの両方が要求されたオブジェクトのコピーを有すると仮定する）。

【0040】

図５は、一実施形態による、ＨＴＴＰリダイレクトを使用してユーザデバイスにＣＤＮキャッシュへのユニキャスト経路を提供するロードバランサ１６０を示す。図示のように、ユーザデバイス１０５はＨＴＴＰ ＧＥＴ要求５０５を送信し、ロードバランサ１６０に対応するエニーキャストＩＰアドレスを使用してエニーキャストルーティングを実行することができる。ユーザデバイスがオブジェクトを取得するのに最適なキャッシュ（例えば、キャッシュ１８０）を選択した後、ロードバランサ１６０は、ＨＴＴＰリダイレクト５１０でＧＥＴ要求５０５に応答することができる。上述のように、ＨＴＴＰリダイレクト５１０は、エニーキャスト接続を閉鎖し、ユーザデバイス１０５がキャッシュ１８０とのユニキャスト接続を確立するための情報を提供することができる。図示のように、ＨＴＴＰリダイレクト５１０は、キャッシュ１８０へのユニキャスト経路を含むＵＲＬ、即ち、ＨＴＴＰ：／／＜ｃａｃｈｅ ｕｎｉｃａｓｔ＞／ｐａｔｈを含む。

【0041】

ＨＴＴＰリダイレクト５１０に応答して、ユーザデバイス１０５は、ＨＴＴＰ ＧＥＴ要求５１５をキャッシュに送信して、ユニキャスト接続を確立する。次に、ユーザデバイス１０５は、この接続を使用して、要求されたオブジェクトをキャッシュ１８０から取得することができる。

【0042】

本開示では、様々な実施形態が参照される。しかし、本開示は、記載された特定の実施形態に限定されないと理解すべきである。代わりに、異なる実施形態に関連するかどうかにかかわらず、以下のフィーチャ及び要素の任意の組み合わせが、本明細書で提供される教示を実施及び実行することが企図される。更に、実施形態の要素が「Ａ及びＢのうちの少なくとも１つ」の形式で記載される場合、要素Ａのみを含む実施形態、要素Ｂのみを含む実施形態、及び要素Ａ及びＢを含む実施形態が各々企図されると理解される。更に、幾つかの実施形態は、他の可能な解決策又は従来技術に対して利点を達成することができるが、所与の実施形態によって特定の利点が達成されるかどうかは、本開示を限定するものではない。従って、本明細書に開示される態様、フィーチャ、実施形態、及び利点は、単なる例示であり、添付の特許請求の範囲に明示的に記載されている場合を除き、特許請求の範囲の要素又は制限とは解釈されない。同様に、「発明」への言及は、本明細書に開示された発明の主題の一般化として解釈されるべきではなく、特許請求の範囲に明示的に記載されている場合を除き、添付の特許請求の範囲の要素又は限定と解釈されるべきではない。

【0043】

当業者には理解されるように、本明細書に記載の実施形態は、システム、方法、又はコンピュータプログラム製品として具体化することができる。従って、実施形態は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、又は、本明細書中で、「回路」、「モジュール」又は「システム」と称されるソフトウェアとハードウェアのアスペクトを組み合わせた実施形態の形態を取ることができる。更に、本明細書に記載の実施形態は、コンピュータ可読プログラムコードが組み込まれた１つ以上のコンピュータ可読媒体に組み込まれたコンピュータプログラム製品の形態を取ることができる。

【0044】

コンピュータ可読媒体に具現化されたプログラムコードは、無線、有線、光ファイバーケーブル、ＲＦ等、又はこれらの任意の適切な組み合わせを含むがこれらに限定されない任意の適切な媒体を使用して送信することができる。

【0045】

本開示の実施形態のオペレーションを実行するためのコンピュータプログラムコードは１つ以上のプログラム言語の任意の組み合わせで記述することができる。プログラム言語は、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のオブジェクト指向プログラミング言語と、「Ｃ」プログラミング言語又は類似のプログラミング言語等の従来の手続き型プログラミング言語を含む。プログラムコードは、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンドアロンソフトウェアパッケージとして、部分的にユーザのコンピュータ上で、部分的にリモートコンピュータ上で、又は完全にリモートコンピュータ又はサーバ上で実行することができる。後者のシナリオでは、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）等、任意のタイプのネットワークを介してリモートコンピュータをユーザのコンピュータに接続するか、外部コンピュータ（例えば、インターネットサービスプロバイダを使用したインターネット経由）と接続することができる。

【0046】

本開示の態様は、本開示の実施形態による方法、装置（システム）、及びコンピュータプログラム製品のフローチャート又はブロック図を参照して、本明細書で説明される。フローチャート又はブロック図の各々のブロック、及びフローチャート又はブロック図のブロックの組み合わせは、コンピュータプログラム命令によって実行することができると理解される。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、又は他のマシンを形成する他のプログラム可能なデータ処理装置のプロセッサに提供され、コンピュータ又は他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャート又はブロック図のブロックで指定された作用／行為を実行するための手段を作成することができる。

【0047】

また、これらのコンピュータプログラム命令は、コンピュータ、他のプログラム可能なデータ処理装置、又は他のデバイスを特定の方法で機能させることができるコンピュータ可読媒体に格納することができ、これによって、コンピュータ可読媒体に格納された命令が、フローチャート又はブロック図のブロックで特定された機能／行為を実行する命令を含む製品を生成する。

【0048】

また、コンピュータプログラム命令は、コンピュータ、他のプログラム可能なデータ処理装置、又は他のデバイスにロードされ、一連の動作ステップがコンピュータ、他のプログラム可能な装置、又は他のデバイス上で実行され、コンピュータによって実行されるプロセスを生成する。これによって、コンピュータ、他のプログラム可能なデータ処理装置、又は他のデバイス上で実行される命令は、フローチャート又はブロック図のブロックで指定された機能／行為を実行するためのプロセスを提供する。

【0049】

図中のフローチャート及びブロック図は、本開示の様々な実施形態によるシステム、方法、及びコンピュータプログラム製品の可能な実装のアーキテクチャ、機能、及びオペレーションを示す。この点に関して、フローチャート又はブロック図の各々のブロックはモジュール、セグメント、又はコードの一部を表し、これは特定された論理機能を実行するための１つ以上の実行可能な命令を含むことができる。また、幾つかの代替的実施形態では、ブロックに記載された機能が、図に記載された順序とは異なる場合があることに留意すべきである。例えば、連続して示される２つのブロックは、機能に応じて、実際には実質的に同時に実行される場合があり、また、ブロックが逆の順序又は順不同で実行される場合もある。また、ブロック図又はフローチャートの各々のブロック、及びブロック図又はフローチャートのブロックの組み合わせは、指定された機能又は行為を実行する専用ハードウェアベースのシステム、又は専用ハードウェアとコンピュータ命令の組み合わせによって実行することができることに留意すべきである。

【0050】

上記は本開示の実施形態を対象としているが、本開示の他の及び更なる実施形態はその基本的範囲から逸脱することなく創作することができ、その範囲は以下の特許請求の範囲に基づいて定められる。

【図1】

【図2】

【図3】

【図4】

【図5】

【外国語明細書】