JP5650877B2 - 複数のコンピューティング機能ソースを用意するための装置及び方法 - Google Patents

Description

本発明は、意味論的に記述されたアプリケーション、デバイス及びサービスに富んだコンピュータ環境に基づいて、複雑なタスクをリアルタイムで、動的に構成及び実行することに関連する。

パーソナルコンピューティングは、ユーザが単独の装置を操作し及びその装置に常駐するアプリケーションにアクセスする／を利用するパラダイムとして言及されてよい。パーソナルコンピューティングは、知識豊富なユーザが複雑なタスクを実行するのに利用可能なリソースを適切に利用できるように、ユーザのコンピュータ環境に関する及びそのユーザのコンピュータで利用可能なアプリケーションに関する充分な知識をユーザが有することを要する。これはほとんどのユーザが日常経験するコンピューティング環境である；複雑なタスクを如何にして達成するかを学習する義務はユーザにあり、そのユーザは、ユーザの機器で動作するアプリケーション各々の及びユーザの機器がサポートする機能各々を理解すること、アプリケーションの間でデータを手動で移行すること（例えば、カット＆ペースト）、タスクに関連するアプリケーションや特定の機能各々を手動で起動すること及び最終的にはその複合的なタスクを実行することに全ての注意を向けること（及び時間を捧げること）を必要とする。

パーソナルコンピューティングからコンピューティング環境のより多くのタスク指向への移行（シフト）は次のようになるであろう：
例えば、オペレーティングシステムの一例として、ユーザが音楽ＣＤをＣＤトレイに挿入すると、その時点からユーザが実行可能なタスクをユーザに示唆するウインドウがポップアップされる。これらの典型的な選択肢のリストは：
オーディオＣＤを再生すること
ＣＤから音楽をコピーすること
ファイルを見るためにフォルダを開くこと
何の動作（アクション）も行わないこと
を含んでもよい。

これらの選択肢の各々は、そのアクションを実行するのに使用されるアプリケーションにも言及する。関心事は実行されるアクション又はタスクについてであり、そのタスクを実行するのに使用されるアプリケーションではない。

しかしながら、目下のオペレーティングシステムは、特定のイベント（例えば、音楽ＣＤを挿入することや、ディジタルカメラを接続したこと等）に関連するアクション又はタスクの所定のリストを利用し、そのイベントが生じたときに、関連するアクションのリストが実行時にユーザに示されるようにする。この意味において、システムの応答はハードワイヤ接続的であり、トリガとなるイベントの結果として実行される可能なイベントについて、システムにプログラムされているものを超える柔軟性を備えていない。言い換えれば、システムは、ディジタルカメラがコンピュータに接続されたときに実行可能な同じアクション群（オペレーティングシステムのプログラマがその特定のイベントについて用意した具体的なアクションリスト）を示す。アプリケーションはリスト中の項目を変更できるが、エンドユーザがそれを変更する簡易な手法はない。

オペレーティングシステムの別の例では、ファイルタイプに依存するアクションの選択肢がユーザに提示される。即ち、ドキュメント、画像、フォトアルバム、音楽、音楽アーティスト、音楽アルバム及びビデオ等のようなファイルタイプの各々について別々のタスクのリストがユーザに提示される。例えば、ファイルタイプが画像であったとすると、「画像タスクの」のリストが表示される：
スライドショーとして見る（表す）
オンライン印刷を要求する
画像を印刷する
画像を背景に設定する
画像をＣＤにコピーする。

このタスクのリストは再び予め組み合わせられ及び特定のファイルタイプに関連付けられる。エンドユーザがこのリストを修正する簡易な手法はない。

事務に適切なソフトウエアの別の例では、スマートタグ特性（機能）が利用可能である。スマートタグ機能は、エディタを利用しながら現在の書類中のテキストを強調し、そのテキスト（文字）が示すオブジェクトと共に実行可能なアクションのドロップダウンメニューをユーザに提示する。例えば、テキストが名前を表現するならば、この機能は人物名に関連するオブジェクトを判別し、可能なアクションの以下のリストを提示する：
（その人に）メールを送る
（その人と共に）ミーティングを計画する
（その人の）連絡先を開く
（その人に関する）連絡先を生成する。

選択肢は、書類中の文字列が名前を表現するかもしれないことを確認することによってイネーブルにされる。このシステムは、特定のテキスト部分が名前を表現することを確認するために、そのテキストのシンタックス属性（文法）を当てにする。しかしながら一般的なアメリカ人の名前に似ていない文字列（例えば、ラッセン ジ）は、人物に関連する名前として確認されないかもしれない。その理由は、テキストの一部を名前として確認すシステムの部分は、テキストに関するシンタックス形式の中で判別可能なパターンを簡易に確認しようとする非常に簡単なプログラム（スクリプト）であるに過ぎないためである。例えば人物、住所等のようにテキストの「属性(nature)」が（適切に又は不適切に）確認されると、予めコンパイルされた可能なアクションのリストがユーザに提示される。アプリケーションプログラマは、アドレスを確認すること及びマップアプリケーションを起動すること等のような他の書類やアプリケーションに関するスマートタグを作成することが可能である。

コンピューティング環境に関するより多くのタスク指向の観点からユーザに提示を行おうとする別の例が以下に説明される。ユーザがサーチエンジンのサーチボックスに或るアドレスをタイプ入力すると、そのサービスは（通常のサーチ結果を超える）マッピング機能へのリンクを返し、それに従うとアドレスのマップを提供する。

しかしながら、タイプされたアドレスのマップをユーザが探しているかもしれないことは自明ではない。他の合理的な可能性が存在する：ユーザはそのアドレスに関連する電話番号リストを望んでいるかもしれない、或いはそのアドレスが会社ならば、ユーザは探索されたビジネスについてより良いビジネス案内(BETTER BUSINESS BUREAU)記録を見ることを望むかもしれない、又はその近辺の天候を調べようとしているかもしれない、等々である。この現在の形式では、サーチエンジンは、タイプされたテキストが表現する「もの（thing）」（目下の例ではアドレス）のタイプを推定し、そのタイプのエントリに関連付けられたハードワイヤ的に関連するタスクを返す。

従ってコンピュータ環境のタスク指向の観点からは、関心事はタスクであり、そのタスクは実行可能なものであり、タスクを実行するのに使用されるアプリケーションに関してではない。更にユーザはタスクにどのアプリケーションが使用されるかを知る必要がない。示唆されたタスクの１つを実行するようにユーザが選択すると、適切なアプリケーションがそれに従って始まり及び呼び出され（開始される）。

しかしながら上述のコンピューティング例は、以下のようなリアルタイム且つダイナミックな実行可能な複合的なタスクを許容しないという同様な性質を示す。或る手法では、ユーザの入力（テキスト又はイベント）のタイプ又は性質が推定され；事実上、システムはそのシンタックス属性を当てにして文字列の意味（セマンティック）を判断しようとする。システムは、その入力の下でユーザが実行することを希望するもっともらしいタスクを推定するが；その推定はシステムに固有の（ハードワイヤ式の）ものであり、従って実際上は、そのシステムはリアルタイムで推定を行うものではなく、ユーザがそのシステムと相互作用する以前に、システムのプログラマがプログラミング時にシステムに関する推測を行うに過ぎない。（ユーザが第２ステップで選択するといつでも）適切なアプリケーションが、ユーザの選択時に自動的に呼び出され、（第１ステップでシステムが推定するといつでも）その適切な入力と共に例示され、静的な因果関係による機構（又は契機に応答する機構）である。

上述のコンピューティング例はユーザの利便性を増やすかもしれないが、従来のシステムは依然として以下のパーソナルコンピューティング的な性質を有する：
機能はアプリケーションの中に設計される；アプリケーションのプログラマはシステムの応答を（固定的に）プログラムする。その結果、これはフレキシブルでスケーラブルな手法ではない。なぜなら可能性の広がりが設計時に決められているからである。

このシステムはユーザのアクション及び希望に対応することについては限られた手法であり、入力の性質（セマンティクス又は意味）を正確に「感知(perceive)」することはできない。上記の例各々で使用される様々な技法があるにもかかわらず、システムは文法特性により入力の意味を正確に推測することを当てにする。

従来のパーソナルコンピューティングシステムは、因果関係（又はトリガ応答）機構を利用する点で、所定のタイプの入力が単独のアクション（アプリケーションの起動）になることを意味する。

また、パーソナルコンピューティング−即ち、ユーザのアプリケーションを実行し及びユーザのデータを「保持」するコンピュータをユーザが所有及び操作する概念−は、境界の明確でないコンピューティング環境に対する手法を与える。コンピュータがコンピュータネットワークに永続的に接続されると、ローカル及びリモートのアプリケーション間の区別、データ破壊は更に悪いことにコンピュータユーザを混乱させる。更に、ユーザは装置にアクセスし及び装置と相互作用することができ、その装置はパーソナルコンピュータという意味ではコンピュータでないが、依然としてかなりの演算能力を有し及びユーザの目的に寄与し、様々なタスクを達成することを支援する（例えば、カメラ、プリンタ、スマート機器等）。一例として、利用可能なリソース（デバイス及び機器）は定常的に変化するかもしれないが、平均的なユーザはそのようなコンピューティング環境の中で何が実行可能か或いは実現可能かに気付いてさえいないかもしれない。言い換えれば、パーソナルコンピュータの手法はユーザに事前に知られていない装置やアプリケーションに満ちた設定を行うことは不可能である。

従ってコンピュータ環境の中でタスクをリアルタイムで動的に発見し、公表し、構成し、管理し及び実行することが望まれており、その手法はコンピューティング環境の中でタスクを実行するユーザの課題に対して根本的に異なるアプローチを必要とする。

ここで説明される本発明の一形態は、意味論的に記述されたアプリケーション、装置及びサービスに富んだコンピューティング（コンピュータシステム）環境に基づいて、複合的なタスクをリアルタイムで動的に発見し、公表し、構成し、管理し及び実行する。一形態によれば、ある方法、装置及びそれに関するコンピュータ読取可能な媒体は、２以上のサービスの複合的なユーザのタスクをリアルタイムでダイナミックに管理し、そのサービスはイベント及びアクションのシーケンス又は列を有する複数のサービスのワークフロー必要とし、そのワークフローは従来のパーソナルコンピューティングシステムで使用される静的な又は予め指定された因果的なプログラミングで簡易に行うことは困難である。

ここで説明される本発明の別の形態によれば、ユーザは、現実的に、効果的に、効率的に、動的に、リアルタイムでフレキシブルな統合されたタスクユーザインターフェースを当てにすることができ（そのインターフェースは機能を発見し、公表し、構成し、サービス提供し及び／又はタスク管理し、及び実行する）、汎用的なコンピュータ環境と共にやり取りを管理し且つインターフェースを取ることができる。別の形態によれば、複合的なタスクを成し遂げること（一連のサービスを管理すること）は、一方ではタスクに関するユーザの理解を、他方では利用可能なリソース（装置及びアプリケーション）のユーザの理解を当てにし、ユーザがそれらをワークフロー（ユーザが実行するワークフローであり、その最終的な成果が完全なタスクになる）に構成することができるようにする。

本願は、西暦２００５年９月８日付けでリュースケマツオカ、ヤニスラブロウ、ゼクスアンソン及びサンリーにより米国特許商標庁に出願された「TASK COMPUTING」と題する35USC119に基づく米国仮出願番号第60/714,952号（代理人管理番号1634.1020P）に関連し且つその利益を享受し、その内容は本願のリファレンスに組み入れられる。

本願は、西暦２００５年４月２７日付けでヤニスラブロウ、リュースケマツオカ及びゼクスアンソンにより米国特許商標庁に出願された「TASK COMPUTING」と題する米国出願の継続出願第11/115,403号に関連し、その内容も本願のリファレンスに組み入れられる。

本願は、西暦２００３年１２月１２日付けでリュースケマツオカ、ヤニスラブロウ、ゼクスアンソン及びサンリーにより米国特許商標庁に出願された「TASK COMPUTING」と題する米国出願の継続出願第10/733,328号に関連し、その内容も本願のリファレンスに組み入れられる。

以下で充分に説明され及び特許請求の範囲に記載されるように、本発明並びに後述の他の形態及び利点は詳細な構成及び動作から更に明らかになり、説明の一部をなす図面が参照され、図中同様な番号は同様な部分を示す。

図１Ａは本発明の一実施例によるタスクコンピューティング環境(TCE: Task Computing Environment)１００のタスクコンピューティングアーキテクチャを示すシステム図である。図１Ａでは、コンピュータで実行される方法は、パーバシブ（汎用的な）タスクコンピューティングシステム環境１００を複数のタスクコンピューティングコンピュータシステム実行段階(tier)に分けるステップを有し、その段階は、プレゼンテーション処理レイヤ１０４、リモートプロセジャコールメカニズムアプリケーションプログラムインターフェース（ＡＰＩ）１０６、リモートプロセジャコールＡＰＩ１０６によりプレゼンテーションレイヤ１０４に対するインターフェースがとられるミドルウエア（サーバ）プロセシングレイヤ１０８を有し、本方法は、機能１１６の意味論的に記述されたコンピュータシステムのソース機能１１６に対して、コンピュータ１００のサービス１１２として、ネットワーク化された、ネットワーク化されていない又は双方として（コンピュータシステム１１０）、リアルタイムで動的に（ダイナミックに）コンピュータで実現されるタスクインターフェース１３０（例えば、）をプレゼンテーションレイヤ１０４で生成する。

一実施例によれば、機能ソース実現レイヤ１１４は機能性に関するコンピューティングソース（例えば、デバイス又はソフトウエア１１４）であり、例えばユーザに対するサービス機能１１５を表現する又は示すことができる。サービスレイヤ１１２は、サービス機能１１５を意味論的に記述するための、サービス機能１１５に関連するセマンティックサービス記述(SSD: Semantic Service Description)１１６を有する。かくてＳＳＤ１１６はサービス機能１１５を意味論的に表現又は記述する。かくて「サービス」１１２なる用語はＳＳＤ１１６のサービス機能１１５への関連付けを意味する。言い換えれば、ＳＳＤ１１６は「サービス」を表現する。より具体的には、「サービス」１１２なる用語は、コンピュータ装置、コンピュータアプリケーション／ソフトウエア、電子サービス及びコンピュータ（若しくはマシン又は双方で）読取可能なコンテンツの機能ソース実現レイヤ１１４の領域からの機能に関する演算例に関連する。より具体的には、サービスレイヤ１１２及び機能ソース実現レイヤ１１４は、機能１１６の意味論的に記述されたコンピュータシステムソースをコンピュータサービス１１２として用意し、ミドルウエアプロセシングレイヤ１０８は、コンピュータシステムでリアルタイムで動的に構成する実行可能なタスクに対するインターフェースをとり、そのタスクは、コンピュータシステム１１０で1以上のサービス１１２に対するプレゼンテーションレイヤ１０４で生成されたタスクインターフェースに従う1以上のサービス１１２より成る。

タスクコンピューティング１００は、アプリケーション、装置、電子サービス及びコンテンツリッチなコンピュータネットワーク環境１１４で複合的なタスクをリアルタイムで動的に発見、公表、構成、管理及び実行する（即ち、実現レイヤ１１４でタスクを実行する）ための新たなパラダイム(paradigm)である。タスクコンピューティング１００は、（例えば、セマンティックサービス記述（ＳＳＤ）１１６ａ−ｎを介して）コンピュータ装置１１４ａ−ｎのサービス機能１１５ａ−ｎを意味論的に記述することに基づき、そのセマンティクスに従ってエンドユーザによりオンザフライで実行可能なタスクに構成可能である。従ってここで説明される実施例によれば、タスクコンピューティング１００システムは、３つ又はそれいじょうのプログラムされたコンピューティング及びコンピュータ読取可能な情報レイヤのマルチレイヤコンピュータシステムアーキテクチャを有し、そのアーキテクチャはプレゼンテーションクライアントプロセシングレイヤ１０４、ミドルウエアサーバープロセシングレイヤ１０８（例えば、セマンティックインスタンス、セマンティックサービス記述１１６）及び複数のコンピュータシステムレイヤ中の複数のサービスを含む。「タスク」１２６なる用語は、例えばユーザが実行するよう希望する、発見されたコンピュータシステムサービス１１２に従う１以上のアクションの構成に関連する。ここで説明される実施例によれば、「タスク」１２６は、ユーザにより自動的に駆動され、或いはそれらの如何なる組み合わせもコンピュータで実現されるタスクインターフェース１３０を介して構成及び管理される。ユーザの場合、１以上のサービス１１２の構成としてのタスク１２６はプレゼンテーションレイヤ１０４で管理される（例えば、発見され、公表され、構成され、実行される、等々）。非限定的なサービスの構成例として、「マイコンタクト１１２の勤務先アドレス１１２の天候情報１１２をプロジェクタ１１２で見る」は、「プロジェクタで見る」、「天候情報」、「勤務先アドレス」及び「マイコンタクト」の４つのサービス１１２で構成される。言い換えれば、「タスク」は１以上のサービス１１２の組み合わせより成る。

「構成(composition)」なる用語は、（非限定的であるが）例えばサービス１１２の入力（消費）／出力（生成）に対するデータオブジェクトタイプのような、サービス１１２の意味論的入力及び出力のように、意味論的に記述されたサービス１１２の用意された機能特性に従って複数のサービス１１２を共に置くことで形成することに関連する。サービスの機能特性例は、サービスの構築性を決定ためにサービス１１２の影響及び前提条件にすることができる。サービス１１２の影響及び前提条件の具体例はサービス１１２の入力及び出力データオブジェクトタイプにすることができる。

「セマンティックインスタンス(semantic instance)」又は「セマンティックオブジェクト(semantic object)」なる用語は、１以上のオントロジ(ontology)に基づく或る項目に関する記述群に関連する。セマンティックサービス記述（ＳＳＤ）１１６は１以上のサービス機能オントロジに基づいてサービス機能１１５を記述する。

「公表(publish)」なる用語は１以上のサービス発見手段を介してセマンティックサービス記述（ＳＳＤ）１１６を利用可能にすることに関連する。

一実施例による「セマンティックサービス記述」１１６なる用語は、サービス機能１１５自身から或るアプリケーション（例えば、タスクコンピューティングシステム（ＴＣＳ）１１８）へ、サービス機能１１５のパラメータを通知するための媒介物に関連する。

「発見(discover)」なる用語はセマンティックサービス記述１１６の発見に関連する。

タスクコンピューティングはコンピュータシステム１１０のタイプを指定し、そのシステムは自動的な若しくはユーザが駆動する又はそれら双方の（適切な如何なる組み合わせによっても）リアルタイムで、ダイナミックに、「タスク」１２６を発見、公表、構成、管理及び実行し、そのタスクは意味論的に記述された１１６アプリケーション、装置及びサービスリッチなコンピュータコンピューティング（コンピュータシステム）環境１１０に基づく１以上のサービス１１２を有する。

セマンティックタスク実行エディタＲ（STEER）（意味論的に記述されたサービス１１６の実行可能なタスクを発見及び構成するためのソフトウエア）及び汎用インスタンスプロビジョン環境(PIPE: Pervasive Instance Provision Environment)（セマンティックインスタンス及び／又はセマンティックサービス１１６を公表及び管理するためのソフトウエア）に関する２つのタスクコンピューティングクライアントの例は、関連する米国特許出願番号第10/733,328号に記載されており、その内容全体は本願のリファレンスに組み入れられる。ここで説明される実施例は、リアルタイムに使用される技術及び／又は技術における改善、意味論的に記述されたサービス１１６の実行可能なタスクへの動的な構成に加えて、意味論的に記述されたサービス１１６の管理（例えば、発見、生成／公表、操作等）に関連する
図１Ａでは、ここで説明される実施例に従って、1以上のタスクコンピューティングシステム（ＴＣＳ）１１８ａ−ｎが、リモートプロセジャコールメカニズムに基づいてクライアントサーバーコンピュータシステムアーキテクチャに従って用意される。ＴＣＳ１１８は論理的であり、実行時にプレゼンテーションプロセシングレイヤ１０４にセグメント化され、クライアントタイプのプログラムされたプロセッサをタスクコンピューティングクライアント１１９ａ−ｎとして提供し、ミドルウエアプロセシングレイヤ１０８はサーバータイプのプログラムされたプロセスを提供し、セグメントされたプレゼンテーション及びミドルウエアプロセシングレイヤ１０４，１０８は、タスクコンピューティング環境ウェブサービスアプリケーションプログラミングインターフェース（TCE-WSAPI）１０６ａ−ｎのようなウェブサービス（ＷＳ）のような如何なるリモートプロセジャコールメカニズムにも従ってインターフェースをとる。ウェブサービスの概念は周知である。従ってここで説明される実施例では、概してＴＣＳ１１８は、プレゼンテーションレイヤ１０４でクライアントタイプのプロセスを用意するタスクコンピューティングクライアント（ＴＣＣ）と、ウェブサービス（ＷＳ）のようなリモートプロセジャコールＡＰＩを介するミドルウエアサーバープロセシングレイヤに関するＴＣＣ１１９インターフェースとを有し、この場合にＴＣＣ１１９はＷＳＴＣＣ１９９と言及される。リモートプロセジャコールメカニズムの具体例として、ウェブサービスを利用するＴＣＳ１１８は、ＷＳＴＣＳ１１８と言及される。第三者アプリケーションを含む如何なるアプリケーション（例えば、マイクロソフトワード、エクセル、アウトルック、アドーブアクロバット等）、ウェブサービスのようなリモートプロセジャコールメカニズム（ウェブサービスコールのようなリモートプロシジャコールを作成することができる（又はリモートプロシジャ呼出機能を組み込むことができる））を用いることで、タスクコンピューティングクライアント（ＴＣＣ）１１９になることができる。ここで説明される実施例は、リモートプロセジャコールメカニズムの具体例としてウェブサービスを利用するが、本発明はそのようなコンフィギュレーションに限定されず、如何なるリモートプロシジャコールメカニズムが使用されてもよい。

従ってウェブサービスをリモートプロシジャコールＡＰＩの具体例として使用すると、セマンティックタスク実行エディタウェブサービスタスクコンピューティングシステム（STEER-WS TCS）１１８ａはＷＳＴＣＳ１１８の一例であり、STEER-WSAPI１２―を介して、ミドルウエアサーバープロセシングレイヤ１０８に関してインターフェースをとるプレゼンテーションプロセシングレイヤ１０４におけるSTEER−WSタスクコンピューティングクライアント（STEER-WSTCC）１１９ａを有する。

パーバシブインスタンスプロビジョン環境ウェブサービスタスクコンピューティングシステム(PIPE−WSTCS)１１８ｂはWSTCS１１８の別の例である。PIPE-WSAPI１２２はミドルウエアサーバ管理ツール１２４を明らかにし、そのツールは一般にタスク１２６を管理することに加えて、タスクコンピューティング１００で使用されるSSD１１６及び／又はセマンティックオブジェクトインスタンスを管理（例えば、生成／公表、除去、操作等）するために使用される。PIPE−WS122を利用するアプリケーションクライアント１１９はここでは意味論的に記述されたサービスコントロールメカニズム(SDSCM: Semantically Described Service Control Mechanism)１１９ｂとして言及され、その具体例は「ホワイトホール(White Hole)」１１９ｂ−１、「サービスマネジャ」１１９ｂ−２、「リアルワールドオブジェクトセマンタイザ」１１９ｂ−３、及び「データベースセマンタイザ１１９ｂ−４」であり、これらは関連する米国出願番号10/733,328号及び11/115,403号でも説明されている。例えば、例えば「ホワイトホール」タスクコンピューティング（ホワイトホール）１１９ｂ−１のように、プレゼンテーションプロセシングレイヤ１０４で（PIPE-WSAPI１２２を介してミドルウエアサーバープロセシングレイヤ１０８とインターフェースをとる）、WSTCS１１８ｂはPIPE-WS122を利用し、ウェブサービスタスクコンピューティングクライアント（アプリケーションクライアント）又はSDSCM１１９ｂを有する。

（非限定的であるが）STEER-WSＴＣＣ１１９ａのようなウェブサービスタスクコンピューティングクライアント（ＷＳＴＣＣ）１１９、ホワイトホール１１９ｂ−１、「サービスマネジャ」１１９ｂ−２、「リアルワールドオブジェクトセマンタイザ」１１９ｂ−３及びデータベースセマンタイザ１１９ｂ−４をプログラム可能なコンピューティング素子（例えば、タスクコンピューティングクライアントソフトウエア）としてプレゼンテーションレイヤ１０４で利用することで、コンピューティング環境の１つ又は複数の如何なるものによってもＴＣＥ−ＷＳＡＰＩ１０６を介するミドルウエアサーバープロセス１０８によって利用可能にされた意味論的に記述されたサービス１１６に基づいて、ユーザはタスク１２６を管理（例えば、発見、公表、構成、実行、操作）することができる。

図１Ａでは、今日のコンピューティング環境に従って、ユーザは実現レイヤ１１４に関連する機能で囲まれており、その機能は、インターネットで利用可能な電子サービス（ｅサービス）、ユーザが操作するコンピュータ装置で動作するアプリケーション、コンピュータ読取可能な媒体で利用可能なコンテンツ等のような装置若しくはコンピュータ媒介サービス、又は特定の機能をサポートする単なる装置を有する。そのような装置、アプリケーション、ｅサービス及びコンテンツの具体例は、（限定ではないが）電話、コンピュータディスプレイ、カメラ、娯楽装置／コンテンツ、テレビジョン、パーソナルディジタルアシスタント（ＰＤＡ）、無線通信装置（例えば、移動電話等）、オーディオプレーヤ、ファクシミリ装置、プリンタ、天気予報サービス、地図サービス、事務関連コンピュータソフトウエア（例えば、電子メールアプリケーション、アドレスブック等）、マルチメディアコンピュータ読取可能メディア（例えば、音楽のコンパクトディスク、映画のディジタルビデオディスク（ＤＶＤ）等）、インターネットサイト、データベース等を含む。

図１Ａでは、実現レイヤ１１４で与えられる機能又はサービス機能１１５ａ−ｎは、例えば（限定ではないが）、（例えば、娯楽装置の場合に）音楽を聴くこと、歌をダウンロードすること、ストリーミングビデオを鑑賞すること、ラジオを聞くこと、連絡先情報を提供すること、地図上の住所を確認すること等を含む。従来、実現レイヤ１１４は、装置又はサービス各々とユーザがやり取りする（及び／又は操作する）ことにより、そのユーザに機能を提供するように設計されていた；例えば、ユーザが訪れている部屋に用意されている電話で同僚に電話することを希望し、その同僚の電話番号がユーザのラップトップの電子アドレスブックアプリケーションに記憶されていたならば、そのユーザはラップトップアプリケーションを起動し、問題としている電話番号を捜し、その電話でその電話番号に手動でダイヤルしなければならない。言い換えればユーザはタスク１２６を構成することはできない。アプリケーション、ｅサービス及び装置が物理的に互いに通信可能である場合でさえ、即ちそれらの間に通信リンクが存在する場合でさえ、実現レイヤ１１４の設計者がコンピュータシステム機能ソース（例えば、コンピュータ装置）をタスクを考慮しながら設計していない限り、アプリケーション等はユーザのタスクについて有意義な方法でデータを交換できない。過剰な機能ソース１１４ａ−ｎに直面するとき、機能のソース１１４ａ−ｎがそのタスク用に設計されていない限り、ユーザはそれら全てのソース中の機能を活用するタスクを実行できない。更に、無関心なユーザはそのような如何なるタスクが可能であるかに気付いていないことが間々ある。

図１Ａでは、ここで説明される実施例により、サービスレイヤ１１２は、機能ソース実現レイヤ１１４からのサービス機能１１５ａと、（ネットワーク化された、ネットワーク化されていない又は双方の部分を含む）コンピュータシステムのサービス１１２として、機能ソース実現レイヤ１１４のサービス機能１１５ａを関連する意味論的に記述するセマンティックサービス記述１１６ａとを有する。ここで説明される実施形態によれば、サービス機能１１５及びＳＳＤ１１６間の関係は、特定の機能ソース１１４に関して多対多（ｎ：ｍ）にすることができる。例えば１つのＳＳＤ１１６と複数のサービス機能１１５では、サービス機能１１５の構成を（その構成中の複数のサービス機能１１５と共に）ＳＳＤ１１６として保存する。１つのサービス機能１１５と多数のＳＳＤ１１６の場合には、単一のサービス機能１１５の複数の種類又はタイプの意味を与える。例えば、書籍検索サービス機能１１５（ＩＳＢＮ入力について著者、価格、写真等を返すサービス）の場合、その機能はセマンティックサービス１１６に基づくことが可能であり、ある者が著者の連絡先を返すこと、別のＳＳＤ１１６が画像を返すこと等を行うようにする。より具体的には、ここで説明される実施例形態によれば、サービスレイヤ１１２は、（ネットワーク化された、ネットワーク化されていない又は双方の部分を含む）利用可能なコンピュータシステム１１０サービス１１２を形成することと共に、サービス機能１１５ａ−ｎに対応するセマンティックサービス記述（ＳＳＤ）１１６ａ−ｎ及び実現レイヤ１１４ａ−ｎにより利用可能なサービス機能１１５ａ−ｎを有する。ＳＳＤ１１６は実現レイヤ１１４のコンピュータネットワークサービス機能１１５を明らかにする。ＳＳＤ１１６の或る具体例は、関連する米国特許出願番号第10/733,328号及び11/115,403号にも記載されており、その全内容は本願のリファレンスに組み入れられる。

従って、タスクコンピューティング１００は、タスクを達成する具体的実現方法を強調するのではなく、タスク１２６を強調する実現レイヤ機能ソース１１４ａ−ｎのサービス機能１１５ａ−ｎ（例えば、コンピュータ装置１１４）とユーザがどのようにやり取りするかの新たなパラダイムであり、そのタスク１２６は、そのコンピュータ装置１１４を利用しながら達成することをユーザが希望するタスクである。タスクコンピューティング１００はユーザが実行したいことと（その環境で利用可能な）コンピュータ装置１１４のサービス機能１１５との間のギャップを埋める。タスクコンピューティング１００は、現在のパーソナルコンピューティングパラダイムのような従来の手法を上回るかなりの恩恵をもたらし、エキスパートでないコンピュータユーザに一層相応しく、全てのタイプのユーザにとって時間を節約でき、汎用コンピュータタイプのコンピューティング環境を実現するのに特に適している。

図１Ａでは、従って、ここで説明される実施形態によれば、拡張及び構築に柔軟性のあるコンピュータシステムアーキテクチャ（ソフトウエア及び／又はプログラマブルコンピューティングハードウエア）を用意するため、個々のモジュール化されたミドルウエアサーバープロセシングレイヤ１０８が作成され、そのレイヤの機能は、リモートプロシジャコールアプリケーションプログラミングインターフェース（ＡＰＩ）を介してプレゼンテーションプロセシングレイヤ１０４に利用可能になる；アプリケーション開発者及びユーザはそれらを用いてタスクコンピューティング機能（例えば、サービス１１２及び／又はタスク１２６の構築、保存、実行、関し、公表、管理等を含む、実行可能なタスク１２６へのサービス１１２発見及び構成）にアクセスする。例えばウェブサービスのようなリモートプロシジャコールメカニズムは、エンドユーザのアプリケーション開発に必要なプログラミング言語非依存性、プラットフォーム及びロケーション（即ち、異なるコンピュータで異なるプロセシングレイヤ）を提供する。

上述したように、ユビキタスパーバシブネットワークコンピュータコンピューティング環境は、その性質上しばしば一時的である多数の装置及びその他の機能（ｅサービス、アプリケーション、コンテンツ）１１４，１１５で満たされ；更に、エンドユーザ又はユビキタス環境のアプリケーションを作成する開発者さえも、如何なる機能（リソース）１１４が及び対応するサービス機能１１５が所与の時点で利用可能であるか及びより重要なことにそれらが何に利用可能であるかを前もって知らないかもしれない。このダイナミズムを考慮するため、サービス機能１１４，１１５は設計時点でなく実行時に発見され組み合わせ可能にされる必要がある。従ってここで説明される実施例は、一例としてセマンティックウェブ技術を利用し、その理由はコンピュータネットワークリソース１１４，１１５がマシン読取可能なセマンティクス１１６によりそれ自身充分に記述されていたならば、或るインフラストラクチャ１００を構築することができ、そのインフラストラクチャはコンピュータシステムサービス１１０のようなリソース１１４，１１５を充分に理解し、アプリケーション開発者が一般的に行うことを、リソース１１４，１１５が提供するもの及び何のために利用可能であるか等の開発者自身の知識を利用することで、エンドユーザが行うことを可能にするからである。セマンティックウェブの概念は周知である。

より具体的には、ここで説明される実施形態によれば、タスクコンピューティング１００はセマンティックウェブ及びウェブサービスの周知の概念を利用する。しかしながら、真に動的なアドホックなユビキタスコンピューティング環境で実際の機能システムを実現するために、ここで説明されるタスクコンピューティング１００では、以下のことが設定及び実行される：
（１）図１に示されるように、機能に関するコンピュータシステムソース１１０に対するタスクインターフェースを用意する。タスクインターフェース１３０は、（１）タスクコンピューティングクライアント（ＴＣＣ）１１９を有するプレゼンテーションプロセシングレイヤ１０４、（２）ミドルウエアサーバープロセシングレイヤ１０８（プレゼンテーションレイヤ１０４でのＴＣＣ１１９がタスクコンピューティング環境（ＴＣＥ）ウェブサービスＡＰＩ１０６（例えば、STEER-WSAPI１２０及びPIPE-WSAPI１２２）のようなリモートプロシジャコールメカニズムＡＰＩ１０６とインターフェースをとる）に論理的にセグメント化されたタスクコンピューティングシステム（ＴＣＳ）１１８を有する。ＡＰＩ１０６は、プレゼンテーションプロセシングレイヤ１０４によりインターフェースされるミドルウエアサーバープロセシングレイヤ１０８を明らかにする。タスクインターフェース１３０も、サービス機能１１５を意味論的に記述するセマンティックサービス記述（ＳＳＤ）１１６を有する。ＳＳＤ１１６はＴＣＣ１１９を介してプレゼンテーションレイヤ１０４で示されるミドルウエアプロセシングレイヤ１０９によって発見され、サービス機能１１５は、例えば実行されるタスク１２６の一部として、用意された制御コマンドに従って、例えば、ＴＣＣ１１９を介してプレゼンテーションレイヤ１０４で及び実行されるサービス機能１１５のＳＳＤ１１６に基づいて、ミドルウエアプロセシングレイヤ１０８により実行される。

（２）共にサービスレイヤ１１２を提供するように、セマンティックサービス記述（ＳＳＤ）１１６及びサービス手段１１５を分離する。

（３）サービス１１２について或る範囲の探索を達成するためにリモートタスクコンピューティングクライアント１１９でアクセス可能であってコンピュータ１１０で動作するリモートプロシジャコールＡＰＩの部分集合としての「スフェア(sphere)」の概念を考察することで、（場合によっては、サービスの又は保存されたタスクの）探索の仕組み、探索範囲及びサービスの操作機能をそれらの範囲の中で及び間で分離する。

（４）サービスを動的に作成及び操作するユーザ（及びアプリケーション）の能力は、利用可能であり（ユーザには能力があり）、他の者と共有可能である（或いは、必要に応じて共用できなくしてもよい。）（即ち、サービスコントロールマネジメントを行う。）。

（５）興味のある及び真に有益なタスク１２６を実行可能にする様々なサービス１１２を用意する。

従って図１Ａに示されるように、上述のレイヤの分離は、論理的なもの及び実現的なもの双方に関連し、タスクコンピューティング１００を構築するのに有益であり、ユーザは複雑なタスクを実行することができ、そのタスクはコンピュータネットワークシステムで（黙示的にも明示的にも）設計されていなかったものであり、かくてユーザのソース機能１１４，１１５（装置、アプリケーション、コンテンツ及びｅサービス）を増やす。本発明はセマンティックウェブに限定されず、（データがアプリケーション、企業及び集団の境界を超えて共有及び再利用されることを可能にする）他の意味論的なタイプの技術やフレームワークがここで説明される実施例で使用可能である。

図１Ａでは、機能ソース実現レイヤ１１４は、最低レイヤとして示され、コンピュータ装置、コンピュータアプリケーション／ソフトウエア、電子サービス及びコンピュータ（又はマシン若しくは双方で）読取可能なコンテンツ等の領域を網羅し、ユーザに利用可能な全ての機能が生じる。機能ソース１１４のサービス機能１１５（以下で更に詳細に説明される）は機能性に関する演算例である。そのようなサービス機能１１５は一般に少なくとも３つの異なるタイプのソース１１４（装置、アプリケーション（ソフトウエア）及びオーバーザウェブｅサービス）から発する。これら３つのソース１１４は厳密に手ではなく緩やかに定義され、カテゴリを限定していない。なぜならそれらの間の境界は融通性が高いからである。一例として、サービス１１５を発する装置１１４は、装置１１４がもたらすように設計された中核的な（コアの）機能である。例えば、電話（装置）１１４の主な機能は電話呼出（サービス）１１５を行うことである。同様に、機能を発するアプリケーション（ソフトウエア）１１４は、コンピュータ装置１１４で実行するソフトウエア１１４のサービス機能１１５である。例えば、個人情報管理(PIM: Personal Information Management)アプリケーションの機能は、人の連絡先情報を記憶及び検索することを含む。最後にｅサービス及び／又はコンテンツ１１４サービス機能１１５は、例えば、ユーザのローカルなネットワークの境界を越えてウェブサービスを介してサービス機能１１５をもたらす何らかのリモートサーバーで動作するサービス機能１１５である。第４のソース機能１１４のようなコンテンツは非常に有用であり、そのコンテンツはサービス機能１１５として利用可能にされ；このタイプのサービス機能１１５は、ユーザ間での情報共有手段として非常に有用である。従って「サービス」１１２はここでは、コンピュータ装置の機能ソース実現レイヤ１１４、コンピュータアプリケーション／ソフトウエア、電子サービス及びコンピュータ（又はマシン若しくは双方で）読取可能なコンテンツの分野からの機能の演算例に関連する。従って機能ソース実現レイヤ１１４からの機能の演算例としての「サービス」１１２は、「サービス」１１２とやりとりするインターフェース特性を有し、それは、サービス名、実行される機能等を含む「サービス」の記述、及び「サービス」１１２に対する入力／出力のようなサービスの機能特性を有する。さらに、ここで説明される実施形態によれば、コンピュータシステムサービス１１０用にコンピュータで使用されるユーザインターフェースは意味論的に記述された「サービス」１１２の出力データ及び入力データに基づくオントロジに従う。例えば、ディスプレイプロジェクタにファイルを表示するためにセマンティックサービス記述１１６に記述されたサービス１１２は、「プロジェクタで表示」と名付けられ、入力としての「ファイル」を受け入れ、何らの出力パラメータもない。

図１Ａでは、サービスレイヤ１１２はセマンティックサービス記述（ＳＳＤ）１１６を介してサービス機能１１５として演算に利用可能にされた機能のソース１１４である。ＳＳＤはサービス機能１１５を発見しそれにアクセスすることを可能にする。各サービス機能１１５は少なくとも１つのセマンティックサービス記述（ＳＳＤ）１１６に関連し、例えばＯＷＬ−Ｓに従ってエンコードされ、ＯＷＬ−Ｓはウェブオントロジ言語（ＯＷＬ）に基づくウェブサービスオントロジ言語であり、リソース記述フレームワーク（ＲＤＦ）／拡張可能マークアップ言語（ＸＭＬ）交換シンタックスを利用し、サービス１１５が動的に作成されるように（利用可能にされるように）、ＳＳＤ１１６はＰＩＰＥ−ＷＳＴＣＳ１１８ｂを介して実行中に（オンザフライで）作成可能である。説明されるＳＳＤの例はＯＷＬ−Ｓの例に限定されず、ウェブサービスを含む、コンピュータシステムサービス機能１１５の特性及び機能を記述するコンピュータで解釈可能な如何なる言語構造でも利用可能である。ＳＳＤ１１６は３つの部分を有し、それらは：プロファイル、プロセス及びグランディング(grounding)であり、プロファイルの部分はユーザがサービス１１５を実際に起動可能にする。サービス１１５はタスクコンピューティング領域１００で利用可能な機能を表現し、これらのサービス１１５のＳＳＤ１１６は、サービス機能１１５のソースに関する複雑さからユーザを隠蔽し、関心のある複雑なタスクを実行する際にそれらのサービス機能をユーザが利用しやすくすることになっている。意味論的に記述されたサービス１１６の例は関連する米国特許出願番号第10/733,328号及び第11/115,403号でも説明されており、その全内容は本願のリファレンスに組み入れられる。

図１Ａでは、ミドルウエアサーバープロセシングレイヤコンポーネント１０８はサービス１１５，１１６（又は１１２）を発見する責務を有し、サービス１１５，１１６が実行可能なタスクにどのように構成可能であるかを決定し、サービスを実行し、実行したサービスを監視し、（意味論的に記述されたサービス１１６の作成及び公表を含む）様々な管理動作を可能にする及び支援する。言い換えれば、ミドルウエアサーバープロセシングレイヤコンポーネント１０８の目的は、全てのサービスリソース１１５を意味論的に記述されたサービス１１６として抽象化することであり、そのサービスは、それらを操作するよう求めるアプリケーションに又はユーザに（例えば、ＴＣＣ１９９を介してプレゼンテーションレイヤ１０４で）利用可能にされることが可能である。

図１Ａでは、プレゼンテーションプロセシングレイヤ１０４はミドルウエアプロセシングレイヤ１０８の機能を利用して、全ての利用可能なサービス機能１１６，１１５（１１２）を結合することでユーザがタスクを実行可能にする。ＷＳＴＣＣ、ＷＳアプリケーション及び／又はＷＳウェブベースインターフェースアプリケーション（ウェブブラウザと共にアクセス可能である）と呼ばれる（ここでは全てＷＳＴＣＣと呼ばれる）ウェブサービス１１８ａ−ｎを用いる様々なプログラム可能なコンピューティングクライアント（例えば、ソフトウエアクライアント、プログラマブルコンピューティングハードウエアクライアント、又は双方等）が用意され、ミドルウエアプロセシングレイヤ１０８を介して利用可能な全てのサービス機能１１２を結合することでタスクを実行する。ここで説明される実施形態によれば、ミドルウエアレイヤコンポーネント１０８は、明確なウェブサービスアプリケーションプログラミングインターフェース（ＷＳＡＰＩ）１０６を介して明らかにされ、それにより、これらのＡＰＩ１０６を用いるＷＳタスクコンピューティングクライアント（ＷＳＴＣＣ）１１９の生成を可能にする。

サービス１１２の発見、構成、実行、保存、生成、管理のようなタスクコンピューティングのコア機能に制限無くアクセスするミドルウエアプロセシングレイヤ１０８でタスクコンピューティング環境ウェブサービスＡＰＩ１０６を規定することは、列挙された機能全てを開放する。例えば、ＷＳＴＣＳ１１９は、ユーザがウェブサービス１０６を呼出可能にする限り、タスクコンピューティングの特定の実現手段に拘束されず、ユーザは如何なるプラットフォームでも作業することができ、ＷＳＴＣＣ１１９を作成し及びサービス１１２にアクセスするのに如何なるプログラミング言語でも利用できる。

図１Ａでは、従って、ここで説明される実施形態によれば、タスクコンピューティング環境ウェブサービス（ＴＣＥ−ＷＳ）ＡＰＩ１０６が提供される。ＴＣＥ−ＷＳＡＰＩ１０６の部分集合（サブセット）は様々なタスクコンピューティングの目的に使用可能であり、STEER−WSTCS１１８ａで使用される場合にはSTEER-WSAPI120と、1以上のPIPE-WSTCS118ｂで使用される場合にはPIPE-WSAPI122と、クロス環境タスクコンピューティングの「スフェア(Sphere)」を用意するのに使用される場合にはスフェアオブマネジメント（SoM）-WSAPI１２３と言及される。本発明の実施例が以下に説明される：
セマンティックタスク実行エディタウェブサービス（ＳＴＥＥＲ−ＷＳＴＣＣＣ）１１９ａのような様々なウェブサービスタスクコンピューティングクライアント（WSTCC）１１９ａの例が詳細に説明され、それはSTEER-WSAPI１２０に基づき、意味論的に記述されたサービス１１６を発見し及び実行可能なタスクに構成するソフトウエアである。WSTCS118のプレゼンテーションレイヤ１０４コンポーネント１０８のようなSTEER-WSTCC119aは、様々なコンピュータで実現されるユーザインターフェースを用意する。関連する米国特許出願番号第10/733,328号及び11/115,403号は、STEER-WS拡張（XT）TCC119a-1に関連するコンピュータ表示グラフィカルユーザインターフェース、移動電話のような無線装置で実施されるコンピュータ表示グラフィカルユーザインターフェースを説明しており、それらは移動電話STEER-WSTCC119a-2、STEER-WS空間情報システム（SIS）TCC119a-3、音声STEER-WSTCC119a-4及びタスクレット-WSTCC119a-5と呼ばれる。本発明の一実施例によるタスクレットWSTCC119a-5が以下に説明される。

ユーザインターフェース−STEER-WS-XT TCC119a-1：
図１Ｂは本発明の一実施例による、プレゼンテーションレイヤでのSTEER-WS-XTTCC119a-1によるコンピュータで実現されるタスクインターフェースとしてコンピュータに表示されたグラフィカルユーザインターフェース画像である。図１Ｂでは、コンピュータ表示グラフィカルユーザインターフェースウインドウ１４２は、発見されたサービス１１２ウインドウ（又は、発見プレーン）であり、そのウインドウは発見されたサービス１１２のアイコンツリー構造に従って表示される。ここで説明される実施形態によれば、サービス１１２は、（限定ではないが）、愛称（フレンドリネーム）、サービスタイプ、アルファベット順等のようなオントロジ及び／又は他の特性に基づく何らかのタイプのサービスカテゴリ階層に従って、発見サービスウインドウ内で組織される。コンピュータ表示グラフィカルユーザインターフェースウインドウ１４４はタスクウインドウ１４４（又はタスク１２６構造プレーン）であり、多数の入力／出力に関するサービス１１２の非線形サービス構造を収容するよう意図されたサービスグラフである。図１Ｂでは、タスクウインドウ１４４は、非限定的に、５つのサービス１１２を含むタスク１２６を表示する。特に、タスク１２６は「マイコンタクト１１２からホームアドレス１２２及びビジネスアドレス１２２へのルート１１２をマイプロジェクタ１１２で表示する」である。

図１Ｂではここで説明される実施形態に従って、ＳＳＤ１１６ウインドウ１５０は、サービスウインドウ１２２で選択されたサービス１１２について、ＳＳＤ１１６パラメータ／特性を表示する。ＳＳＤウインドウ１３５は、例えばタスク１２６の一部としてタスク１２６を検査する際に活用できる。

図１Ｂでは、タスクウインドウ１４４はサービス１１２の選択可能な図形表示を提供し、そのサービスは発見サービスウインドウ１４２で選択されたものである。タスクウインドウ１４４では、発見されたサービス１１２の選択時に、オントロジに基づいてサービスの機能特性に従うコンパチブルなサービスが自動的に見分けられ、サービス１１２の図形表示も自動的に１以上の選択可能な機能特性ボタン１４５ａ−ｎを有し、そのボタンは選択された発見されたサービスについて利用可能な又は有効な（両立可能な）サービス１１２を表す。機能特性ボタンを選択すると、先行するサービス１１２の成果を利用可能な他の発見済みサービス１１２の選択可能なリストが表示され、サービス１１２の図形表示をつなぐ表示された線で示されるように、１以上のサービス１１２を構成することは、或るタスク１２６を作成する。より具体的には、タスクウインドウ１４２の中で、ユーザはタスク１２６として指示したサービス１１２のグラフを構成する。サービス１１２の入力／出力データオブジェクトタイプをサービス１１２の機能特性として用いる場合には、出力機能特性ボタン１４５ａは、着色によって又はコンピュータ表示を区別する既知の何らかの方法によって、入力機能特性ボタン１４７と区別される。

図１Ａ及び図１Ｂを参照するに、タスクコンピューティングシステム１００は或るアークテクチャを有し、そのアーキテクチャは、現在の環境で利用可能なサービスを発見し、利用可能なサービスのユーザ中心の観点によるタスクを構築及び処理し、複数のサービスで構成される結果のタスクを実行するための基礎を与える。必要ならば、エンドユーザさえも新たなサービスを動的且つ簡易に作成する。タスクコンピューティングシステム１００の３つの特性／要素(1),(2),(3)は次のとおりである：
（１）サービス１１２として全ての機能１１４，１１５の一様な抽象化。ここで説明されるように、タスクコンピューティング１００では、ミドルウエアサーバープロセシングレイヤ１０８は意味論的に記述されたサービス１１２として全てのリソースを抽象化するよう機能する。意味論的に記述されたサービスは、（限定ではないが）ＷＳＤＬ（ウェブサービス記述言語）、ＵＰｎＰ（ユニバーサルプラグアンドプレイ）、ＣＯＲＢＡ、ＲＭＩ、ＲＰＣ、ＤＣＥ、ＤＣＯＭサービス機能１１５のようなリモートプロシジャコールを介して利用可能なサービス機能１１５であり、サービスを記述するための言語（例えば、ＯＷＬ−Ｓ）におけるセマンティック記述（ファイル）１１６が指定される。そのようなセマンティック記述１１６を指定すると、指定されたオントロジはそのサービス１１６，１１５（１１２）が動作する領域について具体化される。オントロジに関し、ソフトウエアツールが、オントロジを作成するために、及び可能性のある存在する又は利用可能なオントロジが利用可能なときはいつでも使用可能である。ＯＷＬ−Ｓサービス記述１１６は、サービス機能１１５の機能特性を表現し、その機能は例えば入力及び出力をセマンティックオブジェクトとして、及びオーナー、創作者、ロケーション等とサービス１１２に関して意味付ける。その記述は、実際のＷＳＤＬ及び／又はＵＰｎＰサービスが適切に実行可能になるようにする基礎情報を含む。これらの記述を用意する際に、セマンタイザツール（限定ではないが、ここで説明及び／又は言及されたリアルワールドオブジェクトセマンタイザ119b-4、データベースセマンタイザ119b-5、インターナルサービスインスタンスクリエータ等）は、オントロジオブジェクトをWSDLパラメータにマッピングし、何らかの必要な基礎情報（基礎情報（グラウンディング）はXSLTスクリプトを介して表現される）を作成するのに使用される。ウェブサービスインターフェース１０６はミドルウエアサーバープロセシングレイヤ１０８用に用意され、それに基づいてプレゼンテーションクライアントプロセシングレイヤ１０４での直感的なタスク１２６ユーザインターフェースが用意される。

タスクコンピューティングミドルウエアはセマンティックサービス記述の動的なリポジトリ(repository)と見ることもできる。ここで説明されるこれらの記述にアクセス及び操作するためのＡＰＩ１０６とは別に、ＡＰＩを実行することでそのリポジトリのディレクトリを問い合わせるための手段が用意され、ＡＰＩはサービス記述に対する如何なるＲＤＦ問い合わせ言語（ＲＤＱＬ）クエリをも処理する（ＪＥＮＡ２．０はＲＤＱＬクエリの処理例として使用される。）。例えば、開発者はロケーションのようなサービスの何らかの特性によりタスク合成用にユーザに提示されたサービスを、たとえその目的に対する明示的なＡＰＩが用意されていなかったとしても選別できる。この能力はアプリケーション開発者の力を伸ばし、或るクエリがより有用になるので、それらはミドルウエアにＡＰＩ１０６（事前に選択されたＲＤＱＬクエリを実行する）として永続的に加えられてもよい。或る実施形態によれば、ＳＳＤにおけるサービスの意味論的記述を調べることによるユーザに対する発見されたサービスとユーザのコンテンツとの関連性に基づいて、ＳＳＤを発見した発見手段に基づいて、或いは各サービス又はそれらの如何なる組み合わせの機能特性で決定されたＳＳＤに従うサービスコンパチビリティに基づいて、発見されたＳＳＤは、動的に選別され発見されたサービスになる。

サービス１１２としての機能の抽象化は機能を一般にアクセス可能にし、タスクコンピューティングインフラストラクチャがそのような機能とやり取りすることを可能にする。タスクコンピューティングシステム１００は、ユーザのコンピュータ装置の（アプリケーション及びＯＳによる）、環境中の装置の及びインターネット上で利用可能なｅサービスの機能１１４，１１５を抽象化されたサービス１１２に変換する。この抽象化はその環境で利用可能な機能を処理するための事前の用意を減らす道を開くが、それ自身単独で、ユーザにリアルタイムの操作能力及び機能をタスク１２６に構成する能力を与えるには充分でなく、ここで説明される実施例はプレゼンテーションレイヤ１０４を用意し、リアルタイムの、動的なタスク（複数のサービスを有するタスク）の管理をサポートする。

（２）セマンティックサービス記述（ＳＳＤ）１１６に基づいて抽象化されたサービス１１２の直感的な操作性を（ユーザに及び／又はシステムに）与えること。サービス１１２の直感的な操作性は、セマンティックサービス記述（ＳＳＤ）１１６の利用を通じて可能になる；オントロジはそのようなユーザ及び／又はシステムの直感的な操作を達成するための仕組みである。ＳＳＤ１１６の概念は、関連する米国特許出願第10/733,328号及び／又は第11/115,403号にも記載されており、その全内容は本願のリファレンスに組み入れられる。

例えば、ＳＳＤ１１６の代わりに、ＷＳＤＬ（ウェブサービス記述言語）機能ソース１１５だけがウェブサービスの機能特性を記述するのに使用される場合、ＷＳＤＬベースのウェブサービスは、プログラマがそれらの意味を（ＷＳＤＬ記述内容以上に）理解し且つ適切にそのサービスを利用するためのコードを開発する必要がある。その結果、機能に関するエンドユーザのやりとりは、開発者により事前に決められたそれらのプログラムの範疇に制限される。オントロジオブジェクトをソース機能１１５パラメータ（例えば、限定ではないが、ＷＳＤＬパラメータのようなパラメータ）にマッピングし、及び何らかの必要な基礎情報を作成することによる追加的なセマンティクス（ＳＳＤ１１６で供給される）は、タスクコンピューティング１００インフラストラクチャが、ユーザが詳細な知識なしにそのサービスを操作することを支援することを可能にする。例えば、セマンティクスはユーザによるサービスの操作を制約するために、又はその環境で可能性のあるタスク１２６についてユーザを禁止するために使用可能である。ＷＳＤＬだけがサービスのセマンティック入力及び出力に基づくサービス構成を当てにしているならば、その構成はサービスの如何なる構成にも制約されず、例えば、ＸＳＤストリングを使用する別のものと共にＣＭＬスキーマ定義（ＸＳＤ）ストリングを生成し、おそらくは実行可能でない（無効な）サービス構成を導出する。従ってここで使用される実施形態によれば、「構成(composition)」は、（限定ではないが）例えばサービス１１２の入力（消費）／出力（生成）用のデータオブジェクトタイプのサービス１１２の意味論的な入力及び出力のような、意味論的に記述されたようなサービス１１２の用意された機能特性に従って複数のサービス１１２を共に置くことで形成されることに関する。サービスの機能特性の具体例は、サービス構成を決定するためのサービスの前提条件及び影響でもよい。サービス１１２の前提条件及び影響の具体例は、サービス１１２に関する入力及び出力データオブジェクトタイプでもよい。特に、サービス１１２のＳＳＤ１１６は微細な粒度のサービス入力及び出力をもたらし、例えば、「アドレス」セマンティックオブジェクトを生成するサービスは意味論的に両立性のあるサービスと共にだけ構成可能でもよい。

ユーザの直感的なサービス１１２の操作の別のメカニズムは、「マイホームからのルート」のようなサービス名のような自然言語に従って適切なサービス名を与えることによるものであり、コンパチブルなサービスの構成サービス名は自然言語タスク１２６表現として機能してよい（例えば、「プロジェクタで見る」１１２＋「マイファイル」、１１２「カンパニー1からのルート」１１２「都市名空港」１１２）。オントロジは、サブクラス−スーパー−クラス関係に基づく構成のようなメカニズム、及びエンドユーザにとって非常に自然な意味論的オブジェクト変換をサポート可能である。従ってタスク１２６の構成は自然言語文に基づく、或いは換言すれば構成されたタスク１２６は自然言語文のように読める。より具体的には、ここで説明される実施例は、生前言語シーケンスの要素（例えば、フレーズ）のようなサービスに名称を割り当て、自然言語文のような自然言語要素の構成に対応付けるためのサービスの構築性をサポートする。従ってタスクコンピューティングシステム１００はエンドユーザが環境１１０のサービスとやりとりするのに非常に豊富で興味深い方法を可能にする。

（３）ユーザは例えば図１Ｂに示されるような（１）及び（２）に基づいてコンピュータ実現ユーザインターフェースを介してタスク１２６のリアルタイムの及び／又はダイナミックな（後に結合する形式の）構成を行うことができる。

ウェブサービスアプリケーションプログラムインターフェース(TCE-WSAPI)106：
図２は本発明の一実施例によるSTEER-WSAPI１２０の定義リスト例を示す。図１Ａ及び１Ｂでは、STEER-WSTCC１１９ａはWSTCC119であり、サービス１１２を発見し、選別し、構成し、実行し、タスク１２６としてサービス１１２を保存するのに便利なユーザインターフェースをもたらす。STEER-WSAPI１２０は、TCE-WSAPI１０６であり、独立モジュールからタスクコンピューティング機能を抽出し、例えばSTEER-WSTCC１１９ａのような何らかのWSTCC199によりアクセス可能な標準的なウェブサービスインターフェースとしてそれらを明確にする。

図２に示されるように、ウェブサービス１０６によるタスクコンピューティングミドルウエアサーバー処理レイヤ１０８の機能を明らかにすることで、プレゼンテーションプロセシングレイヤ１０４でのWSTCC１１９は、タスクコンピューティングミドルウエアサーバープロセシングレイヤ１０８のモジュールの実現手段から開放可能である。WSTCS１１９開発者は、ウェブサービス１０６の呼出がなされない限り、如何なるオペレーティングシステムで如何なるプログラミング言語も利用でき、WSTCC119をもたらす。ウェブサービス呼出を実行可能な（又はウェブサービス呼出機能を組み込むことが可能な）第三者のアプリケーション（マイクロソフトワード、エクセル、アウトルック、アドーブアクリバット等）さえ潜在的なWSTCC119でもよい。

図２では、発見、構成、実行、監視、保存等のような機能がSTEER-WSAPI１２０でサポートされている。一般に、STEER-WSAPI１２０及びPIPE-WSAPI１２２のようなTCE-WSAPI１０６はサービス１１２識別子（SID）パラメータを当てにし、そのパラメータはSSD１１６で記述された意味論的に記述された或るサービス機能１１５を固有に特定するものである。典型的には、ここで説明される実施例によれば、SIDはSSD１１６で記述された意味論的に記述されたサービス１１５へのユニフォームリソースロケータ（URL）の文字列である。例えば、図３Ａは発見されたサービス１１２に関するローカルな情報に同期するためにSTEER-WSAPI１２０を利用するコンピュータソースコード３００の例を示す。図３Ｂは複数のサービス１１２と共にタスク１２６を起動するSTEER-WSAPI１２０を用いる別のコンピュータソースコード例３１０を示す。非限定的な例として、図３Ｂでは、サービスリストパラメータは例えば“＆”を用いて複数のタスクを区別し且つ“｜”を用いてタスク内のサービス１１２識別子を区別する入力文字列であり、WSTTCC１９９はタスクの実行を起動及び監視するために自身のコード中に図３Ｂのプログラムループを有することができる。従って本発明では、図３Ａ−３Ｂのようなソースコードは、TCEWSAPI１０６を用いてミドルウエアサーバープロセシングレイヤ１０８のリモートプロシジャを起動し、STEER-WSTCC１１９ａのようなＷＳＴＣＣ１１９の実現例である。

図４は本発明の一実施例によるSTEER-WSTCC119aのミドルウエアプロセッシングレイヤ108プログラムモジュールの機能ブロック図である。図１及び図４に示されるように、STEER-WS-TCC119aのミドルウエアプロセシングレイヤ１０８はセントラルモジュール４０２を有し、そのモジュールは、プレゼンテーションプロセシングレイヤ１０４からのSTEER-WSAPI１２０を介するウェブサービス１０６要求に従って、サービス１１２の発見モジュール４０４、実行モジュール４０６及びモニタモジュール４０８を制御する。セントラルモジュール４０２は、サービス１１２分解及びインデックスモジュール４１０と、サービス１１２構成及びタスク１２６実行計画部４１２とを有する。サービス１１２分解及びインデックスモジュール４１０はインターフェース４１２を登録し、発見モジュール４０４が、発見したサービス１１２を登録すること／登録抹消することを可能にする。発見モジュール４０４は、ローカル発見モジュール４１４、ＵＰｎＰのような第三者サービス機能１１５発見モジュール４１６、リモートサイト発見モジュール４１８及び発見モジュール管理部４２０のような個々の発見モジュール群を有し、管理部４２０は、各発見モジュールが様々な環境１１０で使用されるべきか否かを判定する管理機能を有する。

ここで説明される実施形態によれば、ローカルサービス発見部４１４、第三者サービス発見部４１６、リモートサイトサービス発見部４１８、テンポラリサービス発見部４２８、ネイティブ（固有）サービス発見部４２６又はそれらの如何なる組み合わせによるものの１以上を含む複数の発見手段に従って関連するＳＳＤ１１６を発見することで、サービス機能１１５を発見する。ローカルサービス発見部４１４は、「ソケット」ポートを開き、同じ装置（コンピュータ）で起動されたアプリケーションからのＳＳＤ１１６公表メッセージを監視し、その装置でローカルサービス発見モジュール４１４が実行される。例えば、アプリケーションが始まると、アプリケーションは或るＳＳＤ１１６を公表し、ＳＳＤ公表メッセージを、通知を受けるためにローカルサービス発見部４１４により開かれた所定の「ソケット」ポートに送信する。本実施形態によれば、そのアプリケーションからのローカルサービス発見部４１４により受信されたＳＳＤ公表メッセージは、公表されたＳＳＤ１１６のロケーションを含む。そして、ロケーションサービス発見モジュール４１４がＴＣＣ１１９に利用可能なＳＳＤ１１６を作成する。

第三者発見部４１６は第三者発見標準規格を用いてＳＳＤ１１６を発見する。第三者発見メカニズム４１６は、例えば、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）技術、ジニ（ＪＩＮＩ）技術、ブルートゥース等又はそれらの如何なる組み合わせでもよい。例えば、サイバーリンクＵＰｎＰ及び／又はインテルＵＰｎＰツールキット手段をダイダン社発見モジュール４１６で使用し、ＵＰｎＰによるサブネットワーク内でブロードキャストされたサービス記述を発見してもよい。リモートサイト発見部４１８はリモートウェブサービスに対するウェブサービスプロトコル（ウェブサービスコール）を用いて、ウェブサービスインターフェースにより識別可能なＳＳＤを発見する。

ここで説明される実施形態によれば、ヒューレットパッカード開発会社によるＪＥＮＡがＳＳＤ１１６を格納するのに使用される。分解及びインデックスモジュール４１０は、ＳＳＤ１１６を分解及び分析するための分解及び分析する機能を有する。例えば、ここで説明される実施形態によれば、ＳＳＤ１１６はヒューレットパッカード開発会社によるＪＥＮＡを用いて、アメリカ合衆国メリーランド大学のＭＩＮＤＬＡＢによるペレット（ＰＥＬＬＥＴ）及びＯＷＬ−ＳＡＰＩと共に分解される。特に、「サービス１１２が発見されること」は「或る機能ソース１１４（例えば、デバイス、ソフトウエア１１４）のサービス機能１１５を意味論的に表現するＳＳＤ１１６が発見されること」と等価である。ＳＳＤ１１６は、サービス発見モジュール４０４の何れかにより発見可能であり、登録インターフェース４２２を介してセントラルモジュール４０２に送信され、ＳＳＤ１１６が例えばペレットのサポートと共にＪＥＮＡにより最初に分析される。ＳＳＤが分析されると、ペレットはＲＤＱＬクエリに対する回答する準備を行う。サービス分析及びインデックするモジュール４１０から問い合わせることで及び問い合わせ結果に基づいて、サービス構成及びタスク実行計画モジュール４１２はタスク１２６としてのサービス１１２の構成を想定し、ＴＣＣ１９９からのタスク１２６実行命令に応答してタスク１２６の実行計画を決定する。実行計画が決定されると、中央モジュール４０２は実行モジュール４０６を介して関連するサービス機能１１５を呼び出し、その実行モジュールはサービス機能１１５を呼び出すためにＳＳＤ１１６に用意されたグラウンディング呼び出し部(grounding invocation)４２４を有する。発見モジュール４０４は、サービス機能１１５及びセマンティックサービス記述（ＳＳＤ）１１６を含み得るサービスを発見する。サービス１１２分解及びインデックス部４１０の上記の説明は、そのようなコンフィギュレーションに限定されず、ＪＥＮＡ及びペレット以外のＳＳＤ１１６を分解及び分析する如何なる仕組みも利用可能である。

ここで説明される実施形態によれば、独立したモジュールとして、ＷＳＴＣＣ１１９は、（例えば、基礎をなすブルートゥースＳＤＰ、ＩＲ、ＲＥＮＤＥＺＶＯＵＳ、ＪＩＮＩ等４０４，４０６についてウェブサービスインターフェース１０６を実現することで）統合される及び高度に抽象化される発見及び実行手段がウェブサービスＡＰＩ１０６に従って実行可能である限り、如何なる種類のサービス１１２発見手段４０４又は実行手段４０６をも使用可能である。従って、例えば、ユーザが特定するのに唯一必要なものは、サービスレイヤ１１２とのインターフェースをとるためのSTEER-WSAPI１２０用のウェブサービス定義言語（WSDL）ファイルのユニフォームリソースロケータ（URL）である。ウェブサービスＡＰＩ１０６が用意される限り、ＴＣＥ−ＷＳＡＰＩ１０６により基礎をなす発見手順全体が、プレゼンテーションレイヤ１０４でＷＳＴＣＣ１１９におけるユーザにとって透明(transparent)である。例えば、或るSTEER-WSAPI１２０は、ブルートゥースベースのサービス１１２を発見及び実行するためにブルートゥース発見モジュール４０４を利用することができる。別のSTEER-WSAPI１２０はＵＰｎＰ発見モジュール４０４を利用することができる。

一形態に従って、以下の２つのサービス１１２発見法が説明される：（１）ネイティブサービス発見モジュール４２６；及び（２）テンポラリサービス発見モジュール４２８。ここで説明されるように、サービス１１２の発見は、サービス機能１１５に関連するＳＳＤ１１６の効果的な発見になる。ネイティブサービス発見モジュール４２６はワンタイムファイルベースの発見モジュール(one-time file-based discovery function)である。いくつかのサービス１１２は頻繁に使用され、定常的に利用可能になるよう望まれる。例えば、「常にオン(ON)の」ウェブサービス１１５（例えば、アマゾンウェブサービス）に基づく又はグラウンディングのないWSTCS118(STEER-WSTCS118a)により実行可能な或るサービス１１２が存在する。一形態によれば、「常にオンの」ウェブサービス１１５では、そのウェブサービスの利用可能性はタスクコンピューティングシステム１１８の実行状態に関係しない。多くの場合、第三者ベンダはそのような「常にオンの」ウェブサービス１１５を用意するかもしれない。これらの「常にオンの」ウェブサービスに関し、関連するサービス記述１１６は固定されてもよい。なぜなら、（ウェブサービス１１５が提供されている場所のような）そのウェブサービス１１５に関する情報は不変だからである。従ってそのような「常にオンの」サービス１１５について、「固定された」（常に一定であることを意味する）サービス記述１１６を作成することが可能である。そのような場合、コストのかかる動的なサービス発見手段（例えば、関連する米国特許出願番号第10/733,328号及び第11/115,403号で説明されているようなPIPE-WSTCS１１８ｂによる手段）は不要である。

ネイティブサービス発見モジュール４２６は、固定された記述を含み且つ頻繁に使用されるサービス１１２に関してワンタイムライトウエイト発見モジュールである。一実施形態によれば、ネイティブサービス発見モジュール４２６は、STEER-WSTCS１１８ａのようなＷＳＴＣＳ１１８の初期開始段階で一度だけ動作する。例えば、STEER-WSTCS118aは指定されたディレクトリ（例えば、デフォルトの「マイドキュメント＼マイサービス」）でサービス１１２として発見された全てのサービス記述ファイル１１６をロード又は設置し、これら発見されたサービス１１２をSTEER-WSTCS118a（例えば、発見されたサービス１１２ウインドウ（又は発見プレーン）１４２−図１Ｂ−で利用可能である）に登録する。その後に、ネイティブサービス発見モジュール４２６は閉鎖可能になる。以下の表１はネイティブサービス発見モジュール４２６とローカルサービス発見モジュール４１４との比較概要を与える。ローカルサービス発見４１４は「ソケット通信」に基づく。ローカル発見モジュール４１４は事前に形成されたソケットを開き、監視する。ローカルサービスが或るアプリケーションにより公表されると、そのアプリケーションは所定のソケットにメッセージを送信し、ローカル発見モジュール４１４により発見されるようにする。この手法は動的であり且つＴＣＣ１１９で動作する装置に局所的であると考えられる。なぜならＴＣＣ装置はＴＣＣ装置で動作するアプリケーションを介してサービスを提供しているからである。ＴＣＣのＩＰ（インターネットプロトコル）アドレスが変わると、そのサービス記述も変更されなければならない。

表１：ネイティブサービス発見モジュール４２６対ローカルサービス発見モジュール４１４

テンポラリサービス発見モジュール４２８はサービス１１２用に設計され、そのサービスは、STEER-WSTCS118aのようなＷＳＴＣＳ１１８の現在の実行セッションの中でのみ必要とされ、タスクパッケージ（後述）で使用されるそのようなサービス１１２は、ユーザがタスクパッケージのタスクレット(tasklet)と共に作業する場合にのみ必要とされる。一形態によれば、テンポラリサービス発見モジュール４２８は以下の２つのウェブサービスＡＰＩを用意する：
１．レジスタＡＰＩ（これは、入力としてサービス記述を使用し、登録が成功すればサービスＩＤを返す。）。

２．未登録ＡＰＩ（これは、サービスＩＤを使用し、何も返さない。）。

テンポラリサービス発見モジュール４２８はウェブサービスを介してユーザがサービス１１２を公表する／未公表にすることを可能にする。しかしながら、テンポラリサービス発見モジュール４２８を通じて発見されたサービス１１２は、STEER-WSTCS118aのようなWSTCS118の現在の実行セッションの中でのみの一時的なものである。例えば、STEER-WSTCS118aがリスタートされると、これらのサービス１１２はもはや発見されない。なぜならテンポラリサービス１１２に関する情報がクリアされるからである。

図１Ａでは、PIPE-WSTCS１１８ｂは、セマンティックオブジェクトインスタンスを公表及び管理するためのWSTCS118の別の例である。PIPE-WSAPI１２２は独立モジュールからタスクコンピューティング管理機能１２４を抽出し、「ホワイトホール」１１９ｂ−１、「サービスマネジャ」１１９ｂ−２、「リアルワールドオブジェクトセマンタイザ」１１９ｂ−３及び「データベースセマンタイザ」１１９ｂ−４のような何らかのWSTCS119によりアクセス可能な標準的なウェブサービスインターフェース１０６としてそれらを明らかにする。より具体的には、PIPE-WSAPI１２２はウェブサービスインターフェース１０６をPIPE-WSTCS１１８ｂに与え、オペレーティングシステム、アプリケーションオブジェクト、デバイスサービス等を公表することのようなサービス１１２を管理する。PIPE-WSTCS１１８ｂは例えば関連する米国特許出願番号第10/733,328号及び第11/115,403号にも記載されている。

プレゼンテーションプロセシングレイヤ１０４ユーザインターフェース：
STEER-WSAPI１２０及びPIPE-WSAPI１２２の実現は、WSTCC199用の多種多様のタスクコンピューティング１００ユーザインターフェースを用意することを可能にする。なぜなら、WSTCC199のプレゼンテーションプロセシングレイヤ１０４は、タスクコンピューティングミドルウエアプロセシングレイヤ１０８のモジュールの実現手段から開放可能だからである。WSTCS１１９のユーザインターフェース104の例はタスクレットWSTCC199a-5に関してここで説明される。

タスクレットWSTCC119a-5：
タスクレットTCC199a-5は非常に負担の軽い処理のタスクコンピューティングクライアント（TCC）119であり、サービスのOWL-Sファイルを実行する又はサービスを構成する（タスク１２６）。コマンドラインの中に含まれるOWL-Sファイルを実行するためにタスクレットTCCを形成する手法の中で、好ましい手法は実行されるOWL-Sファイルをダブルクリックすることで（或いは、他の何らかの適切なOS操作により）タスクレットTCCを呼び出すことである。タスクレットTCCがOWL-Sファイルを読み込むと、STEER-WSAPI１２０を用いることで、そのサービス又はサービス構成を実行する。タスクレットTCCはそれ自身のウインドウ中のサービス機能１１５の制御UIを示す。特に、図２を参照するに、タスクレットTCC119a-5はOWL-S記述を実行するために、「OWLS実行」API１２０を呼び出す。タスクレットTCC119a-5はOWL-S「プロセスモデル」及びタスク１２６を格納するサービスグラウンディングを利用し、「プロセスモデル」タスクレットを用意する。一実施例によれば、サービスワークフロー（及びタスクレットプラスサービスワークフロー）及びタスクパッケージが用意される。

図５Ａは本発明の一実施例によるタスクパッケージファイル構造を示す図である。一形態によれば、「タスクパッケージ」５００はサービスワークフロー情報を含むサービスワークフロータスクレット（SW-タスクレット）５０２を含む。SW-タスクレット５０２サービスワークフロー情報及びタスクパッケージ５００は、SW-タスクレット５０２に含まれる構成されたタスク１２６のSSD１１６（サービス１１２）を編集する能力及びポータビリティを改善する。「SW-タスクレット」なる用語は、意味論的に記述されたタスク１２６（２以上のサービス１１２で構成されるコンピュータ解釈可能な意味論的記述）に関連する。例えば、タスクレットTCC119a-5がOWL-Sに基づき且つOWL-Sファイルであり、ユーザがタスク１２６を格納、公表、実行及び共有するのに「プロセスモデル」タスクレットを利用可能ならば、タスク１２６を構成するサービス１１６（１１２）は一旦作成されると編集不可能になる。なぜなら、タスク１２６はOWL-S規格で規定される「プロセスモデル」に従って格納されるからである。OWL-S「プロセスモデル」は多くの方法で限定可能であり；例えば、「プロセスモデル」は実行についてだけである。従って、一実施例によれば、SW-タスクレット５０２は「サービスワークフロー」を含むように拡張される。ここでOWL-Sに基づいてタスク１２６を格納する３つの手法が概説される：
OLW-Sで規定される「プロセスモデル」は実行目的である。個々のサービスのプロセスだけが包含され、プロセスモデル以外にサービスワークフローを抽出することはできない。

「SW-タスクレット」は「プロセスモデル」プラスサービスワークフロー情報である。SW-タスクレットにより、サービスワークフローを抽出し、サービス１１２の構成としてタスク１２６をリスト化することが可能である。

しかしながら、或るサービス１１２が失われたと考えられる場合（例えば、目下の環境の中で発見されなかった場合）、その実行及び編集は失敗する。かくて「タスクパッケージ」５００は「SW-タスクレット」５０２プラス包含されるサービス１１２全ての又は全てのSSD１１６の記述である。タスクパッケージに関し、或るサービス１１２が失われていた場合でさえ、WSTCS118は（例えば、テンポラリサービス発見手段を用いて）依然としてそれらを探すことができ、タスクパッケージ５００のSW-タスクレット502に含まれているタスクの編集又は実行を続けることができる。

特に、OWL-Sファイル各々は３つの部分を含むことができる：（１）プロファイル（これは、サービス名、サービス記述（人がサービス説明を読み取ることができる記述）及び／又はセマンティック入力／出力である。）、（２）プロセス（これは、実行に関連する情報を決める。）及び（３）グラウンディング（これは、実行情報を実際の呼出方法に対応付ける。）。一形態によれば、各ＳＳＤ１１６はＯＷＬ−Ｓファイルである。また、２以上のSSD１１６のタスク１２６を記述するSW-タスクレット５０２はＯＷＬ−Ｓファイルファイルである。構成されたタスクの意味論的記述としてのSW-タスクレット５０２は、構成されたタスクのSSDに基づいて、構成されたタスク記述のSSDプロセスモデルとして実行プランを、構成された全てのSSDのサービスグラウンディングを生成し、及び後述するように構成されたタスク記述のプロファイル属性として構成されたタスクのサービスワークフローを抽出及び付加する。かくてタスク１２６を記述するＯＷＬ−Ｓファイルで又はＳＷ−タスクレット５０２で、タスクレットＯＷＬ−Ｓファイルのプロセスセクション又は「プロセスモデル」は実行プランを含み、構成されたタスク１２６中にＳＳＤ１１６用のＯＷＬ−Ｓファイルのプロセスセクションのみを包含する。従ってタスク１１２６が一旦構築されると、そこから、ＴＣＣ１１９はどのサービスが含まれているか及びタスク１２６の中でそれらがどんな役割であるかを知ることはできない。なぜなら、サービス１１２は複数のプロセスを含むかもしれないし、或いは複数のサービスが同じプロセスを共用するかもしれないからである。何れの場合も、「プロセスモデル」から、どのサービス１１２のプロセスが所属するかを特定することは困難である。換言すれば、「プロセスモデル」はサービス１１２及びプロセスの１対１の対応関係を明らかにしない。なぜなら、サービス１１２の「プロファイル」は「プロセスモデル」に含まれておらず、ＴＣＣ１１９が「プロセスモデル」タスクレットを開くことは困難であり、そのタスクレットはプロセスモデルのみを含み、タスクウインドウ（又はタスク１２６構成プレーン）１４４に示されるサービス１２２のブロックを構築するようなサービスワークフローチャートのように、ユーザがサービス１１２からタスク１２６を初期に構築した段階に戻す。

それ故に、一形態によれば、SW-タスクレット５０２はサービスワークフロー情報概念を有し、TCC１１９はSW-タスクレット５０２を開くことができ、SSD１１６を介して複数のサービス１１２を構成することでタスク１２６をユーザが構築する段階に戻す。タスクレットサービスワークフローの中で、関連するサービス１１２だけでなく、サービス１１２間の関係（或るサービス１１２の出力がどのようにして他のサービス１１２の入力に対応付けられるか等）も定義される。タスクレットサービスワークフローから、TCC119は、タスクレット／タスクパッケージをロードすること及びタスクウインドウ（又はタスク１２６の構成プレーン）１４４内でサービス１１２を構成するタスク（初期の構築段階）を表示することができる。タスクレットサービスワークフロー機能は、既存のタスク１２６をロードする機能及びそのタスク１２６がサービス１１２からどのように構築されたかを見る機能をユーザにもたらす。同一のTCC１１９に関し、タスク１２６から、ユーザはサービス１１２を付加／削除／編集することができ、TCC１１９により提供されるタスクインターフェース１３０を介して（例えば、図１Ｂ）新たなタスク１２６を生成する。これはタスク１２６「編集可能性(editability)」と呼ばれる。

例えば、サービスワークフロー情報は：（１）タスク１２６を有する多数のサービス１１６（１１２）、（２）これらのサービス１１２のＩＤ（即ち、ＳＳＤ１１６のＩＤ）及び（３）サービス１１２がタスク１２６を形成するために如何にしてリンクされたかを含む。タスクレットサービスワークフロー情報を参照することで、ＴＣＣ（タスクコンピューティングクライアント）１１９は、リンクされたサービス１１２を有するサービスワークフローとして、SW-タスクレット５０２タスク１２６の当初の設計内容を復元することができる。

図６Ａ−Ｄは本発明の一実施例によるＳＷ−タスクレット５０２のコンピュータ解釈可能なソースコードを示す。特に、図６Ａ−６Ｄは「マイファイルを開く(Open My File)」のタスク１２６を記述するためのＯＷＬ−Ｓファイルであり、そのファイルは「開く(Open)」１１６ａ及び「マイファイル(MyFile)」１１６ｂのＳＳＤ１１６を介する２つのサービス１１２で構成される。図６Ａ−６Ｄでは、SW-タスクレット５０２は有効なＯＷＬ−Ｓタスク１２６記述であり、SW-タスクレット５０２は実行可能である。図６ＢではSW-タスクレット５０２（Open My File.owls）に関し、以下のラインがサービスワークフロー情報５１２になる。

図６Ｂでは、サービスワークフロー５１２がサービスＩＤ５１６，５１８それぞれを介して２つのサービス「開く（オープン）」及び「マイファイル」の２つのサービスを特定する。更に、サービスワークフロー５１２は、「マイファイル」出力５２０及び「マイファイル」出力５２０に合致する「開く」５２２をサービス１２２（１１６）リンケージとして確認する。

図６Ｂ−６Ｃでは、プロセスフローライン５１４は、ＯＷＬ−Ｓの規格の一部であり、次のようにタスク１２６を実行するのに必要とされる。

サービスワークフロー情報を利用して、タスク１２６の詳細を容易に共有することができる。しかしながらSW-タスクレット５０２の考えられる１つの欠点は、TCC１９９は示される構成サービス全てにその詳細を正確に表示することを要求することである。なぜなら、SW-タスクレット５０２サービスワークフロー情報はサービスIDのみを与え、サービス名、サービス記述、セマンティック入力／出力のような他の重要な情報をタスク１２６の個々のSSD１１６から検索することを当てにしているからである。サービスワークフロー情報と共にSW-タスクレット５０２は、コンパクトな手法でタスク１２６の詳細を共用することを可能にするが、サービスワークフロー情報を備えたSW-タスクレット５０２はタスク１２６を編集する能力及び移植性(portability)を制限するおそれがある。なぜなら何らかのサービス１１２が見失ったと思い（例えば、現在の環境で発見されなかったと思い）、実行も編集も失敗するかもしれないからである。従ってタスクレットサービスワークフロー情報を用意することに加えて、本実施例は「タスクパッケージ」を用意する。サービスワークフローに含まれるサービス１１２がその環境内で発見可能であった場合には、そのサービスワークフローは単体でそのタスク１２６を復元するのに充分である。

図５Ａでは、「タスクパッケージ」５００は次のような３つのタイプのファイルを含むパッケージファイルである：SW-タスクレット５０２、関連するサービス５０４全体のSSD116及びインデックスファイル５０６。インデックスファイル５０６はサービスＩＤ（タスクレットのワークフロー情報に記録されている）及び関連するサービス記述５−４間の対応関係（マッピング）を格納する。一形態によれば、例えば、パッケージファイル５００はジップ（ＺＩＰ）ファイルフォーマットに従ってもよい。図５Ｂは本発明の一実施例によるジップタスクパッケージのファイルリストである。

図５Ａでは、タスクパッケージ５００は以下の部分を含むジップファイルである：「サービス」サブフォルダ（タスク１２６を構成するセマンティック記述１１６全てを格納する（例えば、オープン１１６ａ及びマイファイル１１６ｂ）、SW-タスクレット５０２（ワークフロー情報と共にＯＷＬ−Ｓフォーマットでタスク１２６を記述する）（オープンマイファイルSW-タスクレット５０２）及びインデックスファイル（services.idx）５０６（SW-タスクレット５０２に現れるサービスＩＤを、「サービス」サブフォルダ中に格納されたタスク１２６のＳＳＤ１１６に対応付ける。）。図７Ａ−Ｃは本発明の一実施例による「オープン」サービスに関する意味論的なサービス記述を表すコンピュータ解釈可能なソースコード例を示す。図８Ａは「マイファイル(MyFile)」サービスの意味論的サービス記述を表現する本発明の一実施例によるコンピュータ解釈可能なソースコード例を示す。従って図７及び８に示される「オープン」１１６ａ及び「マイファイル」１１６ｂはタスクパッケージ５００の「サービス」サブフォルダ中にある。

従って、タスクパッケージ５００のサービスサブフォルダ内に、複数のサービス機能１１５で構成されたタスク１２６に含まれる全てのサービス機能１１５のＳＳＤ１１６が格納されている。SW-タスクレット５０２はサービスワークフロー情報５１２も提供する。インデックスファイル「services.idx」５０６は（SW-タスクレット５０２で使用される）サービスＩＤ及び（サービスサブフォルダに格納される）ＳＳＤファイル１１６の間の対応関係を決める。

ＴＣＣ１１９でタスクパッケージ５００が開かれると、STEER-WSTCS１１９ａのような第１のSW-タスクレット５０２が抽出される。SW-タスクレット５０２が必要とする全てのサービス１１２が利用可能であるか否か（即ち、TCC119によって既に発見済みであるか否か）をTCC１１９は検査する。SW-タスクレット５０２サービス１１６がTCC１１９によって既に発見済みであったならば、何らのアクションもなされない。そうでなかった場合、インデックスファイル５０６から、TCC１１９は不足しているサービス１１６全ての記述を見出し、それらをテンポラリサービス発見モジュール４２８を介して公表する。SW-タスクレット５０２サービス１１６はテンポラリサービス発見モジュール４２８以外の発見手段を介して公表可能であるが、テンポラリサービス発見モジュール４２８を利用しなかった場合には、発見されたタスクパッケージ５００サービス１１６は現在のタスクパッケージのタスク構成セッションを過ぎても存続可能である。TCC119によって、不足している全てのサービス１１６が公表され及び発見されると、SW-タスクレット５０２はTCC１１９による手順のロードを再開可能である。一形態によれば、TCC119はタスクパケットファイル５００を開き、SW-タスクレット５０２を実行及び／又は編集するために（例えば、編集するために、構成されたタスクダイヤグラムを表示するために）、ＴＣＣ１１９はタスクパッケージ５００のＳＳＤから、構成済みタスク１２６の不足している又は必要なＳＳＤ１１６の如何なるものも検索する。ＴＣＣ１１９は検索されたＳＳＤ１１６を公表し、テンポラリサービス発見モジュール４２８を介してＳＳＤ１１６を登録することで、ＳＳＤ１１６をＴＣＣ１１９にとって利用可能にする。ＴＣＣ１１９はテンポラリサービス発見部４２８ウェブサービスを呼び出し、タスクパッケージ５００からテンポラリサービス発見４２８ウェブサービスに、検索されたＳＳＤ１１６を提出し、テンポラリサービス発見部４２８はウェブサービスインターフェースを介したＴＣＣ１１９からの入力ＳＳＤ１１６を受け入れる。テンポラリサービス発見部４２８ウェブサービスは、ＴＣＣ１１９による認証用に、受け入れたＳＳＤを発見したサービス１１６（１１２）として登録する。一形態によれば、テンポラリサービス発見部４２８は受け入れたＳＳＤを分析し、ＴＣＣ１１０のサービスインスタンス１１２を作成する。一形態によれば、テンポラリサービス発見部４２８により公表されたサービスは、例えば、ＴＣＣ１１９の実行セッション中に加えてテンポラリサービス発見部４２８を開始するＴＣＣ１１９でのみ利用可能である。

従ってSW-タスクレット５０２は実行可能なOWL-S記述であり、その記述は、包含されるサービス１１２のサービスワークフローに加えて包含されるサービス１１２のプロセスに基づいて、タスク１２６の実行計画を規定する。サービスワークフロー情報を有するSW-タスクレット５０２は或る特定のタグを有し、そのタグは、SW-タスクレット５０２で記述されるタスク１２６のサービスワークフローを表現する。タスクレットサービスワークフロー情報と共に、TCC119はSW-タスクレット５０２を開き、例えば、ユーザインターフェースウインドウ１４４で、包含されるサービス１１２及びそれらの関係を表示する。しかしながら、TCC119環境では、SW-タスクレット５０２の１以上のサービス１１２が、そのようなサービス１１２が発見されない又はTCC１１９に登録されていないことに起因して、不足していると考えられた場合には、開く（オープン）手順は不足情報に起因して失敗するかもしれない。かくて、タスクパッケージ５００は包含されるサービス１１２（又はSSD１１６）全ての記述及びSW-タスクレット５０２を含む。TCC１１９がタスクパッケージ５００を開くと、たとえSW-タスクレット５０２の１以上のサービス１１２が欠けていても、取り付けられたセマンティックサービス記述１１６からそのサービス１１２をロードする選択肢がユーザに与えられる。不足していたサービス１１２全てがロードされると、完全なタスク１２６が復元される。要するに、タスクパッケージ５００はタスク１２６を保存する最もロバストな(robust)方法である。サービスワークフローを備えたタスクレット及びタスクパッケージの双方は「タスク編集可能性」をサポートする。

一形態によれば、SW-タスクレット５０２及びタスクパッケージ５００双方がTCC１１９で作成可能である。例えば、ユーザが一群のサービス１１２からタスク１２６を作成した後で、ユーザはそのタスク１２６を保存するための選択肢を持つことができる。タスク１２６を保存している間、そのユーザはそのタスク１２６を、サービスワークフローを有するSW-タスクレット５０２として又はタスクパッケージ（サービスワークフロー情報を有するタスクレット−プラス−そのタスク１２６に含まれている個々のサービス１１２の記述）として保存することを決定できる。一旦ユーザがその決定を行うと、SW-タスクレット／タスクパッケージは生成可能になる。

SW-タスクレットを生成する手順は次のようにすることができる：
１．タスクのOWL-Sを「プロセスモデル」専用タスクレットとして生成する。

２．タスクのサービスワークフロー情報を抽出し、抽出されたサービスワークフロー情報をプロファイル属性としてOWL-Sに加える。一形態によれば、ユーザはTCC１１９（例えば、STEER-WSTCS119aに関する図１Ｂ）内でタスクを生成する場合に、サービスワークフロー情報がSTEER-WSTCS119のエディタから抽出される。一形態によれば、図１Ｂでは、表示された構成されたタスクダイヤグラムはデータ構造で表現され、或る抽出手順は、編集を含むユーザのタスク構成をタスクデータ構造から分析し、サービスワークフローを算出／決定し、例えば、タスク１２６を構成するサービス１１６（１１２）の数を確認し、どのサービスがタスク１２６に含まれているかを例えばこれらのサービス１１２のＩＤ（即ち、ＳＳＤ１１６のＩＤ）で確認し、タスク１２６を形成するためにどのサービス１１６（１１２）が共にリンクされるかを確認する（例えば、サービス１の出力はサービス２の入力に進む、等々）。

３．或るファイルに対するサービスワークフローと共にＯＷＬ−ＳをSW-タスクレット５０２として格納する。

タスクパッケージの手順は次のようにすることができる：
１．SW-タスクレットを事前に決定したように作成する。

２．含まれているサービス１１６全ての記述を加える。

３．サービスｉｄ及びサービス記述ファイル名の間の対応関係（マッピング）を作り出し、そのマッピングをservices.idxファイルに格納する。図９は本発明の一実施例によるタスクパッケージインデックスファイル例５０６を示す。

４．コンテンツをジップ化する。

タスクパッケージ５００は未改良の方法に比べてかなりの改善効果をもたらし、ユーザは「プロセスモデル」タスクレット及び関連するサービスを手動で梱包し(zip)して他のユーザに送り；それを受けたユーザはそのファイルを開包(unzip)し、不足しているサービスを公表し、「プロセスモデル」専用タスクレットを最終的に開く必要がある。タスクパッケージの利点は明確である。なぜなら、ＴＣＣ１１９でタスクパッケージの構築中に、タスクパッケージフォーマットはＴＣＣ１１９が関連するサービス１１２全てを自動的に検出し、タスクパッケージ中のそれらのサービス記述１１６をSW-タスクレット及び対応するインデックスファイルと共に梱包することを許容するからである。タスクパッケージがTCC１１９で動作する又はオープンされる場合に、TCC119は、如何なる不足サービス１１２をも対象に含み、タスク構成サービスを自動的に決定する。上記の未改良の方法では、受け側のユーザは不足しているサービス１１２を手で抽出し、それらを手動で公表する必要がある。

ここでは、タスクコンピューティング１００環境を複数のコンピュータシステム実行段にセグメント化することによるタスクコンピューティングシステム例が説明され、その実行段は、プレゼンテーションクライアント処理レイヤ、リモートプロシジャ呼出アプリケーションプログラムインターフェース（ＡＰＩ）、ミドルウエアサービスプロセッシングレイヤ（プレゼンテーションレイヤがリモートプロシジャ呼出ＡＰＩを介してリアルタイムでインターフェースをとり、プレゼンテーションレイヤでコンピュータ実行タスクインターフェースを、意味論的に記述されたコンピュータシステムソース機能に対して、コンピュータシステムでのサービスとして動的に生成する）；サービスレイヤ及び機能ソース実現レイヤ（意味論的に記述されたコンピュータシステムソース機能を、ミドルウエアプロセシングレイヤがインターフェースをとるコンピュータシステムでのサービスとして与える）；及びリアルタイムで動的に構成する実行可能なタスク（コンピュータシステムでの１以上のサービスに対してプレゼンテーションレイヤで生成されたタスクインターフェースに従って、１以上のサービスで構成される）を有する。コンピュータサービスは実行可能なタスクにリアルタイムで動的に構成され、その際に、意味論的に記述されたアプリケーション−、装置−及びサービス−リッチなコンピュータに基づいてコンピュータ上のサービスに対して生成されたインターフェースを用いる。ここで説明された実施形態によれば、ユーザは、実用的に、効果的に、効率的に、動的に、リアルタイムに、柔軟性のある統合されたユーザインターフェース（構成及び実行機能）を当てにし、やり取りを管理し、汎用コンピュータ環境とやり取りする。

装置、方法、コンピュータ読取可能な媒体（そのキャリア信号を含む）は複数のコンピューティング機能ソースを用意し、機能に関するコンピューティングソース各々は、例えばユーザ及び／又はコンピュータにサービスを提供し、装置のコンピュータ環境内に及びその装置とネットワーク通信するコンピュータ環境内に存在する。本装置はセマンティックサービス記述（ＳＳＤ）をサービスに関連付ける。ＳＳＤはサービスの意味論的記述を有し、コンピュータ解釈可能な言語に従うサービスパラメータのセマンティック記述、及びサービスグラウンディングのように、ＳＳＤを表現するコンピュータ解釈可能な言語とインターフェースとの間の対応関係（サービスのインターフェースパラメータを含む）を含む。本装置は、ＳＳＤを発見するための複数の発見手段を介して１以上のＳＳＤを利用可能なサービスとして動的に発見し、各サービスに関連する各ＳＳＤ中の意味論的記述に基づいてサービスを動的に選別し、可能なタスクを連続的に示すためにサービスを選択すること及びサービスを選別することに基づいて、タスクを動的に構成するためのユーザインターフェースを生成し、構成されたタスクの構成されたタスク記述として実行可能なセマンティックサービスワークフロー記述を生成する。

実行可能なセマンティックサービスワークフロー記述の生成は、構成されたタスクのＳＳＤに基づいて、構成されたタスク記述のＳＳＤプロセスモデルとして実行プランを、構成されたタスクのＳＳＤ全てのサービスグラウンディングのリストを生成すること、及び構成されたタスクのサービスワークフローを、構成されたタスクの記述におけるプロファイル属性として抽出及び追加することを含む。

タスクコンピューティングは或るアプローチであり、そのアプローチは、（ａ）セマンティックウェブ技術を利用し、より多くの（セマンティック）ウェブリソースがユビキタスコンピューティングアプリケーションに速やかに利用可能になるようにし、（ｂ）リソースの性質には全く関係ないものであり、リソースがどのように発見されるか、どのようにアクセスされるか、どのように接続されるか又はどのように通信するかによらず、抽象化サービス１１６がタスクコンピューティングシステム１００でそれらを利用可能にするようにする。タスクコンピューティングは、全ての機能の普遍的な抽象化として意味論的に記述されたサービス１１６を当てにし、更に、構築可能なタスク１２６は多くのサービス１１２を含んでよいので、タスクコンピューティングは、装置対サービスの相互運用性(interoperability)より大きな範囲を網羅する。例えば典型的なタスクコンピューティング１００システムのタスク１２６はリアルタイムで動的に５−６個のサービス１１２を利用できる。

本発明の上記の好適実施例は、（既知の如何なるコンピュータ読取可能な媒体に格納されるような）ソフトウエアで及び／又はプログラム可能な装置／コンピューティング装置を制御するプログラム可能なコンピューティング装置／ハードウエア（例えば、データを格納、検索、提示（例えば、表示）及び処理することができるプログラム可能な電子装置）−如何なるタイプのプログラム可能なコンピュータ装置で実現されてもよい。そのようなコンピュータ装置は、限定ではないが例えば、パーソナルコンピュータ、クライアントサーバネットワークアーキテクチャの場合にはサーバ及び／又はクライアントコンピュータ、分散ネットワークアーキテクチャにおけるネットワーク化されたコンピュータ、端末装置、パーソナルディジタルアシスタント、モバイル装置等である。

以上本発明に関する多くの特徴及び利点が詳細な説明から明らかになり、かくて添付の特許請求の範囲により、そのような特徴及び利点の全てを本発明の真の精神及び範囲内に網羅することが意図される。更に、多くの修正及び変形が当業者に明白なので、図示及び説明された構成及び動作に厳密に本発明を限定することは望まれず、従って適切な全ての修正及び変形は本発明の範囲内にある。

本発明の一実施例によるタスクコンピューティング環境のアーキテクチャを示すシステム図である。 本発明の一実施例による、コンピュータで実現されるプレゼンテーションレイヤでのタスクインターフェースとしてコンピュータに表示されたグラフィカルユーザインターフェース画像を示す図である。 本発明の一実施例によるSTEER-WSAPIの定義リスト例を示す図である。 本発明の一実施例によるSTEER-WSAPIを利用するコンピュータソースコードを示す図である。 本発明の一実施例によるSTEER-WSAPIを利用するコンピュータソースコードを示す図である。 本発明の一実施例によるミドルウエアプロセッシングレイヤ108プログラムモジュールの機能ブロック図を示す。 本発明の一実施例によるタスクパッケージファイル構造を示す図である。 本発明の一実施例による開包されたタスクパッケージ中のファイルリストを示す図である。 本発明の一実施例によるサービスワークフローと共にタスクレットのコンピュータ解釈可能なソースコードを示す図である。 本発明の一実施例によるサービスワークフローと共にタスクレットのコンピュータ解釈可能なソースコードを示す図である。 本発明の一実施例によるサービスワークフローと共にタスクレットのコンピュータ解釈可能なソースコードを示す図である。 本発明の一実施例によるサービスワークフローと共にタスクレットのコンピュータ解釈可能なソースコードを示す図である。 本発明の一実施例による「オープン」サービスに関する意味論的なサービス記述を表すコンピュータ解釈可能なソースコードを例示する図である。 本発明の一実施例による「オープン」サービスに関する意味論的なサービス記述を表すコンピュータ解釈可能なソースコードを例示する図である。 本発明の一実施例による「オープン」サービスに関する意味論的なサービス記述を表すコンピュータ解釈可能なソースコードを例示する図である。 「マイファイル(MyFile)」サービスの意味論的サービス記述を表現する本発明の一実施例によるコンピュータ解釈可能なソースコード例を示す図である。 「マイファイル(MyFile)」サービスの意味論的サービス記述を表現する本発明の一実施例によるコンピュータ解釈可能なソースコード例を示す図である。 「マイファイル(MyFile)」サービスの意味論的サービス記述を表現する本発明の一実施例によるコンピュータ解釈可能なソースコード例を示す図である。 本発明の一実施例によるタスクパッケージインデックスファイルを例示する図である。

符号の説明

１００ タスクコンピューティング環境
１０４ プレゼンテーションプロセシングレイヤ１０４
１０６ リモートプロシジャコールメカニズムアプリケーションプログラムインターフェース
１０８ ミドルウエアプロセシングレイヤ
１１０ コンピュータシステム
１１２ サービスレイヤ
１１４ 機能ソース実現レイヤ
１１５ サービス機能
１１６ セマンティックサービス記述
１２６ タスク

Claims (17)

1. 複数のコンピュータ機能ソースを用意する装置であって、各コンピュータ機能ソースはサービスを提供し、当該装置のコンピューティング環境の中に、当該装置とネットワーク通信するコンピューティング環境の中に又はそれらの組み合わせの中に存在し、当該装置は或るプロセスに従って当該装置を制御するためのコントローラを有し、コンピュータが実行する該プロセスは、
   コンピュータ解釈可能な言語に従った、サービス機能を特定するパラメータのセマンティック記述と、ユーザによるサービスの起動を可能とさせるサービスグラウンディングとしての、セマンティックサービス記述（ＳＳＤ）を表現するコンピュータ解釈可能な言語で表現されたＳＳＤとインターフェースパラメータを含むサービスのインターフェースとの間の対応関係とを含むサービスのセマンティック記述を有するＳＳＤを、サービスに関連付けるプロセスと、
   ＳＳＤを発見するために複数の発見手段を介して１以上のＳＳＤを利用可能なサービスとして動的に発見するプロセスと、
   各サービスに関連する各ＳＳＤの意味論的記述に基づいて、サービスを動的に選別するプロセスと、
   実行可能なタスクを連続的に提示するために、サービスの選択及びサービスの動的な選別に基づいて、タスクを動的に構成するためのユーザインターフェースを生成するプロセスと、
   実行可能なセマンティックサービスワークフロー記述を、構成されたタスクの構成されたタスク記述として生成するプロセスと、
   を有し、
   前記実行可能なセマンティックサービスワークフロー記述を生成するプロセスは、
   構成されたタスクのＳＳＤに基づいて、構成されたタスクの記述のＳＳＤプロセスモデルとして実行プランと、構成されたタスクのＳＳＤ全てのサービスグラウンディングのリストとを生成し、構成されたタスクのサービスワークフローを、構成されたタスク記述のプロファイル属性として抽出して、実行可能なサービスワークフロー記述に付加するプロセスを含み、
   前記複数の発見手段が、一定のサービス記述を有する定常的に利用可能なサービスを発見するワンタイムサービス発見部としてネイティブサービス発見部を有する、
   ことを特徴とする装置。
2. 前記サービスワークフローが、タスク中の多数のＳＳＤ、タスク中のＳＳＤの身元、タスク中のＳＳＤの接続性を記述するリンク情報又はそれらの組み合わせを有する
   ことを特徴とする請求項１記載の装置。
3. 前記コントローラのプロセスが、構成されたタスクの実行可能なセマンティックサービスワークフロー記述、構成されたタスクのサービスに関するＳＳＤ及びインデックスを有するタスクパッケージファイルを生成するプロセスを更に有し、
   前記タスクパッケージファイルは、クロスコンピューティング環境実行ファイルである
   ことを特徴とする請求項１記載の装置。
4. 前記タスクパッケージファイルが、ジップフォーマットに従う
   ことを特徴とする請求項３記載の装置。
5. 前記コントローラのプロセスが、前記タスクパッケージファイルに従って、編集、実行又はそれら双方の組合せのために、ユーザインターフェースで構成されたタスクを、復元するプロセスを更に有する
   ことを特徴とする請求項３記載の装置。
6. 前記構成されたタスクを復元するプロセスが、
   ウェブサービスインターフェースを介してタスクパッケージファイル中の関連するＳＳＤを受け入れ、前記受け入れた関連するＳＳＤを利用可能な発見されたサービスとして登録する、編集及び実行を含む現在のタスク構成に関するテンポラリサービス発見部、
   一定のサービス記述を有する定常的に利用可能なサービスを発見するワンタイムサービス発見部としてのネイティブサービス発見部、
   アプリケーションからのソケット公表サービスメッセージに従う装置にローカルなサービス発見部、
   第三者発見部、又は
   それらの組み合わせ、
   を有する、
   構成されたタスクのサービスに関連する前記ＳＳＤを発見するための複数の発見手段に基づいて、構成されたタスクのサービスを発見するプロセスと、
   構成されたタスク記述中のプロファイル属性に基づいて、構成されたタスクに包含されるサービスを、ユーザインターフェースを介して提示するプロセスと、
   を有することを特徴とする請求項５記載の装置。
7. 前記複数の発見手段が、ウェブサービスインターフェースを介してサービスに関連するＳＳＤを受け入れ、前記受け入れたＳＳＤを利用可能な発見されたサービスとして登録する、編集及び実行を含む現在のタスク構成に関するテンポラリサービス発見部を有する
   ことを特徴とする請求項１記載の装置。
8. 前記コントローラのプロセスが、構成されたタスク記述のＳＳＤプロセスモデル中のサービスの意味論的に記述されたパラメータ及びサービスインターフェースパラメータの間で各サービスについて変換するために、構成されたタスク記述サービスグラウンディングを利用することで、及び構成されたタスク記述のＳＳＤプロセスモデルを介してサービスを実行するシーケンスを管理することでタスクを実行するプロセスを更に有する
   ことを特徴とする請求項１記載の装置。
9. ＳＳＤのサービスのセマンティック記述を調べることで及び／又はＳＳＤを発見した発見手段に基づいて、発見されたサービスとユーザ及びユーザの状況との関連性に基づいて、発見されたＳＳＤを発見されたサービスとして動的に選別するプロセスを更に有する
   ことを特徴とする請求項１記載の装置。
10. 前記の選別が、リソース記述フレームワークデータクエリ言語（ＲＤＱＬ）クエリに従う
    ことを特徴とする請求項９記載の装置。
11. ＳＳＤを表現するコンピュータ解釈可能な言語が、ウェブオントロジ言語（ＯＷＬ）ベースのウェブサービスオントロジ（ＯＷＬ−Ｓ）言語である
    ことを特徴とする請求項１記載の装置。
12. 各ＳＳＤが或るオントロジに従って各サービスの機能特性を決定し、
    サービスは、各サービスの機能特性を決定したＳＳＤに基づくコンパチビリティに従って選別される
    ことを特徴とする請求項１記載の装置。
13. ＳＳＤとサービスとの関連付けは、自然言語文の要素として名前をサービスに割り当て、自然言語文として自然言語要素の構築可能性へのサービスマッピングの構築可能性をサポートし、
    ユーザインターフェースを生成することは、自然言語文に従って自然言語サービス名に基づいて選択され選別されたサービスのタスクを構成することをサポートすることを含む
    ことを特徴とする請求項１２記載の装置。
14. 前記ユーザインターフェースがコンピュータ表示画面グラフィカルユーザインターフェースであり、該グラフィカルユーザインターフェースは、
    第１グラフィカルユーザインターフェースウインドウで、発見されたＳＳＤの選択可能な図形表示を、ツリー構造に従う利用可能なサービスとして表示し、
    或るプロセスに従って１以上のサービスをタスクにリアルタイムに動的に構成することをサポートする第２グラフィカルユーザインターフェースウインドウを提示し、該プロセスは、
    発見されたサービスを第１のウインドウでユーザにより選択させ、
    選択された発見されたサービスに関連する他のコンパチブルなサービスの選択可能な図形表示を自動的に表示し、
    コンパチブルなサービスをユーザにより選択させ、
    発見されたサービス及びコンパチブルなサービスをタスクとして選択するユーザに従って第２グラフィカルユーザインターフェースウインドウで指示されたサービスグラフをリアルタイムで動的に表示し、
    タスクを実行するためにタスク実行に関する選択可能な図形表示を表示する
    ことを特徴とする請求項１３記載の装置。
15. 表示され発見されたサービスは、発見されたサービスの機能特性に従って第１グラフィカルユーザインターフェースウインドウで組織される
    ことを特徴とする請求項１４記載の装置。
16. 複数のコンピュータ機能ソースを用意するためにコンピュータが実行する方法であって、各コンピュータ機能ソースはサービスを提供し、装置のコンピューティング環境の中に、装置とネットワーク通信するコンピューティング環境の中に又はそれらの組み合わせの中に存在し、当該方法は、
    コンピュータ解釈可能な言語に従った、サービス機能を特定するパラメータのセマンティック記述と、ユーザによるサービスの起動を可能とさせるサービスグラウンディングとしての、セマンティックサービス記述（ＳＳＤ）を表現するコンピュータ解釈可能な言語で表現されたＳＳＤとインターフェースパラメータを含むサービスのインターフェースとの間の対応関係とを含むサービスのセマンティック記述を有するＳＳＤを、サービスに関連付けるステップと、
    ＳＳＤを発見するために複数の発見手段を介して１以上のＳＳＤを利用可能なサービスとして動的に発見するステップと、
    各サービスに関連する各ＳＳＤの意味論的記述に基づいて、サービスを動的に選別するステップと、
    実行可能なタスクを連続的に提示するために、サービスの選択及びサービスの動的な選別に基づいてタスクを動的に構成するためのユーザインターフェースを生成するステップと、
    構成されたタスク用に、実行可能なセマンティックサービスワークフロー記述を生成するステップと、
    を有し、
    前記実行可能なセマンティックサービスワークフロー記述を生成するステップは、
    構成されたタスクのＳＳＤに基づいて、構成されたタスクの記述のＳＳＤプロセスモデルとして実行プランと、構成されたタスクのＳＳＤ全てのサービスグラウンディングのリストとを生成し、構成されたタスクのサービスワークフローを、構成されたタスク記述のプロファイル属性として抽出して、実行可能なサービスワークフロー記述に付加するステップを含み、
    前記複数の発見手段が、一定のサービス記述を有する定常的に利用可能なサービスを発見するワンタイムサービス発見部としてネイティブサービス発見部を有する、
    ことを特徴とする方法。
17. 複数のコンピュータ機能ソースを用意する装置であって、各コンピュータ機能ソースはサービスを提供し、当該装置のコンピューティング環境の中に、当該装置とネットワーク通信するコンピューティング環境の中に又はそれらの組み合わせの中に存在し、当該装置は、
    コンピュータ解釈可能な言語に従った、サービス機能を特定するパラメータのセマンティック記述と、ユーザによるサービスの起動を可能とさせるサービスグラウンディングとしての、セマンティックサービス記述（ＳＳＤ）を表現するコンピュータ解釈可能な言語で表現されたＳＳＤとインターフェースパラメータを含むサービスのインターフェースとの間の対応関係とを含むサービスのセマンティック記述を有するＳＳＤを、サービスに関連付ける手段と、
    ＳＳＤを発見するために複数の発見手段を介して１以上のＳＳＤを利用可能なサービスとして動的に発見する手段と、
    各サービスに関連する各ＳＳＤの意味論的記述に基づいて、サービスを動的に選別する手段と、
    可能なタスクを連続的に提示するために、サービスを選択すること及びサービスを動的に選別することに基づいてタスクを動的に構成するためのユーザインターフェースを生成する手段と、
    実行可能なセマンティックサービスワークフロー記述を、構成されたタスクの構成されたタスク記述として生成する手段と、
    を有し、
    前記実行可能なセマンティックサービスワークフロー記述を生成する手段は、
    構成されたタスクのＳＳＤに基づいて、構成されたタスクの記述のＳＳＤプロセスモデルとして実行プランと、構成されたタスクのＳＳＤ全てのサービスグラウンディングのリストとを生成し、構成されたタスクのサービスワークフローを、構成されたタスク記述のプロファイル属性として抽出して、実行可能なサービスワークフロー記述に付加する手段を含み、
    前記複数の発見手段が、一定のサービス記述を有する定常的に利用可能なサービスを発見するワンタイムサービス発見部としてネイティブサービス発見部を有する、 ことを特徴とする装置。

Images