JP2004220318A - 情報処理装置及びこれに用いるプログラム - Google Patents

Abstract

【課題】サーバーと、同一の情報処理装置上における複数のクライアントプログラムとの間で１つのセッションを共有することで、ユーザの利便性を高める。
【解決手段】情報処理装置２において、ユーザ認証後にサーバープログラムとの間で確立される一つのセッションを複数のクライアントプログラムの間で共有するために、該セッションの識別情報を管理するセッション管理手段２ｍを設ける。異なるクライアントプログラムであっても、ユーザ認証後に確立される同一セッション（サーバーセッション）の識別情報を用いてサーバープログラムとの間で通信処理を行えるようにした。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、通信機能を備えた情報処理装置において、ユーザの利便性を高めるとともに、サーバーの負荷を軽減するための技術に関する。
【０００２】
【従来の技術】
ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ等）サービスを提供するサーバーのクライアントプログラムとして、Ｗｅｂブラウザだけでなく、Ｗｅｂサーバーが提供する機能（Ｗｅｂサービス）について直接ＨＴＴＰ（ハイパーテキスト転送プロトコル）等でアクセスすることができる専用クライアントが一般的になりつつある。
【０００３】
そして、ネットワーク上のサーバーマシンとクライアントマシンとの間で通信を行う場合に、通常、ユーザ認証が必要とされる。例えば、ログインを必要とするＷｅｂサービスを利用する場合、クライアントマシン上のクライアントプログラムからそのＷｅｂサービスを利用するにあたって、ユーザＩＤ（識別情報）やパスワード（暗証番号）等の入力が必要である。
【０００４】
【発明が解決しようとする課題】
ところで、従来の装置では、複数のクライアントプログラムの間で同一のセッションを共有して、サーバープログラムとの間で情報のやりとりを行えないため、例えば、下記に示すような問題が起きる。
【０００５】
同一サーバーにより提供されるＷｅｂサービス等に対してアクセスするためのクライアントプログラムが一つの情報処理装置に一種類しか存在しない場合には、そのクライアントプログラム（アプリケーション）を立ち上げてからユーザＩＤやパスワード等を入力してユーザ認証を行えば良い。しかし、複数のアプリケーションを使って同一のＷｅｂサービスにアクセスし、ユーザがアプリケーション間で連携した使用を望む場合には、アプリケーション毎にユーザＩＤやパスワードを入力し、サーバーとのセッションをそれぞれ開始する必要がある。つまり、サーバーが同じでも、クライエントマシン上のクライアントプログラム毎に異なるセンションが開始される。
【０００６】
このような状況下では、下記の事項が問題となる。
【０００７】
・ユーザが、アプリケーション毎に同じユーザＩＤ及びパスワードをその都度入力する必要があるので、操作が２度手間となり面倒であること。
【０００８】
・サーバーにとっては、１人のユーザに対して異なるセッションを開始しなければならず、無駄なリソース（コンピュータ資源）を消費してしまうこと。
【０００９】
・Ｗｅｂサービス等のシステム設計上、セッション毎の管理に必要な情報を、一時的な情報（揮発性データ）として管理する場合（例えば、ショッピングカートのような購買システムにおいて、ログインしてからカート内にユーザが注文しようとする商品情報を保持する場合が考えられ、そのカート内部の商品情報が、セッションの終了時にクリアされるような場合等）、別々のセッションとして管理されるクライアントプログラム間では、ユーザが同一であるにもかかわらず、サーバー側のデータ等を共有できないといった問題が発生すること。
【００１０】
そこで、本発明は、同一の情報処理装置上における複数のクライアントプログラムと、サーバーとの間でセッションを共有して、ユーザの利便性を高めることを課題とする。
【００１１】
【課題を解決するための手段】
本発明に係る情報処理装置は、ユーザ認証を経てサーバープログラムとクライアントプログラムとの間の論理的な接続関係として確立されるセッションに関して、一つのセッションを複数のクライアントプログラムの間で共有するために、該セッションの識別情報を管理するセッション管理手段を備えたものである。
【００１２】
また、本発明に係る情報処理装置に用いるプログラムは、ユーザ認証後にサーバープログラムとの間で確立される一つのセッションを複数のクライアントプログラムの間で共有するために、該セッションの識別情報を管理するステップを有するものである。
【００１３】
従って、本発明によれば、異なるクライアントプログラムであっても、ユーザ認証後に確立される同一セッションの識別情報を用いてサーバープログラムとの間で通信処理を行うことができる。
【００１４】
【発明の実施の形態】
本発明は、サーバーによるウェブ（Ｗｅｂ）サービス等をクライアントに提供するシステムにおいて、１つのセッション（サーバーセッション）を同一マシン（クライアントマシン）上の複数のクライアントで共有することができるようにしたものである。例えば、１つのＷｅｂサービスにアクセスすることができる、複数のクライアントプログラムをユーザが使用する場合に、ユーザが同じであれば、クライアントプログラム毎に別々のログインを行う必要がなく、１度どれかのクライアントプログラムでログインすると、それ以降、他のクライアントプログラムではログインを行う必要がない。これによって、ユーザの利便性を向上させることができる。
【００１５】
尚、ここで「セッション」とは、ユーザＩＤやパスワード等を用いたユーザ認証を経てサーバープログラムとクライアントプログラムとの間に確立される通信上の論理的な接続関係を意味し、ユーザ認証が正しく行われて生成（又は開始）され、ユーザ操作又は時間制限等の終了条件により消滅する。より簡単に言えば、ログインから開始され、ログアウト等で終了するまでの間、サーバーとクライアントとの間で行われる一連の処理を表している。
【００１６】
図１は、インターネット等を用いたコンピュータネットワーク及びこれに接続された情報処理装置（サーバーマシンやクライアントマシン）により構成されたシステム例を概念的に示したものである。
【００１７】
本システム（情報通信システム）１では、情報処理装置２としてクライアントマシン２ｃ、２ｃ、…及びサーバーマシン２ｓが設けられている。つまり、特定の情報サービス（Ｗｅｂサービス等）をクライアントマシン２ｃ、２ｃ、…に対して提供するサーバーマシン２ｓがネットワーク上に接続されていて、サーバーマシン２ｓ上で実行されるサーバープログラムを用いて、情報サービス等に必要な各種の情報処理が行われる。
【００１８】
クライアントマシン２ｃは、該マシン上で実行されるクライアントプログラムを用いて、サーバープログラムとの間で情報をやりとりすることができる。尚、「クライアントマシン」としては、例えば、ネットワーク通信機能を有するパーソナルコンピュータや、Ｗｅｂサービス等にアクセス可能な、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）、携帯電話等の移動体通信端末装置、あるいはネットワーク接続可能な各種装置（撮像装置や映像機器等）が挙げられる。また、クライアントプログラムとしては、例えば、ブラウザ（閲覧用ソフト）が挙げられるが、これに限らず各種アプリケーションを用いることができる。
【００１９】
図１には、ある情報処理装置（クライアントマシン２ｃ）において、複数のクライアントプログラムＡ、Ｂ、…が実行されている様子を概念的に示している。該クライアントマシンは、複数のクライアントプログラム（プロセス）間で一つのセッションを共有するために、該セッションの識別情報を管理するセッション管理手段２ｍを備えている（実際のハードウェア構成としては、例えば、中央処理装置やメインメモリ、システムコントローラ等の各種コントローラ、補助記憶装置等が設けられ、プログラム等を用いてセッション管理手段２ｍが実現されるが、図には簡略化して示している。）。
【００２０】
一例としては、クライアント側に、１つのサーバーセッションに対応する、実行プログラム（以下、「セッション管理プロセス」という。）を用意し、これを用いてセッションの識別情報を管理する。つまり、このセッション管理プロセスは、上記セッション管理手段２ｍを構成するものであり、クライアントマシン又はプログラムとサーバーマシン又はプログラムとの接続時、あるいはログイン時に生成されるセッションを識別するためのＩＤ情報（以下、「セッションＩＤ」という。）を管理する役目をもっている。
【００２１】
Ｗｅｂサービス等を利用する場合に実行されるクライアントプログラムは、１つのクライアントマシン上において、それぞれ別々のプログラム（プロセス）として存在し、それらは、セッション管理プロセスに対して、セッションＩＤの問い合わせや設定を行うことができる。
【００２２】
第一のクライアントプログラム（クライアントＡ）から、サーバーにログインする時、セッション管理プロセスが起動され、クライアントＡとサーバープログラムとの間で開始されたセッションのセッションＩＤをクライアントＡがセッション管理プロセスに対して設定する。
【００２３】
その後に、第二のクライアント（クライアントＢ）が起動されたときは、セッション管理プロセスの存在を条件として、セッションＩＤが該プロセスからクライアントＢに通知される。つまり、クライアントＢは、セッション管理プロセスが存在しているかどうかを判定し、該プロセスがクライアントマシン上に存在している場合は、設定済みのセッションＩＤを取り出す。そして、クライアントＢを用いてサーバーマシンとの通信を始める場合に、取得したセッションＩＤを使用してサーバーへのアクセスを行う。
【００２４】
クライアントＢとサーバープログラムとの間でクライアントＡの場合と同じセッションＩＤを用いた通信処理が行われ、よって、クライアントＢを使ったユーザが、Ｗｅｂサービス等にログインするために、ユーザ名やパスワード等、ユーザ認証に必要なデータを入力する必要が無い。
【００２５】
尚、上記の説明では、最初のログイン時に、セッション管理プロセスが生成されるものとしたが、該プロセスが生成されるタイミングについては、特に「ログイン」という行為を必要としない。よって、常駐プログラムの形態としても良いし、また最初にＷｅｂサービス等に接続したときにプロセスを生成する等、各種形態で実施することができる。
【００２６】
以下では、画像データを取り扱う、フォト・シェアリングサイト（画像情報の共有及び利用のためのサイト）のウェブサービスを例にして、図２乃至図７に従って具体的に説明する。
【００２７】
本サイト（ｈｔｔｐ：／／ｗｗｗ．ｉｍａｇｅｓｔａｔｉｏｎ．ｊｐ／）では、画像ファイルを”アルバム”という、ファイルシステムのディレクトリに類似の論理構造（１階層構造）により管理している。
【００２８】
ウェブサービスのためのインターフェイス（Ｅｘｔｅｒｎａｌ Ｉｎｔｅｒｆａｃｅ）は、アルバムの一覧やアルバム内の画像情報の取得、あるいは画像の特定アルバムへのアップロード、といった機能を提供するためのインターフェイスであり、クライアントプログラムである「アップローダ」及び「機能拡張バー」から利用される。
【００２９】
「アップローダ」は、クライアントマシン（ローカルマシン）にある画像ファイルを、サイトにアップロード（送信あるいは転送）する機能を備えた専用クライアントプログラムである。
【００３０】
図２は、「アップローダ」の画面（メイン画面）例を示したものであり、（Ａ）図がログイン前の表示状態を示し、（Ｂ）図がログイン後の表示状態を示している。
【００３１】
（Ａ）図に示すログイン前の状態における各部（オブジェクト）の意味は下記の通りである。
【００３２】
・ドロップターゲット部（３＿１）＝本来は画像ファイルのドラッグ＆ドロップ（マウスポインタによるアイコン操作）のために用意された領域（ログイン前ではアニメーション等が表示されるだけで、特別な機能はない。）
・ＩＤ入力部（３＿２）＝ログインＩＤ（ユーザＩＤ）の入力及び編集領域
・パスワード入力部（３＿３）＝パスワードの入力及び編集領域
・「ログイン」ボタン（３＿４）＝ログイン操作用のボタンオブジェクト
・メニューボタン（３＿５）＝操作時にポップアップメニュー（アルバム一覧更新、アップロード、新アルバム作成等の項目を含む）を表示するボタンオブジェクト。
【００３３】
尚、メニューボタン３＿５の右側には、「アルバムを開く」ボタン３＿６、「アルバムに招待する」ボタン３＿７等のオブジェクトが配置されている。
【００３４】
また、（Ｂ）図に示すログイン後の状態における各部（オブジェクト）の意味は下記の通りである。
【００３５】
・ドロップターゲット部（３＿１）＝サイトへのログイン状態において、この部分に対して画像ファイルのドラッグ＆ドロップを行うことで発生するイベントにより、該画像ファイルのアップロードが開始され、下記の「アルバムドロップダウンリスト」に選択されているアルバムに画像ファイルがアップロードされる。
【００３６】
・ニックネーム部（３＿８）＝ログインしたユーザが登録している名称（ニックネーム）の表示領域
・「ログアウト」ボタン（３＿９）＝ログアウト操作用のボタンオブジェクト・アルバムドロップダウンリスト（３＿１０）＝ユーザ所有のアルバムリストを表示したり、ドラッグ＆ドロップによる画像ファイルのアップロード、「アルバムを開く」ボタン３＿６や「アルバムに招待する」ボタン３＿７による操作は、すべてこのリストオブジェクトで選択されているアルバムに対して行われる。
【００３７】
尚、メニューボタン３＿５や、「アルバムを開く」ボタン３＿６、「アルバムに招待する」ボタン３＿７の配置は、（Ａ）図と同じである。
【００３８】
例えば、ユーザが「アップローダ」を用いてサイトにアクセスして、所望の画像ファイルをユーザが意図するアルバムにアップロードする場合の手順は次に示す通りである。
【００３９】
（１）「アップローダ」の起動及びログイン（図２（Ａ）に示す画面でのログインＩＤ及びパスワード入力等の操作）
（２）ユーザ認証が済むと、図２（Ｂ）に示す表示状態となり、ここでユーザが、アルバムドロップダウンリスト３＿１０でアップロード先のアルバムを選択する
（３）所望の画像ファイルのアイコンをドラッグ＆ドロップによりドロップターゲット部３＿１へと移す操作をユーザが行うことで、画像ファイルのアップロードが行われる。
【００４０】
次に、「機能拡張バー」について、図３及び図４を用いて説明する。
【００４１】
この「機能拡張バー」は、特定のブラウザ等にプラグイン（あるいはアドイン）として機能的に追加されるクライアントプログラム（プラグインコンポーネント等）である。
【００４２】
図３はブラウザに追加された形態を示すものであり、図には、アドレスバー等のツールバーの最下段に配置された「機能拡張バー」を示している。これは、例えば、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（マイクロソフト社の商標）へのプラグイン形態の場合、ウィンドウズ（マイクロソフト社製ＯＳの商標）では、ダイナミックリンクライブラリ（ＤＬＬ：：Ｄｙｎａｍｉｃ Ｌｉｎｋ Ｌｉｂｒａｒｙ）として実装されていて、システムに登録しておくことでブラウザによってメモリロードがなされる。
【００４３】
図４は、「機能拡張バー」の画面例を示したものであり、（Ａ）図がログイン前の表示状態を示し、（Ｂ）図がログイン後の状態を示している。
【００４４】
（Ａ）図に示すログイン前の状態では、ボタンオブジェクト４＿１だけが表示されており、このボタンを押すと所定のメニュー（ログイン、ヘルプ等）が表示される。
【００４５】
また、（Ｂ）図に示すログイン後の状態における各部（オブジェクト）の意味は下記の通りである。
【００４６】
・ボタンオブジェクト（４＿１）＝ボタン操作により、ログアウト、アルバム情報、新規アルバムの作成等の各種項目を含むメニューが表示される。
【００４７】
・「アルバム」ボタン（４＿２）＝アルバムタイトルを表示したボタンオブジェクトであり、アルバムの更新時にソーティング（並び替え）された最新のものが表示画面の片側から順番に表示される。ユーザが本ボタンを押すとそのアルバムの画像リストページに遷移する。
【００４８】
・「アルバム移動」ボタン（４＿３）＝バー上に表示される「アルバム」ボタン群の両側に位置されるボタンオブジェクト（「＜＜」、「＞＞」で示す。）。「機能拡張バー」の表示エリアが狭い場合やアルバムの数が多い場合に、本ボタンが有効となり、例えば、ボタン押圧により、「＜＜」又は「＞＞」に示される方向に従って「アルバム」ボタンの位置がシフト（移動）する。これにより、バーに表示される「アルバム」ボタン群の表示を変更できる。
【００４９】
ユーザは「機能拡張バー」からサイトへのログインを行うことができ、その際には、該ユーザのアルバム一覧用データがインターフェイス（Ｅｘｔｅｒｎａｌ Ｉｎｔｅｒｆａｃｅ）経由で取得され、それらは「アルバム」ボタン（ショートカットボタン）としてバー上に並べられる。
【００５０】
尚、「機能拡張バー」と同等の機能を有するプログラム（ブラウザ等）を最初から設計して作成することもできるが、本例のように、ユーザが使い慣れた既存プログラムへの機能追加として必要な処理を付加する形態では、操作等を改めて学習すること等を含めて、ユーザーの負担が少ないといった利点があり、また、プログラム作成上の負担が軽減される。
【００５１】
「アップローダ」、「機能拡張バー」は別々のクライアントプログラムとされるが、どちらを用いても同一サイトにログインすることができ、本来的にはサーバーとの間でセッションをそれぞれ確立することが可能である。
【００５２】
図５は、セッションの共有を行う場合の基本的な流れについて説明するための図であり、ネットワークにより接続されるサーバープログラム（「Ｓ」）及びクライアントプログラムＡ、Ｂ、セッション管理プロセス「Ｍ」の関係を示している。尚、本例では、クライアントプログラムＡが「アップローダ」とされ、クライアントプログラムＢが「機能拡張バー」とされており、最初に「アップローダ」のみが起動され、その後に「機能拡張バー」を含むブラウザが起動された状態を想定している。
【００５３】
図示のように、サーバープログラムＳにおいて作成されるセッションＩＤ（本例では「０００１１１」）は、クライアントマシンに送られ、セッション管理プロセスＭで管理される。
【００５４】
セッション管理プロセスＭは、「クライアントテーブル」を保持しているが、該テーブルは、クライアントプログラムの実行インスタンスを登録しておくためのテーブルである。例えば、クライアントＡがサーバーに対して何らかのリクエストを発し、サーバー内部のセッションに関する情報やデータに変更があった場合に、クライアントＢがそのイベントを知るためにこのテーブルが使用される。各クライアントプログラム（プロセス）はイベントを受け取る用意ができた状態にある場合に、このクライアントテーブルにアプリケーションハンドルを登録しておく（尚、「アプリケーションハンドル」は、実行アプリケーションを特定するために用いられる識別情報であり、例えば、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）の場合、ウィンドウハンドルが挙げられる。）。
【００５５】
所定のイベントが発生した場合（例えば、あるクライアントプログラムでユーザーがログアウトした場合等）、クライアントテーブルに登録されているすべてのクライアントに該イベントに対応するメッセージが送られる。
【００５６】
図５に示す（１）乃至（８）の手順例に従って、一連の処理の流れを、以下に説明する。
【００５７】
（１）クライアントＡの起動及びユーザの入力ステップ
（２）ユーザ認証及びセッション生成のステップ
（３）セッション管理プロセスの生成及びセッション管理等のステップ
（４）クライアントＢの起動ステップ
（５）セッションＩＤの取り出し及びアプリケーションハンドルの登録ステップ
（６）セッションＩＤの返送ステップ
（７）（６）のセッションＩＤを用いたサーバーの呼び出しステップ
（８）ログイン済みセッションへの応答の返送ステップ。
【００５８】
先ず、（１）では、ユーザの指示を受けてクライアントＡ、即ち、「アップローダ」が起動される。その後、ユーザに対して、サイトへのログインＩＤ及びパスワードを要求する画面（図２（Ａ）参照）が提示される。ユーザが入力した項目（ログインＩＤ、パスワード）データは、暗号化されてサーバープログラムＳに送られる。
【００５９】
（２）では、サーバーにおいてユーザ認証が行われ、上記（１）で入力された情報が、正しいユーザ情報であるか否かが判断される。そして、ユーザ情報が正しいと判断された場合には、セッション（ここでは、セッションＩＤを仮に「０００１１１」とする。）が生成される。セッションＩＤの情報はサーバープログラムＳからクライアントＡに返される。
【００６０】
（３）では、正しいセッションＩＤがサーバーから送られてきた場合に、クライアントＡが、セッション管理プロセスＭを生成して、セッションＩＤ（本例では「０００１１１」）を設定する。これは、一つのセッションを複数のクライアントプログラムの間で共有するために、セッション管理プロセスＭがセッションＩＤを管理する必要のためである。また、それと同時にアプリケーションハンドル（ウィンドウハンドル）をセッション管理プロセスＭのクライアントテーブルに登録する（尚、この時点では、クラアントＢはクライアントテーブルに未登録である。）。
【００６１】
（４）において、ユーザの指示を受けてクライアントＢ、即ち、ブラウザが起動される（図３参照。）。
【００６２】
（５）では、クライアントＢの起動直後にセッション管理プロセスＭを検索し、該プロセスの存否が判断される。そして、セッション管理プロセスが存在する場合は、（２）で設定されたセッションＩＤを取り出す。その際、「機能拡張バー」（を含むブラウザ）を特定するためのアプリケーションハンドル（ウィンドウハンドル）を登録しておく（これは、セッション管理プロセスのクライアントテーブルに登録される。）。
【００６３】
（６）では、セッション管理プロセスに登録されているセッションＩＤがクライアントＢに送られる。つまり、クライアントＢとサーバープログラムＳとの間で該セッションＩＤを用いた通信処理を行えるように、セッションＩＤがクライアントＢに通知される。
【００６４】
（７）において、サイトのサーバーを呼び出す場合に、（６）で得られたセッションＩＤを使用してアクセスする。たとえば、（１）でユーザがアップローダに入力したユーザＩＤによるログイン状態のページを要求する際に、このセッションＩＤを一緒にサーバに送る
（８）では、ログイン済みのセッションに対する応答がクライアントＢに返る。
【００６５】
尚、（１）、（２）及び（７）、（８）の処理は、サーバーマシンとクライアントマシンとの間のネットワーク通信により行われ、また、（３）、（５）、（６）の処理はプロセス間通信（ＬＰＣ：Ｌｏｃａｌ Ｐｒｏｃｅｄｕｒｅ ｃａｌｌ等）で行われる。（７）のサーバーへのリクエストについては、いわゆるクッキー（Ｃｏｏｋｉｅ：ＷＷＷサーバーがユーザを識別して管理する仕組み）に（６）で取得したセッションＩＤを入れてサーバーに通知することも可能である。
【００６６】
図５において、（３）や（５）では、アプリケーション（クライアントＡ、Ｂ）がセッション管理プロセスＭに対してアプリケーションハンドルを設定しており、セッション管理プロセスＭではそれらの設定情報をクライアントテーブルに保持している。クライアントテーブルは、セッション管理プロセスＭが、あるクライアントから発生したイベント（例えば、ログアウトや新規アルバムの作成など）を他のクライアントに通知するために必要とされる。
【００６７】
次に、「アップローダ」と、「機能拡張バー」（を含むブラウザ）がともにログイン状態にあるとし、図６を使ってイベント通知の仕組みについて説明する。
【００６８】
処理の流れは以下の通りである。
【００６９】
（１１）クライアントＡ（「アップローダ」）からサーバーに対してログアウト（ｌｏｇｏｕｔ）の操作を行う
（１２）ログアウト成功のステータスがクライアントＡに戻ってくる。尚、ここで、ログアウトとはサーバーセッションの削除を意味する。この状態では、クライアントＢの方ではサーバーに該当セッション（ＩＤ＝０００１１１）が無くなったことは分からない
（１３）クライアントＡが、セッション管理プロセスＭに対して、ログアウトイベントを送る
（１４）セッション管理プロセスＭは、クライアントテーブルに登録されている、クライアントＡ（送り元）以外のすべてのクライアント（本例では、クライアントＢ）にログアウトイベントを送る。これにより、クライアントは、現在のセッションが既に有効でないことを知り、例えば、ユーザインターフェイスをログイン待機状態にする等の処理が可能となる。
【００７０】
図７は、クライアントプログラム（「アップローダ」）を主体として、その起動から停止までの処理の流れをセッション管理プロセスとの関わりに限って例示したフローチャート図である（尚、基本的な処理の流れは、「機能拡張バー」の場合もほぼ同様である。）。
【００７１】
図中の「Ｓｔａｔｅ」はログイン状態（ｌｏｇｉｎ）、ログアウト状態（ｌｏｇｏｕｔ）の如何を示している。
【００７２】
先ず、ステップＳ１では、クライアントＡを起動し（この時点ではログアウト状態である。）、次ステップＳ２で、セッション管理プロセスＭのクライアントテーブルにクライアントＡのアプリケーションハンドルが登録される。
【００７３】
そして、ステップＳ３において、セッション管理プロセスＭからセッションＩＤを取得できるか否かが判断される。つまり、既にセッションが確立されてそのセッションＩＤがセッション管理プロセスＭに保持されている場合には、ステップＳ４に進むが、そうでない場合（セッション未確立）にはステップＳ５に進む。
【００７４】
ステップＳ４ではユーザインターフェイス（ＵＩ）をログイン状態とし（Ｓｔａｔｅ＝ｌｏｇｉｎ）、次ステップＳ５に進む。
【００７５】
ステップＳ５において、セッション管理プロセスＭからのメッセージ及びユーザイベントの待ち処理に入る。
【００７６】
次ステップＳ６では、現在ログアウト状態である場合に、ユーザインターフェイスによるログインを行うか否かが判断される。尚、「Ｓｔａｔｅ＝＝ｌｏｇｏｕｔ」は等値関係の条件式を意味し、該条件の成立時に真値を示す。現状ログアウトとされていてユーザがログインを行う場合には、ステップＳ７に進むが、そうでない場合にはステップＳ１１に進む。
【００７７】
ステップＳ７において、クライアントＡからサーバーにログインリクエストが送られた後、次ステップＳ８でログインの成否を判断し、ログインに成功した場合にはステップＳ９に進むが、ログイン不成功の場合にはステップＳ５に戻る。
【００７８】
ステップＳ９では、ログインの成功時にサーバーから送られてくるセッションＩＤがセッション管理プロセスＭに設定されて管理される。そして次ステップＳ１０でユーザインターフェイスをログイン状態にした後（Ｓｔａｔｅ＝ｌｏｇｉｎ）、ステップＳ５に戻る。
【００７９】
ステップＳ１１では、クライアントＡにセッション管理プロセスＭからログアウトメッセージが届けられたかどうかを判断する。つまり、前記したように、他のクライアントによるログアウト時にイベントが発生した場合には、クライアントテーブルに登録されている全クライアントにログアウトメッセージが送られるので、該メッセージが来た場合には、ステップＳ１２に進んでユーザインターフェイスをログアウト状態にした後（Ｓｔａｔｅ＝ｌｏｇｏｕｔ）、ステップＳ５に戻る。また、クライアントＡにログアウトメッセージが来ない場合には次ステップＳ１３に進み、イベント検知処理、例えば、新規アルバムの作成メッセージか否か等の判断を行い、ステップＳ１４に進みイベントに応じた処理（例えば、アルバムリストの更新等）を行ってからステップＳ５に戻る。
【００８０】
尚、ステップＳ１３からＳ１４に進み、Ｓ５に戻るループがイベント処理に係る主要な流れを示す。
【００８１】
ステップＳ１３からステップＳ１５に進んだ場合に、ここで、クライアントＡの終了（Ｅｘｉｔ）がユーザから指示されたか否かが判断される。そして、終了指示がなされた場合には、ステップＳ１６に進むが、そうでない場合にはステップＳ５に戻る。
【００８２】
ステップＳ１６において、セッション管理プロセスＭのクライアントテーブルからクライアントＡの登録が抹消される（アプリケーションハンドルが削除される。）。そして、ステップＳ１７に進んで、アプリケーション（クライアントＡ）が停止する。
【００８３】
以上のように、クライアントプログラムの起動後に、そのアプリケーションハンドルがクライアントテーブルに登録され、別のクライアントプログラムとサーバープログラムとの間で開始されたセッションの識別情報（セッションＩＤ）がセッション管理プロセスＭにおいて保持されているかが判断される。そして、セッションＩＤを取得することができる場合には、該セッションＩＤを用いてサーバーとの通信処理を行えるようにユーザインターフェイスがログイン状態とされる。また、サーバーとの間にセッションが確立されていない状態でログインを行う場合に、ステップＳ７乃至Ｓ１０に示すようにセッションが新たに開始されて、セッション管理プロセスＭにおけるセッションＩＤの設定登録後にログイン状態とされる。
【００８４】
しかして、上記した構成によれば、例えば、下記に示す利点が得られる。
【００８５】
・ログインを必要とする、ひとつの情報サービス（Ｗｅｂサービス等）に対して、同一マシン上の異なるクライアントプログラム（アプリケーション）からユーザがアクセスする場合に、どれか１つのクライアントプログラムでログインすると、他のクライアントプログラムにおいて再度ログインする必要が無くなる。つまり、ユーザは使用するアプリケーション毎にログインする必要が無くなり、ユーザＩＤやパスワード等をいちいち入力する手間が省けるので、ユーザの利便性が向上する。
【００８６】
・サーバー側からみた場合に、従来の構成では、クライアントマシンを使っているユーザが同一ユーザであるにもかかわらず、アプリケーション毎に複数のセッションを用意する必要がある（つまり、ユーザが同じでもアプリケーション毎にセッションの生成及びセッションＩＤの付与が必要とされる。）。これに対して、本発明に係る上記の構成では、複数のアプリケーションに関して１つのセッションＩＤで済むので、不要なリソースを消費しないように回避できる。
【００８７】
・１つのセッションで有効なデータを使うようなサービス（例えば、ショッピングカートのような仕組みを実装したアプリケーションを用いたサービス）では、別々のクライアントプログラム（アプリケーション）から１つのセッションにアクセス可能であるため、それぞれのクライアントプログラムにおいて、共通の状態を参照したり、情報の更新等を行うことができる（つまり、アプリケーション毎に異なるセッションが確立されてサーバーとクライアントとの間で通信が行われる形態では、アプリケーション側からみた場合にサーバーのデータ等を、複数のアプリケーションの間で共有することができない。）。
【００８８】
尚、本発明は、前記した情報処理装置やこれに用いるプログラムに限らず、上記したセッション管理機能を有するプログラムを記録した情報記録媒体（情報処理装置に装着してそのプログラムをメモリロードできるようにした各種の記録媒体や記憶媒体）や、一つのセッションを複数のクライアントプログラムの間で共有するために、セッションの識別情報を管理する方法等に幅広く適用することができる。
【００８９】
【発明の効果】
以上に記載したところから明らかなように、請求項１、請求項４に係る発明によれば、異なるクライアントプログラムであっても、ユーザ認証後に確立される同一セッションの識別情報を用いてサーバープログラムとの間で通信処理を行うことができるので、ログインのための重複した入力操作からユーザが解放され、また、複数のクライアントプログラムからみた場合に、クライアントプログラムの間でサーバーのデータ等を共有することができる。
【００９０】
請求項２、請求項５に係る発明によれば、クライアントプログラムが新たに起動された場合に、該クライアントプログラムに対してセッションの識別情報を通知することができる。
【００９１】
請求項３、請求項６に係る発明によれば、所定のイベントが発生した場合（例えば、あるクライアントプログラムでのログアウト等）に、テーブルに登録されている全クライアントプログラムに対して該イベントに応じたメッセージが送られるので、該メッセージが通知されないことに起因する弊害や不要動作（例えば、ログアウト状態であるにもかかわらずログイン状態を前提としたリクエスト等が発行される等）を防止できる。
【図面の簡単な説明】
【図１】本発明に係るシステム構成例を示す概念図である。
【図２】クライアントプログラム「アップローダ」の画面例を示す説明図である。
【図３】クライアントプログラム「機能拡張バー」を含むブラウザの画面例を示す説明図である。
【図４】クライアントプログラム「機能拡張バー」の画面例を示す説明図である。
【図５】本発明に係る処理例を示す説明図である。
【図６】イベント通知に係る処理例を示す説明図である。
【図７】クライアントプログラムの起動から停止までの処理例について説明するためのフローチャート図である。
【符号の説明】
２…情報処理装置、２ｍ…セッション管理手段

Claims (6)

1. ユーザ認証を経てサーバープログラムとクライアントプログラムとの間の論理的な接続関係として確立されるセッションを通して情報伝達を行う通信機能を備えた情報処理装置において、
   一つのセッションを複数のクライアントプログラムの間で共有するために、該セッションの識別情報を管理するセッション管理手段を備えている
   ことを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置において、
   第一のクライアントプログラムと上記サーバープログラムとの間で開始されたセッションの識別情報が上記セッション管理手段により管理されるとともに、その後に第二のクライアントプログラムが起動された場合に、該セッションの識別情報が上記セッション管理手段から第二のクライアントプログラムに通知されることで、第二のクライアントプログラムと上記サーバープログラムとの間で該セッションの識別情報を用いた通信処理が行われる
   ことを特徴とする情報処理装置。
3. 請求項１に記載の情報処理装置において、
   上記セッション管理手段が、上記クライアントプログラムを登録するためのテーブルを備えており、所定のイベントが発生した場合に該テーブルに登録されている全てのクライアントプログラムに該イベントに対応するメッセージが送られる
   ことを特徴とする情報処理装置。
4. ユーザ認証を経てサーバープログラムとクライアントプログラムとの間の論理的な接続関係として確立されるセッションを通して情報伝達を行う通信機能を備えた情報処理装置に用いるプログラムであって、
   一つのセッションを複数のクライアントプログラムの間で共有するために、該セッションの識別情報を管理するステップを有する
   ことを特徴とする情報処理装置に用いるプログラム。
5. 請求項４に記載の情報処理装置に用いるプログラムにおいて、
   第一のクライアントプログラムと上記サーバープログラムとの間で開始されたセッションの識別情報を保持し、その後に第二のクライアントプログラムが起動された場合に、第二のクライアントプログラムと上記サーバープログラムとの間で該セッションの識別情報を用いた通信処理を行えるように、該セッションの識別情報を第二のクライアントプログラムに通知するステップを有する
   ことを特徴とする情報処理装置に用いるプログラム。
6. 請求項４に記載の情報処理装置に用いるプログラムにおいて、
   上記クライアントプログラムをテーブルに登録しておき、所定のイベントが発生した場合に該テーブルに登録されている全てのクライアントプログラムに該イベントに対応するメッセージを送るステップを有する
   ことを特徴とする情報処理装置に用いるプログラム。

Images