JP2003196093A - ソフトウェアコンポーネントを統合するシステム及び方法 - Google Patents

Abstract

(57)【要約】 【課題】 最短の時間でソフトウェアコンポーネントを
容易に統合しカスタマイズする。 【解決手段】 システム内に複数のサービスを含んでお
り、各サービスは、システムに関係付けられたソフトウ
ェアコンポーネントを含んでいて、少なくとも１つの機
能性を提供する。ウェブブラウザのようなユーザーイン
ターフェースは、複数のサービスを表示し、各サービス
は、当該サービスに直接アクセスできるようにするため
に自身に関係付けられたリンクを有している。スクリプ
ティングシェルは、複数のサービスからの第１のサービ
スと第２のサービスの選択に応えて、第１及び第２のサ
ービスを一体的に接続し、第1のサービスの出力が第２
のサービスへの入力として提供されるようなシナリオを
作成する。このシナリオに直接アクセスするために、シ
ナリオにはリンクが関係付けられている。

Description

【発明の詳細な説明】

【０００１】

【技術分野】本発明は、概括的にはソフトウェアサービ
スを提供するためのシステム及び方法に関し、より厳密
にはブラウザのようなユーザーインターフェースを使用
してソフトウェアコンポーネントを統合及びカスタマイ
ズするシステム及び方法に関する。

【０００２】

【発明の背景】ユーザーは、各種機能性を提供する数多
くのソフトウェア製品を購入して使用することができ
る。入手できるソフトウェアが豊富にあるにもかかわら
ず、多くのユーザーは、自分の特定の要件を満たすため
にソフトウェアインストレーションをカスタマイズせね
ばならない。他にも、単一のソフトウェア製品ではどれ
をとっても自分の特定の要件に対する完全なソリューシ
ョンが見つけられず、現存するソフトウェアパッケージ
を幾つか統合して所望の機能性を達成しようとするユー
ザーもいる。ユーザーが幾つかのソフトウェアパッケー
ジを統合できるとしても、その費用は顧客の予算が許す
範囲を超えるかもしれない。また、各ソフトウェア製品
のソフトウェア機能性全てが使えるというわけではな
く、費用面の問題が更に悪化することになる。

【０００３】単一のソフトウェアコンポーネントを購入
するユーザーにしても、頻繁に使用するのはソフトウェ
アパッケージの複数の機能性の中のほんの一部である。
ソフトウェアパッケージが手ごろな値段であれば、この
ことはユーザーにはさしたる問題ではない。しかしなが
ら、ソフトウェアパッケージが（ユーザーの予算を基準
にして）高価であれば、ユーザーはそのパッケージを購
入しようという気にはあまりならないだろう。ベンダー
の中には、この問題に気づいて、共用ベースでソフトウ
ェアを提供するものもいる。例えば、一揃いのソフトウ
ェアパッケージをＩｎｔｅｒｎｅｔなどのネットワーク
上にあるサーバに搭載して、ユーザーがそのパッケージ
にアクセスするというようなものである。ユーザーは、
使用したソフトウェア機能性の数とサーバにログインし
た時間に基づいて料金を請求されることになる。

【０００４】知識管理の顧客要件は、とりわけ、しばし
ば現存のソフトウェパッケージに対応しないことがあ
る。知識管理は、そもそもその性質上、要件が流動的で
ある。単一のソフトウェアパッケージで知識管理の顧客
要件を満たすことは殆どまれであるし、たとえ要件を満
たしたとしても、ずっと満たし続けるわけではない。幾
つかのコンポーネントを統合して所望のソリューション
に対応する専用のソリューションを作り上げることが、
知識管理顧客にとって唯一経済的に実行可能なやり方で
ある。

【０００５】ウェブポータルデザイナーにとって、自分
達のポータル上に新しく最新の機能性を維持すること
は、最も難しいことの１つである。最終的なユーザーの
視点から見れば、ポータルはしばしば何ヶ月も更新され
ていない限定された数の機能を提供するという意味で
は、静的である。データの更新は、比較的直進型であ
る。しかしながら、ソフトウェアコンポーネントに対す
る最新の改訂（プラグインなど）や、起こりつつある新
規なもの（例えば、マルチメディア、セキュリティ、暗
号、請求書式の作成など）に遅れずについていくことは
しばしばやっかいである。

【０００６】ユーザーのためにこのような問題を解消し
ようとする試みとして、幾つかのシステムが実施されて
いる。例えば、ヒューレット・パッカード社のｅ―スピ
ークは、ＣＯＲＢＡ（オブジェクト管理グループとして
知られている産業共同体により開発された共通オブジェ
クト・リクエスト・ブローカー・アーキテクチャ）を使
った分散型コンポーネントアーキテクチャの１つの具体
例である。ＣＯＲＢＡは、オブジェクトと呼ばれる複数
のプログラムが、どんなプログラム言語で書かれている
か、又はどんなオペレーティングシステム上で起動して
いるかには関係なく、互いに通信し合えるようにするア
ーキテクチャである。ｅ−スピークは、サービスの登録
と発見、そして専念しているクライアントと編集された
ＸＭＬ文書を介しての対話のための、ブラウザからのウ
ェブアクセスを提供する。登録されたサービスにはウェ
ブアクセスを通じて直接アクセスすることはできず、登
録されたサーブレットを通すことになる。ｅ−スピーク
は、記述／発見言語をユーザーレベルで考慮して、ユー
ザーにサービスを発見するための手段を提供する。ｅ−
スピークは、更に、サーブレットを使ってしか、即ちｈ
ｔｔｐインターフェースでしかアクセスできない外部サ
ービスの手軽なサービス登録も提供する。

【０００７】もう１つのシステムは、企業内の出力設備
の集合体に向けた出力ジョブの実行を管理するソリュー
ションを構築するための、ゼロックスによる内部製品開
発プロジェクトである「エンタープライズ・アウトプッ
ト・マネジメント（ＥＯＭ）ソリューション・プラット
フォーム」である。出力設備の集合体としては、例え
ば、ローカルプリンタ、ビューワ、ウェブパブリッシ
ャ、アーカイブ、ファックス機、ＣＤ−ＲＯＭライタ、
ＥＤＩドライバ、又は遠隔印刷実行依頼サービス等をど
のように組み合わせたものでもよい。ＥＯＭソリューシ
ョン・プラットフォームの主要な要素は、ＤＳＤＩＦ
（ドキュメント・システムズ・ドメイン・インテグレー
ション・フレームワーク）と呼ばれるインテグレーショ
ン・フレームワークである。フレームワークは、オブジ
ェクト指向型システム内では、多数の関連する問題に対
するソリューションの抽象設計を具体化するクラスのセ
ットである。ＤＳＤＩＦは、ＥＯＭソリューション・プ
ラットフォームに属するコンポーネントとサービスが、
互いに統合されて全体として解を構成できるようにして
いる。これにより、サービスとコンポーネントの共通の
セットから、実施労力を最小限にしつつ、数多くのカス
タマイズされたソリューションが入手できるようにな
る。

【０００８】最短の時間でソフトウェアコンポーネント
を容易に統合しカスタマイズするシステム及び方法が求
められている。また、ブラウザのような簡便なユーザー
インターフェースを採用するシステム及び方法も求めら
れている。更には、一式のソフトウェアコンポーネント
に関してユーザー自身のシナリオ（scenario）を実現す
る能力をユーザーに提供するシステム及び方法が求めら
れている。

【０００９】

【発明の要約】本発明による、システム内においてサー
ビスを統合するためのシステムは、複数のサービスを備
え、各サービスは当該システムに関係付けられたソフト
ウェアコンポーネントを備え、少なくとも１つの機能性
を提供する。ウェブブラウザのようなユーザーインター
フェースは複数のサービスを表示し、各サービスは当該
サービスに直接アクセスするためのそのサービスに関係
付けられたリンクを有している。スクリプティング・シ
ェルは、複数のサービスからの第１サービス及び第２サ
ービスの選択に応えて、第１及び第２サービスを接続し
て１つにし、第１サービスからの出力が第２サービスへ
の入力として提供されるようなシナリオを作る。リンク
はこのシナリオに直接アクセスするためのシナリオに関
係付けられている。本発明による、システム内のサービ
スを統合する方法は、ユーザーインターフェースにおい
て複数のサービスを提供する段階と、複数のサービスか
ら第１のサービスを選択する段階と、複数のサービスか
ら第２のサービスを選択する段階と、第１サービスから
の出力が第２サービスへの入力として提供されるような
シナリオを作るために第１サービスと第２サービスを一
体に接続する段階と、を含んでいる。

【００１０】シナリオは、サービスを何個、接続又は連
鎖して構成してもよい。ある実施例では、サービスは、
１つのサービスの出力が次のサービス入力に当てられる
ように連鎖されている。例えば、あるシナリオにサービ
スＡとＢとが含まれている場合、Ａの出力はＢの入力に
（或いは、Ｂの入力は更に別の入力を含んでいてもよ
い）与えられる。ユーザーは、第３のサービスをシナリ
オに加えたい場合、例えばＣの入力として、Ａの出力、
Ｂの出力、又はＡとＢの出力、の何れを提供するかを選
択することになる。ユーザーが最終的なシナリオの構成
に満足すると、システムはそのシナリオに直接アクセス
できるリンクを設定することができる。こうして、この
シナリオはここで入力及び出力を備えた「単一の」サー
ビス、即ちブラックボックスとなる。

【００１１】本発明の別の態様では、システム内のサー
ビスにアクセスする方法は、各サービスが当該システム
に関係付けられたソフトウェアコンポーネントを備え少
なくとも１つの機能性を提供するようになっている、複
数のサービスを提供する段階と、各サービスが直接アク
セスするためのブラウザに関係付けられたｈｔｔｐリン
クを有している複数のサービスをブラウザに表示する段
階と、複数のサービスから１つのサービスを選択する段
階と、ユーザーインターフェースからそのサービスにア
クセスする段階と、を含んでいる。

【００１２】ユーザーがシステム内の数多くのサービス
から選択する際にこれを支援するため、フィルタ制御を
使用して、ユーザーが、各サービスに対して定義された
条件に言及する複数の選択可能な基準の中から選択でき
るようにしてもよい。フィルタ制御の少なくとも１つの
基準が選択されたことに応えて、フィルタ制御は何らか
の結果を生成し、ユーザーインターフェースにその結果
が表示されるが、この結果には複数のサービスのサブセ
ットが含まれている。ユーザーは、次に、スクリプティ
ング・シェルを使って、結果から選択したものを１つに
接続することができる。

【００１３】本システムは、サービスを見つけ出し、選
択したサービスを実験し、シナリオ（接続して１つにさ
れたサービスのセット）を設計し、シナリオを検査して
保存するために使用することができる。サービスを統合
するシステム及び方法は、ソフトウェア技術のためのデ
ィスプレイ・シェルフとして使用することができ、ユー
ザーが、個々のサービスの組み合わせを発見し、テスト
し、実証できるようにする。このシステム及び方法は、
ソフトウェアを対話式に設計するためのツールとして使
用することもでき、即ち、オンデマンドでサービスを構
築する動的ポータルとして使用できるということであ
る。

【００１４】ユーザーインターフェースはウェブブラウ
ザでよいが、別のインターフェースも使用できる。ブラ
ウザは、一般的には、個人がハイパーテキストを読める
ようにし、ノード（又はページ）の内容を見たり１つの
ノードから別のノードへナビゲートする幾つかの手段を
提供するプログラムである。ユーザーインターフェース
がウェブブラウザである場合、システムは、サービスを
選択しどのデータを入力及び出力として考えるべきかを
表示する直感的に理解できる方法を提供する。このシス
テムは、ソフトウェアコンポーネントであるサービス及
び文書を取り込み、それらをシステムに登録する。ウェ
ブブラウザは、当該サービスをウェブページに表示す
る。サービスは、遠隔的に配置して、ｈｔｔｐインター
フェースを介して呼び出すようにしてもよい。システム
は、サービス同士の間でデータを転送して、サービスの
セットに関係付けられたシナリオの創作、テスト、及び
検査を行えるようにしている。シナリオは、幾つかのサ
ービスを包含した、カスタマイズされたソフトウェアア
プリケーションと捉えることができる。

【００１５】サービスは、例えばＪａｖａ（登録商標）
又はＪａｖａ（登録商標）インターフェースなど、何れ
の記述言語で書いてもよい。Ｊａｖａ（登録商標）のよ
うな言語を使用すれば、サービスの文書化及び登録は比
較的直進型となり、サービスの追加に要する労力は、概
ねサービスを文書化しサービス呼び出しの主機能を書き
込むことだけで済む。更に、サービスの出力は構造化さ
れ、即ちストリングとして扱われることになる。例えば
「ウィザード」は「Ｋａｓｂａ」として知られている例
示的システム用に開発された。Ｋａｓｂａウィザードで
は、ユーザーは、一連のプロンプトに従って要求される
情報を入力することにより、１時間以内でＫａｓｂａシ
ステムに新しいシナリオをプラグインできるようになっ
ている。

【００１６】サービスを統合する本システム及び方法
は、多種多様な用途に使用できる。例えば、ユーザー
は、現存するサービスを例えばウェブポータル上でまと
め上げて（組み立てて）自身のサービスを構築すること
ができる。サービスを統合する本システム及び方法は、
ソフトウェア開発者が、幾つかのソフトウェアコンポー
ネントに関わるシナリオを迅速に設計し実施するために
使用することもできる。ソリューションデザイナー／イ
ンテグレータは、コンポーネントの正しいシーケンスを
見つけて、所与の状況にあわせた専用のシナリオ、例え
ば所与のプレゼンテーションにあわせてカスタマイズさ
れたシナリオを迅速に設計するに当たり、１つのコンポ
ーネントを別のものと置き換えることによって目標コン
テキスト内のコンポーネントを評価し、目標コンテキス
ト内の新しいコンポーネントをテストし、コンポーネン
ト間のデータの転送を理解し、交換されたデータの量に
関する問題を予知し、必要なデータが入手不能な場所を
識別するために、コンポーネントを統合する本システム
及び方法を使用することができる。

【００１７】サービスを統合する本システム及び方法
は、知識管理要件の解決に使うこともできる。知識管理
の分野では、データは構造化とタイプがお粗末（殆どの
場合、データはストリングとして表現されている）で、
しばしばデータは非常に不均質（性質の非常に異なるエ
ンティティの操作を要する）であり、データの変換は一
意的ではなくコンテキストによって決まる。知識管理ユ
ーザーは、データを選択して組み合わせることによっ
て、知識データの分析で役目を果たす。サービスを統合
する本システム及び方法は、ユーザーに、知識データの
選択及び処理を特定し、容易に実施する機会を与える。

【００１８】サービスを統合する本システム及び方法
は、シナリオの作成を迅速且つ容易にする。シナリオデ
ザイナーは、足りない及び／又は重要なコンポーネント
を素早く識別することができる。この態様は、幾つかの
コンポーネントの価値は他のコンポーネントと組み合わ
せて使用した場合にのみ判定することができ、即ち多く
のソフトウェアコンポーネントは分離して評価すること
はできないことがしばしばなので、デザイナーにとって
役に立つ。サービスを統合する本システム及び方法を使
えば、ユーザーは（おそらく、コンポーネントをシステ
ムにプラグするに十分な限定された評価ライセンスを購
入することにより）幾つかのシナリオでソフトウェアコ
ンポーネントが作動するのを見た後、そのソフトウェア
コンポーネントの購入を決断することができる。このよ
うにして、最終的なユーザーは、決定を下す前にコンポ
ーネントを評価する機会を持てるようになるので、ユー
ザーの事前投資は限定されたものとなる。

【００１９】

【実施例の詳細な説明】本発明は数多くの環境で実行す
ることができる。便宜上、本発明を知識管理の分野で実
施する場合に関連付けて具体的に説明する。図１では、
サービスを統合するためのシステムのブロック図を、参
照番号１００で示している。システム１００は、複数の
サービス１０、１２、１４、フレームワーク２０、ｈｔ
ｔｐゲートウェイ４０、及びスクリプティングシェル５
０を含んでいる。サービス１００は、バス３０を使って
ネットワークを通して通信する。システム１００には複
数のサービス１０、１２、１４が含まれている。サービ
ス１０はａｓｋＯｎｃｅと呼ばれるサーチエンジンプロ
ダクト、サービス１２はＤｏｃｕｓｈａｒｅデータベー
スアカウント、そしてサービス１４はレコメンダサービ
スである。各サービスはバス３０（一例を挙げるとＪｉ
ｎｉバス３０）にフレームワーク２０を使って接続又は
プラグされている。

【００２０】システム１００は、ネットワーク（インタ
ーネットつまりＩｎｔｅｒｎｅｔ又はイントラネットで
もよい）に接続するためのインフラを現存のプラットフ
ォーム（又はバス）に依存している。本実施例ではＪｉ
ｎｉを選択しているが、他のバス又はプラットフォーム
を使ってサービスにプラグインすることもできる。バス
３０の上で、ゲートウェイ４０はサービス１０、１２、
１４の発見と起動、及びフレームワーク２０に準拠する
サービスとの対話をサポートする。ゲートウェイ４０
は、ユーザーが個々のサービスを直接起動できるように
している。スクリプティング・シェル５０は、シナリオ
執筆を行い、即ちあるユーザー入力（スクリプト、記
憶、再生、共有、テンプレートとしての発行）に従って
サービスを統合してシナリオにする。サービス１０、１
２、１４は、同一バス３０上で別のフレームワーク２５
を使って統合することができ、アプリケーション６０
は、フレームワーク２０か又は現存する別のフレームワ
ーク２５の何れかに頼んで、システム１００の外の同じ
サービスに関わることができる。

【００２１】本実施例中、バス３０はＪｉｎｉバス（ネ
ットワーク上でプリンタやディスクドライブなどのデバ
イスの接続と共用を単純化したＳｕｎＭｉｃｒｏｓｙｓ
ｔｅｍｓ社のソフトウェア）であり、ソフトウェアコン
ポーネントはＪａｖａ（登録商標）で書かれているか又
はＪａｖａ（登録商標）インターフェースを有してい
る。また、本実施例では、ｈｔｔｐゲートウェイ４０
が、ユーザーインターフェース（ここではウェブブラウ
ザ）からソフトウェアコンポーネント１０、１２、１４
への直行パスを提供している。シェル５０とフレームワ
ーク２０はＪａｖａ（登録商標）で書かれている。Ｊａ
ｖａ（登録商標）内省機構は、ソフトウェアコンポーネ
ント同士の入出力パラメータを理解するための使いやす
い方法を提供し、１つのコンポーネントの出力を別のコ
ンポーネントの入力に変換するためのサポートを提供す
る。

【００２２】システム１００は、インターネットつまり
Ｉｎｔｅｒｎｅｔやイントラネットなど何れのネットワ
ーク上にも実装できる。仮に、例えば、Ｉｎｔｅｒｎｅ
ｔ８０に実装された場合、ユーザーは、ワークステーシ
ョン又はパーソナルコンピュータ９０を介してウェブブ
ラウザのようなユーザーインターフェースで、システム
１００にアクセス（図１７参照）することになる。シス
テム１００にアクセスすると、利用可能なサービスのセ
ットが表示される。図２は、システム１００内で統合に
利用可能なサービスのグループを表示している。ウェブ
ブラウザでは、ユーザーはページをロードして登録され
たサービス全てを見ることができる。表示される利用可
能なサービスとしては、メールセンダ、コンピュータ／
Ｚｄｎｅｔのサーチエンジン、一般／オープンディレク
トリのサーチエンジン、ウェブアシスタント、戦略付き
用語抽出、知識ポンプコミュニティ、辞書、ＮＲａｎｋ
サーチ、各種Ｋａｓｂａ機能、サーチエンジンｏｎ／ｆ
ｒａｎｃｅ／ＡｌｌｏＣｉｎｅ、Ｈｔｍｌ文書エディ
タ、ｄｏｃｕｓｈａｒｅ．ｇｒｅｎｏｂｌｅ．ｘｒｃ
ｅ．ｘｅｒｏｘ．ｃｏｍのＤｏｃｕｓｈａｒｅ、文書言
語識別子、イメージコンポーザ、イメージ抽出、文書分
類、Ｐｄｆコンバータ、サーチエンジンｏｎ／ｇｅｎｅ
ｒａｌ／Ｇｏｏｇｌｅ、ドキュメント・ソウル・ビジュ
アライザ、ｌａｕｔａｒｅｔ．ｇｒｅｎｏｂｌｅ．ｘｒ
ｃｅ．ｘｅｒｏｘ．ｃｏｍ：１７０７のＤｏｃｕＳｈａ
ｒｅ、用語抽出、知識プロファイリング、知識プロファ
イルリポジトリ、及びドキュメントサマライザが挙げら
れる。各サービスはそれに直接アクセスするためのリン
クを保有している。例えば、ユーザーが「メールセン
ダ」へのリンクを「クリック」すると、メールセンダの
機能、即ち制御パネル（図４）、フィルタ制御（図
５）、サービス特性（図６）、及びサービスパラメータ
記述（図７）が表示されることになる。

【００２３】ユーザーが個々のサービスに直接アクセス
したくないのであれば、ユーザーは先に進んで機能性の
ルックアップ、発見、及びフィルタリングを使うことも
できる。ウェブページには、フィルタ制御２００（図３
参照）も表示される。フィルタ制御２００は、システム
１００のオペレーションには必要ないが、多様な機能性
を提供する膨大な数のサービスの中からユーザーが選択
を行う際に役に立つ特性である。フィルタ制御２００
は、ユーザーが統合を目指してサービスを選択する過程
で使える幾つかのフィルタを保有している。フィルタ制
御２００は、ロケータ２１０、制約２２０、セレクタ２
３０、２４０、２５０を含んでおり、この中から、ユー
ザーはキーワードを使って選択する。例えば、ユーザー
は、ロケータ２１０から「ＬＡＮ上に発見される第１の
ロケータ」や「ＬＡＮ上の全ロケータ」又はＬＡＮ上の
特定の識別位置の１つといった選択を行う。制約２２０
からは、ユーザーは特定の名前、ドメイン、バージョ
ン、製作者等を選択する。あるいは、ユーザーは制約２
２０を空白のままにして全てについて探索してもよい。
セレクタ２３０、２４０、２５０から、ユーザーは、ド
メイン、場所、バージョン、ベンダ、製作者、モデル、
名前、通し番号をプルダウンメニューから選択する。ユ
ーザーは、自分が選ぶもののキーワードをボックス２３
２、２４２、２５２に入力する。

【００２４】ユーザーがフィルタ制御２００を完了した
後、ユーザーが選択したフィルタサービス２６０及びシ
ステムはフィルタリングを行い制約を課して結果を出
す。その結果、通常は１つ又は複数のサービスが提示さ
れるが、選択されたフィルタリング基準によってはセッ
トが全く無しということもありうる。とにかく空ではな
く何らかの結果が出ると、ユーザーは結果として出てき
たサービスを実験して、文書化された状態で何らかの入
力を送信し、サービスがユーザーの要求に対応している
ことを検証する。あるいは、ユーザーはこの結果を使っ
てカスタマイズされたシナリオを創作開始してもよい。

【００２５】例えば、ユーザーには検討して要約する必
要のある一連の文書、即ちクライアントに書いて送るべ
き報告書、があると仮定する。単一のサービスでこれら
の機能全てを提供することはできないので、ユーザーは
システム１００を使ってこれらの機能全てを行うシナリ
オを創作せねばならない。図２では、ユーザーは、先ず
ドキュメントサマライザを選択し、次にリンクをクリッ
クすることによりこれにアクセスする。するとドキュメ
ントサマライザの制御パネル３００（図１２参照）がユ
ーザーに表示される。ユーザーはコマンドボックス３０
２の「０」を選択してリクエストを送る。ボックス３０
４で、ユーザーは要約する記事の言語を選択するが、デ
フォルトは英語で、フランス語、スペイン語、ドイツ
語、イタリア語、ポルトガル語も選択できる。ボックス
３０６、３０８、３１０は、ユーザーが要約する文書又
はテキストを入力できるようにするもので、ボックス３
０６はストリングテキスト用、ボックス３０８は文書の
ＵＲＬ用、ボックス３１０は文書がファイルの場合のフ
ァイル場所（ユーザーのパーソナルコンピュータ又はワ
ークステーションのあるディレクトリに記憶されている
など）用である。ユーザーの気が変わった場合には、ボ
ックス３２０の「結果消去」を選択すると入力された全
の値は空になる。尚、制御パネル３００には、プルダウ
ンメニュー３１２（言語）、３１４（テキスト）、３１
６（ＵＲＬ）、及び３１８（ファイル）も含まれてい
る。プルダウンメニューは前段階のサービスからの出力
を表示するのに使用される。例えば、ユーザーが「サー
チエンジンｏｎ／ｇｅｎｅｒａｌ／Ｇｏｏｇｌｅ」を第
１のサービスとして選択していたら、システムは適合す
るプルダウンメニューのサーチ結果（Ｇｏｏｇｌｅの出
力）を表示するはずである。

【００２６】要約サービスは、自身のフィルタ制御３５
０（図３１参照）を保有しており、ここからユーザーは
ドキュメントサマライザの機能をフィルタリング及び制
約することができる。フィルタ制御３５０は同様のボッ
クスを持っており、ここからユーザーは要約サービス、
即ちロケータ３５２、制約３５４、セレクタ３５６、３
５８、３６０のフィルタリングと制約を行う。所望のフ
ィルタリングか完了すると、ユーザーはフィルタサービ
ス３６２を選択する。図１４はドキュメントサマライザ
の具体的なサービス特性を掲載しており、図１５はドキ
ュメントサマライザのサービスパラメータ記述を掲載し
ている。

【００２７】ユーザーは、ドキュメントサマライザサー
ビスに関する自信の選択に満足すると、要約する文書の
形態で入力を提供する。ユーザーが文書をドキュメント
サマライザに入力し終わると、各文書毎に１つの要約文
書が出力される。本システムのシナリオ創作の一環とし
て、システム１００は、自動的に、直近に選択されたサ
ービスの入力として前のサービスの出力を提案する。な
お、前のサービスがシナリオ内に複数ある場合には、前
のどのサービスからのどの出力であっても今回のサービ
スへの入力として選択することができる。ユーザーは、
この入力を使っても、自身の入力入れても、両方を行っ
てもよい。ユーザーは、ブラウザ内を行き来して、各ス
テップが１つのサービスの呼び出しに対応するステップ
バイステップの形態でアクセスする。

【００２８】ユーザーが幾つかの文書をドキュメントサ
マライザに投入し、ドキュメントサマライザはそれぞれ
の段落要約を戻すものとする。ユーザーは戻された要約
内の幾つかの単語の定義をチェックしたいものとする。
ここで、ユーザーはそれらの単語を辞書サービスに投入
する。システム１００は（デフォルト設定により）ドキ
ュメントサマライザサービスの出力を取り上げ、それを
辞書サービスの入力に接続するが、この場合、ユーザー
は辞書内の２〜３の単語しか調べたくないであろう。辞
書サービスが選択されると、制御パネル４００（図８参
照）及びフィルタ制御４５０（図９参照）がユーザーに
表示される。

【００２９】辞書制御パネル４００は、コマンドライン
４０２を含んでおり、その中には２つのオプション、即
ち、辞書内のテキストの各単語を調べる場合の「０」
と、テキスト内の各単語を翻訳に向けてハイパーリンク
する場合の「１」が含まれている。出力フォーマット４
０４は、ユーザーが出力としてテキスト又はｈｔｍｌを
選択できるようにしている。テキストは、ボックス４０
６を使ってテキスト経由で、又はボックス４０８を使っ
てＵＲＬ経由で入力される。ボックス４１０は、ユーザ
ーが出力の言語を選択できるようにする。ボックス４１
２は、ユーザーが入力言語を指定できるようにする。ボ
ックス４２０は、ユーザーが結果を消去してやり直せる
ようにする。なお、制御パネル４００は、要約サービス
の出力を直接入力として提供するためのプルダウンメニ
ューも含んでいる。

【００３０】フィルタ制御４５０は、同様に、ロケータ
４５２、制約４５４、セレクタ４５６、４５８、４６０
を保有している。フィルタ制御４５０は、辞書を選択す
るために使用するものである。フィルタサービス４６２
は、辞書サービスを定義に戻らせる。図１０は、辞書サ
ービス用のサービスパラメータを表示しており、図１１
は、辞書サービス用のサービス特性を表示している。

【００３１】ユーザーは、定義をチェックし要約を完成
させてしまうと、自分の報告書を書くことになる。これ
は、オフラインで行ってもよいし、又は（もし、設けら
れている場合には）エディタサービスを使って行っても
よい。本システムでは、ＨＴＭＬドキュメントエディタ
が唯一のエディタである。ユーザーの要件に該当するの
であれば、ユーザーはこのサービスを呼び出して、報告
書を作成し、要約及び定義を添付する。システム１００
は、ドキュメントサマライザと辞書の出力を、ＨＴＭＬ
ドキュメントエディタの入力、並びにユーザーが直接提
供した入力に接続する。次に、ユーザーは報告書を遠方
の同僚に送ろうと決心する。ユーザーはメールセンダを
呼び出す。

【００３２】システム１００は、ＨＴＭＬドキュメント
エディタの出力を取り上げ、それをメールセンダの添付
欄に接続する。メールセンダを選択すると、制御パネル
５００（図４参照）及びフィルタ制御５５０（図５参
照）が表示される。制御パネル５００には、電子メール
を送信するためのコマンドライン５０２、メッセージの
テキストを入力するためのボックス５０４、ブラインド
コピーの受信者がいればそれを掲載するためのボックス
５０６、電子メールの件名を掲載するためのボックス５
０８、メッセージの下書きを掲載するためのボックス５
１０、電子メールの「宛先」受信者を入力するためのボ
ックス５１２、挿入添付用のボックス５１４、コピー受
信者を掲載するためのボックス１５６、メッセージ本文
を掲載するためのボックス５１８、及び電子メールの送
信者を掲載するためのボックス５２０が含まれている。
ボックス５２２は全入力データを消去する。フィルタ制
御５５０は、ロケータ５５２、制約５５４、セレクタ５
５３、５５８、５６０を含んでいる。図６はメールセン
ダのサービス特性を掲載し、図７はメールセンダのサー
ビスパラメータ記述を掲載している。

【００３３】ユーザーは、ドキュメントサマライザ、辞
書、ＨＴＭＬドキュメントエディタ及びメールセンダを
ユーザーの基準に従って全て接続し１つにした組み合わ
せであるシナリオを創作したことになる。図１６に示す
ように、出来上がったシナリオ２８０は、ドキュメント
サマライザサービス２８２、辞書サービス２８４、ＨＴ
ＭＬドキュメントエディタサービス２８６、及びメール
センダサービス３８８を含んでいる。このシナリオで
は、ユーザーは、随意的に３つの入力、即ち、要約する
文書を入力するための入力２８９、辞書に単語を入力す
るための入力２９０、ＨＴＭＬドキュメントエディタに
テキストを入力するための入力２９１、を選択してい
る。辞書２８４は、ユーザー入力２９０の他に、ドキュ
メントサマライザ２８２とＨＴＭＬドキュメントエディ
タ２８６の出力から入力を直接受け取るように構成され
ている。ＨＴＭＬドキュメントエディタ２８６は、ユー
ザー入力２９１の他に、ドキュメントサマライザ２８２
と辞書２８４の出力から入力を受け取るように構成され
ている。シナリオ２８０では、メールセンダサービスへ
提供される唯一の入力は、ＨＴＭＬドキュメントエディ
タ２８６の出力である。しかしながら、ユーザーは、後
日戻ってシナリオ２８０を修正し、各種サービスへ入力
を追加し、又は不要なものを取り除くこともできる。シ
ナリオ２８０は４つの出力、即ち、ＨＴＭＬドキュメン
トエディタ２８６からの出力２９２、ドキュメントサマ
ライザ２８２からの出力２９４、辞書２８４からの出力
２９５、メールセンダ２８８からの出力２９６を有して
いる。ユーザーは、シナリオ２８８に満足した場合、そ
れにしおりをはさむ。しおりの再ローディングは、全て
のサービスの行の実行を例示する。

【００３４】幾つかのコンポーネントを包含するシナリ
オを設計し、実施し、テストすることは、目下のとこ
ろ、非常に時間を消費する行為である。必然的に、ソフ
トウェアエンジニアは、プロジェクトがそれほど壮大で
ない場合にはこれらの段階にかかる時間を短縮しようと
しがちであるが、これには、慌てて決定を下したために
良好でないソリューションをフリーズする危険性が幾ら
かと、最終的に顧客の要件を満足しない危険がしばしば
伴う。また別の帰着は投資に値するだけの壮大なプロジ
ェクトである必要性であり、それは、そうでなければこ
れら予備的な段階全ての費用が支払われなくなり兼ねな
いからである。本発明のシステム及び方法を使えば、ソ
フトウェアエンジニア（及び、最終的なユーザーであっ
ても）は、僅か数分でサービスを発見し、実験し、リン
クすることができるようになる。満足できるソリューシ
ョンが見つかるまでシナリオを変えることはしごく当た
り前のことになる。１つのコンポーネントを別のコンポ
ーネントに変えることは、必要に応じ何度行ってもよ
い。ソフトウェアコンポーネントを簡単にシステムに加
えることができる。実際に、ユーザーは付加的なコンポ
ーネントを加えることを提案するであろう。あるいは、
ユーザーが創作したシナリオの幾つかをシステムに加え
てもよい。

【００３５】利用可能なサービスを発見するために本シ
ステムを使用するには幾つかやり方がある。例えば、ユ
ーザーは、サービスが幾つかの観点によって分類されて
いる一種の森をブラウズすると、同じサービスでも別の
パスで到達できることが分かる。このユーザーは、特定
のサービスを探索するために、単一のキーワード又はキ
ーワードのセットを提供することができる。そうする
と、これらのキーワードと互換性のあるサービス全てが
一覧掲載される。これらのサービスに互換性のあること
が分かるとすぐに、これらのサービスをテストするイン
ターフェースがユーザーに提供される。このインターフ
ェースは、サービスが互いに近似している場合、ユーザ
ーが幾つかのサービスを同時に呼び出せるようにするも
のである。

【００３６】この場合、インターフェースは各インター
フェースの共通部分であり、各サービスに欠かせないパ
ラメータ全部を範囲に入れるとすぐに提示される。例え
ば、異なるソースに関して並行的にいくつかの探索を実
行する場合、キーワードとして「サーチ：探索」を入力
する。これにより幾つかのラッパが、ユーザーがその全
部を呼び出せるような形態で自動的に選択される。基本
的には、探索に欠かせないパラメータだけが、ユーザー
が探索したいストリングであり、それはその形態で必要
なパラメータであるはずである。サービスの記述が厳密
になればなるほど、準拠するサービスのセットは限られ
ることとなり、ユーザーは、選択されたサービスの全て
に使用できるパラメータのより大きなセットを指定でき
るようになる。ユーザーが単一のサービスとの対話を望
んでいると仮定する。ユーザーは当該サービスに利用で
きる全てのパラメータを指定できる。次に、このユーザ
ーが、同一のパラメータを使って２つのサービスとの対
話を望んでいると仮定しよう。ユーザーは２つのサービ
スの両方に共通するパラメータだけを指定すればよい。
同じ例で、仮にユーザーがＧｏｏｇｌｅに対する探索を
禁止したとしても、ユーザーは、Ｇｏｏｇｌｅ、Ａｌｔ
ａＶｉｓｔａ及びＥｘｃｉｔｅを同時に探索するより
も、より多くのパラメータにアクセスする。

【００３７】本発明のある態様は、登録されたシナリオ
を共有し再生する能力である。シナリオは、サービスの
統合されたセットである。システム管理者がそのシナリ
オをシステム上に登録すれば、他のユーザーがこの登録
されたシナリオを再生することができる。別のやり方と
しては、システム管理者は、ユーザー自身が後で使用す
る場合に限ってユーザーのシナリオ登録を許可するよう
にしてもよい。ユーザーがシナリオに満足であれば、ユ
ーザーはこれを保存することができる。登録されたシナ
リオは２つのモードで再生することができ、即ち、第１
のモードはワンショットで実行されるものであり、第２
のモードはステップバイステップモードである。第２の
モードを使えば、ユーザーは、ユーザーインターフェー
ス内の前進後退ボタンをクリックしながら、シナリオを
分解することができる。この技術を使えば、例で学習し
ながらシナリオをデバッグすることができる。これは、
ユーザーがシナリオの作者でない場合、特によく当ては
まる。

【００３８】デバッグモードを使えば、既存のシナリオ
を容易に発展させ拡張することができる。このシステム
は数人のユーザーで使うことができ、各人が自身の能力
に見合った部分を著作し、合体して共同製作の作品を作
ることができる。

【００３９】本システムの別の態様は、複合的なシナリ
オが構築できることである。１つのサービスを別のサー
ビスに組み込むことができるように、１つのシナリオを
別のシナリオに組み込んで、非常に複雑なシナリオを合
成することができる。シナリオのライブラリを開発して
オンデマンドで使うこともできる。

【００４０】複合シナリオの構築をやり易くするため
に、シナリオが記憶され管理される構造化されたレポジ
トリをシステムに組み込んでもよい。この構造化された
レポジトリを、実践とシナリオのメモリを収集するため
の場所として使用することもでき、誰かに新しいシナリ
オを設計して実施する必要ができたら、その都度これを
調査するようにしてもよい。レコメンダサービスをこの
システムと組み合わせて（レコメンダサービスが提供さ
れているサービスの１つでない場合）ユーザーのコミュ
ニティにコメント及び推奨シナリオを提出することもで
きる。これは、ソリューションデザイナー又はソフトウ
ェアインテグレータのグループにとっては役に立つもの
で、それは、前に具現化された最高のものを捕捉しその
上に構築するというのはしばしば難しいからである。

【００４１】本発明のある態様は、サービスを統合する
システム及び方法が、サービスの発見、統合、及びその
シナリオへの連鎖を支援し、そしてシナリオの実行を支
援して包括的な動作を実証することである。この機能性
は、２層構造又は１層構造として提供される。例えば、
シナリオビルダは第１段階、即ち、サービス発見及びシ
ナリオ執筆に取り組み、そして「プレーヤ」はシナリオ
実行に取り組むことになる。

【００４２】本システムを２層構造で実施することによ
り、タイプの異なるユーザーのシステムの異なる要件に
取り組めるようになる。例えば、２層コンセプトを使え
ば、ソフトウェアインテグレータは、ビルダを使って、
最終ユーザーの要件に合致するシナリオを、それを検査
することになる顧客に（「プレーヤ」のフォームで）提
示する前に、設計することができる。この「プレーヤ」
ユーザーインターフェースは、簡略化し磨くことができ
ると同時に、ユーザーパラメータを収集する可能性を維
持し、考慮されたシナリオ次第では対話オプションも提
供できるようになる。情報探索を例に取れば、ユーザー
は探索すべき用語を示さねばならない。次に、フォーム
を使って、ユーザーが再処理及び例えば報告文書に挿入
するために要約を望む探索結果に対応する幾つかのボッ
クスをチェックすることができる。

【００４３】フレームワーク２０は、システムの一部と
するためにサービスから要求されるもの、即ちサービス
記述言語、内省、対話、しか含んでいない。既存のソフ
トウェアフレームワークを、本発明のシステムで拡張す
ることもできる。例えば、ｅ−スピーク、ＵＤＤＩ（ユ
ニバーサル・ディスクリプション、ディスカバリ及びイ
ンテグレーション。従来の電話帳のイエロー及びホワイ
トページ同様、ビジネスが自身をＩｎｔｅｒｎｅｔ上に
掲載し互いに発見できるようにするウェブベースの分散
ディレクトリ）やＳＯＡＰ（シンプル・オブジェクト・
アクセス・プロトコルは、プラットフォームには関係な
くアプリケーションがＩｎｔｅｒｎｅｔ上で互いに通信
できる方法を提供している。ＳＯＡＰは、ＸＭＬに頼ん
で情報のフォーマットを定義し、次にその送信に必要な
ＨＴＴＰヘッダを加える）を、本発明により拡張し、発
見、対話、及びスクリプティング能力を提供してもよ
い。フレームワークに関しても本発明の要件は最小であ
るので、ｅ−スピーク等、既存の統合フレームワークを
これらの機能性で増強するのは概ね容易である。

【００４４】ソフトウェアコンポーネントのようなサー
ビスに加え、プリンタ、ファクシミリ機などのデバイス
を、ソフトウェアサービス同様の手法で本システムにプ
ラグインすることができる。また、第３者サービス及び
デバイス（例えば電話）を、ｄｏｃｕｍｅｎｔ．ｃｏｍ
又はＣｏｍｍｕｎｉｔｙＷａｌｌのような他の内部サー
ビスと補完的に統合してシステムに加えてもよい。

【００４５】本発明のシステム及び方法は、ｅ−スピー
クウェブアクセス（及びＵＤＤＩ）を使う場合に必要と
なる（且つ多大な労力を要する）３つの段階、即ち、ブ
ラウジングにより現存のサービスを発見する段階と、呼
び出しに対応するリクエストを構築する段階であり、時
間の大部分は発見されたスキームで有効なＸＭＬ文書を
書くことから成り、あるサービスとの１つの対話を表し
ているリクエスト構築段階と、テストされた対話を連鎖
するクライエントアプリケーションを書く段階の３つの
段階を統合する。

【００４６】ＤＳＤＩＦと本発明は相補的であり、統合
して１つにすることができる。本発明は、典型的には、
どのサービスが利用できるかを発見すること、新しいサ
ービスを追加すること、それが他のサービスとどのよう
に統合できるかをテストすること、及び幾つかのシナリ
オを設計して検査すること、をサポートする。ＤＳＤＩ
Ｆは、強靭で、厳密な意味論と証明済みの性能を備えた
「プロダクションソフトウェア」の構築に使用できる。
例えば、ＤＳＤＩＦを他のバス上の別のフレームワーク
として考えると、このセットはプログラミング用のオペ
レーティングシステムを構成しているようなものであ
る。ユーザーは、仕様書を読み、予定の順序で一式のサ
ービスを使用するためのコードを作るプログラマであ
る。所与のサービスがエンドユーザーに何らかの意味を
与える場合、サービスは（本発明を使って）見て、コマ
ンドのセットをサブシステムの上に設けるのと同じよう
に、一番上の機能と対話して連鎖できるように提示され
る。そうするためには、ＤＳＤＩＦサービスは、本発明
のフレームワークに準拠していなければならない。そう
なっていれば、ＳＩＦ内でアプリケーションをコード化
する前に、対話式にスクリプトすることにより、機能レ
ベルでの試作を行うことができる。

【００４７】一般的に、システムにサービスを加えるの
に要する労力は「メイン」機能を書きサービスを文書化
することに相当するほんの限られたものと考えられる。
しかしながら、サービスのプラグインに要する労力は、
サービス自体の性質に左右される。サービスが基本的な
入出力ストリーム、例えばＵＮＩＸ（登録商標）コマン
ドに匹敵するものである場合は、かかる労力は１時間の
作業より軽いものとなろう。サービスがＤｏｃｕｓｈａ
ｒｅのような複雑なＡＰＩを有する場合は、正しいプラ
グインを得るまでに１週間以上を要するであろう。

【００４８】知識管理顧客用のシステムを実装する本発
明の例では、知識プロファイルサービスを提供すること
が重要である。このサービスは、非均質データに関し比
較可能な表現を提供する点で有用である。サービスによ
り公表されたデータをプロファイルするのに専用の機構
がある限り、データモデルに制約を課すことなく、殆ど
のデータを比較する方法を提供する。これは、基本的知
識メタデータ、場合によってはキャストオペレーション
として見ることができる。

【００４９】知識プロファイルサービスは、文書、ユー
ザー、対象のコミュニティ、及びウェブソース（例え
ば、ＯｐｅｎＤｉｒｅｃｔｏｒｙ）用の知識プロファイ
ルを提供する。知識プロファイルは、プロファイルされ
たオブジェクトに関係付けられたテキストデータに基づ
いている。従って、これは、例えばユーザー又は文書メ
タデータに関する人口統計的プロファイルと直交してい
る。あるオブジェクトに関係付けられた現在の知識プロ
ファイルは用語加重ベクトルのセットである。複数の知
識プロファイルは、情報の内容／関心に関する類似性を
測る目的で、比較することができる。知識プロファイル
サービスは、２つの機能性のファミリーを提供する。第
１に、オペレーションインターフェースは、特定のオブ
ジェクトの知識プロファイルの探索、並びにそれらと他
との比較／順位付けを許容する。第２に、登録インター
フェースは、知識プロファイルプロバイダが、プロファ
イルされたオブジェクトの新たな又は最新の現存プロフ
ァイリング情報（別名、用語加重ベクトル）を加えるこ
とを許容する。

【００５０】知識プロファイルサービスは、文脈上のフ
ィルタリングアルゴリズムも提供する。知識サービスに
関する問題の１つは、オペレーション毎に予想される結
果の数である。探索又はレポジトリからの文書検索は、
結果の数により限定されるものではない。このようなオ
ペレーションの連鎖は、幾つかのフィルタリングが必要
な指数ツリーに迅速に導いてくれる。正しく包括的なフ
ィルタリングを提供することは、プログラマにとって殆
どの場合不可能である。正しいフィルタリングは、ユー
ザー又はコミュニティ次第である。従って、関連の薄い
ブランチを切り落とす前に、知識プロファイルサービス
の順序機構を、考察するコンテキストに対して用いるこ
とが、最も適切且つ包括的で低コストのフィルタリング
技術であることが多い。

【００５１】本発明は、各種ハードウェアプラットフォ
ーム上で使用することのできるポータブルソースコード
を提供するソフトウェア開発環境を使って、ソフトウェ
アに容易に実装することができると理解されたい。或い
は、開示したシステムは、標準的な論理回路を使ってハ
ードウェアに部分的又は全体的に実装することもでき
る。本システムを実装するためにソフトウェアを使うか
ハードウェアを使うかについては、システムの速度及び
効率要件により、更には、使用されている特定の機能、
及び特定のソフトウェア又はハードウェアシステム、並
びに特定のマイクロプロセッサ又はマイクロコンピュー
タシステムにより異なる。

【図面の簡単な説明】

【図１】ソフトウェアコンポーネントを統合するための
システムのブロック図である。

【図２】ソフトウェアコンポーネントを統合するための
システム内で利用可能なサービスのグループの表示であ
る。

【図３】図２のサービスの中から選択する場合のフィル
タ制御パネルである。

【図４】電子メーラーサービス用の制御パネルである。

【図５】電子メーラーサービス用のフィルタ制御パネル
である。

【図６】電子メーラーサービス用のサービス特性の一覧
である。

【図７】電子メーラーサービス用のサービスパラメータ
の一覧である。

【図８】辞書サービス用の制御パネルである。

【図９】辞書サービス用のフィルタ制御パネルである。

【図１０】辞書サービス用のサービス特性の一覧であ
る。

【図１１】辞書サービス用のサービスパラメータの一覧
である。

【図１２】要約機能サービス用の制御パネルである。

【図１３】要約機能サービス用のフィルタ制御パネルで
ある。

【図１４】要約機能サービス用のサービス特性の一覧で
ある。

【図１５】要約機能サービス用のサービスパラメータの
一覧である。

【図１６】図１のシステムを使って構築した代表的シナ
リオのブロック図である。

【図１７】図１のシステムがネットワーク上でどのよう
に実施されるかを示すブロック図である。

フロントページの続き Ｆターム(参考） 5B076 DD06 DD10 5E501 AA01 AB15 AB16 BA05 DA12 EB05 FA22 FA23

Claims (12)

【特許請求の範囲】
1. 【請求項１】 システム内でサービスを統合する方法に
   おいて、 各サービスが前記システムに関係付けられたソフトウェ
   アコンポーネントを備え少なくとも１つの機能性を提供
   するような複数のサービスを提供する段階と、 各サービスが自身に直接アクセスするための自身に関係
   付けられたリンクを有しているような複数のサービスを
   ユーザーインターフェースに表示する段階と、 前記複数のサービスから第１のサービスを選択する段階
   と、 前記複数のサービスから第２のサービスを選択する段階
   と、 前記第１のサービスからの出力が前記第２のサービスへ
   の入力として提供されるようにシナリオを形成するた
   め、前記第１及び第２のサービスを接続して一体化する
   段階と、から成る方法。
2. 【請求項２】 前記シナリオに直接アクセスするためリ
   ンクを前記シナリオに関係付ける段階を、更に含んでい
   ることを特徴とする請求項１に記載の方法。
3. 【請求項３】 前記複数のサービスから第３のサービス
   を選択する段階と、 前記第２のサービスからの出力が前記第３のサービスへ
   の入力として提供されるような第２のシナリオを形成す
   るため、前記第１、第２、及び第３のサービスを接続し
   て一体化する段階を、更に含んでいることを特徴とする
   請求項１に記載の方法。
4. 【請求項４】 前記複数のサービスから第４のサービス
   を選択する段階と、 前記第１のサービス、前記第２のサービス、又は前記第
   １のサービスと前記第２のサービスの両方、の何れかが
   前記第４のサービスの入力として提供されるように、前
   記第４のサービスを前記第２のサービスに置き換える段
   階を、更に含んでいることを特徴とする請求項１に記載
   の方法。
5. 【請求項５】 前記シナリオに対して入力を提供する段
   階と、前記シナリオからの出力を検査する段階を、更に
   含んでいることを特徴とする請求項１に記載の方法。
6. 【請求項６】 前記サービスそれぞれに対して定義され
   た条件に言及する、複数の選択可能な基準を備えている
   フィルタ制御を提供する段階と、 前記フィルタ制御内で少なくとも１つの基準を選択する
   段階と、 前記フィルタ制御を実行して、前記複数のサービスのサ
   ブセットを備えた何れの結果をも表示する段階を、更に
   含んでいることを特徴とする請求項１に記載の方法。
7. 【請求項７】 サービスシステムを統合するためのシス
   テムにおいて、 各サービスが前記システムに関係付けられたソフトウェ
   アコンポーネントを備え少なくとも１つの機能性を提供
   するような複数のサービスと、 各サービスが自身に直接アクセスするための自身に関係
   付けられたリンクを有しているような複数のサービスを
   表示するためのユーザーインターフェースと、 前記複数のサービスから第１のサービス及び第２のサー
   ビスを選択することに応えて、前記第１のサービスから
   の出力が前記第２のサービスへの入力として提供される
   ようにシナリオを形成するために、前記第１及び第２の
   サービスを接続して一体化するためのスクリプティング
   シェルと、を備えていることを特徴とするシステム。
8. 【請求項８】 前記スクリプティングシェルは、前記シ
   ナリオに直接アクセスするために、リンクを前記シナリ
   オに関係付けることを特徴とする請求項７に記載のシス
   テム。
9. 【請求項９】 前記サービスそれぞれに対して定義され
   た条件に言及する、複数の選択可能な基準の中から選択
   を行うためのフィルタ制御であって、前記フィルタ制御
   内の少なくとも１つの基準の選択に応えて、前記複数の
   サービスからサービスの一覧を生成するようなフィルタ
   制御を、更に備えていることを特徴とする請求項７に記
   載のシステム。
10. 【請求項１０】 各サービスは、サービスを実施するた
    めの制御パネルと、前記サービスに関連する基準を選択
    するためのフィルタ制御とを含んでいることを特徴とす
    る請求項７に記載のシステム。
11. 【請求項１１】 前記システムは知識管理システムを備
    え、前記選択可能な基準は、ベンダ、名前、モデル、通
    し番号、製造者、バージョン、場所、及びドメインを備
    えていることを特徴とする請求項７に記載のシステム。
12. 【請求項１２】 サービスを前記システムに関係付ける
    ための手段を備えていることを特徴とする請求項７に記
    載のシステム。