特許 7467569 コンテンツ配信ネットワークでのプログレッシブオブジェクトのリフレッシュ

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-04-05

(45)【発行日】2024-04-15

(54)【発明の名称】コンテンツ配信ネットワークでのプログレッシブオブジェクトのリフレッシュ

(51)【国際特許分類】

   H04L 67/1074 20220101AFI20240408BHJP

   H04L 67/568 20220101ALI20240408BHJP

【ＦＩ】

H04L67/1074

H04L67/568

【請求項の数】 20

【外国語出願】

(21)【出願番号】P 2022176023

(22)【出願日】2022-11-02

(65)【公開番号】P2023070133

(43)【公開日】2023-05-18

【審査請求日】2023-01-10

(31)【優先権主張番号】17/518,764

(32)【優先日】2021-11-04

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

(73)【特許権者】

【識別番号】504399716

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

(74)【代理人】

【識別番号】100101502

【弁理士】

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

(72)【発明者】

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

(72)【発明者】

【氏名】ルイス エー クルス

(72)【発明者】

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

(72)【発明者】

【氏名】ジェフリー エドウィン グラッブ

【審査官】小林 義晴

(56)【参考文献】

【文献】特開２０１５－２０１１７８（ＪＰ，Ａ）

【文献】中国特許出願公開第１１３４０７８７６（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ６７／１０７４

Ｈ０４Ｌ ６７／５６８

(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】

このプロセスは、エッジサーバにキャッシュされた多くのオブジェクト（又は全てのキャッシュオブジェクト）をリフレッシュするために使用できるため、オリジンデータセンタとエッジサーバを接続するネットワークに大きな負荷がかかる可能性がある。この負荷を制御又は制限するために、オリジンデータセンタは、一度にタグの一部のみを変更することにより、バッチで強制リフレッシュを実行する場合がある。例えば、オリジンデータセンタでは、毎週タグの４分の１だけを変更することで、エッジサーバにキャッシュされた全てのオブジェクトを４週間にわたって強制的にリフレッシュすることができる。有利なことに、本明細書の実施形態を使用して、ＣＤＮは、ネットワークを圧倒しない制御された方法で強制リフレッシュを実行することによって、小規模又は大規模なデータ破損事故から回復できる。

【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】

強制リフレッシュを再開した後、ブロック３２０で、回復モジュールは図３で説明した手法のいずれかを使用してバッチが完了したかを判断する。このバッチはブロック５１０で選択された元のバッチであってもよく、強制リフレッシュが停止された後に実行された縮小されたバッチであってよい。バッチが完了した場合、方法５００は図３のブロック３２５に進み、全てのバッチが完了したかを判断し、完了していない場合、新しいバッチを選択する。現在のバッチが完了していない場合、方法５００はブロック５１５に戻り、現在のバッチの強制リフレッシュを継続的に監視して、それを停止する必要があるかどうかを確認する。

【0051】

要約すると、方法５００は、特定のオブジェクトが強制的にリフレッシュされるのを除外し、ネットワーク又はコンピューティングの問題に応答して、現在のバッチを停止する技術を説明する。

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【図1】

【図2】

【図3】

【図4】

【図5】