JP5949278B2

JP5949278B2 - 情報処理装置、情報処理装置の制御方法、プログラムおよび記録媒体

Info

Publication number: JP5949278B2
Application number: JP2012166426A
Authority: JP
Inventors: 賢治飯沼; 剛高塚
Original assignee: Canon Marketing Japan Inc; Canon IT Solutions Inc
Current assignee: Canon Marketing Japan Inc; Canon IT Solutions Inc
Priority date: 2012-07-27
Filing date: 2012-07-27
Publication date: 2016-07-06
Anticipated expiration: 2032-07-27
Also published as: JP2014026473A

Description

本発明は、アプリケーションのグラフィカルユーザインタフェース（ＧＵＩ）に表示される固定サイズの親のオブジェクト（以下、親オブジェクト、または上位オブジェクト）の中において、さらに子のオブジェクトやエリア（以下、子オブジェクト、または下位オブジェクト）など複数に区分して表示する際に、横（または縦、あるいはその両方）方向に、複数の下位オブジェクトを利用者に分かりやすく表示する情報処理装置に関する。

従来から、表やカレンダーのように、表示されている上位オブジェクトの中において、横または縦、あるいはその両方の方向に、下位オブジェクトを複数個並べるような表示形式のＧＵＩがある。前述のような表示形式としては、例えば上位オブジェクトがカレンダーであり、下位オブジェクトが特定の年・月に現れる各日付におけるスケジュールなどを表示するものがある。

前述のような場合において、上位オブジェクトが固定サイズで、更に下位オブジェクトの数が多くなると、各下位オブジェクトを縮小して表示するため、その中に記載されている情報の可読性が低くなる。あるいは、下位オブジェクトのうち選択された下位オブジェクトのみを読みやすいように拡大する方法もあるが、その場合、選択されていない下位オブジェクトの情報の可読性は更に低くなり、カレンダーのようにスケジュールの前後関係もあわせて確認したい場合には問題があった。

特許文献１では、選択された下位オブジェクトの表示サイズを“少し拡大した場合”や“最大に拡大した場合”のように複数用意する、下位オブジェクトの表示サイズによって表示する情報量を変更する、文字サイズを変更する、などにより可読性をあげる技術を提供している。

ＷＯ２００９／００４６９２

しかしながら、特許文献１における情報表示装置にあっても、例としてあげたカレンダー（上位オブジェクト）の場合には、その日付（下位オブジェクト）の数が限定されているため可読性を維持することが可能であるが、ユーザが任意個の下位オブジェックとを設定可能である場合には、やはり可読性を維持することが困難な状況が生じる。また、近年の携帯端末のように、元来画面サイズが小さく、更にその中に表示されたアプリケーション内である場合に、下位オブジェクトの数によっては、十分な操作性も得られない状況も生じる。

本発明の目的は、上記問題に鑑み、複数配置したオブジェクトの長さが固定のサイズを超える場合であっても、十分な可読性、操作性を維持するための表示方法を提供することである。

本発明は、固定の長さの表示範囲内において複数配置されたオブジェクトを閲覧可能にする情報処理装置であって、複数のオブジェクトの配置の指示をユーザより受け付ける配置指示受付手段と、前記配置指示受付手段によって受け付けた指示に基づき配置された複数のオブジェクトの長さが固定のサイズを超えるか否かを判定するサイズ判定手段と、ユーザから前記配置指示受付手段によって受け付けた指示に基づき配置された複数のオブジェクトより、いずれかのオブジェクトの選択を受け付ける選択受付手段と、前記選択受付手段で受け付けた前記オブジェクトではないオブジェクトのサイズの縮小方法を縮小パターンとして記憶する縮小パターン記憶手段と、前記サイズ判定手段により、前記配置された複数のオブジェクトの長さが前記固定のサイズを超えると判定した場合に、前記選択受付手段で受け付けた前記オブジェクトではないオブジェクトを前記縮小パターンに応じて縮小して前記配置された複数のオブジェクトを表示する表示制御手段と、を備えることを特徴とする。

本発明により、複数配置したオブジェクトの長さが固定の表示サイズを超える場合であっても、十分な可読性、操作性を維持するための表示方法が提供可能となる。

本発明の実施形態に係わるシステム構成の一例を示す図である。本発明の実施形態に係わるワークフローサーバ、クライアント装置、開発装置のハードウェア構成の一例を示すブロック図である。本発明の実施形態に係わるワークフローシステムにおけるソフトウェア構成の一例を示すブロック図である。開発者がワークフローを開発する処理の一例を示すフローチャートである。ワークフローを開発する際に定義する定義体の関連図の一例である。ワークフローの起票時のメニューと、処理待ち案件一覧を開発する際に定義する定義体の関連図の一例である。ワークフロー定義を格納するデータベース構成の一例である。ユーザがワークフローの申請時に利用する画面の一例である。ユーザがワークフローの確認時に利用し、アクティビティの追加／更新の操作をする画面の一例である。ユーザがワークフローの確認時に利用し、アクティビティの削除の操作をする画面の一例である。ワークフロー実行履記憶とアクティビティ情報記憶部のデータベース構成の一例である。ワークフローの実行処理の一例を示すフローチャートである。ワークフローの実行処理においてアクティビティの追加／更新をする処理の一例を示すフローチャートである。本発明の実施形態に係わる、経路情報オブジェクトとアクティビティが表示される状態を示す一例である。本発明の実施形態に係わる、経路情報オブジェクトとアクティビティが表示される状態を示す一例である。経路情報オブジェクトにアクティビティを表示する際の表示制御処理の一例を示すフローチャートである。本発明の実施形態に係わる、経路情報オブジェクトとアクティビティが表示される状態を示す一例である。

以下、本発明の実施の形態を、図面を参照して詳細に説明する。まず、本発明を実施するための一例として、ワークフローシステムの開発、およびエンドユーザによる簡単なアクティビティの追加について説明する。後述の説明の中で、上位オブジェクト（または親オブジェクト）はワークフローの経路情報を表示するための“経路情報オブジェクト”であり、下位オブジェクト（または子オブジェクト）は前記経路情報の中の各業務を表す“アクティビティ”であるとする。

図１は、本発明の実施形態に係わるシステム構成の一例を示す図である。

図１において、ワークフローシステムは、少なくとも１つのクライアント装置１０１（情報処理装置）とワークフローサーバ１０２がネットワーク１０４を介して接続されている。更に開発装置１０３もシステム構成に含まれ、ネットワーク１０４を介してクライアント装置１０１とワークフローサーバ１０２に接続されていてもよい。

ユーザは、例えばウェブブラウザやクライアントソフトウェアなどを利用して、クライアント装置１０１から、ワークフローサーバ１０２に対して、ワークフロー進行の要求などを行う。

ワークフローサーバ１０２は、要求に応じた処理、管理をおこない、必要があればクライアント装置１０１に対して結果などを送信する。

開発者は、例えばウェブブラウザやクライアントソフトウェアなどを利用して、開発装置１０３から、ワークフローの定義などを行う。その際、開発操作は開発装置１０３のみで処理可能であり最終的な定義結果をワークフローサーバ１０２に格納してもよい。あるいは開発装置１０３とワークフローサーバ１０２が協調して開発のための動作をし、また定義結果を随時、ワークフローサーバ１０２に格納するような構成であってもよい。

ワークフローサーバ１０２、クライアント装置１０１、開発装置１０３の間の通信は、通常のＨＴＴＰのリクエストでもよいし、ＳＯＡＰなどを利用したウェブサービスのリクエストでもよい。

クライアント装置１０１ａ、ワークフローサーバ１０２ａ、開発装置１０３ａは、それぞれＬＡＮにおいて接続されてもよい。また、クライアント装置１０１ｂ、ワークフローサーバ１０２ｂ、開発装置１０３ｂは、それぞれインターネット上、クラウド上において構成されてもよい。前述の構成が混在するものであってもよい。

図２は、本発明の実施形態に係わるワークフローサーバ、クライアント装置、開発装置のハードウェア構成の一例を示すブロック図である。

図２に示すように、ワークフローサーバ１０２、クライアント装置１０１は、システムバス２０４を介してＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）２０１、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）２０２、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）２０３、入力コントローラ２０５、ビデオコントローラ２０６、メモリコントローラ２０７、通信Ｉ／Ｆコントローラ２０８等が接続された構成を採る。ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（ＢａｓｉｃＩｎｐｕｔ／ＯｕｔｐｕｔＳｙｓｔｅｍ）やＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）や、各サーバあるいは各ＰＣが実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。また、本発明を実施するために必要な情報が記憶されている。なお外部メモリはデータベースであってもよい。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２１１からＲＡＭ２０２にロードし、ロードしたプログラムを実行することで各種動作を実現する。

また、入力コントローラ２０５は、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。

ビデオコントローラ２０６は、ディスプレイ２１０等の表示器への表示を制御する。尚、表示器は液晶ディスプレイ等の表示器でもよい。これらは、必要に応じて管理者が使用する。

メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、あるいは、ＰＣＭＣＩＡ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒＭｅｍｏｒｙＣａｒｄＩｎｔｅｒｎａｔｉｏｎａｌＡｓｓｏｃｉａｔｉｏｎ）カードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ２０８は、ネットワーク１０４を介して外部機器と接続・通信し、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ／ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）を用いた通信等が可能である。

尚、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上に表示することが可能である。また、ＣＰＵ２０１は、ディスプレイ２１０上のマウスカーソル（図示しない）等によるユーザ指示を可能とする。

本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイルおよび各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明についても後述する。

図３は、本発明の実施形態に係わるワークフローシステムにおけるソフトウェア構成の一例を示すブロック図である。

ワークフローシステムのユーザが、クライアント装置１０１においてワークフローシステムのクライアント画面を起動した後、ユーザの指示により処理待ち案件一覧要求送信部３０１により、処理待ち案件の一覧をワークフローサーバ１０２に要求する。処理待ち案件の一覧とは、承認者が、申請者から何らかの申請がされているか確認する場合や、あるいは申請者が、何らかの申請に対して承認者により否認されているか確認する場合の、案件がリストアップされているものである。

処理待ち案件一覧要求受信部３１２は、処理待ち案件一覧要求送信部３０１から送信された処理待ち案件一覧の要求を受信し、処理待ち案件一覧画面データ生成部３１３に画面データの生成を指示する。

処理待ち案件一覧画面データ生成部３１３は、アクティビティ情報記憶部３２２とワークフロー実行記憶部３２３から、前記ユーザが処理すべき処理待ちのアクティビティ情報とワークフローの実行中の情報を取得し、これらの情報に基づき処理待ち案件一覧の画面データを生成する。また、生成された画面データの各処理待ち案件には、その処理待ち案件がユーザにより選択された場合に、いずれの画面データを表示すべきかを示す画面ＩＤまたはそれらを導出するためのデータが含まれている。

生成された処理待ち案件一覧画面データは、処理待ち案件一覧画面データ送信部３１４により、ワークフローサーバ１０２から、クライアント装置１０１送信される。

処理待ち案件一覧画面データ受信部３０２は、ワークフローサーバ１０２から送信された処理待ち案件一覧画面データを受信し、処理待ち案件一覧画面データ表示制御部３０３に渡し、クライアント装置１０１に表示させる。

ここで、ユーザが新たに電子帳票の起票を使用とする場合には、複数ある申請内容からいずれの申請（交通費申請、出張申請など）をするか選択するための申請内容の一覧が表示される。表示画面に一覧として表示されてもよいし、メニューなどに列挙されてもよい。

処理対象選択部３０４は、処理待ち案件一覧からユーザが選択した処理対象、または前記申請内容の一覧（メニューでもよい）からユーザが選択した申請内容を受け付け、処理対象送信部３０５に渡される。

処理対象送信部３０５は、前記選択された処理対象をワークフローサーバ１０２に送信し、処理対象受信部３１５が受信する。受信した処理対象は、画面データ生成部３１６に渡される。

画面データ生成部３１６は、処理対象が、申請内容の一覧（またはメニュー）から選択された申請内容である場合には、各申請内容に画面ＩＤまたそれらを導出するためのデータ（画面ＩＤ等情報）が含まれており、その画面ＩＤ等情報に対応するレイアウトに基づき、必要な情報を設定するなどして画面データを生成する。

また、処理対象が、処理待ち案件である場合には、前述の通り、処理待ち案件一覧の処理待ち案件毎に、対応する画面ＩＤまたそれらを導出するためのデータ（画面ＩＤ等情報）が含まれている。その画面ＩＤ等情報に対応するレイアウトに基づき、処理待ち案件（案件ＩＤなどで特定されている）に対応する必要な情報を設定するなどして画面データを生成する。

画面を生成するに当たり、アクティビティ情報記憶部３２２やワークフロー実行記憶部３２３、更に業務データベースを参照することは可能であるが、それは各画面ＩＤに対応する画面生成ロジックとして処理が定義されている。

画面データ受信部３０６は、ワークフローサーバ１０２から送信された画面データを受信し、表示制御部３０７に渡し、クライアント装置１０１に表示させる。

クライアント装置１０１において、経路編集受付部３０８は、ユーザが経路編集をする操作を受け付ける。ユーザが指定した操作が、アクティビティの追加、削除、または更新かに応じて処理し、フローウィジェット上のアクティビティのデータを変更する。変更結果は、表示制御部３０７に渡され、表示画面に反映される。

また電子帳票に対してユーザの入力などが完了し、申請、承認などの処理が行われると（例えば申請ボタン、承認ボタンが押下されると）、帳票情報送信部３０９が、入力結果等を帳票情報としてワークフローサーバ１０２に送信する。ワークフローサーバ１０２においては、帳票情報受信部３１８が、帳票情報を受信する。受信した帳票情報から、処理されたアクティビティでの入力情報などの情報を取得し、ユーザが行った処理に応じて各アクティビティのステータスを変更し、アクティビティ情報登録部３１９によりアクティビティ情報記憶部３２２及びワークフロー実行記憶部３２３に登録する。

クライアント装置１０１において、保存指示部３１０は、ユーザが利用しているワークフロー定義に対して、経路編集をした結果を後に再利用するため、ワークフローサーバ１０２に格納する指示を受け付け、ワークフロー定義送信部３１１に渡す。

ワークフロー定義送信部３１１は、経路編集されたワークフロー定義を、ワークフローサーバ１０２に送信する。ワークフローサーバ１０２においては、ワークフロー定義受信部３２０が、ワークフロー定義を受信する。受信したワークフロー定義は、ワークフロー定義登録部３２１により、ワークフロー定義記憶部３２４に登録される。

なお、３０１〜３２１のそれぞれの機能部が、図３の通り、クライアント装置１０１とワークフローサーバ１０２において構成されるのは一例であり、その他の構成であってもよい。例えば経路編集受付部３０８で受け付けた編集内容は、ワークフローサーバ１０２に送信され、ワークフローサーバ１０２において画面データが再生成され、その結果をクライアント装置１０１に送り返し、表示制御部３０７で表示を編集してもよい。本構成は、あくまで一例である。

また、図３には示していないが、処理済み（あるいはこれから処理待ちになる予定）の案件に対して、案件の処理状況を追跡できるために、ユーザが自己に関連している案件の一覧を表示する画面、その案件の内容を確認できる画面の画面データ取得要求、表示制御があってもよい。

次に、図４から図７を用いて、ワークフローシステムが開発者に開発装置１０３を操作させ、ワークフローの各種定義体を作成する処理（以降、簡単に「開発者に定義させる」という場合がある）を説明する。

図４は、開発者がワークフローを開発する処理の一例を示すフローチャートである。図４のフローチャートの各ステップは、開発装置１０３上のＣＰＵ２０１で実行される。各ステップは、開発者による操作を受け付けて必要な定義体を構成していく。図４のフローチャートでは、ワークフローの定義結果は最後にまとめてワークフローサーバ１０２に格納するものとしている。実際には、フローチャートの処理においては、必要に応じてワークフローサーバ１０２と通信を行い、定義したワークフローの定義体をワークフローサーバ１０２の記憶部に随時格納するように実装してもよい。

ステップＳ４０１からＳ４１２においては、作成しようとするワークフローの定義に現れる１つのアクティビティに対応する各種定義体の定義を行う。すなわち、ワークフローの定義に現れるアクティビティの数だけ、ステップＳ４０１からＳ４１２が繰り返される。ただし、実際には複数のアクティビティで再利用可能なアクティビティもあり、必ずしも全てのステップでの定義体を開発者に作成させる必要はない。

ステップＳ４０１においては、アクティビティにおいてユーザが使用する画面のレイアウトを開発者に作成させる。具体的には、画面のベースとなるコンテナを新規に生成し、例えばアクティビティの名称を表示するためのテキストオブジェクト、ユーザに必要な情報を入力させるためのテキストボックスオブジェクト、申請や承認、確認を行い、次のアクティビティに進むときに押下するボタンオブジェクトなどを開発者に配置させる。これらの画面が、ユーザがワークフローを利用する際の帳票画面となる。１つのレイアウトの例を図５により簡単に説明する。

なお、以降「押下」とは、マウスによって対象となるオブジェクトをクリックすること、キーボード操作で対象となるオブジェクトにフォーカスさせエンターキーを押すなど、何らかの操作で対象となるオブジェクトを選択することを含む。

図５は、ワークフローを開発する際に定義する定義体の関連図の一例である。図５では、１つのアクティビティで必要な定義体の例を示すものであるが、前述の通り下記で説明する各定義体は、他のアクティビティを定義する際に再利用可能なものもあるため、必ずしも全てを定義する必要はない。あくまで一例である。

図５の５０１は開発画面のベースとなるコンテナ、５０２はワークフロー「回覧板」を定義する際の最初の「回覧板（申請）」の画面を定義する例である。レイアウト上には、このアクティビティ名と、申請ボタン５０５、その他の入力項目レイアウトを開発者に定義させる。なお、アクティビティ名には、「回覧板（申請）」と定義されているが、この文字列は固定で定義してもよいし、後述するアクションで画面表示をする際に動的に定義するようにしてもよい。

ステップＳ４０２においては、前述の画面レイアウト上にワークフローにおける経路（アクティビティの並び）を配置するための経路情報オブジェクトを、開発者に配置させる。図５においては、経路情報オブジェクト５０４が開発者によって配置された例を示している。

ステップＳ４０３においては、前述において作成したアクティビティに対応する画面が表示される際に実行されるアクションを、開発者に定義される。図５においては、５０３において例が示されている。５０３において、「回覧板（申請）」画面に対応するアクションとして、「ログインユーザ名を取得しアクティビティの画面内に表示する」、「経路情報をワークフロー定義Ｂ（後述）からアクティビティ情報を読み込み、経路情報オブジェクト５０４に設定する」などの処理を記載する。また、外部データベース（業務関係ＤＢ、人事関係ＤＢ）などと連携した処理を記載してもよい。例えば、経路情報オブジェクト５０４における申請者以外の承認者などを、人事データベースにおける上司を設定する処理を定義してもよい。本例（「回覧板」）では、申請者の上司である「課長」「部長」を自動的に設定するようアクションを定義したとする。

ステップＳ４０４においては、申請／確認／承認など、ワークフローを次のアクティビティに進めるために押下するボタンに対応するアクションを、開発者に定義させる。図５においては、申請ボタン５０５に対応するアクション（５０７）を定義させる。例えば、「クライアント装置１０１の帳票画面でユーザが入力した内容のエラーチェックを行う」、「ワークフローが初期に申請されたものであればフローＩＤを付与する」、「入力結果などをアクティビティ情報記憶部（後述）などに登録する」などの処理である。

ステップＳ４０５においては、経路情報オブジェクト５０４が押下された場合のアクションを開発者に定義させる。図５の５０８が対応するアクションの例である。まず、アクティビティが１つ（例えば「申請」）だけであれば、「申請」アクティビティの後に他のアクティビティを追加するための「追加確認ダイアログ」を表示させる処理を定義させる。また、それ以外の場合であれば「追加／削除／更新確認ダイアログ」を表示させる処理を定義させる。

ステップＳ４０６においては、「追加確認ダイアログ」（図５の５０９）のレイアウトを開発者に定義させる。このダイアログでは、経路情報オブジェクト５０４上で選択されたアクティビティ（実行中のアクティビティとは異なってもよい）の後ろに新たなアクティビティを追加することをユーザに確認させるための画面である。

ステップＳ４０７においては、「追加／削除／更新確認ダイアログ」（図５の５１０）のレイアウトを開発者に定義させる。このダイアログでは、経路情報オブジェクト５０４上で選択されたアクティビティ（実行中のアクティビティとは異なってもよい）の後ろに新たなアクティビティを追加する、または選択されたアクティビティを削除／更新することをユーザに確認させるための画面である。

ステップＳ４０８においては、ステップＳ４０６、Ｓ４０７において定義したダイアログ（図５の５０９、５１０）の追加ボタン５１１、削除ボタン５１３、更新ボタン５１４が押下された際のアクション（図５の５１５）を、開発者に定義させる。本例では１つのアクションとしているが、追加、削除、更新のそれぞれに分かれていてもよい。このアクションには、追加ボタン５１１が押下された場合には追加ダイアログ５１６を表示、削除ボタン５１３が押下された場合には経路情報オブジェクト５０４から選択されたオブジェクトを削除、更新ボタン５１４が押下された場合には更新ダイアログ５２２を表示するための処理を開発者に定義させる。

ステップＳ４０９においては、アクティビティの追加処理をユーザにさせるための追加ダイアログ（５１６）のレイアウトを開発者に定義させる。

ステップＳ４１０においては、追加ダイアログ（５１６）のＯＫボタン（５２０）押下時に、ユーザが設定した値を、経路情報オブジェクト５０４に反映させるための処理などをアクションとして開発者に定義させる。例えば、「経路情報オブジェクトにアクティビティを追加する」、「アクティビティ名を追加したアクティビティに設定する」、「処理するユーザのユーザ名を設定する」などである。また、図５の追加ダイアログ（５１６）では、追加するアクティビティに対応する画面を指定する方法はないが、複数の画面をリストボックスなどで指定できるようにし、ステップＳ４１０においては、ユーザが指定した画面との対応付けをアクティビティに設定するようにしてもよい。

ステップＳ４１１においては、アクティビティの更新処理をユーザにさせるための更新ダイアログ（５２２）のレイアウトを開発者に定義させる。

ステップＳ４１２においては、更新ダイアログ（５２２）のＯＫボタン（５２４）押下時に、ユーザが設定した値を、経路情報オブジェクト５０４に反映させるための処理などをアクションとして開発者に定義させる。例えば、「選択したアクティビティの名称を更新する」、「処理するユーザのユーザ名を更新する」などである。

ステップＳ４１３においては、開発者にアクティビティ及び関連する定義体を更に定義するか確認する。更に定義する場合（ＹＥＳの場合）、ステップＳ４０１に進む。定義を完了する場合（ＮＯの場合）、ステップＳ４１４に進む。

なお、後述するワークフローとしては、「回覧板」ワークフローとして、「回覧申請」、「課長確認」、「部長確認」の３つのアクティビティを標準で定義されたものを例として利用する。ただし、「課長確認」と「部長確認」については、アクティビティ名とユーザ名が異なる（表示する際にアクションにより異なる表示をする）だけであり、定義体は同一のものを呼び出すものとする。また、追加ダイアログ（５１６）により追加されるアクティビティも「課長確認」、「部長確認」と同一の定義体に関連付けられるものとする。

すなわち、例として「回覧板」ワークフローの実体は、最初のアクティビティに「回覧申請」、それ以降のアクティビティ（追加するアクティビティも含め）として「確認」の２種類の定義体で構成されるワークフローとなる。

また、ステップＳ４０５〜ステップＳ４１２で定義される画面レイアウトの５０９、５１０、５１６、５２２、及びアクションの５０８、５１５、５１７、５２３の全て、または一部は、経路情報オブジェクト５０４に関連する定義体として、あらかじめ標準で定義されていてもよい。

以上のステップでワークフローの定義体の定義に関する処理の説明を完了する。続くステップにより、これらの定義体が呼び出される処理を、開発者に定義させる。

ステップＳ４１４においては、開発者に初期画面の呼出を定義させる。すなわち上記のフローチャートの例では、経路情報として最初の定義体である「回覧板（申請）」に対応する画面をメニュー（図５の５０６）に登録させる。より詳細には図６を用いて説明する。

図６は、ワークフローの起票示のメニューと、処理待ち案件一覧を開発する際に定義する定義体の関連図の一連である。図５のメニュー５０６と図６のメニュー５０６は同一のものである。メニュー５０６には、例えば既に３つの項目（「交通費申請」など）が登録されている。ステップＳ４１４では、開発者に、前述のステップまでにおいて定義した「回覧板」ワークフローをユーザが実行できるようにメニュー５０６に「回覧板」を登録させる（実際には６０１のように文字列として「回覧板」を対応付ける）。

ステップＳ４１５においては、６０１から登録した項目が選択された場合の処理を、開発者にアクションとして定義させる。前述の「回覧板」の例では、「回覧板（申請）」の画面を表示させるアクションを定義させる（６０２）。

ステップＳ４１６において、処理待ち案件一覧画面（６０３）を表示する際のアクション（６０４）を開発者に定義させる。具体的には、例として、ログインユーザを取得し、後述するアクティビティ情報記憶部３２２から、当該ログインユーザが処理すべき処理待ちアクティビティ情報を処理待ち案件一覧の画面レイアウトに埋め込む処理を定義させる。詳細な情報としては、前記処理待ち案件であるワークフロー名（例えば「回覧板」など）、アクティビティ名（「課長確認」など）を起動時に表示させる処理を定義させる。その他、次のステップで定義させるアクションで使用する情報は、処理待ち案件一覧画面（６０３）にあらかじめ埋め込むよう定義させる。さらに各表示項目とその表示項目が選択された場合のアクション（６０５）を定義させる。すなわち、処理待ち案件として表示された情報や、そのステータス（申請が初めてか、却下された後の再申請か、など）などにより、表示する画面が異なる可能性があるため、選択された処理待ち案件に応じて、画面（画面ＩＤ）を特定し、当該画面の呼出表示処理をアクションとして定義させる。

また、処理待ち一覧画面自体が定義されていない場合（最初のワークフローを定義する際）には、処理待ち案件一覧の画面レイアウト自体を開発者に定義させるステップも必要である（不図示）。

以上のように、処理待ち案件一覧画面（６０３）から、ユーザが処理待ち案件を選択したときに、ワークフローシステムにおいて実行される処理は、６０４、６０５に記載されている。特に、６０４には、開発者により、次に遷移する画面条件と、その画面（画面ＩＤ）が対応付けられて実装されている。あるいは、画面ＩＤが直接埋め込まれていなくとも、ワークフロー定義の種類とアクティビティの種類の２次元データ構成のテーブルに画面ＩＤを登録しておき、例外的な画面遷移以外は、そのテーブルを参照するなど、様々な方式が考えられる。いずれにしても、６０４のアクションに従って処理待ち案件一覧画面が生成される。

すなわち、後述するユーザの利用時において、経路情報オブジェクト５０４にアクティビティを追加、更新、削除しても、６０４のアクションで次の画面ＩＤがされ、画面自体は、画面ＩＤ（例えば５０１）と画面データを生成するためのアクション（例えば５０３）で処理が定義されている。

この構成により、ユーザは、経路情報の前後関係におけるアクティビティの整合性を意識することなく、容易にアクティビティの追加、更新、削除を行うことができるという効果が得られる。

ステップＳ４１７においては、前述のステップで作成したワークフローの定義体、メニューや処理待ち案件一覧に関連する定義の内容を、開発装置１０３からワークフローサーバ１０２に送信し、格納するよう要求する。

ワークフローサーバ１０２においては、この要求に従って、各種定義をワークフロー定義記憶部３２４および関連する画面レイアウト記憶部（不図示）、アクション記憶部（不図示）に記憶する。

次に、ステップＳ４１７でワークフローサーバ１０２に格納要求した定義体のうち、ワークフローサーバ１０２のワークフロー定義記憶部３２４に記憶するワークフロー定義について図７を用いて説明する。

図７は、ワークフロー定義を格納するデータベース構成の一例である。例として、前述のワークフローとして「回覧板」、その経路情報には３つのアクティビティ「回覧申請」、「課長確認」、「部長確認」が定義されている。

ワークフロー定義Ａ７００は、ワークフローの案件自体の情報（ワークフローの情報）を格納するテーブルの一例である。ワークフローが起票される際に、後述するワークフロー実行記憶部を構成するための定義であり、定義時点ではヘッダ（データ項目）のみ定義されており、中にデータが格納されていなくともよい。また、説明する画面の例として後述の図８、図１０が対応する。

ｉｓｓｅ＿ｉｄ７０１は、ワークフローの起票時にユーザが、またはシステムが自動的に付与する発行ＩＤに対応する項目である。本例では、検索キーとして任意に付与する。

ｔｉｔｌｅ７０２は、起票したワークフローの件名をユーザが入力するテキストボックスに対応する項目である。

ｂｏｄｙ７０３は、「回覧申請」に係る内容をユーザが入力する本文のテキストボックスに対応する項目である。

ｃｏｍｍｅｎｔ７０４は、「回覧」の内容の確認者が、確認事項などを自由に記載するコメントに対応する項目である。図８では表示されないが、図１０で表示されている。図８と図１０の違いは、異なるアクティビティにおいて、異なる画面レイアウトを定義するか、または同一の画面レイアウトではあるが、画面を表示する際のアクションにより、コメントの項目を表示するか否かを制御することにより実現する。

ｆｌｏｗ＿ｉｄ７０５は、ワークフローを特定するためのキーとなるＩＤであり、一意的に付与される。ワークフロー定義記憶部のテーブル構成が、ワークフロー定義毎に分かれている場合には、同一のテーブル構成の中で一意的であればよい。ワークフロー実行結果のデータとして、後述するワークフロー定義Ｂ７１０（アクティビティの定義を格納）と対応付けるために用いる（図１１参照）。

ワークフロー定義Ｂ７１０は、アクティビティの定義を格納するデータ構成の一例であり、前述の通りｆｌｏｗ＿ｉｄ（７０５、７１１）によりワークフロー定義Ａ７００のデータ構成と対応付けられている。

ａｃｔ＿ｉｄ７１２は、アクティビティを特定するための一意的なＩＤである。本例では、定義した順に１から番号を付与している。

ａｃｔ＿ｎａｍｅ７１３は、アクティビティ名である。例えば図８〜図１０の経路情報オブジェクト５０４（ａ〜ｇ）に表示される。

ａｃｔ＿ｎｏ７１４は、アクティビティの実行順序である。従って、実行時にアクティビティが追加、削除された場合には、定義順にかかわらず、実際に実行されるべき順に１から番号を付与する。例えば図８〜図１０の経路情報オブジェクト５０４に表示されるアクティビティの順番に一致する。

ｕｓｅｒ＿ｉｄ７１５は、実行予定または実行結果としてのユーザＩＤである。

ｕｓｅｒ＿ｎａｍｅ７１６は、実行予定または実行結果としてのユーザ名である。

ｓｔａｔｅ７１７は、アクティビティの状態である。例えば、「ｔｏｄｏ」は、対応するｕｓｅｒ＿ｉｄ７１５（またはｕｓｅｒ＿ｎａｍｅ７１６）のユーザにとって、該当するアクティビティが処理待ち状態であることを示す。ただし、最初のアクティビティのみは、起票前には「ｔｏｄｏ」とする。「ｄｏｎｅ」は、該当するアクティビティが既に処理済みであることを示す。「ｗａｉｔ」は、未処理であり、対応するユーザにとってまだ処理待ちにもなっていない状態である。

ｅｘｅｃｕｔｉｏｎ＿ｄａｔｅ７１８は、該当するアクティビティの処理が完了した日時である。

ｆｌｏｗ＿ｓｔａｔｅ７１９は、ワークフローの実行状態である。ワークフロー定義体においては、「ｉｎｉｔｉａｌ」が格納される。またワークフローの実行中は、「ａｃｔｉｖｅ」、全てのアクティビティが処理され完了状態となった場合には「ｃｏｍｐｌｅｔｅ」が格納される。

これにより図４〜図７の説明を完了する。すなわち、図４のフローチャートによるワークフローシステムが開発者に開発装置１０３を操作させ、ワークフローの各種定義体を作成する処理の説明を完了する。

次に図８から図１１を用いて、ユーザがクライアント装置１０１において、ワークフロー（例として「回覧板」）を申請、確認する操作と、実行時のデータを管理する記憶部のデータの状態を説明する。

図８は、ユーザがワークフローの申請時に利用する画面の一例である。ユーザとして「鈴木一郎」がログインして操作している（８０３）。申請はメニュー５０６を押下し、さらに６０１のワークフローの一覧からいずれかを選択することで開始する。例では「回覧板」（８０２）を選択したとして説明する。

「回覧板」を選択すると８０４の画面が表示される（ただし各テキストボックスは未入力の状態である）。起票時における画面表示のアクション（図５の５０３）定義により、最初のアクティビティ名「回覧申請」が表示される（８０５）。また、同アクションによりワークフロー定義Ｂ７１０（図７）から３つのアクティビティ名を読み込んで、ａｃｔ＿ｎｏ７１４で指定された順番に経路情報オブジェクト５０４ａに表示する。「回覧申請」のユーザ名はログインユーザ名、「課長確認」、「部長確認」のユーザ名は、前述の通り人事データベースなどから組織情報を取得して、「鈴木一郎」の上司の氏名を当てはめた結果である。現在処理しているアクティビティは協調などにより分かりやすく表示することが可能である。

さらに表示後に、ユーザが、発行ＩＤ８０６に「１０１−００３」、件名８０７に「資料回覧」、本文８０８に「ご覧ください。」と入力した結果であるが８０４の状態である。入力が終わった後、ユーザによる申請ボタン５０５の押下により、申請処理は終了し、ワークフローは次のアクティビティに進む。この時点で、処理結果がワークフローサーバ１０２に登録されるので、図１１を用いて説明する。

図１１は、ワークフロー実行記憶部とアクティビティ情報記憶部のデータベース構成の一例である。各期億部の構成については、ワークフロー実行記憶部３２３はワークフロー定義Ａ７００（図７）と同一、またアクティビティ情報記憶部３２２はワークフロー定義Ｂ７１０と同一であるため、詳細のデータ項目の説明は省略する。

ワークフロー実行記憶部３２３ａには、アクティビティ「回覧申請」において入力した、発行ＩＤ８０６の「１０１−００３」はｉｓｓｕｅ＿ｉｄに、件名８０７の「資料回覧」はｔｉｔｌｅに、本文８０８の「ご覧ください。」はｂｏｄｙに登録される。ｃｏｍｍｅｎｔは、アクティビティ「回覧申請」では入力用のテキストボックスが表示されないため、何も格納されない。またｆｌｏｗ＿ｉｄには自動的に「１８６」が付与され、格納される。

また、アクティビティ情報記憶部３２２ａに登録されるアクティビティの情報について説明する。アクティビティ「回覧申請」において、経路情報オブジェクト５０４上のアクティビティが編集されていないため、アクティビティの構成は同一である。そこで図７のワークフロー定義Ｂ７１０と違いがあるデータ項目のみ説明する。

ｆｌｏｗ＿ｉｄには、ワークフロー実行記憶部３２３ａのｆｌｏｗ＿ｉｄと同一の値が格納される。

ｕｓｅｒ＿ｉｄ、ｕｓｅｒ＿ｎａｍｅについては、アクティビティ「回覧申請」の画面が表示された時点でアクションにより決定されているので、その値が各アクティビティに格納される。

ｓｔａｔｅについては、アクティビティ「回覧申請」の処理が完了しているため、「回覧申請」に対しては「ｄｏｎｅ」へ変更された上で格納される。一方、アクティビティ「課長申請」が処理待ちの状態に変わるので「ｔｏｄｏ」へ変更された上で格納される。

ｅｘｅｃｕｔｉｏｎ＿ｄａｔｅについては、処理が完了したアクティビティ「回覧申請」についてのみ、実際に処理した日時が格納される。

ｆｌｏｗ＿ｓｔａｔｅについては、ワークフロー処理が実行中であるため、３つのアクティビティに対して全て「ａｃｔｉｖｅ」が格納される。

以上で、アクティビティ「回覧申請」の処理の結果を完了した時点のデータベースの状態について説明を完了する。

次にアクティビティ「課長確認」について、図９を用いて説明する。アクティビティ「回覧申請」の処理が完了した段階で、ユーザ「山田二郎」に対して、発行ＩＤ「１０１−００３」のワークフローのアクティビティ「課長確認」が処理待ち案件となる。

図９は、ユーザがワークフローの確認時に利用し、アクティビティの追加／更新の操作をする画面の一例である。まず、「山田二郎」がワークフローの「処理待ち案件一覧」を確認するための画面（９０１）を表示する。

処理待ち案件一覧の画面（９０１）には、「鈴木一郎」が申請した「資料回覧」の処理待ち案件が１つ表示されている。この画面は、処理待ち案件一覧のレイアウト（６０３）上に、アクション（６０４）に基づいて例えばアクティビティ情報記憶部３２２（図１１の３２２ａ）、ワークフロー実行記憶部３２３（図１１の３２３ａ）からログインユーザである「山田二郎」が処理すべき情報を検索して生成する。前記処理すべき情報とは、具体的には、ｕｓｅｒ＿ｉｄ７１５、ｓｔａｔｅ７１７などにより検索される。

処理待ち案件一覧の画面（９０１）の発行ＩＤ「１０１−００３」の行（処理待ち案件）を押下すると、対応付けられた、回覧板のアクティビティ「課長確認」の画面を表示する（９０３）。この画面は、不図示の「課長確認」画面のレイアウトと、当該画面の表示時に呼び出されるアクションにより生成される。

経路情報オブジェクト５０４ｂでは、現在処理中のアクティビティ「課長確認」が強調表示されている。また、ユーザ「山田二郎」は、コメント９０５「読みました。」を入力したとする。

ここで、経路情報オブジェクト５０４ｂにアクティビティを追加する例を説明する。２つめのアクティビティ「課長確認」の直後に、他の課長に回覧したいとする。この時、アクティビティ「課長確認」をフォーカスして押下すると、追加／削除／更新確認のダイアログ（５１０）が表示される。ここで追加ボタン（５１１）を押下すると、追加内容を入力するダイアログ（５１６）が表示される。追加ダイアログ（５１６）で、アクティビティ名（５１８）に「課長確認２」、ユーザ名（（５１９）に「清水四郎」を入力し、ＯＫボタン（５２０）を押下すると、経路情報オブジェクト５０４ｃの通りになる。すなわち、フォーカスしていたアクティビティ「課長確認」の次に、新しいアクティビティ「課長確認２」が追加された。

同様にアクティビティ「課長確認２」をフォーカスして、アクティビティ名「課長確認３」、ユーザ名「斉藤五郎」のアクティビティを追加する。またアクティビティ「部長確認」（９０８）をフォーカスして、アクティビティ名「営業確認」、ユーザ名「営業太郎」のアクティビティを追加する。結果は、経路情報オブジェクト５０４ｄの通りになる。

以上の説明の通り、ユーザは、例えばワークフロー「回覧板」を使用しているときに、設計者（開発者）の定義の意図や、上司／部下などの経路の定義にとらわれることがない。すなわち資料の回覧をすべきと判断した他部門の管理職、あるいは図示していないが、他部門の一般社員であってもワークフローの経路情報に動的で柔軟な追加が可能であるという効果を得ることができる。

また図６でも述べたように、ユーザは、経路情報の前後関係におけるアクティビティの整合性を意識することなく、容易にアクティビティの追加を行うことができるという効果が得られる。

次に直前に追加したアクティビティを更新する例について説明する。アクティビティ「営業確認」をフォーカスして、追加／削除／更新確認のダイアログ（５１０）を表示させ、更新ボタン（５１４）を押下すると、図５の更新ダイアログ５２２が表示される。ここで、アクティビティ名「部長確認２」、ユーザ名「田中六郎」としてＯＫボタン（５２４）を押下すると、経路情報オブジェクト５０４ｅの通りになる（最後のアクティビティが９０９の通りになる）。

以上の説明の通り、ユーザは、例えば設計者（開発者）の定義の意図や、上司／部下などの経路の定義、あるいは他のユーザの経路情報の編集にとらわれることがなく、誤って作成、または異動などによりアクティビティは必要だが、ユーザ名を変更したいようなアクティビティについて、動的で柔軟な更新が可能であるという効果を得ることができる。

また図６でも述べたように、ユーザは、経路情報の前後関係におけるアクティビティの整合性を意識することなく、容易にアクティビティの更新を行うことができるという効果が得られる。

ユーザ（「山田二郎」課長）が、課長確認アクティビティの画面（９０３）で、「確認」ボタン（９０６）を押下すると確認処理は終了し、ワークフローは次のアクティビティに進む。この時点で、処理結果がワークフローサーバ１０２に登録されるので、再度図１１を用いて説明する。

アクティビティ「回覧申請」と「課長確認」の結果として登録された内容については説明済みなので、アクティビティ「回覧申請」と「課長確認」の結果として登録される内容の違いについて述べる。

ワークフロー実行記憶部３２３ｂには、図９の９０５で「山田二郎」が入力した「読みました。」が新たに登録されている。

アクティビティ情報記憶部３２２ａにおいては、もともと３つのみ登録されていたアクティビティが６つになっている。これは図９の経路情報オブジェクト５０４ｅに対応する順番に並んでいる。ただし、ａｃｔ＿ｉｄは定義された順（または登録された順）になるため、「課長確認２」が“４”、「課長確認３」が“５”、「部長確認２」が“６”となっている。

ａｃｔ＿ｎａｍｅには、新たに追加されたアクティビティも含め、そのアクティビティの名称が図９で定義されたとおりに登録されている。

ａｃｔ＿ｎｏは、アクティビティを実行する順番であるため、定義順であるａｃｔ＿ｉｄとは異なり、図９の経路情報オブジェクト５０４ｅに並んでいる順に番号付けられており、そのため、アクティビティ情報記憶部３２２ａとは番号が変わっているアクティビティもある。

ｕｓｅｒ＿ｉｄおよびｕｓｅｒ＿ｎａｍｅには、新たに追加されたアクティビティも含め、ユーザＩＤとユーザ名が、図９の経路情報オブジェクト５０４ｅに並んでいる通りに登録される。

ｓｔａｔｅは、「山田二郎」（アクティビティ名「課長確認」）においては、処理が完了したため「ｄｏｎｅ」となっている。一方、次のアクティビティ（新たに追加されたアクティビティ）である「清水四郎」（アクティビティ名「課長確認２」）が「ｔｏｄｏ」となり、処理待ち案件であることを示す。

また、「山田二郎」（アクティビティ名「課長確認」）のｅｘｅｃｕｔｉｏｎ＿ｄａｔｅに処理時刻が登録される。

以上により、図９のアクティビティを完了した時点でのデータベース内の状態について説明を完了する。

次にアクティビティ「部長確認」について、図１０を用いて説明する（「課長確認２」、「課長確認３」は完了したものと見なす）。アクティビティ「課長確認３」の処理が完了した段階で、ユーザ「佐藤三郎」に対して、発行ＩＤ「１０１−００３」のワークフローのアクティビティ「部長確認」が処理待ち案件となる。この時点で、アクティビティの情報については、アクティビティ情報記憶部３２２ｃの通りになっているとする。

図１０は、ユーザがワークフローの確認時に利用し、アクティビティの削除の操作をする画面の一例である。まず、「佐藤三郎」がワークフローの「処理待ち案件一覧」を確認するための画面（１００１）を表示する。

処理待ち案件一覧の画面（１００１）には、「鈴木一郎」が申請した「資料回覧」の処理待ち案件が１つ表示されている。この画面は、処理待ち案件一覧のレイアウト（６０３）上に、アクション（６０４）に基づいて例えばアクティビティ情報記憶部３２２（図１１の３２２ｂ）、ワークフロー実行記憶部３２３（図１１の３２３ｂ）からログインユーザである「佐藤三郎」が処理すべき情報を検索して生成する。

処理待ち案件一覧の画面（１００１）の発行ＩＤ「１０１−００３」の行（処理待ち案件）を押下すると、対応付けられた、回覧板のアクティビティ「部長確認」の画面を表示する（１００３）。この画面は、不図示の「部長確認」画面のレイアウトと、当該画面の表示時に呼び出されるアクションにより生成される。

経路情報オブジェクト５０４ｆでは、現在処理中のアクティビティ「部長確認」が強調表示されている。

ここで、経路情報オブジェクト５０４ｆ上のアクティビティを削除する例を説明する。最後のアクティビティ「部長確認２」（９０９）を削除したいとする。この時、アクティビティ「部長確認２」をフォーカスして押下すると、追加／削除／更新確認のダイアログ（５１０）が表示される。ここで削除ボタン（５１３）を押下すると、アクティビティ名「部長確認２」が削除された経路情報オブジェクト５０４ｇが表示される。

ユーザ（「佐藤三郎」部長）が、部長確認アクティビティの画面（１００３）で、「確認」ボタン（９０６）を押下すると確認処理は終了し、ワークフローは次のアクティビティに進む。この時点で、処理結果がワークフローサーバ１０２に登録されるので、再度図１１を用いて説明する。

アクティビティ情報記憶部３２２ｄにおいては、アクティビティ情報記憶部３２２ｃで６つ登録されていたアクティビティが５つになっている。これは図１０の経路情報オブジェクト５０４ｇに対応する（「田中六郎」（アクティビティ名「部長確認２」）が削除されている）。

以上の説明の通り、ユーザは、例えば設計者（開発者）の定義の意図や、上司／部下などの経路の定義、あるいは他のユーザの経路情報の編集にとらわれることがなく、（例えば「回覧」することが）不適切であると判断されたアクティビティについての動的で柔軟な削除が可能であるという効果を得ることができる。

また図６でも述べたように、ユーザは、経路情報の前後関係におけるアクティビティの整合性を意識することなく、容易にアクティビティの削除を行うことができるという効果が得られる。

全てのアクティビティの処理が完了したため、全てのｓｔａｔｅは「ｄｏｎｅ」、ｆｌｏｗ＿ｓｔａｔｅが「ｃｏｍｐｌｅｔｅ」となっている。

また「佐藤三郎」（アクティビティ名「部長確認」）のｅｘｅｃｕｔｉｏｎ＿ｄａｔｅに処理時刻が登録される。

以上により、図１０のアクティビティを完了した時点でのデータベース内の状態について説明を完了する。

これにより図８から図１１の説明を完了する。すなわち、ユーザがクライアント装置１０１において、ワークフロー（例として「回覧板」）を申請、確認する操作と、実行時のデータを管理する記憶部のデータの状態の説明を完了する。

次に図１２から図１３により、ワークフローシステムの動作について説明する。

図１２は、ワークフローの実行処理の一例を示すフローチャートである。図１２のフローチャートのステップＳ１２０１からＳ１２１０は、クライアント装置１０１上のＣＰＵ２０１で実行される。またステップＳ１２１１からＳ１２２０は、ワークフローサーバ１０２上のＣＰＵ２０１で実行される。

ステップＳ１２０１においては、ユーザからワークフローの処理対象の選択を受け付ける。ここで処理対象とは、申請時にメニューから選ばれる場合と、承認者／確認者などが処理待ち案件一覧から実行中且つログインユーザが処理すべき処理待ち案件を選択する場合がある。前者の場合、例えば図８のメニュー５０６からワークフローの一覧（６０１）が表示された場合には、ユーザが申請したい項目（例えば「回覧板」８０２）が選択され、ワークフロー「回覧板」の最初のアクティビティ「回覧申請」）を処理対象として受け付ける。一方、後者の場合、例えば図９の処理待ち案件一覧（９０１）から処理待ち案件（ワークフロー「回覧板」）のアクティビティ「課長確認」を処理対象として受け付ける。

ステップＳ１２０２においては、前記処理対象をユーザに操作させるために、ワークフローサーバ１０２に前述の処理対象を処理要求として送信する。

ステップＳ１２１１においては、クライアント装置１０１から送信された処理要求を受信する。

ステップＳ１２１２においては、処理要求に基づいて、画面データを生成する。具体的には、処理要求として、生成すべき画面の指定（画面レイアウトのＩＤ）が特定されており、当該画面レイアウトに対応するアクションにより、ワークフロー実行記憶部３２３、アクティビティ情報記憶部３２２の情報を利用して画面データを生成する。

ステップＳ１２１３においては、生成した画面データをクライアント装置１０１に送信する。

ステップＳ１２０３においては、ワークフローサーバ１０２から送信された画面データを受信する。

ステップＳ１２０４においては、画面データをクライアント装置１０１に接続された表示装置に表示し、ユーザからの電子帳票に対する入力処理、経路情報の編集処理、申請／承認／確認などのボタン押下による次のアクティビティへの進むための操作を受け付ける。電子帳票に対する入力処理についてはステップＳ１２０４の中で行われているものとして、以降の説明では省略する。

ステップＳ１２０５においては、操作内容による条件分岐を行う。具体的には、ユーザから受け付けた操作が、経路情報オブジェクト５０４において、アクティビティの編集を指示されたものである場合には、ステップＳ１２０６に進む。また、次のアクティビティへの進むための操作である場合には、ステップＳ１２１０に進む。

ステップＳ１２０６においては、経路情報オブジェクト５０４におけるユーザの操作内容による条件分岐を行う。具体的には、ユーザから受け付けた操作が、アクティビティの追加または更新の指示である場合には、ステップＳ１２０７に進む。アクティビティの削除の指示である場合には、ステップＳ１２０８に進む。

ステップＳ１２０７においては、アクティビティの追加／更新をするためのユーザ操作を受け付け、操作の結果を経路情報オブジェクト５０４に反映する。詳細については図１３において説明する。アクティビティの追加／更新の処理が完了したら、ステップＳ１２０４に進む。

ステップＳ１２０８においては、ユーザにより指定されたアクティビティを削除する。

ステップＳ１２０９においては、アクティビティが削除された結果を経路情報オブジェクト５０４に反映する。

ステップＳ１２１０においては、ユーザにより電子帳票に入力された内容、経路情報オブジェクト５０４などを、帳票情報としてワークフローサーバ１０２に送信する。

ステップＳ１２１４においては、クライアント装置１０１から送信された帳票情報を受信する。

ステップＳ１２１５においては、帳票情報に含まれる経路情報オブジェクト５０４の現アクティビティに対するｓｔａｔｅを「ｄｏｎｅ」に変更する。

ステップＳ１２１６においては、次アクティビティに対するｓｔａｔｅを「ｔｏｄｏ」とし、次アクティビティに対応するユーザにとっての「処理待ち案件」として指定する。

ステップＳ１２１７においては、処理中のワークフローにフローＩＤが付与されているか否かを判定する。ワークフローが起票された新しいものであれば、前述の帳票情報はクライアント装置１０１から初めて送信されてきたものであり、ワークフローサーバ１０２においてフローＩＤはまだ付与されていない場合があるからである。フローＩＤが付与されていなければ（“ＮＯ”の場合）には、ステップＳ１２１８に進む。フローＩＤが付与されていれば（“ＹＥＳ”の場合）には、ステップＳ１２２０に進む。

ステップＳ１２１８においては、帳票情報にフローＩＤを付与する。

ステップＳ１２１９においては、帳票情報を、ワークフロー実行記憶部３２３、アクティビティ情報記憶部３２２に新規に格納する。

ステップＳ１２２０においては、フローＩＤに基づき、ワークフロー実行記憶部３２３、アクティビティ情報記憶部３２２に既に格納されている情報と、前述の帳票情報を比較して、必要があれば書き換える。本願における「書き換える」とは、比較の結果としてアクティビティが編集されている場合（増減、更新、およびこれらの組み合わせ）の差分を反映すること、および既存の情報のうち、変更がある部分を書き換えることを含む。また、実際には差分のみ書き換えてもよいし、一度全て削除した上で、帳票情報を新たに格納し直す方法、その他いずれの方法であってもよい。これらいずれの方法であっても、本願における「書き換える」ものである。

以上で、図１２におけるフローチャートの処理の説明を完了する。次に、図１２のステップＳ１２０７に対応する処理の詳細を、図１３を用いて説明する。

図１３は、ワークフローの実行処理においてアクティビティの追加／更新をする処理の一例を示すフローチャートである。図１３のフローチャートのステップＳ１３０１からＳ１３０９は、クライアント装置１０１上のＣＰＵ２０１で実行される。またステップＳ１３１０からＳ１３１３は、ワークフローサーバ１０２上のＣＰＵ２０１で実行される。

ステップＳ１３０１においては、経路情報オブジェクト５０４におけるユーザの操作内容による条件分岐を行う。具体的には、ユーザから受け付けた操作が、アクティビティの追加である場合には、ステップＳ１３０２に進む。アクティビティの更新の指示である場合には、ステップＳ１３０３に進む。

ステップＳ１３０２においては、アクティビティを追加するための情報をユーザに入力させるため（図５の５１６）、画面データをワークフローサーバ１０２に要求する。

ステップＳ１３０３においては、アクティビティを更新するための情報をユーザに入力させるため（図５の５２２）、画面データをワークフローサーバ１０２に要求する。

ステップＳ１３１１においては、クライアント装置１０１から画面データの要求を受け付ける。

ステップＳ１３１２においては、要求がアクティビティの「追加」か「更新」かに応じて、画面データの生成を行う。

ステップＳ１３１３においては、生成した画面データをクライアント装置１０１に送信する。要求が「追加」であった場合（追加画面データを生成した場合）には、ステップＳ１３０４に進む。要求が「更新」であった場合（更新画面データを生成した場合）には、ステップＳ１３０７に進む。

ステップＳ１３０４においては、アクティビティを追加するための画面データを受信する。

ステップＳ１３０５においては、アクティビティを追加するための画面をクライアント装置１０１の表示装置に表示し、ユーザに必要な情報を入力させる。例として、図９のダイアログ（追加画面データに基づき生成した画面）５１６のアクティビティ名（５１８）、ユーザ名（５１９）に入力をさせて、受け付ける。

ステップＳ１３０６においては、前述のユーザ入力として受け付けた結果に基づき、経路情報オブジェクト５０４上に、アクティビティを追加する。以上により、追加処理の説明は完了する。

ステップＳ１３０７においては、アクティビティを更新するための画面データを受信する。

ステップＳ１３０８においては、アクティビティを更新するための画面に変更前のアクティビティ情報を設定して、クライアント装置１０１の表示装置に表示し、ユーザに必要な情報を入力させる。

ステップＳ１３０９においては、前述のユーザ入力として受け付けた結果に基づき、経路情報オブジェクト５０４上においてユーザに選択されているアクティビティの情報を更新する。以上により、更新処理の説明は完了する。

以上で、図１３におけるフローチャートの処理の説明を完了する。すなわち、図１２から図１３により、ワークフローシステムの動作についての説明を完了する。

以上の説明により、図６でも述べたように、ユーザは、経路情報の前後関係におけるアクティビティの整合性を意識することなく、容易にアクティビティの追加、更新、削除を行うことができるという効果が得られる。

次に図１４から図１７を用いて、本発明の実施形態における固定サイズの上位オブジェクトの中に、下位オブジェクトが表示される状態を説明する例である。前述で説明したように、本実施例では、ワークフローシステムのクライアント装置１０１に表示される経路情報オブジェクトに、１つまたは複数のアクティビティが表示されている。経路情報オブジェクトを本発明における「上位オブジェクト」（あるいは親オブジェクト）、アクティビティを本発明における「下位オブジェクト」（あるいは子オブジェクト）とする。

図１４は、本発明の実施形態に係わる、経路情報オブジェクトとアクティビティが表示される状態を示す一例である。本例においては、経路情報オブジェクトは横方向に３６単位の長さを持ち、アクティビティは標準で６単位の長さを持つ。５０４ｈでは、６つのアクティビティが経路情報オブジェクトに置かれているため、全てのアクティビティが標準である６単位のサイズで表示される。

図１４の５０４ｉから５０４ｋの経路情報オブジェクトでは、アクティビティの数が１つ増えて７つとなった場合の表示方法を示している。表示方法は様々あってよいが、５０４ｉから５０４ｋの例では、後述する図１６の拡大・縮小パターン記憶部Ｄ１６２１に記憶された縮小パターンに基づいて縮小した表示方法が決定される。まず、読みやすさの観点から「アクティビティやアクティビティに表示される文字はいくらでも小さくしてよいわけではない」ので、縮小パターンにおいては、アクティビティや文字の最小サイズを指定することができる。例えば、アクティビティは標準６単位のサイズだが、最小４単位のサイズとし、文字は標準１０ポイントだが、最小７ポイントとする、などである。

５０４ｉでは、選択状態にあるアクティビティ「課長確認２」以外の表示サイズが、全て５単位となっている（例：１４０２“課長確認４：下山敬子”）。このように選択状態にあるアクティビティの全てを同じ割合で縮小し、７つのアクティビティ全てを表示する方法がある。この方法は、選択されていない他のアクティビティも可能な限り見やすくする、という効果がある。

次に５０４ｊでは、選択状態にあるアクティビティ「課長確認２」に近いアクティビティは、できるかぎり標準サイズ（選択されたアクティビティと同じ６単位）で表示する。５０４ｊにおいては、選択されたアクティビティの左隣１つと、右隣２つのアクティビティが標準のサイズである。一方、最左端の１つ、最右端の２つのアクティビティは、最小サイズで表示されている。選択したアクティビティの周囲の状況（周囲のアクティビティの前後関係）を知りたい場合が多いが、この方法により周囲の状況が見やすくなる、という効果がある。

次に、５０４ｋでは、選択状態にあるアクティビティ「課長確認２」に近いアクティビティから、離れるに従って、より縮小させる、という方法を表している。これは、５０４ｉと５０４ｊの中間的な方法であり、選択されたアクティビティの周囲のアクティビティをより見やすくする、という効果がある。

図１５は、本発明の実施形態に係わる、経路情報オブジェクトとアクティビティが表示される状態を示す一例である。図１４では、７つのアクティビティは、最小サイズにすれば経路情報オブジェクトに配置することができたが、図１５の例は、選択されたアクティビティ以外、全てのアクティビティを最小サイズにしても、経路情報オブジェクトに収まらない例である。

経路情報オブジェクトのサイズは固定（例えば３６単位）であり、アクティビティの最小サイズは４単位であるため、アクティビティの数が９個を超える場合、５０４ｌによると、選択されたアクティビティ以外を全て最小にしても１５０１の部分が経路情報オブジェクトに収まらない。そこで１５０２のように経路情報オブジェクトにスクロールバーを設定する。スクロールバーを設定することにより、ユーザは、経路情報オブジェクトに表示されていないアクティビティが存在することを知り、また、バーを移動することで、表示されていないアクティビティが表示されるように表示状態を変更することができる。

ここで、スクロールバーを表示してスクロールさせる方法はあくまで例である。その他の方法では、例えば近年スマートフォンのＧＵＩ（グラフィカルユーザインタフェース）などにおいて、スワイプ（スマートフォンのタッチパネルに指を当てて左右に滑らせる動作、以下“スライド移動”と呼ぶことにする）などによることもできる。この場合、経路情報オブジェクトには表示されていないアクティビティが存在することをユーザに認識させるため、経路情報オブジェクトの左端、右端に、何らかの表示をしてもよい。スクロールやスワイプにより経路情報オブジェクトの中に収められているアクティビティが多く、全てのアクティビティを１度に画面に表示できない場合であっても、“スライド移動”させて確認することが可能となる。すなわちスライドすることにより、経路情報オブジェクト（上位オブジェクト）に配置されたアクティビティ（下位オブジェクト）のうち、表示対象となるアクティビティを変更する。なお本実施形態においては、ワークフローのアクティビティを使用しているため、左側にあるアクティビティが時間的に前に処理されるものであるが、実際に左右の前後関係はあってもなくてもよいものとする。

また、以上の例では、選択されたアクティビティは拡大していないが、ユーザにより見やすくするため、選択されたアクティビティの拡大、およびアクティビティ内に記載された情報の拡大、またはアクティビティ内に記載されるべき情報量をより詳細にする、などとしてもよい。

図１６は、経路情報オブジェクトにアクティビティを表示する際の表示制御処理の一例を示すフローチャートである。図１６のフローチャートの各ステップは、クライアント装置１０１上のＣＰＵ２０１で実行される。

ステップＳ１６０１においては、クライアント装置は、ユーザの操作から経路情報オブジェクトの編集を受け付ける。すなわち、経路情報オブジェクトに対するアクティビティの追加、削除、または選択中のアクティビティの更新を受け付ける。

ステップＳ１６０２においては、拡大・縮小パターン記憶部Ｄ１６２１から、拡大パターン・縮小パターンに関する情報を取得する。拡大パターンには、選択されたアクティビティを拡大する場合のサイズ（最大サイズ）、アクティビティ内に表示する情報量と文字サイズ、縮小パターンには、選択されたアクティビティ以外を縮小する場合のパターン、最小サイズ、アクティビティ内に表示する情報量（アクティビティがどのサイズの場合に、アクティビティに関連付けられた情報のうち、どの程度の情報を表示するか）、文字の最小サイズ、などを含む。

ステップＳ１６０３においては、アクティビティの増減があった場合を含め、全アクティビティが経路情報オブジェクト５０４に標準サイズで配置可能か否かを判断する。標準サイズで配置可能（“ＹＥＳ”の場合）には、ステップＳ１６１０に進む。標準サイズで配置可能ではない場合（“ＮＯ”の場合）には、ステップＳ１６０３に進む。

ステップＳ１６０４においては、選択されたアクティビティ以外のアクティビティを、どのパターンで縮小するか判断する。ここでは、図１４で説明した３つのパターンを例とするが、その他のパターンがあってもよい。選択されたアクティビティ以外を均等に縮小する旨、縮小パターンに設定されている場合（例：図１４の５０４ｉ）にはステップＳ１６０５に進む。標準サイズ（図１４で説明したところの６単位のサイズ）となるアクティビティを最大数となるように設定されている場合（例：図１４の５０４ｊ）には、ステップＳ１６０６に進む。選択されたアクティビティから離れるに従い徐々に小さくする旨、縮小パターンに設定されている場合（例：図１４の５０４ｋ）には、ステップＳ１６０７に進む。

ステップＳ１６０５においては、選択されたアクティビティ以外を均等に縮小する。最小サイズにまで縮小しなくとも全てのアクティビティが経路情報オブジェクト５０４に表示可能な場合には、最小サイズにまで縮小しなくともよい。

ステップＳ１６０６においては、選択されたアクティビティ以外で標準サイズとなるアクティビティを最大数とする。それ以外のアクティビティティは、最小サイズにする。

ステップＳ１６０７においては、選択されたアクティビティから経路情報オブジェクトの最左端、最右端にかけて、アクティビティのサイズを徐々に小さくする。どの程度まで小さくするかは、最小サイズによるが、小さくしなくても（すなわち標準サイズでも）全てのアクティビティが経路情報オブジェクト５０４に表示可能な場合には、最小サイズにまで縮小しなくともよい。

ステップＳ１６０８においては、前記ステップＳ１６０５〜Ｓ１６０７でアクティビティを縮小した場合に、アクティビティ内に表示する情報（文字列など）を縮小パターンの設定に基づき一部省略するか、あるいはサイズ（文字サイズなど）を縮小するか、を判断する。省略・縮小しない場合（“ＮＯ”の場合）はステップＳ１６１０、省略・縮小する場合（“ＹＥＳ”の場合）はステップＳ１６０９に進む。ここで、表示内容のうち、省略・縮小するものについて、いずれの項目から省略あるいは縮小するかは、不図示のテーブル（設定ファイル）などで、優先順位が指定することが可能である。さらに、どの程度まで縮小するかということ、またそれ以上縮小できない場合には、省略する、などの設定も可能である。

ステップＳ１６０９においては、縮小パターンの設定に基づき、アクティビティ内の表示情報の省略、文字などのサイズを決定する。例えば、ワークフローの例によると、アクティビティサイズを複数の段階に区切り、一段階縮小すると“承認者”の名前を省略し、更に省略すると“アクティビティ名”の文字サイズを小さくするなどのパターンが考えられる。あるいは、いずれも省略せず、文字サイズの縮小のみで対応する、などのパターンが考えられる。このようなパターンが縮小パターンとして定義されており、アクティビティのサイズの縮小・拡大に伴って、縮小の場合には表示内容の省略・縮小し、また縮小したサイズから拡大する場合には、省略した表示内容を再表示し、またサイズの拡大などを制御する。

ステップＳ１６１０においては、選択されたアクティビティ（図９の９０７、図１４の１４０１など太枠で記載されたアクティビティ）を標準サイズよりも拡大する。本ステップはなくともよい。すなわち縮小パターンのみがあり、拡大パターンは定義されていなくともよい。拡大パターンとしては、アクティビティの最大サイズ、表示内容（標準では表示していなかった承認時刻を表示するなど）、文字サイズなどがある。これらはあくまで例であり、他のパターンがあってもよい。

ステップＳ１６１１においては、前述の通り各アクティビティを縮小・拡大した結果として、全アクティビティが経路情報オブジェクト５０４に表示可能に収まるかを判定する。収まる場合（“ＹＥＳ”の場合）はステップＳ１６１３に進む。収まらない場合（“ＮＯ”の場合）はステップＳ１６１２に進む。

ステップＳ１６１２において、経路情報オブジェクト５０４にスクロールバーの付与、あるいはスワイプによって“スライド移動”することが可能となるように設定する。前述の通り、スクロールバーあるいはスワイプはあくまで一例であり、他の方法により“スライド移動”するものであってもよい。例えば、クライアント装置１０１のハードウェアとしてボタンなどが用意され、それらのボタンの押下により、イベントが発生し“スライド移動”が実行されてもよい。この場合、全てのアクティビティが経路情報オブジェクト５０４の表示領域内に表示される場合には、前記ボタンに対応する“スライド移動”のイベントは発生しないか、発生しても処理が実行されない。また、前述の“スワイプ”などの場合には、経路情報オブジェクト５０４上で“スワイプ”することにより実行されるため、可視的な意味ではスクロールバーのようなオブジェクトは表示されない場合があってもよい。いずれの場合も含めて、本発明の実施形態においては、“スライドイベントを処理可能とする”と表現する。

ステップＳ１６１３において、アクティビティが設定され、必要に応じてスクロールバーなどが設定された経路情報オブジェクト５０４がＧＵＩ上に表示される。

以上により、図１６のフローチャートについての説明を完了する。

また、ワークフローにおける経路情報では、“申請”（最初のアクティビティ）と“最終承認”（最後のアクティビティ）は、特に重要な役割がある。このため、図１６のフローチャートで示された処理における“縮小パターン”に対応する処理は実行せず、“標準サイズ”として表示してもよい。

一般的に、下位オブジェクトとしては、“配置指示受付部”で受け付け、“上位オブジェクト”に配置する場合に、最初と最後のオブジェクトには、“常に標準サイズで表示する”という属性を下位オブジェクトに設定してもよい。また、そのような属性を持たせるのではなく、図１６のフローチャートで、最初のオブジェクトや最後のオブジェクトを判断して“標準サイズ”で表示するように処理してもよい。また、ユーザに属性を設定させるようにしてもよい。

図１７は、本発明の実施形態に係わる、経路情報オブジェクトとアクティビティが表示される状態を示す一例である。前述の経路情報オブジェクトにおいては、アクティビティは全て横向きに並べられたが、縦向きに並べられてもよい（１７０１）。

また、上位オブジェクト（親オブジェクト）に対して、下位オブジェクト（子オブジェクト）は、縦横２次元に収められるようなものであってもよい（１７０２）。また、経路情報オブジェクトは、アクティビティに「処理順」という概念があるため、方向性があった。例えば左から右に、矢印が記載されていた。しかしながら、必ずしも方向性は必要ではない。単なる表であってもよく、１７０２はこの状態を表している。

なお、下位オブジェクトの配置は、アプリケーション（例えば前述のワークフローシステム）の開発時に開発者により実施されてもよいし、アプリケーションの実行時にエンドユーザにより実施されてもよい。いずれの場合も、本発明における“上位オブジェクトの表示領域内に下位オブジェクトを配置するようユーザから指示を受け付ける”ものである。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明におけるプログラムは、図４、図１２、図１３、図１６に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図４、図１２、図１３、図１６の処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図４、図１２、図１３、図１６の各装置の処理方法ごとのプログラムであってもよい。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１クライアント装置
１０２ワークフローサーバ
１０３開発装置
１０４ネットワーク

Claims

複数配置されたオブジェクトを、固定のサイズの表示領域内において閲覧可能に表示する情報処理装置であって、
複数のオブジェクトの配置の指示をユーザより受け付ける配置指示受付手段と、
前記配置指示受付手段によって受け付けた指示に基づき配置された複数のオブジェクトが固定のサイズの表示領域内において配置可能か否かを判定するサイズ判定手段と、
ユーザから前記配置指示受付手段によって受け付けた指示に基づき配置された複数のオブジェクトより、いずれかのオブジェクトの選択を受け付ける選択受付手段と、
前記選択受付手段で受け付けた前記オブジェクトではないオブジェクトのサイズの縮小方法を縮小パターンとして記憶する縮小パターン記憶手段と、
前記サイズ判定手段により、前記配置された複数のオブジェクトが前記固定のサイズの表示領域内において配置可能でないと判定した場合に、前記選択受付手段で受け付けた前記オブジェクトではないオブジェクトを前記縮小パターンに応じて縮小して前記配置された複数のオブジェクトを表示する表示制御手段と、
を備えることを特徴とする情報処理装置。
前記選択受付手段で受け付けた前記オブジェクトではないオブジェクトを前記縮小パターンに応じて縮小した後の複数の前記オブジェクトが前記固定のサイズの表示領域内において配置可能でない場合、前記固定のサイズの範囲以内において複数のオブジェクトを表示可能にするスライド機能を設定するスライド設定手段、
を更に備えることを特徴とする請求項１に記載の情報処理装置。
前記縮小パターンには、前記選択受付手段により選択を受け付けたオブジェクト以外のオブジェクトを均等のサイズに縮小して表示することが指定されること
を特徴とする請求項１または請求項２に記載の情報処理装置。
前記縮小パターンには、前記選択受付手段により選択を受け付けたオブジェクトと近い位置にあるオブジェクトは前記選択を受け付けたオブジェクトと同じサイズで表示させることが指定され、一方、前記選択受付手段により選択を受け付けたオブジェクトと離れた位置にあるオブジェクトは前記選択を受け付けたオブジェクトとよりも小さいサイズに縮小させることが指定されること
を特徴とする請求項１または請求項２に記載の情報処理装置。
前記縮小パターンには、前記選択受付手段により選択を受け付けたオブジェクト以外のオブジェクトを、前記選択受付手段により選択を受け付けたオブジェクトからの距離に応じて縮小する定義が含まれることが指定されること
を特徴とする請求項１または請求項２に記載の情報処理装置。
前記縮小パターンには、オブジェクトの縮小サイズに応じて、当該オブジェクトに表示する情報を、当該情報の優先順位に従って省略する定義が含まれることを特徴とする請求項１乃至請求項５のいずれか１項に記載の情報処理装置。
前記縮小パターンには、オブジェクトの縮小されたサイズに応じて、当該オブジェクトに表示する情報のサイズを縮小する定義が含まれることを特徴とする請求項１乃至請求項６のいずれか１項に記載の情報処理装置。
前記選択受付手段で受け付けた前記オブジェクトのサイズの拡大方法を拡大パターンとして記憶する拡大パターン記憶手段と、
を更に備え、
表示制御手段は、更に、前記選択受付手段で受け付けた前記オブジェクトを前記拡大パターンに応じて拡大して前記配置された複数のオブジェクトを表示する
ことを特徴とする請求項１乃至請求項７のいずれか１項に記載の情報処理装置。
オブジェクトを標準サイズで表示するか否かを前記縮小パターンの定義において指定可能であって、当該オブジェクトを標準サイズで表示する指定である場合には、縮小する対象であっても縮小しないで標準サイズで表示すること
を特徴とする請求項１乃至請求項８のいずれか１項に記載の情報処理装置。
複数配置されたオブジェクトを、固定のサイズの表示領域内において閲覧可能に表示する情報処理装置の制御方法であって、
配置指示受付手段が、複数のオブジェクトの配置の指示をユーザより受け付ける配置指示受付工程と、
サイズ判定手段が、前記配置指示受付工程によって受け付けた指示に基づき配置された複数のオブジェクトが固定のサイズの表示領域内において配置可能か否かを判定するサイズ判定工程と、
選択受付手段が、ユーザから前記配置指示受付工程によって受け付けた指示に基づき配置された複数のオブジェクトより、いずれかのオブジェクトの選択を受け付ける選択受付工程と、
縮小パターン記憶手段が、前記選択受付工程で受け付けた前記オブジェクトではないオブジェクトのサイズの縮小方法を縮小パターンとして縮小パターン記憶手段に登録する縮小パターン登録工程と、
表示制御手段が、前記サイズ判定工程により、前記配置された複数のオブジェクトが前記固定のサイズの表示領域内において配置可能でないと判定した場合に、前記選択受付工程で受け付けた前記オブジェクトではないオブジェクトを前記縮小パターンに応じて縮小して前記配置された複数のオブジェクトを表示する表示制御工程と、
を備えることを特徴とする情報処理装置の制御方法。
複数配置されたオブジェクトを、固定のサイズの表示領域内において閲覧可能に表示する情報処理装置において実行可能なプログラムであって、
前記情報処理装置を、
複数のオブジェクトの配置の指示をユーザより受け付ける配置指示受付手段と、
前記配置指示受付手段によって受け付けた指示に基づき配置された複数のオブジェクトが固定のサイズの表示領域内において配置可能か否かを判定するサイズ判定手段と、
ユーザから前記配置指示受付手段によって受け付けた指示に基づき配置された複数のオブジェクトより、いずれかのオブジェクトの選択を受け付ける選択受付手段と、
前記選択受付手段で受け付けた前記オブジェクトではないオブジェクトのサイズの縮小方法を縮小パターンとして縮小パターン記憶手段に登録する縮小パターン登録手段と、
前記サイズ判定手段により、前記配置された複数のオブジェクトが前記固定のサイズの表示領域内において配置可能でないと判定した場合に、前記選択受付手段で受け付けた前記オブジェクトではないオブジェクトを前記縮小パターンに応じて縮小して前記配置された複数のオブジェクトを表示する表示制御手段と、
として機能させることを特徴とするプログラム。
請求項１１に記載されたプログラムを記録したコンピュータ読み取り可能な記録媒体。