"データにアクセスするための方法であって、ワークフロー言語で記述され、2つまたはそれ以上の外部ネットワークリソースからの保護されたデータを統合する複合アプリケーションのセキュリティ要件を宣言するように構成された、ワークフローモデルを受取ることであって、前記複合アプリケーションは、前記ワークフローモデルに従って少なくとも1つのホストサーバコンピュータ上で実行される、前記受取ること、および少なくとも1つのセキュアサーバコンピュータ上で認証サービスを実行することであって、前記認証サービスは、前記複合アプリケーションのために、前記外部ネットワークリソースで前記保護されたデータにアクセスし、ユーザの認証および認可を実施するように構成される、前記実行すること、を含む、データにアクセスするための方法。前記サーバコンピュータは、前記ユーザによって信頼されたエンティティによって制御される、請求項1に記載のデータにアクセスするための方法。前記ワークフロー言語は拡張可能ワークフロー言語である、請求項1に記載のデータにアクセスするための方法。前記2つまたはそれ以上の外部ネットワークリソースのうちの1つに関するプロトコル情報を取り出すことをさらに含む、請求項1に記載のデータにアクセスするための方法。前記複合アプリケーションから前記認証サービスに接続することをさらに含む、請求項1に記載のデータにアクセスするための方法。前記認証サービスから前記2つまたはそれ以上の外部ネットワークリソースのうちの1つに接続することをさらに含む、請求項1に記載のデータにアクセスするための方法。前記認証サービスによってユーザ証明を取得すること、および前記外部ネットワークリソースで前記保護されたデータにアクセスするために、前記ユーザの認証および認可を実施するための前記ユーザ証明を使用すること、をさらに含む、請求項1に記載のデータにアクセスするための方法。データにアクセスするためのシステムであって、2つまたはそれ以上の外部ネットワークリソースからの保護されたデータを統合する複合アプリケーションのセキュリティ要件を宣言するように構成された、ワークフロー言語で記述されたワークフローモデルであって、前記複合アプリケーションは、前記ワークフロー言語に従って少なくとも1つのホストサーバコンピュータ上で実行する、ワークフローモデルと、少なくとも1つのセキュアサーバコンピュータ上で実行する認証サービスであって、前記複合アプリケーションのために、前記外部ネットワークリソースで前記保護されたデータにアクセスし、ユーザの認証および認可を実施するように構成される、認証サービスと、を備える、データにアクセスするためのシステム。ユーザ証明は、前記認証サービス上に記憶される、請求項8に記載のデータにアクセスするためのシステム。前記複合アプリケーションは、前記認証サービスと通信するための少なくとも1つのセキュリティハンドラであって、前記セキュリティハンドラは、セキュリティプロトコルを使用して前記認証サービスと通信するように構成される、少なくとも1つのセキュリティハンドラと、前記ワークフローモデルのワークフローインスタンスと、をさらに備える、請求項8に記載のデータにアクセスするためのシステム。前記セキュリティプロトコルはOAuthである、請求項10に記載のデータにアクセスするためのシステム。前記セキュリティプロトコルはHTTPBasic認証である、請求項10に記載のデータにアクセスするためのシステム。前記ワークフローインスタンスは、前記複合アプリケーションが前記認証サービスと通信する場合、その実行の状態を維持する、請求項10に記載のデータにアクセスするためのシステム。前記認証サービスを介して取得されたユーザ証明のセットは、前記ワークフローインスタンス中に使用するために前記セキュリティハンドラ内に記憶される、請求項10に記載のデータにアクセスするためのシステム。具体化されたコンピュータ読み取り可能プログラムコードを有するコンピュータ読み取り可能記憶媒体を備え、前記コンピュータ読み取り可能プログラムコードは、2つまたはそれ以上の外部ネットワークリソースからの保護されたデータを統合する、複合アプリケーションのセキュリティ要件を宣言するように構成された、ワークフロー言語で記述されたワークフローモデルを受取ること、および前記ワークフロー言語に従って前記複合アプリケーションのために、前記外部ネットワークリソースで前記保護されたデータにアクセスし、ユーザの認証および認可を実行する旨の要求を、少なくとも1つのセキュアサーバコンピュータ上で実行する認証サービスに対して発行すること、を、実行するように構成される、コンピュータプログラム。前記認証サービスに対する前記要求は、証明を要求するために、ユーザを前記複合アプリケーションから前記認証サービスへとリダイレクトする、請求項15に記載のコンピュータプログラム。前記コンピュータ読み取り可能プログラムコードは、非同期メッセージングサービスを介してユーザに接触するようにさらに構成される、請求項15に記載のコンピュータプログラム。前記非同期メッセージングサービスは電子メールである、請求項17に記載のコンピュータプログラム。前記非同期メッセージングサービスはインスタントメッセージングサービスである、請求項17に記載のコンピュータプログラム。前記コンピュータ読み取り可能プログラムコードは、前記認証サービスから保護されたデータを受信するようにさらに構成される、請求項15に記載のコンピュータプログラム。本発明の例示的実施形態は、データにアクセスするための方法である。この方法は、ワークフロー言語で記述されたワークフローモデルを受信することを含む。ワークフローモデルは、2つまたはそれ以上の外部ネットワークリソースからの保護されたデータを統合する、複合アプリケーションのセキュリティ要件を宣言するように構成される。この方法は、少なくとも1つのセキュアサーバコンピュータ上で認証サービスを実行すること組み込む。認証サービスは、ワークフロー言語に従って少なくとも1つのホストサーバコンピュータ上で実行している複合アプリケーションに代わって、外部ネットワークリソースで保護されたデータにアクセスするために、ユーザの認証および認可を実施するように構成される。本発明の他の例示的実施形態は、データにアクセスするためのシステムを含む。このシステムは、ワークフロー言語で記述されたワークフローモデルを含む。ワークフローモデルは、2つまたはそれ以上の外部ネットワークリソースからの保護されたデータを統合する、複合アプリケーションのセキュリティ要件を宣言するように構成される。このシステムは、少なくとも1つのセキュアサーバコンピュータ上で実行する認証サービスも含む。認証サービスは、ワークフロー言語に従って少なくとも1つのホストサーバコンピュータ上で実行している複合アプリケーションに代わって、外部ネットワークリソースで保護されたデータにアクセスするために、ユーザの認証および認可を実施するように構成される。本発明のさらに他の例示的実施形態は、データにアクセスするためのコンピュータプログラム製品である。このコンピュータプログラム製品は、ワークフロー言語で記述されたワークフローモデルを受信することを含む。ワークフローモデルは、2つまたはそれ以上の外部ネットワークリソースからの保護されたデータを統合する、複合アプリケーションのセキュリティ要件を宣言するように構成される。コンピュータプログラム製品は、ワークフロー言語に従って複合アプリケーションに代わって外部ネットワークリソースで保護されたデータにアクセスするために、ユーザの認証および認可を実行する旨の要求を、少なくとも1つのセキュアサーバコンピュータ上で実行する認証サービスに対して発行するように構成されたコードも含む。本発明に関する主題は、本明細書の末尾の特許請求の範囲で、具体的に指摘および明確に請求されている。本発明の前述および他の目的、特徴、および利点は、添付の図面に関連した以下の詳細な説明から明らかとなろう。本発明について、本発明の実施形態を参照しながら説明する。本発明の説明全体にわたって、図1~図8が参照される。本発明の態様は、第三者のセキュアサービスを集約するマッシュアップのためのセキュリティモデルに関する。現行のエンタープライズマッシュアップツールには、認証および認可に関してまったく異なるセキュリティ要件を有する場合に、セキュアな方法でマッシュアップにおいて異なるサービスを消費および統合する機能が欠如している。したがって、多くのマッシュアップツールは、セキュリティなしのサービスおよびデータソースまたはハードコード認証データのみを統合することができる。ユーザは自分の認証情報を第三者に提供したがらず実際、企業ポリシーがそれを禁止している場合さえある、リソースは、通常、カスタムセキュリティ要件を有するため、これは企業環境において問題である。さらに、集約されたセキュアサービスは、異なるプロトコルを介して異なるユーザから異なる証明credentialを必要とする。リソースは、HTTPBasic認証などのいくつかの認証プロトコル、カスタムアプリケーションキー、またはそれ以上のOpenIDおよびOAuthなどのWeb2.0のようなプロトコルのうちのいずれかを、サポートすることができる。本発明の実施形態は、ユーザがネットワーク上のセキュアおよび非セキュアの両方のリソースからのデータを集約することが可能な、エンタープライズマッシュアップに関するサポートを提供し、セキュアなリソースは、それぞれ潜在的に異なるセキュリティプロトコルを使用している。図1は、本発明によって企図される、データにアクセスするためのシステム100の例を示す。図に示されたシステム100は、本発明の様々な配置構成のうちの単なる一例であり、本発明をいずれの特定の構成にも限定するものと解釈されるべきでないことを理解されたい。一実施形態では、システム100は、ホストサーバコンピュータ102およびセキュアサーバコンピュータ110を含む。ホストサーバコンピュータ102上では、複合アプリケーション104が実行されている。ワークフロー言語で記述されたワークフローモデル106は、2つまたはそれ以上の外部リソース116により保護されたデータ118を統合する複合アプリケーション104の、セキュリティ要件を宣言するように構成される。したがってワークフローは、マッシュアップを提示/実体化および実行するための方法である。ホストサーバコンピュータ102上で実行可能な複合アプリケーション104は、ワークフローモデル106を含むことができる。複合アプリケーション104は、ワークフロー言語を含むコンパイル済みまたはインタプリタ言語で作成可能である。ワークフロー言語は、BiteまたはBite言語の拡張バージョンを含む、XMLベース言語を含むことが可能な、コンパイル済みまたはインタプリタ言語とすることができる。Bite言語に関する詳細な情報については、FranciscoCurbera、MatthewDuftler、RaniaKhalaf、DouglasLovellによる、2007年9月17~20日、オーストリア、ウィーンでの、Bite:WorkflowCompositionfortheWeb,InternationalConferenceonServiceOrientedComputingICSOC2007、SpringerLNCSを参照されたい。複合アプリケーション104の他の実施形態は、セキュリティハンドラ108を含む。セキュリティハンドラ108は、認証サービス112と対話する複合アプリケーション104におけるモジュールとすることができる。セキュリティハンドラ108は、ターゲットサービスで異なるセキュリティメカニズムに関するサポートを提供するために、OAuth、HTTPBasic認証、およびAppIDを含むがこれらに限定されない、いくつかの認証プロトコルを介して、認証サービス112と対話することができる。本発明の実施形態では、複合アプリケーション104はワークフローモデル106の少なくとも1つのワークフローインスタンスを含む。ワークフローは、ワークフロー言語で作成可能である。本発明の実施形態では、ワークフローインスタンスは、複合アプリケーション104が認証サービス112と対話する間、その実行状態を維持する。セキュアサーバ110は、認証およびアクセス制御規則によって保護された信頼できる環境に配置されなければならない。セキュアサーバコンピュータ110上では、認証サービス112が実行している。認証サービス112は、複合アプリケーション104に代わって、外部リソース116上で保護されたデータ118にアクセスするために、ユーザの認証および認可を実施するように構成される。外部リソース116は、セキュアまたは非セキュアのいずれかの外部コンピュータ上で使用可能な、任意のリソースを含む。保護されたデータ118は、RSSまたはAtomなどのフィード、RESTまたはSOAPなどのサービス、HTMLまたはXMLソース、あるいは、画像または文書などのコンピュータアクセス可能ファイルを含む。一実施形態では、ユーザ証明114は認証サービス112内に記憶される。ユーザ証明114は、パスワード、ユーザ名、または識別情報を記憶するトークンを含むことができる。ホストサーバコンピュータ102は、ネットワーク120を介してセキュアサーバコンピュータ110に接続される。ネットワーク120は、ローカルエリアネットワークLAN、ワイドエリアネットワークWAN、有線または無線あるいはその両方のネットワークを含む、当分野で知られた様々なタイプのネットワークのうちのいずれかとすることができる。ネットワーク120は、たとえば、TCP/IP、Wi-FiR、BluetoothR、ピコネット、トークンリング、光およびマイクロ波を含むがこれらに限定されない、当分野で知られた様々な構成を使用することができる。Wi-Fiはテキサス州オースティンにあるWi-FiAllianceの登録商標である。Bluetoothはワシントン州ベルビューにあるBluetoothSIG,Inc.の登録商標である。図2は、本発明によって企図される、データにアクセスするための方法の流れ図200の例を示す。各ワークフローアクティビティは、セキュリティを必要とする場合に、動作204~218を実行することができる。すなわちこれら動作は、ワークフローアクティビティがセキュリティ要素を含む場合で、外部アクセスを必要とするアウトバウンドである場合に、実行されても良い。データにアクセスするための方法はブロック202で開始され、2つまたはそれ以上の外部ネットワークリソースにより保護されたデータを統合する複合アプリケーションの、セキュリティ要件を宣言するために、ワークフロー言語を受取ることを含む。セキュリティ要件を宣言する際に、ワークフロー言語でセキュリティ拡張要素を使用しても良い。ブロック204で、方法は、ワークフロー言語に従ってホストサーバコンピュータ上で実行している複合アプリケーションのために、外部ネットワークリソースで保護されたデータにアクセスし、ユーザの認証および認可を実施するための認証サービスを提供することを含む。方法は、ブロック205で、複合アプリケーションから認証サービスに接続することを含む。これは、OAuthプロトコルなどの共通セキュリティプロトコルを使用することによって実施可能である。OAuthは、ウェブベースのアプリケーションに関する、十分理解されますます普及してきたプロトコルであり、コンシューマとプロバイダとの間での認証および認可を処理するシームレスな方法を実装する。このシナリオでは、コンシューマはBiteエンジンでありプロバイダはSASそれ自体である。OAuthプロバイダは、1要求トークンURL相対URL/requesttoken、2ユーザ認可URL/authorize、および3アクセストークンURL/accesstokenの、3つの異なる要求URLを提供しなければならない。典型的なOAuth認証および認可は、以下のように処理される。第1に、コンシューマは、コンシューマアプリケーション、タイムスタンプ、ナンス、署名などを識別するための事前に交渉されたコンシューマキーなどの、いくつかのOAuth特有のパラメータを送信することによって、要求トークンURL1を使用して要求トークンを要求する。すべてのパラメータが正しくかつ検証可能である場合、サービスプロバイダは未認可の要求トークンを発行する。要求トークンがコンシューマによって受信された場合、ユーザのブラウザは、認証および認可を取得するためにサービスプロバイダへリダイレクトすることができる。この認可により、ブラウザの背後にいるユーザは、コンシューマのウェブアプリケーションが、代理としてサービスプロバイダのリソースへのアクセスを許可されたことを明示的に保証する。認可が実行されると、サービスプロバイダは、コールバックURLを使用してユーザをコンシューマアプリケーションへと再度リダイレクトすることができる。最後にコンシューマは、サービスプロバイダ側で、アクセストークンに関する要求トークンを交換しなければならない。これは典型的には、ユーザが前のステップで認証および認可を正常に実行した場合に付与される。このアクセストークンは、あらゆる他の要求と共に、保護されたサービスとりわけ、コンシューマキー、タイムスタンプ、署名などへと送信されなければならない、OAuthパラメータのうちの1つである。方法は、ブロック206で、複合アプリケーションに代わって認証サービスに要求を発行することを含む。この要求は、複合アプリケーションが第三者リソース上で保持されているデータを必要とする場合に発行可能である。さらにこのデータは、保護可能である。要求は、複合アプリケーション内のセキュリティハンドラモジュールを使用することによって発行可能である。ブロック208で、方法は、2つまたはそれ以上の外部ネットワークリソースのうちの1つに関するプロトコル情報を取り出すことを含む。プロトコル情報は、外部リソースにプロトコル情報を要求すること、またはセキュリティハンドラモジュールまたは認証サービス内にセキュリティ情報をハードコーディングすることによって、取り出すことができる。ブロック210で、方法は、証明を要求するために、ユーザを複合アプリケーションから認証サービスへとリダイレクトすることを含む。このステップは、プロトコルに応じて変化する。プロトコルがHTTPBasic認証またはAppIDの場合、SASはユーザ証明を収集するための書式を表示し、これらの証明をSASでセキュアに記憶する。第三者サービス用のプロトコルがOAuthである場合、SASは第三者サービスを用いてOAuthプロトコルを実行し、ユーザはSASによって第三者サービスへとリダイレクトされることになるため、結果として、ユーザ証明は第三者サービスでのみ入力され、SASに記憶されることはない。ブロック210は、ユーザのブラウザを認証サービスのウェブページにリダイレクトすることによって、現在複合アプリケーションと対話しているユーザをリダイレクトすることをさらに含むことができる。本発明の実施形態では、これは、ユーザが現在複合アプリケーションに接続されていない場合、非同期メッセージングサービスを介してユーザに接触することによって実施可能である。非同期メッセージングサービスは、たとえば、電子メール、インスタントメッセージ、または携帯電話のテキストメッセージを含むことができる。SASのOAuthインターフェースを介して異なる第三者サービスのセキュアな認証および認可をトランスペアレントにサポートするためには、OAuthプロトコルの拡張が必要である。これによって、SASは、様々な他の認証プロトコルに関するセキュアプロキシとして動作することができる。そのために、SASは、少なくともターゲットサービスのURLおよび認証タイプが必要である。この情報は、Biteフロー中のアクティビティ指定およびセキュリティ拡張たとえば、図4の18~23行で使用可能であるため、トランスペアレントな第三者サービス認証を実行可能にするために、SASに送信するだけでよい。したがって、BiteエンジンがSASで要求トークンを要求した場合、いくつかの要求パラメータが追加される。ブロック214で、方法は、認証サービスによってユーザ証明を取得することを含む。これは、証明を依頼するために、ユーザを第三者サービスへとリダイレクトすることによって実施可能である。しかしながら、前述のように、第三者サービス用のプロトコルがOAuthである場合、SASは第三者サービスを用いてOAuthプロトコルを実行し、ユーザはSASによって第三者サービスへとリダイレクトされることになるため、結果として、ユーザ証明は第三者サービスでのみ入力され、SASに記憶されることはない。ブロック216で、方法は、認証サービスから2つまたはそれ以上の外部ネットワークリソースのうちの1つに接続することを提供する。認証サービスはユーザ証明を有することが可能であり、第三者リソースによって使用される特定のセキュリティプロトコルのメカニズムに従うことが可能である。加えて、ブロック218で、方法は、認証サービスから保護されたデータを受信することを含む。認証サービスは、データならびにセキュリティのための仲介として動作することができる。図3は、本発明によって企図される、データにアクセスするためのシステムおよび方法の使用のシナリオ例を示す。エンタープライズマッシュアップシナリオは、問題および概念を示すために使用される。このシナリオでは、AcmeIncの採用マネージャ左は、新規ポジションに対する採用を行っている。彼はエンタープライズマッシュアップを使用して、候補者右下との面接をスケジューリングし、その履歴書を入手する。そのためにマッシュアップは、第1に、Googleカレンダを介して使用可能な採用マネージャのカレンダを呼び出す。次にこれが分岐する。下の分岐では、最初のコールに返信し、上の分岐では、利用可能な時間をAcmeの面接スケジューリングサービスにポストし、そのサービスによって戻された最終スロット、および、プロセスを完了するためにたどらなければならないリンクを、候補者に電子メールで送信する。候補者がリンクをクリックすると、自分の個人情報を記入して履歴書を添付する書式が表示される。最終的に、マッシュアップは、オンライン共同ソリューションであるLotusLiveEngage内のFilesファイル共有サービス内に、履歴書を配置する。複数のセキュアな第三者サービスとの対話には、証明および認証プロトコルの様々なセットが必要である。たとえば、GoogleカレンダはOAuthプロトコルを使用し、AcmeのスケジューリングサービスはHTTPBasic認証を使用し、Filesサービスは、アプリケーションキーおよびファイルが追加されることになるストアのユーザを必要とする。Googleカレンダの呼び出しおよびFilesサービスの呼び出しには、どちらも、おそらくはユーザがもはやシステムにログインしていない場合に、マッシュアップがユーザに代わってそれらと対話することが必要である。図4は、図3のシナリオ例からのワークフローモデルのリスト例である。ビジネスマッシュアッププラットフォームBMPは、状況に応じたビジネスプロセスまたはエンタープライズマッシュアップの迅速な開発のために、ホスト開発環境を提供する。グラフィカルマッシュアップ環境は、ブラウザベースであり、BPMNスタイルエディタを活用する、書式デザイナおよびパレット内のデザイナに提供される拡張アクティビティのカタログである。マッシュアップが完全に指定されると、BMPは、即時呼び出しが可能な、マッシュアップの1クリック展開が可能となる。バックエンドでは、Biteコードが生成され、サーバ上で実行される。Biteは、軽量かつ拡張可能なワークフローの実装を容易にするように設計された、XMLベースのREST中心の複合言語である。プロセスモデルは、アトミックアクションアクティビティを含むフラットグラフflatgraphループを除くからなり、それらをリンクする、WS-BPEL実行セマンティクスのサブセットを実装する。ループは、他のアクティビティを含むことができる唯一の構成である、専用のwhileループwhileloopアクティビティを使用して作成することができる。グラフ実行論理は、アクティビティ間の条件付き移行リンク内に符号化される。エラー処理は、エラー処理アクティビティへの特別なエラーリンクによって提供される。Biteは、組み込みアクティビティの小セットである、1HTTP要求receiveGET|POST、replyGET|POST、receive-replyGET|POSTを受信およびこれに返信するため、ならびに外部サービスに対してHTTP要求GET、POST、PUT、DELETEを実行するための、基本HTTP通信プリミティブ、2ローカルコードを待機または呼び出すためのユーティリティアクティビティ、3外部選択およびループなどの制御ヘルパー、を提供する。Biteワークフローは、外部サービスを呼び出すこと、およびサービスとしてそれ自体を提供することの、両方を行う。HTTPPOST要求をワークフローの基本URLに送信すると、結果として、新しいインスタンスURLに割り当てられる新しいワークフローインスタンスが作成される。このインスタンスURLは、応答のHTTPロケーションヘッダフィールドで戻される。インスタンスURLは、そのワークフローへの後続の要求の相関に使用される、ワークフローIDを含む。各ワークフローインスタンスは、複数のエントリポイントに対応する複数の受信アクティビティを定義することができる。これらのアクティビティは、インスタンスのネストされたリソースの論理アドレスとして、追加のURLを公開する。これらのURLに向けて送られるPOST要求は、アクティビティのURL属性で定義された相対URLを使用して、ワークフローモデル内の個々の受信アクティビティにディスパッチされる。このメカニズムによって、ワークフローと対話するための複数のエントリポイントを有する対話型ワークフローを構築することができる。この挙動は、ビジネスマッシュアッププラットフォームBMPによるマッシュアップ作成の一部として設計されるウェブ書式などの、様々なアクティビティによって活用される。Biteの概念は、Bite拡張アクティビティを作成し、それらをBiteエンジンに登録することによって、開発者コミュニティが最上の様式で追加の機能を提供できるようにする、拡張可能設計である。この設計により、言語およびそのランタイムを非常に小規模に維持することが可能であり、開発者は他の必要なアクティビティを拡張として実装することができる。拡張アクティビティは、JavaScriptingAPIたとえばGroovy、Ruby、Pythonなどによってサポートされる、Javaまたは任意のスクリプト言語を使用して作成可能である。図4は、図3の採用サンプルに関する省略されたBiteコードを示す。各マッシュアップは、プロセスと呼ばれるルート要素を有する第1行。新しいワークフローインスタンスは、HTTPPOST要求を初期receivePOSTの相対URL/採用に送信することによって作成される第2行。POST要求に関連付けられたデータは、すべての従属アクティビティに出力される変数hrInputで暗黙的に使用可能である。この場合、変数はすべてのPOSTパラメータのマップを含む。hrInputアクティビティが完了すると、gcalアクティビティが起動される第5~10行。アクティビティ間の移行は、制御要素によって表される第6行。第12~15行から、マッシュアップは、選択された面接日を伴う電子メールを受信することになる旨を通知する、採用マネージャからの初期のHTTPPOSTに返信する。面接スケジューリングは、第18~23行で、HTTPPOST呼び出しを発行することによって実行される。次に、たとえば、どちらもBite拡張アクティビティとして実装される簡潔にするためにリスト内には表示せず、sendMailアクティビティを使用して電子メールを送信すること、および、書式アクティビティを使用して候補者書式を作成することなどの、他の残りのステップが実行される。最後に、shareFile拡張アクティビティ第28~37行が、収集された候補日をLotusLiveにアップロードする。発信されるHTTPGETおよびPOST呼び出しgcalおよびscheduleInterviewならびにshareFileアクティビティは、マッシュアップを正常に実行するために必要な異なるセキュリティ証明を必要とする。図5は、図3に示される本発明の例示的実施形態を実装する、セキュリティソリューションの概要である。以下で詳細に示すように、SASは、複数のユーザがマッシュアップと対話できるようにし、マッシュアップが各ユーザに代わってサービスにアクセスできるようにする。エンタープライズマッシュアッププラットフォームにセキュリティを提供するために、i第三者サービスでのユーザの認証すなわち、ユーザの請求された識別の検証、およびiiBiteエンジンがユーザに代わってタスクを実行することをユーザが認可しなければならないという意味での認可に対処する。加えて、2つの態様が区別される。第1に、セキュリティ問題をBite言語に統合するために、言語レベルでセキュリティに対処する。これは、言語拡張を最小限に維持し、シームレスなユーザ中心の方法で様々な認証プロトコルに関する拡張可能なサポートを提供するために、有利な可能性がある。第2に、拡張可能メカニズムは、異なる認証プロトコルを有する信頼されるサービスの認証および認可を実現するために有益である。このプロセスは、OAuthインターフェースを提供するセキュア認証サービスSASによって、トランスペアレントに処理される。図5では、セキュリティソリューションの基本的概要が示される。実行可能ワークフローを含むBiteエンジンが左側に示されている図3の例の再アセンブリング。白色のサービスは認証を必要としないサービスを構築し、灰色は認証を必要とする。中央は、企業ネットワークがワークフローの実行中に証明を管理する場合に、内部のセキュアな信頼される領域で動作しなければならないSASである。右側には、実行時に呼び出される第三者サービスが示されている。SASを信頼される位置に配置するために有用である。いくつかのオプションは、第三者プロバイダまたは各サービスプロバイダでのSASのいずれかを含む。エンタープライズマッシュアップに焦点が置かれているため、SASは、ユーザとプロキシインフラストラクチャとの間の信頼に関する問題点を少なくする、企業自体によって提供されるサービスであることが可能である。ユーザが、ウェブ書式のまたは他のアプリケーションからのHTTPPOST要求を使用することによって、ワークフローの実行をトリガした場合、マッシュアップが実行され、第1のセキュアな第三者サービス図4のgcalアクティビティに到達するとすぐに、Biteエンジンはセキュリティハンドラを使用して、ユーザのターゲットサービスでの認証を可能にする。ハンドラは、SASと対話することによってこれを実行する。SASは、ターゲットサービスでの様々なセキュリティメカニズムのサポートを提供するために、OAuth、HTTPBasic認証、およびAppIDなどの、複数の異なるセキュリティモジュールへのプラグインを可能にする。認証および認可を実行するための手順には、同期認証および非同期認証の2つのケースがある。同期認証:このケースでは、ユーザはすでにウェブアプリケーションを介してワークフローと対話しているため、単にSASにリダイレクトすることで、ターゲットサービスでの認証を実行することができる。ワークフローにおいて、これは、receiveGET|POSTが、対応するreplyGET|POSTアクティビティに到達することなく、処理されたことを意味する。たとえばこれは、receivePOSTとreplyPOSTとの間にある、図4第5~10行からのgcalアクティビティの場合である。非同期認証:このケースでは、replyGET|POSTアクティビティを実行することによって、ワークフローはすでにユーザに戻っている。別の方法として、receive-replyGET|POSTと呼ばれるアクティビティを使用して、着信要求の受信および即時返信が実行される。したがってユーザは、もはやワークフローと対話しておらず、SASにリダイレクト可能な接続は存在しない。たとえば、図4の第18行以降のすべてのアクティビティすなわち、scheduleInterview、emailCandidate、collectCandidateData、およびstoreApplicationである。可能な解決策は、非同期技法を使用してユーザに接触し、第三者サービスで認証するように要求することである。これは、電子メールおよびインスタントメッセージングを介して達成可能である。BiteエンジンとSASとの間の通信は、OAuthプロトコルのやや拡張されたバージョンを使用して、ウェブアプリケーション当方のケースでは、BiteエンジンおよびSAS間の認証および認可の処理をシームレスに実施する。図6は、例示的セキュリティ拡張要素の図3のシナリオ例からのワークフローモデルのリスト例である。Bite内でのセキュリティを可能にするために、言語を拡張して、認証および認可などのセキュリティ要件を捕捉することができる。目標は、こうした言語拡張を最小限に維持することであってよい。マッシュアップの実行を希望するユーザの認証および認可は、インバウンドセキュリティと呼ばれる。すなわち、インバウンドセキュリティは、メッセージがマッシュアップに送信されるケースであるすなわち、このケースではマッシュアップはセキュアサービスである。インバウンドセキュリティは、ランタイムレベルで実行され、それによってユーザは、OpenID、または外部認証サービスを伴う同様のプロトコルを使用して認証し、認証されたユーザは、受信アクティビティreceiveGET-POSTに関するユーザの制約に照らしてチェック可能なプロセスコンテキストに注入される。ユーザが受信にアクセス可能な場合、アクティビティが起動し、メッセージおよびユーザ情報を適切な変数内に記憶して、完了する。アクセス可能でない場合、エラーがユーザに返信され、受信アクティビティは起動されない。ユーザと対話するすべてのアクティビティに関するユーザ情報は、提供される場合、ランタイム時に暗黙変数[activityname]User内に記憶されることに留意されたい。したがって後続のアクティビティは、この変数を使用して、特定のユーザを逆に参照する。セキュリティの特徴およびアクティビティの要件を定義するために、セキュリティ拡張要素が提供され、GET、POST、PUT、DELETE、および、認証も必要とする可能性のあるカスタム挙動を実装するすべての拡張アクティビティなどの、すべてのアウトバウンド通信アクティビティに対してオプションとされる。図4は、ワークフロー内に3つのセキュリティ要素第9、22、および31~36行を有する。図6に、セキュリティ要素構文が提示されている。属性記述:セキュリティ要素に使用可能な属性は以下の通りである。authtype:ターゲットサービスでユーザを認証するための認証タイプを指定する。OAuth、HTTPBasic認証、および、様々なサービスプロバイダによって単一または複数のGETまたはPOSTパラメータの形で頻繁に使用されるカスタマイズされたアプリケーションIDが、サポートされる。これらの認証タイプの処理は、セキュア認証サービスSASによってトランスペアレントにサポートされる。user:その代理として特定のサービスが実行される、ユーザの名前を文字列または式として定義する。このuser属性は、特に、代理セマンティクスをサポートする拡張アクティビティに関連する。たとえば、図4からの採用ワークフローは、LotusLiveを使用してファイルのアップロードおよび共有を行う。このアプリケーションは、Biteワークフロー内でuser属性によって示される、文書を誰がアップロードしたかを明示的に定義することによって、代理セマンティクスをサポートするこのユーザ名は、その後、LotusLiveのファイル共有サービスで、アップロードされた文書の所有者として使用される。role:ユーザが有することのできる役割を、コンマで区切られた文字列の形で定義する。roleが使用される場合、role定義をランタイムに提供することができる。notification:notificationは、サービスが認証を必要とする旨をどのようにユーザに通知すべきであるかを定義する。同期認証の場合、認証および認可を要求するためにSASにリダイレクトすることによって、httpを使用することができる。非同期の場合、認証を要求するためにワークフローをユーザに戻さなければならない。これは、セキュリティを要求するアクティビティをブロックすること、ユーザに電子メールを送信すること属性値email、または、ユーザをSASに指示するインスタントメッセージングを使用すること属性値sametime、および、認証/認可が完了した時点でアクティビティを再開することによって、実行することができる。手法の1つはLotusSametimeを使用し、他のプロトコルは容易に追加可能である。notificationReceiver:この属性は、通知タイプの電子メールまたはsametimeを使用する場合、連絡先の詳細たとえば電子メールアドレスまたはsametime連絡先を有する必要があるため、こうした場合にのみ必要である。httpの場合、ユーザは依然としてブラウザ内でワークフローと対話しており、認証を実行するためにSASにリダイレクトされるため、これは不要である。scope:scopeは、アクティビティのセキュリティ証明が、再使用のために他のアクティビティに伝搬されるかどうかを定義する。属性値がworkflowである場合、証明が伝搬され、これによって、同じユーザに関するワークフロー内で複数回呼び出されるサービスへの証明の再使用によるログインの反復が避けられる。属性値がactivityの場合、証明は伝搬されない。Bite言語の実行セマンティクスに対するセキュリティ要素の効果は、以下の通りである。セキュリティ要素を有するアクティビティがワークフロー内に達すると、セキュリティ要素の属性の値が評価され、セキュリティコンテキストに記憶され、ワークフローインスタンスに関する実行の状態を維持するプロセスコンテキストにそれ自体が記憶される。この情報を使用して、ハンドラレジストリ内の対応するセキュリティハンドラがルックアップされる。セキュリティコンテキストおよびメッセージペイロードが、必要な認証および認可を提供するためにSASと対話する、このハンドラに提供される。使用可能な証明がない場合、ハンドラは、それらをSASに送信しているユーザに接触する。その後、ハンドラはセキュアな呼び出しを実行して、その結果をアクティビティ実施に戻し、これをその出力変数内に記憶する。scope属性値がactivityに設定された場合、セキュリティハンドラは、必要なセキュリティ処理を続行するために、そのOAuthインターフェースを介してSASに接触し、OAuth接続トークンは認証後に破棄される。workflowに設定された場合、これらのOAuthトークンはプロセスコンテキストに記憶され、同じサービスが同じユーザに関するワークフロー内で再度呼び出される場合に、再使用することができる。SASに接続するために同じOAuthトークンを再使用することで、代理として所与の第三者サービスを呼び出すために、ユーザが以前にBiteを認証および認可したかどうかを判別することができる。非同期のケースはこれ以上ワークフローセマンティクスに影響を与えないが、同期httpのケースは、証明が使用できない場合、ユーザに接触し、ユーザをSASにリダイレクトした後、ワークフローに戻るために、ワークフローインスタンスのオープン接続のうちの1つを再使用する必要があることから、より深く関与している。Biteは、いくつかの受信アクティビティを同時にオープンにすなわち、まだ返信されていない状態にすることができる。したがって、正しいオープン接続を識別しなければならない。そのために、ワークフローインスタンスにおけるオープンな受信アクティビティが、ユーザUser変数値と、処理されているセキュリティ要素内のものとの一致に関してチェックされる。一致する受信アクティビティの返信状況replystatusがリダイレクト待機awaitingredirectに設定され、SASからワークフローへのリダイレクトバックを一致させることが可能な、これに関するキーが作成される。返信は、ユーザをSASにリダイレクトする受信のオープン接続に送信される。ユーザがSASとの作業を完了すると、クライアント側のリダイレクトがユーザをワークフローに返送する。また、一致した受信アクティビティインスタンスがキーを使用して見つけられ、その返信状況がオープンopenにリセットされる。オープンな受信間に一致が見つからない場合、返信待機awaitingreply受信が、最終的にオープンになり、その時点で使用可能な場合にチェックされる。オープンまたはリダイレクト待機の受信間に一致が見つからない場合、非同期のケースで、接触情報がセキュリティ要素定義に提供されるのと同様に、ユーザに接触する。そうでない場合、障害が投じられる。リダイレクト待機の受信に対する返信アクティビティは、受信の応答状況が再度オープンとなり、他のセキュリティリダイレクトがその受信に対して保留中となるまで、待機しなければならず、その後その応答を送信することができる。セキュア認証サービスSASは、様々な認証タイプの異なるセキュアなウェブベースの、たとえばRESTfulサービスを、トランスペアレントに処理することが可能な、プロキシを提供する責務を負う。したがってSASは、異なるセキュリティメカニズムをサポートし、OAuthインターフェース、ウェブベースのAPI間で認証および認可を管理するための普及プロトコルを使用して、それ自体を公開する。本明細書では、これをOAuthプロトコルは、ユーザが自分のサービスプロバイダ証明をコンシューマに開示する必要なしに、ウェブサイトまたはアプリケーションコンシューマが、ウェブサービスサービスプロバイダからAPIを介して保護されたリソースにアクセスできるようにすると定義する。OAuthは、SASとの通信に関するプロトコルとして使用する場合に、以下のような2つの利点を有する。OAuthは、ウェブベースのアプリケーションに関する十分理解されますます普及してきたプロトコルであり、コンシューマとプロバイダとの間での認証および認可を処理するシームレスな方法を実装する。このシナリオでは、コンシューマはBiteエンジンでありプロバイダはSASそれ自体である。OAuthプロバイダは、1要求トークンURL相対URL/requesttoken、2ユーザ認可URL/authorize、および3アクセストークンURL/accesstokenの、3つの異なる要求URLを提供しなければならない。典型的なOAuth認証および認可は、以下のように処理される。第1に、コンシューマは、コンシューマアプリケーション、タイムスタンプ、ナンス、署名などを識別するための事前に交渉されたコンシューマキーなどの、いくつかのOAuth特有のパラメータを送信することによって、要求トークンURL1を使用して要求トークンを要求する。すべてのパラメータが正しくかつ検証可能である場合、サービスプロバイダは未認可の要求トークンを発行する。要求トークンがコンシューマによって受信された場合、ユーザのブラウザは、認証および認可を取得するためにサービスプロバイダへリダイレクトすることができる。この認可により、ブラウザの背後にいるユーザは、コンシューマのウェブアプリケーションが、代理としてサービスプロバイダのリソースへのアクセスを許可されたことを明示的に保証する。認可が実行されると、サービスプロバイダは、コールバックURLを使用してユーザをコンシューマアプリケーションへと再度リダイレクトすることができる。最後にコンシューマは、サービスプロバイダ側で、アクセストークンに関する要求トークンを交換しなければならない。これは典型的には、ユーザが前のステップで認証および認可を正常に実行した場合に付与される。このアクセストークンは、あらゆる他の要求と共に、保護されたサービスとりわけ、コンシューマキー、タイムスタンプ、署名などへと送信されなければならない、OAuthパラメータのうちの1つである。SASのOAuthインターフェースを介して異なる第三者サービスのセキュアな認証および認可をトランスペアレントにサポートするためには、OAuthプロトコルの拡張が必要である。これによってSASは、様々な他の認証プロトコルに対するセキュアプロキシとして動作することができる。そのために、SASは、少なくともターゲットサービスのURLおよび認証タイプが必要である。この情報は、Biteワークフローにおけるアクティビティ指定およびセキュリティ拡張たとえば、図4の第18~23行で使用可能であるため、トランスペアレントな第三者サービスの認証を可能にするために、SASに送信するだけでよい。したがって、以下で考察されるように、BiteエンジンがSASの要求トークンを要求する場合、いくつかの要求パラメータが追加される。HTTPBasic認証は、SSLを使用しない限りそれほどセキュアではないが、実際には幅広く使用されている。これは、HTTPBasicにauthtypeを設定することによって、指定可能であるたとえば、図4の第22行。ランタイム時に、Biteエンジンは、以下の拡張OAuth要求を送信することによって要求トークンを要求することで、SASに接触する。パラメータx-oauth_serviceurlおよびx-oauth_authtypeは、図4からのscheduleInterviewアクティビティからの、セキュアな第三者サービスのターゲットURLおよびその認証タイプを示すこれはHTTPヘッダ拡張の共通パターンであるため、拡張はx-でプレフィックスされている。同期認証のケースでは、ユーザはSASウェブインターフェースにリダイレクトされ、その他の場合非同期のケースでは、notificationReceiver属性に指定されたユーザIDは、認証に使用されるリンク基本的に、同期のケースでBiteのリダイレクト先と同じであるを受信する。これらの2つの拡張属性は、iframeにおけるターゲットURLへの発信呼び出しを実行するために、SASによって使用される。これはユーザに、ターゲットサービスの証明についてのプロンプトを発行する。認証が成功した場合、ターゲットサービスのHTTP認可ヘッダは、SASのプロキシメカニズムによって遮断される。SASでのトランスペアレントなプロキシを達成するために、単純なプロキシサーブレット/proxyが使用される。ターゲットサービスの応答はSASでキューに入れられ、そうでない場合、1回は認証用、1回は最初のサービス呼び出し用の2回、サービスを呼び出すことになる。最初の実際のサービス呼び出しが実行された場合、SASは、認証プロセス中にキューに入れられた応答を戻すことになる。カスタムアプリケーションIDをサポートするには、SASで動的にレンダリングされるウェブ書式においてアプリケーションIDがユーザからどのように照会されるか、および、このデータがたとえば、HTTPヘッダあるいはGETまたはPOSTパラメータ内でどのようにターゲットサービスに送信されるかに関する、詳細を符号化する、x-oauthappidマッピングと呼ばれる、他のOAuth拡張パラメータを追加する必要がある。したがって、Biteワークフロー内のセキュリティ拡張要素が、マッピング要素を定義する図4、第31~36行。より具体的に言えば、このマッピングは、ターゲットサービスが正常な認証に関して、この拡張アクティビティは内部でPOSTを使用するためHTTPPOSTパラメータとして追加する必要のある2つのパラメータ、parおよびkeyを有する旨を提示する。加えて、各要素は、動的にレンダリングされる認証書式において、HTML入力要素に対してラベルとして使用されるlabel属性を定義する。こうしたアプリケーションIDベースサービスの実行時に、Biteエンジンは、前述のOAuth拡張を使用してSASに転送される、単純なテキストベース書式へのBiteXMLマッピングをシリアル化する。その後、アプリケーションIDに関するプロンプトを発行するために、動的にレンダリングされる認証書式が表示される。OAuthに関するサポートは、SASによってもトランスペアレントにサポートされる。このケースでは、SASは、いずれの情報も記憶することなく、Biteとターゲットサービスプロバイダとの間の他の層のリダイレクトを追加するだけである。OAuthベースのサービスを直接消費するために、Biteは、すでにSASに対するOAuthコンシューマであるためカスタマイズされたセキュリティハンドラを実装することが可能となる。しかしながら、OAuthベースのサービスを消費する場合、SASを経由することは、Biteエンジンに対して複数のセキュリティメカニズムをトランスペアレントに処理する利点を有する。BiteおよびSASは、Java1.6で実装されている。Biteは、サーブレットコンテナまたはWebShperesMashサーバのいずれかで実行可能である。SASの実装は、異なるエンドポイントに複数のサーブレットを提供する要求トークン、アクセストークンなどGoogleのJavaOAuth実装に基づく。これらのサーブレットは、前述のセキュリティプロトコルをトランスペアレントにサポートするように拡張されている。Biteエンジンは、セキュリティ要素を用いてアクティビティからサービスを呼び出す際に、特定のセキュリティハンドラを使用することによってSASSecurityHandler、OAuthクライアントを実装する。他のすべての呼び出しは、SASを含まないNullSecurityHandlerを使用する。図7は、図3のシナリオ例からの、SASへリダイレクトされた場合の、ユーザのブラウザのウェブページの例である。図8は、図3のシナリオ例からの、ユーザのブラウザの認可ウェブページの例である。図7および図8は、カスタムアプリケーションIDをセキュリティメカニズムとして使用する、図4からのshareFileアクティビティ第28~37行に関する認証および認可のためのSASのウェブインターフェースを示す。図7は、Biteでの指定に基づいて動的にレンダリングされる認証書式を示す。ユーザのブラウザがSASにリダイレクトされた場合、ユーザには、図に示されるようなウェブページが示される。リンクをクリックすることで、認証ボックスがポップアップし、ユーザは証明を入力する。証明をサブミットした後、ユーザは、代理でサービスを呼び出すことをBiteに明示的に認可しなければならない図8。ユーザがBiteを認可した場合、ワークフローはその実行を続行し、ユーザはワークフローアプリケーションにリダイレクトバックされ同期のケースで、認可しない場合、エラーが投じられる。HTTPBasic認証にも同じユーザ経験が使用可能であるが、ダイアログボックスは動的にレンダリングされず、ブラウザ特有である。SASに基づく提案された手法は、本発明のケースでのBiteなどのコンシューマアプリケーションに対する証明の開示の必要なしに、第三者サービスの認証および認可の両方を、効果的にサポートする。当業者であれば理解されるように、本発明の態様は、システム、方法、またはコンピュータプログラム製品として具体化することができる。したがって、本発明の態様は、完全にハードウェア実施形態、完全にソフトウェア実施形態ファームウェア、常駐ソフトウェア、マイクロコードなどを含む、あるいは、本明細書ではすべてが全体として回路、モジュール、またはシステムと呼ばれることのあるソフトウェアおよびハードウェアの態様を組み合わせた実施形態の、形を取ることができる。さらに、本発明の態様は、その上に具体化されたコンピュータ読み取り可能プログラムコードを有する、1つまたは複数のコンピュータ読み取り可能媒体内で具体化される、コンピュータプログラム製品の形を取ることができる。1つまたは複数のコンピュータ読み取り可能媒体の任意の組み合わせを使用することができる。コンピュータ読み取り可能媒体は、コンピュータ読み取り可能信号媒体またはコンピュータ読み取り可能記憶媒体とすることができる。コンピュータ読み取り可能記憶媒体は、たとえば、電子、磁気、光、電磁、赤外線、または半導体のシステム、装置、またはデバイス、あるいはそれらの任意の好適な組み合わせとすることができるが、これらに限定されるものではない。コンピュータ読み取り可能記憶媒体のより具体的な例非網羅的リストは、1本または複数本のワイヤを有する電気接続、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリRAM、読み取り専用メモリROM、消去可能プログラマブル読み取り専用メモリEPROMまたはフラッシュメモリ、光ファイバ、ポータブルコンパクトディスク読み取り専用メモリCD-ROM、光記憶デバイス、磁気記憶デバイス、あるいは、それらの任意の好適な組み合わせを含むものである。本書との関連において、コンピュータ読み取り可能記憶媒体は、命令実行のシステム、装置、またはデバイスによって、あるいはそれらと関連して使用するためのプログラムを、含むかまたは記憶することが可能な、任意の有形媒体とすることができる。コンピュータ読み取り可能信号媒体は、たとえば、ベースバンド内、または搬送波の一部として、内部にコンピュータ読み取り可能プログラムコードが具体化された、伝搬データ信号を含むことができる。こうした伝搬信号は、電磁、光、またはそれらの任意の好適な組み合わせを含むが、これらに限定されない、多様な形のうちのいずれかを取ることができる。コンピュータ読み取り可能信号媒体は、コンピュータ読み取り可能記憶媒体でなく、命令実行のシステム、装置、またはデバイスによって、あるいはそれらと関連して使用するためのプログラムを、通信、伝搬、または移送することが可能な、任意のコンピュータ読み取り可能媒体とすることができる。コンピュータ読み取り可能媒体上に具体化されるプログラムコードは、ワイヤレス、ワイヤライン、光ファイバケーブル、RFなど、またはそれらの任意の好適な組み合わせを含むが、それらに限定されない、任意の適切な媒体を使用して伝送可能である。本発明の態様に関する動作を実行するためのコンピュータプログラムコードは、Java、Smalltalk、Cなどの、オブジェクト指向プログラミング言語、および、Cプログラミング言語または同様のプログラミング言語などの、従来の手続き型プログラミング言語を含む、1つまたは複数のプログラミング言語の任意の組み合わせで作成可能である。プログラムコードは、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンドアロン型ソフトウェアパッケージとして、部分的にユーザのコンピュータ上および部分的にリモートコンピュータ上で、あるいは、完全にリモートコンピュータまたはサーバ上で、実行可能である。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワークLANまたはワイドエリアネットワークWANを含む、任意のタイプのネットワークを介して、ユーザのコンピュータに接続することができるか、あるいは、たとえば、インターネットサービスプロバイダを使用し、インターネットを介して外部コンピュータに接続することができる。本発明の態様について、本発明の実施形態に従った方法、装置システム、およびコンピュータプログラム製品の、流れ図またはブロック図あるいはその両方を参照しながら、以下で説明する。流れ図またはブロック図あるいはその両方の各ブロック、および、流れ図またはブロック図あるいはその両方におけるブロックの組み合わせは、コンピュータプログラム命令によって実装可能であることを理解されよう。これらのコンピュータプログラム命令は、機械を製造するために、汎用コンピュータ、特定用途向けコンピュータ、または他のプログラマブルデータ処理装置のプロセッサに提供可能であり、結果として、コンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行する命令は、流れ図またはブロック図あるいはその両方のブロック内に指定された機能/動作を実装するための手段を作成する。これらのコンピュータプログラム命令は、コンピュータ、他のプログラマブルデータ処理装置、または他のデバイスに対して、特定の様式で機能するように命じることが可能な、コンピュータ読み取り可能媒体内に記憶することも可能であり、結果として、コンピュータ読み取り可能媒体内に記憶された命令は、流れ図またはブロック図あるいはその両方のブロック内に指定された機能/動作を実装する命令を含む製品を製造する。コンピュータプログラム命令は、コンピュータ実装プロセスを生成するために、コンピュータ、他のプログラマブルデータ処理装置、または他のデバイス上で一連の動作ステップを実行させるように、コンピュータ、他のプログラマブルデータ処理装置、または他のデバイス上にロードすることも可能であり、結果として、コンピュータまたは他のプログラマブル装置上で実行する命令は、流れ図またはブロック図あるいはその両方のブロック内に指定された機能/動作を実装するためのプロセスを提供する。図面内の流れ図およびブロック図は、本発明の様々な実施形態に従ったシステム、方法、およびコンピュータプログラム製品の可能な実装の、アーキテクチャ、機能、および動作を図示している。この点において、流れ図またはブロック図内の各ブロックは、指定された論理機能を実装するための1つまたは複数の実行可能命令を含む、モジュール、セグメント、またはコードの一部を表すことができる。いくつかの代替の実装では、ブロック内に記載された機能は、図面内に示された順序以外で発生可能であることにも留意されたい。たとえば、連続して示された2つのブロックは、実際にはほぼ同時に実行可能であるか、またはブロックは、関連する機能に応じて時には逆の順序で実行可能である。ブロック図または流れ図あるいはその両方の各ブロック、および、ブロック図または流れ図あるいはその両方におけるブロックの組み合わせは、指定された機能または動作、あるいは特定用途向けハードウェアおよびコンピュータ命令の組み合わせを実行する、特定用途向けハードウェアベースのシステムによって実装可能であることにも留意されよう。以上、本発明の好ましい実施形態について説明してきたが、当業者であれば、現在および将来のどちらにおいても、以下の特許請求の範囲の範囲内に入る様々な改良および機能強化を実行可能であることを理解されよう。したがって、特許請求の範囲は、最初に説明された本発明に関する適切な保護を維持するものと解釈されたい。"