(57)【要約】【課題】コンテキストラウンチ管理方法等を提供する。【解決手段】各アプリケーションプログラム固有の処理データをその機能または属性の分類に応じて定義付けしたクラスと、当該クラス毎に各アプリケーションプログラムが実行可能な処理との対応関係を定めたテーブルを有して、ユーザインターフェイスに表示されたアプリケーションプログラムの前記処理データがユーザより選択された際、当該処理データに関連付けされたコールバック処理を実行するステップと、前記処理データのクラスに対応した処理一覧を前記テーブルより抽出し、これをユーザインターフェイスに表示するステップと、ユーザインターフェイスに表示された前記処理一覧中のある処理がユーザより選択された際、当該処理を受付けるステップと、前記処理に関連付けられた処理内容を前記テーブルより認識し、この処理内容に応じたアプリケーションプログラムの起動処理を行うステップと、を実行する。【選択図】　　　図４
2004102453.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラム間におけるコンテキストラウンチのコンピュータによる管理方法であって、
前記コンピュータが、各アプリケーションプログラム固有の処理データをその機能または属性の分類に応じて定義付けしたクラスと、当該クラス毎に各アプリケーションプログラムが実行可能な処理との対応関係を定めたテーブルを有して、
ユーザインターフェイスに表示されたアプリケーションプログラムの前記処理データがユーザより選択された際、当該処理データに関連付けされたコールバック処理を実行するステップと、
前記処理データのクラスに対応した処理一覧を前記テーブルより抽出し、これをユーザインターフェイスに表示するステップと、
ユーザインターフェイスに表示された前記処理一覧中のある処理がユーザより選択された際、当該処理を受付けるステップと、
前記処理に関連付けられた処理内容を前記テーブルより認識し、この処理内容に応じたアプリケーションプログラムの起動処理を行うステップと、
を備えることを特徴とするコンテキストラウンチ管理方法。
【請求項２】
前記処理データのクラスに対応した処理一覧を前記テーブルより抽出した際、該当する処理が１つであったならば、当該処理に関連付けられた処理内容を前記テーブルより認識し、この処理内容に応じたアプリケーションプログラムの起動処理を行うことを特徴とする請求項１に記載のコンテキストラウンチ管理方法。
【請求項３】
前記各ステップを、ユーザインターフェイス上でのユーザによる処理データ選択に応じて順次繰り返すことを特徴とする請求項１に記載のコンテキストラウンチ管理方法。
【請求項４】
前記コンピュータに対するユーザのセッション情報を、前記アプリケーションプログラムに受け渡すことで、各アプリケーションプログラムの利用権限を認証させ、前記各ステップを実行することを特徴とする請求項１に記載のコンテキストラウンチ管理方法。
【請求項５】
アプリケーションプログラム間におけるコンテキストラウンチの管理システムであって、
各アプリケーションプログラム固有の処理データをその機能または属性の分類に応じて定義付けしたクラスと、当該クラス毎に各アプリケーションプログラムが実行可能な処理との対応関係を定めたテーブルと、
ユーザインターフェイスに表示されたアプリケーションプログラムの前記処理データがユーザより選択された際、当該処理データに関連付けされたコールバック処理を実行する手段と、
前記処理データのクラスに対応した処理一覧を前記テーブルより抽出し、これをユーザインターフェイスに表示する手段と、
ユーザインターフェイスに表示された前記処理一覧中のある処理がユーザより選択された際、当該処理を受付ける手段と、
前記処理に関連付けられた処理内容を前記テーブルより認識し、この処理内容に応じたアプリケーションプログラムの起動処理を行う手段と、
を備えることを特徴とするコンテキストラウンチ管理システム。
【請求項６】
アプリケーションプログラム間におけるコンテキストラウンチの管理方法を、各アプリケーションプログラム固有の処理データをその機能または属性の分類に応じて定義付けしたクラスと、当該クラス毎に各アプリケーションプログラムが実行可能な処理との対応関係を定めたテーブルを有したコンピュータ上で実行させるプログラムであって、
ユーザインターフェイスに表示されたアプリケーションプログラムの前記処理データがユーザより選択された際、当該処理データに関連付けされたコールバック処理を実行するステップと、
前記処理データのクラスに対応した処理一覧を前記テーブルより抽出し、これをユーザインターフェイスに表示するステップと、
ユーザインターフェイスに表示された前記処理一覧中のある処理がユーザより選択された際、当該処理を受付けるステップと、
前記処理に関連付けられた処理内容を前記テーブルより認識し、この処理内容に応じたアプリケーションプログラムの起動処理を行うステップと、
を備えることを特徴とするコンテキストラウンチ管理プログラム。
【請求項７】
請求項６に記載のコンテキストラウンチ管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンテキストラウンチ管理方法およびシステム、ならびにプログラム、記録媒体に関する。
【０００２】
【従来の技術】
企業等の情報処理システムが取り扱うデータ量や種類は増大の一途を辿っており、それに伴い、システムのユーザがコンピュータ上で実行する各種処理もその手順が複雑化しがちである。特に、ネットワーク上に分散した複数のオブジェクト（アプリケーションプログラム）を起動させて処理を行い、その処理結果を利用するユーザにとって、アプリケーションプログラム間の連携を可能にする技術が望まれていた。
【０００３】
だが通常、コンピュータシステム上で起動された複数の各アプリケーションプログラムはそれぞれ独立に動作しており、互いに他のアプリケーションについて関知しないし、またプロパティを共用することもほとんどない。例えば、コモンゲートウェイインタフェース（ＣＧＩ）プログラムとＪａｖａ（登録商標）アプレットは異なったところから環境情報を得ている。いずれにせよ、アプリケーションプログラム間で情報を共用し互いに連携するという処理手法は提案されてこなかった。
【０００４】
そこで、オブジェクト指向型プログラミングやコンポーネント技術などが登場し、ＧＵＩ技術とも相まって、アプリケーションプログラム間の連携を図って、ユーザの操作負担を軽減する志向が高まっている。例えば、ＧＵＩ中において、ある表示部位をユーザがクリックすることで「印刷」、「コピー」、「切り取り」等の処理が一覧となったコンテキストメニューを表示させ、このコンテキストメニューから選択された処理に応じたアプリケーションプログラム（オブジェクト）を実行させることは可能となっている。
【０００５】
【特許文献１】
特開平７−７３００９号公報
【０００６】
【発明が解決しようとする課題】
しかしながら、あるアプリケーションプログラムを起動し、このアプリケーションプログラムにおけるＧＵＩ画面上でコンテキストラウンチの処理を行って別のアプリケーションプログラムを直接起動する技術、あるいはこれを繰り返す技術は提供されていなかった。このような場合、アプリケーションプログラムの管理マネージャ機能が備えているラウンチプログラムや、このコンテキストラウンチに必要なリポジトリデータなどを各アプリケーションプログラム全てに実装させる必要が生じてくる。
【０００７】
例えばストレージサブシステム、バックアップ・リカバリ製品、データベース製品、アプリケーション製品等を管理マネージャ機能で統合的に制御するような状況下においては、コンテキストラウンチさせるアプリケーションプログラムの種類やその数が膨大となり、また、そのシステム上での所在も多岐に亘る。ここで、それぞれのアプリケーションプログラム毎に前記したようなラウンチプログラムやリポジトリデータの実装対応を行うとすれば、アプリケーションプログラムの開発や保守管理に過大な負担がかかるのは避けがたい。
【０００８】
そこで、アプリケーションプログラムの開発や保守管理の負担を抑制しつつ、各アプリケーションプログラムの相互連携を可能にし、ユーザの目的に応じたアプリケーションプログラムの起動を簡便迅速に可能とするコンテキストラウンチの管理方法が望まれていた。
本発明はこのような経緯に基づいてなされたもので、コンテキストラウンチ管理方法およびシステム、ならびにプログラム、記録媒体を提供することを目的とする。
【０００９】
【課題を解決するための手段】
この目的を達成するための、本発明の主たる発明は、アプリケーションプログラム間におけるコンテキストラウンチのコンピュータによる管理方法であって、前記コンピュータが、各アプリケーションプログラム固有の処理データをその機能または属性の分類に応じて定義付けしたクラスと、当該クラス毎に各アプリケーションプログラムが実行可能な処理との対応関係を定めたテーブルを有して、ユーザインターフェイスに表示されたアプリケーションプログラムの前記処理データがユーザより選択された際、当該処理データに関連付けされたコールバック処理を実行するステップと、前記処理データのクラスに対応した処理一覧を前記テーブルより抽出し、これをユーザインターフェイスに表示するステップと、ユーザインターフェイスに表示された前記処理一覧中のある処理がユーザより選択された際、当該処理を受付けるステップと、前記処理に関連付けられた処理内容を前記テーブルより認識し、この処理内容に応じたアプリケーションプログラムの起動処理を行うステップと、を備えることを特徴とする。これにより、アプリケーションプログラムの開発や保守管理の負担を抑制しつつ、各アプリケーションプログラムの相互連携を可能にし、ユーザの目的に応じたアプリケーションプログラムの起動を簡便迅速に可能とする。
【００１０】
その他、本願が開示する課題、及びその解決方法は、発明の実施の形態の欄及び図面により明らかにされる。
【００１１】
【発明の実施の形態】
本明細書の記載により、少なくとも次のことが明らかにされる。
前記コンテキストラウンチ管理方法において、前記処理データのクラスに対応した処理一覧を前記テーブルより抽出した際、該当する処理が１つであったならば、当該処理に関連付けられた処理内容を前記テーブルより認識し、この処理内容に応じたアプリケーションプログラムの起動処理を行うことこととできる。これにより、ユーザに無用の選択処理を強いることなくシステム全体の処理効率向上を図ることができる。
【００１２】
また、前記コンテキストラウンチ管理方法において、前記各ステップを、ユーザインターフェイス上でのユーザによる処理データ選択に応じて順次繰り返すこととできる。これにより、アプリケーションプログラムを重層的に使用する状況かにも柔軟かつ確実に対応可能となる。
【００１３】
更に、前記コンテキストラウンチ管理方法において、前記コンピュータに対するユーザのセッション情報を、前記アプリケーションプログラムに受け渡すことで、各アプリケーションプログラムの利用権限を認証させ、前記各ステップを実行することとできる。これにより、連携するアプリケーションプログラム毎の認証および認可を迅速かつ容易にし、スタンドアロン実行時などに無用なコンテキストメニューの表示を回避することもできる。
【００１４】
また、アプリケーションプログラム間におけるコンテキストラウンチの管理システムであって、各アプリケーションプログラム固有の処理データをその機能または属性の分類に応じて定義付けしたクラスと、当該クラス毎に各アプリケーションプログラムが実行可能な処理との対応関係を定めたテーブルと、ユーザインターフェイスに表示されたアプリケーションプログラムの前記処理データがユーザより選択された際、当該処理データに関連付けされたコールバック処理を実行する手段と、前記処理データのクラスに対応した処理一覧を前記テーブルより抽出し、これをユーザインターフェイスに表示する手段と、ユーザインターフェイスに表示された前記処理一覧中のある処理がユーザより選択された際、当該処理を受付ける手段と、前記処理に関連付けられた処理内容を前記テーブルより認識し、この処理内容に応じたアプリケーションプログラムの起動処理を行う手段と、を備えることを特徴とするコンテキストラウンチ管理システムをなすこととできる。これにより、本発明のコンテキストラウンチ管理方法をコンピュータシステムとして実現することができる。
【００１５】
また、アプリケーションプログラム間におけるコンテキストラウンチの管理方法を、各アプリケーションプログラム固有の処理データをその機能または属性の分類に応じて定義付けしたクラスと、当該クラス毎に各アプリケーションプログラムが実行可能な処理との対応関係を定めたテーブルを有したコンピュータ上で実行させるプログラムであって、ユーザインターフェイスに表示されたアプリケーションプログラムの前記処理データがユーザより選択された際、当該処理データに関連付けされたコールバック処理を実行するステップと、前記処理データのクラスに対応した処理一覧を前記テーブルより抽出し、これをユーザインターフェイスに表示するステップと、ユーザインターフェイスに表示された前記処理一覧中のある処理がユーザより選択された際、当該処理を受付けるステップと、前記処理に関連付けられた処理内容を前記テーブルより認識し、この処理内容に応じたアプリケーションプログラムの起動処理を行うステップと、を備えることを特徴とするコンテキストラウンチ管理プログラムをなすこととできる。これによれば、本発明のコンテキストラウンチ管理方法をコンピュータ上で実行可能なプログラムを提供可能となる。
【００１６】
更に、前記コンテキストラウンチ管理プログラムを記録したコンピュータ読み取り可能な記録媒体をなすこととできる。これによれば、コンテキストラウンチ管理プログラムをおさめた記録媒体をなすことができる。
【００１７】
図１は本実施形態のコンテキストラウンチ管理システムを含むネットワーク構成図である。以下、システム構成について図面を用いて詳細に説明する。コンテキストラウンチ管理システム１００を主として構成するサーバ１０は複数のアプリケーションプログラム３０を管理し制御する管理マネージャとしての機能を果たす。この場合、前記アプリケーションプログラム３０が、サーバ１０が内部バス４０を介して備える１または複数のハードディスク等の記憶装置２０内に格納されているとすれば、前記サーバ１０はコンテキストラウンチ管理システム１００としてこの記憶装置２０もその構成に含むものと出来る。
【００１８】
前記サーバ１０は、適宜なファイルシステムを備えて各アプリケーションプログラム３０の管理・実行を行う。また、前記記憶装置２０が何らかのネットワークを介してサーバ１０に接続されている場合、例えばＳＣＳＩドライバ等とＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃａｒｄ）を介してＩ／Ｏ要求などの各種データをネットワーク上に送り出し、データ通信を行うとしてもよい。但し、サーバ１０と記憶装置２０とを結ぶネットワークは、本発明を実現可能であればインターネットやＬＡＮなどの他、いかなるプロトコルを備えるものであってもよい。
【００１９】
一方、アプリケーションプログラム３０を格納している記憶装置２０が、例えばストレージサブシステムを構成する物理ユニットあるいは論理ユニット、またはディスクアレイ装置自体である状況も想定できる。この場合、前記管理マネージャはストレージサブシステム全体における各ドライブやハードウェア装置の構成、容量、アドレス、データ処理状況、およびアプリケーションプログラム３０のインストールオプション情報やアプリケーションプログラム３０の保持している管理情報などを管理する機能も有することになる。また、前記バス４０をストレージサブシステムにおけるスイッチ装置と読み替え、更に記憶装置２０をディスクアレイ装置と読み替えることも出来る。
【００２０】
ストレージサブシステムの管理も行う場合の前記サーバ１０は、ＳＣＳＩやファイバーチャネルなどのインタフェース（図示しない）を介して各ストレージサブシステムの記憶制御装置（図示しない）に接続される。この記憶制御装置はＣＰＵやサーバ１０との間の入出力インタフェースを備えるのは勿論のこと、キャッシュメモリ、共有メモリ、チャンネルアダプタ、ディスクアダプタなどを備える。
【００２１】
前記記憶制御装置は、複数台の記憶装置２０の記憶エリアを用いて編成される論理ユニット、およびこの論理ユニット内に区画されたデータブロックを用いて記憶装置により提供される記憶エリアの管理を行っている。論理ユニットはＬＵＮ（Ｌｏｇｉｃａｌ　Ｕｎｉｔ　Ｎｕｍｂｅｒ）で識別され、また、データブロックはブロックアドレスで指定される。なお前記状況において、記憶装置２０とサーバ１０らとのデータ通信を規定・制御するプロトコルとしてＳＣＳＩやファイバーチャネルの他、ｉＳＣＳＩなども想定出来る。勿論、本発明を実現可能な技術であれば、いかなるネットワークとプロトコルを採用可能であるのは言うまでもない。
【００２２】
いずれにせよ複数のアプリケーションプログラム３０の管理を行うサーバ１０は、本発明のコンテキストラウンチ管理方法を実現するためいくつかのモジュールを有する。１つは主にコンピュータの制御やジョブの管理などのインターフェイスとなるコンソールおよびそのインターフェイスを構成するＧＵＩのアーキテクチャとなるＧＵＩフレームワークのモジュール１１である。ここには、コンソールでのインターフェイスの雛形となるＧＵＩテンプレート１２を複数備える一方で、Ｓｅｒｖｌｅｔ（登録商標）（サーブレット）モジュール１３も含まれている。
【００２３】
Ｓｅｒｖｌｅｔモジュール１３は、サーバ１０上でアプリケーションプログラム３０の実行を制御するソフトウェアも含み、サーバ１０にアドオンして動作する。例えばサーバ１０とＣＯＲＢＡ（登録商標）サービス等とのゲートウェイとしての役割、つまり、分散システム環境でのオブジェクト同士のメッセージ交換機能をサポート可能である。したがって、あるアプリケーションプログラムから他のアプリケーションプログラムを呼び出して実行させるコンテキストラウンチのツールの一部となる。
【００２４】
他のモジュールとしてはセキュリティモジュール１４を有する。このモジュール１４は、サーバ１０に対するログイン処理やアクセス管理機能を果たす。そのためのモジュール１５を備える。
【００２５】
また、他のモジュールとしてポリシーモジュール１６がある。このモジュール１６は、状況に応じて利用できるリソースやプログラムなどの機能を制限する機能を発現し、例えばサーバ１０にログインしたユーザのセッション情報に応じて操作可能なオブジェクトを限定することも可能となる。
【００２６】
サーバ１０は上記のようなモジュール１１、１４、１６の他、リポジトリデータベース１８を備えている。このリポジトリデータベース１８は、共通リポジトリデータ（テーブル或いは処理定義テーブル）を管理する。この共通リポジトリデータ１９は、各アプリケーションプログラム３０の構成情報およびハードウェアの構成や設定に関する情報、ならびにアプリケーションプログラム３０が保持している管理情報のうちでアプリケーションプログラム３０間のリンクやコンテキストラウンチに必要となる情報から構成される。サーバ１０は、各アプリケーションプログラム３０間でのコンテキストラウンチを行う際のコールバック処理に伴い、このリポジトリデータベース１８におけるに共通リポジトリデータ１９を参照するのである。この共通リポジトリデータ１９のデータ構造については後述する。
【００２７】
なお、アプリケーションプログラム３０とリポジトリデータベース１８とのアクセスなどを含む各種データの格納や参照には、ＪＤＢＣ（登録商標）（Ｊａｖａ　Ｄａｔａｂａｓｅ　Ｃｏｎｎｅｃｔｉｖｉｔｙ）を採用している。これは、Ｊａｖａ（登録商標）プログラムからデータベースにアクセスするために考案された統一インターフェイスであり、このＪＤＢＣにより、さまざまなドライバを用いて、ネットワーク上のサーバやデータベースなどを接続することが可能になる。
【００２８】
図２は本実施形態のスケジュール管理用データおよび名刺管理用データの構成図であり、図３は本実施形態の処理定義テーブルのデータ構成を示す図である。前記サーバ１０が管理するアプリケーションプログラム３０の例として、例えばスケジュール管理プログラムと名刺管理プログラムとが含まれていたとする。この各プログラムは、処理対象となる固有の処理データを備えて、スケジュール管理または名刺管理に際して要求される処理を実行することになる。
【００２９】
スケジュール管理プログラムにおける処理データは図２におけスケジュール管理用データ２００となる。このスケジュール管理用データ２００は、スケジューリングされたタスク、そのタイトル、並びにその担当者などのデータを含む構造を備える。一方、名刺管理用プログラムにおける処理データは図２における名刺管理用データ２１０となる。この名刺管理用データ２１０は、名刺に記載されていた人名、その連絡先たる電話番号および電子メールアドレスなどのデータを含む構造を備える。
【００３０】
上述したデータ構造を構成する各処理データは属性等に応じて分類され、それぞれクラス２５０が定義付けされる。オブジェクト指向プログラミングにおいて、いくつかのオブジェクトに共通する機能や性質（属性）を定義したものをクラスと呼ぶが、このクラスにより同じような機能や性質を持つオブジェクト群をまとめて扱うことが容易になるのである。本実施形態においては処理データについてクラス定義を行うとし、例えば前記スケジュール管理用データ２００から、タスクＩＤを総括するスケジュールタスク、タスクタイトルを総括するタスクタイトル、タスクの担当者を総括する人名の各クラス２５０が定義される。一方、名刺管理用データ２１０においても同様に、人名、電話番号、電子メールアドレスといったクラス２５０が定義できる。各クラス２５０における実際の処理データは、各クラスに属するインスタンスとも言える。
【００３１】
また、本実施形態において各処理データは、例えばアプリケーションプログラムの実行に伴ってユーザインターフェイスに適宜出力され、コンテキストラウンチ処理におけるユーザによる選択対象となる。一般にコンテキストは、オブジェクト指向プログラミングにおける処理中のプロセスの状態や環境のことを指し、本実施形態で言えば、例えばユーザがコンソールのＧＵＩ上でマウスカーソルを操作して、前記処理データのいずれかをクリックした状況がそれにあたる。この処理データの選択事象に応じ、例えばコンテキスト・メニューがポップアップし、ラウンチする先の処理（他のアプリケーションプログラム）の選択をユーザから受付け可能とする。
【００３２】
このように処理データの選択を受けて次に連携するアプリケーションプログラムをラウンチ処理するに際し、参照されるのが前記共通リポジトリデータ１９であり、その実例を図３の処理定義テーブル３００に示す。この処理定義テーブル３００は、前記処理データより定義した各クラスをキー項目とし、これに各クラスに対応可能な処理名データ、その処理を行うアプリケーションプログラムを示す処理内容データ、そして各アプリケーションプログラムが実行するコマンドデータ（或いはリンク記述）などが関係付けされたデータ構造をなしている。サーバ１０はこの処理定義テーブル３００から処理データのクラスに対応した処理一覧を抽出し、ユーザインターフェイスに表示することになる。
【００３３】
図４は本実施形態のコンテキストラウンチ管理方法の実際手順を示す流れ図である。以下、図５〜図８に示した各画面遷移例１〜４に即して処理手順を詳述する。前記サーバ１０は、前記モジュール１１におけるＧＵＩテンプレートをＧＵＩフレームワークに従ってコンソール画面に適用しユーザインターフェイスに出力しているとする。その最初のコンソール画面が図５に示すログイン画面５００である。ユーザはここでログインＩＤおよびパスワードをそれぞれの入力欄５０１、５０２に入力し、ログイン処理を指示する。サーバ１０は、セキュリティモジュール１５において認証作業を実行し、ログイン権限があるものと認識したならば（ｓ４０１：ＹＥＳ）、セッションキーを生成し画面５１０で表示する。一方、認証が出来ない場合には（ｓ４０１：ＮＯ）、処理を終了する。
【００３４】
このログイン処理に際し生成されるセッションキーは、例えばリポジトリデータベース１８などの適宜な記憶手段に格納されるとともに、その有効期間が定めらる。当該期間を経過すると無効となる。よって、この有効期間経過後にコンソールでの操作を受け付けた場合には、ユーザに再認証を要求することになる。ユーザがログイン後、適宜なアプリケーションプログラムを起動させる際には、このセッションキーを当該アプリケーションプログラムに受け渡す（ｓ４０２）。
【００３５】
このセッションキーは、サーバ１０に最初にログインしたユーザの権限を、連携する各アプリケーションプログラムに継続させ、その使用権限を認証する役割を果たす。
【００３６】
図５に示す例では、まずアプリケーションプログラムを起動するのではなく、リソースツリー５２１をコンソール画面５２０に出力している（ｓ４０３）。このリソースツリー５２１は、前記スケジュール管理用データ２００や名刺管理用データ２１０の処理データ単位で互いの階層構造を構成したものであり、各処理データがその名称でもって表示部５２２に出力される。
【００３７】
画面５２０のＧＵＩに表示された各表示部（処理データ）が、ユーザによりクリックされるなどして選択された際、当該処理データに関連付けされたコールバック処理をサーバ１０は実行する（ｓ４０４：処理データ選択、ｓ４０５）。この場合は例えばリソースツリーの表示を担うプログラムからコールバック処理を実行することになろう。一方、ＧＵＩに表示された各表示部をユーザが選択せず、例えば“処理終了”の旨を選択或いは指示したとすれば、処理は終了する。
【００３８】
図示した例は、“スケジュール管理”に属する“タスク１”がクリックされている。サーバ１０が管理するのがＷｅｂアプリケーションプログラムであった場合、「ｈｔｔｐ：／／・・・／ｃａｌｌｂａｃｋ？　ｃｌａｓｓ＝ｓｃｈｅｄｕｌｅｔａｓｋ＃　ｖａｌｕｅ＝ｔａｓｋ１」などいったリンク記述がこの“タスク１”の表示部５２２に埋め込まれている。Ｓｅｒｖｌｅｔモジュール１３がこれに応じてコールバック処理を担うことが想定出来る。
【００３９】
ユーザにより選択された前記処理データ、“タスク１”については、そのクラスである“スケジュールタスク”を前記処理定義テーブル３００に照合し、処理一覧を抽出する（ｓ４０６）。処理定義テーブル３００によると、“スケジュールタスク”なるクラスに対応する処理は、“スケジュール表示”、“スケジュール編集”、“スケジュール共有”の３処理であるから、この処理一覧をユーザインターフェイスに表示する（ｓ４０７）。
【００４０】
この処理一覧を処理定義テーブル３００より抽出した際、該当する処理が１つであったならば（ｓ４０８：ＮＯ）、当該処理に関連付けられた処理内容を前記処理定義テーブル３００より認識する。そしてこの処理内容に応じたアプリケーションプログラムの起動処理を行うことになる。
【００４１】
一方、処理一覧に複数の処理が含まれる場合（ｓ４０８：ＹＥＳ）、コンソール画面６００に抽出した前記処理一覧６０１を出力する（図６参照）。ここで、処理一覧６０１中のある処理がユーザより選択されたならば、当該処理を受付ける（ｓ４０９）。画面６００で選択されたのが“スケジュール表示”なる処理であり、これに例えば「ｈｔｔｐ：／／・・・／ｓｃｈｅｄｕｌｅｒ？ｔａｓｋ＝ｔａｓｋ１＃ｃａｌｌｂａｃｋ＝”ｈｔｔｐ：／／・・・／ｃａｌｌｂａｃｋ”」などといったリンク記述が埋め込まれているならば、前記処理定義テーブル３００における処理名“スケジュール表示”に対応するアプリケーションプログラが“ｓｃｈｅｄｕｌｅｒ”であることを認識する（ｓ４１０）。
【００４２】
そして、上記同様にセッションキーの受渡処理を行って（ｓ４１１）、アプリケーションプログラムの起動を実行する（ｓ４１２）。この“ｓｃｈｅｄｕｌｅｒ”は前記したスケジュール管理プログラムを指している。スケジュール管理プログラムがスケジュール管理用データ２００より処理データを取得して表示処理したのが画面６１０におけるスケジュール内容６１１である。
【００４３】
この画面６１０においては、“担当者名”の“○○太郎”に関して更なるラウンチが可能である旨を示すタグ６１２を付している。表示した処理データのいずれにもラウンチするアプリケーションプログラムが存在しない場合にはこのタグ６１２は付されず、ラウンチの連携は途切れることになる。いずれにせよ、各クラス毎に可能なラウンチ先は前記処理定義テーブル３００において定めれている。アプリケーションプログラム３０が増減したり、クラスの定義内容が変われば、処理定義テーブル３００も自動更新されるとすれば好適である。
【００４４】
ここでの“○○太郎”は“人名”なるクラスに属するものであるから、前記タグ６１２がクリックされた際は（ｓ４１３：ＹＥＳ）、上記同様にコールバック処理を実行し、処理定義テーブル３００より、“人名”のクラスに対応する処理一覧を抽出する。“人名”なるクラスに対応する処理名は“連絡先表示”、及び“関係履歴表示”の２処理である。ここでユーザが“連絡先表示”なる処理を選択したならば、この処理に対応する“名刺管理プログラム”をセッションキーの受渡とともに起動する。この名刺管理プログラムが“○○太郎”について名刺管理用データ２１０から処理データを抽出し、画面表示したのが図７の画面７００である。
【００４５】
この画面７００においては、“電話番号”、“ＦＡＸ”、および“Ｅ−ＭＡＩＬ”のそれぞれに関して更なるラウンチが可能である旨を示すタグ７０２を付している。ここで前記タグ７０２がクリックされた際は、上記同様にコールバック処理を実行し、処理定義テーブル３００より、“電話番号”のクラスに対応する処理一覧７１１を抽出する。“電話番号”なるクラスに対応する処理名は“連絡先確認示”、及び“ダイアル”の２処理である。ここでユーザが“ダイアル”なる処理を選択したならば、この処理に対応する“ダイヤラープログラム”をセッションキーの受渡とともに起動する。ダイヤラープログラムは画面７２０に示すＧＵＩを表示し、実際に“○○太郎”に電話をかける動作を実行する。この画面７２０での処理によりラウンチの継続が完了するならば本実施形態における処理手順は終了する。
【００４６】
一方、図８に示すように名刺管理プログラムの画面８００において、“Ｅ−ＭＡＩＬ”に関して更なるラウンチが可能である旨を示すタグ８０２がクリックされた際は、上記同様にコールバック処理を実行し、処理定義テーブル３００より、“電子メールアドレス”のクラスに対応する処理一覧８１１を抽出する。“電子メールアドレス”なるクラスに対応する処理名は“メール送信”、及び“アドレス修正”の２処理である。ここでユーザが“メール送信”なる処理を選択したならば、この処理に対応する“メールプログラム”をセッションキーの受渡とともに起動する。メールプログラムは画面８２０に示すＧＵＩを表示し、実際に“○○太郎”の“＊＊＠＊＊．ｃｏ．ｊｐ”なるアドレスにメールを送るメール送信用フォーム８２１を用意する。この画面８２０での処理によりラウンチの継続が完了するならば本実施形態における処理手順は終了する。上述したように、コンソール画面におけるＧＵＩ上での処理データ選択に応じて、コンテキストラウンチを順次繰り返すことが可能となる。
【００４７】
なお本実施形態においては、アプリケーションプログラム３０としてＷｅｂアプリケーションを想定した例を記載したが、本発明のコンテキストラウンチ管理方法の適用対象がこれに限定されることはない。上記したようにアプリケーションプログラム３０がストレージサブシステム中の各所に存在してる場合などにも当然対応可能である。この場合は、上述するアプリケーションプログラム３０とサーバ１０とのデータ授受形態を、ストレージサブシステムのハードウェア構成やネットワークプロトコル等に応じて修正し、前記リンク記述等を適宜なコマンドに変更すればよい。
【００４８】
本発明の実施の形態によれば、次の効果を奏する。
本発明のコンテキストラウンチ管理方法によれば、あるアプリケーションプログラムを起動し、このアプリケーションプログラムにおけるＧＵＩ画面上でコンテキストラウンチの処理を行って別のアプリケーションプログラムを直接起動することが可能となる。しかも、ラウンチプログラムや、このコンテキストラウンチに必要なリポジトリデータなどを各アプリケーションプログラム毎に実装させることもなく、アプリケーションプログラムの開発や保守管理にかかる過大な負担を抑制することが可能となる。つまり、アプリケーションプログラムの開発や保守管理の負担を抑制しつつ、各アプリケーションプログラムの相互連携を可能にし、ユーザの目的に応じたアプリケーションプログラムの起動を簡便迅速に可能とするのである。
以上、本発明の実施の形態について、その実施の形態に基づき具体的に説明したが、これに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【００４９】
【発明の効果】
本発明によれば、コンテキストラウンチ管理方法およびシステム、ならびにプログラム、記録媒体を提供可能となる。
【図面の簡単な説明】
【図１】本実施形態のコンテキストラウンチ管理システムを含むネットワーク構成図である。
【図２】本実施形態のスケジュール管理用データおよび名刺管理用データの構成図である。
【図３】本実施形態の処理定義テーブルのデータ構成を示す図である。
【図４】本実施形態のコンテキストラウンチ管理方法の実際手順を示す流れ図である。
【図５】本実施形態のコンテキストラウンチ管理方法における画面遷移例１を示す図である。
【図６】本実施形態のコンテキストラウンチ管理方法における画面遷移例２を示す図である。
【図７】本実施形態のコンテキストラウンチ管理方法における画面遷移例３を示す図である。
【図８】本実施形態のコンテキストラウンチ管理方法における画面遷移例４を示す図である。
【符号の説明】
１０　サーバ、管理マネージャ
１１、１４、１６　モジュール
１２　ＧＵＩテンプレート
１３　Ｓｅｒｖｌｅｔモジュール
１５　セキュリティモジュール
１７　ポリシーデータ
１８　リポジトリデータベース
１９　リポジトリデータ
２０　記憶装置
３０　アプリケーションプログラム
４０　バス、スイッチ、ネットワーク
１００　コンテキストラウンチ管理システム
２００　スケジュール管理用データ、処理データ
２１０　名刺管理用データ、処理データ
２５０　クラス
３００　処理定義テーブル、テーブル
【図１】
2004102453.tif 000003
【図２】
2004102453.tif 000004
【図３】
2004102453.tif 000005
【図４】
2004102453.tif 000006
【図５】
2004102453.tif 000007
【図６】
2004102453.tif 000008
【図７】
2004102453.tif 000009
【図８】
2004102453.tif 000010