JP7395934B2 - 情報処理装置及びプログラム - Google Patents

Description

本発明は、情報処理装置及びプログラムに関する。

文書等のデータを取り扱うシステムの中には、データに対して実行可能なコマンドを呼び出すためのボタン等のＧＵＩ（グラフィカルユーザーインタフェース）部品を並べた一種のワークフローを示すバーをユーザに提供するものがある。ユーザは、バーに並んでいるボタンを順に押下していくことで、ワークフローに沿った作業を行うことができる。

また、このようなバーを、サーバを介して複数のユーザ端末で共有することも行われている。例えば、バーを共有しているユーザや管理者がそのバーに対してボタンの追加等の変更を加えると、その変更がサーバに登録され、そのバーを共有している各ユーザ端末は、サーバからその変更後のツールバーを取得して利用する。

このようなバーとして、出願人が提供するＤｏｃｕｗｏｒｋｓ（登録商標）の「お仕事バー」がある。

またこの種のシステムの中には、ユーザ端末のアプリケーションは、サーバとオンライン状態のときはもちろん、サーバとオフライン状態であっても、バーを用いてデータに対する処理を実行することができるものがある。

このように、データに対する処理を実行するコマンドやバー等の機能について他装置にて変更が行われた場合に、他装置と通信することによりその変更を受け付けて、自装置内の当該機能に反映することが行われている。自装置内の機能は、他装置と通信していない間でも実行できるものがある。

また、特許文献１に記載されたシステムでは、サーバは、複数のファイルを記憶し、変更管理ルールに実装されるユーザプリファレンスに従って、クライアントデバイスに渡ってその複数のファイルの同期を管理する。第１のバージョンのファイルは、少なくとも第１のクライアントと第２のクライアントに渡って同期することが指定されている。第１のクライアントは、第１のバージョンのファイルへアクセスして、第１の修正バージョンのファイルを作成し、第２のクライアントは第２のバージョンのファイルへアクセスして、第２の修正バージョンのファイルを作成する。第１のクライアントと第２のクライアントがそれぞれの修正バージョンのファイルを再同期することを試行する場合、サーバは、変更管理ルールに従って利用可能な修正バージョンのファイルから好適なバージョンを判定する。次に、好適なバージョンはサーバによって記憶され、次に、複数のクライアントデバイスに渡る同期のために供給される。

特許文献２に開示されたシステムでは、作業者は、共有データベースに格納された設計対象の標準設計データを、設計データ表現形式変換手段によって設計データ編集手段に固有のデータ表現に変換し、編集する。レビュー支援システムが、標準設計データに対する変更要求を検出した場合は、コミュニケーション制御手段がその変更要求を含むレビューメッセージを構成し、コミュニケーション手段によって他の作業者に配送する。その際、変更要求通知手段が配送すべき作業者と配送のタイミングを決定する。配送されたレビューメッセージは、レビュー履歴収集手段において変更要求箇所ごとに分別して蓄積されるので、作業者はその中から適切な変更要求を評価・選択し、設計データに反映させる。

特表２０１５－５２７６４６号公報 特開平８－２３５２３１号公報

他装置と通信していない間に、自装置内の機能に係る処理をデータに対して実行したとき、その間にその他装置でその機能に対して変更が行われていた場合、自装置内でのそのデータの処理結果は、その機能の変更に対応していない。そのデータの処理結果を変更後の機能に沿ったものにするには、自装置内にあるそのデータを特定する必要がある。このためにはユーザは、自装置が他装置と通信していなかった間に、変更された機能で処理したデータはどれであったのか思い出さなければならない。

本発明は、他装置と通信していない間に自装置内の機能に係る処理をデータに対して実行し、かつその間にその他装置でその機能に対して変更が行われていた場合に、自装置がそのデータを特定しない場合と比べて、ユーザがそのデータを特定する手間を軽減することを目的とする。

請求項１に係る発明は、プロセッサを備え、前記プロセッサは、他装置と通信を行い、前記他装置で行われた、データに処理を行う機能に対する変更を受け付け、前記変更を、自装置が持つ前記機能に反映させ、前記他装置と通信を行っていない期間に、ユーザからの指示に従って、自装置が持つ第１の機能に係る処理を第１のデータに対して実行し、前記第１の機能に係る処理を前記第１のデータに対して実行した後、前記他装置と通信を行ったときに、前記第１の機能に対する変更を前記他装置から受け付けた場合に、前記第１のデータを特定する情報を表示する、ことを特徴とする情報処理装置である。

請求項２に係る発明は、前記プロセッサは、更に、前記第１のデータに対して前記第１の機能に係る処理を実行した後、前記他装置と通信を行ったときに、前記第１の機能に対する変更を前記他装置から受け付けた場合に、前記第１のデータを前記第１の機能に係る処理の実行前の状態に戻す戻し処理を実行する、ことを特徴とする請求項１に記載の情報処理装置である。

請求項３に係る発明は、前記プロセッサは、前記戻し処理の後の前記第１のデータに対して、前記変更を反映した後の前記第１の機能に係る処理を実行する、ことを特徴とする請求項２に記載の情報処理装置である。

請求項４に係る発明は、前記第１の機能は、順序が規定された複数の部分機能から構成され、前記第１の機能に対する変更は、前記第１の機能を構成する複数の部分機能のうちのいずれかの部分機能の変更又は削除、又は前記第１の機能に対する部分機能の追加であり、前記プロセッサは、更に、前記期間における１以上の前記部分機能の実行の後、前記他装置と通信を行ったときに、前記第１の機能に対する変更を前記他装置から受け付けた場合に、前記第１のデータを、前記順序において、該変更にて前記第１の機能のうち変更又は削除又は追加された前記部分機能、の直前の部分機能以降の所定条件を満たす部分機能が実行されたときの状態に戻す戻し処理、を実行する、ことを特徴とする請求項１に記載の情報処理装置である。

請求項５に係る発明は、前記部分機能の各々には編集有無属性が設定されており、前記編集有無属性は、当該部分機能の実行により前記第１のデータに編集が加えられる可能性があるか否か示す属性であり、前記所定条件は、前記変更において前記第１の機能のうち変更又は削除又は追加された前記部分機能、の直前の部分機能以降の部分機能のうち、編集が加えられる可能性があることを示す前記編集有無属性を持つ、前記順序において最初の部分機能の直前の部分機能であること、である請求項４に記載の情報処理装置である。

請求項６に係る発明は、前記第１のデータに対して前記第１の機能に係る処理を実行した後、前記他装置と通信を行ったときに、前記第１の機能に対する変更を前記他装置から受け付けた場合に、前記第１のデータの状態を戻すか否かをユーザに問い合わせ、前記ユーザが戻す旨の指示を行った場合に、前記戻し処理を実行する、請求項２項に記載の情報処理装置である。

請求項７に係る発明は、各部分機能には、前記戻し処理の後に当該部分機能の自動実行を許可するか否かが設定されており、前記プロセッサは、前記戻し処理の後の前記第１のデータに対して、前記変更後の前記第１の機能を構成する複数の部分機能のうち、前記変更にて変更又は削除又は追加された前記部分機能以降の各部分機能を、自動実行を許可しないと設定されている部分機能、又は実行済みでない部分機能、のいずれかに達するまで、前記順序に従って実行する自動実行処理を行う、ことを特徴とする請求項４又は５に記載の情報処理装置である。

請求項８に係る発明は、前記自動実行処理後の前記第１のデータを表示し、前記ユーザから表示した前記第１のデータを受け入れるかどうか問い合わせ、前記ユーザから受け入れの回答があった場合に、前記自動実行処理後の前記第１のデータを有効なものとして保存する、請求項７に記載の情報処理装置である。

請求項９に係る発明は、前記プロセッサは、更に、ユーザからの指示に従って前記第１の機能の前記複数の部分機能のうちの１以上を実行した場合に、実行済みの部分機能の記録を行い、前記記録に基づき、前記順序においてユーザが次に実行を指示すべき部分機能が特定可能な表示を行い、前記戻し処理を実行した場合には、前記順序において、前記変更にて前記第１の機能のうち変更又は削除又は追加された前記部分機能、の直前の部分機能以降の前記所定条件を満たす部分機能の次の部分機能を、前記順序においてユーザが次に実行を指示すべき部分機能として特定可能な表示を行う、請求項４、５、７又は８のいずれか１項に記載の情報処理装置である。

請求項１０に係る発明は、コンピュータに、他装置と通信を行い、前記他装置で行われた、データに処理を行う機能に対する変更を受け付け、前記変更を、自装置が持つ前記機能に反映させ、前記他装置と通信を行っていない期間に、ユーザからの指示に従って、自装置が持つ第１の機能に係る処理を第１のデータに対して実行し、前記第１の機能に係る処理を前記第１のデータに対して実行した後、前記他装置と通信を行ったときに、前記第１の機能に対する変更を前記他装置から受け付けた場合に、前記第１のデータを特定する情報を表示する、という処理を実行させるためのプログラムである。

請求項１又は１０に係る発明によれば、装置と通信していない間に自装置内の機能に係る処理を第１のデータに対して実行し、かつその間にその他装置でその機能に対して変更が行われていた場合に、自装置がその第１のデータを特定しない場合と比べて、ユーザがその第１のデータを特定する手間を軽減することができる。

請求項２に係る発明によれば、ユーザが第１のデータをその機能の実行前の状態に戻す手間をなくすことができる。

請求項３に係る発明によれば、その機能の実行前の状態に戻した第１のデータに対して、変更後のその機能の実行をユーザが指示する手間をなくすことができる。

請求項４に係る発明によれば、部分機能の変更の影響を受ける直前の状態まで第１のデータを戻すことを、ユーザの介入なしに実行できる。

請求項５に係る発明によれば、ある部分機能の変更により第１のデータの編集に影響が出る直前の段階まで第１のデータを戻すことを、ユーザの介入なしに実行できる。

請求項６に係る発明によれば、第１データに対する戻し処理をユーザの希望に応じて実行することができる。

請求項７に係る発明によれば、戻し処理後に、変更された部分機能以降の各部分機能の実行をユーザが指示する場合と比べて、ユーザの負担を軽減することができる。

請求項８に係る発明によれば、自動実行の結果がユーザにとって適切である場合にのみ、その自動実行を有効なものとすることができる。

請求項９に係る発明によれば、ある部分機能の変更の後、どの部分機能を次に実行すればよいかを、ユーザに示すことができる。

フローバーを用いる文書取扱アプリケーションのＵＩ画面を例示する図である。 複数ユーザで共有されるフローバーに対して、あるユーザがサーバにオフライン状態であるときに変更が加えられる様子を例示する図である。 クライアントのハードウエア構成を例示する図である。 サーバ及びクライアントが保持する情報群を例示する図である。 ボタン管理情報を例示する図である。 バー管理情報を例示する図である。 履歴情報を例示する図である。 オフライン期間中のフローバーの変更により影響を受ける文書を知らせる処理手順を例示する図である。 オフライン期間中のフローバーの変更により影響を受ける文書を知らせるＵＩ画面を例示する図である。 オフライン期間中のフローバーの変更により影響を受ける文書を、適切な状態まで戻す処理手順を例示する図である。 図１０の手順における戻し処理の詳細な手順を例示する図である。 フローバーのボタンの追加に応じ、実行済みとする段階を、どのボタンまで戻すかを説明するための図である。 戻し処理が行われる前後のＵＩ画面の変化を例示する図である。 自動実行可否属性を含むボタン管理情報を例示する図である。 図１０の手順における戻し処理の詳細な手順の別の例であり、ボタンの自動実行を含む手順を例示する図である。 自動実行を行った場合のＵＩ画面の例を示す図である。 図１６に示した画面から呼び出される詳細画面の表示内容を例示する図である。 自動実行を行った場合のＵＩ画面の別の例を示す図である。 図１８に示した画面から呼び出される詳細画面の表示内容を例示する図である。 オフライン期間中のフローバーの変更により影響を受ける文書を、適切な状態まで戻す処理手順の別の例を示す図である。

図１を参照して、データに処理を行う機能の一例であるフローバー１１００を説明する。図１に示すのは、ユーザが操作するクライアント上で実行される文書取扱アプリケーションが提供するウィンドウ１０００である。このウィンドウ１０００のメインペイン１０１０には、フローバー１１００による処理の対象となり得るデータの一例である文書ファイル（以下単に文書と呼ぶ）のアイコン１０１２、１０１４が配置されている。メインペイン１０１０は、ユーザの作業の場、例えば机の上、のメタファであり、個々のアイコン１０１２及び１０１４は、その作業の場にある個々の文書を表象している。ツールバー１０２０には、文書に対して実行可能な機能の別の一例であるコマンドを表すボタン１０２２、１０２４等が配列されている。

ユーザは、アイコン１０１２又は１０１４等をマウスのクリック操作等で選択することで、これから行う処理の対象とする文書を選択する。そして、例えばユーザがツールバー１０２０上のボタン１０２２を押下する操作を行うと、その文書に対して、そのボタン１０２２に対応するコマンドの処理が実行される。

また、文書に対して実行するコマンドは、ツールバー１０２０上のボタン以外にも、ウィンドウ１０００上のメニューバー内の「ファイル」や「編集」等のメニューを選ぶことで表示されるプルダウンメニュー内から選択することもできる。

文書取扱アプリケーションが実行可能なコマンドには、例えばスキャナからのスキャン結果の文書を取り込むスキャンコマンド、文書内容を表示する表示コマンド、文書に対するアノテーション（すなわち注釈）を追加するアノテーションコマンドがある。アノテーションの中には、ユーザの承認印等の印影を表す画像を文書内の所定の場所に追加するものがある。また、そのようなコマンドの中には、文書をページ単位で複数の文書に分割する「ばらし」コマンドや、その逆に複数の文書のページ群を１つの文書に合成する「たばね」コマンド、及び文書に対して暗号化やアクセス権設定などを行うセキュリティコマンドがある。

フローバー１１００は、ユーザがこのアプリケーションを用いて行う業務のワークフローを表すバーである。フローバー１１００内には、そのワークフローを構成する個々のコマンドを表すボタン１１０２～１１０８が、そのワークフローにおける順序に従って配列されている。フローバー１１００内の個々のボタン１１０２～１１０８は、ツールバー１０２０やメニューバーから呼び出し可能なコマンドに対応している。そのボタン１１０２～１１０８の見た目や、対応するコマンドの設定内容については、そのユーザに固有のカスタマイズを行うことも可能である。例えば、ボタン１１０２は、スキャンコマンドに対応付けられているが、そのボタン１１０２を表す画像中には、「見積もり書をスキャン」というカスタマイズされた文言が含まれる。またボタン１１０４は、アノテーションコマンドに対応付けられており、アノテーションの内容としてそのユーザの承認印の印影の画像が設定されている。

ユーザは、フローバー１１００が表すワークフローを実行する場合、まずスキャナに見積もり書をセットして、先頭のボタン１１０２を押下する。これにより、スキャナがその見積もり書をスキャンし、スキャンの結果得られる文書が文書取扱アプリケーション内に取り込まれる。取り込まれた文書のアイコン１０１２は、メインペイン１０１０内に表示される。次に、ユーザが、そのアイコン１０１２を選択し、ボタン１１０４を押下すると、そのアイコン１０１２が示す文書（すなわち見積もり書）に対して承認印が押下される。次に、ユーザは、ボタン１１０６（名称「カタログと束ねる」）を押下して、アイコン１０１２が示す見積もり書に対して、別途スキャンしてメインペイン１０１０に取り込んであった製品カタログの文書ファイルを束ねる。これにより、見積もり書とカタログを束ねた１つの文書のアイコンがメインペイン１０１０上にできる。次にユーザは、その文書のアイコンを選択し、ボタン１１０８（名称「セキュリティをかける」）を押下することで、その文書に対して、所定のアクセス権（例えば編集禁止）を設定する等のセキュリティ上の処理を施す。

ここでは、フローバー１１００内の全てのボタン１１０２～１１０８を１人のユーザが押下する形で説明したが、これは一例に過ぎない。この代わりに、同じフローバー１１００を共有する複数のユーザが、それぞれ自分の役割に対応するボタン１１０２～１１０８を押下することにより、複数人によるワークフローを構成することも可能である。この場合、例えば、そのフローバー１１００にはサーバ上の特定のフォルダが対応付けられ、そのフォルダは、ユーザのクライアント内の特定のフォルダと同期される。各ユーザが操作するクライアントのメインペイン１０１０には、そのフローバー１１００に対応するサーバ上のフォルダと同期している、クライアント内の特定のフォルダ内にある文書群のアイコン１０１２等が表示される。

フローバー１１００は、そのフローバー１１００内に含まれるボタン１１０２～１１０８が示すコマンドの並びが示す一連の処理を、対象のとなる１以上の文書等のデータに施す。すなわち、フローバー１１００は、「データに処理を行う機能」を表している。フローバー１１００を１つの「機能」とみなした場合、それに含まれる個々のボタン１１０２～１１０８が示すコマンドは、その「機能」を構成する「部分機能」とみなせる。

上述の通り、フローバー１１００は複数のユーザ間で共有可能である。そして、それら複数のユーザが共有するフローバー１１００は、それら複数のうちのいずれかのユーザにより、或いはそのフローバー１１００の編集権限を持つ他のユーザ（例えばシステム管理者）により変更される場合がある。フローバー１１００の変更には、例えば、新たなボタン（すなわちコマンド）の追加、既存のボタンの削除、既存のボタンに対応するコマンドの設定内容の変更、等がある。

あるユーザが自分の操作するクライアント上でフローバー１１００を変更した場合、その変更の内容は、そのクライアントがサーバと通信可能になり次第、サーバに反映される。例えばサーバとオンライン状態（すなわち通信可能な状態）にあるクライアント上でユーザがフローバー１１００を変更した場合、その変更は即座にサーバ上のそのフローバー１１００の管理情報に反映される。そして、サーバに反映された変更後のフローバー１１００は、そのフローバー１１００を共有している各ユーザのクライアントがそのサーバと通信可能になり次第、そのクライアントに反映される。

フローバー１１００を共有しているあるユーザのクライアントがサーバに対してオフライン状態（すなわち通信不可の状態）にあるときに、サーバ上のそのフローバー１１００が変更されることがある。その場合、そのクライアントは、再びサーバに対してオンライン状態となるまでは、変更前のフローバー１１００を用いてユーザからの指示を受け付ける。

なお、フローバー１１００を用いて１つのジョブのワークフローを実行する場合、フローバー１１００内の個々のボタンが示すコマンドを、そのフローバー１１００を共有する別々のユーザが実行してもよい。

図２に示す例では、サーバ２００上のフローバー１１００Ａが、あるとき、ボタン１１０４を追加されることにより、フローバー１１００Ｂへと変更されている。ユーザ「Ａさん」のクライアント１００は、その変更の際にサーバ２００とオンライン状態なので、その変更に直ちに追従し、ウィンドウ１０００内に変更後のフローバー１１００Ｂを表示する。これに対して、ユーザ「Ｂさん」のクライアント１００は、その変更の際にサーバ２００とオフライン状態なので、変更前のフローバー１１００Ａを用いて、「Ｂさん」からの指示を受け付ける。

このようにサーバ２００上のフローバー１１００が変更されたときに、サーバ２００とオフライン状態であるクライアント１００では、変更前のフローバー１１００を用いたまま処理が進められる場合が出てくる。変更前のフローバー１１００を用いて進められてしまった処理の結果の文書は、変更後のフローバー１１００が表すワークフローに準拠しないものとなってしまうことがある。例えば、図２の例において、「Ｂさん」がサーバ２００にオフライン状態のクライアント１００で、変更前のフローバー１１００Ａの最後のボタン１１０８（これは「セキュリティをかける」コマンドを示す）まで作業を進めたとする。しかしながら、この作業が行われた時点では、サーバ２００上ではフローバー１１００Ａは既にフローバー１１００Ｂに変更されている。「Ｂさん」の作業結果の文書は、サーバ２００上の正しいフローバー１１００Ｂが含んでいるボタン１１０４の処理を経ていないので、承認印が押印されていない状態となっている。この文書は、変更後のフローバー１１００Ｂが示すワークフローにとっては不適格なものである。

その後「Ｂさん」のクライアント１００がサーバ２００にオンライン状態となったときに、そのクライアント１００上のフローバー１１００Ａは、サーバ２００と同期してフローバー１１００Ｂへと変更される。このとき、オフライン期間中に変更前のフローバー１１００Ａを用いて処理された文書は、そのままでは新しいワークフローに合わないので、その文書に施した編集を元に戻す必要が出てくる。このためには、「Ｂさん」は、メインペイン１０１０内のアイコン１０１２、１０１４等が示す文書の中から、そのオフライン期間中に処理したものを探す必要があり、手間が掛かる。そこで、本実施形態では、「Ｂさん」に対して、そのオフライン期間中に処理した文書を知らせることを行う。なお、オフライン期間とは、クライアント１００がサーバ２００とオフライン状態である期間のことをいう。

＜ハードウエア構成の例＞
文書取扱アプリケーションを実行するクライアント１００のハードウエア構成を例示する。

クライアント１００は、コンピュータの一種であり、例えば、図３に示すように、ハードウエアとして、プロセッサ１０２、ランダムアクセスメモリ（ＲＡＭ）等のメモリ（主記憶装置）１０４、フラッシュメモリやＳＳＤ（ソリッドステートドライブ）、ＨＤＤ（ハードディスクドライブ）や等の補助記憶装置１０６を制御するコントローラ、各種の入出力装置１０７とのインタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース１０８等が、例えばバス１０９等のデータ伝送路を介して接続された回路構成を有する。文書取扱アプリケーションが、ネットワーク等を経由してコンピュータにインストールされ、補助記憶装置１０６に保存される。補助記憶装置１０６に保存されたそのアプリケーションが、プロセッサ１０２によりメモリ１０４を用いて実行されることにより、そのアプリケーションの各機能が実現される。

ここでプロセッサ１０２とは広義的なプロセッサを指し、汎用的なプロセッサ（例えばＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、等）や、専用のプロセッサ（例えばＧＰＵ：Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、 ＡＳＩＣ：Ａｐｐｌｉｃｔｉｏｎ Ｓｐｅｓｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、 ＦＰＧＡ：Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ、 プログラマブル論理デバイス、等）を含むものである。

また、プロセッサ１０２の動作は、１つのプロセッサ１０２によってなすのみでなく、物理的に離れた位置に存在する複数のプロセッサ１０２が協働してなすものであってもよい。また、アプリケーション実行時のプロセッサ１０２の各動作は、以下の実施形態において説明する順序のみに限定されるものではなく、適宜に変更してもよい。

なお、サーバ２００も、クライアント１００と同様、コンピュータをベースとして構成されている。

＜フローバーに関する管理情報の例＞
図４に例示するように、上述したフローバー１１００関連のサービスのために、クライアント１００及びサーバ２００は、ボタン管理情報１１０及び２１０、バー管理情報１２０及び２２０、並びに履歴情報１３０及び２３０を保持している。

ボタン管理情報１１０及び２１０は、フローバー１１００に含まれる個々のボタン１１０２～１１０８についての管理情報である。ボタン管理情報１１０及び２１０は、図５に例示するように、ボタンＩＤ、編集有無、及び最終更新日時の各属性項目を含む。

「ボタンＩＤ」は、個々のボタン１１０２～１１０８を一意に識別する識別情報である。サーバ２００は、様々なユーザが用いる様々なフローバー１１００の情報を管理している。ボタンＩＤは、それら様々なフローバー１１００内の各ボタンに対して一意に割り当てられている。図示は省略したが、ボタンが示すコマンドと設定内容の組が、そのボタンのボタンＩＤに対応付けてクライアント１００及びサーバ２００に保存されている。このうち、設定内容は、ユーザごと、又はそのボタンを共有するユーザのグループごとにカスタマイズされている。

ボタン管理情報１１０及び２１０の属性「編集有無」は、当該ボタンを押下した場合に、対象の文書に対して編集が加えられる可能性が有るか否かを示す。ここで、文書に対する編集とは、文書の内容又は文書の特定の属性又は文書のデータ形式に変更を加える処理を指す。

ここで、文書の内容の編集には、文書本体の内容の編集、文書本体に付加されるアノテーションの編集が含まれる。このうち文書本体の編集は、文書本体に対する記載の追加、削除又は変更を含む。また、文書をページ単位で複数の部分にばらすばらし処理や、複数の文書を１つに束ねる束ね処理も、文書本体の編集の概念に含まれる。また、アノテーションの編集は、文書本体に対してアノテーションを付加すること、文書本体に付加されているアノテーションを削除すること、又は文書本体に付加されているアノテーションを変更すること、を含む。

例えば、「承認印を押す」ボタン１１０４は、文書に対して承認印の画像を示すアノテーションを追加する処理を示すものであり、文書の見た目の内容に変更を加えるものである。したがって、そのボタン１１０４についての属性「編集有無」の値は「有」となる。

また、「カタログと束ねる」ボタン１１０６は、スキャンした文書（例えば注文書）を対応するカタログの文書と束ねて１つの文書にする処理であり、このボタン１１０６についての属性「編集有無」の値は「有」となる。

また、「セキュリティをかける」ボタン１１０８に対応するコマンドが実行する処理には、文書に対して、予め設定されている操作を禁止する操作禁止属性を付加する処理が含まれる。例えば、文書の内容の編集を禁止するか否か、文書に付加するアノテーションの編集を禁止するか否か、印刷を禁止するか否か、文書の内容やアノテーションを他の文書に転記することを禁止するか否か、といった各種の項目が、そのボタン１１０８に対して設定可能である。そのボタン１１０８が示す処理は、文書の特定の属性の一例である操作禁止属性に対して変更を加えるものであり、文書に対する編集の一形態である。したがって、そのボタン１１０８の属性「編集有無」の値は「有」である。

また、「ＰＤＦ形式で保存する」ボタンのように、文書のデータ形式を変更する処理を示すボタンの属性「編集有無」の値は「有」となる。

一方、対象の文書に関する予め用意されているメモやマニュアルを表示するボタンは、その文書の内容や属性等を変更するものではないため、属性「編集有無」の値は「無」である。

ボタン管理情報１１０及び２１０の属性「最終更新日時」は、当該ボタンに対応するコマンドの処理内容又は設定内容が最後に更新された日時を示す。

バー管理情報１２０及び２２０は、フローバー１１００の管理情報である。バー管理情報１２０及び２２０は、図６に例示するように、バーＩＤ、バー定義、及び最終更新日時の各属性項目を含む。

「バーＩＤ」は、当該フローバー１１００を一意に識別するための識別情報である。「バー定義」は、当該フローバー１１００が表すワークフロー、すなわちそのフローバー１１００を構成するボタンのボタンＩＤの並びを表す情報である。例えば、図示例のバーＩＤ「１」のフローバーは、ボタンＡ、Ｂ、Ｃがこの順に並んだフローバー１１００を表す。「最終更新日時」は、当該フローバー１１００のバー定義が最後に更新された日時を示す。

例えばあるユーザが、あるフローバーに含まれるあるボタンに対応するコマンドの設定内容を変更すると、ボタン管理情報１１０及び２１０におけるそのボタンの最終更新日時がその変更のあった日時へと変更される。またこの場合、バー管理情報１２０及び２２０内の、そのボタンを含むフローバーの最終更新日時も、その変更のあった日時へと変更される。

また例えばあるユーザが、あるフローバーに対してボタンの追加を行った場合、バー管理情報１２０及び２２０におけるそのフローバーの最終更新日時が、その追加のあった日時へと変更される。また、このとき、ボタン管理情報１１０及び２１０に、その追加されたボタンの情報が登録される。また例えばあるユーザが、あるフローバーに対してボタンの削除を行った場合、バー管理情報１２０及び２２０におけるそのフローバーの最終更新日時が、その削除のあった日時へと変更される。

クライアント１００内のボタン管理情報１１０及びバー管理情報１２０と、サーバ２００内のボタン管理情報２１０及びバー管理情報２２０とは、同期している。ただし、サーバ２００内のボタン管理情報２１０又はバー管理情報２２０が変更されたときに、サーバ２００とオフライン状態であるクライアント１００内のボタン管理情報１１０及びバー管理情報１２０は、今度サーバ２００とオンライン状態になるまでは、古い情報のままである。

履歴情報１３０及び２３０は、ユーザがフローバー１１００を利用した履歴を示す情報である。履歴情報１３０及び２３０の個々のレコードは、図７に例示するように、ジョブＩＤ、バーＩＤ、ボタンＩＤ、文書ＩＤを含む。

ジョブＩＤは、フローバー１１００を用いて実行されるジョブ（すなわち１つの具体的なワークフロー）を一意に識別する識別情報である。ジョブＩＤとしては、例えば、ジョブが生成される順に採番されるシリアル番号を用いてもよい。この場合、あるユーザがあるフローバー１１００内のボタンの並びのうちの最初のボタンを押下すると、そのフローバー１１００を用いた新たなジョブが開始され、そのジョブのジョブＩＤが採番される。

図７のレコード内のバーＩＤは、当該ジョブで用いられているフローバー１１００のバーＩＤである。またボタンＩＤは、そのバーＩＤが示すフローバー１１００内で、そのレコードが生成される際に押下されたボタンのボタンＩＤである。また文書ＩＤは、そのボタンの押下により実行されたコマンドの処理結果として生成された文書の識別情報である。なお、１つの文書の文書ＩＤは、押下されたボタンに対応するコマンドの実行によりその文書の内容が変更された場合も維持される。

以上の説明から分かるように、履歴情報１３０及び２３０のレコードは、フローバー１１００のボタンが押下されるごとに生成される。履歴情報１３０及び２３０内のレコード群は、そのレコードが生成された順に並んでいる。原理上はなくてもよいが、個々のレコードには、そのレコードに対応するボタンが押下された時刻（或いはそのボタンに対応するコマンドの実行時刻）が含まれていてもよい。

クライアント１００上で押下されたボタンについてのレコードは、そのクライアント１００内の履歴情報１３０に追加される。また、そのレコードは、そのクライアント１００がサーバ２００とオンライン状態になり次第、サーバ２００に送信され、サーバ２００内の履歴情報２３０に追加される。したがって、クライアント１００上でボタンが押下されたときにそのクライアント１００がサーバ２００とオンライン状態であれば、そのボタン押下に対応する履歴のレコードは即座にサーバ２００に記録される。しかし、クライアント１００上でボタンが押下されたときにそのクライアント１００がサーバ２００とオフライン状態であれば、そのボタン押下の履歴のレコードは、そのときにはそのクライアント１００のみに記録され、サーバ２００には反映されない。

図１に例示したウィンドウ１０００内のメインペイン１０１０上で文書のアイコンが選択されると、プロセッサ１０２は、その文書のＩＤを含んだレコードを履歴情報１３０から特定し、そのレコードに含まれるバーＩＤに対応するフローバー１１００を表示してもよい。

＜オフライン中に処理した文書を知らせる処理＞
次に図８を参照して、クライアント１００のプロセッサ１０２が実行する、本実施形態の処理の一例を説明する。この処理は、例えば、クライアント１００にインストールされている文書取扱アプリケーションの機能の１つとして実装される。図８の処理手順は、そのクライアント１００がサーバ２００とオフライン状態にある間にそのクライアント１００でフローバー１１００を用いて処理された文書を知らせる処理である。図８の手順は、クライアント１００にインストールされているフローバー１１００ごとに実行される。図８の手順の対象となっているフローバー１１００のことを注目バーと呼ぶ。

図８の手順は、プロセッサ１０２が、サーバ２００に対してオフライン状態からオンライン状態へと変化したことを検知したときに実行される。この手順では、プロセッサ１０２は、まずサーバ２００からボタン管理情報２１０、バー管理情報２２０及び履歴情報２３０を取得する（Ｓ１０）。このとき、ボタン管理情報２１０、バー管理情報２２０及び履歴情報２３０のうち、注目バーと同じバーＩＤのフローバー１１００の情報、このフローバー１１００に含まれる各ボタンの情報、及びそのバーＩＤを含む履歴のレコード群を取得する。クライアント１００内のボタン管理情報１１０及びバー管理情報１２０は、このとき取得した情報を反映した状態へと更新される。

次にプロセッサ１０２は、Ｓ１０で取得した情報に基づいて、注目バーがオフライン期間中に変更されたかどうかを判定する（Ｓ１２）。すなわち、クライアント１００内のバー管理情報１２０中の注目バーの最終更新日時よりも、サーバ２００内のバー管理情報２２０中の同じバーＩＤに対応する最終更新日時が後であれば、注目バーに変更があったと判定する。

Ｓ１２の判定結果がＮｏの場合は、注目バー自体が変更されていないので、その注目バーを用いた文書の編集結果を元に戻す必要はない。したがって、この場合は、図８の処理を終了する。

Ｓ１２の判定結果がＹｅｓの場合、プロセッサ１０２は、クライアント１００内の履歴情報１３０と、サーバ２００から取得した履歴情報２３０とをジョブ単位で突き合わせる。そして、履歴情報１３０と２３０の両方で共にフローバーの最後のボタンの実行が完了しているジョブについては、以降の処理の対象から外す（Ｓ１３）。そのようなジョブについては、クライアント１００とサーバ２００を含むシステム全体で、既にフローバーが示すワークフローが完了しているからである。これに対して、サーバ２００の履歴情報２３０においてフローバーの最後のボタンの実行が完了していないジョブが見つかれば、そのジョブは、以降の処理の対象となる。

次にプロセッサ１０２は、注目バーのボタンのうち今回のオフライン期間（すなわち今回オンライン状態に移行する直前のオフライン期間）中に変更があったボタンを特定する。変更があったボタンとは、対応するコマンドや設定内容が変更されたボタン、注目バーに追加されたボタン、又は注目バーから削除されたボタンである。以下、変更があったボタンのことを「変更ボタン」と呼ぶ。変更ボタンが今回のオフライン期間中に注目バーから削除されたボタンである場合、その変更ボタンは変更後の注目バーには存在しない。注目バーにボタンが追加又は削除されたことは、クライアント１００内の当該注目バーのバー定義と、サーバ２００から取得した当該注目バーのバー定義とを比較することで見つけることができる。また、その注目バーのバー定義に含まれるボタンのクライアント１００のボタン管理情報１１０内での最終更新日時よりも、サーバ２００のボタン管理情報２１０でのそのボタンの最終更新日時が新しければ、そのボタンのコマンド内容又は設定内容が変更されたと判定できる。

以下に説明するＳ１４以降のステップ群は、Ｓ１３で処理対象として残ったジョブごとに実行される。すなわち、以下に説明するステップ群では、処理対象のジョブごとに、履歴情報１３０内のそのジョブのＩＤを含んだレコード群を調べることで、以下の各ステップを実行する。

プロセッサ１０２は、注目バー内のボタンのうち、変更ボタンより順序が後の実行済みのボタンを特定する（Ｓ１４）。Ｓ１４では、クライアント１００内の履歴情報１３０中の注目バーのバーＩＤを含んだレコードの中に、変更ボタンより順序が後のボタンの実行履歴を示すレコードがあるかどうかを調べる。そのようなレコードがあれば、そのレコードが示すボタンを、Ｓ１４にて変更ボタンより順序が後の実行済みのボタンとして特定する。Ｓ１４で特定したボタンを「実行済みボタン」と呼ぶ。

次にプロセッサ１０２は、Ｓ１４の条件に該当する実行済みボタンが見つかったか否かを判定する（Ｓ１６）。変更ボタンより順序が後のボタンの実行結果は、変更ボタンの変更により影響を受ける。変更ボタンより順序が後の実行済みボタンがある場合、その実行済みボタンの実行により文書が編集されている可能性もあるため、確認が必要である。これに対して変更ボタンより順序が前のボタンの実行結果は、変更ボタンの変更により影響を受けないので、そのような確認は不要である。

Ｓ１６の判定結果がＮｏの場合、プロセッサ１０２は、Ｓ１８～Ｓ２４をスキップし、サーバ２００から得た注目バーの変更を、当該クライアント１００内のバー管理情報１２０内の注目バーの情報に反映する（Ｓ２６）。これにより、当該クライアント１００内の注目バーは、サーバ２００上の当該注目バーの最新状態と同期する。

Ｓ１６の判定結果がＹｅｓの場合、プロセッサ１０２は、注目バー内のボタンのうちの変更ボタンと、その変更ボタンよりも注目バー内での順序が後の各実行済みボタンとについて、ボタン管理情報２１０内の「編集有無」属性の値が「有」のものを探す（Ｓ１８）。そして、それらボタンの中に「編集有無」属性の値が「有」のものがあったかどうかを判定する（Ｓ２０）。

変更ボタンとこれ以降の実行済みボタンの中に「編集有無」属性の値が「有」のものがあれば、それは、変更ボタンの変更前の状態に対応するコマンドが実行された後更に編集を受けた文書が存在することを意味する。その文書の編集結果は、変更ボタンの変更後の状態に対応するコマンドの実行を経ていないので、変更後のワークフローからみて有効と言えない場合がある。このような文書を探すために、Ｓ２０を実行している。

Ｓ２０の判定結果がＮｏの場合、プロセッサ１０２は、サーバ２００から得た注目バーの変更を、当該クライアント１００内のバー管理情報１２０内の注目バーの情報に反映する（Ｓ２６）。これにより、当該クライアント１００内の注目バーは、サーバ２００上の当該注目バーの最新状態と同期する。

Ｓ２０の判定結果がＹｅｓの場合、プロセッサ１０２は、Ｓ２０で見つけた「編集有無」属性の値が「有」の変更ボタン及び実行済みボタンに対応する、編集結果の文書を特定する（Ｓ２２）。このステップでは、履歴情報１３０中の、変更ボタン及びこれより順序が後の実行済みボタンについてのレコード（図７参照）から、「編集有無」属性の値が「有」の変更ボタン及び実行済みボタンに対応する文書ＩＤを特定すればよい。

次にプロセッサ１０２は、表示しているウィンドウ１０００のメインペイン１０１０内の各文書のアイコン１０１２、１０１４等のうち、Ｓ２２で特定した文書のアイコンを、そうでない文書のアイコンと区別できる表示態様で強調表示する（Ｓ２４）。また、プロセッサ１０２は、サーバ２００から得た注目バーの変更を、当該クライアント１００内のバー管理情報１２０内の注目バーの情報に反映する（Ｓ２６）。

以上、図８の手順について説明した。図８の手順のＳ２４及びＳ２６によりクライアント１００の画面に表示されるウィンドウ１０００の例を図９に示す。

図９の例は、図２に示したフローバー１１００Ａが、ボタン１１０４の追加により、フローバー１１００Ｂに変化した場合の例である。図９に例示したウィンドウ１０００では、Ｓ２２で特定された文書のアイコン１０１２が太い枠線により強調表示されている。また、そのアイコン１０１２に関連付けて、メッセージ欄１０５０がポップアップ表示されている。このメッセージ欄１０５０には、フローバーが変更されたために、その文書の編集を元に戻す必要があることを示すメッセージが表示される。また、ウィンドウ１０００には、ボタン１１０４が追加されたフローバー１１００Ｂが表示されている。

以上に説明したように、図８の処理手順によれば、ウィンドウ１０００内に表示された文書のうち、オフライン期間中のフローバー１１００の変更により編集結果を元に戻す必要がある文書がどれであるかが、強調表示によりユーザに示される。

なお、以上の例では、Ｓ２２で特定した文書をウィンドウ１０００のメインペイン１０１０内で強調表示したが、特定した文書を知らせるための表示は、このような強調表示に限らない。例えば、Ｓ２２で特定した文書を指し示すリンク等の情報を一覧表示した別ウィンドウを表示するという方式で、それら文書を特定する情報をユーザに提供してもよい。

＜オフライン期間中の編集結果に対する戻し処理＞
次に、図１０及び図１１を参照して、図８の手順の変形例を説明する。図８の手順では、注目バーの変更に応じてオフライン期間中の編集結果を元に戻す必要がある文書がどれであるかをユーザに知らせるだけであった。これに対して、この変形例では、文書の状態をオフライン期間中の編集が行われる前まで戻す処理を行う。

図１０は、この処理の全体的な手順を示す図である。図１０の手順のうち、Ｓ１０～Ｓ２２は、図８の手順の同符号のステップと同じ処理を示す。

図１０の手順では、Ｓ２０の判定結果がＮｏの場合、プロセッサ１０２は、サーバ２００から得た注目バーの変更を、当該クライアント１００内のバー管理情報１２０内の注目バーの情報に反映する（Ｓ２８）。一方、Ｓ２０の判定結果がＹｅｓの場合、プロセッサ１０２はＳ２２の処理を行う。そして、プロセッサ１０２は、Ｓ２２で特定した各文書について「戻し処理」を実行する（Ｓ３０）。

図１１に、Ｓ３０の詳細な処理手順の一例を示す。この手順では、Ｓ２２で特定された文書の戻し先ボタンを特定する（Ｓ３０２）。Ｓ３０２では、プロセッサ１０２は、変更ボタンを起点とし、その起点からフローバー上でのボタンの並び順に、ボタン管理情報１１０における変更ボタン又は実行済みボタンの「編集有無」の値を調べていく。そして、その過程で最初見つかった編集「有」のボタンの直前のボタンを戻し先ボタンとする。注目バーのボタンの並び順における実行済みボタンのうちの最後のものを示すマークを、その戻し先ボタンまで戻すのである。変更ボタンの変更が文書の編集に影響するのは、その変更ボタン以降で最初の編集「有」のボタンが最初なので、その最初の編集「有」のボタンは未実行の状態に戻すわけである。

この処理では、変更ボタン（すなわち追加、削除、又は内容が変更されたボタン）が削除されたボタンである場合でも、その変更ボタンが編集「有」であれば、その変更ボタンの直前のボタンが戻し先ボタンとなる。文書の編集を伴う処理を示すボタンを削除した場合、その削除後のフローでは、その編集のない文書の処理結果が必要となるため、文書の状態をその編集を受ける前に戻す必要がある。また、Ｓ３０２の処理の過程で最初に見つかった編集「有」のボタンの直前のボタンが変更ボタンであり、その変更ボタンが削除されたボタンである場合、変更後のフローバーにはその変更ボタンは存在しないので、その変更ボタンの１つ前のボタンを戻し先ボタンとする。

また、オフライン期間中に、同じ注目バーを用いて複数のジョブが実行されていた場合、戻し先ボタンはジョブごとに異なる可能性がある。

次にプロセッサ１０２は、Ｓ２２で特定した文書の状態を戻し先ボタンの実行直後（言い換えればその『最初の編集「有」のボタン』の実行直前）の状態まで戻す（Ｓ３０４）。

文書に対してあるボタンが実行されることにより得られた実行の結果の文書をそのボタンの実行前の状態に戻すには、そのボタンが示すコマンドの処理の逆の処理をその文書に施せばよい。このボタン単位での処理の巻き戻しを、文書に対して最新に実行されたボタンから、ボタン群の実行の順の逆順に１ボタン分ずつ行うことで、戻し先ボタンの実行直後の状態まで文書の状態を戻す。また、別の例として、履歴情報１３０及び２３０の各レコードに、そのレコードに係るボタンの実行結果の文書（すなわちその実行時点でのスナップショット）を記録しておけば、戻し先ボタンの実行直後の状態まで文書の状態を戻すことは容易である。この場合、単にその戻し先ボタンのレコードに記録されたその文書のスナップショットを取り出し、メインペイン１０１０に表示する文書をそのスナップショットに入れ替えればよい。

これに伴い、プロセッサ１０２は、履歴情報１３０から、当該ジョブ（すなわち、戻す対象の文書が含まれていたレコードが属するジョブ）内の戻し先ボタンより後のボタンの実行済みを示すレコードを削除する。

次にプロセッサ１０２は、サーバ２００から取得した注目バーの最新状態を、クライアント１００内の注目バーに反映する（Ｓ３０６）。Ｓ３０６の処理はＳ２６の処理と同様である。次にプロセッサ１０２は、注目バーに表示する完了マーカを、戻し先ボタンの位置に移動する（Ｓ３０８）。完了マーカは、フローバー１１００が示すボタンの並び順において、実行済みボタンのうちの最後のものを表すマーカ（すなわち印）である。なお、プロセッサ１０２が、メインペイン１０１０上で選択されている文書に対応するフローバー１１００を表示する際、履歴情報１３０内のレコード群から当該ジョブの最後の実行済みボタンを特定し、このボタンに完了マーカを表示することも考えられる。この場合、履歴情報１３０から戻し先ボタンより後のボタンのレコードを削除しておけば、Ｓ３０８の効果は自動的に得られる。

そして、プロセッサ１０２は、Ｓ３０２で特定した戻し先ボタンの情報をサーバ２００に送信する（Ｓ３１０）。このときプロセッサ１０２がサーバ２００に送る情報には、当該ジョブのジョブＩＤ、及び戻し先ボタンのボタンＩＤが含まれる。この情報を受け取ったサーバ２００は、履歴情報２３０内のそのジョブＩＤを含んだレコードのうち、戻し先ボタンより順序が後のボタンの実行済みを示すレコードを削除する。これにより、当該ジョブについての戻し先ボタンがサーバ２００に反映される。

なお、図１０及び図１１の処理では戻し処理（Ｓ３０）を自動的に実行したが、これは一例に過ぎない。この代わりに、Ｓ２０の判定結果がＹｅｓの場合に、ユーザに対して戻し処理を行うか否かを問い合わせ、その問い合わせに対してユーザから戻し処理の実行を指示された場合にのみ戻し処理を実行することとしてもよい。

以上に説明した図１０及び図１１の処理の具体例を、図１２を参照して説明する。図１２に例示するフローバー１１００は、ボタンＡ～Ｇをこの順に並べたものである。この例ではボタンＡの実行はオンライン期間中に済んでいたが、その後クライアント１００はサーバ２００とオフライン状態となり、オフライン期間中にボタンＢ～Ｅが実行されている。図１２において、Ｂ、Ｃ、Ｄ、Ｅの隣に括弧書きで示される「有」、「無」は、当該ボタンの「編集有無」の値である。このオフライン期間中に、フローバー１１００のボタンＣとＤの間にボタンαが追加されたとする。そして現在、すなわちボタンＥが実行済みとなった後、ボタンＦが実行される前の時点で、クライアント１００がサーバ２００に対してオンライン状態に戻ったとする。このとき、プロセッサ１０２により図１０及び図１１の手順が実行される。

この時点で、クライアント１００が持っているフローバー１１００はボタンα追加前の状態であるのに対し、サーバ２００が持っているフローバー１１００はボタンαが追加されたものである。したがって、図１０のＳ１２の判定結果はＹｅｓとなる。次にプロセッサ１０２は、Ｓ１４で、クライアント１００内の履歴情報１３０と、サーバ２００から取得した履歴情報２３０を突き合わせることにより、そのオフライン期間中にボタンＢ～Ｅが実行されたことを認識する。追加されたボタンαが「変更ボタン」であり、その変更ボタンより後に、オフライン期間中の実行済みボタンＤ及びＥがあるので、Ｓ１６の判定結果はＹｅｓとなる。

Ｓ１８でプロセッサ１０２は、変更ボタンα及びその後の実行済みボタンＤ及びＥの属性「編集有無」の値をチェックする。この場合、ボタンＥの属性「編集有無」の値が「有」なので、Ｓ２０の判定結果はＹｅｓとなる。Ｓ２２でプロセッサ１０２は、そのボタンＥの実行による編集結果の文書を履歴情報１３０から特定し、その特定した文書について、Ｓ３０の処理を実行する。

Ｓ３０の処理では、プロセッサ１０２は、まずＳ３０２で戻し先ボタンを特定する。図１２の例では、変更ボタンである追加されたボタンαの直前のボタンＣの次のボタンであるボタンαを起点とする。この起点のボタンから後に向かって探索を行い、属性「編集有無」の値が「有」となる最初のボタンの直前のボタンを戻し先ボタンとする。

例えば追加されたボタンαの属性「編集有無」の値が「無」であれば、ボタンα以降で属性「編集有無」の値が「有」となる最初のボタンはボタンＥである。したがって、戻し先ボタンは、そのボタンＥの１つ前のボタンＤとなる。この場合、Ｓ３０４では、ボタンＥの実行による編集結果の文書が、戻し先であるボタンＤの実行直後、すなわちボタンＥの実行直前、の状態に戻される。この場合、Ｓ３０８での完了マーカの移動先はボタンＤであり、これはＳ３１０でサーバ２００にも反映される。

また、追加されたボタンαの属性「編集有無」の値が「有」であれば、Ｓ３０２において戻し先ボタンはボタンＣと判定される。この場合、Ｓ３０４では、ボタンＥの実行による編集結果の文書が、戻し先であるボタンＣの実行直後の状態に戻される。なお、ボタンＤの属性「編集有無」の値は「無」なので、文書のボタンＣの実行直後の状態は、その文書のボタンＥの実行直前の状態と同じである。この場合、Ｓ３０８での完了マーカの移動先はボタンＣであり、これはＳ３１０でサーバ２００にも反映される。

戻し処理（Ｓ３０）による文書取扱アプリケーションのＵＩ画面の変化の例を図１３に示す。図１３に示すウィンドウ１０００ａは、クライアント１００がオフライン状態からオンライン状態へと切り替わる直前の状態を示し、ウィンドウ１０００ｂはオンライン状態へ切り替わり、戻し処理を実行した直後の状態を示す。

戻し処理直前のウィンドウ１０００ａでは、メインペイン１０１０内の文書のアイコン１０１２が選択状態となっている。履歴情報１３０内で、その文書の文書ＩＤを含んだレコード群に含まれるバーＩＤが特定され、そのバーＩＤに対応するフローバー１１００Ａがウィンドウ１０００ａ内に表示されている。このフローバー１１００Ａは、ボタン１１０２、１１０６及び１１０８の３つをこの順に並べたものである。このフローバー１１００Ａは、オフライン期間中のものであり、サーバ２００上でのそのフローバー１１００Ａに対応する変更は未適用である。また、戻し処理直前の時点では、フローバー１１００Ａの最後のボタン１１０８まで実行が済んでおり、そのボタン１１０８の右肩に完了マーカ１１３０が表示されている。

図１３の例では、そのオフライン期間中にフローバー１１００Ａのボタン１１０２と１１０６の間に、ボタン１１０４が追加されている。追加されたボタン１１０４は、「承認印を押す」という処理を実行するボタンであり、対象となる文書の内容を編集するものである。すなわち、ボタン１１０４の属性「編集有無」の値は「有」である。

この場合、戻し処理では、そのボタン１１０４が起点から見て最初の編集「有」のボタンであり、戻し先ボタンはその直前のボタン１１０２となる。したがって、戻し処理直後のウィンドウ１０００ｂには、ボタン１１０４が追加されたフローバー１１００Ｂが表示され、完了マーカ１１３０は戻し先であるボタン１１０２の右肩に表示される。ユーザは、この完了マーカ１１３０を見て、ボタン１１０２までの実行が終わっていると認識し、次にボタン１１０４を実行すべきであることを知る。

また、戻し処理直前の時点で実行済みのボタン１１０６及び１１０８は、それぞれ「カタログと束ねる」処理、及び「セキュリティをかける」処理を示している。これらはいずれも文書に変更を加える処理であり、属性「編集有無」の値は「有」である。そこで、これらボタン１１０６及び１１０８の実行結果の文書を元の状態に戻す処理が行われる。この例では、まずボタン１１０８でセキュリティがかけられた文書（すなわちアイコン１０１２が示す文書「注文書」）が、セキュリティがかけられる前の状態に戻される。次に、そのセキュリティがかけられる前の状態の文書が、ボタン１１０６で束ねられる前の状態に戻される。図示例では、１つに束ねられた後の「注文書」が、「見積もり書をスキャン」ボタン１１０２の実行によるスキャン結果の文書「注文書」と、これに束ねられるカタログと、に分かれている状態に戻る。これにより、戻し処理後のウィンドウ１０００ｂは、ボタン１１０２の実行によるスキャン結果の文書「注文書」を示すアイコン１０１２ａと、これに束ねられるカタログを示すアイコン１０１２ｂとを表示した状態となる。

またこのウィンドウ１０００ｂには、メッセージ欄１０５２がポップアップ表示されている。このメッセージ欄１０５２には、フローバーを更新したこと、及び、フローバー内で再実行が必要な段階（すなわち戻し先ボタンの直後）まで文書の編集を戻したこと、を示すメッセージが表示される。

ユーザは、このメッセージ欄１０５２を見ることで、ウィンドウ１０００ｂのメインペイン１０１０はボタン１１０２の処理が終わった時点の状態を示しており、次にボタン１１０４から作業をやり直す必要があることを知る。

＜戻し処理後のボタンの自動実行＞
以上に説明した戻し処理の例では、完了マーカ１１３０が戻し先ボタンまで戻るので、戻し先ボタンの次のボタンから再度実行し直す必要があった。

しかし、フローバー１１００内のボタンの中には、その実行に際してユーザの介入が不要なものがある。

例えば、文書をＰＤＦ形式へと変換するコマンドを表すボタンがその一例である。そのボタンが押下された場合に実行されるそのコマンドの処理の内容は既定のものであり、そのボタンの押下以外にユーザが介入する必要はない。また、文書をページ単位にばらすコマンドを表すボタンもその一例である。ページ単位にばらす処理にはユーザの介入が不要である。また、文書内の特定の位置に特定のアノテーションを追加する処理を表すボタンも、その一例である。そのボタンが押下されると、そのボタンの設定内容に従い、文書内の特定の位置に特定のアノテーションが追加されるので、ユーザの介入は不要である。

このように実行に際してユーザの介入が不要なボタンに関しては、戻し処理の後で、文書取扱アプリケーションが自動的に実行することが可能である。このような自動実行を行うと、ユーザが手作業でボタンを押し直す手間が省かれる。

逆に、実行に際してユーザの介入が必要なボタンには、自動実行は適用しない。実行に際してユーザの介入が必要なボタンの例としては、文書に対してユーザがコメントを入力するコマンドを示すボタンがある。このボタンが押下されると、その文書が開かれてアノテーションが入力可能な状態となり、ユーザはその文書を読んで思いついたコメントをアノテーションとしてその文書に追加する。また、そのようなボタンの別の例として、設定されているメモを表示するボタンがある。メモの表示はユーザに読ませるために行われる。すなわち、そのボタンの実行には、「読む」というユーザの介入が必要である。また、更に別の例として、文書に対してユーザが名前を付けて保存するというコマンドを表すボタンがある。このボタンの実行に際し、ユーザは、文書の名前を入力するという介入を行う。更に別の例として、文書に追加されているアノテーションをユーザの指定した別の文書にコピーするというコマンドを表すボタンがある。この例では、ユーザは、アノテーションのコピー先の文書を指定するという形の介入を行う。

戻し処理後のボタンの自動実行を実施するために、ボタン管理情報１１０及び２１０は、図１４に例示するように「自動実行可否」の属性を含む。実行に際してユーザの介入が不要なボタンはこの属性の値が「可」に設定され、実行に際してユーザの介入が必要なボタンはこの属性の値が「不可」に設定される。この属性の値は、例えば当該ボタンを作成したユーザが設定する。

図１５に、ボタンの自動実行を含む戻し処理の手順を例示する。図１５に示す手順は、図１０の手順における戻し処理（Ｓ３０）の詳細な手順の二番目の例である。図１５の手順のうちＳ３０２～Ｓ３０８までは、図１１の手順の同符号のステップと同内容の処理を表す。

図１５の手順では、プロセッサ１０２は、Ｓ３０８の後、図１１に示したＳ３１０ではなく、Ｓ３１２～Ｓ３２４のステップ群を実行する。

すなわちプロセッサ１０２は、Ｓ３０８の後、注目バー内の戻し先ボタンの次のボタンを対象とし（Ｓ３１２）、ボタン管理情報１１０におけるその対象のボタンの属性「自動実行可否」の値が「可」であるか否かを判定する（Ｓ３１４）。この判定の結果がＹｅｓの場合、プロセッサ１０２は、その対象ボタンが表す処理を自動実行する（Ｓ３１６）。例えば対象ボタンが、そのボタンに設定された承認印の画像を文書の所定の位置に追加する処理を示す場合、戻し先ボタンの実行直後の状態に戻った文書の所定の位置にその承認印の画像を追加する。またプロセッサ１０２は、その対象ボタンを実行したことを示す履歴のレコードを履歴情報１３０に追加すると共に、完了マーカ１１３０の位置をその対象ボタンに移動する（Ｓ３１８）。そして、プロセッサ１０２は、注目バー内の順序で、現在の対象ボタンの次のボタンを新たな対象ボタンとし（Ｓ３２０）、その新たな対象ボタンが当該ジョブにおいて実行済みのボタンであるか判定する（Ｓ３２２）。Ｓ３２２の判定結果がＹｅｓの場合は、プロセッサ１０２は、Ｓ３１４以降の処理を繰り返す。Ｓ３２２の判定結果がＮｏの場合は、対象ボタンは、当該ジョブにおいてユーザが未だ実行していないボタンなので、これについては自動実行は行わない。この場合、プロセッサ１０２はＳ３２４の処理に進む。

対象とするボタンを１つずつ移動しながらＳ３１４からＳ３２２の処理を繰り返していくと、いずれＳ３１４又はＳ３２２の判定結果がＮｏとなる。この場合、プロセッサ１０２は、Ｓ３１６で自動実行した各ボタンについての実行履歴のレコードをサーバ２００に送信する（Ｓ３２４）。

それらレコード群を受け取ったサーバ２００は、それらレコード群を履歴情報２３０に反映する。すなわち、サーバ２００は、受け取ったレコード群に含まれるジョブＩＤと同じジョブＩＤを含んだレコード群を履歴情報２３０から探索する。次に、この探索により見つけた履歴情報２３０内のレコード群のうち、その受け取ったレコード群と同じボタンＩＤを持つレコードを、受け取ったレコード群に置き換える。また、その探索により見つけた履歴情報２３０内のレコード群のうち、その受け取ったレコード群における最後のボタンより順序が後のボタンの実行履歴を示すレコードは、履歴情報２３０から削除する。これにより、サーバ２００内の履歴情報２３０が、クライアント１００側での自動実行が完了したときの状態を示すものとなる。

ボタンの自動実行を含む戻し処理を実行した後に、文書取扱アプリケーションが提供するウィンドウ１０００の例を図１６及び図１８に例示する。いずれの例も、図１３に示す例と同じく、戻し処理の実行前には図１３に示すウィンドウ１０００ａが表示されており、オフライン期間中にフローバー１１００Ａに対してボタン１１０４が追加されたものとする。

図１６の例は、追加されたボタン１１０４、及びその後に続くボタン１１０６及び１１０８のすべての属性「自動実行可否」の値が「可」である場合のものである。この場合、Ｓ３０８でボタン１１０２まで完了マーカ１１３０が戻された後、その後のボタン１１０４、１１０６及び１１０８が自動実行される。この自動実行後のウィンドウ１０００では、ボタン１１０８の右肩に完了マーカ１１３０が表示される。またそのウィンドウ１０００のメインペイン１０１０内には、承認印の押下、カタログとの束ね、及びセキュリティをかける処理がその順に自動実行された結果得られた文書のアイコン１０１２が表示される。またこのウィンドウ１０００には、メッセージ欄１０５４がポップアップ表示されている。このメッセージ欄１０５４には、フローバーを更新したこと、及び、フローバー更新後のボタンの自動実行によりそのフローバーの最後のボタンまで実行が完了したこと、を示すメッセージが表示される。

また、メッセージ欄１０５４には、詳細ボタン１０５６が示される。ユーザがその詳細ボタン１０５６を押下すると、プロセッサ１０２は、そのフローバーの更新の内容を示す詳細画面を表示する。図１７に、その詳細画面の表示内容を例示する。図１７に例示する詳細画面には、そのフローバーが含む各順番のボタンごとに、そのボタンの画像、変更履歴、及び自動実行の履歴が示される。このうち変更履歴は、今回のフローバーの更新によって当該ボタンが変更されたか否か、及び変更された場合にはその変更の種類を示す。例えば、１番目のボタン「見積もり書スキャン」の変更履歴の値は「変更なし」であるのに対し、２番目のボタン「承認印を押す」は今回の更新で追加されたものなので、変更履歴の値は「追加」である。また、自動実行の履歴の欄には、当該ボタンのフローバー内での順序が戻し先ボタン以前であれば「不要」という値が表示される。また、当該ボタンの順序が戻し先ボタンより後である場合、当該ボタンを自動実行したならば、自動実行の履歴の欄には「自動実行済み」という値が表示される。図１６及び図１７の例では、フローバーの２番目から最後の４番目までのボタンについて「自動実行済み」と表示される。ユーザは、この詳細表示を見ることで、どのボタンが自動実行されたかを知る。

図１８の例は、追加されたボタン１１０４とその次のボタン１１０６は属性「自動実行可否」の値が「可」であるが、最後のボタン１１０８は属性「自動実行可否」の値が「不可」である場合のものである。この場合、Ｓ３０８でボタン１１０２まで完了マーカ１１３０が戻された後、ボタン１１０４及び１１０６は自動実行されるが、最後のボタン１１０８は自動実行されない。図１７に示すこの自動実行の後のウィンドウ１０００では、自動実行された最後のボタン１１０６の右肩に完了マーカ１１３０が表示される。またそのウィンドウ１０００のメインペイン１０１０内には、承認印の押下、及びカタログとの束ねがその順に自動実行された結果得られた文書のアイコン１０１２が表示される。その文書に対しては、セキュリティはかけられていない。またこのウィンドウ１０００には、メッセージ欄１０６０がポップアップ表示されている。このメッセージ欄１０５４には、フローバーを更新したこと、及びボタンを自動実行したがフローの完了までに残作業があるため完了マーカ１１３０がついているボタンの次のボタンから作業を再開すべきこと、を示すメッセージが表示される。

ユーザが、メッセージ欄１０６０内の詳細ボタン１０６２を押下すると、プロセッサ１０２は、そのフローバーの更新の内容を示す詳細画面（図１９参照）を表示する。図１９に例示する詳細画面は、図１７に示した例に対して、４番目のボタンの自動実行の履歴の内容のみが異なる。すなわち、この例では、４番目のボタンは自動実行されなかったので、自動実行の履歴の値は「手動実行する必要があります」となっている。ユーザは、この詳細表示を見ることで、４番目のボタンが自動実行されなかったので、手動でボタンを押す必要があることを知る。

図１５の手順でボタンの自動実行を行った場合において、例えばＳ３１４又はＳ３２２の判定結果がＮｏとなったときに、プロセッサ１０２は、それら一連の自動実行の結果得られた文書を画面に表示し、その文書が受け入れ可能かどうかユーザに問い合わせてもよい。この問合せに対してユーザが受け入れ可能の旨を回答した場合、プロセッサ１０２は、それら一連の自動実行を有効なものとする。この場合、自動実行の履歴のレコードは有効なものとして履歴情報１３０及び２３０に残り、自動実行の結果得られた文書も有効なものとしてクライアント１００又はサーバ２００に保存される。逆に、その問合せに対してユーザが受け入れ不可の旨を回答した場合、プロセッサ１０２は、履歴情報１３０からそれら一連の自動実行の履歴のレコードを削除し、文書の状態を戻し先ボタンの実行直後の状態（すなわち一連のボタンの自動実行が行われる前の状態）に戻す。この場合、サーバ２００にも、この戻し先ボタンの実行直後の状態が反映される。

＜処理手順の別の例＞
以上に説明した例では、変更ボタンの「編集有無」属性が編集「有」か否かによらず、フローバーにおけるボタンの実行状態を戻し先ボタンの実行直後まで戻す処理（以下「手戻り処理」と呼ぶ）を実行した。しかし、これは一例に過ぎない。

別の例として、変更ボタンの属性「編集有無」が編集「有」である場合にのみ、そのような手戻り処理を実行する手順を、図２０に例示する。図２０のうち、図８の手順のステップと同内容の処理を行うステップには、同じ符号を付した。

図２０の手順では、Ｓ１６の判定結果がＹｅｓである場合、プロセッサ１０２は、変更ボタンの属性「編集有無」が編集「有」であるか否かを判定する（Ｓ４０）。この判定の結果がＮｏの場合は、手戻り処理を実行せず、サーバ２００から得た注目バーの変更を、当該クライアント１００内のバー管理情報１２０内の注目バーの情報に反映する（Ｓ２６）。一方、Ｓ４０の判定結果がＹｅｓの場合は、プロセッサ１０２は、Ｓ４２及びＳ４４に示す手戻り処理を実行する。すなわち、プロセッサ１０２は、フローバー内の並び順において変更ボタン以降の各実行済みボタンの中から編集「有」のボタンを特定し、特定したボタンの実行結果の文書を特定する。そして、それら特定した文書を、変更ボタンの実行直前の状態（すなわち、変更ボタンの直前のボタンの実行直後の状態）に戻す（Ｓ４２）。また、プロセッサ１０２は、完了マーカ１１３０の位置を変更ボタンの直前のボタンに移動させると共に、履歴情報１３０内の変更ボタン以降の各ボタンについての履歴のレコードを削除する（Ｓ４４）。そして、プロセッサ１０２は、サーバ２００から得た注目バーの変更を、当該クライアント１００内のバー管理情報１２０内の注目バーの情報に反映する（Ｓ２６）。

図２０の手順は、図１０及び図１１に示した手順に対する１つの変形例である。図８に示した手順にも、図１０及び図１１の手順に対する図２０の手順の変形と同様の変形を加えることも可能である。

また、以上に説明した実施形態は、ある機能（例えばフローバー１１００）が含む部分機能（例えばフローバー１１００内の個々のボタン）に変更があった場合を対象とするものであった。しかし、例えば単一のボタンのみを含むフローバー１１００において、そのボタンが示すコマンドの処理内容が変更された場合にも上記実施形態で説明した処理手順は適用可能である。すなわち、単一の機能が変更された場合にも、上記実施形態と同様の考え方で、変更前のその機能により処理された文書等のデータを特定する情報を表示したり、それら文書等のデータをその機能による処理が施される前の状態に戻したりすることができる。また、この場合に、その機能の「自動実行可否」属性が「可」である場合に、変更間のその機能による処理が施される前の状態に戻したデータに対して、変更後のその機能による処理を自動実行してもよい。

以上に説明した実施形態はあくまで例示的なものにすぎない。本発明の範囲内で様々な変形があり得る。

１０２ プロセッサ、１０４ メモリ、１０６ 補助記憶装置、１０７ 入出力装置、１０８ ネットワークインタフェース、１０９ バス、１１０，２１０ ボタン管理情報、１２０，２２０ バー管理情報、１３０，２３０ 履歴情報、１０００，１０００ａ，１０００ｂ ウィンドウ、１０１０ メインペイン、１０１２、２００ サーバ、１０１４ アイコン、１０２０ ツールバー、１０５０，１０５２，１０５４，１０６０ メッセージ欄、１１００，１１００Ａ，１１００Ｂ フローバー、１１０２～１１０８ ボタン、１１３０ 完了マーカ。

Claims (10)

1. プロセッサを備え、
   前記プロセッサは、
   他装置と通信を行い、
   前記他装置で行われた、データに処理を行う機能に対する変更を受け付け、
   前記変更を、自装置が持つ前記機能に反映させ、
   前記他装置と通信を行っていない期間に、ユーザからの指示に従って、自装置が持つ第１の機能に係る処理を第１のデータに対して実行し、
   前記第１の機能に係る処理を前記第１のデータに対して実行した後、前記他装置と通信を行ったときに、前記第１の機能に対する変更を前記他装置から受け付けた場合に、前記第１のデータを特定する情報を表示する、
   ことを特徴とする情報処理装置。
2. 前記プロセッサは、更に、
   前記第１のデータに対して前記第１の機能に係る処理を実行した後、前記他装置と通信を行ったときに、前記第１の機能に対する変更を前記他装置から受け付けた場合に、前記第１のデータを前記第１の機能に係る処理の実行前の状態に戻す戻し処理を実行する、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記プロセッサは、
   前記戻し処理の後の前記第１のデータに対して、前記変更を反映した後の前記第１の機能に係る処理を実行する、
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記第１の機能は、順序が規定された複数の部分機能から構成され、
   前記第１の機能に対する変更は、前記第１の機能を構成する複数の部分機能のうちのいずれかの部分機能の変更又は削除、又は前記第１の機能に対する部分機能の追加であり、
   前記プロセッサは、更に、
   前記期間における１以上の前記部分機能の実行の後、前記他装置と通信を行ったときに、前記第１の機能に対する変更を前記他装置から受け付けた場合に、前記第１のデータを、前記順序において、該変更にて前記第１の機能のうち変更又は削除又は追加された前記部分機能、の直前の部分機能以降の所定条件を満たす部分機能が実行されたときの状態に戻す戻し処理、を実行する、
   ことを特徴とする請求項１に記載の情報処理装置。
5. 前記部分機能の各々には編集有無属性が設定されており、前記編集有無属性は、当該部分機能の実行により前記第１のデータに編集が加えられる可能性があるか否か示す属性であり、
   前記所定条件は、前記変更において前記第１の機能のうち変更又は削除又は追加された前記部分機能、の直前の部分機能以降の部分機能のうち、編集が加えられる可能性があることを示す前記編集有無属性を持つ、前記順序において最初の部分機能の直前の部分機能であること、である請求項４に記載の情報処理装置。
6. 前記第１のデータに対して前記第１の機能に係る処理を実行した後、前記他装置と通信を行ったときに、前記第１の機能に対する変更を前記他装置から受け付けた場合に、前記第１のデータの状態を戻すか否かをユーザに問い合わせ、前記ユーザが戻す旨の指示を行った場合に、前記戻し処理を実行する、請求項２項に記載の情報処理装置。
7. 各部分機能には、前記戻し処理の後に当該部分機能の自動実行を許可するか否かが設定されており、
   前記プロセッサは、
   前記戻し処理の後の前記第１のデータに対して、前記変更後の前記第１の機能を構成する複数の部分機能のうち、前記変更にて変更又は削除又は追加された前記部分機能以降の各部分機能を、自動実行を許可しないと設定されている部分機能、又は実行済みでない部分機能、のいずれかに達するまで、前記順序に従って実行する自動実行処理を行う、
   ことを特徴とする請求項４又は５に記載の情報処理装置。
8. 前記自動実行処理後の前記第１のデータを表示し、前記ユーザから表示した前記第１のデータを受け入れるかどうか問い合わせ、前記ユーザから受け入れの回答があった場合に、前記自動実行処理後の前記第１のデータを有効なものとして保存する、
   請求項７に記載の情報処理装置。
9. 前記プロセッサは、更に、
   ユーザからの指示に従って前記第１の機能の前記複数の部分機能のうちの１以上を実行した場合に、実行済みの部分機能の記録を行い、
   前記記録に基づき、前記順序においてユーザが次に実行を指示すべき部分機能が特定可能な表示を行い、
   前記戻し処理を実行した場合には、前記順序において、前記変更にて前記第１の機能のうち変更又は削除又は追加された前記部分機能、の直前の部分機能以降の前記所定条件を満たす部分機能の次の部分機能を、前記順序においてユーザが次に実行を指示すべき部分機能として特定可能な表示を行う、
   請求項４、５、７又は８のいずれか１項に記載の情報処理装置。
10. コンピュータに、
    他装置と通信を行い、
    前記他装置で行われた、データに処理を行う機能に対する変更を受け付け、
    前記変更を、自装置が持つ前記機能に反映させ、
    前記他装置と通信を行っていない期間に、ユーザからの指示に従って、自装置が持つ第１の機能に係る処理を第１のデータに対して実行し、
    前記第１の機能に係る処理を前記第１のデータに対して実行した後、前記他装置と通信を行ったときに、前記第１の機能に対する変更を前記他装置から受け付けた場合に、前記第１のデータを特定する情報を表示する、
    という処理を実行させるためのプログラム。

Images