JP2010035151A - データ送信装置、送信制御方法及びプログラム - Google Patents

Abstract

【課題】データの送信に用いた情報を更新することにより、データを送信したことを、その情報を用いて把握することを可能とする。
【解決手段】画像処理装置１０１は、データの送信先を含む情報をネットワーク上の提供装置から取得し、取得された情報に従って送信先にデータを送信する。また、画像処理装置１０１は、データの送信時に、情報の更新を提供装置に要求する。
【選択図】図１

Description

本発明は、データを送信したことを把握するための技術に関するものである。

従来、デジタル複合機（ＭＦＰ）を用いてスキャンしたデータを送信するようなサービスがある。その際には、出張清算等一つの送信作業に対して一つのジョブが発行される。また、送信先に格納されている自分のデータを問い合わせて表示し、閲覧することは可能である。さらに、作業する内容を記述した指示書を作成したり、更新したりすることが簡単に実現可能な技術がある(例えば、特許文献１参照)。

特開２００７−４８００９号公報

しかしながら、一つの送信作業に対して一つのジョブが発行されるため、ユーザが送信したいデータが複数存在した場合は、一度に複数のデータの送信作業を行わなければならない。場合によっては、何日かに分けて複数のデータを送信した方が便利な場合もある。例えば、出張清算等は、３日間の出張期間のうち、１日目の交通費だけをその日のうちにとりあえず送信しておくことができるほうが便利である。そのためには、日にち毎に発行されるジョブを分けることも考えられるが、そうすると処理が煩雑になる。

そこで、本発明の目的は、データの送信に用いた情報を更新することにより、データを送信したことを、その情報を用いて把握することを可能とすることにある。

本発明のデータ送信装置は、データを送信するデータ送信装置であって、前記データの送信先を含む情報をネットワーク上の提供装置から取得する取得手段と、前記取得手段により取得された情報に従って前記送信先にデータを送信する送信手段と、前記送信手段によるデータの送信時に、前記情報の更新を前記提供装置に要求する要求手段とを有することを特徴とする。

本発明によれば、データの送信に用いた情報を更新することにより、データを送信したことを、その情報を用いて把握することが可能となる。

本発明の実施形態におけるシステム全体の構成を示す図である。 画像処理装置の機能的な構成を示すブロック図である。 チケットサーバから取得されるスキャンチケット、及び、画像処理装置において編集したスキャンチケットの一例を示す図である。 チケットサーバから取得されるスキャンチケット、及び、画像処理装置において編集したスキャンチケットの一例を示す図である。 画像処理装置のスキャンデータ送信処理部における処理の流れを示すフローチャートである。 画像処理装置のスキャンデータ送信処理部における処理の流れを示すフローチャートである。 画像処理装置のスキャンデータ送信処理部における処理の流れを示すフローチャートである。 画像処理装置のスキャンデータ送信処理部における処理の流れを示すフローチャートである。 スキャンチケットの最終処理者と次の処理者の情報を追加記述した例、及び、スキャンチケットの最終処理者と次の処理者の情報を変更した例を示す図である。 画像処理装置のチケット編集部における処理の流れを示すフローチャートである。

以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。

先ず、本発明の第１の実施形態を説明する。図１は、本発明の第１の実施形態におけるシステム全体の構成を示す図である。

１０１は、画像処理装置であり、ネットワーク上に設けられる後述するチケットサーバ１０２や送信先１０４とやり取りを行うデータ送信装置として機能する。１０２は、チケットサーバであり、後述するスキャンチケットをユーザ毎に格納し管理している。１０３は、チケットサーバ１０２に格納されているスキャンチケットであり、スキャンした画像（スキャンチケット）を格納するための情報が記述されている。１０４は、後述するスキャンデータの送信先となる例えばデータベース（ＤＢ）であり、送信されたデータを格納する。１０５は、画像処理装置１０１のスキャン処理により生成されたスキャンデータである。１０６は、画像処理装置１０１によって編集された編集済みスキャンチケットである。スキャンチケット１０３、１０６は、データ処理情報である。

図２は、画像処理装置１０１の機能的な構成を示すブロック図である。図２に示すように、画像処理装置１０１は、スキャンデータ送信処理部２０１、ジョブ実行処理部２０２、スキャン処理部２０３から構成されている。

スキャンデータ送信処理部２０１は、チケットサーバ１０２からスキャンチケット１０３を受け取り、送信先１０４にスキャンしたスキャンデータ１０５を格納する。また、スキャンデータ送信処理部２０１は、必要に応じてスキャンチケット１０３を編集し、編集したスキャンチケット１０６をチケットサーバ１０２に送信し、更新を要求する。このスキャンチケット１０６には、送信先情報、用紙のサイズ及び解像度等のスキャン設定情報が記述されている。スキャンデータ送信処理部２０１の詳細は更に後述する。

ジョブ実行処理部２０２は、スキャンデータ送信処理部２０１から指示を与えられ、スキャン処理部２０３にジョブを実行させる。スキャン処理部２０３は、紙媒体上に記録される情報を読み取り、電子化するスキャン処理を実行する。

スキャンデータ送信処理部２０１において、２１１はチケット取得部であり、チケットサーバ１０２からユーザのスキャンチケット１０３を取得する。即ち、チケットサーバ１０２は、スキャンチケットを画像処理装置１０１に対して提供する提供装置として機能する。２１２はチケット解析部であり、チケット取得部２１１から渡されたスキャンチケット１０３の中身を解析する。２１３は格納場所特定部であり、チケット解析部２１２から渡されたスキャンチケット１０３の解析結果とユーザの更新及び追加指示とを基にファイル名を決定する。そして、格納場所特定部２１３は、後述するスキャン命令部２１４にスキャン設定情報を、後述するデータ送信部２１５に送信先情報とファイル名とを渡す。

２１４は、スキャン命令部であり、格納場所特定部２１３から渡されたスキャン設定情報を基にジョブ実行処理部２０２にスキャンを要求する。２１５は、データ送信部であり、格納場所特定部２１３から渡された送信先情報を基に、スキャン命令部２１４から渡されたスキャンデータ１０５を送信先１０４に格納する。２１６は、チケット編集部であり、格納場所特定部２１３からスキャンチケット１０３の編集を要求された場合に、スキャンチケット１０３の編集を行う。２１７は、チケット更新部であり、チケット編集部２１６から受け取った編集済みスキャンチケット１０６をチケットサーバ１０２に送信し、元のスキャンチケット１０３の更新を要求する。

図３（Ａ）は、チケットサーバ１０２から取得されるスキャンチケット１０３の一例を示す図である。図３は、送信先１０４がユーザの会社における出張清算ＤＢであり、ユーザが出張清算を行った場合のスキャンチケット１０３の例を示している。

ユーザは、自分の処理するべき出張清算のスキャンチケット１０３をチケットサーバ１０２に問い合わせ、スキャンチケット１０３を取得する。３０１は、スキャンチケット１０３の名前であり、ここでは、Yamada_出張清算となっている。３０２は、スキャンチケットＩＤであり、Yamada_出張清算における一意のＩＤ情報である。３０３は、スキャン設定情報であり、３０４でカラー、モノクロの設定を、３０５で画像のフォーマットを指定する。ここでは、カラーでＪＰＧの形式でスキャンすることが記述してある。３０６は、出張清算の項目である。ここでは、２つの項目が記述されている。３０７は、宿泊費のカテゴリーを示す宿泊費項目であり、出張清算の項目の１つである。宿泊費項目においては、名前が宿泊費(name=宿泊費)で、最大格納ファイル数は１であること(data_max=1)が記述してある。３０８は、交通費のカテゴリーを示す交通費項目であり、出張清算の項目の１つである。交通費項目においては、名前が交通費(name=交通費)で、最大格納ファイル数に上限がないこと(data_max=unlimited)が記述してある。３０９は、格納場所であり、ディレクトリ名までが記述されている。

図３（Ｂ）は、図３（Ａ）のスキャンチケット１０３を画像処理装置１０１において編集したスキャンチケット１０６の一例を示す図である。図３（Ｂ）では、ユーザが宿泊費データを新規に格納した場合のスキャンチケット１０６の例を示している。図３（Ａ）に示すスキャンチケット１０３と図３（Ｂ）に示すスキャンチケット１０６との異なる点は、４０１の記述箇所である。４０１は、送信先１０４に格納した宿泊費データの識別子としてのファイル名の記述であり、宿泊費項目３０７に追加で記述されている。また、４０１には、属性として、格納した日付又は日時の情報が付加されている(date=2007/5/12)。

図４（Ａ）は、チケットサーバ１０２から取得されるスキャンチケット１０３の一例を示す図である。図４（Ａ）は、図３（Ｂ）のスキャンチケット１０３に、さらに、ユーザが交通費データを送信した際に編集され、チケットサーバ１０２に保存された場合の例を示している。図３（Ｂ）に示すスキャンチケット１０６と図４（Ａ）に示すスキャンチケット１０３との異なる点は、５０１、５０２の記述箇所である。

５０１は、送信先１０４に格納された交通費データのファイル名が記述されており、交通費項目３０８に追加されている。また、その属性として、格納された日時（格納時期）の情報が付加されている(date=2007/5/12)。同様に、５０２も送信先１０４に格納された交通費データのファイル名が記述されており、交通費項目３０８に記述されている。また、その属性として、格納された日時（格納時期）の情報が付加されている(date=2007/5/14)。

図４（Ｂ）は、図４（Ａ）のスキャンチケット１０３を画像処理装置１０１において編集したスキャンチケット１０６の一例を示す図である。図４（Ｂ）では、ユーザが交通費データの更新と新規追加を行った場合のスキャンチケット１０６を示している。図４（Ａ）のスキャンチケット１０３と図４（Ｂ）のスキャンチケット１０６との異なる点は、６０１、６０２の記述箇所である。

６０１は、送信先１０４に既に格納されている交通費データ0002.jpg（５０２）を更新した場合の記述であり、属性の日時が変化している(date=2007/5/16)。６０２は、新たに追加した交通費データであり、交通費項目３０８に追加されている。また、その属性として、格納した日時の情報が付加されている(date=2007/5/16)。

図５〜図８は、画像処理装置１０１のスキャンデータ送信処理部２０１における送信制御処理の流れを示すフローチャートである。

図５に示すように、ユーザがログインした際に、チケット取得工程に処理が移る(Ｓ７０１)。チケット取得工程において先ずチケット取得部２１１は、チケットサーバ１０２に、ログインしたユーザのスキャンチケット１０３が存在するかを問い合わせ、チケットサーバ１０２から応答を受け取る(Ｓ７０２)。

続いて、チケット取得部２１１は、チケットサーバ１０２から受け取った応答を元に、チケットサーバ１０２に当該ユーザのスキャンチケット１０３が存在するか否かを判定する（Ｓ７０３）。スキャンチケット１０３が存在すれば(Ｓ７０３／ＹＥＳ)、チケット取得部２１１は、当該ユーザのスキャンチケット１０３をチケットサーバ１０２から取得する(Ｓ７０４)。一方、スキャンチケット１０３が存在しなかった場合(Ｓ７０３／ＮＯ)、そこで処理は終了する。例えば、チケットサーバ１０２の名前がDBで、ユーザのスキャンチケットがYamadaフォルダに格納されている場合は、DB/Yamadaフォルダにあるスキャンチケットが取得される。

チケット取得部２１１は、取得したスキャンチケット１０３のうち、当該ユーザが処理を実行するスキャンチケット１０３を選択する(Ｓ７０５)。この選択のために、チケット取得部２１１は、取得したスキャンチケット１０３のチケット名を画像処理装置１０１の不図示の操作部に表示し、ユーザによるスキャンチケット１０３の選択を受け付ける。続いて、チケット取得部２１１は、選択されたスキャンチケット１０３をチケット解析部２１２に渡す(Ｓ７０６)。

そして、処理がチケット解析工程に移る(Ｓ７０７)。チケット解析工程においてチケット解析部２１２は、取得したスキャンチケット１０３の解析を行う(Ｓ７０８)。スキャンチケット１０３には、スキャン設定情報と送信先情報とが記述されている。チケット解析部２１２は、スキャンチケット１０３の解析後、スキャンチケット１０３と解析した情報を格納場所特定部２１３に渡す(Ｓ７０９)。

そして、図６に示すように、処理は格納場所特定工程に移る(Ｓ７１０)。まず、スキャンチケット１０３に含まれる項目名を表示し、ユーザがデータを処理する項目を選択する。この表示される処理項目は、図３（Ａ）の３０７、３０８に記述されていた宿泊費、交通費の一方である。ユーザがデータを処理する項目を選択すると、選択された項目名の情報は、格納場所特定部２１３に入力される(Ｓ７１１)。

続いて、格納場所特定部２１３は、スキャン命令部２１４にチケット解析部２１２から渡されたスキャン設定情報を渡す(Ｓ７１２)。また、格納場所特定部２１３は、スキャンチケット１０３内のユーザにより選択された処理項目（宿泊費または交通費）に、既に送信したファイルの記述があるかを調べる(Ｓ７１３)。

もし、既に送信されたファイルの記述がなければ（Ｓ７１３／ＮＯ）、格納場所特定部２１３は、新規にファイル名を生成する（Ｓ７１４）。続いて、格納場所特定部２１３は、ファイル名を生成したファイル名にして、データ送信部２１５にそのファイル名と格納場所３０９とを通知する（Ｓ７１５）。

一方、処理項目に既に送信されたファイルの記述があれば(Ｓ７１３／ＹＥＳ)、格納場所特定部２１３は、記述されている最大格納ファイル数を調べる(Ｓ７１６)。最大格納ファイル数は、図３（Ａ）の３０７、３０８に記述されていたdata_maxの数値である。最大格納ファイル数が１であれば(Ｓ７１６／ＹＥＳ)、ファイル名を既に記述されているファイル名にして、データ送信部２１５にそのファイル名と格納場所３０９とを通知する(Ｓ７１５)。この場合は、送信済みのファイルは更新される。一方、最大格納ファイル数が１でなければ(Ｓ７１６／ＮＯ)、格納場所特定部２１３は、不図示の操作部を介して、ユーザに更新を要求するか否かを問い合せる（Ｓ７１７）。

ユーザが更新を要求する場合(Ｓ７１７／ＹＥＳ)、格納場所特定部２１３は、スキャンチケット１０３に記述されている、処理項目に既に格納されている全てのファイル情報を操作部に表示する(Ｓ７１８)。従って、ここではデータ送信処理によって編集対象となる処理項目の全てのファイル情報が表示されることになる。

続いて、格納場所特定部２１３は、ユーザが更新するファイルを操作部で選択したか否かを判定する（Ｓ７１９）。ユーザが更新するファイルを選択した場合（Ｓ７１９／ＹＥＳ）、格納場所特定部２１３は、ファイル名をユーザが選択したファイル名にして、データ送信部２１５にそのファイル名と格納場所３０９とを通知する（Ｓ７１５）。一方、ユーザが更新するファイルを選択していない場合（Ｓ７１９／ＮＯ）、格納場所特定部２１３は、ユーザによる更新するファイルの選択を待つ。

一方、Ｓ７１７においてユーザが新規追加を要求したと判定された場合（Ｓ７１７／ＮＯ）、格納場所特定部２１３は、既に格納されているファイル名と異なるファイル名を生成する(Ｓ７２０)。続いて、格納場所特定部２１３は、データ送信部２１５にその生成したファイル名と格納場所３０９とを通知する(Ｓ７１５)。

次に、図７に示すように、処理はスキャン命令工程に移る(Ｓ７２１)。スキャン命令工程において先ずスキャン命令部２１４は、ユーザからスキャン指示があると、そのスキャン指示を受け付ける(Ｓ７２２)。

続いて、スキャン命令部２１４は、ジョブ実行処理部２０２にスキャン設定情報３０３を与えてスキャンを要求する(Ｓ７２３)。ジョブ実行処理部２０２は、紙媒体（原稿）上に記録される情報をスキャン設定情報３０３に示される条件に従って読み取り、スキャンデータ（原稿データ）１０５を生成する。続いて、スキャン命令部２１４は、ジョブ実行処理部２０２からスキャンデータ１０５を取得する(Ｓ７２４)。続いて、スキャン命令部２１４は、スキャンデータ１０５をデータ送信部２１５に渡す(Ｓ７２５)。

そして、処理はデータ送信工程に移る(Ｓ７２６)。データ送信工程において、先ずデータ送信部２１５は、スキャン命令部２１４から受け取ったスキャンデータ１０５を、格納場所特定部２１３から渡された送信先（格納場所３０９）１０４に送信する(Ｓ７２７)。

続いて、データ送信部２１５は、正常にスキャンデータ１０５が送信されたか否かを判定する（Ｓ７２８）。正常にスキャンデータ１０５が送信されなかった場合（Ｓ７２８／ＮＯ）、データ送信部２１５は、スキャンデータ１０５の送信に失敗したことをユーザに操作部を介して通知し、処理は終了する(Ｓ７２９)。一方、スキャンデータ１０５が正常に送信された場合（Ｓ７２８／ＹＥＳ）、データ送信部２１５は、格納場所特定部２１３にスキャンデータ１０５の送信の成功を通知する(Ｓ７３０)。

続いて、図８に示すように、処理は格納場所特定工程に移る(Ｓ７３１)。格納場所特定工程において先ず格納場所特定部２１３は、スキャンチケット１０３の編集が必要かどうかを判定する（Ｓ７３２）。スキャンチケット１０３の編集が必要でない場合（Ｓ７３２／ＮＯ）、処理は終了する。一方、スキャンチケット１０３の編集が必要である場合（Ｓ７３２／ＹＥＳ）、格納場所特定部２１３は、格納された項目のファイル名、格納日時及び元のスキャンチケット１０３をチケット編集部２１６に渡す(Ｓ７３３)。

そして、処理はチケット編集工程に移る(Ｓ７３４)。チケット編集工程において先ずチケット編集部２１６は、格納場所特定部２１３から渡された情報を基にスキャンチケット１０３の内容を編集する（Ｓ７３５）。即ち、チケット編集部２１６は、元のスキャンチケット１０３の内容を、上記格納された項目のファイル名、格納日時を用いて更新する。続いて、チケット編集部２１６は、チケット更新部２１７に編集したスキャンチケット１０６を渡す(Ｓ７３６)。

そして、処理はチケット更新工程に移る(Ｓ７３７)。チケット更新工程においてチケット更新部２１７は、チケットサーバ１０２にチケット編集部２１６から渡された編集済みスキャンチケット１０６を送信し、元のスキャンチケット１０３を更新することを要求する（Ｓ７３８）。即ち、チケット更新部２１７は、スキャンデータの送信時において、スキャンチケット１０３の更新を要求する。そして、処理は終了する。

次に、本発明の第２の実施形態について説明する。上述した第１の実施形態では、スキャンチケットに追加する情報として、送信したデータの格納場所と送信日時とを例に挙げて説明した。しかし、それ以外にも、現在の処理状態をスキャンチケットに記述しておき、その状態に応じて、処理を行う相手を変更することも可能である。そこで、本発明の第２の実施形態では、現在の処理状態をスキャンチケットに記述する場合について説明を行う。以下、本発明の第２の実施形態を、図９〜図１０を参照しながら説明する。なお、本発明の第２の実施形態では、第１の実施形態と同様の箇所については説明しない。

図９（Ａ）は、図４（Ｂ）に示すチケットサーバ１０２から取得されるスキャンチケットに現在の処理状態を追加記述した例を示す図である。８０１のmodeのテキスト部分には現在の処理者が記述してある。図９（Ａ）では、「清算処理者」と示しており、処理清算者が処理を行っていることを表している。また、modeのapproverID属性には、次の処理者である承認者を識別するためのＩＤ（１０９８８）が記述されている。

なお、mode要素のapproverID属性に記述された識別IＤは、次の処理者を特定できるものであればどのような情報でもよい。例えば、ユーザＩＤや社員番号などが考えられる。ユーザが自分の処理が終了した際、次の処理者に処理を回したい場合に、次の処理者を選択することで、スキャンチケットが自動的に編集される。これにより、このスキャンチケットはapproverID属性にマッチする承認者のチケットとなる。

このmode要素のapproverIDにマッチする承認者がスキャンチケットの取得を要求した際に、このスキャンチケットが取得できる。そして、３０６のcontents内に記述されているデータを取得し、承認するかどうかを判断する。承認された場合は、このスキャンチケットは消滅する。一方、却下された場合は、modeのapproverIDを再び処理清算者に変更し、処理が処理清算者に戻る。この際、何が問題で却下された等のコメントをスキャンチケットに追加記述し、処理清算者がスキャンチケットを取得した際に、その内容を表示することも可能である。

図９（Ｂ）は、処理が却下された場合のスキャンチケットの例である。図９（Ｂ）は図９（Ａ）のスキャンチケットにおいて、最終処理者（最後に処理を行った人）と次の処理者の情報が変更されている。すなわち、９０１のmode要素のテキスト部分には、最終処理者である承認者の識別ＩＤが記述してあり、approverID属性には処理清算者の識別ＩＤが記述されている。また、何が問題で却下された等の承認者からのコメントが９０２のようにチケットに追加記述され、処理清算者がチケットを取得した際に、その内容が表示されてもよい。

最後に、図３〜図４、及び図８〜図１０を用いて、チケット編集処理の詳細について説明する。図１０は、画像処理装置１０１のチケット編集部２１６における処理のフローチャートである。まず、ユーザが図３（Ａ）のスキャンチケットを取得し、宿泊費のデータを新規スキャンして送信する場合を考える。すなわち、宿泊費と交通費のうち、宿泊費を処理することが選択されている。この場合、格納場所特定部２１３によって、図３（Ａ）のスキャンチケットと、スキャンした項目名「宿泊費」、ファイル名「宿泊費.jpg」、格納日時「2007/5/12」がチケット編集部２１６に渡される(図８のＳ７３３)。

チケット編集部２１６は、まず、渡されたチケットである図３（Ａ）をパースし(Ｓ１００１)、name属性が「宿泊費」であるitem要素３０７を発見する(Ｓ１００２)。次に、チケット編集部２１６は、item要素内にすでに「宿泊費.jpg」と同じファイル名をもつfilename要素が存在するかを調べる(Ｓ１００３)。図３（Ａ）には存在しないので(Ｓ１００３／ＮＯ)、チケット編集部２１６は、date属性に格納日時「2007/5/12」、テキストにファイル名「宿泊費.jpg」をセットする(Ｓ１００６)。これにより、４０１の項目が情報としてセットされる。

次に、チケット編集部２１６は、ユーザが次の処理者を指定したか判断する(Ｓ１００７)。この処理は、ここで、ＮＯであると(Ｓ１００７／ＮＯ)、チケット編集部２１６は、チケットの書き出し処理を行ない(Ｓ１０１２)、編集されたチケットである図３（Ｂ）がチケット更新部２１７に渡される(図８のＳ７３６)。チケット更新部２１７は、編集済みスキャンチケットをチケットサーバ１０２に送信し、元のスキャンチケットの更新を要求する。ここでは、送信した宿泊費のデータの識別子である「宿泊費.jpg」が、送信したデータのカテゴリーを示す項目３０７に対応して追加されるように、チケットサーバ１０２に要求する。

次に、ユーザが図４（Ａ）のスキャンチケットを取得し、交通費のデータを更新及び追加スキャンして送信する場合を考える。この場合、「交通費」が選択されている。更に、更新するファイルとして「交通費0002.jpg」が選択され、追加されるファイルのファイル名として「交通費0003.jpg」が生成されている。まず、格納場所特定部２１３によって、図４（Ａ）のスキャンチケットと、スキャンした項目名「交通費」、ファイル名「交通費0002.jpg」、ファイル名「交通費0003.jpg」、格納日時「2007/5/16」がチケット編集部２１６に渡される(図８のＳ７３３)。

チケット編集部２１６は、まず、渡された図４（Ａ）のチケットをパースし(Ｓ１００１)、name属性が「交通費」であるitem要素３０８を発見する(Ｓ１００２)。次に、チケット編集部２１６は、item要素内にすでに「交通費0002.jpg」及び「交通費0003.jpg」と同じファイル名をもつfilename要素が存在するかを調べる(Ｓ１００３)。図４（Ａ）には、「交通費0002.jpg」のfilename要素５０２が存在する(Ｓ１００３／ＹＥＳ)。そのため、チケット編集部２１６は、５０２のdate属性の格納日時を「2007/5/16」に更新する(Ｓ１００４)。一方、「交通費0003.jpg」は存在しないので(Ｓ１００３／ＮＯ)、チケット編集部２１６は、date属性に格納日時「2007/5/16」、テキストにファイル名「交通費0003.jpg」をセットする(Ｓ１００６)。これにより、図４（Ｂ）に示すように、６０１と６０２の項目が情報としてセットされる。

次に、チケット編集部２１６は、ユーザが次の処理者を指定したか判断する(Ｓ１００７)。ＮＯであると(Ｓ１００７／ＮＯ)、チケット編集部２１６は、チケットの書き出し処理を行ない(Ｓ１０１２)、編集された図５（Ｂ）のチケットがチケット更新部２１７に渡される(図８のＳ７３６)。

次に、ユーザが自分の処理を終了し、次の処理者に処理を渡す場合を考える。この場合、チケット編集部２１６には、ユーザから、次の処理者が指定される(Ｓ１００７／ＹＥＳ)。なお、スキャンしたデータのファイル名の追加及び更新におけるチケット編集は、ここでは省略する。ユーザが、次の処理者である承認者のＩＤ(１０９８８)を指定する(Ｓ１００７／ＹＥＳ)。図３（Ｂ）や図４の場合、mode要素は存在しない(Ｓ１００８／ＮＯ)。従って、チケット編集部２１６は、mode要素を作成し(Ｓ１００９)、approverID属性に次の処理者の識別ＩＤを、テキスト要素の最終処理者である現在のユーザ(清算処理者)の識別ＩＤをセットする(Ｓ１０１０)。そして、ユーザのコメントが存在する場合、チケット編集部２１６は、その情報を追加する(Ｓ１０１１)。ここでは、ユーザのコメントは、ないものとする。これにより、８０１の項目が情報としてセットされる。最後に、チケット編集部２１６は、チケットの書き出し処理を行ない(Ｓ１０１２)、編集された図９（Ａ）のチケットがチケット更新部２１７に渡される(図８のＳ７３６)。

さらに、この図９（Ａ）のスキャンチケットを渡された承認者が承認を却下した場合、同様のフローにより、処理が清算者に戻る。なお、承認者は、清算処理者のフォルダ内にあるスキャンチケットのうち、approverIDが自身のＩＤと一致するスキャンチケットを取得可能である。その場合、ユーザが、前の処理者である清算のＩＤ(１００００)を指定する(Ｓ１００７／ＹＥＳ)。図９（Ａ）の場合、mode要素は存在する(Ｓ１００８／ＹＥＳ)。従って、チケット編集部２１６は、approverID属性に、前の処理者である清算者の識別ＩＤを、テキスト要素の最終処理者である現在のユーザ(承認者)の識別ＩＤをセットする(Ｓ１０１０)。即ちここでは、スキャンチケットの提供先を指定する指定情報の更新が行われる。そして、チケット編集部２１６は、ユーザのコメントを追加する(Ｓ１０１１)。これにより、９０１と９０２の項目が情報としてセットされる。最後に、チケット編集部２１６は、チケットの書き出し処理を行ない(Ｓ１０１２)、編集された図９（Ｂ）のチケットがチケット更新部２１７に渡される(図８のＳ７３６)。

第２の実施形態では、現在の処理状態のみを追加記述することを説明したが、その他にも、前の処理や後の処理との関連性を記述しておき、現在の状況から次にどのような処理に移行するかが分かるようにしてもよい。即ち、今回のデータの送信処理（追加、更新処理等）と当該送信処理後に当該データについて行われる処理（承認処理等）との関連性を記述しておいてもよい。

本発明の第１の実施形態においては、送信したデータのファイル名、送信日時を用いて、データの送信先情報を含むスキャンチケットを編集するように構成している。従って、送信先にデータの格納状況を問い合わせることなく、スキャンチケットから送信先におけるデータの格納状況を把握することが可能となる。

また、本発明の第２の実施形態においては、スキャンチケットを取得することが可能なユーザを変更するように構成している。従って、例えば、データを送信先に送信した後、データの送信者から当該データの承認者にスキャンチケットの取得権限を変更することにより、データの送信者が間違ったデータを送信した状態でそのまま当該データに対する処理が進行してしまうことを防止することができる。

さらに、本発明の第２の実施形態においては、今回のデータの送信処理と当該送信処理後のデータについて行われる処理との関連性を把握することができるように構成している。従って、関連性のある処理が全て完了するまで一部のジョブが未処理のまま消滅してしまうことを防止することが可能となる。

上述した本発明の実施形態を構成する各手段及び各ステップは、コンピュータのＲＡＭやＲＯＭ等に記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。

また、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施形態も可能であり、具体的には、一つの機器からなる装置に適用してもよい。

１０１：画像処理装置、１０２：チケットサーバ、１０３：スキャンチケット、１０４：送信先、１０５：スキャンデータ、１０６：編集済スキャンチケット

Claims (10)

1. データを送信するデータ送信装置であって、
   前記データの送信先を含む情報をネットワーク上の提供装置から取得する取得手段と、
   前記取得手段により取得された情報に従って前記送信先にデータを送信する送信手段と、
   前記送信手段によるデータの送信時に、前記情報の更新を前記提供装置に要求する要求手段とを有することを特徴とするデータ送信装置。
2. 前記要求手段は、前記送信手段により送信したデータの識別子が追加されるように、前記情報の更新を前記提供装置に要求することを特徴とする請求項１に記載のデータ送信装置。
3. 前記要求手段は、前記情報を提供する提供先を指定する指定情報の更新を、前記提供装置に要求することを特徴とする請求項１に記載のデータ送信装置。
4. 前記情報は、送信するデータのカテゴリーを示す情報を含み、前記要求手段は、前記送信したデータの識別子が、前記送信したデータが属するカテゴリーに対応して追加されるように、前記提供装置に要求することを特徴とする請求項１に記載のデータ送信装置。
5. 前記送信手段は、前記提供装置から取得した情報に含まれる条件に従って原稿を読み取り、得られた原稿データを前記送信先に送信することを特徴とする請求項１に記載のデータ送信装置。
6. データを送信するデータ送信装置による送信制御方法であって、
   前記データの送信先を含む情報をネットワーク上の提供装置から取得する取得ステップと、
   前記取得された情報に従って前記送信先にデータを送信する送信ステップと、
   前記データの送信時に、前記情報の更新を前記提供装置に要求する要求ステップとを含むことを特徴とする送信制御方法。
7. 前記要求ステップは、前記送信したデータの識別子が追加されるように、前記情報の更新を前記提供装置に要求することを特徴とする請求項６に記載の送信制御方法。
8. 前記要求ステップは、前記情報を提供する提供先を指定する指定情報の更新を、前記提供装置に要求することを特徴とする請求項６に記載の送信制御方法。
9. データの送信先を含む情報をネットワーク上の提供装置から取得する取得ステップと、
   前記取得された情報に従って前記送信先にデータを送信する送信ステップと、
   前記データの送信時に、前記情報の更新を前記提供装置に要求する要求ステップとをコンピュータに実行させるためのプログラム。
10. 前記要求ステップは、前記送信したデータの識別子が追加されるように、前記情報の更新を前記提供装置に要求することを特徴とする請求項９に記載のプログラム。

Images