情報処理システム、情報処理方法、プログラム、及び、記録媒体
【課題】容易に複数のアプリケーションにおいてシームレスな認証を可能とすること。
【解決手段】アプリサーバ１は、画面要求にSsIDがない場合、ワークフローサーバのＵＲＬ（戻りＵＲＬ含む）にリダイレクトさせる。ワークフローサーバは、要求に含まれる戻りＵＲＬをログイン画面に埋め込みブラウザへ送る。またログイン処理が成功するとSsIDを生成してワークフローＤＢに登録する。またブラウザをログイン要求に含まれていた戻りＵＲＬ（SsID含む）にリダイレクトさせる。アプリサーバ１は画面要求にSsIDがある場合、SsIDの有効性をワークフローサーバに確認する。有効性はワークフローＤＢに基づいて確認される。有効な場合、アプリサーバ１はSsIDを埋め込んだ画面をブラウザへ送る。またアプリサーバ２への画面遷移要求を受けた場合、ブラウザをアプリケーションサーバ２のＵＲＬ（SsID含む）にリダイレクトさせる。
【解決手段】アプリサーバ１は、画面要求にSsIDがない場合、ワークフローサーバのＵＲＬ（戻りＵＲＬ含む）にリダイレクトさせる。ワークフローサーバは、要求に含まれる戻りＵＲＬをログイン画面に埋め込みブラウザへ送る。またログイン処理が成功するとSsIDを生成してワークフローＤＢに登録する。またブラウザをログイン要求に含まれていた戻りＵＲＬ（SsID含む）にリダイレクトさせる。アプリサーバ１は画面要求にSsIDがある場合、SsIDの有効性をワークフローサーバに確認する。有効性はワークフローＤＢに基づいて確認される。有効な場合、アプリサーバ１はSsIDを埋め込んだ画面をブラウザへ送る。またアプリサーバ２への画面遷移要求を受けた場合、ブラウザをアプリケーションサーバ２のＵＲＬ（SsID含む）にリダイレクトさせる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントと、ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと、情報処理サーバとを含む情報処理システムに関し、とくに複数のウェブアプリケーションにまたがるユーザ認証制御に関する。
【背景技術】
【０００２】
基幹業務におけるワークフローアプリケーションを作成する場合、業務アプリケーションとワークフローエンジンを組み合わせて作成する。また、基幹業務におけるワークフローアプリケーションは、いくつかの異なる業務にまたがって処理するため、複数のシステムが関連する。
【０００３】
特許文献１には、複数のシステムが関連している環境において、処理速度の低下等を防止する技術が記載されている。
【０００４】
なお、特許文献１では、認証に関しては何ら開示されていないが、実際のシステムでは認証機能を持っているのが一般的である。
【特許文献１】特開２００７−５２６９７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上記複数のシステムが関連している環境において、各アプリケーションがそれぞれ認証機能を持っている場合、異なるアプリケーションへ遷移した際に、その都度、ログイン処理が必要となり、ユーザ便宜を悪くしていた。また、ユーザの管理するＩＤやパスワードの数も増え、非常に煩雑であった。
【０００６】
このような複数のシステムにまたがるアプリケーションでは、エンドユーザから見た場合、1つのシステムとしてシームレスにつながっていることが理想的である。
【０００７】
このようなシステムを構築するためには、異なるアプリケーションに遷移した場合でも、その都度、ログイン画面を表示することなく、異なるアプリケーション間で、ユーザ情報が引き継がれる必要がある。即ち、異なるアプリケーション間で、ログイン情報やセッション情報を各システム間で受け渡しする必要がある。
【０００８】
このようなシステムの構築方法として、ＬＤＡＰ(Lightweight Directory Access Protocol)等を利用したシングル・サインオン(Single Sign-On)のような認証統括システムを利用したものがある。
【０００９】
しかし、シングル・サインオンを実現するためには、それぞれのアプリケーションで、(1)ユーザの認証情報が統一されていなければならない、(2)認証インタフェースが統合されていなければならない、(3)アクセス制御が統合されていなければならない等の要件をクリアする必要がある。そのため、シングル・サインオン環境を導入するための構築作業が煩雑であり、非常に時間がかかってしまう等の問題点があった。
【００１０】
本発明は、上記の問題点を解決するためになされたもので、小規模な情報処理システムにおいて、ＬＤＡＰ等のシングル・サインオンの技術を用いることなく、容易に複数のアプリケーションにおいてシームレスな認証を可能とするシステムを容易に構築可能な仕組を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと、情報処理サーバとを含む情報処理システムであって、前記ウェブアプリケーションサーバは、ウェブクライアントからアプリケーション画面情報の要求を受け付けた場合、該要求に、前記情報処理サーバへのログイン状況を示す識別子が含まれているかを判定する判定手段と、前記判定手段により前記識別子が含まれないと判定された場合、前記ウェブクライアントから前記情報処理サーバへ前記ログイン画面情報を要求させるための、該情報処理サーバのロケーション情報に、当該ウェブアプリケーションサーバのロケーション情報をパラメータとして付加して、前記ウェブクライアントに通知する第１の通知手段と、前記判定手段により前記識別子が含まれると判定された場合、該識別子の有効性を前記情報処理サーバに問い合わせる問い合わせ手段と、前記問い合わせ手段による問い合わせの結果、前記識別子が有効である場合、前記識別子を埋め込んだウェブアプリケーション画面情報を、前記ウェブクライアントへ送信する第１の画面情報送信手段と、前記ウェブクライアントから他のウェブアプリケーションサーバへ画面を遷移する要求を受け付けた場合、前記ウェブクライアントから前記他のウェブアプリケーションサーバへ前記他のウェブアプリケーション画面情報を要求させるための、該他のウェブアプリケーションサーバのロケーション情報に、前記要求内の前記ウェブアプリケーション画面情報に含まれる識別情報を、パラメータとして付加して、前記ウェブクライアントに通知する第２の通知手段とを有し、前記情報処理サーバは、前記ウェブクライアントから前記ログイン画面情報の要求を受け付けた場合、前記要求に含まれる前記ウェブアプリケーションサーバのロケーション情報を、前記ログイン画面情報に埋め込んで、前記ウェブクライアントへ送信する第２の画面情報送信手段と、前記ウェブクライアントから前記ログイン画面情報を含むログイン要求を受け付けた場合、ログイン処理を行うログイン処理手段と、前記ログイン処理手段によるログイン処理が成功した場合、前記識別子を生成して保持手段に保持させる識別子生成手段と、前記ウェブクライアントから前記ウェブアプリケーションサーバへ前記アプリケーション画面情報を要求させるための、前記ログイン要求内のログイン画面情報に含まれていた前記ウェブアプリケーションサーバのロケーション情報に、前記識別子生成手段により生成された識別子をパラメータとして付加して、前記ウェブクライアントに通知する第３の通知手段と、前記問い合わせ手段により問い合わされた識別子が有効であるか否かを、該識別子が前記保持手段に保持されているか否かで判定し、該判定結果を返信する識別子有効性判定手段とを有することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、小規模な情報処理システムにおいて、ＬＤＡＰ等のシングル・サインオンの技術を用いることなく、容易に複数のアプリケーションにおいてシームレスな認証を可能とすることができる。
【００１３】
したがって、複数の業務アプリケーションサーバとワークフローサーバとの間でのユーザ認証情報やセッション情報の受け渡しをするアプリケーションを開発し易いアプリケーション構築方法を提供することができる等の効果を奏する。
【発明を実施するための最良の形態】
【００１４】
図１は、本発明の一実施形態を示す情報処理システムの一例を示すシステム構成図である。本例では、基幹業務におけるワークフローアプリケーションの構成を示す。
【００１５】
図１において、００１，００２はアプリケーションサーバ（ウェブアプリケーションサーバ）である。アプリケーションサーバ１（００１），００２は、業務処理（例えば、受注システム，出荷システム等）の業務アプリケーション（ウェブアプリケーション）を実行し、アプリケーションＤＢ００５に、その情報を保管する。
【００１６】
ワークフローサーバ００３は、ワークフロー経路情報に従って、ワークフロー操作（承認、否認、差戻し等）処理を行い、ワークフローＤＢ００４に、その情報を保管する。
【００１７】
クライアントブラウザ００６は、クライアント端末でウェブクライアントとして動作するウェブブラウザを示す。クライアントブラウザ００６は、ユーザの指示に従って、ネットワーク００７を介してアプリケーションサーバ１（００１）、アプリケーションサーバ２（００２）、ワークフローサーバ００３に通信し、アプリケーション処理を行う。
【００１８】
なお、図中、００１〜００６は、それぞれ異なる情報処理装置に実装されてもよいし、いずれか又は全てが同一の情報処理装置に実装される構成であってもよい。
【００１９】
図２は、図１に示したアプリケーションサーバ１（００１）、アプリケーションサーバ２（００２）、ワークフローサーバ００３、クライアントブラウザ００６に適用可能な情報処理装置のハードウェア構成の一例を示すブロック図である。
【００２０】
図２において、１０１はＣＰＵであり、ＲＯＭ１０３或いは外部記憶装置（ハードディスク（ＨＤ）等）１０４に記憶されている制御プログラムに基づいて、システムバスに接続されている各種デバイスとのアクセスを総括的に制御する。
【００２１】
１０２はＲＡＭで、ＣＰＵ１０１の主メモリ、ワークエリア等として機能する。ＲＯＭ１０３或いはＨＤ１０４には、ＣＰＵ１０１の制御プログラムであるＢＩＯＳ（Basic Input / Output Ｓystem）やオペレーティングシステム（ＯＳ）プログラム、後述するフローチャートに示す処理をＣＰＵに実行させるために必要な各種プログラム等が記憶されている。そして、ＣＰＵ１０１は、必要なプログラム等をＲＡＭ１０２にロードして実行することにより、各種機能を実現するものである。
【００２２】
また、１０５は、キーボードやマウス等の入力装置である。１０６は、ＬＣＤやＣＲＴ等の表示装置である。１０７はネットワークインタフェースカード（ＮＩＣ）であり、ＬＡＮ，ＷＡＮ等のネットワーク００７を介して、他の装置と通信可能に構成されている。
【００２３】
以下、図３のシーケンスチャートを参照して、クライアントブラウザ００６からアプリケーションサーバ１（００１）にログインする手順について説明する。
【００２４】
図３は、クライアントブラウザ００６からアプリケーションサーバ１（００１）にログインする手順の一例を示すシーケンスチャートである。
【００２５】
図３において、まず、Ｓ２０１〜Ｓ２０３は、クライアントブラウザ００６から初めてアプリケーションサーバ１（００１）の処理画面を要求したときの動作である。
【００２６】
Ｓ２０１では、クライアントブラウザ００６からアプリケーションサーバ１（００１）に、後述する図１２に示すログイン画面を要求する。
【００２７】
２０２では、アプリケーションサーバ１（００１）は、図４に示す処理を行い、ワークフローサーバのログイン画面（後述する図７）のＵＲＬ（ロケーション情報）をクライアントブラウザ００６にリダイレクトする（Ｓ２０３）。なお、リダイレクトとは、あるＵＲＬから他のＵＲＬに転送させることをいう。図３のＳ２０３では、アプリケーションサーバ１（００１）は、クライアントブラウザ００６からワークフローサーバ００３へ前記ログイン画面情報の要求をさせるための、ワークフローサーバ００３のＵＲＬに、当該アプリケーションサーバ１（００１）のＵＲＬをパラメータとして付加して、クライアントブラウザ００６に通知する処理を行う。
【００２８】
ここで、図４を用いて、Ｓ２０２，Ｓ２０３の処理について詳細に説明する。
【００２９】
図４は、アプリケーションサーバ１（００１）の動作の一例を示すフローチャートである。なお、このフローチャートの各ステップ（Ｓ３０１〜Ｓ３１０）は、アプリケーションサーバ１（００１）を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、アプリケーションサーバ１（００１）が実行すると記載する。
【００３０】
まず、クライアントブラウザ００６からのログイン画面の表示要求（図３のＳ２０１）を受信すると、アプリケーションサーバ１（００１）は、Ｓ３０１に処理を進める。
【００３１】
Ｓ３０１において、アプリケーションサーバ１（００１）は、セッションの状態を判定する。図３のＳ２０２の場合、クライアントブラウザ００６からの画面表示要求（図３のＳ２０１）が最初の要求のため、セッションは存在しない。つまり、セッション上のログイン済みフラグは存在していないため、アプリケーションサーバ１（００１）は、Ｓ３０１を偽（Ｎ）と判定し、Ｓ３０２に処理を進める。
【００３２】
Ｓ３０２において、アプリケーションサーバ１（００１）は、パラメータにパラメータ名SsIDに対応する値が存在するか判定する。最初の要求では、クライアントブラウザ００６はパラメータを指定していない。そのため、アプリケーションサーバ１（００１）は、Ｓ３０２を偽（Ｎ）と判定し、Ｓ３０３に処理を進める。なお、SsIDとは、ワークフローサーバ００３へのログイン状況を確認するために使用される識別子である。
【００３３】
Ｓ３０３において、アプリケーションサーバ１（００１）は、アプリケーションサーバ１（００１）の外部記憶装置１０４上にある設定ファイル「workflow.conf」（図５）を読み取りＲＡＭ１０２に格納する。
【００３４】
図５は、アプリケーションサーバ１（００１）の外部記憶装置１０４上に記憶される設定ファイル「workflow.conf」の一例を示す図である。
【００３５】
図５に示すように、「workflow.conf」は、全てのアプリケーションサーバとワークフローサーバに予め準備されるものであり、共通の情報（ＵＲＬ情報）が記載されるものである。
【００３６】
次に、Ｓ３０４において、アプリケーションサーバ１（００１）は、Ｓ３０３で読み込んだ情報からワークフローサーバ００３のＵＲＬ（例えば、図５の９０１）を取得し、該取得したＵＲＬに、現在のリクエストのＵＲＬを、戻りＵＲＬパラメータとして付加する。ここでは、アプリケーションサーバ１（００１）のＵＲＬが戻りＵＲＬパラメータとして付加される。
【００３７】
次に、Ｓ３０５において、アプリケーションサーバ１（００１）は、Ｓ３０４で作成したＵＲＬ（現在のリクエストのＵＲＬを戻りＵＲＬパラメータとして付加したワークフローサーバのＵＲＬ）をクライアントブラウザ００６にリダイレクトする（図３の２０３）。
【００３８】
以上、図３のＳ２０２，Ｓ２０３の動作を詳細に説明した。
【００３９】
次に、Ｓ２０４〜Ｓ２０６は、ワークフローサーバ００３が、ログインページを表示するまでの動作を示す。
【００４０】
Ｓ２０４では、クライアントブラウザ００６は、アプリケーションサーバ１（００１）のレスポンスに従ってリダイレクト先、つまり、ワークフローサーバ００３のＵＲＬにアクセスする。
【００４１】
Ｓ２０５では、ワークフローサーバ００３は、図６に示す処理を行い、Ｓ２０６において、ログイン画面（図７）をクライアントブラウザ００６に送信し、クライアントブラウザ００６にログイン画面（図７）を表示させる。
【００４２】
ここで、図６を用いて、Ｓ２０５，Ｓ２０６の処理について詳細に説明する。
【００４３】
図６は、ワークフローサーバ００３の動作の一例を示すフローチャートである。なお、このフローチャートの各ステップ（Ｓ４０１〜Ｓ４０７）は、ワークフローサーバ００３を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、ワークフローサーバ００３が実行すると記載する。
【００４４】
まず、クライアントブラウザ００６からのリクエストを受信すると（図３のＳ２０４）、ワークフローサーバ００３は、Ｓ４０１に処理を進める。
【００４５】
Ｓ４０１において、ワークフローアプリケーション００４は、ワークフローＤＢ００４のユーザログイン情報上にセッションＩＤが存在するか判定する。図３のＳ２０４の場合、クライアントブラウザ００６からのリクエスト（図３のＳ２０４）が最初のアクセスなので、ワークフローＤＢ００４のユーザログイン情報上にセッションＩＤは存在しない。つまり、ワークフローサーバ００３は、Ｓ４０１を偽（Ｎ）と判定し、Ｓ４０２に処理を進める。
【００４６】
Ｓ４０２では、ワークフローサーバ００３は、現在のリクエストがログインページのログインボタンが押されたものか判定する。図３のＳ２０４の場合、該当しないため、ワークフローサーバ００３は、Ｓ４０２を偽（Ｎ）と判定し、Ｓ４０３に処理を進める。
【００４７】
Ｓ４０３では、ワークフローサーバ００３は、図４のＳ３０４においてパラメータとしてリクエストに付加された戻りＵＲＬ情報を取得し、これを保持するために、ログイン画面（図７）の項目にセットする。ログイン画面の項目にセットするとは、例えば、このログイン画面を構成するＨＴＭＬなどの構造化言語内の非表示項目に記述することで実現する。
【００４８】
次に、Ｓ４０４において、ワークフローサーバ００３は、ログイン画面（図７）をクライアントブラウザ００６にレスポンスする（図３のＳ２０６）。
【００４９】
以上、図３のＳ２０５，Ｓ２０６の動作を詳細に説明した。
【００５０】
図７は、クライアントブラウザ００６に表示されるログイン画面の一例を示す図である。
【００５１】
ユーザは、クライアントブラウザ００６から、７０１にユーザ名（ユーザＩＤ），７０２にパスワードを入力し、ログインボタン７０３を押下指示して、ログイン操作を行う。
【００５２】
次に、図３のＳ２０７〜Ｓ２１０では、ログイン画面（図７）のログインボタン７０３がユーザによって押下されワークフローサーバでログイン処理する動作を示す。
【００５３】
Ｓ２０７において、ユーザは、クライアントブラウザ００６にユーザ名、パスワードを入力してログインボタン７０３を押下する。
【００５４】
この操作を検知したクライアントブラウザ００６は、Ｓ２０８において、入力されたユーザ名、パスワード、図６のＳ４０３でログイン画面（図７）にセットされた戻りＵＲＬを、ワークフローサーバ００３に送信する。ここでは、アプリケーションサーバ１（００１）のＵＲＬが、戻りＵＲＬとして送信される。
【００５５】
次に、Ｓ２０９において、ワークフローサーバ００３は、図６の処理を行い、クライアントブラウザ００６から受信したユーザ名、パスワードを元にログイン確認処理を行い、ログイン処理をする。
【００５６】
そして、Ｓ２１０において、ワークフローサーバ００３は、アプリケーション画面のＵＲＬをリダイレクトする。詳細には、Ｓ２１０では、ワークフローサーバ００３は、クライアントブラウザ００６からアプリケーションサーバ１（００１）へ前記アプリケーション画面情報の要求させるための、前記ログイン要求内のログイン画面情報に含まれていた前記アプリケーションサーバ１（００１）のＵＲＬに、前記識別子をパラメータとして付加して、クライアントブラウザ００６に通知する処理を行う。
【００５７】
ここで、図６を用いて、Ｓ２０９，Ｓ２１０の処理について詳細に説明する。
【００５８】
まず、クライアントブラウザ００６からユーザ名，パスワード，戻りＵＲＬを受信すると（図３のＳ２０８）、ワークフローサーバ００３は、図６のＳ４０１に処理を進める。
【００５９】
Ｓ４０１において、ワークフローアプリケーション００４は、ワークフローＤＢ００４のユーザログイン情報上にセッションＩＤが存在するか判定する。図３のＳ２０８の場合、Ｓ２０４に次ぐ２度目のアクセスであるが、まだセッションＩＤはセットされておらず、Ｓ２０４の場合と同様に、ワークフローＤＢ００４のユーザログイン情報上にセッションＩＤは存在しない。つまり、ワークフローサーバ００３は、Ｓ４０１を偽（Ｎ）と判定し、Ｓ４０２に処理を進める。
【００６０】
Ｓ４０２では、ワークフローサーバ００３は、現在のリクエストがログインページのログインボタンが押されたものか判定する。図３のＳ２０８の場合、ログインボタンが押下されたものであるため、ワークフローサーバ００３は、Ｓ４０２を真（Ｙ）と判定し、Ｓ４０５に処理を進める。
【００６１】
Ｓ４０５では、ワークフローサーバ００３は、受信したユーザ名，パスワードが有効であるかチェックする。ワークフローサーバ００３は、上記受信したユーザ名，パスワードと、ワークフローＤＢ００４のユーザログイン情報との比較を行うことで有効性のチェックが可能であるが、ここではその方式は特に問わないため省略する。
【００６２】
そして、ユーザ名，パスワードが有効でない場合（ログインエラーの場合）には、ワークフローサーバ００３は、Ｓ４０５を真（Ｙ）と判定し、Ｓ４０３，Ｓ４０４において、エラーメッセージ情報とともに、再びログインページをクライアントブラウザ００６に表示させる。そして、本フローチャートの処理を終了する。
【００６３】
一方、Ｓ４０５において、ユーザ名，パスワードが有効である場合（ログインが成功した場合）には、ワークフローサーバ００３は、Ｓ４０５を偽（Ｎ）と判定し、Ｓ４０６に処理を進める。
【００６４】
Ｓ４０６では、ワークフローサーバ００３は、SsIDを生成し、ワークフローＤＢ００４のユーザログイン情報に登録する。なお、SsIDは、アプリケーションサーバ、ワークフローサーバでユニークに識別できるものであればよい。ここでは、SsIDはセッションＩＤと同等のものを使用する。なお、SsIDを、タイムアウトにより削除する運用も可能である。
【００６５】
次に、Ｓ４０７において、ワークフローサーバ００３は、戻りＵＲＬ（図６のＳ４０３でログイン画面（図７）にセットされた戻りＵＲＬ）のパラメータにＳ４０６で生成したSsIDを付加し（図８）、該戻りＵＲＬをリダイレクト先としてクライアントブラウザ００６にレスポンスする（図３のＳ２１０）。
【００６６】
以上、図３のＳ２０９，Ｓ２１０の動作を詳細に説明した。
【００６７】
図８は、図６のＳ４０７でパラメータとしてSsIDを付加した戻りＵＲＬの一例を示す図である。
【００６８】
次に、図３のＳ２１１〜Ｓ２１６では、ログイン処理後、アプリケーション画面を表示するまでの処理を示す。
【００６９】
Ｓ２１１では、クライアントブラウザ００６は、ワークフローサーバ００３のレスポンスに従ってリダイレクト先、つまり、アプリケーションサーバ１（００１）のＵＲＬにアクセスする。
【００７０】
Ｓ２１２では、アプリケーションサーバ１（００１）は、図４の処理を行い、Ｓ２１３において、ワークフローサーバ００３に対してログイン確認を行う。
【００７１】
Ｓ２１４において、ワークフローサーバ００３は、図９に示すログイン確認処理を行い、Ｓ２１５において、ログイン確認結果をアプリケーションサーバ１（００１）に返信する。
【００７２】
Ｓ２１６では、アプリケーションサーバ１（００１）は、ログイン結果がＯＫであったら、アプリケーション画面（後述する図１１）をクライアントブラウザ００６に送信し、クライアントブラウザ００６にアプリケーション画面（図１１）を表示させる。
【００７３】
ここで、図４，図９を用いて、Ｓ２１２〜Ｓ２１６の処理について詳細に説明する。
【００７４】
まず、クライアントブラウザ００６からのリクエスト（図３のＳ２１１）を受信すると、アプリケーションサーバ１（００１）は、図４のＳ３０１に処理を進める。
【００７５】
Ｓ３０１において、アプリケーションサーバ１（００１）は、セッションの状態を判定する。図３のＳ２０２の場合、Ｓ２０１に次ぐ２回目のアクセスのためセッション自身は存在するが、まだログイン済みフラグはセットされておらず、Ｓ２０１の場合と同様に、アプリケーションサーバ１（００１）は、Ｓ３０１を偽（Ｎ）と判定し、Ｓ３０２に処理を進める。
【００７６】
Ｓ３０２において、アプリケーションサーバ１（００１）は、パラメータにパラメータ名SsIDに対応する値が存在するか判定する。図６のＳ４０７においてSsIDがパラメータに指定されているので、アプリケーションサーバ１（００１）は、Ｓ３０２を真（Ｙ）と判定し、Ｓ３０６に処理を進める。
【００７７】
Ｓ３０６において、アプリケーションサーバ１（００１）は、Ｓ３０２で取得したSsIDを、ワークフローサーバ００３に対して有効であるか問い合わせをする（図３のＳ２１３〜２１５、図９のＳ５０１〜Ｓ５０３）。
【００７８】
図３のＳ２１３〜Ｓ２１５は、ワークフローサーバ００３において、SsIDがワークフローＤＢ００４のログイン情報に登録されているかどうかを判定する処理である。
【００７９】
図３のＳ２１３において、アプリケーションサーバ１（００１）は、パラメータにSsIDを指定して、図９に示すようなＷｅｂ Ｓｅｒｖｉｃｅを呼び出す。
【００８０】
図３のＳ２１４は、Ｓ２１３の呼び出しに対応するワークフローサーバ側の処理であり、その詳細な処理を図９に示す。
【００８１】
図９は、ワークフローサーバ００３のログイン確認動作の一例を示すフローチャートである。なお、このフローチャートの各ステップ（Ｓ５０１〜Ｓ５０３）は、ワークフローサーバ００３を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、ワークフローサーバ００３が実行すると記載する。
【００８２】
図９のＳ５０１〜Ｓ５０３は、アプリケーションサーバ１（００１）が、パラメータSsIDを含むリクエスト（ログイン確認要求）を受信し、SsIDが有効であるかどうかを判定し、結果を返す動作の詳細である。
【００８３】
まず、アプリケーションサーバ１（００１）からのパラメータSsIDを含むリクエスト（ログイン確認要求）を受信すると（図３のＳ２１３）、ワークフローサーバ００３は、Ｓ５０１に処理を進める。
【００８４】
Ｓ５０１では、ワークフローサーバ００３は、パラメータで与えられたSsIDがワークフローＤＢ００４内のログイン情報に存在する（登録済み）か判定する。
【００８５】
そして、パラメータで与えられたSsIDがワークフローＤＢ００４内のログイン情報に存在する（登録済み）と判定した場合には、ワークフローサーバ００３は、Ｓ５０２に処理を進める。
【００８６】
Ｓ５０２では、ワークフローサーバ００３は、アプリケーションサーバ１（００１）からのパラメータで与えられたSsIDは有効であるとして、アプリケーションサーバ１（００１）に登録済みである旨をレスポンスする（図３のＳ２１５）。
【００８７】
一方、Ｓ５０１において、パラメータで与えられたSsIDがワークフローＤＢ００４内のログイン情報に存在しない（未登録）と判定した場合には、ワークフローサーバ００３は、Ｓ５０３に処理を進める。
【００８８】
Ｓ５０３では、ワークフローサーバ００３は、アプリケーションサーバ１（００１）からのパラメータで与えられたSsIDは有効でないとして、アプリケーションサーバ１（００１）に未登録である旨をレスポンスする（図３のＳ２１５）。
【００８９】
アプリケーションサーバ１（００１）は、ワークフローサーバ００３からSsIDの有効性の問い合わせ結果を受信すると、図４のＳ３０７に処理を進める。
【００９０】
Ｓ３０７では、アプリケーションサーバ１（００１）は、図３のＳ２１５でワークフローサーバから受取ったSsIDの有効性結果を判定する。
【００９１】
そして、未登録である旨の結果を受信した場合には、アプリケーションサーバ１（００１）は、Ｓ３０７を偽（Ｎ）と判定し、Ｓ３０３〜Ｓ３０５において、再度ログイン処理を促すための処理を実行する。
【００９２】
一方、登録済みであれる旨の結果を受信した場合には、アプリケーションサーバ１（００１）は、Ｓ３０７を真（Ｙ）と判定し、Ｓ３０８に処理に処理を進める。
【００９３】
Ｓ３０８では、アプリケーションサーバ１（００１）は、セッション上のログイン済みフラグをセットする。なお、このフラグはＳ３０１の判定に使われるものである。
【００９４】
次に、Ｓ３０９において、アプリケーションサーバ１（００１）は、アプリケーション処理を実行する。この場合、ログイン後のアプリケーション初期画面（図１１）を生成する処理を行う。
【００９５】
次に、Ｓ３１０において、アプリケーションサーバ１（００１）は、アプリケーション画面（図１１）の項目にSsID（図１０）を出力する。
【００９６】
図１０は、図４のＳ３１０でアプリケーション画面の項目に出力されるSsIDの一例を示す図であり、アプリケーション画面を構成するＨＴＭＬのソースの一部を示すものであり、SsIDは画面には表示されないタグに記載されている。
【００９７】
図１０に示す例では、SsIDが、JAVA（登録商標）のオブジェクトをシリアライズした形式に変換されて埋め込まれている。なお、SsIDを変換せず、図８に示したような形式で埋め込んでもよい。
【００９８】
このように画面に埋め込まれたSsIDは、表示したアプリケーション画面からボタンなどが押下されたときに、再度、クライアントブラウザ００６からリクエストパラメータとしてSsIDを送信するためにおこなうものである。
【００９９】
図３のＳ２１６において、アプリケーションサーバ１（００１）は、図４のＳ３０９〜Ｓ３１０によってアプリケーションサーバ１（００１）で処理した画面を、クライアントブラウザ００６に送信し、表示させる。
【０１００】
図１１は、クライアントブラウザ００６に表示されるアプリケーションサーバ１（００１）のアプリケーション画面の一例を示す図である。なお、このアプリケーション画面には、図１０に示したようにSsIDが埋め込まれている。ただし、埋め込まれSsIDは画面には表示されない。
【０１０１】
次に、図１２のシーケンスチャートを参照して、アプリケーションサーバ１（００１）からアプリケーションサーバ２（００２）への画面遷移時におけるログイン情報の受け渡し処理の流れを説明する。
【０１０２】
図１２は、アプリケーションサーバ１（００１）からアプリケーションサーバ２（００２）への画面遷移時におけるログイン情報の受け渡し処理の流れの一例を示すシーケンスチャートである。
【０１０３】
図１２において、まず、Ｓ６０１〜Ｓ６０３は、遷移元のアプリケーションサーバ１（００１）の処理の流れである。
【０１０４】
ユーザが画面（図１１）の画面遷移ボタン（例えば、受注起案１３０１）等を押下すると、この操作を検知したクライアントブラウザ００６は、Ｓ６０１において、画面情報を含むリクエストをアプリケーションサーバ１（００１）に送信する。なお、画面情報には、図４のＳ３１０で画面に出力したSsIDが含まれている。
【０１０５】
次に、Ｓ６０２において、アプリケーションサーバ１（００１）は、図１３に示す処理を行い、リクエストから押下されたボタン等に対応する遷移先アプリケーションのＵＲＬを取得し、Ｓ６０３において、該クライアントにＵＲＬをクライアントブラウザ００６にリダイレクトする。
【０１０６】
詳細には、Ｓ６０３において、アプリケーションサーバ１（００１）は、クライアントブラウザ００６からアプリケーションサーバ２（００２）へ画面を遷移する要求を受け付けた場合、クライアントブラウザ００６からアプリケーションサーバ２（００２）へ該アプリケーションサーバ２（００２）のウェブアプリケーション画面情報を要求させるための、該アプリケーションサーバ２（００２）のＵＲＬに、前記要求内のアプリケーション画面情報に含まれる識別情報を、パラメータとして付加して、クライアントブラウザ００６に通知する処理を行う。
【０１０７】
ここで、図１３を用いて、Ｓ６０２，Ｓ６０３の動作について詳細に説明する。
【０１０８】
図１３は、アプリケーションサーバ１（００１）の動作の一例を示すフローチャートである。なお、このフローチャートの各ステップ（Ｓ７０１〜Ｓ７０４）は、アプリケーションサーバ１（００１）を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、アプリケーションサーバ１（００１）が実行すると記載する。
【０１０９】
まず、クライアントブラウザ００６からのリクエスト（図１２のＳ６０１）を受信すると、アプリケーションサーバ１（００１）は、Ｓ７０１に処理を進める。
【０１１０】
Ｓ７０１では、アプリケーションサーバ１（００１）は、アプリケーションサーバ１（００１）の外部記憶装置１０４上にある設定ファイル「workflow.conf」（図５）を読み取りＲＡＭ１０２に格納する。
【０１１１】
次に、Ｓ７０２において、アプリケーションサーバ１（００１）は、リクエストからクライアントブラウザ００６上で押下されたボタン名（アクション）に対応する遷移先アプリケーションＩＤを決定する。この対応は、プログラムあるいはファイルまたはＤＢ上にある対応情報から決定する。さらに、アプリケーションサーバ１（００１）は、Ｓ７０１で読み込んだ設定ファイル「workflow.conf」（図５）から、論理アプリＩＤに対応するＵＲＬ（例えば、図５の９０２）を取得し、そのパラメータにSsIDを付加し、これを「次ＵＲＬ」としてＲＡＭ１０２に保持する。図１２のＳ６０２では、アプリケーションサーバ２（００２）のＵＲＬを取得し、クライアントブラウザ００６から送信された画面情報に含まれるSsIDをパラメータに付加する。
【０１１２】
次に、Ｓ７０３において、アプリケーションサーバ１（００１）は、遷移元のセッション情報は不要であるため、アプリケーションサーバ１（００１）のセッションを破棄（無効化）することで開放する。
【０１１３】
次に、Ｓ７０４において、アプリケーションサーバ１（００１）は、Ｓ７０２で保持した「次ＵＲＬ」をクライアントブラウザ００６にリダイレクトする。
【０１１４】
以上で、図７のＳ６０１〜Ｓ６０３の動作を詳細に説明した。
【０１１５】
次に、Ｓ６０４〜Ｓ６０９は、アプリケーションサーバ２（００２）への遷移処理と、ワークフローサーバのログインチェック処理の流れである。
【０１１６】
Ｓ６０４において、クライアントブラウザ００６は、アプリケーションサーバ１（００１）から与えられたリダイレクト先「次ＵＲＬ」であるアプリケーションサーバ２（００２）にリクエストを送る。
【０１１７】
Ｓ６０５では、アプリケーションサーバ２（００２）は、図４の処理を行い、Ｓ６０６において、リクエストのパラメータのSsIDの有効性の確認をワークフローサーバ００３に要求し、ログイン確認を行う。なお、上記のSsIDが有効であればログイン済みとする。
【０１１８】
Ｓ６０７において、ワークフローサーバ００３は、ログイン確認処理を行い、Ｓ６０８において、ログイン確認結果をアプリケーションサーバ２（００２）に返信する。
【０１１９】
Ｓ６０９では、アプリケーションサーバ２（００２）は、ログイン結果がＯＫであったら、アプリケーション画面（後述する図１４）をクライアントブラウザ００６に送信し、クライアントブラウザ００６にアプリケーション画面（図１４）を表示させる。
【０１２０】
図１４は、クライアントブラウザ００６に表示されるアプリケーションサーバ２（００２）のアプリケーション画面の一例を示す図である。
【０１２１】
以上説明したように、本実施形態によれば、小規模な情報処理システムにおいて、ＬＤＡＰ等のシングル・サインオンの技術を用いることなく、容易に複数のアプリケーションにおいてシームレスな認証を可能とするシステムを容易に構築することができる。
【０１２２】
即ち、シングル・サインオンのように、それぞれのアプリケーションで、(1)ユーザの認証情報が統一されていなければならない、(2)認証インタフェースが統合されていなければならない、(3)アクセス制御が統合されていなければならない等の要件をクリアする必要がなく、容易な構築作業で短時間に当該システムを導入することが可能となる。
【０１２３】
したがって、複数の業務アプリケーションサーバとワークフローサーバとの間でのユーザ認証情報やセッション情報の受け渡しをするアプリケーション等を容易に開発することができる。
【０１２４】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０１２５】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１２６】
以下、図１５に示すメモリマップを参照して本発明に係る情報処理システムを構成する各情報処理装置で読み取り可能なデータ処理プログラムの構成について説明する。
【０１２７】
図１５は、本発明に係る情報処理システムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【０１２８】
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１２９】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１３０】
本実施形態における図３，図４，図６，図９，図１２，図１３に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１３１】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１３２】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１３３】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１３４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３５】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３６】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウエアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１３７】
さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１３８】
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【図面の簡単な説明】
【０１３９】
【図１】本発明の一実施形態を示す情報処理システムの一例を示すシステム構成図である。
【図２】図１に示したアプリケーションサーバ１、アプリケーションサーバ２、ワークフローサーバ００３、クライアントブラウザ００６に適用可能な情報処理装置のハードウェア構成の一例を示すブロック図である。
【図３】クライアントブラウザ００６からアプリケーションサーバ１（００１）にログインする手順の一例を示すシーケンスチャートである。
【図４】アプリケーションサーバ１の動作の一例を示すフローチャートである。
【図５】アプリケーションサーバ１の外部記憶装置１０４上に記憶される設定ファイル「workflow.conf」の一例を示す図である。
【図６】ワークフローサーバ００３の動作の一例を示すフローチャートである。
【図７】クライアントブラウザ００６に表示されるログイン画面の一例を示す図である。
【図８】図６のＳ４０７でパラメータとしてSsIDを付加した戻りＵＲＬの一例を示す図である。
【図９】ワークフローサーバ００３のログイン確認動作の一例を示すフローチャートである。
【図１０】図４のＳ３１０でアプリケーション画面の項目に出力されるSsIDの一例を示す図である。
【図１１】クライアントブラウザ００６に表示されるアプリケーションサーバ１（００１）のアプリケーション画面の一例を示す図である。
【図１２】アプリケーションサーバ１からアプリケーションサーバ２への画面遷移時におけるログイン情報の受け渡し処理の流れをの一例を示すシーケンスチャートである。
【図１３】アプリケーションサーバ１の動作の一例を示すフローチャートである。
【図１４】クライアントブラウザ００６に表示されるアプリケーションサーバ２（００２）のアプリケーション画面の一例を示す図である。
【図１５】本発明に係る情報処理システムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【符号の説明】
【０１４０】
００１ アプリケーションサーバ１
００２ アプリケーションサーバ２
００３ ワークフローサーバ
００４ ワークフローＤＢ
００５ アプリケーションＤＢ
００６ クライアントブラウザ
００７ ネットワーク
【技術分野】
【０００１】
本発明は、クライアントと、ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと、情報処理サーバとを含む情報処理システムに関し、とくに複数のウェブアプリケーションにまたがるユーザ認証制御に関する。
【背景技術】
【０００２】
基幹業務におけるワークフローアプリケーションを作成する場合、業務アプリケーションとワークフローエンジンを組み合わせて作成する。また、基幹業務におけるワークフローアプリケーションは、いくつかの異なる業務にまたがって処理するため、複数のシステムが関連する。
【０００３】
特許文献１には、複数のシステムが関連している環境において、処理速度の低下等を防止する技術が記載されている。
【０００４】
なお、特許文献１では、認証に関しては何ら開示されていないが、実際のシステムでは認証機能を持っているのが一般的である。
【特許文献１】特開２００７−５２６９７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上記複数のシステムが関連している環境において、各アプリケーションがそれぞれ認証機能を持っている場合、異なるアプリケーションへ遷移した際に、その都度、ログイン処理が必要となり、ユーザ便宜を悪くしていた。また、ユーザの管理するＩＤやパスワードの数も増え、非常に煩雑であった。
【０００６】
このような複数のシステムにまたがるアプリケーションでは、エンドユーザから見た場合、1つのシステムとしてシームレスにつながっていることが理想的である。
【０００７】
このようなシステムを構築するためには、異なるアプリケーションに遷移した場合でも、その都度、ログイン画面を表示することなく、異なるアプリケーション間で、ユーザ情報が引き継がれる必要がある。即ち、異なるアプリケーション間で、ログイン情報やセッション情報を各システム間で受け渡しする必要がある。
【０００８】
このようなシステムの構築方法として、ＬＤＡＰ(Lightweight Directory Access Protocol)等を利用したシングル・サインオン(Single Sign-On)のような認証統括システムを利用したものがある。
【０００９】
しかし、シングル・サインオンを実現するためには、それぞれのアプリケーションで、(1)ユーザの認証情報が統一されていなければならない、(2)認証インタフェースが統合されていなければならない、(3)アクセス制御が統合されていなければならない等の要件をクリアする必要がある。そのため、シングル・サインオン環境を導入するための構築作業が煩雑であり、非常に時間がかかってしまう等の問題点があった。
【００１０】
本発明は、上記の問題点を解決するためになされたもので、小規模な情報処理システムにおいて、ＬＤＡＰ等のシングル・サインオンの技術を用いることなく、容易に複数のアプリケーションにおいてシームレスな認証を可能とするシステムを容易に構築可能な仕組を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明は、ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと、情報処理サーバとを含む情報処理システムであって、前記ウェブアプリケーションサーバは、ウェブクライアントからアプリケーション画面情報の要求を受け付けた場合、該要求に、前記情報処理サーバへのログイン状況を示す識別子が含まれているかを判定する判定手段と、前記判定手段により前記識別子が含まれないと判定された場合、前記ウェブクライアントから前記情報処理サーバへ前記ログイン画面情報を要求させるための、該情報処理サーバのロケーション情報に、当該ウェブアプリケーションサーバのロケーション情報をパラメータとして付加して、前記ウェブクライアントに通知する第１の通知手段と、前記判定手段により前記識別子が含まれると判定された場合、該識別子の有効性を前記情報処理サーバに問い合わせる問い合わせ手段と、前記問い合わせ手段による問い合わせの結果、前記識別子が有効である場合、前記識別子を埋め込んだウェブアプリケーション画面情報を、前記ウェブクライアントへ送信する第１の画面情報送信手段と、前記ウェブクライアントから他のウェブアプリケーションサーバへ画面を遷移する要求を受け付けた場合、前記ウェブクライアントから前記他のウェブアプリケーションサーバへ前記他のウェブアプリケーション画面情報を要求させるための、該他のウェブアプリケーションサーバのロケーション情報に、前記要求内の前記ウェブアプリケーション画面情報に含まれる識別情報を、パラメータとして付加して、前記ウェブクライアントに通知する第２の通知手段とを有し、前記情報処理サーバは、前記ウェブクライアントから前記ログイン画面情報の要求を受け付けた場合、前記要求に含まれる前記ウェブアプリケーションサーバのロケーション情報を、前記ログイン画面情報に埋め込んで、前記ウェブクライアントへ送信する第２の画面情報送信手段と、前記ウェブクライアントから前記ログイン画面情報を含むログイン要求を受け付けた場合、ログイン処理を行うログイン処理手段と、前記ログイン処理手段によるログイン処理が成功した場合、前記識別子を生成して保持手段に保持させる識別子生成手段と、前記ウェブクライアントから前記ウェブアプリケーションサーバへ前記アプリケーション画面情報を要求させるための、前記ログイン要求内のログイン画面情報に含まれていた前記ウェブアプリケーションサーバのロケーション情報に、前記識別子生成手段により生成された識別子をパラメータとして付加して、前記ウェブクライアントに通知する第３の通知手段と、前記問い合わせ手段により問い合わされた識別子が有効であるか否かを、該識別子が前記保持手段に保持されているか否かで判定し、該判定結果を返信する識別子有効性判定手段とを有することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、小規模な情報処理システムにおいて、ＬＤＡＰ等のシングル・サインオンの技術を用いることなく、容易に複数のアプリケーションにおいてシームレスな認証を可能とすることができる。
【００１３】
したがって、複数の業務アプリケーションサーバとワークフローサーバとの間でのユーザ認証情報やセッション情報の受け渡しをするアプリケーションを開発し易いアプリケーション構築方法を提供することができる等の効果を奏する。
【発明を実施するための最良の形態】
【００１４】
図１は、本発明の一実施形態を示す情報処理システムの一例を示すシステム構成図である。本例では、基幹業務におけるワークフローアプリケーションの構成を示す。
【００１５】
図１において、００１，００２はアプリケーションサーバ（ウェブアプリケーションサーバ）である。アプリケーションサーバ１（００１），００２は、業務処理（例えば、受注システム，出荷システム等）の業務アプリケーション（ウェブアプリケーション）を実行し、アプリケーションＤＢ００５に、その情報を保管する。
【００１６】
ワークフローサーバ００３は、ワークフロー経路情報に従って、ワークフロー操作（承認、否認、差戻し等）処理を行い、ワークフローＤＢ００４に、その情報を保管する。
【００１７】
クライアントブラウザ００６は、クライアント端末でウェブクライアントとして動作するウェブブラウザを示す。クライアントブラウザ００６は、ユーザの指示に従って、ネットワーク００７を介してアプリケーションサーバ１（００１）、アプリケーションサーバ２（００２）、ワークフローサーバ００３に通信し、アプリケーション処理を行う。
【００１８】
なお、図中、００１〜００６は、それぞれ異なる情報処理装置に実装されてもよいし、いずれか又は全てが同一の情報処理装置に実装される構成であってもよい。
【００１９】
図２は、図１に示したアプリケーションサーバ１（００１）、アプリケーションサーバ２（００２）、ワークフローサーバ００３、クライアントブラウザ００６に適用可能な情報処理装置のハードウェア構成の一例を示すブロック図である。
【００２０】
図２において、１０１はＣＰＵであり、ＲＯＭ１０３或いは外部記憶装置（ハードディスク（ＨＤ）等）１０４に記憶されている制御プログラムに基づいて、システムバスに接続されている各種デバイスとのアクセスを総括的に制御する。
【００２１】
１０２はＲＡＭで、ＣＰＵ１０１の主メモリ、ワークエリア等として機能する。ＲＯＭ１０３或いはＨＤ１０４には、ＣＰＵ１０１の制御プログラムであるＢＩＯＳ（Basic Input / Output Ｓystem）やオペレーティングシステム（ＯＳ）プログラム、後述するフローチャートに示す処理をＣＰＵに実行させるために必要な各種プログラム等が記憶されている。そして、ＣＰＵ１０１は、必要なプログラム等をＲＡＭ１０２にロードして実行することにより、各種機能を実現するものである。
【００２２】
また、１０５は、キーボードやマウス等の入力装置である。１０６は、ＬＣＤやＣＲＴ等の表示装置である。１０７はネットワークインタフェースカード（ＮＩＣ）であり、ＬＡＮ，ＷＡＮ等のネットワーク００７を介して、他の装置と通信可能に構成されている。
【００２３】
以下、図３のシーケンスチャートを参照して、クライアントブラウザ００６からアプリケーションサーバ１（００１）にログインする手順について説明する。
【００２４】
図３は、クライアントブラウザ００６からアプリケーションサーバ１（００１）にログインする手順の一例を示すシーケンスチャートである。
【００２５】
図３において、まず、Ｓ２０１〜Ｓ２０３は、クライアントブラウザ００６から初めてアプリケーションサーバ１（００１）の処理画面を要求したときの動作である。
【００２６】
Ｓ２０１では、クライアントブラウザ００６からアプリケーションサーバ１（００１）に、後述する図１２に示すログイン画面を要求する。
【００２７】
２０２では、アプリケーションサーバ１（００１）は、図４に示す処理を行い、ワークフローサーバのログイン画面（後述する図７）のＵＲＬ（ロケーション情報）をクライアントブラウザ００６にリダイレクトする（Ｓ２０３）。なお、リダイレクトとは、あるＵＲＬから他のＵＲＬに転送させることをいう。図３のＳ２０３では、アプリケーションサーバ１（００１）は、クライアントブラウザ００６からワークフローサーバ００３へ前記ログイン画面情報の要求をさせるための、ワークフローサーバ００３のＵＲＬに、当該アプリケーションサーバ１（００１）のＵＲＬをパラメータとして付加して、クライアントブラウザ００６に通知する処理を行う。
【００２８】
ここで、図４を用いて、Ｓ２０２，Ｓ２０３の処理について詳細に説明する。
【００２９】
図４は、アプリケーションサーバ１（００１）の動作の一例を示すフローチャートである。なお、このフローチャートの各ステップ（Ｓ３０１〜Ｓ３１０）は、アプリケーションサーバ１（００１）を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、アプリケーションサーバ１（００１）が実行すると記載する。
【００３０】
まず、クライアントブラウザ００６からのログイン画面の表示要求（図３のＳ２０１）を受信すると、アプリケーションサーバ１（００１）は、Ｓ３０１に処理を進める。
【００３１】
Ｓ３０１において、アプリケーションサーバ１（００１）は、セッションの状態を判定する。図３のＳ２０２の場合、クライアントブラウザ００６からの画面表示要求（図３のＳ２０１）が最初の要求のため、セッションは存在しない。つまり、セッション上のログイン済みフラグは存在していないため、アプリケーションサーバ１（００１）は、Ｓ３０１を偽（Ｎ）と判定し、Ｓ３０２に処理を進める。
【００３２】
Ｓ３０２において、アプリケーションサーバ１（００１）は、パラメータにパラメータ名SsIDに対応する値が存在するか判定する。最初の要求では、クライアントブラウザ００６はパラメータを指定していない。そのため、アプリケーションサーバ１（００１）は、Ｓ３０２を偽（Ｎ）と判定し、Ｓ３０３に処理を進める。なお、SsIDとは、ワークフローサーバ００３へのログイン状況を確認するために使用される識別子である。
【００３３】
Ｓ３０３において、アプリケーションサーバ１（００１）は、アプリケーションサーバ１（００１）の外部記憶装置１０４上にある設定ファイル「workflow.conf」（図５）を読み取りＲＡＭ１０２に格納する。
【００３４】
図５は、アプリケーションサーバ１（００１）の外部記憶装置１０４上に記憶される設定ファイル「workflow.conf」の一例を示す図である。
【００３５】
図５に示すように、「workflow.conf」は、全てのアプリケーションサーバとワークフローサーバに予め準備されるものであり、共通の情報（ＵＲＬ情報）が記載されるものである。
【００３６】
次に、Ｓ３０４において、アプリケーションサーバ１（００１）は、Ｓ３０３で読み込んだ情報からワークフローサーバ００３のＵＲＬ（例えば、図５の９０１）を取得し、該取得したＵＲＬに、現在のリクエストのＵＲＬを、戻りＵＲＬパラメータとして付加する。ここでは、アプリケーションサーバ１（００１）のＵＲＬが戻りＵＲＬパラメータとして付加される。
【００３７】
次に、Ｓ３０５において、アプリケーションサーバ１（００１）は、Ｓ３０４で作成したＵＲＬ（現在のリクエストのＵＲＬを戻りＵＲＬパラメータとして付加したワークフローサーバのＵＲＬ）をクライアントブラウザ００６にリダイレクトする（図３の２０３）。
【００３８】
以上、図３のＳ２０２，Ｓ２０３の動作を詳細に説明した。
【００３９】
次に、Ｓ２０４〜Ｓ２０６は、ワークフローサーバ００３が、ログインページを表示するまでの動作を示す。
【００４０】
Ｓ２０４では、クライアントブラウザ００６は、アプリケーションサーバ１（００１）のレスポンスに従ってリダイレクト先、つまり、ワークフローサーバ００３のＵＲＬにアクセスする。
【００４１】
Ｓ２０５では、ワークフローサーバ００３は、図６に示す処理を行い、Ｓ２０６において、ログイン画面（図７）をクライアントブラウザ００６に送信し、クライアントブラウザ００６にログイン画面（図７）を表示させる。
【００４２】
ここで、図６を用いて、Ｓ２０５，Ｓ２０６の処理について詳細に説明する。
【００４３】
図６は、ワークフローサーバ００３の動作の一例を示すフローチャートである。なお、このフローチャートの各ステップ（Ｓ４０１〜Ｓ４０７）は、ワークフローサーバ００３を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、ワークフローサーバ００３が実行すると記載する。
【００４４】
まず、クライアントブラウザ００６からのリクエストを受信すると（図３のＳ２０４）、ワークフローサーバ００３は、Ｓ４０１に処理を進める。
【００４５】
Ｓ４０１において、ワークフローアプリケーション００４は、ワークフローＤＢ００４のユーザログイン情報上にセッションＩＤが存在するか判定する。図３のＳ２０４の場合、クライアントブラウザ００６からのリクエスト（図３のＳ２０４）が最初のアクセスなので、ワークフローＤＢ００４のユーザログイン情報上にセッションＩＤは存在しない。つまり、ワークフローサーバ００３は、Ｓ４０１を偽（Ｎ）と判定し、Ｓ４０２に処理を進める。
【００４６】
Ｓ４０２では、ワークフローサーバ００３は、現在のリクエストがログインページのログインボタンが押されたものか判定する。図３のＳ２０４の場合、該当しないため、ワークフローサーバ００３は、Ｓ４０２を偽（Ｎ）と判定し、Ｓ４０３に処理を進める。
【００４７】
Ｓ４０３では、ワークフローサーバ００３は、図４のＳ３０４においてパラメータとしてリクエストに付加された戻りＵＲＬ情報を取得し、これを保持するために、ログイン画面（図７）の項目にセットする。ログイン画面の項目にセットするとは、例えば、このログイン画面を構成するＨＴＭＬなどの構造化言語内の非表示項目に記述することで実現する。
【００４８】
次に、Ｓ４０４において、ワークフローサーバ００３は、ログイン画面（図７）をクライアントブラウザ００６にレスポンスする（図３のＳ２０６）。
【００４９】
以上、図３のＳ２０５，Ｓ２０６の動作を詳細に説明した。
【００５０】
図７は、クライアントブラウザ００６に表示されるログイン画面の一例を示す図である。
【００５１】
ユーザは、クライアントブラウザ００６から、７０１にユーザ名（ユーザＩＤ），７０２にパスワードを入力し、ログインボタン７０３を押下指示して、ログイン操作を行う。
【００５２】
次に、図３のＳ２０７〜Ｓ２１０では、ログイン画面（図７）のログインボタン７０３がユーザによって押下されワークフローサーバでログイン処理する動作を示す。
【００５３】
Ｓ２０７において、ユーザは、クライアントブラウザ００６にユーザ名、パスワードを入力してログインボタン７０３を押下する。
【００５４】
この操作を検知したクライアントブラウザ００６は、Ｓ２０８において、入力されたユーザ名、パスワード、図６のＳ４０３でログイン画面（図７）にセットされた戻りＵＲＬを、ワークフローサーバ００３に送信する。ここでは、アプリケーションサーバ１（００１）のＵＲＬが、戻りＵＲＬとして送信される。
【００５５】
次に、Ｓ２０９において、ワークフローサーバ００３は、図６の処理を行い、クライアントブラウザ００６から受信したユーザ名、パスワードを元にログイン確認処理を行い、ログイン処理をする。
【００５６】
そして、Ｓ２１０において、ワークフローサーバ００３は、アプリケーション画面のＵＲＬをリダイレクトする。詳細には、Ｓ２１０では、ワークフローサーバ００３は、クライアントブラウザ００６からアプリケーションサーバ１（００１）へ前記アプリケーション画面情報の要求させるための、前記ログイン要求内のログイン画面情報に含まれていた前記アプリケーションサーバ１（００１）のＵＲＬに、前記識別子をパラメータとして付加して、クライアントブラウザ００６に通知する処理を行う。
【００５７】
ここで、図６を用いて、Ｓ２０９，Ｓ２１０の処理について詳細に説明する。
【００５８】
まず、クライアントブラウザ００６からユーザ名，パスワード，戻りＵＲＬを受信すると（図３のＳ２０８）、ワークフローサーバ００３は、図６のＳ４０１に処理を進める。
【００５９】
Ｓ４０１において、ワークフローアプリケーション００４は、ワークフローＤＢ００４のユーザログイン情報上にセッションＩＤが存在するか判定する。図３のＳ２０８の場合、Ｓ２０４に次ぐ２度目のアクセスであるが、まだセッションＩＤはセットされておらず、Ｓ２０４の場合と同様に、ワークフローＤＢ００４のユーザログイン情報上にセッションＩＤは存在しない。つまり、ワークフローサーバ００３は、Ｓ４０１を偽（Ｎ）と判定し、Ｓ４０２に処理を進める。
【００６０】
Ｓ４０２では、ワークフローサーバ００３は、現在のリクエストがログインページのログインボタンが押されたものか判定する。図３のＳ２０８の場合、ログインボタンが押下されたものであるため、ワークフローサーバ００３は、Ｓ４０２を真（Ｙ）と判定し、Ｓ４０５に処理を進める。
【００６１】
Ｓ４０５では、ワークフローサーバ００３は、受信したユーザ名，パスワードが有効であるかチェックする。ワークフローサーバ００３は、上記受信したユーザ名，パスワードと、ワークフローＤＢ００４のユーザログイン情報との比較を行うことで有効性のチェックが可能であるが、ここではその方式は特に問わないため省略する。
【００６２】
そして、ユーザ名，パスワードが有効でない場合（ログインエラーの場合）には、ワークフローサーバ００３は、Ｓ４０５を真（Ｙ）と判定し、Ｓ４０３，Ｓ４０４において、エラーメッセージ情報とともに、再びログインページをクライアントブラウザ００６に表示させる。そして、本フローチャートの処理を終了する。
【００６３】
一方、Ｓ４０５において、ユーザ名，パスワードが有効である場合（ログインが成功した場合）には、ワークフローサーバ００３は、Ｓ４０５を偽（Ｎ）と判定し、Ｓ４０６に処理を進める。
【００６４】
Ｓ４０６では、ワークフローサーバ００３は、SsIDを生成し、ワークフローＤＢ００４のユーザログイン情報に登録する。なお、SsIDは、アプリケーションサーバ、ワークフローサーバでユニークに識別できるものであればよい。ここでは、SsIDはセッションＩＤと同等のものを使用する。なお、SsIDを、タイムアウトにより削除する運用も可能である。
【００６５】
次に、Ｓ４０７において、ワークフローサーバ００３は、戻りＵＲＬ（図６のＳ４０３でログイン画面（図７）にセットされた戻りＵＲＬ）のパラメータにＳ４０６で生成したSsIDを付加し（図８）、該戻りＵＲＬをリダイレクト先としてクライアントブラウザ００６にレスポンスする（図３のＳ２１０）。
【００６６】
以上、図３のＳ２０９，Ｓ２１０の動作を詳細に説明した。
【００６７】
図８は、図６のＳ４０７でパラメータとしてSsIDを付加した戻りＵＲＬの一例を示す図である。
【００６８】
次に、図３のＳ２１１〜Ｓ２１６では、ログイン処理後、アプリケーション画面を表示するまでの処理を示す。
【００６９】
Ｓ２１１では、クライアントブラウザ００６は、ワークフローサーバ００３のレスポンスに従ってリダイレクト先、つまり、アプリケーションサーバ１（００１）のＵＲＬにアクセスする。
【００７０】
Ｓ２１２では、アプリケーションサーバ１（００１）は、図４の処理を行い、Ｓ２１３において、ワークフローサーバ００３に対してログイン確認を行う。
【００７１】
Ｓ２１４において、ワークフローサーバ００３は、図９に示すログイン確認処理を行い、Ｓ２１５において、ログイン確認結果をアプリケーションサーバ１（００１）に返信する。
【００７２】
Ｓ２１６では、アプリケーションサーバ１（００１）は、ログイン結果がＯＫであったら、アプリケーション画面（後述する図１１）をクライアントブラウザ００６に送信し、クライアントブラウザ００６にアプリケーション画面（図１１）を表示させる。
【００７３】
ここで、図４，図９を用いて、Ｓ２１２〜Ｓ２１６の処理について詳細に説明する。
【００７４】
まず、クライアントブラウザ００６からのリクエスト（図３のＳ２１１）を受信すると、アプリケーションサーバ１（００１）は、図４のＳ３０１に処理を進める。
【００７５】
Ｓ３０１において、アプリケーションサーバ１（００１）は、セッションの状態を判定する。図３のＳ２０２の場合、Ｓ２０１に次ぐ２回目のアクセスのためセッション自身は存在するが、まだログイン済みフラグはセットされておらず、Ｓ２０１の場合と同様に、アプリケーションサーバ１（００１）は、Ｓ３０１を偽（Ｎ）と判定し、Ｓ３０２に処理を進める。
【００７６】
Ｓ３０２において、アプリケーションサーバ１（００１）は、パラメータにパラメータ名SsIDに対応する値が存在するか判定する。図６のＳ４０７においてSsIDがパラメータに指定されているので、アプリケーションサーバ１（００１）は、Ｓ３０２を真（Ｙ）と判定し、Ｓ３０６に処理を進める。
【００７７】
Ｓ３０６において、アプリケーションサーバ１（００１）は、Ｓ３０２で取得したSsIDを、ワークフローサーバ００３に対して有効であるか問い合わせをする（図３のＳ２１３〜２１５、図９のＳ５０１〜Ｓ５０３）。
【００７８】
図３のＳ２１３〜Ｓ２１５は、ワークフローサーバ００３において、SsIDがワークフローＤＢ００４のログイン情報に登録されているかどうかを判定する処理である。
【００７９】
図３のＳ２１３において、アプリケーションサーバ１（００１）は、パラメータにSsIDを指定して、図９に示すようなＷｅｂ Ｓｅｒｖｉｃｅを呼び出す。
【００８０】
図３のＳ２１４は、Ｓ２１３の呼び出しに対応するワークフローサーバ側の処理であり、その詳細な処理を図９に示す。
【００８１】
図９は、ワークフローサーバ００３のログイン確認動作の一例を示すフローチャートである。なお、このフローチャートの各ステップ（Ｓ５０１〜Ｓ５０３）は、ワークフローサーバ００３を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、ワークフローサーバ００３が実行すると記載する。
【００８２】
図９のＳ５０１〜Ｓ５０３は、アプリケーションサーバ１（００１）が、パラメータSsIDを含むリクエスト（ログイン確認要求）を受信し、SsIDが有効であるかどうかを判定し、結果を返す動作の詳細である。
【００８３】
まず、アプリケーションサーバ１（００１）からのパラメータSsIDを含むリクエスト（ログイン確認要求）を受信すると（図３のＳ２１３）、ワークフローサーバ００３は、Ｓ５０１に処理を進める。
【００８４】
Ｓ５０１では、ワークフローサーバ００３は、パラメータで与えられたSsIDがワークフローＤＢ００４内のログイン情報に存在する（登録済み）か判定する。
【００８５】
そして、パラメータで与えられたSsIDがワークフローＤＢ００４内のログイン情報に存在する（登録済み）と判定した場合には、ワークフローサーバ００３は、Ｓ５０２に処理を進める。
【００８６】
Ｓ５０２では、ワークフローサーバ００３は、アプリケーションサーバ１（００１）からのパラメータで与えられたSsIDは有効であるとして、アプリケーションサーバ１（００１）に登録済みである旨をレスポンスする（図３のＳ２１５）。
【００８７】
一方、Ｓ５０１において、パラメータで与えられたSsIDがワークフローＤＢ００４内のログイン情報に存在しない（未登録）と判定した場合には、ワークフローサーバ００３は、Ｓ５０３に処理を進める。
【００８８】
Ｓ５０３では、ワークフローサーバ００３は、アプリケーションサーバ１（００１）からのパラメータで与えられたSsIDは有効でないとして、アプリケーションサーバ１（００１）に未登録である旨をレスポンスする（図３のＳ２１５）。
【００８９】
アプリケーションサーバ１（００１）は、ワークフローサーバ００３からSsIDの有効性の問い合わせ結果を受信すると、図４のＳ３０７に処理を進める。
【００９０】
Ｓ３０７では、アプリケーションサーバ１（００１）は、図３のＳ２１５でワークフローサーバから受取ったSsIDの有効性結果を判定する。
【００９１】
そして、未登録である旨の結果を受信した場合には、アプリケーションサーバ１（００１）は、Ｓ３０７を偽（Ｎ）と判定し、Ｓ３０３〜Ｓ３０５において、再度ログイン処理を促すための処理を実行する。
【００９２】
一方、登録済みであれる旨の結果を受信した場合には、アプリケーションサーバ１（００１）は、Ｓ３０７を真（Ｙ）と判定し、Ｓ３０８に処理に処理を進める。
【００９３】
Ｓ３０８では、アプリケーションサーバ１（００１）は、セッション上のログイン済みフラグをセットする。なお、このフラグはＳ３０１の判定に使われるものである。
【００９４】
次に、Ｓ３０９において、アプリケーションサーバ１（００１）は、アプリケーション処理を実行する。この場合、ログイン後のアプリケーション初期画面（図１１）を生成する処理を行う。
【００９５】
次に、Ｓ３１０において、アプリケーションサーバ１（００１）は、アプリケーション画面（図１１）の項目にSsID（図１０）を出力する。
【００９６】
図１０は、図４のＳ３１０でアプリケーション画面の項目に出力されるSsIDの一例を示す図であり、アプリケーション画面を構成するＨＴＭＬのソースの一部を示すものであり、SsIDは画面には表示されないタグに記載されている。
【００９７】
図１０に示す例では、SsIDが、JAVA（登録商標）のオブジェクトをシリアライズした形式に変換されて埋め込まれている。なお、SsIDを変換せず、図８に示したような形式で埋め込んでもよい。
【００９８】
このように画面に埋め込まれたSsIDは、表示したアプリケーション画面からボタンなどが押下されたときに、再度、クライアントブラウザ００６からリクエストパラメータとしてSsIDを送信するためにおこなうものである。
【００９９】
図３のＳ２１６において、アプリケーションサーバ１（００１）は、図４のＳ３０９〜Ｓ３１０によってアプリケーションサーバ１（００１）で処理した画面を、クライアントブラウザ００６に送信し、表示させる。
【０１００】
図１１は、クライアントブラウザ００６に表示されるアプリケーションサーバ１（００１）のアプリケーション画面の一例を示す図である。なお、このアプリケーション画面には、図１０に示したようにSsIDが埋め込まれている。ただし、埋め込まれSsIDは画面には表示されない。
【０１０１】
次に、図１２のシーケンスチャートを参照して、アプリケーションサーバ１（００１）からアプリケーションサーバ２（００２）への画面遷移時におけるログイン情報の受け渡し処理の流れを説明する。
【０１０２】
図１２は、アプリケーションサーバ１（００１）からアプリケーションサーバ２（００２）への画面遷移時におけるログイン情報の受け渡し処理の流れの一例を示すシーケンスチャートである。
【０１０３】
図１２において、まず、Ｓ６０１〜Ｓ６０３は、遷移元のアプリケーションサーバ１（００１）の処理の流れである。
【０１０４】
ユーザが画面（図１１）の画面遷移ボタン（例えば、受注起案１３０１）等を押下すると、この操作を検知したクライアントブラウザ００６は、Ｓ６０１において、画面情報を含むリクエストをアプリケーションサーバ１（００１）に送信する。なお、画面情報には、図４のＳ３１０で画面に出力したSsIDが含まれている。
【０１０５】
次に、Ｓ６０２において、アプリケーションサーバ１（００１）は、図１３に示す処理を行い、リクエストから押下されたボタン等に対応する遷移先アプリケーションのＵＲＬを取得し、Ｓ６０３において、該クライアントにＵＲＬをクライアントブラウザ００６にリダイレクトする。
【０１０６】
詳細には、Ｓ６０３において、アプリケーションサーバ１（００１）は、クライアントブラウザ００６からアプリケーションサーバ２（００２）へ画面を遷移する要求を受け付けた場合、クライアントブラウザ００６からアプリケーションサーバ２（００２）へ該アプリケーションサーバ２（００２）のウェブアプリケーション画面情報を要求させるための、該アプリケーションサーバ２（００２）のＵＲＬに、前記要求内のアプリケーション画面情報に含まれる識別情報を、パラメータとして付加して、クライアントブラウザ００６に通知する処理を行う。
【０１０７】
ここで、図１３を用いて、Ｓ６０２，Ｓ６０３の動作について詳細に説明する。
【０１０８】
図１３は、アプリケーションサーバ１（００１）の動作の一例を示すフローチャートである。なお、このフローチャートの各ステップ（Ｓ７０１〜Ｓ７０４）は、アプリケーションサーバ１（００１）を実装する情報処理装置のＣＰＵ１０１が、外部記憶装置１０４に記憶されるプログラムをＲＡＭ１０２にロードして実行することにより実現されるものであり、以下、アプリケーションサーバ１（００１）が実行すると記載する。
【０１０９】
まず、クライアントブラウザ００６からのリクエスト（図１２のＳ６０１）を受信すると、アプリケーションサーバ１（００１）は、Ｓ７０１に処理を進める。
【０１１０】
Ｓ７０１では、アプリケーションサーバ１（００１）は、アプリケーションサーバ１（００１）の外部記憶装置１０４上にある設定ファイル「workflow.conf」（図５）を読み取りＲＡＭ１０２に格納する。
【０１１１】
次に、Ｓ７０２において、アプリケーションサーバ１（００１）は、リクエストからクライアントブラウザ００６上で押下されたボタン名（アクション）に対応する遷移先アプリケーションＩＤを決定する。この対応は、プログラムあるいはファイルまたはＤＢ上にある対応情報から決定する。さらに、アプリケーションサーバ１（００１）は、Ｓ７０１で読み込んだ設定ファイル「workflow.conf」（図５）から、論理アプリＩＤに対応するＵＲＬ（例えば、図５の９０２）を取得し、そのパラメータにSsIDを付加し、これを「次ＵＲＬ」としてＲＡＭ１０２に保持する。図１２のＳ６０２では、アプリケーションサーバ２（００２）のＵＲＬを取得し、クライアントブラウザ００６から送信された画面情報に含まれるSsIDをパラメータに付加する。
【０１１２】
次に、Ｓ７０３において、アプリケーションサーバ１（００１）は、遷移元のセッション情報は不要であるため、アプリケーションサーバ１（００１）のセッションを破棄（無効化）することで開放する。
【０１１３】
次に、Ｓ７０４において、アプリケーションサーバ１（００１）は、Ｓ７０２で保持した「次ＵＲＬ」をクライアントブラウザ００６にリダイレクトする。
【０１１４】
以上で、図７のＳ６０１〜Ｓ６０３の動作を詳細に説明した。
【０１１５】
次に、Ｓ６０４〜Ｓ６０９は、アプリケーションサーバ２（００２）への遷移処理と、ワークフローサーバのログインチェック処理の流れである。
【０１１６】
Ｓ６０４において、クライアントブラウザ００６は、アプリケーションサーバ１（００１）から与えられたリダイレクト先「次ＵＲＬ」であるアプリケーションサーバ２（００２）にリクエストを送る。
【０１１７】
Ｓ６０５では、アプリケーションサーバ２（００２）は、図４の処理を行い、Ｓ６０６において、リクエストのパラメータのSsIDの有効性の確認をワークフローサーバ００３に要求し、ログイン確認を行う。なお、上記のSsIDが有効であればログイン済みとする。
【０１１８】
Ｓ６０７において、ワークフローサーバ００３は、ログイン確認処理を行い、Ｓ６０８において、ログイン確認結果をアプリケーションサーバ２（００２）に返信する。
【０１１９】
Ｓ６０９では、アプリケーションサーバ２（００２）は、ログイン結果がＯＫであったら、アプリケーション画面（後述する図１４）をクライアントブラウザ００６に送信し、クライアントブラウザ００６にアプリケーション画面（図１４）を表示させる。
【０１２０】
図１４は、クライアントブラウザ００６に表示されるアプリケーションサーバ２（００２）のアプリケーション画面の一例を示す図である。
【０１２１】
以上説明したように、本実施形態によれば、小規模な情報処理システムにおいて、ＬＤＡＰ等のシングル・サインオンの技術を用いることなく、容易に複数のアプリケーションにおいてシームレスな認証を可能とするシステムを容易に構築することができる。
【０１２２】
即ち、シングル・サインオンのように、それぞれのアプリケーションで、(1)ユーザの認証情報が統一されていなければならない、(2)認証インタフェースが統合されていなければならない、(3)アクセス制御が統合されていなければならない等の要件をクリアする必要がなく、容易な構築作業で短時間に当該システムを導入することが可能となる。
【０１２３】
したがって、複数の業務アプリケーションサーバとワークフローサーバとの間でのユーザ認証情報やセッション情報の受け渡しをするアプリケーション等を容易に開発することができる。
【０１２４】
なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【０１２５】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１２６】
以下、図１５に示すメモリマップを参照して本発明に係る情報処理システムを構成する各情報処理装置で読み取り可能なデータ処理プログラムの構成について説明する。
【０１２７】
図１５は、本発明に係る情報処理システムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【０１２８】
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１２９】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１３０】
本実施形態における図３，図４，図６，図９，図１２，図１３に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１３１】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１３２】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１３３】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１３４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３５】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３６】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウエアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１３７】
さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１３８】
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【図面の簡単な説明】
【０１３９】
【図１】本発明の一実施形態を示す情報処理システムの一例を示すシステム構成図である。
【図２】図１に示したアプリケーションサーバ１、アプリケーションサーバ２、ワークフローサーバ００３、クライアントブラウザ００６に適用可能な情報処理装置のハードウェア構成の一例を示すブロック図である。
【図３】クライアントブラウザ００６からアプリケーションサーバ１（００１）にログインする手順の一例を示すシーケンスチャートである。
【図４】アプリケーションサーバ１の動作の一例を示すフローチャートである。
【図５】アプリケーションサーバ１の外部記憶装置１０４上に記憶される設定ファイル「workflow.conf」の一例を示す図である。
【図６】ワークフローサーバ００３の動作の一例を示すフローチャートである。
【図７】クライアントブラウザ００６に表示されるログイン画面の一例を示す図である。
【図８】図６のＳ４０７でパラメータとしてSsIDを付加した戻りＵＲＬの一例を示す図である。
【図９】ワークフローサーバ００３のログイン確認動作の一例を示すフローチャートである。
【図１０】図４のＳ３１０でアプリケーション画面の項目に出力されるSsIDの一例を示す図である。
【図１１】クライアントブラウザ００６に表示されるアプリケーションサーバ１（００１）のアプリケーション画面の一例を示す図である。
【図１２】アプリケーションサーバ１からアプリケーションサーバ２への画面遷移時におけるログイン情報の受け渡し処理の流れをの一例を示すシーケンスチャートである。
【図１３】アプリケーションサーバ１の動作の一例を示すフローチャートである。
【図１４】クライアントブラウザ００６に表示されるアプリケーションサーバ２（００２）のアプリケーション画面の一例を示す図である。
【図１５】本発明に係る情報処理システムを構成する各情報処理装置で読み取り可能な各種データ処理プログラムを格納する記録媒体（記憶媒体）のメモリマップを説明する図である。
【符号の説明】
【０１４０】
００１ アプリケーションサーバ１
００２ アプリケーションサーバ２
００３ ワークフローサーバ
００４ ワークフローＤＢ
００５ アプリケーションＤＢ
００６ クライアントブラウザ
００７ ネットワーク
【特許請求の範囲】
【請求項１】
ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと、情報処理サーバとを含む情報処理システムであって、
前記ウェブアプリケーションサーバは、
ウェブクライアントからアプリケーション画面情報の要求を受け付けた場合、該要求に、前記情報処理サーバへのログイン状況を示す識別子が含まれているかを判定する判定手段と、
前記判定手段により前記識別子が含まれないと判定された場合、前記ウェブクライアントから前記情報処理サーバへ前記ログイン画面情報を要求させるための、該情報処理サーバのロケーション情報に、当該ウェブアプリケーションサーバのロケーション情報をパラメータとして付加して、前記ウェブクライアントに通知する第１の通知手段と、
前記判定手段により前記識別子が含まれると判定された場合、該識別子の有効性を前記情報処理サーバに問い合わせる問い合わせ手段と、
前記問い合わせ手段による問い合わせの結果、前記識別子が有効である場合、前記識別子を埋め込んだウェブアプリケーション画面情報を、前記ウェブクライアントへ送信する第１の画面情報送信手段と、
前記ウェブクライアントから他のウェブアプリケーションサーバへ画面を遷移する要求を受け付けた場合、前記ウェブクライアントから前記他のウェブアプリケーションサーバへ前記他のウェブアプリケーション画面情報を要求させるための、該他のウェブアプリケーションサーバのロケーション情報に、前記要求内の前記ウェブアプリケーション画面情報に含まれる識別情報を、パラメータとして付加して、前記ウェブクライアントに通知する第２の通知手段とを有し、
前記情報処理サーバは、
前記ウェブクライアントから前記ログイン画面情報の要求を受け付けた場合、前記要求に含まれる前記ウェブアプリケーションサーバのロケーション情報を、前記ログイン画面情報に埋め込んで、前記ウェブクライアントへ送信する第２の画面情報送信手段と、
前記ウェブクライアントから前記ログイン画面情報を含むログイン要求を受け付けた場合、ログイン処理を行うログイン処理手段と、
前記ログイン処理手段によるログイン処理が成功した場合、前記識別子を生成して保持手段に保持させる識別子生成手段と、
前記ウェブクライアントから前記ウェブアプリケーションサーバへ前記アプリケーション画面情報を要求させるための、前記ログイン要求内のログイン画面情報に含まれていた前記ウェブアプリケーションサーバのロケーション情報に、前記識別子生成手段により生成された識別子をパラメータとして付加して、前記ウェブクライアントに通知する第３の通知手段と、
前記問い合わせ手段により問い合わされた識別子が有効であるか否かを、該識別子が前記保持手段に保持されているか否かで判定し、該判定結果を返信する識別子有効性判定手段とを有することを特徴とする情報処理システム。
【請求項２】
前記ウェブアプリケーションサーバは、前記問い合わせ手段による問い合わせの結果、前記識別子が有効である場合、セッションの状態をログイン済みとし、また、前記第２の通知手段による通知処理後に前記セッションを開放するセッション管理手段を有し、
前記セッション管理手段は、前記ウェブクライアントからアプリケーション画面情報の要求を受け付けた場合、該要求に対応するセッションの状態がログイン済みでない場合、前記判定手段に判定処理を実行させ、一方、ログイン済みである場合、第１の画面情報送信手段に画面送信処理を実行させる、ことを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記ウェブアプリケーションサーバと前記情報処理サーバは、前記各ロケーション情報を含む同一のファイルをそれぞれ保持することを特徴とする請求項１又は２に記載の情報処理システム。
【請求項４】
前記各画面情報は、構造化言語で記述されることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
【請求項５】
ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと、情報処理サーバとを含む情報処理システムにおける情報処理方法であって、
前記ウェブアプリケーションサーバに、
判定手段が、ウェブクライアントからアプリケーション画面情報の要求を受け付けた場合、該要求に、前記情報処理サーバへのログイン状況を示す識別子が含まれているかを判定する判定ステップと、
第１の通知手段が、前記判定ステップにより前記識別子が含まれないと判定された場合、前記ウェブクライアントから前記情報処理サーバへ前記ログイン画面情報を要求させるための、該情報処理サーバのロケーション情報に、当該ウェブアプリケーションサーバのロケーション情報をパラメータとして付加して、前記ウェブクライアントに通知する第１の通知ステップと、
問い合わせ手段が、前記判定ステップにより前記識別子が含まれると判定された場合、該識別子の有効性を前記情報処理サーバに問い合わせる問い合わせステップと、
第１の画面情報送信手段が、前記問い合わせステップによる問い合わせの結果、前記識別子が有効である場合、前記識別子を埋め込んだウェブアプリケーション画面情報を、前記ウェブクライアントへ送信する第１の画面情報送信ステップと、
第２の通知手段が、前記ウェブクライアントから他のウェブアプリケーションサーバへ画面を遷移する要求を受け付けた場合、前記ウェブクライアントから前記他のウェブアプリケーションサーバへ前記他のウェブアプリケーション画面情報を要求させるための、該他のウェブアプリケーションサーバのロケーション情報に、前記要求内の前記ウェブアプリケーション画面情報に含まれる識別情報を、パラメータとして付加して、前記ウェブクライアントに通知する第２の通知ステップとを実行させ、
前記情報処理サーバに、
第２の画面情報送信手段が、前記ウェブクライアントから前記ログイン画面情報の要求を受け付けた場合、前記要求に含まれる前記ウェブアプリケーションサーバのロケーション情報を、前記ログイン画面情報に埋め込んで、前記ウェブクライアントへ送信する第２の画面情報送信ステップと、
ログイン処理手段が、前記ウェブクライアントから前記ログイン画面情報を含むログイン要求を受け付けた場合、ログイン処理を行うログイン処理ステップと、
識別子生成手段が、前記ログイン処理手段によるログイン処理が成功した場合、前記識別子を生成して保持手段に保持させる識別子生成ステップと、
第３の通知手段が、前記ウェブクライアントから前記ウェブアプリケーションサーバへ前記アプリケーション画面情報を要求させるための、前記ログイン要求内のログイン画面情報に含まれていた前記ウェブアプリケーションサーバのロケーション情報に、前記識別子生成手段により生成された識別子をパラメータとして付加して、前記ウェブクライアントに通知する第３の通知ステップと、
識別子有効性判定手段が、前記問い合わせステップにより問い合わされた識別子が有効であるか否かを、該識別子が前記保持手段に保持されているか否かで判定し、該判定結果を返信する識別子有効性判定手段とを実行させることを特徴とする情報処理方法。
【請求項６】
請求項５に記載された情報処理方法を、ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと情報処理サーバとを含む情報処理システムにおいて実行させるためのプログラム。
【請求項７】
請求項５に記載された情報処理方法を、ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと情報処理サーバとを含む情報処理システムにおいて実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１】
ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと、情報処理サーバとを含む情報処理システムであって、
前記ウェブアプリケーションサーバは、
ウェブクライアントからアプリケーション画面情報の要求を受け付けた場合、該要求に、前記情報処理サーバへのログイン状況を示す識別子が含まれているかを判定する判定手段と、
前記判定手段により前記識別子が含まれないと判定された場合、前記ウェブクライアントから前記情報処理サーバへ前記ログイン画面情報を要求させるための、該情報処理サーバのロケーション情報に、当該ウェブアプリケーションサーバのロケーション情報をパラメータとして付加して、前記ウェブクライアントに通知する第１の通知手段と、
前記判定手段により前記識別子が含まれると判定された場合、該識別子の有効性を前記情報処理サーバに問い合わせる問い合わせ手段と、
前記問い合わせ手段による問い合わせの結果、前記識別子が有効である場合、前記識別子を埋め込んだウェブアプリケーション画面情報を、前記ウェブクライアントへ送信する第１の画面情報送信手段と、
前記ウェブクライアントから他のウェブアプリケーションサーバへ画面を遷移する要求を受け付けた場合、前記ウェブクライアントから前記他のウェブアプリケーションサーバへ前記他のウェブアプリケーション画面情報を要求させるための、該他のウェブアプリケーションサーバのロケーション情報に、前記要求内の前記ウェブアプリケーション画面情報に含まれる識別情報を、パラメータとして付加して、前記ウェブクライアントに通知する第２の通知手段とを有し、
前記情報処理サーバは、
前記ウェブクライアントから前記ログイン画面情報の要求を受け付けた場合、前記要求に含まれる前記ウェブアプリケーションサーバのロケーション情報を、前記ログイン画面情報に埋め込んで、前記ウェブクライアントへ送信する第２の画面情報送信手段と、
前記ウェブクライアントから前記ログイン画面情報を含むログイン要求を受け付けた場合、ログイン処理を行うログイン処理手段と、
前記ログイン処理手段によるログイン処理が成功した場合、前記識別子を生成して保持手段に保持させる識別子生成手段と、
前記ウェブクライアントから前記ウェブアプリケーションサーバへ前記アプリケーション画面情報を要求させるための、前記ログイン要求内のログイン画面情報に含まれていた前記ウェブアプリケーションサーバのロケーション情報に、前記識別子生成手段により生成された識別子をパラメータとして付加して、前記ウェブクライアントに通知する第３の通知手段と、
前記問い合わせ手段により問い合わされた識別子が有効であるか否かを、該識別子が前記保持手段に保持されているか否かで判定し、該判定結果を返信する識別子有効性判定手段とを有することを特徴とする情報処理システム。
【請求項２】
前記ウェブアプリケーションサーバは、前記問い合わせ手段による問い合わせの結果、前記識別子が有効である場合、セッションの状態をログイン済みとし、また、前記第２の通知手段による通知処理後に前記セッションを開放するセッション管理手段を有し、
前記セッション管理手段は、前記ウェブクライアントからアプリケーション画面情報の要求を受け付けた場合、該要求に対応するセッションの状態がログイン済みでない場合、前記判定手段に判定処理を実行させ、一方、ログイン済みである場合、第１の画面情報送信手段に画面送信処理を実行させる、ことを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記ウェブアプリケーションサーバと前記情報処理サーバは、前記各ロケーション情報を含む同一のファイルをそれぞれ保持することを特徴とする請求項１又は２に記載の情報処理システム。
【請求項４】
前記各画面情報は、構造化言語で記述されることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
【請求項５】
ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと、情報処理サーバとを含む情報処理システムにおける情報処理方法であって、
前記ウェブアプリケーションサーバに、
判定手段が、ウェブクライアントからアプリケーション画面情報の要求を受け付けた場合、該要求に、前記情報処理サーバへのログイン状況を示す識別子が含まれているかを判定する判定ステップと、
第１の通知手段が、前記判定ステップにより前記識別子が含まれないと判定された場合、前記ウェブクライアントから前記情報処理サーバへ前記ログイン画面情報を要求させるための、該情報処理サーバのロケーション情報に、当該ウェブアプリケーションサーバのロケーション情報をパラメータとして付加して、前記ウェブクライアントに通知する第１の通知ステップと、
問い合わせ手段が、前記判定ステップにより前記識別子が含まれると判定された場合、該識別子の有効性を前記情報処理サーバに問い合わせる問い合わせステップと、
第１の画面情報送信手段が、前記問い合わせステップによる問い合わせの結果、前記識別子が有効である場合、前記識別子を埋め込んだウェブアプリケーション画面情報を、前記ウェブクライアントへ送信する第１の画面情報送信ステップと、
第２の通知手段が、前記ウェブクライアントから他のウェブアプリケーションサーバへ画面を遷移する要求を受け付けた場合、前記ウェブクライアントから前記他のウェブアプリケーションサーバへ前記他のウェブアプリケーション画面情報を要求させるための、該他のウェブアプリケーションサーバのロケーション情報に、前記要求内の前記ウェブアプリケーション画面情報に含まれる識別情報を、パラメータとして付加して、前記ウェブクライアントに通知する第２の通知ステップとを実行させ、
前記情報処理サーバに、
第２の画面情報送信手段が、前記ウェブクライアントから前記ログイン画面情報の要求を受け付けた場合、前記要求に含まれる前記ウェブアプリケーションサーバのロケーション情報を、前記ログイン画面情報に埋め込んで、前記ウェブクライアントへ送信する第２の画面情報送信ステップと、
ログイン処理手段が、前記ウェブクライアントから前記ログイン画面情報を含むログイン要求を受け付けた場合、ログイン処理を行うログイン処理ステップと、
識別子生成手段が、前記ログイン処理手段によるログイン処理が成功した場合、前記識別子を生成して保持手段に保持させる識別子生成ステップと、
第３の通知手段が、前記ウェブクライアントから前記ウェブアプリケーションサーバへ前記アプリケーション画面情報を要求させるための、前記ログイン要求内のログイン画面情報に含まれていた前記ウェブアプリケーションサーバのロケーション情報に、前記識別子生成手段により生成された識別子をパラメータとして付加して、前記ウェブクライアントに通知する第３の通知ステップと、
識別子有効性判定手段が、前記問い合わせステップにより問い合わされた識別子が有効であるか否かを、該識別子が前記保持手段に保持されているか否かで判定し、該判定結果を返信する識別子有効性判定手段とを実行させることを特徴とする情報処理方法。
【請求項６】
請求項５に記載された情報処理方法を、ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと情報処理サーバとを含む情報処理システムにおいて実行させるためのプログラム。
【請求項７】
請求項５に記載された情報処理方法を、ウェブアプリケーションが動作する複数のウェブアプリケーションサーバと情報処理サーバとを含む情報処理システムにおいて実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２００９−２７１８１７（Ｐ２００９−２７１８１７Ａ）
【公開日】平成２１年１１月１９日（２００９．１１．１９）
【国際特許分類】
【出願番号】特願２００８−１２３１１３（Ｐ２００８−１２３１１３）
【出願日】平成２０年５月９日（２００８．５．９）
【出願人】（３０１０１５９５６）キヤノンソフトウェア株式会社 (364)
【Ｆターム（参考）】
【公開日】平成２１年１１月１９日（２００９．１１．１９）
【国際特許分類】
【出願日】平成２０年５月９日（２００８．５．９）
【出願人】（３０１０１５９５６）キヤノンソフトウェア株式会社 (364)
【Ｆターム（参考）】
[ Back to top ]