JP2017509936A - リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理の、サードパーティによる実行の容易化 - Google Patents

Abstract

この開示の一局面は、リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理をサードパーティ／サーバシステムが行なうことを容易にする。一実施形態では、サーバシステム／サードパーティは、一群の要求から次の要求を選択し、次の要求は、オーナー／ユーザー（ファーストパーティ）によって所有される（セカンドパーティ上でホストされる）保護されたリソースを要求する。サーバシステムは、オーナーに代わってサーバシステムによって保護されたリソースのアクセスを認可するアクセストークンが存在するか否かをチェックする。アクセストークンが存在しない場合、サーバシステムは、アクセストークンを受信するためにオーナーとオフラインモードで通信する。サーバシステムは次に、現在の／受信されたアクセストークンを使用して保護されたリソースにアクセスすることによって、次の要求を処理する。

Description

優先権主張
本特許出願は、ここに全体として援用される以下の同時係属出願に関しており、それらからの優先権を主張する：
Ａ．「リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理の、サードパーティによる実行の容易化」（Facilitating Third Parties To Perform Batch Processing Of Requests Requiring Authorization From Resource Owners For Repeat Access To Resources）と題された、本特許出願と同じ出願人による、２０１４年２月１８日に出願されたインド特許出願連続番号第７５８／ＣＨＥ／２０１４号；および
Ｂ．「リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理の、サードパーティによる実行の容易化」と題された、本特許出願と同じ出願人による、２０１４年６月１０日に出願された米国非仮特許出願連続番号第１４３００２５１号。

開示の背景
技術分野
この開示は企業システムに関し、より特定的には、リソースへの繰返しアクセスについてリソースオーナーから認可（authorization）を要求する要求のバッチ処理をサードパーティが行なうことを容易にすることに関する。

関連技術
リソースとは、ファイル、写真、ユーザー情報などの任意のデータ項目を指す。リソースはしばしば、オーナーによって「所有され」ているものの、他者／セカンドパーティによって格納され管理されている。リソースの所有権は、対応するユーザー（通常は人間）が、セカンドパーティによって管理されるリソースへのアクセスを誰が許可されまたは拒否されるかを制御できる、ということを意味する。そのようなリソースは、「保護されたリソース」と呼ばれる。

オーナーは、適切な認可を付与することによって、リソースのアクセスをサードパーティに許可することができる。リソースへの「繰返し」アクセスを許可することに対する要望がしばしば存在し、これは、単一の認可が時間をかけた複数のアクセスの根拠となり得ることを意味する。ＯＡｕｔｈプロトコルは、１つのオープン標準であり、それは、関連技術において周知であるように、リソースの繰返しアクセスについてのそのような認可をオーナーに代わって可能にする。

要求のバッチ処理が望ましい状況がある。バッチ処理は、いくつかの要求が（適切なバッファリングによって）蓄積され、後の都合の良い時間にバッチして処理される（すなわち、すべての要求の処理が完了するまで、蓄積された要求を処理し続ける）ということを意味する。バッチ処理は一般に、大規模環境において有用である。

この開示の局面は、リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理をサードパーティが行なうことを容易にする。

この開示の例示的な実施形態を、以下に簡単に説明される添付図面を参照して説明する。

この開示のいくつかの局面が実現され得る例示的な環境を示すブロック図である。 一実施形態における、保護されたリソースの認可が実現される態様を示すシーケンス図である。 この開示の一局面に従った、リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理をサードパーティが行なうことが容易にされる態様を示すフローチャートである。 一実施形態における、リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理を行なうサーバの例示的な一実現化例を示す図である。 一実施形態における、異なる時間インスタンスで維持されたクレデンシャルデータの部分を示す図である。 一実施形態における、異なる時間インスタンスで維持されたクレデンシャルデータの部分を示す図である。 この開示のさまざまな局面が、適切な実行可能なモジュールの実行によって作用する、デジタル処理システムの詳細を示すブロック図である。 この開示の別の実施形態における、要求のバッチ処理を行なうためのデジタル処理システムを示すブロック図である。

図面では、同じ参照番号は概して、同一、機能的に同様、および／または構造的に同様の要素を示す。要素が最初に現われる図面は、対応する参照番号における一番左の数字によって示される。

開示の実施形態の詳細な説明
１．概略
この開示の一局面によれば、サーバシステム／サードパーティは、バッチで処理されるべき複数の要求を受信する。サーバシステムは次に、受信された要求から次の要求を選択し、次の要求は、オーナー／ユーザー（ファーストパーティ）によって所有される（セカンドパーティ上でホストされる）保護されたリソースを要求する。サーバシステムは、オーナーに代わってサーバシステムによって保護されたリソースのアクセスを認可するアクセストークンが存在するか否かをチェックする。アクセストークンが存在しない場合、サーバシステムは、アクセストークンを受信するためにオーナーとオフラインモードで通信する。サーバシステムは次に、現在の／受信されたアクセストークンを使用して保護されたリソースにアクセスすることによって、次の要求を処理する。

このため、リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理をサードパーティ／サーバシステムが行なうことが容易にされる。

この開示の別の局面によれば、オフラインモードでオーナーからアクセストークンを受信することは、まず、前記第１の保護されたリソースへのアクセスの非同期認可のためにオーナーに通信を送信することによって実施される。一実施形態では、オーナーに送信された通信はユニフォームリソースロケータ（Uniform Resource Locator：ＵＲＬ）を含み、それは、オーナーによって非同期に選択されると、前記認可付与がサーバシステムに転送されるようにする。（オーナーがＵＲＬを選択したことに応答して）オーナーから第１の保護されたリソースについての認可付与を受信後、アクセストークンが、受信された認可付与を認可サーバに送信することによって取得される。

一実施形態では、保護されたリソースはリソースサーバ上でホストされ、サーバシステム、認可サーバおよびリソースサーバは、保護されたリソースの認可のためにＯＡｕｔｈプロトコルをサポートするために実装される。

例示のために、この開示のいくつかの局面を、例を参照して以下に説明する。しかしながら、関連技術の当業者であれば、この開示は、特定の詳細のうちの１つ以上がなくても、または他の方法、コンポーネント、材料などを用いても実践され得る、ということを認識するであろう。他の例では、この開示の特徴を不明瞭にしないように、周知の構造、材料、または動作は詳細には示されない。さらに、説明される特徴／局面はさまざまな組合せで実践され得るが、簡潔にするために、組合せのうちのいくつかのみをここに説明する。

２．例示的な環境
図１は、この開示のいくつかの局面が実現され得る例示的な環境を示すブロック図である。このブロック図は、エンドユーザーシステム１１０Ａ〜１１０Ｚと、インターネット１２０と、イントラネット１３０と、サーバシステム１４０Ａ〜１４０Ｃと、ＳＯＡ（service-oriented architecture：サービス指向アーキテクチャ）サーバ１５０と、認可サーバ１７０と、データストア１８０とを含んで図示されている。

単なる例示のために、代表的な数／種類のシステムのみを図に示す。多くの環境は、環境が設計された目的に依存して、数および種類の双方においてさらに多くのシステムを含むことが多い。また、企業のシステムは（「ＯＡｕｔｈ２．０認可フレームワーク」と題されたＲＦＣ６７４９に詳細に記載されるような）ＯＡｕｔｈ標準プロトコルに従って実現されると仮定されるが、代替的な実施形態では他の同様のプロトコルが使用可能である。図１の各システム／装置を、以下により詳細に説明する。

イントラネット１３０は、（点線の境界で示された）企業内にすべて設けられている、サーバシステム１４０Ａ〜１４０Ｃ、ＳＯＡサーバ１５０、認可サーバ１７０およびデータストア１８０間の接続性を提供するネットワークを表わす。インターネット１２０は、これら（および企業の他のシステム）と、エンドユーザーシステム１１０Ａ〜１１０Ｚなどの外部システムとの接続性を拡張する。イントラネット１３０およびインターネット１２０の各々は、関連技術において周知である、伝送制御プロトコル（Transmission Control Protocol：ＴＣＰ）および／またはインターネットプロトコル（Internet Protocol：ＩＰ）などのプロトコルを使用して実現されてもよい。一般に、ＴＣＰ／ＩＰ環境では、伝送の基本単位としてＩＰパケットが使用され、ソースアドレスは、パケットが生じるソースシステムに割当てられたＩＰアドレスに設定され、宛先アドレスは、パケットが最終的に配信されることになっている宛先システムのＩＰアドレスに設定される。

（ＩＰ）パケットは、パケットの宛先ＩＰアドレスが宛先システムの（ＩＰ）アドレスに設定される場合、パケットがネットワーク１１０によって最終的に宛先システムに配信されるように、宛先システムに差し向けられると言われている。宛先アプリケーションを特定する、ポート番号などの内容をパケットが含む場合、パケットは、そのようなアプリケーションにも差し向けられると言われ得る。宛先システムは、対応するポート番号を利用可能に／オープンに保ち、パケットを対応する宛先ポートで処理するように要求される場合がある。インターネット１２０およびイントラネット１３０の各々は、ワイヤベースの媒体または無線媒体の任意の組合せを使用して実現されてもよい。

データストア１８０は、サーバシステム１４０Ａ〜１４０Ｃ、ＳＯＡサーバ１５０および認可サーバ１７０といった、企業の他のシステムで実行されるアプリケーションによるデータの集まりの格納および検索を容易にする不揮発性（永続的）ストレージを表わす。データストア１８０は、リレーショナルデータベース技術を使用してデータベースサーバとして実現されてもよく、それに応じて、ＳＱＬ（Structured Query Language：構造化問合せ言語）といった構造化された問合せを使用してデータの格納および検索を提供してもよい。これに代えて、データストア１８０は、関連技術において周知であるように、１つ以上のディレクトリとして編成されたファイルの形をしたデータの格納および検索を提供するファイルサーバとして実現されてもよい。

エンドユーザーシステム１１０Ａ〜１１０Ｚの各々は、企業の特定のシステムに差し向けられるユーザー要求を生成して送信するためにユーザーによって使用される、パーソナルコンピュータ、ワークステーション、モバイルステーション、携帯電話、コンピューティングタブレットなどのシステムを表わす。ユーザー要求は、適切なユーザーインターフェイス（たとえば、企業で実行されるアプリケーションによって提供されるウェブページ）を使用して生成されてもよい。たとえば、ユーザーは、さまざまなタスクを行なうためのユーザー要求を、サーバシステム１４０Ａ〜１４０Ｃで実行されるアプリケーションに送信してもよい。これに代えて、ユーザー／オーナーは、ユーザー要求をインターネット１２０を通して企業のシステムに送信することにより、さまざまな対象リソースを管理（作成、除去、認可／アクセス拒否）してもよい。

サーバシステム１４０Ａ〜１４０Ｃの各々は、企業におけるリソースを保護し、リソースへのアクセスを提供することができる、ウェブ／アプリケーションサーバなどのサーバを表わす（そのため、セカンドパーティを表わす）。アプリケーション、それらのアプリケーションによって提供されるウェブページなどといった保護されたリソースのうちのいくつかは、サーバシステム上でホストされてもよい。これに代えて、保護されたリソース（たとえば、個人データ、画像または映像といったメディアなど）は、バックエンド記憶システム（図示せず）上でホストされてもよく、そのようなリソースのアクセスはサーバシステムによって制御される。例示のために、保護されたリソースは、企業（点線の境界）内でホストされるように図示されている。しかしながら、関連技術の当業者がここの開示を読めば明らかであるように、この開示の特徴は、保護されたリソースが企業の外部のシステム（図示せず）上でホストされ得る（リソースはインターネット１２０を介してアクセスされる）代替的な実施形態で実現されてもよい。

アプリケーションサーバ１６０は、（企業内でホストされる）保護されたリソースのうちのいくつかへのアクセスを望み得るサードパーティアプリケーションを実行することができる、ウェブ／アプリケーションサーバなどのサーバを表わす。サードパーティアプリケーションは、（たとえば、エンドユーザーシステム１１０Ａ〜１１０Ｚから受信された）ユーザー要求を処理するために保護されたリソースへのアクセスを要求する場合がある。一実施形態では、サードパーティアプリケーションは、保護されたリソースの認可を行なうために認可サーバ１７０とともに動作するように設計されている。認可が成功すると、サードパーティアプリケーションは、認可された保護されたリソースに繰返しアクセスしてユーザー要求を処理してもよい。

認可サーバ１７０は、（オーナー／ユーザーによる）保護されたリソースの認可を容易にし、それにより、サードパーティ／アプリケーションがリソースへの繰返しアクセスを要求する要求を処理できるようにする、サーバなどのシステムを表わす。上述のように、認可サーバ１７０および企業の他のシステム（サーバシステム１４０Ａ〜１４０Ｃ、アプリケーションサーバ１６０およびデータストア１８０など）は、ＯＡｕｔｈプロトコルに従ってリソースの認可を行なうように実現される。保護されたリソースのそのような認可が行なわれ得る態様を、例を用いて以下に説明する。

３．保護されたリソースの認可
図２は、一実施形態における、保護されたリソースの認可が図１の環境においてＯＡｕｔｈプロトコルに従って実現される態様を示すシーケンス図である。説明は、アプリケーションサーバ１６０で実行されるサードパーティアプリケーション２１０が、サーバシステム１４０Ｂでホストされる保護されたリソースへのアクセスを要求し、保護されたリソースはエンドユーザーシステム１１０Ａを使用するオーナー／ユーザーによって所有されている、と仮定して続けられる。説明は例示のためにＯＡｕｔｈプロトコルに従って提供されるが、特徴は、対応する環境において適するような他の同様の認可プロトコルを用いて実現されてもよい、ということが理解されるべきである。

サードパーティアプリケーション２１０は、オーナーによって使用されるエンドユーザーシステム１１０Ａに認可要求を送信する（イベント２２０）よう図示されている。認可要求は、保護されたリソース、リソースを要求するサードパーティアプリケーション、要求されるアクセスの数／期間などの詳細を示してもよい。これに応答して、ユーザー／オーナーは、要求された保護されたリソースについて、サードパーティアプリケーションのアクセス権（見ること、修正すること、アクセスの有効期限など）を特定（概して認可）し、その後、認可付与を示す応答を送信（イベント２３０）してもよい。認可付与は、ユーザー／オーナーによって特定された権利を示してもよい。

図示されていないものの、ユーザー／オーナーは、認可を提供する前に、（リソースを保護しているサーバシステム１４０Ｂなどの）セカンドパーティを用いて自分自身を認証することを要求され得る、ということが理解されるであろう。ユーザーの認証（すなわち、ユーザーのアイデンティティの確立）は、当該技術において周知であるように、ユーザーＩＤとパスワードとの組合せを使用するなど、適切な認証手法を使用して行なわれてもよい。認証が成功した後で、ユーザーは、認可付与の一環として所望のアクセス権を特定してもよい。認証および認可は、セカンドパーティによって提供される適切なユーザーインターフェイスを使用して行なわれてもよい。

サードパーティアプリケーション２１０は次に、認可付与を認可サーバ１７０に送信し（イベント２４０）、それは次に、認可付与に対応するアクセストークンを生成し、生成されたアクセストークンを認可付与に対する応答として送信する（イベント２５０）。アクセストークンは、アクセスを要求するサードパーティアプリケーション、保護されたリソース、およびリソースのオーナーによって特定された特定のアクセス権（あらゆる有効期限を含む）の詳細を（典型的には符号化された形で）示してもよい。

サードパーティアプリケーション２１０はその後、サーバシステム１４０Ｂ、すなわちリソースをホストするリソースサーバにアクセストークンを送信し（イベント２６０）、それに応じて、保護されたリソースへのアクセスを提供される（イベント２７０）。アクセストークンの生成後、アクセストークンはその後、（アクセストークンが期限切れになっていないと仮定して）保護されたリソースの繰返しアクセスのために使用されてもよい、ということが理解されるであろう。サードパーティアプリケーション２１０は、保護されたリソースへの繰返しアクセスを容易にするために、認可サーバから受信されたアクセストークンをデータストア１８０に格納してもよい。

このため、サードパーティソフトウェア（２１０）は、オーナーによって提供された認可に基づいて、オーナーに代わって保護されたリソースに繰返しアクセスすることが容易にされる。少なくとも、ＯＡｕｔｈプロトコルに基づいたそのようなアプローチでは、アクセストークンの生成はオーナーの積極的な参加を要求する、すなわち、オーナーは、必要な認可を提供するために「ライブ／オンライン」であるよう要求される、ということが理解されるであろう。

したがって、複数の要求のバッチ処理を行なう場合、いくつかの課題が提示される。関連技術において周知であるように、（以前の異なる時間インスタンスで受信された）複数の要求を（後の時間インスタンスで）バッチでともに処理することは、（「ライブ／オンライン」で行なうことと比較すると）ユーザーとやりとりすることなくバックグラウンドで行なわれることが多い。そのようなアプローチはまた、多数の（何千もの大きさの）ユーザー／オーナーを含み、サードパーティソフトウェアの実行中にユーザー／オーナーが動的に追加されることが多い（図１の企業などの）大規模環境では、実行可能ではない。さらに、アクセストークンの取消し／失効は、アクセストークンの再生成を必要とする場合がある。

この開示のいくつかの局面に従って提供されるＳＯＡサーバ１５０は、上述の欠点のうちのいくつかを克服しつつ、リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理を行なう。周知であるように、ＳＯＡサーバは、適切なビジネスフローの実行によって要求を処理するサーバシステムを表わす。実行されたビジネスフローの活動のうちのいくつかは、サーバシステム１４０Ａ〜１４０Ｃによって露出された１つ以上のウェブサービス（保護されたリソース）への呼出しとして実現され、露出されたウェブサービスは別々のオーナーに属している。ＳＯＡサーバ１５０がそのような保護されたリソース／ウェブサービスへのアクセスを要求する要求のバッチ処理を行なう態様を、例を用いて以下に説明する。

４．要求のバッチ処理
図３は、この開示の一局面に従った、リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理をサードパーティが行なうことが容易にされる態様を示すフローチャートである。このフローチャートは、単なる例示のために、図１のシステム、特にＳＯＡサーバ１５０に関して説明される。しかしながら、関連技術の当業者がここに提供された開示を読めば明らかであるように、特徴は、この開示のさまざまな局面の範囲および精神から逸脱することなく、他のシステムおよび環境でも実現され得る。

加えて、関連技術の当業者には明らかであるように、ステップのうちのいくつかは、特定の環境に適するように、以下に記載されるものとは異なる順序で行なわれてもよい。そのような実現化例の多くは、この開示のいくつかの局面によって網羅されると考えられる。フローチャートはステップ３０１で開始し、そこでは制御が直ちにステップ３１０に進む。

ステップ３１０で、ＳＯＡサーバ１５０は、バッチでの処理のための複数の要求を受信する。要求は、実質的に長い期間（たとえば１日）にわたって広がった以前の異なる時間インスタンスでエンドユーザーシステム１１０Ａ〜１１０Ｚから受信されてもよく、要求は、後の時間インスタンスで処理を開始するためにバッファリングされてもよい。

ステップ３２０で、ＳＯＡサーバ１５０は、処理されるべき次の要求を選択し、選択された要求は、オーナーによって所有される保護されたリソース（たとえばウェブサービス）を要求する。次の要求の選択は、予め定められた選択基準に基づいて、任意の便利な態様で行なわれてもよい。選択基準は、たとえば、受信された時間インスタンス、要求の優先順位などを含む。保護されたリソースは、サーバシステム１４０Ｂ〜１４０Ｃによってホストされ、およびまたは保護されてもよい。

ステップ３３０で、ＳＯＡサーバ１５０は、オーナーに代わって保護されたリソースのアクセスを認可するアクセストークンが存在するか否かをチェックする。チェックは、以前に生成された（かつ、まだ期限切れになっていない／取消されていない）アクセストークンを示すクレデンシャルデータを検査することによって行なわれてもよい。検査動作は、ＯＡｕｔｈプロトコルの規約に従っている。なぜなら、アクセストークンの内容はそのプロトコルによって定義されているためである。要求されている保護されたリソースについてのアクセストークンが存在する場合、制御はステップ３８０に進み、その他の場合、ステップ３５０に進む。

ステップ３５０で、ＳＯＡサーバ１５０は、保護されたリソースへのアクセスの非同期認可のためにオーナーに通信を送信する。上述のようなあらゆる必要な認証などが、そのような非同期認可の一環として行なわれてもよい。

「非同期」という用語は、オーナーは、（同期／オンライン応答モードで要求されるように）実質的に直ちに通信に応答するよう要求されず、後の都合のよい時間（たとえば、数時間／数日中など）に応答できる、ということを意味する。以下に説明される実施形態では通信はＵＲＬであるとして説明されるが、当業者がここに提供された開示を読めば明らかであるように、代替的なアプローチはコード断片（たとえばアプレット）を採用することができる。

ステップ３６０で、オーナーが非同期認可を提供すると、ＳＯＡサーバ１５０は、保護されたリソースについての認可付与を受信する。ステップ３７０で、ＳＯＡサーバ１５０は、図２のイベント２４０および２５０と同様に、認可付与を認可サーバ１７０に送信することによってアクセストークンを取得する。３５０、３６０および３７０のステップは、オフラインモードで、すなわち、オーナーがライブ／オンラインであることを必要とせずに行なわれる、ということが理解されるべきである。

ステップ３８０で、ＳＯＡサーバ１５０は、以前に存在した／取得されたアクセストークンを使用して保護されたリソースにアクセスすることによって、次の要求を処理する（図２のイベント２６０および２７０と同様）。ステップ３９０で、ＳＯＡサーバ１５０は、より多くの要求がバッチで処理されるよう要求されているか否かを判断する。より多くの要求が存在する場合、制御はステップ３２０に進み（それに応じて次の要求が処理される）、その他の場合、ステップ３９９に進む。フローチャートはステップ３９９で終了する。

このように、ＳＯＡサーバ１５０は、リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理を行なう。ＳＯＡサーバ１５０が図３に従って要求のバッチ処理を行ない得る態様を、例を用いて以下に示す。

５．例示的な例
図４Ａ〜４Ｃはともに、一実施形態における、リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理をサードパーティが行なうことが容易にされる態様を示す。図の各々を以下に詳細に説明する。

図４Ａは、一実施形態における、リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理を行なうサーバ（ＳＯＡサーバ１５０）の例示的な一実現化例を示す。大まかに言えば、フロントエンドオーダーアプリケーション（図示せず）が、製品についてのオーダーを生成し、生成されたオーダーを不揮発性ストレージに格納する（たとえば、オーダーデータ４１０をデータストア１８０に格納する）。オーダーは次に、ＳＯＡサーバ１５０で実行されるビジネスフロー（オーダープロセッサ４２０）によってバッチで処理される。

オーダーを処理する一環として行なわれるべき活動のうちの１つは、（オーダーを出した）顧客組織に代わって、個人ウェブサイト（たとえばツイッター（登録商標））をオーダーの現状ステータス（たとえば「オーダー受信」、「オーダー処理開始」、「インボイス作成」など）で周期的に更新することである。個人ウェブサイトは、ユーザーがさまざまなアカウントを作成し、そのようなアカウント上にメッセージを投稿することを可能にする、と仮定される。他のユーザー（フォロワー）が所望のアカウントをフォローしてもよく、それによりフォロワーは、そのような所望のアカウントのメッセージを自動的に受信する。

このように、ＳＯＡサーバ１５０がオーダーステータスを投稿すること（ひいては、顧客組織のアカウントのフォロワーに必要な周期的更新を提供すること）ができるように、ＳＯＡサーバ１５０は、顧客組織のアカウントの認可を提供される必要がある。言い換えれば、アカウントは保護されたリソースとして見られ、それは、顧客組織に代わってアクセスされることになっている。理解され得るように、上述のＯＡｕｔｈは一般に、サードパーティへのそのようなアクセスを提供するために設計されている。しかしながら、要求がバッチで処理される場合、課題がいくつかあり、それらのうちのいくつかは上述されている。

ＳＯＡサーバ１５０は、図４Ａおよび図４Ｂに関して以下に詳細に説明されるように、そのような課題のうちの少なくともいくつかに取組んでいる。

（一実施形態では、データストア１８０に維持された）オーダーデータ４１０は、バッチで処理されるよう求められる（フロントエンドオーダーアプリケーションによって生成され格納された）要求／オーダーの詳細を特定する。オーダープロセッサ４２０は、ＳＯＡサーバ１５０で実行され、かつオーダーのバッチ処理を行なうことが可能にされたビジネスフローを表わす。ビジネスフローの一環として、オーダープロセッサ４２０は、個人ウェブサイト上の顧客のアカウントを、オーダーを処理する現状ステータスで更新するために、サーバシステム１４０Ｃによって露出されたターゲット（ウェブ）サービス４８０を呼出すように設計されている。

したがって、オーダープロセッサ４２０は、（オーダーデータ４１０に維持された）受信されたオーダーからのオーダー／要求の選択に応答して、まず、ターゲットサーバ４８０についてのアクセストークンがすでに存在するか否かを判断するために、クレデンシャルチェッカー４３０とインターフェイス接続する。クレデンシャルチェッカー４３０は、（オーダープロセッサ４２０が個人ウェブサイト上の顧客のアカウントにアクセスできるようにするための）アクセストークンが存在するか否かを判断するために、クレデンシャルデータ４６０を検査する。オフラインモードでアクセストークンを取得するためにクレデンシャルデータが維持され使用され得る態様を、例を用いて以下に説明する。

６．クレデンシャルデータ
図４Ｂおよび図４Ｃは、一実施形態における、異なる時間インスタンスで維持されたクレデンシャルデータ（４６０）のそれぞれの部分を示す。例示のために、クレデンシャルデータも（オーダーデータ４１０とともに）、データベースサーバとして実現されたデータストア１８０に格納されると仮定される。したがって、クレデンシャルデータ４６０は、データベースサーバにおけるデータベースにテーブルの形で維持されて図示されている。しかしながら、代替的な実施形態では、関連技術の当業者がここの開示を読めば明らかであるように、クレデンシャルデータは、他のデータ構造（ツリー、連想配列など）を使用して、および／またはＸＭＬ（Extensible Markup Language：拡張マークアップ言語）などの任意の他のフォーマットで維持されてもよい。

図４Ｂを参照して、ユーザー／オーナーのユニーク識別子を特定する「ユーザーＩＤ」列、ユーザー／オーナーのために生成されたアクセストークンを特定する「アクセストークン」列、アクセストークンがその日まで有効である日を示す「失効日」列、オフラインモードでアクセストークンを取得するための通信が（ＳＯＡサーバ１５０によってオーナー／ユーザーに）送信された日を示す「要求日」列、およびアクセストークンの現状ステータス（「アクティブ」、「失効」、「取消し」、「保留」など）を示す「ステータス」列という５つの列を含むクレデンシャルデータ／テーブル４６０が図示されている。

テーブル４６０の行の各々は、対応するユーザー／オーナーから受信されたアクセストークンの詳細を特定する。上述のように、アクセストークンは、アクセスを要求するサードパーティアプリケーション、保護されたリソース、およびリソースのオーナーによって特定された特定のアクセス権（あらゆる有効期限を含む）の詳細を（符号化された形で）特定する。ステータスが「アクティブ」であり、かつ「アクセストークン」列における対応する値がブランクではない場合、アクセストークンは存在すると考えられる。

このように、保護されたリソースの異なるユーザー／オーナーについてのクレデンシャルデータ（４６０）が、ＳＯＡサーバ１５０によって維持される。要求の処理中、クレデンシャルチェッカー４３０は、顧客のアクセストークンがテーブル４６０に存在するか否かをチェックする。

オーナーに代わってターゲットサービス４８０にアクセスすることをオーダープロセッサ４２０に認可するアクセストークンが存在するシナリオでは、クレデンシャルチェッカー４３０は、アクセストークンをオーダープロセッサ４２０に転送する。オーダープロセッサ４２０は次に、提供されたアクセストークンを使用してターゲットサービス４８０にアクセスし、それにより、個人ウェブサイト上の顧客のアカウントを現状ステータスで更新する。

アクセストークンが存在しないシナリオでは、クレデンシャルチェッカー４３０はまず、（行４９０に示すように）認可を得るべきオーナー／ユーザー、認可の要求が送信された日、「保留」などのステータスといったオーダーの詳細をテーブル４６０に格納する。クレデンシャルチェッカー４３０は次に、アクセストークンを取得するためにターゲットサービス４８０のオーナーがオフラインモードで通信されることになっているという表示を、（ユーザーＩＤなどの他のデータとともに）ＵＲＬジェネレータ４４０に送信する。ＵＲＬジェネレータ４４０は、表示に応答して、（受信されたユーザーＩＤに基づいて判断された）オーナーによって非同期に選択されると保護されたリソースについての認可付与がコールバックサービス４５０に転送されるようにするＵＲＬを生成してオーナーに送信する。そのようなＵＲＬは、任意の便利な態様で生成されてもよい。

ターゲットサービス４８０についての認可付与がコールバックサービス４５０に転送されるようにするＵＲＬフォーマットの一例を、以下に示す。

https://domain-name/authrequest?callbackuri=<http://domain-name/CredentialCallbackService&user-id=578578>
ここで、
「domain-name」は、サードパーティアプリケーションをホストする企業のドメインであり、
「authrequest」は、認可付与を生成するために使用され、ユーザー／オーナーがＵＲＬを選択すると呼出される（たとえば、サーバシステム１４０Ｃまたは認可サーバ１７０によって提供される）サービスの名前であり、
「callbackuri」は、認可付与がＵＲＩ（universal resource identifier：ユニバーサルリソース識別子）に転送されることになっていることを示すキーワードであり、そのキーワードの値（http://domain-name/CredentialCallbackService）として特定されており、
「CredentialCallbackService」は、コールバックサービス（４５０）のアイデンティティであり、
「user-id」は、その人のためにアクセストークンが生成されるユーザー／オーナーＩＤ（たとえば、５７８５７８）を示すキーワードである。

ＵＲＬは次に、たとえば、オーナーのインボックスに送信される電子メールメッセージの一部として、オーナーのモバイル装置（たとえば１１０Ａ）に送信されるショートメッセージサービス（short message service：ＳＭＳ）メッセージの形で、といった公知のやり方でオーナーに配信されてもよい。ＵＲＬはその後、たとえば（場合によっては数日後）、エンドユーザーシステム１１０Ａを使用してインボックスから電子メールにアクセスする際、モバイル装置でＳＭＳメッセージを見ている間、といった後の時間インスタンスで（非同期に）オーナーによって選択されてもよい。オーナーは次に、ＵＲＬを選択し、（保護されたリソースをホストする）サーバシステム１４０Ｃを用いてあらゆる必要な認証を行ない、次に、ターゲットサービス４８０についての（オーナーによって特定された特定の認可を示す）認可付与を作成する。ＵＲＬのフォーマットにより、新たに作成された認可付与はコールバックサービス４５０に転送される。

通信をオーナーに送信後、オーダープロセッサ４２０は（同期通信で要求されるように）通信への返答を待ったりせず、選択されたオーダーおよび／または他のオーダーのバッチ処理を続ける、ということが理解されるであろう。

コールバックサービス４５０は認可付与を受信し、次に、図２のイベント２４０および２５０と同様に認可付与を認可サーバ１７０に送信することによってアクセストークンを取得する。コールバックサービス４５０は次に、新たに取得されたアクセストークンをクレデンシャルデータ４６０の一部として格納し（図４Ｃの行４９５）、次に、アクセストークンが存在するとオーダープロセッサ４２０に通知する。オーダープロセッサ４２０はその後、クレデンシャルデータ４６０から新たに取得されたアクセストークンを検索するためにクレデンシャルチェッカー４３０とインターフェイス接続して、ターゲットサービス４８０へのアクセスを要求するオーダーを処理してもよい。

このように、サードパーティのオーダープロセッサ４２０は、（サーバシステム１４０Ａ〜１４０Ｃなどのセカンドパーティによってホスト／保護された）リソース／ウェブサービスへの繰返しアクセスについてリソースオーナー（ファーストパーティ）から認可を要求するオーダー／要求のバッチ処理を行なうことが容易にされる。

上述の特徴は、さまざまな実施形態において、ハードウェア、実行可能なモジュール、およびファームウェアのうちの１つ以上の所望の組合せとして実現され得る、ということが理解されるべきである。実行可能なモジュールが実行される場合にさまざまな特徴が作用する一実施形態に関して、説明を続ける。

７．デジタル処理システム
図５は、この開示のさまざまな局面が、適切な実行可能なモジュールの実行によって作用する、デジタル処理システム５００の詳細を示すブロック図である。デジタル処理システム５００はＳＯＡサーバ１５０に対応していてもよい。

デジタル処理システム５００は、中央処理装置（central processing unit：ＣＰＵ）５１０、ランダムアクセスメモリ（random access memory：ＲＡＭ）５２０、二次メモリ５３０、グラフィックスコントローラ５６０、表示部５７０、ネットワークインターフェイス５８０、および入力インターフェイス５９０といった１つ以上のプロセッサを含んでいてもよい。表示部５７０以外のすべてのコンポーネントは、関連技術において周知であるようにいくつかのバスを含み得る通信経路５５０を通して互いに通信してもよい。図５のコンポーネントを、以下により詳細に説明する。

ＣＰＵ５１０は、この開示のいくつかの特徴を提供するためにＲＡＭ５２０に格納された命令を実行してもよい。ＣＰＵ５１０は複数の処理部を含んでいてもよく、各処理部は場合によっては特定のタスクのために設計されている。これに代えて、ＣＰＵ５１０は、単一の汎用処理部のみを含んでいてもよい。

ＲＡＭ５２０は、通信経路５５０を使用して二次メモリ５３０から命令を受信してもよい。ＲＡＭ５２０は現在、操作環境５２５および／または他のユーザープログラム５２６（データベースソフトウェアなど）を構成するソフトウェア命令を含んで図示されている。操作環境５２５に加えて、ＲＡＭ５２０は、装置ドライバ、仮想マシンなどの他のソフトウエアプログラムを含んでいてもよく、それらは、他のプログラム／ユーザープログラムの実行のために（共通）ランタイム環境を提供する。

グラフィックスコントローラ５６０は、ＣＰＵ５１０から受信されたデータ／命令に基づいて、表示部５７０への（たとえばＲＧＢフォーマットの）表示信号を生成する。表示部５７０は、表示信号によって規定された画像を表示するための表示画面を含む。入力インターフェイス５９０は、キーボードおよびポインティングデバイス（たとえばタッチパッド、マウス）に対応していてもよく、入力を提供するために使用されてもよい。ネットワークインターフェイス５８０は、（たとえば、インターネットプロトコルを使用して）ネットワークへの接続性を提供しており、ネットワーク（図１の１２０および１３０）に接続された他のシステムと通信するために使用されてもよい。

二次メモリ５３０は、ハードドライブ５３５と、フラッシュメモリ５３６と、リムーバブルストレージドライブ５３７とを含んでいてもよい。二次メモリ５３０は、データ（たとえばＵＲＬの一部）と（図３のステップを実施するための）ソフトウェア命令とを格納していてもよく、それらは、デジタル処理システム５００がこの開示に従ったいくつかの特徴を提供することを可能にする。二次メモリ５３０に格納されたコード／命令は、より速い実行速度のためにＣＰＵ５１０による実行の前にＲＡＭ５２０にコピーされてもよく、または、ＣＰＵ５１０によって直接実行されてもよい。

二次メモリ５３０は、ハードドライブ５３５と、フラッシュメモリ５３６と、リムーバブルストレージドライブ５３７とを含んでいてもよい。データおよび命令のうちのいくつかまたはすべては、リムーバブル記憶部５４０上に提供されてもよく、データおよび命令はリムーバブルストレージドライブ５３７によって読出されてＣＰＵ５１０に提供されてもよい。リムーバブル記憶部５４０は、リムーバブルストレージドライブ５３７がデータおよび命令を読出すことができるように、リムーバブルストレージドライブ５３７と互換性がある媒体および記憶フォーマットを使用して実現されてもよい。このため、リムーバブル記憶部５４０は、コンピュータソフトウェアおよび／またはデータを格納したコンピュータ読取可能（記憶）媒体を含む。しかしながら、コンピュータ（または、概してマシン）読取可能媒体は、他の形態のもの（たとえば、非リムーバブル、ランダムアクセスなど）であり得る。

この文書では、「コンピュータプログラム製品」という用語は、ハードドライブ５３５にインストールされたハードディスクまたはリムーバブル記憶部５４０を概して指すために使用される。これらのコンピュータプログラム製品は、デジタル処理システム５００にソフトウェアを提供するための手段である。ＣＰＵ５１０は、上述のこの開示のさまざまな特徴を提供するために、ソフトウェア命令を検索し、命令を実行してもよい。

ここに使用されるような「記憶媒体」という用語は、マシンを特定のやり方で動作させるデータおよび／または命令を格納する任意の非一時的媒体を指す。そのような記憶媒体は、不揮発性媒体および／または揮発性媒体を含んでいてもよい。不揮発性媒体は、たとえば、記憶メモリ５３０などの光ディスク、磁気ディスク、またはソリッドステートドライブを含む。揮発性媒体は、ＲＡＭ５２０などのダイナミックメモリを含む。記憶媒体のよくある形態は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、ソリッドステートドライブ、磁気テープ、または任意の他の磁気データ記憶媒体、ＣＤ−ＲＯＭ、任意の他の光学データ記憶媒体、穴のパターンを有する任意の物理的媒体、ＲＡＭ、ＰＲＯＭ、およびＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、ＮＶＲＡＭ、任意の他のメモリチップまたはカートリッジを含む。

記憶媒体は、伝送媒体とは別個であるが、伝送媒体とともに使用されてもよい。伝送媒体は、記憶媒体間の情報の転送に関与する。たとえば、伝送媒体は、バス５５０を含むワイヤを含む、同軸ケーブル、銅線および光ファイバーを含む。伝送媒体はまた、電波データ通信および赤外線データ通信中に生成されたものなどの音波または光波の形を取り得る。

図６は、この開示の別の実施形態における、要求のバッチ処理を行なうためのデジタル処理システム６００を示すブロック図である。この開示の原理を実行するために、システム６００のブロックは、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組合わせによって実現されてもよい。上述のようにこの開示の原理を実行するために、図６に記載されたブロックは、組合わされてもよく、またはサブブロックへと分離されてもよい、ということが当業者には理解される。したがって、ここでの説明は、ここに説明される機能的ブロックのあらゆる可能な組合せまたは分離またはさらなる定義をサポートしてもよい。

図６に示すように、サーバシステムにおいて要求を処理するためのシステム６００は、第１の受信部６１０と、選択部６２０と、チェック部６３０と、通信部６４０と、処理部６５０とを含んでいてもよい。第１の受信部６１０は、バッチでの処理のための複数の要求を受信できる。選択部６２０は、複数の要求から次の要求を選択できる。次の要求は、第１のオーナーによって所有される第１の保護されたリソースを要求する。チェック部６３０は、第１のオーナーに代わってサーバシステムによって第１の保護されたリソースのアクセスを認可するアクセストークンが存在するか否かをチェックできる。通信部６４０は、アクセストークンが存在しない場合、アクセストークンを受信するために第１のオーナーとオフラインモードで通信できる。処理部６５０は、アクセストークンを使用して第１の保護されたリソースにアクセスすることによって、次の要求を処理できる。

この開示の一実施形態によれば、通信部は、第１の保護されたリソースへのアクセスの非同期認可のために第１のオーナーに通信を送信するための送信部６４１と、 第１の保護されたリソースについての認可付与を受信するための第２の受信部６４２と、 認可付与を認可サーバに送信することによってアクセストークンを取得するための取得部６４３とを含んでいてもよい。

この開示の一実施形態によれば、通信は、電子メールメッセージまたはショートメッセージサービス（ＳＭＳ）メッセージであり得る。

この開示の一実施形態によれば、通信はユニフォームリソースロケータ（ＵＲＬ）を含んでいてもよく、それは、第１のオーナーによって非同期に選択されると、認可付与がサーバシステムに転送されるようにする。第２の受信部６４２は、第１のオーナーがＵＲＬを選択して第１の保護されたリソースへのアクセスを認可したことに応答して、認可付与を受信してもよい。

この開示の一実施形態によれば、システムは、第１のオーナーを含むオーナーのために生成されたアクセストークンを示すクレデンシャルデータを維持するための維持部６６０をさらに含んでいてもよい。チェックすることは、アクセストークンが第１のオーナーのために存在するか否かを判断するためにクレデンシャルデータを検査することを含んでいてもよい。

この開示の一実施形態によれば、第１の保護されたリソースはリソースサーバ上でホストされ得る。サーバシステム、認可サーバおよびリソースサーバは、保護されたリソースの認可のためにＯＡｕｔｈプロトコルをサポートするために実装されてもよい。

この開示の一実施形態によれば、サーバシステムはサービス指向アーキテクチャ（ＳＯＡ）サーバであり得る。複数の要求は、次の要求が次のオーダーであるように複数のオーダーに対応していてもよい。保護されたリソースは、個人ウェブサイトにおけるアカウントであり得る。第１のオーナーは、アカウントへのアクセスを認可するアドミニストレータであり得る。処理部は、アカウントを次のオーダーの処理の現状ステータスで更新するための更新部６５１を含んでいてもよい。

本明細書全体にわたる「一実施形態」、「ある実施形態」、または同様の文言への言及は、その実施形態に関連して説明された特定の特徴、構造、または特性がこの開示の少なくとも１つの実施形態に含まれる、ということを意味する。このため、本明細書全体にわたる「一実施形態では」、「ある実施形態では」、または同様の文言の出現は、必ずしもそうとは限らないものの、すべて同じ実施形態を指していてもよい。

さらに、この開示の説明された特徴、構造、または特性は、１つ以上の実施形態において任意の好適な態様で組合わされてもよい。上述の説明では、この開示の実施形態の完全な理解を提供するために、プログラミング、ソフトウェアモジュール、ユーザー選択、ネットワークトランザクション、データベース問合せ、データベース構造、ハードウェアモジュール、ハードウェア回路、ハードウェアチップなどの例といった多くの特定の詳細が提供されている。

８．結論
この開示のさまざまな実施形態が上述されてきたが、それらは限定のためではなく単なる例示のために提示されてきた、ということが理解されるべきである。このため、この開示の幅および範囲は上述の例示的な実施形態のいずれによっても限定されるべきでなく、請求項およびそれらの均等物に従ってのみ定義されるべきである。

この開示の機能性および利点を強調する添付物に示された図および／またはスクリーンショットは、単なる例示的な目的のために提示されている、ということが理解されるべきである。この開示は十分に柔軟性があり、構成可能であり、そのため、それは、添付図面に示された以外のやり方で利用され得る。

また、要約書の目的は、一般には特許庁および一般大衆、特に特許もしくは法律用語または言葉遣いに精通していない科学者、エンジニアおよび当業者が、一瞥して本願の技術的開示の性質および本質を迅速に判断できるようにすることである。要約書は、この開示の範囲に関して限定的であるよう全く意図されていない。

Claims (27)

1. サーバシステムにおいて要求を処理する方法であって、前記方法は、
   バッチでの処理のための複数の要求を受信することと、
   前記複数の要求から次の要求を選択することとを含み、前記次の要求は、第１のオーナーによって所有される第１の保護されたリソースを要求し、前記方法はさらに、
   前記第１のオーナーに代わって前記サーバシステムによって前記第１の保護されたリソースのアクセスを認可するアクセストークンが存在するか否かをチェックすることと、
   前記アクセストークンが存在しない場合、前記アクセストークンを受信するために前記第１のオーナーとオフラインモードで通信することと、
   前記アクセストークンを使用して前記第１の保護されたリソースにアクセスすることによって、前記次の要求を処理することとを含む、方法。
2. 前記オフラインモードで通信することは、
   前記第１の保護されたリソースへのアクセスの非同期認可のために前記第１のオーナーに通信を送信することと、
   前記第１の保護されたリソースについての認可付与を受信することと、
   前記認可付与を認可サーバに送信することによって前記アクセストークンを取得することとを含む、請求項１に記載の方法。
3. 前記通信は、電子メールメッセージまたはショートメッセージサービス（ＳＭＳ）メッセージである、請求項２に記載の方法。
4. 前記通信はユニフォームリソースロケータ（ＵＲＬ）を含み、それは、前記第１のオーナーによって非同期に選択されると、前記認可付与が前記サーバシステムに転送されるようにし、
   前記受信することは、前記第１のオーナーが前記ＵＲＬを選択して前記第１の保護されたリソースへのアクセスを認可したことに応答して、前記認可付与を受信する、請求項２または請求項３に記載の方法。
5. 前記第１のオーナーを含むオーナーのために生成されたアクセストークンを示すクレデンシャルデータを維持することをさらに含み、
   前記チェックすることは、前記アクセストークンが前記第１のオーナーのために存在するか否かを判断するために前記クレデンシャルデータを検査することを含む、前述の請求項のいずれかに記載の方法。
6. 前記第１の保護されたリソースはリソースサーバ上でホストされ、前記サーバシステム、前記認可サーバおよび前記リソースサーバは、保護されたリソースの認可のためにＯＡｕｔｈプロトコルをサポートするために実装される、前述の請求項のいずれかに記載の方法。
7. 前記サーバシステムはサービス指向アーキテクチャ（ＳＯＡ）サーバであり、前記複数の要求は、前記次の要求が次のオーダーであるように複数のオーダーに対応しており、
   前記保護されたリソースは、個人ウェブサイトにおけるアカウントであり、前記第１のオーナーは、前記アカウントへのアクセスを認可するアドミニストレータであり、
   前記次のオーダーの前記処理は、前記アカウントを、前記次のオーダーの処理の現状ステータスで更新することを含む、前述の請求項のいずれかに記載の方法。
8. サーバシステムが要求を処理できるようにするための１つ以上のシーケンスの命令を格納する、非一時的なマシン読取可能媒体であって、前記サーバシステムに含まれる１つ以上のプロセッサによる前記１つ以上の命令の実行は、前記サーバシステムが以下のアクションを行なうことを可能にし、前記以下のアクションは、
   バッチでの処理のための複数の要求を受信することと、
   前記複数の要求から次の要求を選択することとを含み、前記次の要求は、第１のオーナーによって所有される第１の保護されたリソースを要求し、前記以下のアクションはさらに、
   前記第１のオーナーに代わって前記サーバシステムによって前記第１の保護されたリソースのアクセスを認可するアクセストークンが存在するか否かをチェックすることと、
   前記アクセストークンが存在しない場合、前記アクセストークンを受信するために前記第１のオーナーとオフラインモードで通信することと、
   前記アクセストークンを使用して前記第１の保護されたリソースにアクセスすることによって、前記次の要求を処理することとを含む、マシン読取可能媒体。
9. 前記オフラインモードで通信することは、
   前記第１の保護されたリソースへのアクセスの非同期認可のために前記第１のオーナーに通信を送信し、
   前記第１の保護されたリソースについての認可付与を受信し、
   前記認可付与を認可サーバに送信することによって前記アクセストークンを取得するための１つ以上の命令を含む、請求項８に記載のマシン読取可能媒体。
10. 前記通信は、電子メールメッセージまたはショートメッセージサービス（ＳＭＳ）メッセージである、請求項９に記載のマシン読取可能媒体。
11. 前記通信はユニフォームリソースロケータ（ＵＲＬ）を含み、それは、前記第１のオーナーによって非同期に選択されると、前記認可付与が前記サーバシステムに転送されるようにし、
    前記受信することは、前記第１のオーナーが前記ＵＲＬを選択して前記第１の保護されたリソースへのアクセスを認可したことに応答して、前記認可付与を受信する、請求項９または請求項１０に記載のマシン読取可能媒体。
12. 前記第１のオーナーを含むオーナーのために生成されたアクセストークンを示すクレデンシャルデータを維持するための１つ以上の命令をさらに含み、
    前記チェックすることは、前記アクセストークンが前記第１のオーナーのために存在するか否かを判断するために前記クレデンシャルデータを検査する１つ以上の命令を含む、請求項９〜１１のいずれかに記載のマシン読取可能媒体。
13. 前記第１の保護されたリソースはリソースサーバ上でホストされ、前記サーバシステム、前記認可サーバおよび前記リソースサーバは、保護されたリソースの認可のためにＯＡｕｔｈプロトコルをサポートするために実装される、請求項９〜１２のいずれかに記載のマシン読取可能媒体。
14. デジタル処理システムであって、
    プロセッサと、
    ランダムアクセスメモリ（ＲＡＭ）と、
    前記ＲＡＭ内で検索されて前記プロセッサによって実行されると、前記デジタル処理システムに要求を処理させる１つ以上の命令を格納するためのマシン読取可能媒体とを含み、前記デジタル処理システムは、
    バッチでの処理のための複数の要求を受信することと、
    前記複数の要求から次の要求を選択することとを行ない、前記次の要求は、第１のオーナーによって所有される第１の保護されたリソースを要求し、前記デジタル処理システムはさらに、
    前記第１のオーナーに代わって前記サーバシステムによって前記第１の保護されたリソースのアクセスを認可するアクセストークンが存在するか否かをチェックすることと、
    前記アクセストークンが存在しない場合、前記アクセストークンを受信するために前記第１のオーナーとオフラインモードで通信することと、
    前記アクセストークンを使用して前記第１の保護されたリソースにアクセスすることによって、前記次の要求を処理することとを行なう、デジタル処理システム。
15. 前記オフラインモードで通信することのために、前記デジタル処理システムは、
    前記第１の保護されたリソースへのアクセスの非同期認可のために前記第１のオーナーに通信を送信することと、
    前記第１の保護されたリソースについての認可付与を受信することと、
    前記認可付与を認可サーバに送信することによって前記アクセストークンを取得することとを行なう、請求項１４に記載のデジタル処理システム。
16. 前記通信は、電子メールメッセージまたはショートメッセージサービス（ＳＭＳ）メッセージである、請求項１５に記載のデジタル処理システム。
17. 前記通信はユニフォームリソースロケータ（ＵＲＬ）を含み、それは、前記第１のオーナーによって非同期に選択されると、前記認可付与が前記サーバシステムに転送されるようにし、
    前記デジタル処理システムは、前記第１のオーナーが前記ＵＲＬを選択して前記第１の保護されたリソースへのアクセスを認可したことに応答して、前記認可付与を受信する、請求項１５または請求項１６に記載のデジタル処理システム。
18. 前記第１のオーナーを含むオーナーのために生成されたアクセストークンを示すクレデンシャルデータを維持することをさらに含み、
    前記チェックすることのために、前記デジタル処理システムは、前記アクセストークンが前記第１のオーナーのために存在するか否かを判断するために前記クレデンシャルデータを検査することを行なう、請求項１４〜１７のいずれかに記載のデジタル処理システム。
19. 前記第１の保護されたリソースはリソースサーバ上でホストされ、前記サーバシステム、前記認可サーバおよび前記リソースサーバは、保護されたリソースの認可のためにＯＡｕｔｈプロトコルをサポートするために実装される、請求項１４〜１８のいずれかに記載のデジタル処理システム。
20. 前記デジタル処理システムはサービス指向アーキテクチャ（ＳＯＡ）サーバであり、前記複数の要求は、前記次の要求が次のオーダーであるように複数のオーダーに対応しており、
    前記保護されたリソースは、個人ウェブサイトにおけるアカウントであり、前記第１のオーナーは、前記アカウントへのアクセスを認可するアドミニストレータであり、
    前記次のオーダーの前記処理は、前記アカウントを、前記次のオーダーの処理の現状ステータスで更新することを含む、請求項１４〜１９のいずれかに記載のデジタル処理システム。
21. サーバシステムにおいて要求を処理するためのシステムであって、前記システムは、
    バッチでの処理のための複数の要求を受信するために構成された第１の受信部と、
    前記複数の要求から次の要求を選択するために構成された選択部とを含み、前記次の要求は、第１のオーナーによって所有される第１の保護されたリソースを要求し、前記システムはさらに、
    前記第１のオーナーに代わって前記サーバシステムによって前記第１の保護されたリソースのアクセスを認可するアクセストークンが存在するか否かをチェックするために構成されたチェック部と、
    前記アクセストークンが存在しない場合、前記アクセストークンを受信するために前記第１のオーナーとオフラインモードで通信するために構成された通信部と、
    前記アクセストークンを使用して前記第１の保護されたリソースにアクセスすることによって、前記次の要求を処理するために構成された処理部とを含む、システム。
22. 前記通信部は、
    前記第１の保護されたリソースへのアクセスの非同期認可のために前記第１のオーナーに通信を送信するために構成された送信部と、
    前記第１の保護されたリソースについての認可付与を受信するために構成された第２の受信部と、
    前記認可付与を認可サーバに送信することによって前記アクセストークンを取得するために構成された取得部とを含む、請求項２１に記載のシステム。
23. 前記通信は、電子メールメッセージまたはショートメッセージサービス（ＳＭＳ）メッセージである、請求項２２に記載のシステム。
24. 前記通信はユニフォームリソースロケータ（ＵＲＬ）を含み、それは、前記第１のオーナーによって非同期に選択されると、前記認可付与が前記サーバシステムに転送されるようにし、
    前記第２の受信部は、前記第１のオーナーが前記ＵＲＬを選択して前記第１の保護されたリソースへのアクセスを認可したことに応答して、前記認可付与を受信するために構成されている、請求項２３に記載のシステム。
25. 前記第１のオーナーを含むオーナーのために生成されたアクセストークンを示すクレデンシャルデータを維持するために構成された維持部をさらに含み、
    前記チェックすることは、前記アクセストークンが前記第１のオーナーのために存在するか否かを判断するために前記クレデンシャルデータを検査することを含む、請求項２４に記載のシステム。
26. 前記第１の保護されたリソースはリソースサーバ上でホストされ、前記サーバシステム、前記認可サーバおよび前記リソースサーバは、保護されたリソースの認可のためにＯＡｕｔｈプロトコルをサポートするために実装される、請求項２５に記載のシステム。
27. 前記サーバシステムはサービス指向アーキテクチャ（ＳＯＡ）サーバであり、前記複数の要求は、前記次の要求が次のオーダーであるように複数のオーダーに対応しており、
    前記保護されたリソースは、個人ウェブサイトにおけるアカウントであり、前記第１のオーナーは、前記アカウントへのアクセスを認可するアドミニストレータであり、
    前記処理部は、前記アカウントを、前記次のオーダーの処理の現状ステータスで更新するために構成された更新部を含む、請求項２５に記載のシステム。

Images