(57)【要約】承認の要求を呈示する機能が記述されている。この機能は、第１の承認の要求及び第２の承認の要求の両方を記述した情報を同時に表示する。ここで、第１の承認の要求は、第１のアプリケーションプログラムを用いて生成され、第２の承認の要求は、第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムを用いて生成される。【特許請求の範囲】
【請求項１】
コンピュータシステムにて、承認の要求を呈示する方法であって、
第１のアプリケーションプログラムを用いて作成された第１の承認の要求を記述した情報を表示するステップ（ａ）と、
前記ステップ（ａ）と同時に、前記第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムを用いて作成された第２の承認の要求を記述した情報を表示するステップ（ｂ）とを含むことを特徴とする方法。
【請求項２】
前記ステップ（ａ）及び前記ステップ（ｂ）の両方が、単一の表示ウィンドウ内で実行されることを特徴とする請求項１記載の方法。
【請求項３】
前記ステップ（ａ）及び前記ステップ（ｂ）の両方が、第３のアプリケーションプログラムに属するアプリケーションウィンドウ内で実行されることを特徴とする請求項１記載の方法。
【請求項４】
前記方法が、さらに、第３のアプリケーションプログラムにて、前記第１の承認の要求及び前記第２の承認の要求の両方に対処することを指定したユーザの入力を受信することを特徴とする請求項１記載の方法。
【請求項５】
受信された前記ユーザの入力は、前記第１の承認の要求及び前記第２の承認の要求の両方を承認することを指定していることを特徴とする請求項４記載の方法。
【請求項６】
前記方法が、さらに、前記第３のアプリケーションプログラムにて受信された前記ユーザの入力に従って、前記第１の承認の要求及び前記第２の承認の要求を解決することを特徴とする請求項４記載の方法。
【請求項７】
前記方法が、さらに、
前記第１の承認の要求を記述して表示された情報とともに表示されたコントロールを選択したユーザの入力を取得し、
前記ユーザの入力に応答して、前記第１の承認の要求を記述した追加情報を表示することを特徴とする請求項１記載の方法。
【請求項８】
前記追加情報は、前記第１のアプリケーションプログラムの制御の下で表示されることを特徴とする請求項７記載の方法。
【請求項９】
前記追加情報は、前記第１の承認の要求に関連した前記第１のアプリケーションプログラムの表示を用いて表示されることを特徴とする請求項７記載の方法。
【請求項１０】
さらに、前記第１の承認の要求の１人又は２人以上の以前の承認者によりなされた処理についての情報を表示することを特徴とする請求項１記載の方法。
【請求項１１】
表示データ構造を一括して含む１つ又は２つ以上のコンピュータメモリであって、前記表示データ構造は、
第１のアプリケーションプログラムを用いて作成された第１の承認の要求を記述した情報と、
前記第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムを用いて作成された第２の承認の要求を記述した情報とが、同時に表示されるようにする情報を含むことを特徴とするコンピュータメモリ。
【請求項１２】
コンピュータシステムにて、承認の要求を解決する方法であって、
第１の承認の要求を記述した情報を表示し、
第２の承認の要求を記述した情報を表示し、
前記第１の承認の要求及び前記第２の承認の要求が表示された状態で、ユーザの単一の対話を受信し、
受信された前記ユーザの単一の対話に応答して、さらなるユーザの入力を受信することなく、前記第１の承認の要求及び前記第２の承認の要求の両方の解決を遂行することを特徴とする方法。
【請求項１３】
受信された前記ユーザの単一の対話は、ポインティングデバイスによる選択であることを特徴とする請求項１２記載の方法。
【請求項１４】
受信された前記ユーザの単一の対話は、マウスクリックであることを特徴とする請求項１１記載の方法。
【請求項１５】
受信された前記ユーザの単一の対話は、視覚的ユーザインタフェースコントロール内のマウスクリックであることを特徴とする請求項１２記載の方法。
【請求項１６】
受信されたユーザの単一の対話は、ボタン内のマウスクリックであることを特徴とする請求項１２記載の方法。
【請求項１７】
前記方法が、さらに、前記第１の承認の要求及び前記第２の承認の要求が表示された状態で、ユーザの単一の対話を受信する前に、前記第１の承認の要求及び前記第２の承認の要求が解決されるべき手法を指定した以前のユーザの対話を受信することを特徴とする請求項１２記載の方法。
【請求項１８】
前記の以前のユーザの対話は、少なくとも、表示された第１の承認の要求に対して近接して表示されたチェックボックスをクリックすることを含むことを特徴とする請求項１７記載の方法。
【請求項１９】
前記第１の承認の要求及び前記第２の承認の要求が表示されている間は、その他のユーザの対話が受信されることはないことを特徴とする請求項１２記載の方法。
【請求項２０】
承認の要求を解決するコンピュータシステムであって、
第１の承認の要求を記述した情報及び第２の承認の要求を記述した情報が表示される表示装置と、
前記第１の承認の要求及び前記第２の承認の要求が前記表示装置上に表示されている間に、ユーザの単一の対話を受信する入力サブシステムと、
前記入力サブシステムにより受信された前記ユーザの単一の対話の受領に応答して、前記第１の承認の要求及び前記第２の承認の要求の両方の解決を遂行する処理サブシステムとを、備えたことを特徴とするコンピュータシステム。
【請求項２１】
コンピュータシステムにて、承認の要求を呈示する方法であって、
第１のユーザに対して、該第１のユーザが対処するように指定された承認の要求を表示し、
前記第１のユーザに対して、前記承認の要求に対処するためのコントロールを表示し、
前記第１のユーザが、前記承認の要求に対して関連づけられた時間が経過する前に、前記第１のユーザに対して表示された前記コントロールに対処しない場合、
前記承認の要求を、前記第１のユーザとは異なる第２のユーザに対して表示し、
前記第２のユーザに対して、前記承認の要求に対処するためのコントロールを表示することを特徴とする方法。
【請求項２２】
前記第２のユーザを、前記第１のユーザの識別情報に基づいて選択することを特徴とする請求項２１記載の方法。
【請求項２３】
前記承認の要求に対して関連づけられた時間は、前記承認の要求が作成された後の選択された期間であることを特徴とする請求項２１記載の方法。
【請求項２４】
前記承認の要求に対して関連づけられた時間は、前記承認の要求が前記第１のユーザに対して表示された後の選択された期間であることを特徴とする請求項２１記載の方法。
【請求項２５】
前記承認の要求に対して関連づけられた時間は、選択された期間に基づいており、
前記方法は、さらに、前記期間の長さを、前記承認の要求に対して関連づけられた型に基づいて選択することを特徴とする請求項２１記載の方法。
【請求項２６】
前記承認の要求に対して関連づけられた時間は、選択された時間に基づいており、
前記方法は、さらに、前記期間の長さを、前記承認の要求の緊急性のレベルの表示に基づいて選択することを特徴とする請求項２１記載の方法。
【請求項２７】
前記承認の要求に対して関連づけられた時間は、選択された時間に基づいており、
さらに、前記期間の長さを、前記承認の要求の重要性のレベルの表示に基づいて選択することを特徴とする請求項２１記載の方法。
【請求項２８】
前記第１のユーザが、前記承認の要求に対して関連づけられた時間が経過する前に、前記承認の要求を承認するかまたは却下するために、前記の表示されたコントロールを用いなかった場合、前記承認の要求が、前記第２のユーザに対して表示されることを特徴とする請求項２１記載の方法。
【請求項２９】
コンピュータ読み取り可能な媒体の１つ又は２つ以上のインスタンスであって、該インスタンスのコンテンツが一括してコンピュータシステムに作用し、
第１のユーザに対して、該第１のユーザが対処するように指定された承認の要求を表示し、
前記第１のユーザに対して、前記承認の要求に対処するためのコントロールを表示し、
前記第１のユーザが、前記承認の要求に対して関連づけられた時間が経過する前に、前記第１のユーザに対して表示された前記コントロールに対処しない場合、
前記承認の要求を、前記第１のユーザとは異なる第２のユーザに対して表示し、
前記第２のユーザに対して、前記承認の要求に対処するためのコントロールを表示することにより、前記コンピュータシステムに承認の要求を呈示させることを特徴とするインスタンス。
【請求項３０】
コンピュータシステムにて、承認の要求を呈示する方法であって、
特定のユーザへ向けられた複数の承認の要求の各々について、
前記特定のユーザに対して、承認の要求を記述した情報を表示し、
前記承認の要求に対して関連づけられた期限が既に超過したかどうかを判別し、
前記承認の要求に対して関連づけられた期限が既に超過している場合、前記特定のユーザに対して、承認の要求を記述した表示された情報の中で、前記承認の要求に対して関連づけられた期限が既に超過している旨の指示を表示することを特徴とする方法。
【請求項３１】
特定のユーザへ向けられた複数の承認の要求に関する表示データ構造を一括して含む１つ又は２つ以上のコンピュータメモリであって、前記複数の承認の要求の各々に対して期限が関連づけられ、前記表示データ構造は、特定のユーザに対して表示されるようにする情報を含み、前記複数の承認の要求の各々について、当該情報は承認の要求を記述し、当該情報は、超過した期限が関連づけられた複数の承認の要求の各々について、前記承認の要求に対して関連づけられた前記期限が既に超過している旨の指示を含むことを特徴とするコンピュータメモリ。
【請求項３２】
コンピュータシステムにて、承認の要求を呈示する方法であって、
時間及び時間における方向を指定するユーザの入力を受信し、
各々に期限がある複数の承認の要求の中から、指定された方向において指定された時間により補足された現在時刻よりも期限が後になったものを選択し、
選択されていない複数の承認の要求についての情報を表示することなく、選択された承認の要求の各々についての情報を表示することを特徴とする方法。
【請求項３３】
受信されたユーザの入力は、その期限が将来へ向けて指定された時間を超えていない承認の要求が選択されるように、時間における経過方向を指定することを特徴とする請求項３２記載の方法。
【請求項３４】
受信された前記ユーザの入力は、その期限が過去へ向けて指定された時間を超えていない承認の要求が選択されるように、時間における経過方向を指定することを特徴とする請求項３２記載の方法。
【請求項３５】
受信された前記ユーザの入力は、その期限が現在時刻を超えていない承認の要求が選択されるように、０時間を指定することを特徴とする請求項３２記載の方法。
【請求項３６】
コンピュータ読み取り可能な媒体の１つ又は２つ以上のインスタンスであって、該インスタンスのコンテンツが一括してコンピュータシステムに作用し、
方向付けがなされた時間を指定するユーザの入力を受信し、
各々に期限がある複数の承認の要求の中から、指定されかつ方向付けがなされた時間により補足された現在時刻よりも期限が後になったものを選択し、
選択されていない複数の承認の要求についての情報を表示することなく、選択された承認の要求の各々についての情報を表示することにより、前記コンピュータシステムに承認の要求を呈示させることを特徴とするインスタンス。
【請求項３７】
コンピュータシステムにて、承認の要求を呈示する方法であって、
１人又は２人以上の承認者に承認の要求を呈示するための複数の呼出要求を受信し、該呼出要求の各々は、承認の要求を記述した情報を含み、
前記呼出要求の受信に応答して、前記承認の要求を承認者に呈示することを特徴とする方法。
【請求項３８】
前記呼出要求は、第１のアプリケーションプログラム、及び該第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムの両方から受信されることを特徴とする請求項３７記載の方法。
【請求項３９】
前記呼出要求は、第１のアプリケーションプログラム、及び該第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムの両方から受信され、前記第１のアプリケーションプログラムから受信された前記呼出要求は、第１の型の承認の要求を呈示するためのものであり、前記第２のアプリケーションプログラムから受信された前記呼出要求は、前記第１の型とは異なる第２の型の承認の要求を呈示するためのものであることを特徴とする請求項３７記載の方法。
【請求項４０】
コンピュータシステムにて、承認の要求を呈示する方法であって、
１人又は２人以上の承認者に承認の要求を呈示するための呼出要求を送信し、該呼出要求の各々は、当該呼出要求を特定するとともに承認者を特定する情報を含み、
送信された前記呼出要求の通知を受信することを特徴とする方法。
【請求項４１】
送信された前記呼出要求は、承認の要求を１人又は２人以上の承認者に呈示する業務サービスについての呼出要求であることを特徴とする請求項４０記載の方法。
【請求項４２】
送信された前記呼出要求は、承認の要求を表す業務オブジェクトを特定する情報を含むことを特徴とする請求項４０記載の方法。
【請求項４３】
呼出データ構造を含むコンピュータメモリであって、該呼出データ構造は、承認の要求を１人又は２人以上の承認者に呈示するための呼出要求を表し、
承認の要求を記述した情報と、
前記承認の要求についての２つ以上の可能な解決策の指定とを含むことを特徴とするコンピュータメモリ。
【請求項４４】
前記コンピュータメモリが、第１の呼出データ及び第２の呼出データ構造を含み、前記第１の呼出データ構造は、前記第１のアプリケーションプログラムにより構築され、前記第２の呼出データ構造は、前記第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムにより構築されることを特徴とする請求項４３記載のコンピュータメモリ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はオフィスオートメーションの分野に関し、特に、承認の要求を処理する分野に関する。
【背景技術】
【０００２】
多くの企業組織は、事案を認証する承認処理を利用している。なお、承認処理においては、組織におけるある構成員が、組織における別の構成員による承認のための要求を提出しなければならない。例えば、組織の承認処理には、組織におけるある種の構成員が、労働時間を記録した就労時間集計票を提出する度に、管理者から承認を得る必要があることもある。通常の承認処理には、組織の構成員が、このような要求を、経費、レポート、休暇願、目的及び評価、転属、雇用、昇進、訓練願、奨励補償願、契約、発注、見積、プレスリリース、並びに、ウェブ掲載用コンテンツ等、他の様々な環境において提出する必要があることもある。
【０００３】
通常の組織では、これらの型の承認の要求のいくつかは、要求者により手動で作成されてから、承認者へと電子メールで送信される。例えば、転属の要求は、要求者により手動で作成されてから、承認者へと電子メールで送信されることがある。多くの場合、このような組織の構成員は、このような電子メールで送信された承認の要求を、かなりの量、処理することが必要とされている。このように電子メールで送信された承認の要求は、他の型の着信電子メールメッセージの中に点在しているので、承認の要求であることを特定するのが困難であることが多い。電子メールで送信された特定の承認の要求が既決であるかどうか、そして、どのように処理されたかを特定すること、あるいは、上記のように電子メールで送信されて受信されたものの未決であるような承認の要求を特定することは、困難又は不可能であることもあり得る。
【０００４】
他の型の承認の要求は、いくつもの様々なアプリケーションプログラムの１つを用いて生成されてもよい。例えば、就労時間集計票を作成して承認のために提出するのには、就労時間集計票アプリケーションが使用されることになるが、注文書を作成して承認のために提出するのには、独立した発注アプリケーションが使用される。このような場合において、承認者は、上記のようなアプリケーションを個別に開いて、当該アプリケーションにより作成された承認の要求に対処することが必要となる。前述の例では、例えば、承認者は、就労時間集計表及び注文書をそれぞれ承認するために、就労時間集計表及び発注アプリケーションを個別に開く必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
前述の承認の要求を処理するための従来の手法の実質的な欠点を考慮すると、さらに効率的でユーザにとって利用しやすい手法が有用となるであろう。
【課題を解決するための手段】
【０００６】
前述のような従来の手法の問題点に対処するために、承認の要求を処理するソフトウェア機能（以下、単に「当該機能」という）が提供されている。ある種の実施形態では、当該機能は、様々なアプリケーションにより作成された承認の要求（以下、単に「要求」と称することもある）を審査して処理するための「承認受信箱」と称することもある単一のユーザインタフェースを提供している。例えば、就労時間集計票の承認の要求が、就労時間集計票を用いて作成され、注文書の承認の要求が、発注アプリケーションを用いて作成される場合、当該機能は、就労時間集計票の要求及び注文書の要求の両方を審査して処理するために、単一のユーザインタフェースを提供する。
【０００７】
ある種の実施形態では、当該機能は、ユーザがマウスを１回クリックする等の単一の対話を実行することによって、いくつものそれぞれの要求に対処することを可能にするようなユーザインタフェースを提供する。例えば、ユーザは、４つの異なる要求を承認するために、単一の対話を実行してもよい。
【０００８】
ある種の実施形態では、要求に対処する役割を有するユーザが、所定の時間内に承認しなかった場合に、当該要求は代替のユーザへと再転送される。例えば、就労時間集計票の要求に対処する役割を有するユーザが、この就労時間集計票の要求を受け取った週の内に承認しなかった場合、当該就労時間集計票の要求は、ユーザの対処すべき要求のリストから削除されて、ユーザの管理者へと再転送される。
【０００９】
ある種の実施形態では、当該機能は、期限切れで未決の要求を識別する視覚的指示を表示する。例えば、各々の要求がそれ自身の行にリストアップされている場合、当該機能は、行の交点に期限切れの要求のための「期限切れ（past due）」カラムを付して、積極的な指示を表示する。
【００１０】
ある種の実施形態では、当該機能により、ユーザは、自分自身の未決の要求のサブセットを、期限に基づいて照会することができるようになっている。例えば、ユーザは、少なくとも２日前に期限切れとなった未決の要求、又は、来週に期限を迎える未決の要求を照会してもよい。
【００１１】
前述のように、承認の要求に対処するためのユーザインタフェースを提供することにより、当該機能の実施形態は、承認の要求に対処する処理を著しく簡素化する。
【発明を実施するための最良の形態】
【００１２】
システムの概観及び全体構成
一実施形態では、本発明の教示内容が実施されるシステムは、図１に示すようなマルチレイヤアーキテクチャとして論理的に構成され得る。一実施形態では、図１に示すような論理マルチレイヤアーキテクチャにより、様々なアプリケーションに対応した共通のサービス用に、プラットフォームが提供される。これらのサービスには、ユーザインタフェースレイヤ１１０、オブジェクトマネージャレイヤ１２０、データマネージャレイヤ１３０、及びデータ交換レイヤ１４０が、含まれてもよい。
【００１３】
一実施形態では、ユーザインタフェースレイヤ１１０により、１つ又は２つ以上のアプリケーションに対応したアプレット、表示、図、及びレポート等が提供されてもよい。一実施形態では、様々な型のクライアントに対して、ユーザインタフェースレイヤ１１０により対応可能となっている。これらの様々な型のクライアントとしては、従来の接続式クライアント、リモートクライアント、インターネットを介した簡略式クライアント、ジャバ（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）等とともに提供するような、ウェブベースのアプリケーションを構築及び管理する機能が、含まれてもよい。
【００４５】
一実施形態では、設計時ツールが、統合点をカスタマイズしたり設計したり提供したりするためのサービス、及び、アプリケーションを指示するためのサービスを提供するように、設計及び構成されてもよい。これらの様々なツールは、アプリケーションを規定する１つの共通の場を提供する。
【００４６】
一実施形態では、管理サービスが、アプリケーション環境を監視及び管理するための１つの共通の場を提供するように、設計及び構成される。一実施形態では、これらのサービスにより、ユーザは、グラフィックユーザインタフェース（ＧＵＩ）又はコマンドラインを介してアプリケーションを管理することが可能となる。
機能及びその実施形態
以下、当該機能についてさらに説明するために、いくつもの表示図の例とともに、その実施形態及び動作について考察する。
【００４７】
図５は、承認の要求を１つ含む代表的な承認受信箱表示を示す表示図である。図示の如く、表示５００は、カラム５０１〜５１１、及び行５２０のような行へと分割されたテーブルである。このような表示は、その代替として、様々な他の形式で構成されてもよいことが、当業者には理解されるであろう。各々の行は、承認受信箱が表示されるユーザが対処可能な承認の要求に対応している。各々の承認の要求に対処すべきユーザは、様々な異なる方法で、決定されてもよい。その方法の１つとして、米国特許商標庁にて係属中の米国特許出願（特許代理人の事件番号３８４８１−８００４ＵＳ００）に記載のものがあり、その内容の全てが、本願明細書に一体に組み入れられている。要求は、通常、処理されるまで承認受信箱内に保持されるが、ある種の実施形態では、他の状況下においてある要求が承認受信箱から削除される。それは、上記要求が、その作成者により取り下げられる場合、対処すべき期限が経過したために、権限を有する他の承認者に委譲される場合、及び、他の承認者が処理したために現行の承認者の処理が不要になる場合等である。
【００４８】
行５２０は、特定の承認の要求に対応しており、複数のカラムの各々に情報が含まれている。行５２０とカラム５０１との交点により、承認の要求が新規であること、すなわち、承認の要求が承認受信箱に以前に表示されたことがないことがわかる。行５２０とカラム５０２との交点では、承認の要求に要求識別番号０１０１が付されていることがわかる。行５２０とカラム５０３との交点では、承認の要求の型が経費であることがわかる。行５２０とカラム５０４との交点では、承認の要求が「Ｊルイス」により作成されたことがわかる。行５２０とカラム５０５との交点では、承認の要求の摘要が「南アジア出張」であることがわかる。行５２０とカラム５０６との交点では、２００１年４月１０日に受理されたことがわかる。行５２０とカラム５０７との交点では、その状態が受理になっていることがわかる。当該状態としては、不受理、受入可、承認済及び却下等の他の様々な状態もとり得る。行５２０とカラム５０９との交点では、承認の要求が承認受信箱内に０日間表示されていることがわかる。行５２０とカラム５１０との交点では、要求の承認期限は２００１年４月１７日であることがわかる。行５２０とカラム５１１との交点では、要求が期限超過（期限切れ）になっていないことがわかる。
【００４９】
図６は、承認受信箱に示された要求のための追加の情報に関する代表的な表示を示す表示図である。図６では、ユーザは、行６２０に表示された要求の摘要６２１をクリックして、この要求についての追加情報６９０を表示させる。本実施例では、この要求について以下の追加情報が表示される。すなわち、当該追加情報は、上記要求の摘要、この摘要が適用される期間、経費合計額、及び経費報告が適用される予算科目である。ある種の実施形態では、この追加情報を表示するために、当該機能は、この承認の要求を生成するのに用いられるアプリケーションプログラム、ここでは、経費報告アプリケーションを呼び出す。
【００５０】
図７は、ユーザが要求に対処している代表的な承認受信箱を示す表示図である。行７２０の要求の現行の状態をクリックすることにより、ユーザは、当該機能に、この要求のとり得る状態のドロップダウンリスト７２１を表示させている。引き続き、ユーザは、ドロップダウンボックス内の複数の状態から特定の１つを、その状態を上記要求の属性とするために選択する。例えば、ユーザは、上記要求を承認するために、承認済の状態を選択してもよく、あるいは、上記要求を却下するために却下の状態を選択してもよい。ある種の実施形態では、このような処理により、当該機能は、上記要求を作成するのに用いられたアプリケーションプログラム（ここでは経費報告アプリケーション）に対して解決策の通知を送信することになる。
【００５１】
図８乃至図１１は、未決の要求に対処するための機能のある種の実施形態により提供される追加のユーザインタフェース技術を示す表示図である。図８は、未決の要求を３つ含む承認受信箱の第１の代表的な表示を示す表示図である。カラム８０８では、全チェックボックスのチェックの承認８５０がチェックされていることがわかる。そして、ユーザが送信ボタン８７０をクリックすると、承認受信箱内に表示されている３つの未決の要求の全てが、同時に承認される。ある種の実施形態では、このような処理により、当該機能は、承認された各々の要求を作成するのに用いられたアプリケーションへ、承認通知を送信することになる。ある種の実施形態では、チェックボックス８５０は、最初はデフォルト（default ）でチェックされていて、ユーザが、単に送信ボタン８７０をクリックするだけで、全ての表示されている要求を承認することができるようにしている。
【００５２】
図９は、未決の要求を３つ含む承認受信箱の第２の代表的な表示を示す表示図である。カラム９０８では、全チェックボックスの承認９５０及び全チェックボックスの却下９６０は、いずれもチェックされていないので、表示された要求が個別に処理可能となっていることがわかる。さらに、行９２０及び９４０の承認チェックボックス９５１及び９５３がそれぞれチェックされていることがわかる。そして、ユーザが送信ボタン９７０をクリックすると、行９２０及び９４０により表される要求は、同時に承認される。
【００５３】
図１０は、未決の要求を３つ含む承認受信箱の第３の代表的な表示を示す表示図である。カラム１００８では、ユーザが全チェックボックスの却下１０６０をチェックしていることがわかる。そして、ユーザが送信ボタン１０７０をクリックすると、承認受信箱内に表示されている３つの未決の要求の全てが、同時に却下される。ある種の実施形態では、この処理により、当該機能は、３つの要求の各々を作成するのに用いられたアプリケーションへ、却下通知を送信することになる。
【００５４】
図１１は、未決の要求を３つ含む承認受信箱の第４の代表的な表示を示す表示図である。カラム１１０８では、行１１２０及び１１４０の承認チェックボックス１１６１及び１１６３がそれぞれチェックされていることがわかる。そして、ユーザが送信ボタン１１７０をクリックすると、行１１２０及び１１４０に示される２つの未決の要求は、同時に却下される。
【００５５】
図１２は、未決の要求のフィルタ処理済リストの表示を示す表示図である。この図は、承認受信箱内に表示されている承認の要求のリストにユーザがフィルタをかける際に使用可能な「ＰＤＱ」メニューを示している。このメニューには、新規項目エントリ１２９１等の複数のメニューが含まれている。この新規項目エントリ１２９１は、ユーザにより選択されると、表示される要求を、カラム１２０１内の新規のフラグが立っているものに制限する。さらに、経費報告エントリ１２９２が含まれている。この経費報告エントリ１２９２は、ユーザにより選択されると、表示される要求を、型のカラム１２０２にて経費報告として指定されたものに制限する。さらに、期限超過（期限切れ）エントリ１２９３が含まれている。この期限超過エントリ１２９３は、ユーザにより選択されると、表示される要求を、期限超過カラム１２１１が「ＹＥＳ（はい）」になったものに制限する。承認受信箱１２００には、ユーザが超過期限エントリを選択した場合に当該機能により表示される未決要求のリストが示されており、その全てについて期限が超過している。表示される要求のリストにフィルタをかけるのに、他の様々な属性が使用可能であることが、当業者には理解されるであろう。
【００５６】
図１３は、未決の要求の承認履歴の表示を示す表示図である。ウィンドウ１３００には、未決の要求のリストが含まれる。ここでは、未決の要求１３１１が１つ含まれている。リストアップされた各々の要求のために、フィールド１３０１〜１３０７が表示されている。ここでは、未決の要求１３１１が選択されている。ウィンドウ１３２０には、ウィンドウ１３００内で選択された要求の承認履歴が示されている。より具体的には、ウィンドウ１３２０には、以前の承認者が当該要求の承認処理で行った承認処理１３３１及び１３３２が示されている。各々の処理について、ウィンドウ１３２０には、承認者の識別情報１３２１、状態又はなされた処理１３２２、上記要求が承認者により受理された日時１３２３、処理が現行のものであるかどうかの表示１３２４、承認者によりなされたコメント１３２５、及びタスクの所有者の識別子１３２６が示されている。
【００５７】
ある種の実施形態では、当該機能は、適切な承認者に呈示すべく新規に作成された要求を送信するために、承認の要求を作成したアプリケーションにより呼び出され得るアプリケーションプログラムインタフェース（ＡＰＩ）を提供している。ある種の実施形態では、このＡＰＩは、業務サービスとして提供されている。このＡＰＩには、一般に、２つの方法（メソッド）が含まれている。すなわち、一つのメソッドとして、当該新規の要求を適切な承認者に対して送信するために「送信メソッド」が呼び出され、他のメソッドとして、送信された要求を処理前に呈示から取り下げるために、「取下メソッド」が呼び出される。
【００５８】
送信メソッドを呼び出す場合、通常、アプリケーションは、承認識別子、型、作成者、適用、及び期限日、並びに当該要求のために利用可能な解決策の様々な形式の指示等、承認受信箱内で各々の要求について表示された情報のいくつか又は全てを渡す。要求の型は、特定の業務オブジェクトクラスの用語で特定されてもよい。送信メソッドを呼び出す場合、アプリケーションは、要求についての詳細情報を表示することを当該アプリケーションに対してどのように通知するか、及び、承認者により選択された要求の解決策を当該アプリケーションに対してどのように通知するかといったような情報を、さらに渡してもよい。要求についての詳細情報を表示することをアプリケーションに対してどのように通知するかについての情報は、要求についての詳細情報の表示先である基底のアプリケーションの表示を特定してもよい。ある種の実施形態では、送信メソッドは、当該機能内で要求を一意的に特定する識別子を返却してもよい。この識別子は、アプリケーションと当該機能との間での後続の通信において、要求を特定するために用いられてもよい。
【００５９】
取下メソッドを呼び出す場合、通常、アプリケーションは、このアプリケーションにより要求に対して割り当てられた識別子のような、取り下げるべき要求の識別子、又は、当該機能により要求に対して割り当てられた識別子を、当該機能に渡す。例えば、要求を作成したアプリケーションが、要求を作成したユーザにより、この要求を取り下げるように命令された場合、アプリケーションは、特定の要求について、取下メソッドを呼び出してもよい。例えば、ユーザが要求を作成した後、要求内に見つかった誤りを訂正するために、ユーザが上記のように要求を取り下げることもある。要求の送信及び取下のために、他の様々な手法が代用され得ることが、当業者には認識されるであろう。
結論
前述の機能は、そのままで適用されてもよく、様々な様式に拡張されてもよいことが、当業者には理解されるであろう。例えば、ここに説明した技術の任意のサブセットが、当該機能の実施形態により用いられてもよい。実際には、任意の型の承認の要求が、当該機能により処理されてもよく、上記要求は、承認又は却下以外の他の様々な様式で解決されてもよい。上記要求は、ユーザが対処しなかった場合には、個々のユーザの承認受信箱の表示から削除されてもよい。前述の説明は、好適な実施形態を参照しているが、本発明の範囲は、添付の特許請求の範囲及びそこに列挙された要素によってのみ規定されるものである。
【図面の簡単な説明】
【００６０】
【図１】本発明の教示内容が実施されるマルチレイヤシステムアーキテクチャである。
【図２】本発明の教示内容が実施されるシステム構成の一実施形態のブロック図である。
【図３】本発明の教示内容に応じてアプリケーションが構築可能なマルチレイヤアーキテクチャの他の論理表現を示すブロック図である。
【図４】本発明の教示内容が実行され得るアプリケーションフレームワークの一実施形態のブロック図である。
【図５】承認の要求を１つ含む代表的な承認受信箱表示を示す表示図である。
【図６】承認受信箱に示された要求のための追加の情報に関する代表的な表示を示す表示図である。
【図７】ユーザが要求に対処している代表的な承認受信箱を示す表示図である。
【図８】未決の要求に対処するための機能のある種の実施形態により提供される追加のユーザインタフェース技術を示す表示図である。
【図９】未決の要求に対処するための機能のある種の実施形態により提供される追加のユーザインタフェース技術を示す表示図である。
【図１０】未決の要求に対処するための機能のある種の実施形態により提供される追加のユーザインタフェース技術を示す表示図である。
【図１１】未決の要求に対処するための機能のある種の実施形態により提供される追加のユーザインタフェース技術を示す表示図である。
【図１２】未決の要求のフィルタ処理済リストの表示を示す表示図である。
【図１３】未決の要求の承認履歴の表示を示す表示図である。
【図１】
2005521974.tif 000002
【図２】
2005521974.tif 000003
【図３】
2005521974.tif 000004
【図４】
2005521974.tif 000005
【図５】
2005521974.tif 000006
【図６】
2005521974.tif 000007
【図７】
2005521974.tif 000008
【図８】
2005521974.tif 000009
【図９】
2005521974.tif 000010
【図１０】
2005521974.tif 000011
【図１１】
2005521974.tif 000012
【図１２】
2005521974.tif 000013
【図１３】
2005521974.tif 000014
【手続補正書】
【提出日】平成17年3月3日(2005.3.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピュータシステムにて、承認の要求を呈示する方法であって、
第１のアプリケーションプログラムを用いて作成された第１の承認の要求を記述した情報を表示するステップ（ａ）と、
前記ステップ（ａ）と同時に、前記第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムを用いて作成された第２の承認の要求を記述した情報を表示するステップ（ｂ）とを含むことを特徴とする方法。
【請求項２】
前記ステップ（ａ）及び前記ステップ（ｂ）の両方が、単一の表示ウィンドウ内で実行されることを特徴とする請求項１記載の方法。
【請求項３】
前記ステップ（ａ）及び前記ステップ（ｂ）の両方が、第３のアプリケーションプログラムに属するアプリケーションウィンドウ内で実行されることを特徴とする請求項１記載の方法。
【請求項４】
前記方法が、さらに、第３のアプリケーションプログラムにて、前記第１の承認の要求及び前記第２の承認の要求の両方に対処することを指定したユーザの入力を受信することを特徴とする請求項１記載の方法。
【請求項５】
受信された前記ユーザの入力は、前記第１の承認の要求及び前記第２の承認の要求の両方を承認することを指定していることを特徴とする請求項４記載の方法。
【請求項６】
前記方法が、さらに、前記第３のアプリケーションプログラムにて受信された前記ユーザの入力に従って、前記第１の承認の要求及び前記第２の承認の要求を解決することを特徴とする請求項４記載の方法。
【請求項７】
前記方法が、さらに、
前記第１の承認の要求を記述して表示された情報とともに表示されたコントロールを選択したユーザの入力を取得し、
前記ユーザの入力に応答して、前記第１の承認の要求を記述した追加情報を表示することを特徴とする請求項１記載の方法。
【請求項８】
前記追加情報は、前記第１のアプリケーションプログラムの制御の下で表示されることを特徴とする請求項７記載の方法。
【請求項９】
前記追加情報は、前記第１の承認の要求に関連した前記第１のアプリケーションプログラムの表示を用いて表示されることを特徴とする請求項７記載の方法。
【請求項１０】
さらに、前記第１の承認の要求の１人又は２人以上の以前の承認者によりなされた処理についての情報を表示することを特徴とする請求項１記載の方法。
【請求項１１】
表示データ構造を一括して含む１つ又は２つ以上のコンピュータメモリであって、前記表示データ構造は、
第１のアプリケーションプログラムを用いて作成された第１の承認の要求を記述した情報と、
前記第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムを用いて作成された第２の承認の要求を記述した情報とが、同時に表示されるようにする情報を含むことを特徴とするコンピュータメモリ。
【請求項１２】
コンピュータシステムにて、承認の要求を解決する方法であって、
第１の承認の要求を記述した情報を表示し、
第２の承認の要求を記述した情報を表示し、
前記第１の承認の要求及び前記第２の承認の要求が表示された状態で、ユーザの単一の対話を受信し、
受信された前記ユーザの単一の対話に応答して、さらなるユーザの入力を受信することなく、前記第１の承認の要求及び前記第２の承認の要求の両方の解決を遂行することを特徴とする方法。
【請求項１３】
受信された前記ユーザの単一の対話は、ポインティングデバイスによる選択であることを特徴とする請求項１２記載の方法。
【請求項１４】
受信された前記ユーザの単一の対話は、マウスクリックであることを特徴とする請求項１２記載の方法。
【請求項１５】
受信された前記ユーザの単一の対話は、視覚的ユーザインタフェースコントロール内のマウスクリックであることを特徴とする請求項１２記載の方法。
【請求項１６】
受信されたユーザの単一の対話は、ボタン内のマウスクリックであることを特徴とする請求項１２記載の方法。
【請求項１７】
前記方法が、さらに、前記第１の承認の要求及び前記第２の承認の要求が表示された状態で、ユーザの単一の対話を受信する前に、前記第１の承認の要求及び前記第２の承認の要求が解決されるべき手法を指定した以前のユーザの対話を受信することを特徴とする請求項１２記載の方法。
【請求項１８】
前記の以前のユーザの対話は、少なくとも、表示された第１の承認の要求に対して近接して表示されたチェックボックスをクリックすることを含むことを特徴とする請求項１７記載の方法。
【請求項１９】
前記第１の承認の要求及び前記第２の承認の要求が表示されている間は、その他のユーザの対話が受信されることはないことを特徴とする請求項１２記載の方法。
【請求項２０】
承認の要求を解決するコンピュータシステムであって、
第１の承認の要求を記述した情報及び第２の承認の要求を記述した情報が表示される表示装置と、
前記第１の承認の要求及び前記第２の承認の要求が前記表示装置上に表示されている間に、ユーザの単一の対話を受信する入力サブシステムと、
前記入力サブシステムにより受信された前記ユーザの単一の対話の受領に応答して、前記第１の承認の要求及び前記第２の承認の要求の両方の解決を遂行する処理サブシステムとを、備えたことを特徴とするコンピュータシステム。
【請求項２１】
コンピュータシステムにて、承認の要求を呈示する方法であって、
第１のユーザに対して、該第１のユーザが対処するように指定された承認の要求を表示し、
前記第１のユーザに対して、前記承認の要求に対処するためのコントロールを表示し、
前記第１のユーザが、前記承認の要求に対して関連づけられた時間が経過する前に、前記第１のユーザに対して表示された前記コントロールに対処しない場合、
前記承認の要求を、前記第１のユーザとは異なる第２のユーザに対して表示し、
前記第２のユーザに対して、前記承認の要求に対処するためのコントロールを表示することを特徴とする方法。
【請求項２２】
前記第２のユーザを、前記第１のユーザの識別情報に基づいて選択することを特徴とする請求項２１記載の方法。
【請求項２３】
前記承認の要求に対して関連づけられた時間は、前記承認の要求が作成された後の選択された期間であることを特徴とする請求項２１記載の方法。
【請求項２４】
前記承認の要求に対して関連づけられた時間は、前記承認の要求が前記第１のユーザに対して表示された後の選択された期間であることを特徴とする請求項２１記載の方法。
【請求項２５】
前記承認の要求に対して関連づけられた時間は、選択された期間に基づいており、
前記方法は、さらに、前記期間の長さを、前記承認の要求に対して関連づけられた型に基づいて選択することを特徴とする請求項２１記載の方法。
【請求項２６】
前記承認の要求に対して関連づけられた時間は、選択された時間に基づいており、
前記方法は、さらに、前記期間の長さを、前記承認の要求の緊急性のレベルの表示に基づいて選択することを特徴とする請求項２１記載の方法。
【請求項２７】
前記承認の要求に対して関連づけられた時間は、選択された時間に基づいており、
さらに、前記期間の長さを、前記承認の要求の重要性のレベルの表示に基づいて選択することを特徴とする請求項２１記載の方法。
【請求項２８】
前記第１のユーザが、前記承認の要求に対して関連づけられた時間が経過する前に、前記承認の要求を承認するかまたは却下するために、前記の表示されたコントロールを用いなかった場合、前記承認の要求が、前記第２のユーザに対して表示されることを特徴とする請求項２１記載の方法。
【請求項２９】
コンピュータ読み取り可能な媒体の１つ又は２つ以上のインスタンスであって、該インスタンスのコンテンツが一括してコンピュータシステムに作用し、
第１のユーザに対して、該第１のユーザが対処するように指定された承認の要求を表示し、
前記第１のユーザに対して、前記承認の要求に対処するためのコントロールを表示し、
前記第１のユーザが、前記承認の要求に対して関連づけられた時間が経過する前に、前記第１のユーザに対して表示された前記コントロールに対処しない場合、
前記承認の要求を、前記第１のユーザとは異なる第２のユーザに対して表示し、
前記第２のユーザに対して、前記承認の要求に対処するためのコントロールを表示することにより、前記コンピュータシステムに承認の要求を呈示させることを特徴とするインスタンス。
【請求項３０】
コンピュータシステムにて、承認の要求を呈示する方法であって、
特定のユーザへ向けられた複数の承認の要求の各々について、
前記特定のユーザに対して、承認の要求を記述した情報を表示し、
前記承認の要求に対して関連づけられた期限が既に超過したかどうかを判別し、
前記承認の要求に対して関連づけられた期限が既に超過している場合、前記特定のユーザに対して、承認の要求を記述した表示された情報の中で、前記承認の要求に対して関連づけられた期限が既に超過している旨の指示を表示することを特徴とする方法。
【請求項３１】
特定のユーザへ向けられた複数の承認の要求に関する表示データ構造を一括して含む１つ又は２つ以上のコンピュータメモリであって、前記複数の承認の要求の各々に対して期限が関連づけられ、前記表示データ構造は、特定のユーザに対して表示されるようにする情報を含み、前記複数の承認の要求の各々について、当該情報は承認の要求を記述し、当該情報は、超過した期限が関連づけられた複数の承認の要求の各々について、前記承認の要求に対して関連づけられた前記期限が既に超過している旨の指示を含むことを特徴とするコンピュータメモリ。
【請求項３２】
コンピュータシステムにて、承認の要求を呈示する方法であって、
時間及び時間における方向を指定するユーザの入力を受信し、
各々に期限がある複数の承認の要求の中から、指定された方向において指定された時間により補足された現在時刻よりも期限が後になったものを選択し、
選択されていない複数の承認の要求についての情報を表示することなく、選択された承認の要求の各々についての情報を表示することを特徴とする方法。
【請求項３３】
受信されたユーザの入力は、その期限が将来へ向けて指定された時間を超えていない承認の要求が選択されるように、時間における経過方向を指定することを特徴とする請求項３２記載の方法。
【請求項３４】
受信された前記ユーザの入力は、その期限が過去へ向けて指定された時間を超えていない承認の要求が選択されるように、時間における経過方向を指定することを特徴とする請求項３２記載の方法。
【請求項３５】
受信された前記ユーザの入力は、その期限が現在時刻を超えていない承認の要求が選択されるように、０時間を指定することを特徴とする請求項３２記載の方法。
【請求項３６】
コンピュータ読み取り可能な媒体の１つ又は２つ以上のインスタンスであって、該インスタンスのコンテンツが一括してコンピュータシステムに作用し、
方向付けがなされた時間を指定するユーザの入力を受信し、
各々に期限がある複数の承認の要求の中から、指定されかつ方向付けがなされた時間により補足された現在時刻よりも期限が後になったものを選択し、
選択されていない複数の承認の要求についての情報を表示することなく、選択された承認の要求の各々についての情報を表示することにより、前記コンピュータシステムに承認の要求を呈示させることを特徴とするインスタンス。
【請求項３７】
コンピュータシステムにて、承認の要求を呈示する方法であって、
１人又は２人以上の承認者に承認の要求を呈示するための複数の呼出要求を受信し、該呼出要求の各々は、承認の要求を記述した情報を含み、
前記呼出要求の受信に応答して、前記承認の要求を承認者に呈示することを特徴とする方法。
【請求項３８】
前記呼出要求は、第１のアプリケーションプログラム、及び該第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムの両方から受信されることを特徴とする請求項３７記載の方法。
【請求項３９】
前記呼出要求は、第１のアプリケーションプログラム、及び該第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムの両方から受信され、前記第１のアプリケーションプログラムから受信された前記呼出要求は、第１の型の承認の要求を呈示するためのものであり、前記第２のアプリケーションプログラムから受信された前記呼出要求は、前記第１の型とは異なる第２の型の承認の要求を呈示するためのものであることを特徴とする請求項３７記載の方法。
【請求項４０】
コンピュータシステムにて、承認の要求を呈示する方法であって、
１人又は２人以上の承認者に承認の要求を呈示するための呼出要求を送信し、該呼出要求の各々は、当該呼出要求を特定するとともに承認者を特定する情報を含み、
送信された前記呼出要求の通知を受信することを特徴とする方法。
【請求項４１】
送信された前記呼出要求は、承認の要求を１人又は２人以上の承認者に呈示する業務サービスについての呼出要求であることを特徴とする請求項４０記載の方法。
【請求項４２】
送信された前記呼出要求は、承認の要求を表す業務オブジェクトを特定する情報を含むことを特徴とする請求項４０記載の方法。
【請求項４３】
呼出データ構造を含むコンピュータメモリであって、該呼出データ構造は、承認の要求を１人又は２人以上の承認者に呈示するための呼出要求を表し、
承認の要求を記述した情報と、
前記承認の要求についての２つ以上の可能な解決策の指定とを含むことを特徴とするコンピュータメモリ。
【請求項４４】
前記コンピュータメモリが、第１の呼出データ及び第２の呼出データ構造を含み、前記第１の呼出データ構造は、前記第１のアプリケーションプログラムにより構築され、前記第２の呼出データ構造は、前記第１のアプリケーションプログラムとは異なる第２のアプリケーションプログラムにより構築されることを特徴とする請求項４３記載のコンピュータメモリ。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００３５
【補正方法】変更
【補正の内容】
【００３５】
図３は、本発明の教示内容に応じてアプリケーションが構築可能なマルチレイヤアーキテクチャの他の論理表現を示すブロック図である。繰り返すと、図３に示すマルチレイヤアーキテクチャは、設計されて様々なアプリケーションに対応した様々な共通のサービスに対して、構成されたプラットフォームを提供する。一実施形態では、これらの様々なサービスには、アプレットマネージャ及びユーザインタフェースレイヤに対応したプレゼンテーションサービス・ロジックレイヤ、オブジェクトマネージャ（ＯＭ）レイヤ及びデータマネージャレイヤ（ＤＭ）に対応したアプリケーションサービス・ロジックレイヤ、並びにデータベースレイヤに対応したデータ格納サービス・ロジックレイヤが、含まれてもよい。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００３６
【補正方法】変更
【補正の内容】
【００３６】
一実施形態では、プレゼンテーションサービスは、様々な型のクライアントに対応するように設計及び構成されてもよく、これらのプレゼンテーションサービスに対してユーザインタフェースアプレット、表示、図、及びレポート等を提供してもよい。前述のように、ワイヤレスクライアント、ハンドヘルドクライアント、ウェブクライアント、移動ウェブクライアント、及び専用（接続）クライアント等、多岐に亘るクライアントに対応してもよい。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００３７
【補正方法】変更
【補正の内容】
【００３７】
一実施形態では、アプリケーションサービスには、業務ロジックサービス及びデータベース対話サービスが、含まれてもよい。一実施形態では、業務ロジックサービスは、業務オブジェクト及び業務コンポーネントの種類及び動作を提供する。一実施形態では、データベース対話サービスは、データに対するユーザインタフェース（ＵＩ）の要求を業務コンポーネントから取得して、要求を満たすために必要なデータベースコマンド（例えば、ＳＱＬの照会等）を生成するように、設計及び構成されてもよい。例えば、データ対話サービスは、データのコールをＤＢＭＳ別のＳＱＬ文に変換するために用いられてもよい。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００３８
【補正方法】変更
【補正の内容】
【００３８】
一実施形態では、データ格納サービスは、様々なアプリケーションの基礎として機能する基底のデータモデルのためにデータの格納を提供するように、設計及び構成されてもよい。例えば、データモデルは、コールセンタ、販売、サービス、及びマーケティング等の様々なソフトウェア製品及びアプリケーション、並びに、電子ファイナンス、電子保険、電子コミュニケーション、電子医療等の産業に対して縦断的な様々な製品及びアプリケーションに対応するように、設計及び構成されてもよい。
【国際調査報告】
2005521974.tif 000015