(57)【特許請求の範囲】
【請求項１】
保護されたウェブサービスリソースへのアクセスを制御するコンピューティングシステムであって、
通信ネットワークを介して通信する通信デバイスと、
前記通信デバイスに通信可能に接続されたプロセッサと、
プログラム命令を保存するメモリであって、前記プログラム命令が前記プロセッサによって実行されると、前記コンピューティングシステムに、
前記保護されたウェブサービスリソースにアクセスするリクエストを前記通信ネットワークから受信することと、
前記保護されたウェブサービスリソースへのアクセスに対し認可が要求されるかを判定することと、
前記認可が要求される場合に、前記リクエストのステータスに関するデータを格納するリクエストリソースを発生し、格納することであって、前記リクエストリソースは、前記保護されたウェブサービスリソースへのアクセスが認可されているかを識別するデータを収容することを含むことと、
前記保護されたウェブサービスリソースにアクセスするリクエストが認可されているかを判定することと、
前記リクエストが認可されている場合、前記リクエストリソースに前記保護されたウェブサービスリソースへのアクセスが認可された旨を示すデータを格納し、同時に前記保護されたウェブサービスリソースへのアクセスを許可することと、
前記リクエストが認可されていない場合、前記保護されたウェブサービスリソースへのアクセスを拒否することと
を備えた動作を行わせる、メモリと
を備えたことを特徴とするコンピューティングシステム。
【請求項２】
前記リクエストを受信することは、ｃｒｅａｔｅ（クリエイト）メッセージを受信することを備えたことを特徴とする請求項１に記載のコンピューティングシステム。
【請求項３】
前記リクエストリソースは、拡張マークアップ言語によって定義されることを特徴とする請求項１に記載のコンピューティングシステム。
【請求項４】
前記リクエストリソースは、
行われる動作の識別子を格納する第１のエレメントと、
前記保護されたウェブサービスリソースにアクセスするリクエストの現在のステータスの識別子を格納する第２のエレメントと、
を備えたことを特徴とする請求項３に記載のコンピューティングシステム。
【請求項５】
前記リクエストリソースは、ｓｔａｔｕｓ（ステータス）エレメント、ｄｅｔａｉｌ（ディテール）エレメント、ａｐｐｒｏｖａｌ  ｐｒｏｃｅｓｓ（アプルーバルプロセス）エレメント及びｄａｔａ（データ）エレメントのコピーを格納するｒｅｑｕｅｓｔ（リクエスト）エレメントをさらに備えたことを特徴とする請求項４に記載のコンピューティングシステム。
【請求項６】
前記保護されたウェブサービスリソースにアクセスするリクエストが認可されているかを判定することは、前記リクエストが前記リクエストリソースから認可されているかを識別するデータを取得することを備えたことを特徴とする請求項１に記載のコンピューティングシステム。
【請求項７】
前記保護されたウェブサービスリソースへのアクセスを拒否することは、前記ネットワークを介してフォールト（ｆａｕｌｔ）メッセージを送信することを備えたことを特徴とする請求項１に記載のコンピューティングシステム。
【請求項８】
前記保護されたウェブサービスリソースへのアクセスを許可することは、前記保護されたリソースを変更すること、前記保護されたリソースを修正すること、前記保護されたリソースに追加すること、前記保護されたリソースを削除すること、前記保護されたリソースを修正すること及び前記保護されたリソースを使用することを備えたグループから選択された動作をさらに備えたことを特徴とする請求項１に記載のコンピューティングシステム。
【請求項９】
コンピューティングシステム内のウェブサービスリソースへのアクセスを認可する方法であって、前記コンピューティングシステム内のコンピューティングデバイスが、
ウェブサービスリソースを識別するリクエスタからのリクエストを受信することと、
認可が前記ウェブサービスリソースにアクセスするために要求されることを判定することと、
前記認可が要求される場合に、前記リクエストのステータスに関するデータを格納するリクエストリソースを発生し、格納することであって、前記リクエストリソースは、前記保護されたウェブサービスリソースへのアクセスが認可されているかを識別するデータを収容することを含むことと、
前記ウェブサービスリソースにアクセスするために前記リクエスタを認可するオーソライザからの認可を受信することと、
前記リクエストリソースに前記保護されたウェブサービスリソースへのアクセスが認可された旨を示すデータを収容し、同時に前記保護されたウェブサービスリソースへのアクセスを許可することと、
前記リクエスタのステータス照会に応答して、前記認可を前記リクエスタに通知することと、
を備えることを特徴とする方法。
【請求項１０】
コンピュータによって実行されると保護されたリソースへのアクセスを認可する方法を行うコンピュータ実行可能命令を収容したコンピュータ可読記憶媒体であって、前記方法は、
ウェブサービスの前記保護されたリソースを識別するリクエスタからのリクエストを受信することとであって、前記リクエストを受信することは、
認可が前記保護されたウェブサービスリソースへのアクセスに要求されるかを判定することと、
前記リクエストのステータスに関するデータを格納するリクエストに関連するリクエストリソースを発生し、格納することであって、前記リクエストリソースは、前記リクエストが認可されているかを識別するデータを収容することを含むことと、
前記ウェブサービスの前記保護されたリソースの使用を認可する認可を受信することと、
前記リクエストが認可されていることを判定することと、
前記リクエストリソースに前記リクエストが認可された旨を示すデータを格納し、同時に前記保護されたウェブサービスリソースへのアクセスを許可することと、
前記リクエスタのステータス照会に応答して前記認可を前記リクエスタへ通知することと、
を備えることを特徴とするコンピュータ可読記憶媒体。
【請求項１１】
前記方法は、前記リクエストが認可されていることを判定することの後に前記保護されたリソースへのアクセスを可能にすることをさらに備えることを特徴とする請求項１０に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【背景技術】
【０００１】
ウェブサービスは、近年、人、情報及びプロセスをさらに結び付ける方法として発展してきた。ウェブサービスの利点の１つは、ウェブサービスが複数のプラットフォームに亘って動作する能力及びウェブサービスに変更をすることができる容易性である。ウェブサービスがそれほど成功した理由の１つは、構造化データを表現し、伝送するための標準言語及び共通言語として、プログラミング言語、ソフトウェアプラットフォーム及びハードウェアに依存しないＸＭＬの使用である。
【発明の概要】
【発明が解決しようとする課題】
【０００２】
ウェブサービスリソースが適切な人またはシステムによってのみアクセスまたは使用できるように、リソースを保護することが望まれる状況が多く存在する。ウェブサービスリソースを保護する従来の方法は、認証に焦点が当てられ、特に信頼関係を定義することに焦点が当てられている。従来のシステムは、しばしば、信頼された場所からウェブサービスにアクセスする任意の人またはデバイスが、ウェブサービス及び関連するリソースにアクセスできるようにしている。これらの従来のシステムは、ウェブサービスへアクセスするか、またはウェブサービスの使用する特定の要求に対する認可を提供する第三者のための方法を提供しない。むしろ、ウェブサービスは、しばしば、信頼された場所から通信するいかなる人をも信頼するように構成されている。これらの及びその他の問題は、本発明による様々な実施態様によって対処される。
【課題を解決するための手段】
【０００３】
本発明の実施形態は、概してウェブサービスを伴う認可に関する。１つの非限定的な例において、ウェブサービスは、保護されたリソースを含む。リクエスタ（requester）は、保護されたリソースに関してウェブサービスにリクエストを送る。認可がオーソライザ（authorizer）からウェブサービスによって受け取られるまで、ウェブサービスは、保護されたリソースへのアクセスを禁止するように動作する。
【０００４】
本明細書で議論されるように、いくつかの実施形態の態様は、保護されたウェブサービスリソースへのアクセスを制御するコンピューティングシステムに関する。コンピューティングシステムは、通信デバイス、プロセッサ及びメモリを含む。通信デバイスは、通信ネットワークを介して通信する。プロセッサは、通信デバイスに通信可能に接続される。メモリは、プログラム命令を格納し、このプログラム命令は、プロセッサによって実行されるとコンピューティングシステムに、保護されたウェブサービスリソースへのアクセスのリクエストを通信ネットワークから受け取る動作と、保護されたウェブサービスリソースへのアクセスのリクエストが認可されているかを判定する動作と、リクエストが認可されていない場合には、保護されたウェブサービスリソースへのアクセスを拒否する動作と、リクエストが認可されている場合には、保護されたウェブサービスリソースへのアクセスを許可する動作とを行わせる。
【０００５】
いくつかの実施形態の別の態様は、ウェブサービスリソースへのアクセスを認可する方法に関する。この方法は、ウェブサービスリソースを識別するリクエスタからのリクエストを受け取ることと、ウェブサービスリソースへのアクセスに認可が要求されることを判定することと、ウェブサービスリソースにアクセスするためにリクエスタを認可するオーソライザからの認可を受け取ることと、認可をリクエスタに通信することとを含む。
【０００６】
いくつかの実施形態のさらなる態様は、コンピュータによって実行されると、保護されたリソースへのアクセスを認可する方法を実行するコンピュータ実行可能命令を収容したコンピュータ可読媒体に関する。この方法は、ウェブサービスの保護されたリソースを識別するリクエストを受け取ることと、ウェブサービスの保護されたリソースの使用を認可許可する認可を受け取ることと、リクエストが認可されていることを判定することと、認可をリクエスタに通信することとを含む。
【０００７】
この発明の概要は、発明を実施するための形態において以下にさらに説明されている概念の抜粋を単純化した形式で紹介するために提供されている。この発明の概要は、請求項に記載された事項の重要なまたは本質的な特徴を特定することを意図しておらず、どのような方法であれ、請求項に記載された事項の範囲を限定するために使用されることも意図していない。
【図面の簡単な説明】
【０００８】
【図１】例示の認可システムのブロック図である。
【図２】図１の認可システムの態様を実装する例示のコンピューティングシステムの図である。
【図３】ウェブサービスリソースへのアクセスを認可する方法の一例を示したフロー図である。
【図４】ウェブサービスリソースへのアクセスを認可する方法の別の例を示したフロー図である。
【図５】図４に示されたウェブサービスリソースへのアクセスを認可する方法の一例をさらに示したフロー図である。
【発明を実施するための形態】
【０００９】
本開示は、これから、特定の実施形態が示されている添付の図面を参照して例示の実施形態をさらに完全に説明することになる。しかし、他の態様も多くの異なった形態で具現でき、本開示の特定の実施形態に含まれるものは、このような態様を本明細書で説明される実施形態に限定するものとして解釈されるべきではない。図面に描かれた実施形態は、詳細で完全であり、意図された範囲を当業者に十分に伝達する開示を提供するために含められている。図を参照するとき、全体を通じて示される同様の構造及び要素は、同様の参照符号で示されている。
【００１０】
本開示の実施形態は、概してウェブサービスを伴う認可に関する。１つの非限定的な例において、ウェブサービスは、保護されたリソースを含む。リクエスタは、保護されたリソースに関してウェブサービスへリクエストを送る。ウェブサービスは、認可がウェブサービスによってオーソライザから受け取られるまで、保護されたリソースへのアクセスを禁止するように動作する。
【００１１】
図１は、例示の認可システム１００のブロック図である。認可システム１００は、リクエスタ１０２、ウェブサービス１０４、保護リソース（protected resource）１０６及びオーソライザ１０８を含む。リクエスタ１０２、ウェブサービス１０４及びオーソライザ１０８は、全てネットワーク１１０に通信可能に接続されている。
【００１２】
１つの実施形態において、リクエスタ１０２は、ネットワーク１１０を介してウェブサービス１０４とデータ通信するコンピューティングシステムであり、図２に示されたコンピューティングシステム２００等である。いくつかの実施形態において、リクエスタ１０２は、ユーザインタフェースを通じてコンピューティングシステムに入力を提供し、コンピューティングシステムに対して決定を下すユーザからの入力を受け取る。ユーザは、ディスプレイ、マウス、キーボード等、１または複数のユーザインタフェースを通じてコンピューティングシステムと対話（interact）する。いくつかの実施形態において、リクエスタ１０２は、ネットワーク１１０を介してウェブサービス１０４とハイパーテキスト転送プロトコル（ＨＴＴＰ）等のネットワークプロトコルを使用して通信するインターネットエクスプローラ（INTERNET EXPLORER）（登録商標）インターネットブラウザ等のブラウザソフトウェアアプリケーションを動作させる。他の実施形態において、インターネットブラウザ以外の１または複数のソフトウェアアプリケーションがリクエスタ１０２上で動作する。例示の実施形態において、リクエスタ１０２は、ウェブサービス１０４の保護リソース１０６にアクセスすることを求める。
【００１３】
１つの実施形態において、ウェブサービス１０４は、ウェブサービスを動作させるウェブサーバ等のコンピューティングシステムである。一般に、ウェブサービス１０４は、保護リソース１０６を伴う有用な機能を提供する。ウェブサービスは、ネットワークプロトコルを使用してネットワーク１１０を通じてアクセスすることができる。ウェブサービスは、際限なく多様な有用な機能を提供するために使用することができる。１つの例は、カレンダーサービスである。クライアントは、カレンダーに約束を追加する等、リクエストをサーバに提供する。ウェブサービスは、クライアントの約束を格納する。後に、クライアントは、格納された約束を見るためにリクエストすることができ、この約束はウェブサービスによって提供される。可能なウェブサービスの他の例は、電子メール配信リストを維持するサービスである。クライアントは、メーリングリストに格納すべきユーザを識別する。サーバは、クライアントのためのリストを格納する。後に、クライアントは、メッセージがサーバによって配信リストの全てのメンバに送られることをリクエストすることができる。ウェブサービスは、リクエストされた機能を行う。可能なウェブサービスの他の例は、ユーザネームを、システム管理者のグループ等のセキュリティグループに追加すること、所与のアクションの認可要件を変更すること、人事スタッフのメンバまたは緊急作業員によってリクエストされたとき等にユーザの個人情報へのアクセスを提供すること、並びに、特定のユーザグループ及び／または本明細書に記載されたプロセス等によって、レコード（record）にアクセスすることを特別に認可されている人々にレコードへのアクセスを限定することを含む。
【００１４】
ウェブサービス１０４の一例は、図２に示されたコンピューティングシステム２００である。ウェブサービス１０４は、ネットワーク１１０を介して、リクエスタ１０２及びオーソライザ１０８とデータ通信する。ウェブサービスの一例は、Service Oriented Architecture Protocolとも称されるSimple Object Access Protocol（ＳＯＡＰ）に従ってネットワーク１１０を介して通信するように構成されたコンピューティングシステムである。ＳＯＡＰは、ワールドワイドウェブの国際標準組織であるワールドワイドウェブコンソーシアムのＸＭＬプロトコルワーキンググループによって、現在、維持管理されているプロトコルである。ＳＯＡＰは、拡張マークアップ言語（ＸＭＬ）を標準のメッセージフォーマットとして利用する。１つの実施形態において、ＳＯＡＰメッセージは、ＨＴＴＰ１．１等のＨＴＴＰを使用して交換される。
【００１５】
ＨＴＴＰは、リクエストで始まり、レスポンスで終わる通信のパターンを定義する転送プロトコルである。リクエストメッセージは、（リクエスタ１０２からウェブサービス１０４へ等）クライアントからサーバへ送信されるメッセージであり、一般に、リクエスト、ヘッダ、ブランク行（blank line）及びメッセージボディ（message body）を含む。リクエストは、メッセージに関するリソースの識別を含む。ＨＴＴＰは、識別されたリソース上で行われる所望のアクションを示す複数のリクエストメソッドを定義する。ＨＴＴＰリクエストメソッドの一例は、Get（ゲット）メソッドである。Getメソッドは、識別されたリソースの表現、またはコピーをリクエストする。ＨＴＴＰリクエストメソッドの別の例は、Put（プット）メソッドである。Putメソッドは、識別されたリソースの表現をアップロードする。Getコマンドを収容するリクエストメッセージは、GetメッセージまたはGetリクエストと称される。Putコマンドを収容するリクエストメッセージは、PutメッセージまたはPutリクエストと称される。リクエストがウェブサーバによって受信された後、ウェブサーバはクライアントにレスポンスを提供する。レスポンスは、ステータス行（status line）、ヘッダ、ブランク行及びメッセージボディを含む。ステータス行は、ステータスコード及びテキストの理由フレーズ（textual reason phrase）（「Not Found」等）を含む。レスポンスのコンテンツは、リクエストのコンテンツに依存する。例えば、Getメッセージへのレスポンスは、リクエストのとおり、識別されたリソースの表現を含むことになる。
【００１６】
ＳＯＡＰは、ＳＯＡＰフォールト（SOAP fault）と称されるメッセージフォーマットも定義する。ＳＯＡＰフォールトは、一般に、ＳＯＡＰメッセージフォーマットでエラー情報を伝達するために使用される。ＳＯＡＰフォールトは、リクエストに従ってクライアントにレスポンスを通信するためにウェブサーバによって使用することができる。１つの例において、ＳＯＡＰ１．２が使用され、そのＳＯＡＰフォールトは、コンテキストヘッダ（context header）及びボディを収容するようにする。コンテキストヘッダは、オリジナルリクエストを識別する識別子及びそのリクエストに関連すると判明した任意の認可プロセスを含む。ボディは、本明細書に記載されている詳細エレメント（element）のコンテンツを含む。詳細エレメントのコンテンツは、リクエストされたリソースが、ウェブサービスがさらに処理を続行できる前に認可を要求することを知らせる。
【００１７】
別の実施形態において、ウェブサービス１０４との通信は、ＷＳ−ＲＴ（Web Service Resource Transfer）プロトコルに準拠しているＳＯＡＰ通信を伴う。ＷＳ−ＲＴは、ウェブサービスベースのリソースの表現にアクセスするための通信プロトコルを定義する。ＷＳ−ＲＴは、Create（クリエイト）メッセージ、Getメッセージ及びPutメッセージを含む。Createメッセージは、ＸＭＬ表現等のオブジェクトの表現を発生するために使用される。所望の表現は、Createメッセージのボディに含まれる。Getメッセージは、リソースの表現のフラグメント（fragment）の表現を取得するために使用することができる。表現のフラグメントは、表現の全体を取得する必要はないような表現の一部である。Getメッセージは、所望のオブジェクトの固有の識別子をメッセージのヘッダに含む。従って、Getメッセージは、固有の識別子が既に知られている単一のオブジェクトをリクエストするために使用される。Putメッセージは、リソースに表現または表現のフラグメントをアップロードするために使用することができる。ＷＳ−ＲＴは、フォールト動作を定義して、クライアントへレスポンスを通信する。本明細書内で使用されるように、Get、Put及びFault（フォールト）メッセージは、特定のプロトコルが具体的に特定されない限り、様々なプロトコル（ＨＴＴＰ、ＳＯＡＰ及び様々なウェブサービスプロトコル）を包含する一般タイプのメッセージを参照する。
【００１８】
別の実施形態は、ＷＳ−列挙（Enumeration）プロトコルを使用する。ＷＳ−列挙プロトコルもワールドワイドウェブコンソーシアムによって維持管理されている。ＷＳ−列挙は、列挙（enumerate）メッセージを定義する。列挙メッセージは、クエリの表現とともに送信される。１つの実施形態において、クエリは、ＸＰａｔｈ言語で書かれる。１つの例として、クエリは、ある基準のセットにマッチした全てのリソースの表現をリクエストする。ウェブサービスは、列挙コンテキストの識別子とともに列挙メッセージにレスポンスをする。クライアントは、その後、列挙コンテキスト識別子を含むPullメッセージを送り、クエリにマッチするいくつのオブジェクトが取得されるべきかを指定する。ウェブサービスは、その後、クエリにマッチするリソースの指定された数とともにレスポンスする。後続のPullメッセージが、その後、サーバに送られて、クエリにマッチするリソースの別のバッチ（batch）取得することができる。このプロセスは、本明細書において、列挙メッセージを送り、レスポンスを受け取るとい一般に参照されることがある。列挙メッセージの利点の１つは、クライアントがある基準にマッチする任意数のリソースをクエリすることを可能にすることである。
【００１９】
別の実施形態は、ＷＳ−Ｔｘ（Web Service Transfer）プロトコルを利用する。他の有用な機能に加えて、ＷＳ−Ｔｘは、保護リソースを削除するdeleteメッセージを定義する。
【００２０】
例示の実施形態において、ウェブサービス１０４は、保護リソース１０６を含む。保護リソースには、例えば、認可されたクライアントによってのみアクセスされ、使用されまたは変更され得る、ウェブサービス１０４によって行われる機能及びウェブサービス１０４によって格納されるデータが含まれる。例えば、ウェブサービス１０４がグループ配信リストを維持管理するサービスを提供する場合、このグループ配信リストは、認可されたクライアントによってのみアクセスされ、使用されまたは変更され得る保護リソースである。別の例として、保護リソース１０６は、ディレクトリ内のエントリ（entry）である。別の実施形態において、保護リソース１０６は、データベース内のレコード（record）である。別の実施形態において、保護リソース１０６は、メモリ記憶デバイスに格納されたファイルまたはファイルの一部である。他の実施形態は、他の形式の保護リソース１０６を使用する。
【００２１】
用語「アクセス」は、本明細書において、保護リソース１０６の任意の変更、修正、追加、削除または使用を参照するのに使用されるときがある。いくつかの実施形態において、保護リソース１０６の使用は、保護リソース１０６に格納されたデータを取得することを含む。いくつかの実施形態において、非認可のクライアントが、保護リソース１０６へのアクセスを得ることができる。例えば、ネットワーク管理者は、いくつかの実施形態において、オーソライザによる特別な認可が無くてもアクセスが可能である。
【００２２】
可能な実施形態において、オーソライザ１０８は、ウェブサービス１０４とデータ通信をするコンピューティングシステムである。いくつかの実施形態において、オーソライザ１０８は、ネットワーク１１０を介してウェブサービス１０４にメッセージを通信することが可能なソフトウェアを動作させる。例えば、オーソライザ１０８は、マイクロソフト（MICROSOFT）（登録商標）アウトルック（OUTLOOK）（登録商標）メッセージング及びコラボレーションクライアントを動作させる。メッセージング及びコラボレーションクライアントは、ネットワーク１１０を介して、ウェブサービス１０４に電子メッセージを送信することが可能である。例示の実施形態において、ウェブサービス１０４は、オーソライザ１０８に依拠してユーザが保護リソース１０６を使用するように認可されるべきか否かを判定する。いくつかの実施形態において、オーソライザ１０８及びウェブサービス１０４は、同じコンピューティングシステム上で動作する。
【００２３】
ネットワーク１１０は、リクエスタ１０２、ウェブサービス１０４及びオーソライザ１０８の間のデータ通信経路である。１つの実施形態において、ネットワーク１１０は、インターネットである。他の実施形態において、ネットワーク１１０は、ローカルエリアネットワーク、イントラネット、無線ネットワークまたは１の処理デバイスから別の処理デバイスへデータを送信可能な任意の他の通信経路である。
【００２４】
いくつかの実施形態において、ネットワーク１１０を介したデータ通信は、ネットワーク通信プロトコルに従って行われる。１つの可能な例において、ＨＴＴＰがリクエスタ１０２、ウェブサービス１０４及びオーソライザ１０８の間のデータ通信に使用される。別の実施形態においては、ＳＯＡＰに従う。別の実施形態においては、ＷＳ−ＲＴプロトコルに従う。他の実施形態は、他のデータ通信プロトコルを使用する。
【００２５】
いくつかの実施形態において、ユーザは彼ら自ら主張している者であることを保証するように認証される。認証の一例は、Craig V. McMurtry, Alexander T. Weinert, Vadim Meleshuk, and Mark E. Gabarraによる２００８年２月１日に出願された「REQUEST-SPECIFIC AUTHENTICATION FOR ACCESSING WEB SERVICE RESOURCES」と題された米国特許出願第１２／０２４，９０１号に記載されており、当該文献の全開示内容は、参照によってここに組み込まれる。
【００２６】
図２は、本開示の態様を実装する例示のコンピューティングシステム２００である。１つの実施形態において、コンピューティングシステム２００は、ウェブサービス１０４である。別の実施形態において、コンピューティングシステム２００は、リクエスタ１０２である。別の実施形態において、コンピューティングシステム２００は、オーソライザ１０８である。
【００２７】
その最も基本的な構成において、コンピューティングシステム２００は、通常、少なくとも１つの処理ユニット２０２及びメモリ２０４を含む。コンピューティングシステムの正確な構成及びタイプに応じて、メモリ２０４は、揮発性（ＲＡＭ等）、不揮発性（ＲＯＭ、フラッシュメモリ等）またはこの２つの何らかの組み合わせとすることができる。この最も基本的な構成は、図２において破線２０６によって示されている。さらに、コンピューティングシステム２００は、追加の特徴／機能を有していてもよい。例えば、コンピューティングシステム２００は、限定するものではないが、磁気または光学のディスクまたはテープを含む追加の記憶装置（リムーバブル及び／又は非リムーバブル）を有していてもよい。このような追加の記憶装置は、図２において、リムーバブル記憶装置２０８及び非リムーバブル記憶装置２１０によって示されている。
【００２８】
コンピューティングシステム２００は、通常、少なくとも何らかの任意の形式のコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピューティングシステム２００によってアクセスすることができる任意の利用可能な媒体とすることができる。例示であって限定するものではないが、コンピュータ可読媒体は、コンピュータ記憶媒体及び通信媒体を備えることができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータ等の情報の格納のための任意の方法または技術において実装される揮発性及び不揮発性の媒体、リムーバブル及び非リムーバブルの媒体を含む。コンピュータ記憶媒体は、限定するものではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を格納するために使用することができ、コンピューティングシステム２００によってアクセスすることができる任意の他の媒体を含む。通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータを搬送波または他の転送メカニズム等の変調データ信号に具体化し、任意の情報伝送媒体を含む。用語「変調データ信号」は、信号に情報を符号化するような態様でその特性の１または複数を設定また変化した信号を意味する。例示であって限定するものではないが、通信媒体は、有線ネットワークまたは直接配線接続等の有線媒体、及び音響、ＲＦ、赤外線、他の無線媒体などの無線媒体を含む。任意の上記の組み合わせは、コンピュータ可読媒体の範囲内に含まれるべきである。このようなコンピュータ記憶媒体は、コンピューティングシステム２００の一部とすることができる。
【００２９】
コンピューティングシステム２００は、コンピューティングシステムが他のデバイスと通信することを可能とする通信接続（１または複数）２１２を収容してもよい。通信接続（１または複数）２１２は、通信媒体の一例である。通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータを搬送波または他の転送メカニズム等の変調データ信号に具体化し、任意の情報伝送媒体を含む。用語「変調データ信号」は、信号に情報を符号化するようにその特性の１または複数を設定また変化した信号を意味する。例示であって限定するものではないが、通信媒体は、有線ネットワークまたは直接配線接続等の有線媒体、及び音響、ＲＦ、赤外線、他の無線媒体などの無線媒体を含む。本明細書で使用される用語コンピュータ可読媒体は、記憶媒体及び通信媒体の両方を含む。
【００３０】
コンピューティングシステム２００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイス等の入力デバイス（１または複数）２１４を含んでもよい。ディスプレイ、スピーカ、プリンタ等の出力デバイス（１または複数）２１６も含まれ得る。これらのデバイスの全ては、当該技術おいて周知であり、ここで詳細に論ずる必要はない。
【００３１】
いくつかの実施形態において、メモリ２０４は、１または複数のオペレーティングシステム２２０、アプリケーションプログラム２２２、他のプログラムモジュール２２４及びプログラムデータ２２６を含む。アプリケーションプログラム２２２の例は、ウェブサービスソフトウェアアプリケーション、インターネットブラウザソフトウェアアプリケーション、メッセージング及びコラボレーションクライアントソフトウェアアプリケーションまたは様々な他のソフトウェアアプリケーションを含む。可能な実施形態において、プログラムモジュール２２４及びプログラムデータ２２６のいずれかも保護データを含む。
【００３２】
図３は、ウェブサービスリソースへのアクセスを認可する例示の方法３００を示したフロー図である。方法３００は、動作３０２及び動作３０４を含む。方法３００は、動作３０２で始まり、その間に、リクエストがリソースに関してなされる。１つの実施形態において、動作３０２は、保護リソースによって提供される機能を利用するためにリクエスタによる試行を伴う。リソースは保護されているので、リクエスタは、保護リソースを使用することを自動的には許されない。むしろ、リクエストが最初に認可されなければならない。従って、動作３０２は次に、リクエストが認可される間に行われる。１つの実施形態において、動作３０２は、オーソライザからの認可を受信することを伴う。認可が受信されると、リクエスタは、保護リソースを利用することを許される。他の可能な実施形態において、動作３０２は、保護リソースにアクセスするリクエストを含む。
【００３３】
図４は、ウェブサービスリソースの使用を認可する例示の方法４００を示したフロー図である。方法４００は、動作４０２、４０４、４０６及び４０８を含む。方法４００は、動作４０２で始まり、その間に、リソースリクエストがなされる。１つの可能な実施形態において、動作４０２は、リクエスタ１０２からウェブサービス１０４へリクエストを送信することを伴う。ウェブサービス１０４は、リソースリクエストを受信し、リクエストが保護リソースに関することを判定する。ウェブサービス１０４は、その後、リクエスタ１０２が保護リソースにアクセスすることを認可されたかを評価する。例示の例において、リクエスタ１０２は、認可されていないので、リソースへのアクセスは、認可があるまで禁止される。
【００３４】
可能な実施形態において、動作４０４がその後、行われて、リソースリクエストのステータスをチェックする。いくつかの実施形態において、動作４０４は、行われない。動作４０４の一例において、リクエスタ１０２は、ウェブサービスを定期的にポーリング（poll）してリクエストのステータスを判定する。ウェブサービス１０４は、ステータスとともにリクエスタ１０２にレスポンスする。例示の例において、ウェブサービス１０４は、リクエスタ１０２に、リクエストがまだ認可されていないことを知らせる。いくつかの実施形態において、ポーリングは、リクエスタ１０２のユーザが、インターネットブラウザソフトウェアアプリケーションのリフレッシュオプションを選択したときに行われる。別の実施形態において、ポーリングは、リクエスタ１０２上で稼動しているソフトウェアアプリケーションによって定期的に行われる。
【００３５】
動作４０６は、リソースが動作４０２においてリクエストされた後に行われて、リクエストを認可する。１つの実施形態において、動作４０６は、リクエストを認可するためにオーソライザ１０８からウェブサービス１０４へメッセージを送信することを伴う。リクエストが認可された後、動作４０８が行われて、保護リソースがいまから利用できることをリクエスタに通知する等、リクエストが認可されたことを通信する。他の実施形態においては、リクエストが認可されていることを通信するよりむしろ（またはこれに加えて）動作４０８は、リクエストされたとおり保護リソースへのアクセスを提供するように進行する。
【００３６】
図５は、ウェブサービスリソースの使用を認可する例示の方法５００を示したフロー図である。この例において、方法５００は、リクエスタ１０２、オーソライザ１０８及びウェブサービス１０４の対話を伴う。さらに、方法５００は、図４に図示され、図４を参照して説明される動作４０２、４０４、４０６及び４０８のさらに具体的な例を含む。図５において、システムから送信される通信は、それぞれのシステムから下に伸びている破線から出ている矢印によって表されている。さらに、システムによって受信される通信は、それぞれのシステムから下に伸びている破線で終端する矢印によって表されている。
【００３７】
例示のシナリオにおいて、リクエスタ１０２は、ウェブサービス１０４上で動作しており、ウェブサービス１０４よって保護されている保護リソース１０６へのアクセスを得ることを望む。しかし、アクセスが許可される前に、ウェブサービス１０４は、認可がオーソライザ１０８から受信されることを要求する。
【００３８】
この実施形態において、方法５００は、動作４０２、４０４、４０６及び４０８を含む。方法５００は、動作４０２で始まり、その間に、保護リソース１０６を使用するためにリクエストがリクエスタ１０２によってウェブサービス１０４に対してなされる。動作４０４は、動作４０２に続いてオプションで行われ、その間に、リクエスタ１０２がリクエストのステータスをチェックする。動作４０６は、動作４０２の後に行われる。動作４０６は、リクエストを認可するためにオーソライザ１０８からウェブサービス１０４へ認可を送信することを伴う。リクエストが認可されると、動作４０８が行われ、その間に、リクエストが認可されたことをリクエスタ１０２に知らせるためにウェブサービス１０４からリクエスタ１０２へ通信が送信される。
【００３９】
方法５００の一例を完全に説明するために、動作４０２、４０４、４０６及び４０８は、様々な動作を含むものとしてそれぞれ例示されている。これらの動作は、ウェブサービスリソースの使用を認可する方法の一例としてのみ示されている。この実施形態において、動作４０２は、動作５２０、５２２及び５２４を含む。動作５２０が最初に行われ、その間に、リクエストがリクエスタ１０２からウェブサービス１０４に送信され、保護リソース１０６の使用及び保護リソース１０６へのアクセスをリクエストする。１つの実施形態において、動作５２０は、リクエスタ１０２からウェブサービス１０４へCreateメッセージを送信することを伴う。ウェブサービス１０４は、リクエストを受信し、保護リソース１０６が認可を要求するか否かを評価し、そうであれば、リクエスタ１０２が以前に認可されているかを評価する。そうでなければ、ウェブサービス１０４は、リクエスタ１０２が保護リソース１０６へアクセスし、または保護リソース１０６を使用することができる前に、認可が要求されることを判定する。
【００４０】
ウェブサービス１０４が、認可が要求されることを判定すると、動作５２２が行われ、その間に、ウェブサービス１０４がリクエストリソース５０２を発生する。リクエストリソース５０２は、ウェブサービス１０４によって使用されて、動作５２０において受信されたリクエストのステータスをトラッキングする。例えば、リクエストリソース５０２は、動作５２０においてなされたリクエストが認可されているか否かを識別するデータを収容する。最初に発生されたとき、リクエストリソース５０２は、リクエストがまだ認可されていないことを識別する。認可がその後に受信されると、（本明細書において説明された動作５５０において行われるように）リクエストリソース５０２が更新されて、リクエストが認可されていることを識別する。１つの実施形態において、リクエストリソース５０２は、拡張マークアップ言語（ＸＭＬ）によって定義される。リクエストリソーススキーマの１つの実施形態は以下のとおりである。
リクエストリソーススキーマの例
【００４１】
【表１】
0005432888.tif 000002
【００４２】
【表２】
0005432888.tif 000003
【００４３】
【表３】
0005432888.tif 000004
【００４４】
上に提供した例示のリクエストリソーススキーマ例において、Status、Details、ApprovalProcesses、ApprovalResponses、Data、ReferenceProperty、Action、Body、RequiredApproval、Actions及びRequestを含む、いくつかのエレメントが定義される。この例において、Statusエレメントは、認可されているまたは認可されていない等のリクエストのステータスを収容する。Detailsエレメントは、オリジナルリクエストの記述を含む。ApprovalProcessesエレメントは、リクエストに関連する承認プロセスの固有の識別子を格納する。ApprovalResponsesエレメントは、承認（approval）レスポンスの固有の識別子を収容する。Dataエレメントは、オリジナルリクエストによって取得される任意のデータを収容する。ReferencePropertyエレメントは、オリジナルリクエストのターゲット（target）を識別するＷＳ−Ａｄｄｒｅｓｓｉｎｇ（Web Services addressing）リファレンスプロパティ（reference property）を収容する。Actionエレメントは、オリジナルリクエストのアクションヘッダを収容する。RequiredApprovalエレメントは、オーソライザ１０８の識別子等の承認オブジェクトの固有の識別子を格納する。このようにして、各保護リソースは、そのリソースに対する認可を提供することを可能にする異なるオーソライザを含むことができる。これは、いくつかの実施形態において、１のオーソライザによって取り扱われるべき１のトピックまたはタイプのリソースに関する認可を可能にし、別のオーソライザによって取り扱われるべき別のトピックまたはタイプのリソースに関する認可を可能にするために有用である。Actionsエレメントは、リクエストを認可するのに使用される承認アクションタイプの固有の識別子を収容する。Requestエレメントは、例えば、Status、Details、ApprovalProcesses及びDataエレメントのコピーを収容するラッパー（wrapper）である。
【００４５】
リクエストスキーマの別の例は以下のとおりである。
リクエストリソーススキーマの第２例
【００４６】
【表４】
0005432888.tif 000005
【００４７】
【表５】
0005432888.tif 000006
【００４８】
【表６】
0005432888.tif 000007
【００４９】
上に提供したリクエストリソーススキーマの第２例において、Parameter、Operation、Target、BusinessJustification、RequestStatus、RequestStatusDetails、AuthenticationWorkflowInstance及びActionWorkflowInstanceを含む、いくつかのエレメントが定義される。この例において、Parameterエレメントは、ウェブサービス１０４のリクエストディスパッチャ（Request Dispatcher）によって書かれる。Parameterエレメントは、動作５２４において送信されるメッセージのボディの正規化表現（normalized representation）を収容する。
【００５０】
Operationエレメントは、動作５２０においてなされたリクエストによってリクエストされた動作の識別を収容する。いくつかの実施形態において、Operationエレメントは、「Create」、「Read」、「Update」、「Delete」、「Enumerate」及び「SystemEvent」から選択される値を収容する。Targetエレメントは、動作が参照しているターゲットオブジェクトへの参照を収容する。
【００５１】
BusinessJustificationエレメントは、保護リソース１０６へのアクセスがなぜ必要なのかに関する追加の情報をオーソライザ１０８に提供する、リクエスタ１０２によって入力されたテキストベースのメッセージを収容する。
【００５２】
RequestStatusエレメントは、リクエストの現在のステータスを収容する。いくつかの実施形態において、RequestStatusは、「Not Found」、「Validating」、「Validated」、「Authenticating」、「Authenticated」、「Authorizing」、「Authorized」、「Denied」、「Processing」、「ProcessingEffects」、「Completed」、及び「Cancelled」から選択される値を収容する。
【００５３】
RequestStatusDetailsエレメントは、リクエスタ１０２へのフィードバックを提供するために使用されるアトリビュート（attribute）を収容する。フィードバックの例には、リクエスタ１０２へ送信されるエラーメッセージまたは情報が含まれる。
【００５４】
AuthenticationWorkflowInstancesは、起動されている全ての認証ワークフローインスタンスへの参照を収容する。
【００５５】
AuthorizationWorkflowInstancesは、起動されている全ての認可ワークフローインスタンスへの参照を収容する。
【００５６】
ActionWorkflowInstancesは、起動されている全てのアクションワークフローインスタンスへの参照を収容する。
【００５７】
リクエストリソース５０２は、ウェブサービス１０４によってアクセスできるように格納される。１つの可能な実施形態において、リクエストソース５０２は、ディレクトリ内のエントリである。別の実施形態において、リクエストソース５０２は、データベース内のレコードである。別の実施形態において、リクエストリソース５０２は、メモリ記憶デバイス上に格納されたファイルまたはファイルの一部である。
【００５８】
リクエストソース５０２の発生に続いて、動作５２４がその後に行われて、リクエストがウェブサービス１０４によって処理することができる前に認可が要求されることをリクエスタ１０２に知らせる。１つの実施形態において、動作５２４は、ＳＯＡＰフォールトの形式のレスポンスを送信することを伴う。ＳＯＡＰフォールトは、detailエレメントのコンテンツを含む。いくつかの実施形態において、detailエレメントは、ＷＳ−Ａｄｄｒｅｓｓｉｎｇのエンドポイントリファレンス（endpoint reference）も含み、これは、ウェブサービスエンドポイント（ＷＳ−ＲＴエンドポイント等）のアドレスを収容する。いくつかの実施形態において、エンドポイントリファレンスは、リソースを参照する参照プロパティを収容する。いくつかの実施形態において、動作５２４は、動作５２２の前に行われる。
【００５９】
動作４０２に続いて、オプションの動作４０４が行われる。動作４０４は、一般に、リクエストが認可されているか否かを判断する等、リクエスタ１０２がリクエストのステータスのチェックをすることができるプロセスである。動作４０４は、動作５３０、５３２、５３４及び５３６を含む。動作４０４は、動作５３０で始まり、その間に、リクエスタ１０２がウェブサービス１０４へクエリを送信してリクエストのステータスを照会する。１つの実施形態において、動作５３０は、リクエスタ１０２からウェブサービス１０４へGetメッセージを送信することを伴う。Getメッセージは、動作５２４のＳＯＡＰフォールトによって提供されるようなリクエストリソースのアドレスを含む。別の実施形態において、動作５３０は、リクエスタ１０２からウェブサービス１０４へ列挙メッセージを送信することを伴う。
【００６０】
別の実施形態において、動作５３０は、動作５２０においてなされたリクエストに関連するＷＳ−ＳｅｃｕｒｅＣｏｎｖｅｒｓａｔｉｏｎコンテキストヘッダを含む等、動作５２０においてなされてリクエストを再サブミットすることを伴う。リクエストは、動作５２４においてレスポンスによって提供されるアドレスへ送信される。
【００６１】
ステータスクエリがウェブサービス１０４によって受信されると、動作５３２がその後に行われる。動作５３２の間に、ウェブサービス１０４は、リクエストリソース５０２にクエリしてリクエストのステータスを判定する。実施形態の一例において、リクエストリソース５０２は、データベース内に格納される。この実施形態において、動作５３２は、例えば、ウェブサービス１０４がＳＱＬ（Structured Query Language）のSelectステートメントを実行してリクエストリソース５０２の表現をリクエストすることを伴う。実施形態の別の例において、リクエストリソース５０２は、ディレクトリのエントリである。この実施形態において、動作５３２は、ウェブサービス１０４がＬＤＡＰクエリを実行することを伴う。
【００６２】
動作５３４がその後に行われ、その間に、リクエストリソース５０２がウェブサービス１０４へ戻される。ウェブサービス１０４は、リクエストソース５０２を読み、リクエストのステータスを判定する。例えば、ウェブサービス１０４は、リクエストリソース５０２の「Status」エレメントを読んで、リクエストが認可されているか否かを判定する。ステータスが判定されると、動作５３６が行われ、その間に、ステータスがリクエスタ１０２へ通信し戻される。例示の実施形態において、リクエストはまだ認可されておらず、そのため、ウェブサービス１０４は、リクエストがまだ認可されてない旨を示すメッセージを送信する。いくつかの実施形態において、動作５３６は、GetまたはEnumerateメッセージへレスポンスを送信することを伴う。
【００６３】
リクエスタ１０２が動作４０２のリクエストをなした後のある時点で、オーソライザ１０８はリクエストを認可または拒否する。例示の実施形態において、オーソライザ１０８は、動作４０６においてリクエストを認可する。動作４０６は、動作５４０で始まり、その間に、認可がオーソライザ１０８からウェブサービス１０４へ送信される。１つの実施形態において、認可がオーソライザ１０８からウェブサービス１０４へメッセージを通じて通信される。オーソライザ１０８が、リクエストは認可されるべきではないと判定する場合、オーソライザ１０８は、リクエストは認可されないことになるとウェブサービス１０４に知らせる拒絶（rejection）メッセージを送信する。１つの実施形態において、拒絶も、Putメッセージを使用して通信される。Putメッセージは、例示のリクエストリソーススキーマによって定義されたフォーマットでリソースのDataエレメントを更新するために使用される。別の可能な実施形態において、ＷＳ−ＳｅｃｕｒｅＣｏｎｖｅｒｓａｔｉｏｎトークンが、例えば、MICROSOFT（登録商標）.NET framework３．５及びDurable Servicesを利用することによって提供される。
【００６４】
別の可能な実施形態において、オーソライザ１０８は、別個のリソースを作成することによって認可のリクエストに対してレスポンスする。１つの例として、オーソライザ１０８は、ＷＳ−ＴｒａｎｓｆｅｒのCreateメッセージを送信することによって動作５４０を行う。作成（create）メッセージは、認可のリクエストに対するレスポンスを記述する情報を収容する別個のリソース（Approval Responseリソース）を作成するように働く。ApprovalResponseリソースに関するスキーマの一例を以下に示す。
ApprovalResponceリソーススキーマの例
【００６５】
【表７】
0005432888.tif 000008
【００６６】
【表８】
0005432888.tif 000009
【００６７】
上に提供したApproval Responseリソーススキーマの例において、Approval、Decision及びReasonを含む、いくつかのエレメントが定義される。Approvalエレメントは、オーソライザ１０８への参照を収容する。Decisionエレメントは、動作５２０においてなされるリクエストに対するオーソライザ１０８からのレスポンスを示す文字列（string）を収容する。１つの実施形態において、Decisionエレメントは、「Approved」または「Rejected」のどちらかの値を有する。理由（reason）エレメントは、リクエストがなぜ承認されるかまたはなぜ拒絶されるかに関する追加の情報を提供するオーソライザ１０８からのテキストメッセージを収容する。他の実施形態は、他のリソース及びリソーススキーマを含む。
【００６８】
１つの実施形態において、オーソライザ１０８は、認可を待っているリクエストを表示するウェブサイトにアクセスすることによって、動作４０６を開始する等のために認可が要求されることを判定する。例えば、ウェブサービス１０４は、ウェブサーバとして働き、オーソライザ１０８上で動作しているブラウザにウェブサイトを送信する。別の実施形態において、オーソライザ１０８は、定期的にウェブサービス１０４をポーリングして認可されるべく待機しているリクエストをチェックするソフトウェアアプリケーションを走らせる。例えば、ソフトウェアアプリケーションは、オーソライザ１０８上で動作して、認可を待っているリクエストを定期的にチェックする。別の実施形態において、ウェブサービス１０４は、オーソライザ１０８と通信してリクエストが認可を待っていることをオーソライザ１０８に知らせる。この一例は、２００７年１１月１５日に出願され、「MODELING USER-INITIATED REQUESTS AND STATUS UPDATES WITHIN AN E-MAIL MESSAGE」と題された米国特許出願第１１／９３１，００４号に記載されており、当該文献の全開示は、参照によってここに組み込まれる。
【００６９】
動作５４２及び５４６がその後に行われ、その間に、ウェブサービス１０４がリクエストリソース５０２のコピーを取得する。１つの例示の実施形態において、リクエストリソース５０２は、データベースに格納される。この実施形態において、動作５４２は、ウェブサービス１０４がＳＱＬのSelectステートメントを実行してリクエストリソース５０２の表現をリクエストすることを伴う。別の例示の実施形態において、リクエストリソース５０２は、ディレクトリ内のエントリである。この実施形態において、動作５４２は、ウェブサービス１０４がＬＤＡＰクエリを実行することを伴う。リクエストされたリソースは、その後、動作５４６においてウェブサービス１０４へ戻される。
【００７０】
認可が受信されると、動作５４８がその後に行われ、その間に、もともとリクエストされた動作が、保護リソース１０６を伴って行われる。例えば、ユーザネームがグループ配信リストに加えられる。本明細書において説明されているように、多くの他の動作が、ウェブサービス１０４によって行うことができる。
【００７１】
認可が受信された後、動作５５０が行われる。動作５５０において、ウェブサービス１０４がリクエストリソース５０２のステータスを更新する。１つの実施形態において、これは、リクエストリソース５０２のstatusエレメントを変更して、リクエストに関して認可が受信されていることを示すことを伴う。別の実施形態において、リクエストリソース５０２は、動作５４８の結果とともに更新されて、リクエストされた動作が行われるときに起こったことを記録する。例えば、リクエストリソース５０２は、statusエレメントにおいて更新されて、リクエストが認可されたことを示す。別の例として、リクエストリソース５０２が更新されて、ユーザネームがグループ配信リストに加えられたことを示す。このことは、例えば、リクエストが認可されたときにどの動作が行われただけではなく、動作の結果のレコードも提供するために有用である。
【００７２】
動作５５２は、人ｋあが受信された後に行われる。動作５５２の間に、ウェブサービス１０４は、オーソライザ１０８と通信して承認の受理を確認する。１つの実施形態において、動作５５２は、ウェブサービス１０４からオーソライザ１０８へPut Responseメッセージを送信することを伴う。代替の実施形態において、動作５４８、５５０及び５５２は、任意の順序で行うことができる。例えば、ウェブサービス１０４は、動作５４８においてリクエストされた動作を行うのに先立って、リクエストリソース５０２のステータスを更新することができる。さらに、動作５５２は、動作５４０に続く任意の時点で行って、認可が成功裏に受理されたことをオーソライザ１０８に通信する。
【００７３】
認可が受信されると、動作４０８が行われて、認可の事実をリクエスタ１０２に通信する。動作４０４において、認可がまだ受信されていないことをリクエスタが通知され、動作４０８において、認可が既に受信されていることをリクエスタが通知されることを除いて、動作４０８は動作４０４と同じである。可能な実施形態において、動作４０４は、認可が受信されていることを示す動作４０６が行われるまで定期的に行われる。
【００７４】
例示の実施形態において、動作４０８は動作５６０で始まり、その間に、リクエスタ１０２はウェブサービス１０４にクエリを送信してリクエストのステータスを照会する。１つの実施形態において、動作５６０は、リクエスタ１０２からウェブサービス１０４へGetメッセージを送信することを伴う。Getメッセージは、動作５２４のＳＯＡＰフォールトによって提供されるような、リクエストリソースのアドレスを含む。別の実施形態において、動作５６０は、リクエスタ１０２からウェブサービス１０４へEnumerateメッセージを送信することを伴う。別の実施形態において、動作５６０は、リクエスタ１０２上で動作するブラウザを介してウェブページをリフレッシュすることを伴う。
【００７５】
動作５６２及び５６４がその後に行われ、その間に、ウェブサービス１０４は、リクエストリソース５０２のコピーをリクエストし、リクエストソース５０２のコピーを受信する。１つの実施形態において、動作５６２は、ウェブサービス１０４がリクエストリソース５０２にクエリしてリクエストのステータスを判定することを伴う。動作５６４がその後に行われて、その間に、リクエストリソース５０２がウェブサービス１０４に返送される。リクエストリソース５０２がウェブサービス１０４によって取得されると、リクエストリソース５０２をレビューしてリクエストのステータスを判定する。例示の例において、リクエストは、動作５４０において認可されている。従って、動作５６６が行われて、リクエストが認可されていることをリクエスタ１０２に知らせる。１つの実施形態において、動作５６６は、GetまたはEnumerateメッセージへレスポンスを送信することを伴う。いくつかの実施形態において、レスポンスは、オリジナルリクエストによって保護リソース１０６からリクエストされる情報（dataエレメントからのデータ）を含む。
【００７６】
上記の図面を参照して本開示の実施形態を説明してきたが、当業者に容易に想到されるであろうし、本開示の範囲及び精神に包含される、開示の実施形態に対する多くの変更を行うことができることが理解されるべきである。実際、現在の好ましい実施形態が本明細書で説明されてきたが、本開示の範囲内にある様々な変形及び変更を行うことができる。
【００７７】
同様に、本開示は、構造的特徴、方法的アクト及びこのようなアクトを収容するコンピュータ可読媒体に特有の言葉を使用したが、添付の特許請求の範囲に記載の主題は、本明細書に記載された特定の構造、アクト、特徴または媒体に必ずしも限定されないことが理解されるべきである。むしろ、上述の特定の特徴及びアクトは、請求項を実装する例示の形態として開示されている。当業者は、本発明の範囲及び精神内にある他の実施形態または改良を認識するであろう。従って、特定の構造、アクトまたは媒体は、単に例示の実施形態として開示されている。
【図１】
0005432888.tif 000010
【図２】
0005432888.tif 000011
【図３】
0005432888.tif 000012
【図４】
0005432888.tif 000013
【図５】
0005432888.tif 000014