(57)【要約】選択された型の承認のための要求を承認する処理を定義する機能が記述されている。この機能は、複数の承認処理要素の各々の視覚的表示（５１１〜５１８）を含むパレット（５１０）を表示する。そして、この機能は、いくつものユーザ入力のインスタンスを取得し、当該ユーザ入力のインスタンスの各々は、承認処理要素の配列を形成するために、視覚的表示（５１１〜５１８）の１つをワークスペース（５２０）内の選択された位置へとドラッグする。そして、この機能は、承認処理要素の形成された配列に対応した処理の定義を格納する。
2005522755.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータシステムにて、選択された型の承認の要求を承認するための処理を定義する方法であって、
複数の承認処理要素の各々の視覚的表示を含むパレットを表示し、
ユーザ入力の複数のインスタンスを取得し、該ユーザ入力の複数のインスタンスの各々は、前記視覚的表示の１つをワークスペース内の選択された位置へとドラッグして、前記承認処理要素の配列を形成し、
形成された前記承認処理要素の配列に対応した処理の定義を格納することを特徴とする方法。
【請求項２】
さらに、格納された前記処理の定義を用いて、選択された型の承認の要求を処理することを特徴とする請求項１記載の方法。
【請求項３】
さらに、格納された処理の定義を取得し、
取得された前記処理の定義を修正し、
修正された前記処理の定義を、選択された型とは異なる特定の型の承認の要求を処理するために格納することを特徴とする請求項１記載の方法。
【請求項４】
表示された前記視覚的表示の１つは、ゲート要素の視覚的表示であり、前記ゲート要素は、承認処理にて、各々の前記要求が到達する位置であって、１人または２人以上の承認者のグループの少なくとも１人により各々の前記要求が承認されるべき位置を確立することを特徴とする請求項１記載の方法。
【請求項５】
表示された前記視覚的表示の１つは、条件要素の視覚的表示であって、前記条件要素は、当該条件要素に関連した条件の値に基づき、当該条件要素に到達する各々の前記要求のための承認処理を、１つ又は２つの代替的な経路へと分岐させることを特徴とする請求項１記載の方法。
【請求項６】
表示された前記視覚的表示の１つは、接続要素の視覚的表示であって、前記接続要素は、当該接続要素に到達する各々の前記要求の承認処理を、２つの別個の経路の両方へと分割し、両方の前記経路は、承認されるべき要求を満たすべきものであることを特徴とする請求項１記載の方法。
【請求項７】
表示された前記視覚的表示の１つは、分離要素の視覚的表示であって、前記分離要素は、当該分離要素に到達する各々の前記要求の承認処理を、２つの別個の経路の両方へと分割し、両方の前記経路のうち、要求が承認されるかどうかを判別する第１の経路のほうが完了することを特徴とする請求項１記載の方法。
【請求項８】
表示された前記視覚的表示の１つは、終了要素の前記視覚的表示であって、前記終了要素は、承認処理にて、各々の前記要求が到達する位置であって、各々の前記要求が承認されるべきものと判別される位置を確立することを特徴とする請求項１記載の方法。
【請求項９】
表示された前記視覚的表示の１つは、コネクタの視覚的表示であって、前記コネクタは、承認処理にて、第１の承認処理要素から第２の承認処理要素への流れを確立することを特徴とする請求項１記載の方法。
【請求項１０】
選択された型の承認の要求を処理するための処理をコンピュータシステムに定義させるコンテンツを含むコンピュータ読み取り可能な媒体であって、前記コンテンツは、
複数の承認処理要素の各々の視覚的表示を含むパレットを表示し、
ユーザ入力の複数のインスタンスを取得し、前記ユーザ入力の複数のインスタンスの各々は、前記視覚的表示の１つをワークスペース内の選択された位置へとドラッグして、前記承認処理要素の配列を形成し、
形成された前記承認処理要素の配列に対応した処理の定義を格納することにより、前記コンピュータシステムに定義させることを特徴とするコンピュータ読み取り可能な媒体。
【請求項１１】
選択された型の承認の要求を処理するための処理を定義するコンピュータシステムであって、
複数の承認処理要素の各々の視覚的表示を含むパレットを表示する表示装置と、
前記視覚的表示の１つをワークスペース内の選択された位置へとドラッグして、前記承認処理要素の配列を形成するユーザ入力の複数のインスタンスを取得するユーザ入力モジュールと、
形成された前記承認処理要素の配列に対応した処理の定義を格納する記憶装置とを備えたことを特徴とするコンピュータシステム。
【請求項１２】
コンピュータシステムにて、第１の型の承認の要求を承認するための処理を定義する方法であって、
第１の型とは異なる第２の型の承認の要求を承認するために格納された処理の定義を取得し、
取得された前記処理の定義の図形表現を表示し、
表示された前記図形表現を修正するユーザの入力を取得し、
修正された前記図形表現に対応した処理の定義を格納し、格納された前記処理の定義は、前記第１の型の承認の要求を承認するための処理を定義していることを特徴とする方法。
【請求項１３】
前記第１の型の承認の要求は、第１のアプリケーションを用いて生成され、前記第２の型の承認の要求は、第１のアプリケーションとは異なる第２のアプリケーションを用いて生成されることを特徴とする請求項１２記載の方法。
【請求項１４】
格納された前記処理の定義は、基底のアプリケーションの表示を特定し、その中に、前記第１の型の承認の要求についての詳細が表示され得ることを特徴とする請求項１２記載の方法。
【請求項１５】
格納された前記処理の定義は、前記第１の型の承認の要求に対応した業務オブジェクトの種類を特定することを特徴とする請求項１２記載の方法。
【請求項１６】
格納された前記処理の定義は、前記第１の型の承認の要求を作成する業務サービスを特定することを特徴とする請求項１２記載の方法。
【請求項１７】
承認の要求の転送データ構造を含むコンピュータメモリであって、前記データ構造は、２人または３人以上の承認の要求の承認者のグループを特定する情報を含み、前記データ構造が承認の要求を承認者へ転送するために用いられる場合、当該承認の要求は、ほぼ同時に呈示され、第１の承認者が当該承認の要求に対処するまでの間にのみ呈示されることを特徴とするコンピュータメモリ。
【請求項１８】
前記グループを特定する情報は、グループ全体を特定する単一の識別子であることを特徴とする請求項１７記載のコンピュータメモリ。
【請求項１９】
前記グループを特定する情報は、前記グループにおける個々の構成員を特定する各々の識別子のリストであることを特徴とする請求項１７記載のコンピュータメモリ。
【請求項２０】
前記グループを特定する情報は、前記グループの構成員を特定する結果をもたらす照会であることを特徴とする請求項１７記載のコンピュータメモリ。
【請求項２１】
前記データ構造は、さらに、前記グループによる承認の図形表現への参照を含むことを特徴とする請求項１７記載のコンピュータメモリ。
【請求項２２】
承認の要求の転送データ構造を含むコンピュータメモリであって、前記データ構造は、
前記データ構造が承認の要求を転送するために用いられる場合に実行されるべき判別を示す情報と、
前記判別が首尾よく通った場合に辿るべき第１の承認経路の識別と、
前記判別が首尾よく通らなかった場合に辿るべき第２の承認経路の識別とを含み、前記第２の承認経路は、前記第１の承認経路とは異なることを特徴とするデータ構造。
【請求項２３】
前記データ構造は、さらに、前記判別の図形表現への参照を含むことを特徴とする請求項２２記載のコンピュータメモリ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はオフィスオートメーションの分野に関し、特に、承認の要求を処理する分野に関する。
【背景技術】
【０００２】
多くの企業組織は、事案を認証する承認処理を利用している。なお、承認処理においては、組織におけるある構成員（「要求者」）が、組織における１人又は２人以上の別の構成員（「承認者」）による承認のための要求を提出しなければならない。例えば、組織の承認処理には、組織におけるある種の構成員が、管理者から承認を得る必要があることもあり、あるいは、その管理者の管理者から承認を得る必要があることもあり、その度に、労働時間を記録した就労時間集計票を提出している。通例の承認処理には、組織の構成員が、このような要求を、経費、レポート、就労時間集計票、休暇願、目的及び評価、雇用、昇進、訓練要求、奨励補償願、契約、発注、見積、プレスリリース、並びに、ウェブ掲載用コンテンツ等、他の様々な環境において提出する必要があることもある。
【０００３】
通例の組織では、これらの型の承認の要求のいくつかは、要求者により手動で作成されてから、紙又は電子メールで、適切な承認者の系列へと提出される。例えば、転属要求は、要求者により手動で作成されてから、必要な承認者へと提出される。このような場合、承認処理に参加している組織の各構成員（要求者及び全ての承認者）は、このような型の要求のために指定された承認処理を完全に理解して、当該承認処理に応じて要求を転送しなければならない。例えば、転属要求を作成した要求者は、その要求が自分の管理者へと転送されるべきであって、そのように転送されることを、認識していなければならない。要求者の管理者は、要求を承認し、要求が自分の管理者へと転送されるべきことを認識して、そのように要求を転送しなければならない。要求者の管理者の管理者は、要求を承認し、さらなる処置のために要求が特定の執行者へと転送されるべきことを認識して、そのように要求を転送しなければならない。このような承認には、処理についてのかなりのレベルの知識、及び、その承認処理に関与する全構成員が参加することが必要である。
【０００４】
ある種の承認の要求は、様々なアプリケーションプログラムの１つを用いて、作成されてもよい。例えば、就労時間集計票のアプリケーションは、就労時間集計票を作成して、適切な処理を通じて自動的に転送するために用いられ、個々の発注のアプリケーションは、注文書を作成して、適切な処理を通じて自動的に転送するために用いられ得る。このような場合にて、これらの要求がこのように自動転送されるためには、各アプリケーションについて１つ又は２つ以上の承認処理が、作成されねばならない。このようにして承認処理を作成することは、多くの場合は困難である。例えば、承認処理を作成する者に対して、承認処理を実行するコンピュータプログラムを、汎用プログラミング言語で記述することが要請されることにもなる。さらに、あるアプリケーション用にある承認処理が一旦作成されると、それが用いられるべき追加のアプリケーション毎に作成し直される必要がある。このことに関しては、追加の労力が、かなりかかることにもなる。それは、アプリケーションによって、作成処理がかなり異なることが多いためである。前述の実施例では、例えば、就労時間集計票の承認処理を作成した者に対して、その承認処理を、発注アプリケーション用に作成し直すことが、要求されることもある。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
前述の承認の要求を転送するための従来の手法の実質的な欠点を考慮すると、さらに効率的でユーザにとって利用しやすい手法が有用となるであろう。
【課題を解決するための手段】
【０００６】
前述のような従来の手法の問題点に対処するために、承認の要求のための承認処理を定義するソフトウェア機能（以下、単に「当該機能」という）について説明する。当該機能の実施形態により、承認執行者又は他のユーザが、就労時間集計票を承認するための要求等の選択された型の承認の要求のための承認処理を定義するのに使用可能な視覚的インタフェースが、提供される。ユーザに対する視覚的インタフェースには、様々な承認処理要素の各々を図示するパレットが含まれる。例えば、パレットには、要求が承認のために提出される開始点の視覚的表現、要求転送方法を定める論理条件、個々の承認者又は承認者のグループによる承認判断、共同での承認判断を管理する論理作用体、要求が承認されるべく決定される終端点、及び承認処理フロー内の他の承認処理要素を接続するコネクタが含まれてもよい。ユーザは、視覚的表現を、パレットからワークスペース内の特定の相対位置へとドラッグする。そこでは、上記視覚的表現の配列により、承認処理の図形表現が形成される。当該機能により、ユーザは、選択された型の各々の承認の要求を処理するのに用いるための対応する承認処理における無駄をなくすことが可能となる。
【０００７】
ある種の実施形態では、当該機能により、ユーザは、要求が代替的な承認者のグループにおける任意の者による作用を受ける承認処理を定義することが可能となる。当該機能は、２人又は３人以上の承認者のグループに対して同時に要求が呈示される承認処理を定義するために使用可能である。これらの承認者の１人が要求を承認又は却下すると、グループ全体を代表して承認又は却下がなされ、そのグループの他の構成員に対する呈示が中止される。
【０００８】
ある種の実施形態では、当該機能は、新規の承認処理が、現行の承認処理に基づき「テンプレート（template）」を行うことを可能にする。このようにするために、当該機能は、現行の承認処理の複製を作成し、対応する図形表現をユーザが修正することができるようにする。そして、修正された図形表現に対応した承認処理は、それぞれ異なる型の各々の承認の要求を処理するのに用いるための節減された処理となる。
【０００９】
ユーザが前述のように承認処理を定義することを可能にすることで、当該機能の実施形態は、この業務を著しく簡素化し、特殊な訓練を受けていない者により迅速かつ効率的に上記業務が完遂されることを可能にする。
【発明を実施するための最良の形態】
【００１０】
システムの概観及び全体構成
一実施形態では、本発明の教示内容が実施されるシステムは、図１に示すようなマルチレイヤアーキテクチャとして論理的に構成され得る。一実施形態では、図１に示すような論理マルチレイヤアーキテクチャにより、様々なアプリケーションに対応した共通のサービス用に、プラットフォームが提供される。これらのサービスには、ユーザインタフェースレイヤ１１０、オブジェクトマネージャレイヤ１２０、データマネージャレイヤ１３０、及びデータ交換レイヤ１４０が含まれてもよい。
【００１１】
一実施形態では、ユーザインタフェースレイヤ１１０により、１つ又は２つ以上のアプリケーションに対応したアプレット、表示、図、及びレポート等が提供されてもよい。一実施形態では、様々な型のクライアントに対して、ユーザインタフェースレイヤ１１０により対応可能となっている。これらの様々な型のクライアントとしては、従来の接続式クライアント、リモートクライアント、インターネットを介した簡略式クライアント、ジャバ（Java）簡略式クライアント、又はウィンドウズに基づいて構築されていない（non-Windows-based ）オペレーティングシステム、及び、インターネットを介したＨＴＭＬクライアント等がある。
【００１２】
一実施形態では、オブジェクトマネージャレイヤ１２０は、１つ又は２つ以上のアプリケーションに関連した１つ又は２つ以上の組の業務規則又は業務概念を管理し、ユーザインタフェースレイヤ１１０とデータマネージャレイヤ１３０との間にインタフェースを提供するように、設計されている。一実施形態では、業務規則又は業務概念は、業務オブジェクトとして表現され得る。一実施形態では、業務オブジェクトは、会計、連絡、機会、サービス要求、及び解決策等の様々な業務規則又は業務概念の構成可能なソフトウェア表現として、設計されてもよい。
【００１３】
一実施形態では、データマネージャレイヤ１３０は、基底のデータの論理表示を維持し、オブジェクトマネージャが、データが格納された基底のデータ構造又はテーブルから独立して機能するように、設計されてもよい。一実施形態では、データマネージャ１３０により、データにアクセスするために構造化照会言語（ＳＱＬ）をリアルタイムで生成するといったような、ある種のデータベース照会機能が提供されてもよい。一実施形態では、データマネージャ１３０は、データベースの概要を定義した格納ファイル１６０内のオブジェクトの定義に作用するように設計される。一実施形態では、データ格納サービス１７０により、１つ又は２つ以上のアプリケーションに関連したデータモデル用のデータ格納が提供される。
【００１４】
一実施形態では、データ交換レイヤは、１つ又は２つ以上の特定の対象データベースとの対話を取り扱い、データマネージャレイヤ１３０と基底のデータソースとの間にインタフェースを提供するように設計されている。図２に、本発明の教示内容が実施されるシステム構成の一実施形態のブロック図を示す。
【００１５】
一実施形態では、マルチレイヤアーキテクチャにより、１つ又は２つ以上のソフトウェアレイヤが、様々なマシン上に存在することができるようになる。例えば、一実施形態では、ユーザインタフェース、オブジェクトマネージャ、及びデータマネージャは、いずれも、専用のウェブクライアント上にあってもよい。ワイヤレスクライアント等の他の型のクライアントについて、一実施形態では、オブジェクトマネージャ及びデータマネージャは、システムサーバ上にあってもよい。なお、図２に示したシステム構成は、説明の目的で例示されたものであり、本発明の教示内容の個々の実施例及び用途に応じて変化し得ることが、当業者には認識されかつ理解されるであろう。
【００１６】
一実施形態では、図２に示すシステム環境には、２つ以上のデータベース２９０が含まれてもよい。データベース２９０の１つ又は２つ以上のサブセットが、作成されてもよく、複製マネージャにより複製されてもよい。さらに、移動ウェブクライアントは、追加のリモートデータベース（ローカルデータベースとも呼ばれる）を有してもよい。一実施形態では、移動ウェブクライアントに関連したリモートデータベースまたはローカルデータベースが読取専用データベースとして定義されたのでなければ、当該移動ウェブクライアントは、データをローカルで作成及び更新することが可能であり、当該データは、最終的には、各々の移動ウェブクライアントがシステムサーバと同期する度に、主要なデータベースへと伝達される。
【００１７】
一実施形態では、データベース２９０は、所定のデータの型式（例えば、テーブルオブジェクト、インデックスオブジェクト等）、複製オブジェクト（例えば、業務オブジェクト及びコンポーネント、表示定義及び表示規則等）、及びユーザ又は顧客データ等の様々な型のデータを格納するように設計されている。一実施形態では、他の型のクライアントとともに動作するもの等の専用のウェブクライアント及びサーバコンポーネントが、データベース２９０に直接接続されて、リアルタイムでの変更が可能である。一実施形態では、移動ウェブクライアントは、サーバのデータのサブセットをローカルで使用するためにダウンロードし、システムサーバがローカル及びサーバのデータベースの両方を更新することにより、サーバのデータベースと周期的に同期を取ることが可能である。
【００１８】
一実施形態では、データベース２９０に含まれる様々なテーブルが、以下の形式へと論理的に編成されてもよい。すなわち、当該形式は、データテーブル、インタフェーステーブル、及び格納テーブル等である。
【００１９】
一実施形態では、データテーブルは、ユーザの業務データ、執行データ、シードデータ（seed data ）、及び取引データを格納するために用いられ得る。一実施形態では、これらのデータテーブルは、様々なアプリケーション及び処理により、取り込まれて更新されてもよい。一実施形態では、データテーブルには、ベーステーブル及び共通テーブル等が含まれてもよい。一実施形態では、ベーステーブルには、様々なアプリケーションにより定義されて使用されるカラムが含まれてもよい。一実施形態では、ベーステーブルは、業務コンポーネントのテーブルプロパティにて指定された当該業務コンポーネントにカラムを提供するように設計される。一実施形態では、共通テーブルは、２つの業務コンポーネント間の多対多関係を実行するために用いられるテーブルである。また一方で、これらの共通テーブルは、共通データカラムを保持してもよく、それにより、各関連性についての情報が格納される。一実施形態では、共通テーブルにより、関連アプレット用のデータ構造が提供される。
【００２０】
一実施形態では、インタフェーステーブルは、ベーステーブルのグループを、外部プログラムとのインタフェースとして機能する単一のテーブルへと特殊化する（denormalize）ために用いられる。一実施形態では、これらのインタフェーステーブルは、データのエクスポート及びインポート用のステージ領域として用いられてもよい。
【００２１】
一実施形態では、格納テーブルには、以下のものに関する１つ又は２つ以上のアプリケーションを指定するオブジェクト定義が含まれる。
【００２２】
・クライアントアプリケーション構成
・データのインポート及びエクスポートに用いられるマッピング
・移動クライアントへデータを転送するための規則
一実施形態では、ファイルシステム２９５は、アプリケーションサーバ上に配置可能でかつネットワークアクセス可能なディレクトリである。一実施形態では、ファイルシステム２９５は、第３者のテキストエディタにより作成されたファイル、及びデータベース２９０内には格納されていない他のデータ等、様々なアプリケーションにより作成された物理ファイルを格納する。一実施形態では、ファイルシステム２９５内に格納された物理ファイルは、圧縮されて様々な命名規約により格納されてもよい。一実施形態では、専用のウェブクライアントは、ファイルシステム２９５に対して、ファイルディレクトリを直接読み出したり書き込んだりすることが可能である。一実施形態では、移動ウェブクライアントは、サーバベースのファイルシステム２９０と周期的に同期するローカルファイルシステムを有してもよい。一実施形態では、ワイヤレスクライアント及びウェブクライアント等の他の型のクライアントが、システムサーバを介してファイルシステム２９０にアクセスすることが可能である。
【００２３】
一実施形態では、企業サーバ２５０は、端点から共通のゲートウェイサーバへと、共通のテーブル所有者又はデータベースを共用するシステムサーバ２５５を論理的にグループ化したものであり、サーバマネージャ２６０を用いてグループとして管理され得る。一実施形態では、ゲートウェイサーバへの接続は、ＴＣＰ／ＩＰを介して確立可能である。一実施形態では、企業サーバ２５０は、当該企業サーバ２５０内で複数のシステムサーバ２５５を配備することにより、効率的に拡大縮小可能であるので、アプリケーションの中間層に対して高度の拡張性が提供される。
【００２４】
一実施形態では、サーバ２５５は、一つ又は複数のサーバプログラムを実行する。このサーバは、着信した処理の要求を取り扱い、サーバ上の全ての処理の状態を監視する。一実施形態では、サーバプログラムは、データのインポート及びエクスポート、データベースの構成、仕事の流れ及び処理の自動化の実行、データの同期及び複製のために移動ウェブクライアントに対応する処理、並びに、業務規則の執行等、１つ又は２つ以上の特定の機能又はジョブを実行するように設計及び構成されている。一実施形態では、サーバ２５５は、ＮＴサービス（ウィンドウズＮＴ（Windows NT）オペレーティングシステムの下で）であってもよく、ユニックス（UNIX）オペレーティングシステムの下ではデーモン（daemon）（例えばバックグラウンドのシェルプロセス）であってもよい。一実施形態では、サーバ２５５は、マルチプロセス及びマルチスレッド・コンポーネントの両方に対応しており、コンポーネントを、バッチ、サービス、及び対話モードで実行することが可能である。
【００２５】
一実施形態では、サーバマネージャ２６０は、サーバ２５５及び企業サーバ２５０用の異なるプログラムに亘り、共通の制御、執行及び監視を可能とするユーティリティとして、構成される。一実施形態では、サーバマネージャ２６０は、以下のタスクを実行するために利用可能である。すなわち、当該タスクは、サーバ２５５、コンポーネント、及びタスクの開始、停止、一時停止、及び再開や、企業サーバ内の複数のタスク、コンポーネント、及びサーバについての状態の監視及び統計の収集や、企業サーバ、個々のサーバ、個々のコンポーネント、及びタスクの構成等である。
【００２６】
一実施形態では、ゲートウェイサーバは、論理的な実体として構成され得る。この実体は、サーバへのアクセスのための単一のエントリポイントとしての役割を果たす。一実施形態では、このゲートウェイサーバは、拡張性を向上させ、負荷の均衡、及び企業サーバに亘る高度の利用可能性を提供するために用いられてもよい。一実施形態では、ゲートウェイサーバには、ネームサーバ及び接続仲介コンポーネントが含まれてもよい。一実施形態では、ネームサーバは、サーバに関連したパラメータを監視するように構成される。例えば、サーバに対応した利用可能性情報及び接続性情報は、ネームサーバ内に格納されてもよい。システム内の様々なコンポーネントは、ネームサーバに対して、サーバの利用可能性及び接続性に関する様々な情報を照会することが可能である。ウィンドウズＮＴ環境では、ネームサーバは、ＮＴサービスとして実行可能である。ユニックス環境では、ネームサーバは、デーモンプロセスとして実行可能である。一実施形態では、接続仲介コンポーネントは、クライアント接続の要求を適切なサーバ（例えば、最も混雑度の低いサーバ）へと向けるといったような、負荷均衡機能を実行するのに用いられる。
【００２７】
一実施形態では、図２に示すように、システムが対応可能な様々な型のクライアントとして、以下のものがある。すなわち、専用ウェブクライアント、移動ウェブクライアント、ウェブクライアント、ワイヤレスクライアント、及びハンドヘルドクライアント等である。
【００２８】
一実施形態では、専用ウェブクライアント（接続クライアントとも呼ばれる）は、ＬＡＮ又はＷＡＮを介して、データアクセス用のデータベースサーバに直接接続されている。一実施形態では、これらの接続クライアントすなわち専用ウェブクライアントは、ローカルでデータを格納することはない。また一方で、これらの専用ウェブクライアントは、ファイルシステムにも直接接続される。一実施形態では、マルチレイヤアーキテクチャのユーザインタフェース、オブジェクトマネージャ、及びデータマネージャレイヤは、専用ウェブクライアント上にある。
【００２９】
一実施形態では、移動ウェブクライアントは、ローカルでデータにアクセスするように設計及び構成されているので、自身のローカルデータベース及び／又はローカルファイルシステムを有してもよい。一実施形態では、移動ウェブクライアントは、ゲートウェイサーバを介して、システム内の他のコンポーネントと対話してもよい。同期を通して、ローカルデータベース及びサーバデータベースの変更は、交換可能である。以下、移動ウェブクライアントについて詳述する。
【００３０】
一実施形態では、ウェブクライアントは、クライアントマシンからの標準的なブラウザフォーマットにて実行される。一実施形態では、ウェブクライアントは、ウェブサーバを介して、システムサーバ２２５に接続可能である。一実施形態では、システムサーバ２５５は、業務ロジックを実行してデータベース２９０及びファイルシステム２９５のデータにアクセスするように設計及び構成されている。一実施形態では、ここで説明するウェブクライアントは、本発明の教示内容に従って対話モードで動作するように、設計及び構成されている。一実施形態では、ここで説明する対話式ウェブクライアントフレームワークは、サーバ側のオブジェクトに対応してブラウザ側でジャバスクリプト（JavaScript）にて実行されて動的に生成されたオブジェクトを利用する。一実施形態では、ブラウザ側でこのように動的に生成されたオブジェクトには、現行の表示及び対応したアプレット、現行の業務オブジェクト及び対応した業務コンポーネント等が、含まれてもよい。以下、ウェブクライアントについて詳述する。
【００３１】
一実施形態では、ワイヤレスクライアントは、実質的にはワイヤレス機器上で有効となる簡略式クライアントである。ワイヤレスクライアントは、ワイヤレスアプリケーションプロトコル（ＷＡＰ）ベースのユーザインタフェースを使用して、システムサーバと情報／データを伝達及び交換してもよい。
【００３２】
以下、説明用の例として、様々な構造、データベース、テーブル、及びファイルシステム等を参照しつつ、図２に示したようなシステム構成について詳述する。
【００３３】
図３は、本発明の教示内容に応じてアプリケーションが構築可能なマルチレイヤアーキテクチャの他の論理表現を示すブロック図である。繰り返すと、図３に示すマルチレイヤアーキテクチャは、設計されて様々なアプリケーションに対応した様々な共通のサービスに対して、構成されたプラットフォームを提供する。一実施形態では、これらの様々なサービスには、アプレットマネージャ及びユーザインタフェースレイヤ３１０に対応したプレゼンテーションサービス・ロジックレイヤ３１５、オブジェクトマネージャ（ＯＭ）レイヤ３２０及びデータマネージャレイヤ（ＤＭ）３３０に対応したアプリケーションサービス・ロジックレイヤ３２５、並びにデータベースレイヤ３４０に対応したデータサービス・ロジックレイヤ３４５が、含まれてもよい。
【００３４】
一実施形態では、プレゼンテーションサービス３１５は、様々な型のクライアントに対応するように設計及び構成されてもよく、これらのプレゼンテーションサービスに対してユーザインタフェースアプレット、表示、図、及びレポート等を提供してもよい。前述のように、ワイヤレスクライアント、ハンドヘルドクライアント、ウェブクライアント、移動ウェブクライアント、及び専用（接続）クライアント等、多岐に亘るクライアントに対応してもよい。
【００３５】
一実施形態では、アプリケーションサービス３２５には、業務ロジックサービス及びデータベース対話サービスが、含まれてもよい。一実施形態では、業務ロジックサービスは、業務オブジェクト及び業務コンポーネントの種類及び動作を提供する。一実施形態では、データベース対話サービスは、データに対するユーザインタフェース（ＵＩ）の要求を業務コンポーネントから取得して、要求を満たすために必要なデータベースコマンド（例えば、ＳＱＬの照会等）を生成するように、設計及び構成されてもよい。例えば、データ対話サービスは、データのコールをＤＢＭＳ別のＳＱＬ文に変換するために用いられてもよい。
【００３６】
一実施形態では、データ格納サービス３４５は、様々なアプリケーションの基礎として機能する基底のデータモデルのためにデータの格納を提供するように、設計及び構成されてもよい。例えば、データモデルは、コールセンタ、販売、サービス、及びマーケティング等の様々なソフトウェア製品及びアプリケーション、並びに、電子ファイナンス、電子保険、電子コミュニケーション、電子医療等の産業に対して縦断的な様々な製品及びアプリケーションに対応するように、設計及び構成されてもよい。
【００３７】
図４は、本発明の教示内容が実行され得るアプリケーションフレームワークの一実施形態のブロック図である。図４に示すように、アプリケーションフレームワークには、業務のニーズ及び環境に基づいて個々のアプリケーションを設計及び構成するために使用可能な、様々な型のサービス及び様々な型のツールの様々な論理グループが、含まれてもよい。
【００３８】
一実施形態では、コアサービスは、アプリケーションが実行されるフレームワークを提供するように、設計及び構成されている。一実施形態では、コアサービスには、以下のものが含まれてもよい。
【００３９】
・中間層のアプリケーションサーバである企業サーバ
・全ての部分を相互に連結するネットワーク
・複数導入された様々なアプリケーション間、及び、様々なアプリケーションと他の外部アプリケーションとの間で、データの共用を可能とするイベントマネージャ及びデータの複製のような機能
・認証及びアクセス制御、すなわちセキュリティ機能
一実施形態では、アプリケーション統合サービスが、このフレームワークに応じて構築された様々なアプリケーションが外界と通信することができるように、設計及び構成されてもよい。一実施形態では、この論理グループ内の様々な型のサービスは、リアルタイム、ほぼリアルタイム、及びバッチでの外部アプリケーションとの統合に備えて、設計及び構成されてもよい。例えば、これらの統合サービスは、外部アプリケーションと内部アプリケーションとの通信を、利用可能な方法、技術、及びソフトウェア製品を用いて可能にするために、使用されてもよい。一実施形態では、アプリケーション統合サービスにより、システム又はアプリケーションは、他の外部企業アプリケーションとデータを共用及び複製することが可能となる。したがって、これらのサービスにより、個々のアプリケーション又はシステムは、情報を要求しているクライアント、及び、要求された情報を有するサーバのいずれともなり得る。
【００４０】
一実施形態では、業務処理サービスは、クライアントがアプリケーションを介して業務処理を自動化することができるように、設計及び構成される。一実施形態では、これらの様々な業務処理サービスには、以下のものが含まれてもよい。
【００４１】
・割当マネージャによるタスクの割当
・ワークフローマネージャによる業務の執行
・ビジネスサービスによる特定業務ロジックの再利用
・製品構成部及び価格設定部による適切な製品構成の確保及び価格設定
一実施形態では、これらの業務処理の作成は、個人用デザイナ（Personalization Designer）、ワークフローデザイナ（Workflow Designer ）、スマートスクリプトデザイナ（SmartScript Designer ）、割当アドミニストレーション・ビューズ（Assignment Administration Views ）、及びモデルビルダ（Model Builder ）等の実行時ツールによりなされてもよい。
【００４２】
一実施形態では、統合サービスは、クライアントにユーザインタフェース及び簡略式クライアント対応を提供するように、設計及び構成されてもよい。一実施形態では、これらの統合サービスには、ユーザのプロファイル管理、共同サービス、並びに電子メール及びファックスサービス等のウェブサポート機能を、改良されたスマートスクリプティング（Smart Scripting ）等とともに提供するような、ウェブベースのアプリケーションを構築及び管理する機能が、含まれてもよい。
【００４３】
一実施形態では、設計時ツールが、統合点をカスタマイズしたり設計したり提供したりするためのサービス、及び、アプリケーションを支持するためのサービスを提供するように、設計及び構成されてもよい。これらの様々なツールは、アプリケーションを規定する１つの共通の場を提供する。
【００４４】
一実施形態では、管理サービスが、アプリケーション環境を監視及び管理するための１つの共通の場を提供するように、設計及び構成される。一実施形態では、これらのサービスにより、ユーザは、グラフィックユーザインタフェース（ＧＵＩ）又はコマンドラインを介してアプリケーションを管理することが可能となる。
機能及びその実施形態
以下、当該機能についてさらに説明するために、いくつもの表示図の例とともに、その実施形態及び動作について考察する。
【００４５】
図５は、要求の承認処理を当該機能を用いて定義する動作を示す典型的な一連の表示における最初のものを示す表示図である。図５は、当該機能により表示された要求承認処理定義ウィンドウ５００を示している。要求承認処理定義ウィンドウ５００は、パレット・サブウィンドウ５１０とワークスペース・サブウィンドウ５２０とに分割されている。パレット５１０には、要求承認処理を構築するために用いられるそれぞれの要素に対応したアイコン５１１〜５１８が含まれている。パレット５１０に示された承認処理要素のアイコンの組は、単に例示的なものである。そのため、図示のアイコンの１つと同等の意味を有するものの外観が異なる各アイコン、及び／又は別の意味を有するアイコン等、別のアイコンの組が表示されてもよいことが、当業者には理解されるであろう。
【００４６】
ワークスペース５２０は、そこに、ユーザが定義している承認処理の図形表現を当該ユーザが構築するというものである。定義されている承認処理の図形表現に承認処理の要素を追加するために、ユーザは、対応するアイコンをパレットからワークスペース内の所望の位置へとドラッグする。図５には、ユーザが、承認処理開始要素の視覚的表示５１１をワークスペースへドラッグして、承認処理要素インスタンス５２１を作成したことが示されている。これは、要求承認処理の開始点を示しており、そこで、承認を求める要求がユーザにより送信される。
【００４７】
図６は、作成について図５で示された承認処理開始要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。ウィンドウ６００には、型６０１、名称６０２、承認処理６０３、対応する業務オブジェクト６０４、作成者識別情報６０５、作成日６０６、及び処理モード６０７等、要素インスタンス自体の様々な属性が示されている。第２のウィンドウ６１０には、後続の要素インスタンス、すなわち当該要素インスタンスの後に処理が渡される要素インスタンスを示す情報が含まれている。情報項目６１１〜６１３は、ＡＮＤ承認処理要素インスタンスに対して接続された要素インスタンス５２１を示している。通常、ウィンドウ６１０に示す情報は、次の要素インスタンス又は処理中の要素インスタンスがワークスペース内に作成された後にのみ、要素インスタンス５２１とともに判別されて格納される。この実施例では、後述するような図７にて反映される対話をユーザが実行した後に、ウィンドウ６１０に示された特定の情報が作成されて格納される。
【００４８】
図７は、要求の承認処理を当該機能を用いて定義する動作を示す典型的な一連の表示における第２のものを示す表示図である。図７には、アイコン７１６及び７１３をワークスペースへドラッグして、定義されている要求承認処理における承認処理開始要素インスタンス７２１の次のＡＮＤ承認処理要素インスタンス７２２を作成した結果が示されている。ＡＮＤ承認処理要素は、承認処理を２つ以上の並行した経路に分割する。通常、各経路は、同時に実行され、当該経路の全てが、最終的には承認されるべき要求のために履行されねばならない。
【００４９】
図８は、作成について図７で示されたＡＮＤ承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。ウィンドウ８００には、要素インスタンス自体の様々な特性が示され、ウィンドウ８１０には、後続の要素インスタンス、すなわち当該要素インスタンスの後に処理が渡される要素インスタンスを示す情報が含まれている。
【００５０】
図９は、要求の承認処理を当該機能を用いて定義する動作を示す典型的な一連の表示における第３のものを示す表示図である。図９には、アイコン９１７をワークスペースへドラッグして、定義されている要求承認処理におけるＡＮＤ承認処理要素インスタンス９２２の次のＯＲ承認処理要素インスタンス９２３を作成した結果が示されている。ＯＲ承認処理要素は、承認処理を２つ以上の並行した経路に分割する。通常、各経路は、同時に実行され、当該経路の少なくとも１つが、最終的には承認されるべき要求のために履行されねばならない。
【００５１】
図１０は、作成について図９で示されたＯＲ承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。ウィンドウ１０００には、要素インスタンス自体の様々な特性が示され、ウィンドウ１０１０には、後続の要素インスタンス、すなわち当該要素インスタンスの後に処理が渡される要素インスタンスを示す情報が含まれている。
【００５２】
図１１は、要求の承認処理を当該機能を用いて定義する動作を示す典型的な一連の表示における第４のものを示す表示図である。図１１には、アイコン１１１２をワークスペースへドラッグして、ＯＲ承認処理要素インスタンス１１２３の次の２つのゲート承認処理要素インスタンス１１２４及び１１２５を作成した結果が示されている。各ゲート承認処理要素は、１人又は２人以上の承認者を指定している。このような承認は、承認受信箱の一部が各承認者に対して表示されるといったように、要求についての情報を表示する等の様々な方法で、承認者から得られてもよい。それについては、米国特許出願第１０／１１２，４１５号（特許代理人の事件番号３８４８１−８００４）において、より完全に詳述されており、その内容が、本願明細書に一体に組み入れられている。
【００５３】
図１２乃至図１８は、作成について図１１で示されたゲート承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。ウィンドウ１２００には、ゲート承認処理要素インスタンスに対して割り当てられたゲート型１２０７等、要素インスタンス自体の様々な特性が示されている。ウィンドウ１２２０には、可能なゲート型のリストが示されており、ユーザは、このリストから、相対的地位ゲート型１２２１、絶対的地位ゲート型１２２２、個人ゲート型１２２３、照会ゲート型１２２４、読取オブジェクトゲート型１２２５、チームゲート型１２２６、及びアクセスグループゲート型１２２７等を選択する。以下、これらのゲート型の各々について詳述する。
【００５４】
相対的地位ゲートは、要求の作成者を基準とした承認者の地位に基づいて、承認者を指定する。ウィンドウ１２３０には、直接の管理者の相対的地位１２３１、管理者の管理者の相対的地位１２３２、及び直属の相対的地位１２３３等、相対的地位ゲートのために選択され得る相対的地位の例が示されている。
【００５５】
絶対的地位ゲートは、組織内での承認者の絶対的地位に基づいて、承認者を指定する。図１３におけるウィンドウ１３３０には、内部監査役の絶対的地位１３３１、民生品のソフトウェアエンジニアの絶対的地位１３３２、及び専門サービスの地域責任者１３３３等、絶対的地位ゲートのために選択され得る絶対的地位のいくつもの例が示されている。
【００５６】
個人ゲートは、承認者の個人識別情報に基づいて承認者を指定する。図１４におけるウィンドウ１４３０には、ウィリー・アーロン１４３１、ジョン・エイブラハム１４３２、及びデビッド・アッカーマン１４３３等、個人ゲートのために選択され得る人々の例が示されている。
【００５７】
照会ゲートは、要求作成時に処理され得るデータベース型の照会に基づき、承認者を指定する。図１５におけるウィンドウ１５３０には、照会ゲートのために選択され得る照会の例が示されている。ウィンドウ１５３０には、それぞれの従業員の属性に対応したいくつものカラム１５４１〜１５４６に分割された照会行１５３１が含まれている。ユーザは、これらのフィールドのどれにでも、情報が合致する従業員を選択する照会を指定するために、照会テキストをタイピングすることができる。照会行１５３１について、ユーザは、業務電話番号のフィールド１５４８内に照会文字列“＊５５５＊”を入力する。この結果、この照会により、業務電話番号のどこかに部分文字列“５５５”が含まれる従業員が全て選択される。ウィンドウ１５６０には、ユーザがウィンドウ１５３０にて「次へ」ボタン１５５０をクリックした場合に、この照会により選択される従業員１５６１〜１５６３等の従業員が示されている。ある種の実施形態では、照会ゲートのために指定された照会は、特定の要求の転送処理中に実行され、この結果は、その時点での従業員データベースの内容に反映される。これらの実施形態では、ウィンドウ１５６０の内容は、以前の時点での従業員データベースの内容に対応しているので、単に説明のためのものである。他の実施形態では、承認処理の設計時に照会を実行することにより作成されたウィンドウ１５６０に示される照会の結果は、照会ゲートにより指定された承認者を特定するために用いられる。本実施形態では、照会は、定義された承認処理を通して各々の要求を転送することの一部として再実行されることはない。これらの実施形態のいくつかでは、ユーザは、リストに対する承認者の追加又は承認者の削除といったように、承認者のリストを修正してもよい。
【００５８】
読取オブジェクトゲートは、業務オブジェクトから承認者の識別情報を読み取ることにより、承認者を指定する。図１６におけるウィンドウ１６３０には、承認者の識別情報を業務オブジェクトから読み取る方法を指定した情報１６３１の例が示されている。そこには、経費報告業務オブジェクトの経費業務コンポーネント内にある処理センタフィールドから、識別情報が読み取られるべきであることが示されている。
【００５９】
チームゲートは、予め定められたチームの構成員である承認者を指定する。図１７におけるウィンドウ１７３０には、チームゲートのために選択され得るチーム１７３１の例が示されている。
【００６０】
アクセスグループゲートは、特定の型の情報が通常送信されるアクセスグループの構成員である承認者を指定している。図１８におけるウィンドウ１８３０には、アクセスグループゲートのために選択され得るアクセスグループ１８３１の例が、リストアップされている。
【００６１】
図１９は、要求の承認処理を当該機能を用いて定義する動作を示す典型的な一連の表示における第５のものを示す表示図である。図１９には、アイコン１９１５をワークスペースへドラッグして、定義されている要求処理内に判別点承認処理要素インスタンス１９２６を作成した結果が示されている。判別点承認処理要素は、判別の結果に基づき、承認処理を２つの異なる経路のいずれかに分岐させる。判別が首尾よく通れば、承認処理は“Ｙｅｓ（はい）”の分岐を辿るが、判別が首尾よく通らなければ、承認処理は“Ｎｏ（いいえ）”の分岐を辿る。
【００６２】
図２０は、作成について図１９で示された判別点承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。ウィンドウ２０００には、承認処理がどの分岐を辿るべきかを判別するために判別点にて実行される判別２００７等、要素インスタンス自体の様々な特性が示されている。ここで、判別は、経費報告の額が５，０００ドル（＄）を超えているかどうかについてのものである。ウィンドウ２０１０には、当該要素インスタンスの後に処理が渡される後続の要素インスタンスを記述した情報が含まれている。より具体的には、情報項目２０１１〜２０１３は、判別が首尾よく通ると処理はゲートＥへと渡されることを示し、情報項目２０１４〜２０１６は、判別が首尾よく通らない場合に処理が終了することを示している。
【００６３】
図２１は、要求承認処理の完全に定義されたものを示す表示図である。追加の承認処理要素インスタンス２１２８〜２１３２が、ユーザにより対応するアイコンをパレット２１１０からワークスペース２１２０へドラッグすることで追加されていることが理解されるであろう。これらの追加の承認処理要素インスタンスには、終了、すなわち要求が承認された承認処理要素インスタンス２１３２が含まれている。承認処理がこの要素インスタンスに到達すると、その承認の要求は、承認されたものとみなされる。
【００６４】
ここで、ユーザは、この承認処理に応じて処理されるべき承認の要求の型を特定してもよい。そして、当該機能は、この承認処理を、この型の作成された承認の要求の各々を処理するのに用いるために保存する。ある種の実施形態では、当該機能により保存された承認処理には、以下の１つ又は２つ以上に対する参照が含まれる。すなわち、これらの参照は、この型の承認の要求を生成するためのアプリケーションの表示、この型の承認の要求に対応した業務オブジェクトの種類、及び、この型の承認の要求を作成するための業務サービスである。
【００６５】
図２１に示す完全に定義された承認処理の効果をより完全に示すため、それについて以下に詳述する。
【００６６】
ユーザは、経費報告の承認の要求を送信する。この要求は、以下の経路を辿る。
【００６７】
要求は、Ａ、Ｂ、Ｃ、及びＤへと同時に送られる。２つのループが続き、その一方にはＡ及びＢが関与し、他方にはＣ及びＤが関与する。
【００６８】
・第１のループでは、ＡまたはＢのいずれかが、必ず要求を承認する。それらの１つが、一旦承認すると、
・承認の要求は、他方の承認受信箱から自動的に消失する。例えば、Ｂが承認すると、要求はＡの承認受信箱から消失する。
【００６９】
・額が５，０００ドルを超えると、要求は承認のためにＥへと送られる。
【００７０】
・Ｅは要求を承認する。以下のループが完了し、額が１０，０００ドルを超えると、項目はＦへと送られる。
【００７１】
・他方のループでは、Ｃ及びＤの両方が必ず要求を承認する（ＡとＢとが独立して）。
【００７２】
・それらの１つが要求を一旦承認すると、他方の人は、第１の承認について通知を受ける。
【００７３】
・Ｃ及びＤの双方が要求を一旦承認し、前述のループが完了すると、承認のために項目はＦへと送られる（額が１０，０００ドルを超える場合）。先行する全てのゲートがクリアされた場合、Ｆのみが項目を取得する。
【００７４】
・（額が１０，０００ドルを超えた場合）Ｆが要求を一旦承認すると、承認処理は完了し、項目の状態は“承認”となる。
【００７５】
・（額が１０，０００ドル未満の場合）両ループが一旦完了し、額が５，０００ドルを超えた場合にＥが承認すると、承認処理は完了し、要求の状態は“承認”となる。承認処理は、記号により以下のように図示される。ここで、∪はＯＲの論理記号であり、∩はＡＮＤの論理記号であり、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、及びＦは、項目を承認すべきゲート（人／地位／職務）を表している。
【００７６】
［（（Ａ∪Ｂ）∩Ｅ）∩（Ｃ∩Ｄ）］∩Ｆ
以下の表１に、この承認処理下での承認の要求のいくつもの異なる中間及び最終の解決策を示す。
【００７７】
【表１】
2005522755.tif 000003
【００７８】
結論
前述の機能は、そのままで適用されてもよく、様々な様式に拡張されてもよいことが、当業者には理解されるであろう。例えば、当該機能は、ここに説明及び図示したものに基づく様々な承認処理要素を提供してもよい。さらに、当該機能の実施形態は、ここに説明した機能の一部を用いてもよく、その機能が一部として組み込まれてもよい。前述の説明は、好適な実施形態を参照しているが、本発明の範囲は、添付の特許請求の範囲及びそこに列挙された要素によってのみ規定されるものである。
【図面の簡単な説明】
【００７９】
【図１】本発明の教示内容が実施されるマルチレイヤシステムアーキテクチャである。
【図２】本発明の教示内容が実施されるシステム構成の一実施形態のブロック図である。
【図３】本発明の教示内容に応じてアプリケーションが構築可能なマルチレイヤアーキテクチャの他の論理表現を示すブロック図である。
【図４】本発明の教示内容が実行され得るアプリケーションフレームワークの一実施形態のブロック図である。
【図５】要求の承認処理を当該機能を用いて定義する動作を示す典型的な一連の表示における最初のものを示す表示図である。
【図６】作成について図５で示された承認処理開始要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。
【図７】要求の承認処理を当該機能を用いて定義する動作を示す典型的な一連の表示における第２のものを示す表示図である。
【図８】作成について図７で示されたＡＮＤ承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。
【図９】要求の承認処理を当該機能を用いて定義する動作を示す典型的な一連の表示における第３のものを示す表示図である。
【図１０】作成について図９で示されたＯＲ承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。
【図１１】要求の承認処理を当該機能を用いて定義する動作を示す典型的な一連の表示における第４のものを示す表示図である。
【図１２】作成について図１１で示されたゲート承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。
【図１３】作成について図１１で示されたゲート承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。
【図１４】作成について図１１で示されたゲート承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。
【図１５】作成について図１１で示されたゲート承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。
【図１６】作成について図１１で示されたゲート承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。
【図１７】作成について図１１で示されたゲート承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。
【図１８】作成について図１１で示されたゲート承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。
【図１９】要求の承認処理を当該機能を用いて定義する動作を示す典型的な一連の表示における第５のものを示す表示図である。
【図２０】作成について図１９で示された判別点承認処理要素インスタンスに関連した情報を表示及び／又は編集する機能におけるさらなるユーザインタフェースの特徴を示す表示図である。
【図２１】要求承認処理の完全に定義されたバージョンを示す表示図である。
【図１】
2005522755.tif 000004
【図２】
2005522755.tif 000005
【図３】
2005522755.tif 000006
【図４】
2005522755.tif 000007
【図５】
2005522755.tif 000008
【図６】
2005522755.tif 000009
【図７】
2005522755.tif 000010
【図８】
2005522755.tif 000011
【図９】
2005522755.tif 000012
【図１０】
2005522755.tif 000013
【図１１】
2005522755.tif 000014
【図１２】
2005522755.tif 000015
【図１３】
2005522755.tif 000016
【図１４】
2005522755.tif 000017
【図１５】
2005522755.tif 000018
【図１６】
2005522755.tif 000019
【図１７】
2005522755.tif 000020
【図１８】
2005522755.tif 000021
【図１９】
2005522755.tif 000022
【図２０】
2005522755.tif 000023
【図２１】
2005522755.tif 000024
【国際調査報告】
2005522755.tif 000025
2005522755.tif 000026
2005522755.tif 000027
2005522755.tif 000028