(57)【要約】【課題】共有データの更新要求や取得要求を効率的に行うことができ、無駄な通知処理を減少することができ、融合機のリソースを浪費することなく書き換え可能な共有データを管理できる画像形成装置，共有データ管理方法および共有データ管理システムを提供することを目的とする。【解決手段】プログラム２３〜２５，３８が利用する書き換え可能な共有データを有する画像形成装置１であって、共有データの更新又は共有データの取得及び更新が禁止されているときに、その禁止により処理できない共有データに対する取得開始要求又は更新開始要求を受信すると取得開始要求又は更新開始要求を保留し、共有データの更新又は共有データの取得及び更新が可能となると、保留した取得開始要求又は更新開始要求に応じて共有データの更新又は共有データの取得及び更新を禁止する共有データ管理手段３７を有することにより上記課題を解決する。【選択図】図３
2008118672.tif 000002
【特許請求の範囲】
【請求項１】
画像形成処理で使用されるハードウェア資源と、画像形成に係る処理を行う１つ以上のプログラムと、前記プログラムが利用する書き換え可能な共有データとを有する画像形成装置であって、
前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求を受信すると前記取得開始要求又は更新開始要求を保留し、
前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を禁止する共有データ管理手段を有することを特徴とする画像形成装置。
【請求項２】
画像形成処理で使用されるハードウェア資源と、画像形成に係る処理を行う１つ以上のプログラムと、前記プログラムが利用する書き換え可能な共有データとを有する画像形成装置の共有データ管理方法であって、
前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求を受信すると前記取得開始要求又は更新開始要求を保留する段階と、
前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を禁止する段階と
を有することを特徴とする共有データ管理方法。
【請求項３】
１つ以上の外部のネットワーク機器と、前記外部のネットワーク機器にネットワークを介して接続された画像形成装置とを用いて、前記画像形成装置のプログラムが利用する書き換え可能な共有データの管理を行う共有データ管理システムであって、
前記画像形成装置は、前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求を受信すると前記取得開始要求又は更新開始要求を保留し、
前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を禁止する共有データ管理手段を有することを特徴とする共有データ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像形成装置，共有データ管理方法および共有データ管理システムに係り、特に書き換え可能な共有データを管理する画像形成装置，共有データ管理方法および共有データ管理システムに関する。
【背景技術】
【０００２】
近年、プリンタ，コピー，ファクシミリおよびスキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置（以下、融合機という）が知られるようになった。この融合機は、１つの筐体内に表示部，印刷部および撮像部などを設けると共に、プリンタ，コピー，ファクシミリおよびスキャナにそれぞれ対応する４種類のソフトウェアを設け、そのソフトウェアを切り替えることより、プリンタ，コピー，ファクシミリおよびスキャナとして動作させるものである。特許文献１には、上記のような融合機の一例が記載されている。
【０００３】
このような融合機では、コピーやスキャナ等で利用する電子メールアドレスやファクシミリ番号などの宛先データがユーザ情報として一元管理されている。融合機により一元管理されているユーザ情報は、融合機を操作するオペレータからの指示により適宜更新される。また、融合機は、例えばネットワークを介してネットワーク機器に接続されており、ネットワーク機器からの指示により、ユーザ情報が適宜更新される。
【０００４】
融合機により一元管理されているユーザ情報は、融合機またはネットワーク機器を操作する１人以上のオペレータからの要求により更新されるため、複数のオペレータから同時にユーザ情報を更新される可能性があった。また、ユーザ情報はコピーやスキャナ等に対応するソフトウェアにより利用されているときに、融合機またはネットワーク機器を操作するオペレータが更新する可能性もあった。さらに、ユーザ情報は融合機またはネットワーク機器を操作するオペレータにより更新されているときに、コピーやスキャナ等に対応するソフトウェアにより利用される可能性もあった。
【０００５】
そこで、従来の融合機は一のオペレータがユーザ情報を更新しているとき、他のオペレータからのユーザ情報の更新要求や、コピーやスキャナ等に対応するソフトウェアからのユーザ情報の取得要求を排他していた。また、従来の融合機はコピーやスキャナ等に対応するソフトウェアがユーザ情報を利用しているとき、オペレータからのユーザ情報の更新要求を排他していた。
【特許文献１】特開２００２−８４３８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
第１に、従来の融合機は、ユーザ情報の更新要求や取得要求が排他された場合、先に行われていたユーザ情報の更新または利用が終了するのを待って、再びユーザ情報の更新要求や取得要求を行っていた。
【０００７】
したがって、従来の融合機はユーザ情報の更新要求や取得要求が連続して排他されたときに、ユーザ情報の更新要求や取得要求を何度も繰り返し行わなければユーザ情報の更新または利用を行えないという問題があった。また、従来の融合機はユーザ情報の更新要求や取得要求が連続して排他されたときに、ユーザ情報の更新要求や取得要求が多数発生して融合機のリソースを無駄に浪費しているという問題があった。
【０００８】
第２に、従来の融合機は、融合機やネットワーク機器を操作するオペレータからユーザ情報の更新終了を通知されると、ユーザ情報を利用する又は利用する可能性のある全てのソフトウェアにユーザ情報の更新終了を通知する。ユーザ情報の更新終了を通知されたソフトウェアは、必要に応じてユーザ情報の読み出し要求を行って更新済みのユーザ情報を取得していた。
【０００９】
しかしながら、ユーザ情報の更新終了を通知されたソフトウェアの全てが、必ずしも更新終了直後にユーザ情報を取得する必要はなかった。したがって、ユーザ情報を利用する又は利用する可能性のある全てのソフトウェアにユーザ情報の更新終了を通知することは無駄であり、融合機のリソースを無駄に浪費しているという問題があった。
【００１０】
本発明は、上記の点に鑑みなされたもので、共有データの更新要求や取得要求を効率的に行うことができ、無駄な通知処理を減少することができ、融合機のリソースを浪費することなく書き換え可能な共有データを管理できる画像形成装置，共有データ管理方法および共有データ管理システムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
そこで、上記課題を解決するため、本発明は、画像形成処理で使用されるハードウェア資源と、画像形成に係る処理を行う１つ以上のプログラムと、前記プログラムが利用する書き換え可能な共有データとを有する画像形成装置であって、前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求を受信すると前記取得開始要求又は更新開始要求を保留し、前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を禁止する共有データ管理手段を有することを特徴とする。
【００１２】
また、本発明は、画像形成処理で使用されるハードウェア資源と、画像形成に係る処理を行う１つ以上のプログラムと、前記プログラムが利用する書き換え可能な共有データとを有する画像形成装置の共有データ管理方法であって、前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求を受信すると前記取得開始要求又は更新開始要求を保留する段階と、前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を禁止する段階とを有することを特徴とする。
【００１３】
また、本発明は、１つ以上の外部のネットワーク機器と、前記外部のネットワーク機器にネットワークを介して接続された画像形成装置とを用いて、前記画像形成装置のプログラムが利用する書き換え可能な共有データの管理を行う共有データ管理システムであって、前記画像形成装置は、前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求を受信すると前記取得開始要求又は更新開始要求を保留し、前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を禁止する共有データ管理手段を有することを特徴とする。
【００１４】
本発明によれば、共有データの更新要求や取得要求が無駄に行われることを回避することで、共有データの更新要求や取得要求を効率的に行うことができ、融合機のリソースを浪費することなく書き換え可能な共有データを管理することが可能な画像形成装置，共有データ管理方法および共有データ管理システムを提供できる。
【００１５】
また、本発明によれば、共有データの更新開始および更新終了を通知すべきプログラムを選択して通知するので、無駄な通知処理を減少することができ、融合機のリソースを浪費することなく書き換え可能な共有データを管理することが可能な画像形成装置，共有データ管理方法および共有データ管理システムを提供できる。
【発明の効果】
【００１６】
共有データの更新要求や取得要求を効率的に行うことができ、無駄な通知処理を減少することができ、融合機のリソースを浪費することなく書き換え可能な共有データを管理できる画像形成装置，共有データ管理方法および共有データ管理システムを提供できる。
【発明を実施するための最良の形態】
【００１７】
次に、本発明の実施の形態について図面に基づいて説明する。
【００１８】
図１は、本発明による融合機の一実施例の構成図である。融合機１は、ソフトウェア群２と，融合機起動部３と，ハードウェア資源４とを含むように構成される。
【００１９】
融合機起動部３は融合機１の電源投入時に最初に実行され、アプリケーション層５およびプラットフォーム６を起動する。例えば融合機起動部３は、アプリケーション層５およびプラットフォーム６のプログラムをハードディスク装置（以下、ＨＤＤという）などから読み出し、読み出した各プログラムをメモリ領域に転送して起動する。
【００２０】
ハードウェア資源４は、白黒レーザプリンタ（Ｂ＆Ｗ  ＬＰ）１１と，カラーレーザプリンタ（Ｃｏｌｏｒ  ＬＰ）１２と，スキャナやファクシミリなどのその他のハードウェアリソース１３とを含む。
【００２１】
また、ソフトウェア群２は、ＵＮＩＸ（登録商標）などのオペレーティングシステム（以下、ＯＳという）上に起動されているアプリケーション層５とプラットフォーム６とを含む。
【００２２】
アプリケーション層５は、プリンタ，コピー，ファックスおよびスキャナなどの画像形成にかかるユーザサービスにそれぞれ固有の処理を行うプログラムを含む。アプリケーション層５は、プリンタアプリ２１と，コピーアプリ２２と，ファックスアプリ２３と，スキャナアプリ２４と，ネットファイルアプリ２５とを含む。なお、ネットファイルアプリ２５はネットワークファイル用アプリケーションであり、融合機１にネットワークを介して接続されるネットワーク機器とのデータ通信を管理するものである。
【００２３】
また、プラットフォーム６は、アプリケーション層５からの処理要求を解釈してハードウェア資源４の獲得要求を発生するコントロールサービス層９と、１つ以上のハードウェア資源４の管理を行ってコントロールサービス層９からの獲得要求を調停するシステムリソースマネージャ（以下、ＳＲＭという）３９と、ＳＲＭ３９からの獲得要求に応じてハードウェア資源４の管理を行うハンドラ層１０とを含む。
【００２４】
コントロールサービス層９は、ネットワークコントロールサービス（以下、ＮＣＳという）３１，デリバリーコントロールサービス（以下、ＤＣＳという）３２，オペレーションパネルコントロールサービス（以下、ＯＣＳという）３３，ファックスコントロールサービス（以下、ＦＣＳという）３４，エンジンコントロールサービス（以下、ＥＣＳという）３５，メモリコントロールサービス（以下、ＭＣＳという）３６，ユーザインフォメーションコントロールサービス（以下、ＵＣＳという）３７，システムコントロールサービス（以下、ＳＣＳという）３８など、一つ以上のサービスモジュールを含むように構成されている。
【００２５】
なお、プラットフォーム６は予め定義されている関数により、アプリケーション層５からの処理要求を受信するＡＰＩ５３を有するように構成されている。ＯＳは、アプリケーション層５およびプラットフォーム６の各ソフトウェアをプロセスとして並列実行する。
【００２６】
ＮＣＳ３１のプロセスは、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、各アプリケーションからのデータをネットワーク側に送信する際の仲介を行う。例えばＮＣＳ３１は、融合機にネットワークを介して接続されるネットワーク機器とのデータ通信を制御する。
【００２７】
ＤＣＳ３２のプロセスは、融合機に蓄積されている文書データの配送などの制御を行う。ＯＣＳ３３のプロセスは、オペレータと本体制御との間の情報伝達手段となるオペレーションパネルの制御を行う。ＦＣＳ３４のプロセスは、アプリケーション層５からＰＳＴＮまたはＩＳＤＮ網を利用したファックス送受信，バックアップ用のメモリで管理されている各種ファックスデータの登録／引用，ファックス読み取り，ファックス受信印刷などを行うためのＡＰＩを提供する。
【００２８】
ＥＣＳ３５のプロセスは、白黒レーザプリンタ１１，カラーレーザプリンタ１２，ハードウェアリソース１３などのエンジン部の制御を行う。ＭＣＳ３６のプロセスは、メモリの取得および解放，ＨＤＤの利用，画像データの圧縮および伸張などのメモリ制御を行う。ＵＣＳ３７のプロセスは、ユーザ情報の管理を行うものである。
【００２９】
ＳＣＳ３８のプロセスは、アプリケーション管理，操作部制御，システム画面表示，ＬＥＤ表示，ハードウェア資源管理，割り込みアプリケーション制御などの処理を行う。ＳＲＭ３９のプロセスは、ＳＣＳ３８と共にシステムの制御およびハードウェア資源４の管理を行うものである。例えばＳＲＭ３９のプロセスは、白黒レーザプリンタ１１やカラーレーザプリンタ１２などのハードウェア資源４を利用する上位層からの獲得要求に従って調停を行い、実行制御する。
【００３０】
具体的に、ＳＲＭ３９のプロセスは獲得要求されたハードウェア資源４が利用可能であるか（他の獲得要求により利用されていないかどうか）を判定し、利用可能であれば獲得要求されたハードウェア資源４が利用可能である旨を上位層に通知する。また、ＳＲＭ３９のプロセスは上位層からの獲得要求に対してハードウェア資源４を利用するためのスケジューリングを行い、要求内容（例えば、プリンタエンジンによる紙搬送と作像動作，メモリ確保，ファイル生成など）を直接実施している。
【００３１】
また、ハンドラ層１０は後述するファックスコントロールユニット（以下、ＦＣＵという）の管理を行うファックスコントロールユニットハンドラ（以下、ＦＣＵＨという）４０と、プロセスに対するメモリの割り振り及びプロセスに割り振ったメモリの管理を行うイメージメモリハンドラ（以下、ＩＭＨという）４１とを含む。
【００３２】
ＳＲＭ３９およびＦＣＵＨ４０は、予め定義されている関数によりハードウェア資源４に対する処理要求を送信するエンジンＩ／Ｆ５４を利用して、ハードウェア資源４に対する処理要求を行う。
【００３３】
図１の構成により、融合機１は各アプリケーションで共通的に必要な処理をプラットフォーム６で一元的に処理することができる。次に、融合機１のハードウェア構成について説明する。
【００３４】
図２は、本発明による融合機の一実施例のハードウェア構成図である。融合機１は、コントローラ６０と，オペレーションパネル７０と，ＦＣＵ８０と，ＵＳＢデバイス９０と，ＩＥＥＥ１３９４デバイス１００と，エンジン部１１０とを含む。
【００３５】
また、コントローラ６０は、ＣＰＵ６１と，システムメモリ（ＭＥＭ−Ｐ）６２と，ノースブリッジ（以下、ＮＢという）６３と，サウスブリッジ（以下、ＳＢという）６４と，ＡＳＩＣ６６と，ローカルメモリ（ＭＥＭ−Ｃ）６７と，ＨＤＤ６８およびネットワークインターフェースコントローラ６９とを含む。
【００３６】
オペレーションパネル７０は、コントローラ６０のＡＳＩＣ６６に接続されている。また、ＦＣＵ８０，ＵＳＢデバイス９０，ＩＥＥＥ１３９４デバイス１００およびエンジン部１１０は、コントローラ６０のＡＳＩＣ６６にＰＣＩバスで接続されている。
【００３７】
コントローラ６０は、ＡＳＩＣ６６にローカルメモリ６７，ＨＤＤ６８およびネットワークインターフェースコントローラ６９などが接続されると共に、ＣＰＵ６１とＡＳＩＣ６６とがＣＰＵチップセットのＮＢ６３を介して接続されている。このように、ＮＢ６３を介してＣＰＵ６１とＡＳＩＣ６６とを接続することにより、ＣＰＵ６１のインターフェースが公開されていない場合に対応する。
【００３８】
なお、ＡＳＩＣ６６とＮＢ６３とはＰＣＩバスを介して接続されているのでなく、ＡＧＰ（Accelerated Graphics Port）６５を介して接続されている。このように、図１のアプリケーション層５やプラットフォーム６を形成する一つ以上のプロセスを実行制御するため、ＡＳＩＣ６６とＮＢ６３とを低速のＰＣＩバスでなくＡＧＰ６５を介して接続し、パフォーマンスの低下を防いでいる。
【００３９】
ＣＰＵ６１は、融合機１の全体制御を行うものである。ＣＰＵ６１は、ＮＣＳ３１，ＤＣＳ３２，ＯＣＳ３３，ＦＣＳ３４，ＥＣＳ３５，ＭＣＳ３６，ＵＣＳ３７，ＳＣＳ３８，ＳＲＭ３９，ＦＣＵＨ４０およびＩＭＨ４１をＯＳ上にそれぞれプロセスとして起動して実行させると共に、アプリケーション層５を形成するプリンタアプリ２１，コピーアプリ２２，ファックスアプリ２３，スキャナアプリ２４，ネットファイルアプリ２５を起動して実行させる。
【００４０】
ＮＢ６３は、ＣＰＵ６１，システムメモリ６２，ＳＢ６４およびＡＳＩＣ６６を接続するためのブリッジである。システムメモリ６２は、融合機１の描画用メモリなどとして用いるメモリである。ＳＢ６４は、ＮＢ６３とＲＯＭ，ＰＣＩバス，周辺デバイスとを接続するためのブリッジである。また、ローカルメモリ６７はコピー用画像バッファ，符号バッファとして用いるメモリである。
【００４１】
ＡＳＩＣ６６は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。ＨＤＤ６８は、画像データの蓄積，文書データの蓄積，プログラムの蓄積，フォントデータの蓄積，フォームの蓄積などを行うためのストレージである。ネットワークインターフェースコントローラ６９は、ネットワークを介して接続されているネットワーク機器とＭＡＣアドレスなどを用いて通信する。また、オペレーションパネル７０は、オペレータからの入力操作を受け付けると共に、オペレータに向けた表示を行う操作部である。
【００４２】
以下、融合機１により実現される共有データ管理方法について図面を参照しつつ説明していく。図３は、本発明による共有データ管理方法を説明するためのシステム構成図である。なお、図３では説明に必要のない構成を省略している。
【００４３】
ＵＣＳ３７は、共有データの一例としてのユーザ情報を一元管理している。例えばＵＣＳ３７は、ユーザ情報をＨＤＤ６８に格納して管理する。ＵＣＳ３７が管理するユーザ情報は、例えば図４のように構成される。
【００４４】
図４は、ユーザ情報の一例の構成図である。図４のユーザ情報は、エントリＩＤ件数，見出し情報，ユーザコード情報，メール情報，ファックス情報，グループ情報，中継情報，認証情報，並び順入れ換え情報をデータ項目として含む。
【００４５】
データ項目「エントリＩＤ件数」は、融合機１に登録できるエントリの件数を表す。例えばエントリＩＤ件数が１００の場合、１００人のオペレータを登録できる。
【００４６】
データ項目「見出し情報」は、登録されたエントリを分類して表示するための見出しを表す。例えば見出し情報が「あ，か，さ，た，・・・」の場合、エントリは見出し「あ，か，さ，た，・・・」により分類されて表示される。データ項目「ユーザコード情報」は、オペレータを識別するための識別情報を表す。
【００４７】
データ項目「メール情報」は、スキャナアプリ２４が利用する電子メールアドレスを表す。また、データ項目「ファックス情報」はファックスアプリ２３が利用するファックス番号を表す。
【００４８】
データ項目「グループ情報」は、エントリをグループ化するためのメンバＩＤリストを表す。例えばメンバＩＤリストは、そのグループに所属するオペレータのエントリＩＤで構成される。データ項目「中継情報」は、ファックスデータを中継するための情報を表す。
【００４９】
データ項目「認証情報」は、スキャナアプリ２４がスキャナデータを送信するために必要な例えばパスワードなどの情報を表す。データ項目「並び順入れ替え情報」は、ユーザ情報の並び順を入れ替え可能か否かを表す情報である。図４のユーザ情報は、融合機１の有する機能（コピー機能，ファックス機能，スキャナ機能など）の組み合わせにより構成が異なっている。
【００５０】
図３のファックスアプリ２３は、ＵＣＳ３７にユーザ情報の取得要求を行うことでファックス機能に必要なユーザ情報を取得し、取得したユーザ情報を用いてオペレーションパネル７０に画面３１０を表示する。画面３１０には、ファックスデータを送信する宛先データ（例えばファックス番号）を選択するための情報が表示される。
【００５１】
スキャナアプリ２４は、ＵＣＳ３７にユーザ情報の取得要求を行うことでスキャナ機能に必要なユーザ情報を取得し、取得したユーザ情報を用いてオペレーションパネル７０に画面３２０を表示する。画面３２０には、スキャナデータを送信する宛先データ（例えば電子メールアドレス）を選択するための情報が表示される。
【００５２】
ＳＣＳ３８のシステム初期設定機能３０２は、ＵＣＳ３７にユーザ情報の取得要求を行うことで必要なユーザ情報を取得する。ＭＣＳ３６は、ＵＣＳ３７にユーザ情報の取得要求を行うことで必要なユーザ情報を取得する。また、ネットファイルアプリ（ＮＦＡ）２５はＮＣＳ３１およびネットワーク３３０を介して接続されるネットワーク機器３３１，３３２からの要求に応じてＵＣＳ３７にユーザ情報の取得要求を行うことで必要なユーザ情報を取得する。なお、ＳＣＳ３８のソフトキーボード機能３０１はオペレーションパネル７０にソフトキーボードを表示し、表示したソフトキーボードを制御する。
【００５３】
図３では、ネットファイルアプリ２５またはＳＣＳ３８のシステム初期設定機能３０２が、ＵＣＳ３７にユーザ情報の追加，変更または削除などの更新要求を行うことで、ユーザ情報を更新する。
【００５４】
図３のＵＣＳ３７は、ユーザ情報が利用されているときにユーザ情報の更新要求が起きた場合，ユーザ情報が更新されているときにユーザ情報の取得要求が起きた場合、またはユーザ情報が更新されているときにユーザ情報の更新要求が起きた場合に対処するため、後述するようなリードロックまたはライトロックを行う。
【００５５】
リードロックとは、ユーザ情報の取得要求を行う前にユーザ情報の書き換え禁止をＵＣＳ３７に要求するものである。なお、リードロックに対応するアンロックにより、ユーザ情報の書き換え禁止が解除される。
【００５６】
また、ライトロックとはユーザ情報の更新要求を行う前にユーザ情報の読み出し禁止と、他のアプリなどからのユーザ情報の書き換え禁止とをＵＣＳ３７に要求するものである。なお、ライトロックに対応するアンロックにより、ユーザ情報の読み出し禁止と書き換え禁止が解除される。
【００５７】
次に、リードロックおよびライトロックの基本的な処理について説明する。図５は、リードロックの基本的な処理を表す一例のシーケンス図である。ステップＳ５０１では、スキャナアプリ２４からＵＣＳ３７に対してリードロックが行われている。ステップＳ５０２ではステップＳ５０１のリードロックに対するアンロックが行われる前に、スキャナアプリ２４からＵＣＳ３７に対してリードロックが行われている。
【００５８】
このような同一アプリからの多重リードロックは、ユーザ情報が書き換え禁止であっても何ら問題が生じないため許可されている。ステップＳ５０１及びステップＳ５０２でリードロックを行ったあと、スキャナアプリ２４とＵＣＳ３７との間ではユーザ情報の取得要求および取得応答が繰り返し行われているが、図示を省略する。以下の説明でも同様に、スキャナアプリ２４とＵＣＳ３７との間で行われているユーザ情報の取得要求および取得応答の図示を省略する。
【００５９】
ユーザ情報の取得が終了すると、スキャナアプリ２４はステップＳ５０３およびステップＳ５０４でステップＳ５０１およびステップＳ５０２に対応するアンロックをＵＣＳ３７に行って、ユーザ情報の取得処理を終了する。
【００６０】
また、図６はリードロックの基本的な処理を表す他の一例のシーケンス図である。ステップＳ６０１では、スキャナアプリ２４からＵＣＳ３７に対してリードロックが行われている。ステップＳ６０２ではステップＳ６０１のリードロックに対するアンロックが行われる前に、ファックスアプリ２３からＵＣＳ３７に対してリードロックが行われている。
【００６１】
このような異なるアプリからの多重リードロックは、ユーザ情報が書き換え禁止であっても何ら問題が生じないため許可されている。なお、ステップＳ６０１及びステップＳ６０２でリードロックを行ったあと、ファックスアプリ２３およびスキャナアプリ２４とＵＣＳ３７との間ではユーザ情報の取得要求および取得応答が繰り返し行われる。
【００６２】
ユーザ情報の取得が終了すると、ファックスアプリ２３はステップＳ６０３でステップＳ６０２に対応するアンロックをＵＣＳ３７に行って、ユーザ情報の取得処理を終了する。また、スキャナアプリ２４はステップＳ６０４でステップＳ６０１に対応するアンロックをＵＣＳ３７に行って、ユーザ情報の取得処理を終了する。
【００６３】
図７は、ライトロックの基本的な処理を表す一例のシーケンス図である。ステップＳ７０１では、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われている。ステップＳ７０２ではステップＳ７０１のライトロックに対するアンロックが行われる前に、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われている。
【００６４】
このような同一アプリからの多重ライトロックは、更新後のユーザ情報に矛盾が生じるなどの問題が生じるため許可されていない。したがって、ステップＳ７０２のライトロックは拒絶される。ステップＳ７０１でライトロックを行ったあと、スキャナアプリ２４とＵＣＳ３７との間ではユーザ情報の更新要求および更新応答が繰り返し行われているが、図示を省略する。以下の説明でも同様に、スキャナアプリ２４とＵＣＳ３７との間で行われているユーザ情報の更新要求および更新応答の図示を省略する。ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ７０３でステップＳ７０１に対応するアンロックをＵＣＳ３７に行って、ユーザ情報の更新処理を終了する。
【００６５】
また、図８はライトロックの基本的な処理を表す他の一例のシーケンス図である。ステップＳ８０１では、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われている。ステップＳ８０２ではステップＳ８０１のライトロックに対するアンロックが行われる前に、ファックスアプリ２３からＵＣＳ３７に対してライトロックが行われている。
【００６６】
このような異なるアプリからの多重ライトロックは、更新後のユーザ情報に矛盾が生じるなどの問題が生じるため許可されていない。したがって、ステップＳ８０２のライトロックは拒絶される。なお、ステップＳ８０１でライトロックを行ったあと、スキャナアプリ２４とＵＣＳ３７との間ではユーザ情報の更新要求および更新応答が繰り返し行われる。ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ８０３でステップＳ８０１に対応するアンロックをＵＣＳ３７に行って、ユーザ情報の更新処理を終了する。
【００６７】
図９は、リードロックおよびライトロックの基本的な処理を表す一例のシーケンス図である。ステップＳ９０１では、スキャナアプリ２４からＵＣＳ３７に対してリードロックが行われている。ステップＳ９０２ではステップＳ９０１のリードロックに対するアンロックが行われる前に、ファックスアプリ２３からＵＣＳ３７に対してライトロックが行われている。
【００６８】
このようなリードロックがアンロックされる前のライトロックは、ユーザ情報が書き換え禁止であるため許可されていない。したがって、ステップＳ９０２のライトロックは拒絶される。なお、ステップＳ９０１でリードロックを行ったあと、スキャナアプリ２４とＵＣＳ３７との間ではユーザ情報の取得要求および取得応答が繰り返し行われる。ユーザ情報の取得が終了すると、スキャナアプリ２４はステップＳ９０３でステップＳ９０１に対応するアンロックをＵＣＳ３７に行って、ユーザ情報の取得処理を終了する。
【００６９】
また、図１０はリードロックおよびライトロックの基本的な処理を表す他の一例のシーケンス図である。ステップＳ１００１では、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われている。ステップＳ１００２ではステップＳ１００１のライトロックに対するアンロックが行われる前に、ファックスアプリ２３からＵＣＳ３７に対してリードロックが行われている。
【００７０】
このようなライトロックがアンロックされる前のリードロックは、ユーザ情報が読み出し禁止であるため許可されていない。したがって、ステップＳ１００２のリードロックは拒絶される。なお、ステップＳ１００１でライトロックを行ったあと、スキャナアプリ２４とＵＣＳ３７との間ではユーザ情報の更新要求および更新応答が繰り返し行われる。
【００７１】
ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ１００３でステップＳ１００１に対応するアンロックをＵＣＳ３７に行って、ユーザ情報の更新処理を終了する。
【００７２】
次に、ライトロックが行われたときにユーザ情報が更新された旨をファックスアプリ２３などに通知する変化通知処理について説明する。図１１は、ユーザ情報の変化通知処理を表す一例のシーケンス図である。
【００７３】
ステップＳ１１０１では、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われている。ステップＳ１１０２では、ＵＣＳ３７が、ユーザ情報の更新開始をスキャナアプリ２４に通知する。また、ステップＳ１１０３では、ＵＣＳ３７が、ユーザ情報の更新開始をファックスアプリ２３に通知する。ユーザ情報の更新開始を通知されることで、ファックスアプリ２３およびスキャナアプリ２４はユーザ情報が更新される可能性を認識する。
【００７４】
ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ１１０４でステップＳ１１０１に対応するアンロックをＵＣＳ３７に行う。ステップＳ１１０５では、ＵＣＳ３７が、ユーザ情報の更新終了をスキャナアプリ２４に通知する。また、ステップＳ１１０６では、ＵＣＳ３７が、ユーザ情報の更新終了をファックスアプリ２３に通知する。
【００７５】
ユーザ情報の更新終了を通知されることで、ファックスアプリ２３およびスキャナアプリ２４はユーザ情報が更新されたことを認識する。ユーザ情報の更新終了を通知されたあと、ファックスアプリ２３，スキャナアプリ２４などは更新済みのユーザ情報を取得する。
【００７６】
なお、ユーザ情報の更新開始を通知されてから更新終了を通知されるまで、ファックスアプリ２３，スキャナアプリ２４などは、画面３１０，画面３２０の表示要求が起きた場合、画面３１０，画面３２０の代わりにユーザ情報が更新中である旨を表示する画面をオペレーションパネル７０に表示する。例えばスキャナアプリ２４は、図１２のような画面をオペレーションパネル７０に表示する。図１２は、更新開始通知画面の一例のイメージ図である。
【００７７】
また、ユーザ情報の更新終了を通知されると、ファックスアプリ２３，スキャナアプリ２４などは、ユーザ情報が更新された旨を表示する画面をオペレーションパネル７０に表示する。例えばスキャナアプリ２４は、図１３のような画面をオペレーションパネル７０に表示する。図１３は、更新終了通知画面の一例のイメージ図である。
【００７８】
ファックスアプリ２３，スキャナアプリ２４などは、図１２および図１３のような画面をオペレーションパネル７０に表示することで、オペレータにユーザ情報の更新開始および更新終了を通知している。
【００７９】
ところで、図８のステップＳ８０２ではステップＳ８０１のライトロックに対するアンロックが行われる前に、ファックスアプリ２３からＵＣＳ３７に対してライトロックが行われているため、ファックスアプリ２３が行ったライトロックが拒絶されている。したがって、ファックスアプリ２３は再びライトロックをＵＣＳ３７に行わなければならなかった。
【００８０】
また、図９のステップＳ９０２ではステップＳ９０１のリードロックに対するアンロックが行われる前に、ファックスアプリ２３からＵＣＳ３７に対してライトロックが行われているため、ファックスアプリ２３が行ったライトロックが拒絶されている。したがって、ファックスアプリ２３は再びライトロックをＵＣＳ３７に行わなければならなかった。
【００８１】
また、図１０のステップＳ１００２ではステップＳ１００１のライトロックに対するアンロックが行われる前に、ファックスアプリ２３からＵＣＳ３７に対してリードロックが行われているため、ファックスアプリ２３が行ったリードロックが拒絶されている。したがって、ファックスアプリ２３は再びリードロックをＵＣＳ３７に行わなければならなかった。
【００８２】
図８〜図１０の例では、ライトロックまたはリードロックが拒絶されると、再びファックスアプリ２３がライトロックまたはリードロックをＵＣＳ３７に対して行う必要があり、処理が冗長になっていた。
【００８３】
そこで、本発明による共有データ管理方法では、拒絶されたライトロックまたはリードロックを図１４のように管理し、拒絶されたライトロックまたはリードロックが、拒絶の理由がなくなったあとで行われるようにライトロック予約またはリードロック予約を行っている。
【００８４】
図１４は、拒絶されたライトロックまたはリードロックの管理について説明するための図である。ＵＣＳ３７は、例えばファックスアプリ２３やスキャナアプリ２４からのライトロックまたはリードロックが行われると、そのライトロックまたはリードロックを行ったファックスアプリ２３やスキャナアプリ２４の情報を、ロックの状態を管理するリードロックキューまたはライトロックキューに並べて格納する。
【００８５】
例えば図１４では、リードロックがＡアプリ，Ｂアプリ，Ａアプリ，Ｃアプリの順番で行われ、ライトロックがＤアプリ，Ｅアプリの順番で行われたことを表している。なお、図１４ではＥアプリが行ったライトロックが拒絶され、ライトロック予約されている。
【００８６】
したがって、ＵＣＳ３７は、図１４のようにライトロック予約またはリードロック予約を行うことにより、拒絶の理由がなくなったあとでライトロックまたはリードロックを行うことができる。
【００８７】
次に、ライトロック予約またはリードロック予約の処理について詳細に説明する。なお、ファックスアプリ２３およびスキャナアプリ２４はユーザ情報をオペレーションパネル７０に表示することがあるものとする。また、ネットファイルアプリ２５はユーザ情報をオペレーションパネル７０に表示することがないものとする。
【００８８】
図１５は、本発明によるライトロック予約処理を表す第１実施例のシーケンス図である。ステップＳ１５０１では、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われる。ステップＳ１５０２では、ＵＣＳ３７が、ユーザ情報の更新開始をスキャナアプリ２４に通知する。
【００８９】
なお、ＵＣＳ３７はユーザ情報の更新開始をネットファイルアプリ２５に通知しない。ネットファイルアプリ２５は、ユーザ情報や図１２または図１３の画面をオペレーションパネル７０に表示することがないためである。
【００９０】
ステップＳ１５０３では、ネットワーク機器３３１などからユーザ情報の書き換え要求が発生し、ネットファイルアプリ２５からＵＣＳ３７に対してライトロックが行われている。しかし、ステップＳ１５０３のライトロックは、ステップＳ１５０１のライトロックがアンロックされていないため、拒絶される。ＵＣＳ３７は、ステップＳ１５０３で拒絶されたライトロックを図１４のように管理することで、ライトロック予約を行う。
【００９１】
ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ１５０４でステップＳ１５０１に対応するアンロックをＵＣＳ３７に行う。ステップＳ１５０４では、ステップＳ１５０１のライトロックがアンロックされたため、ステップＳ１５０３でライトロックが拒絶された理由がなくなる。したがって、ＵＣＳ３７はライトロック予約に基づきステップＳ１５０３のライトロックを行う。
【００９２】
ステップＳ１５０５では、ＵＣＳ３７が、ユーザ情報の更新開始をネットファイルアプリ２５に通知する。ユーザ情報の更新が終了すると、ネットファイルアプリ２５はステップＳ１５０６でステップＳ１５０３に対応するアンロックをＵＣＳ３７に行う。ステップＳ１５０７では、ＵＣＳ３７が、ユーザ情報の更新終了をネットファイルアプリ２５に通知する。また、ステップＳ１５０８では、ＵＣＳ３７が、ユーザ情報の更新終了をスキャナアプリ２４に通知する。
【００９３】
図１５のライトロック予約処理では、拒絶の理由がなくなったあと、拒絶されたライトロックを自動的に行うことができる。
【００９４】
図１６は、本発明によるライトロック予約処理を表す第２実施例のシーケンス図である。ステップＳ１６０１では、スキャナアプリ２４からＵＣＳ３７に対してリードロックが行われる。
【００９５】
ステップＳ１６０２では、ファックスアプリ２３からＵＣＳ３７に対してライトロックが行われている。しかし、ステップＳ１６０２のライトロックは、ステップＳ１６０１のリードロックがアンロックされていないため、拒絶される。ＵＣＳ３７は、ステップＳ１６０２で拒絶されたライトロックを図１４のように管理することで、ライトロック予約を行う。
【００９６】
ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ１６０３でステップＳ１６０１に対応するアンロックをＵＣＳ３７に行う。ステップＳ１６０３では、ステップＳ１６０１のリードロックがアンロックされたため、ステップＳ１６０２でライトロックが拒絶された理由がなくなる。したがって、ＵＣＳ３７はライトロック予約に基づきステップＳ１６０２のライトロックを行う。
【００９７】
ステップＳ１６０４では、ＵＣＳ３７が、ユーザ情報の更新開始をスキャナアプリ２４に通知する。また、ステップＳ１６０５ではＵＣＳ３７が、ユーザ情報の更新開始をファックスアプリ２３に通知する。
【００９８】
ユーザ情報の更新が終了すると、ファックスアプリ２３はステップＳ１６０６でステップＳ１６０２に対応するアンロックをＵＣＳ３７に行う。ステップＳ１６０７では、ＵＣＳ３７が、ユーザ情報の更新終了をファックスアプリ２３に通知する。また、ステップＳ１６０８では、ＵＣＳ３７が、ユーザ情報の更新終了をスキャナアプリ２４に通知する。
【００９９】
図１６のライトロック予約処理では、拒絶の理由がなくなったあと、拒絶されたライトロックを自動的に行うことができる。
【０１００】
図１７は、本発明によるリードロック予約処理を表す第１実施例のシーケンス図である。ステップＳ１７０１では、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われる。ステップＳ１７０２では、ＵＣＳ３７が、ユーザ情報の更新開始をスキャナアプリ２４に通知する。
【０１０１】
なお、ＵＣＳ３７はユーザ情報の更新開始をネットファイルアプリ２５に通知しない。ネットファイルアプリ２５は、ユーザ情報や図１２または図１３の画面をオペレーションパネル７０に表示することがないためである。
【０１０２】
ステップＳ１７０３では、ネットワーク機器３３１などからユーザ情報の読み出し要求が発生し、ネットファイルアプリ２５からＵＣＳ３７に対してリードロックが行われている。しかし、ステップＳ１７０３のリードロックは、ステップＳ１７０１のライトロックがアンロックされていないため、拒絶される。ＵＣＳ３７は、ステップＳ１７０３で拒絶されたリードロックを図１４のように管理することで、リードロック予約を行う。
【０１０３】
ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ１７０４でステップＳ１７０１に対応するアンロックをＵＣＳ３７に行う。ステップＳ１７０４では、ステップＳ１７０１のライトロックがアンロックされたため、ステップＳ１７０３でリードロックが拒絶された理由がなくなる。したがって、ＵＣＳ３７はリードロック予約に基づきステップＳ１７０３のリードロックを行う。
【０１０４】
ステップＳ１７０５では、ＵＣＳ３７が、ユーザ情報の更新終了をスキャナアプリ２４に通知する。ユーザ情報の取得が終了すると、ネットファイルアプリ２５はステップＳ１７０６でステップＳ１７０３に対応するアンロックをＵＣＳ３７に行う。
【０１０５】
図１７のリードロック予約処理では、拒絶の理由がなくなったあと、拒絶されたリードロックを自動的に行うことができる。
【０１０６】
ところで、ＵＣＳ３７に対して行ったリードロックはリードロックに対応するアンロックにより解除する必要がある。また、ＵＣＳ３７に対して行ったライトロックはライトロックに対応するアンロックにより解除する必要がある。
【０１０７】
しかしながら、同一アプリがＵＣＳ３７に対してリードロックおよびライトロックを連続して行う場合、先に行ったリードロックまたはライトロックに対応するアンロックを以下のように省略できる。
【０１０８】
図１８は、本発明によるアンロック省略処理を表す第１実施例のシーケンス図である。ステップＳ１８０１では、スキャナアプリ２４からＵＣＳ３７に対してリードロックが行われる。ユーザ情報の読み出しが終了すると、スキャナアプリ２４はステップＳ１８０２で、ＵＣＳ３７に対してライトロックを行う。
【０１０９】
即ち、ステップＳ１８０１のリードロックとステップＳ１８０２のライトロックとは、同一のスキャナアプリ２４により行われる。このように、同一のスキャナアプリ２４がステップＳ１８０１でリードロックを行ったあとステップＳ１８０２でライトロックを連続して行う場合、後に行うステップＳ１８０２のライトロックにステップＳ１８０１のリードロックに対応するアンロックの役割を持たせることができる。
【０１１０】
したがって、同一のスキャナアプリ２４がリードロックを行ったあとでライトロックを連続して行う場合、先に行ったステップＳ１８０１のリードロックに対応するアンロックを省略できる。
【０１１１】
ステップＳ１８０３では、ＵＣＳ３７が、ユーザ情報の更新開始をスキャナアプリ２４に通知する。また、ステップＳ１８０４ではＵＣＳ３７が、ユーザ情報の更新開始をファックスアプリ２３に通知する。
【０１１２】
ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ１８０５でステップＳ１８０２に対応するアンロックをＵＣＳ３７に行う。ステップＳ１８０６では、ＵＣＳ３７が、ユーザ情報の更新終了をスキャナアプリ２４に通知する。また、ステップＳ１８０７ではＵＣＳ３７が、ユーザ情報の更新終了をファックスアプリ２３に通知する。
【０１１３】
図１８のアンロック省略処理では、同一のスキャナアプリ２４がリードロックを行ったあとでライトロックを連続して行う場合、先に行ったステップＳ１８０１のリードロックに対応するアンロックを省略できる。
【０１１４】
図１９は、本発明によるアンロック省略処理を表す第２実施例のシーケンス図である。ステップＳ１９０１では、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われる。ステップＳ１９０２では、ＵＣＳ３７が、ユーザ情報の更新開始をスキャナアプリ２４に通知する。また、ステップＳ１９０３ではＵＣＳ３７が、ユーザ情報の更新開始をファックスアプリ２３に通知する。
【０１１５】
ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ１９０４でＵＣＳ３７に対してリードロックを行う。即ち、ステップＳ１９０１のライトロックとステップＳ１９０４のリードロックとは、同一のスキャナアプリ２４により行われる。
【０１１６】
このように、同一のスキャナアプリ２４がステップＳ１９０１でライトロックを行ったあとステップＳ１９０４でリードロックを連続して行う場合、後に行うステップＳ１９０４のリードロックにステップＳ１９０１のライトロックに対応するアンロックの役割を持たせることができる。
【０１１７】
したがって、同一のスキャナアプリ２４がライトロックを行ったあとでリードロックを連続して行う場合、先に行ったステップＳ１９０１のライトロックに対応するアンロックを省略できる。
【０１１８】
ステップＳ１９０５では、ＵＣＳ３７が、ユーザ情報の更新終了をスキャナアプリ２４に通知する。また、ステップＳ１９０６ではＵＣＳ３７が、ユーザ情報の更新終了をファックスアプリ２３に通知する。そして、ユーザ情報の取得が終了すると、スキャナアプリ２４はステップＳ１９０７でステップＳ１９０４に対応するアンロックをＵＣＳ３７に行う。
【０１１９】
図１９のアンロック省略処理では、同一のスキャナアプリ２４がライトロックを行ったあとでリードロックを連続して行う場合、先に行ったステップＳ１９０１のライトロックに対応するアンロックを省略できる。
【０１２０】
図１８および図１９のアンロック省略処理を利用することで、リードロックまたはライトロックなどのロックの状態は図２０のように遷移する。図２０は、ロックの一例の状態遷移図である。
【０１２１】
例えばスキャナアプリ２４などのアプリはイニシャライズ（初期化）処理により停止状態からレディー状態に遷移する。レディー状態のアプリは、ＵＣＳ３７に対してアプリ利用申請処理を行うことによりレディー状態から待機中状態に遷移する。
【０１２２】
待機中状態のアプリは、ＵＣＳ３７に対してリードロックまたはライトロックを行うことにより待機中状態からリードロック状態またはライトロック状態に遷移する。なお、リードロック状態のアプリまたはライトロック状態のアプリはアンロックを行うことによりリードロック状態またはライトロック状態から待機中状態に遷移する。リードロック状態のアプリは、ＵＣＳ３７に対してリードロックを行ってもリードロック状態のままである。
【０１２３】
一方、リードロック状態のアプリは、図１８のアンロック省略処理を利用してライトロックを行うことで、アンロックを省略してリードロック状態からライトロック状態に遷移することができる。また、ライトロック状態のアプリは、図１９のアンロック省略処理を利用してリードロックを行うことで、アンロックを省略してライトロック状態からリードロック状態に遷移することができる。
【０１２４】
ところで、ファックスアプリ２３，スキャナアプリ２４などは、ユーザ情報を予め取得しておく必要があるため、ユーザ情報の更新終了を通知されたあと直ぐに更新済みのユーザ情報を取得する。
【０１２５】
一方、起動時にユーザ情報を取得するアプリなどは、ユーザ情報を予め取得しておく必要がないため、ユーザ情報の更新終了を通知されたあと直ぐに更新済みのユーザ情報を取得しなくてもよい。また、ネットファイルアプリ２５などはオペレーションパネル７０にユーザ情報を表示することがなく、ユーザ情報を予め取得しておく必要がないため、ユーザ情報の更新終了を通知されたあと直ぐに更新済みのユーザ情報を取得しなくてもよい。
【０１２６】
したがって、図１１の更新開始通知および更新終了通知は、ユーザ情報を予め取得しておく必要のあるファックスアプリ２３，スキャナアプリ２４などを選択した上で通知することが効率的である。以下、ユーザ情報の変化通知を選択的に通知する変化通知処理について説明する。
【０１２７】
図２１は、本発明によるユーザ情報の変化通知処理を表す第１実施例のシーケンス図である。なお、ファックスアプリ２３およびスキャナアプリ２４はユーザ情報をオペレーションパネル７０に表示することがあるものとする。また、ネットファイルアプリ２５はユーザ情報をオペレーションパネル７０に表示することがないものとする。
【０１２８】
ステップＳ２１０１では、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われる。ステップＳ２１０２では、ＵＣＳ３７が、ユーザ情報の更新開始をスキャナアプリ２４に通知する。また、ステップＳ２１０３では、ＵＣＳ３７が、ユーザ情報の更新開始をファックスアプリ２３に通知する。
【０１２９】
なお、ＵＣＳ３７はユーザ情報の更新開始をネットファイルアプリ２５に通知しない。ネットファイルアプリ２５は、ユーザ情報や図１２または図１３の画面をオペレーションパネル７０に表示することがないためである。
【０１３０】
ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ２１０４でステップＳ２１０１に対応するアンロックをＵＣＳ３７に行う。ステップＳ２１０５では、ＵＣＳ３７が、ユーザ情報の更新終了をスキャナアプリ２４に通知する。また、ステップＳ２１０６では、ＵＣＳ３７が、ユーザ情報の更新終了をファックスアプリ２３に通知する。
【０１３１】
なお、ＵＣＳ３７はユーザ情報の更新終了をネットファイルアプリ２５に通知しない。ネットファイルアプリ２５は、ユーザ情報や図１２または図１３の画面をオペレーションパネル７０に表示することがなく、又、更新済みのユーザ情報を必ずしも更新直後に取得しなくてもよいためである。
【０１３２】
ユーザ情報の更新終了を通知されると、スキャナアプリ２４はステップＳ２１１０でＵＣＳ３７に対してリードロックを行う。また、ファックスアプリ２３はステップＳ２１１１でＵＣＳ３７に対してリードロックを行う。
【０１３３】
ユーザ情報の取得が終了すると、スキャナアプリ２４はステップＳ２１１２でステップＳ２１１０に対応するアンロックをＵＣＳ３７に行って、ユーザ情報の取得処理を終了する。また、ファックスアプリ２３はステップＳ２１１３でステップＳ２１１１に対応するアンロックをＵＣＳ３７に行って、ユーザ情報の取得処理を終了する。図２１の変化通知処理では、無駄な更新開始通知及び更新終了通知を省略することで、融合機１のリソースを節約できる。
【０１３４】
図２２は、本発明によるユーザ情報の変化通知処理を表す第２実施例のシーケンス図である。ステップＳ２２０１では、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われる。
【０１３５】
ステップＳ２２０２では、ＵＣＳ３７が、ユーザ情報の更新開始をスキャナアプリ２４に通知する。また、ステップＳ２２０３では、ＵＣＳ３７が、ユーザ情報の更新開始をファックスアプリ２３に通知する。ここでは、ユーザ情報の更新が行われなかったものとする。
【０１３６】
スキャナアプリ２４はステップＳ２２０４でステップＳ２２０１に対応するアンロックをＵＣＳ３７に行う。ステップＳ１５０５では、ＵＣＳ３７が、ユーザ情報の更新終了をスキャナアプリ２４に通知する。また、ステップＳ２２０６では、ＵＣＳ３７が、ユーザ情報の更新終了をファックスアプリ２３に通知する。
【０１３７】
なお、ステップＳ２２０５およびステップＳ２２０６で通知される更新終了通知にユーザ情報の更新が行われなかったことを表す情報を含ませておき、ファックスアプリ２３およびスキャナアプリ２４にユーザ情報の取得処理を省略させることができる。図２２の変化通知処理では、無駄なユーザ情報の取得処理を省略することで、融合機１のリソースを節約できる。
【０１３８】
図２３は、本発明によるユーザ情報の変化通知処理を表す第３実施例のシーケンス図である。ステップＳ２３０１では、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われる。ステップＳ２３０２では、ＵＣＳ３７が、ユーザ情報の更新開始をスキャナアプリ２４に通知する。
【０１３９】
なお、ＵＣＳ３７はユーザ情報の更新開始をネットファイルアプリ２５に通知しない。ネットファイルアプリ２５は、ユーザ情報や図１２または図１３の画面をオペレーションパネル７０に表示することがないためである。
【０１４０】
ステップＳ２３０３では、ネットワーク機器３３１などからユーザ情報の読み出し要求が発生し、ネットファイルアプリ２５からＵＣＳ３７に対してリードロックが行われている。しかし、ステップＳ２３０３のリードロックは、ステップＳ２３０１のライトロックがアンロックされていないため、拒絶される。
【０１４１】
このようにユーザ情報の更新開始通知を省略したネットファイルアプリ２５からリードロックが行われると、ＵＣＳ３７はステップＳ２３０４に進み、省略したユーザ情報の更新開始通知をユーザ情報の状態通知の代わりにネットファイルアプリ２５に通知する。
【０１４２】
ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ２３０５でステップＳ２３０１に対応するアンロックをＵＣＳ３７に行う。ステップＳ２３０６では、ＵＣＳ３７が、ユーザ情報の更新終了をスキャナアプリ２４に通知する。また、ステップＳ２３０７では、ＵＣＳ３７が、ユーザ情報の更新終了をネットファイルアプリ２５に通知する。
【０１４３】
ユーザ情報の更新終了を通知されると、スキャナアプリ２４およびネットファイルアプリ２５はユーザ情報の取得を行う。図２３の変化通知処理では、省略した更新開始通知を必要に応じて後から行うことができる。
【０１４４】
図２４は、本発明によるユーザ情報の変化通知処理を表す第４実施例のシーケンス図である。ステップＳ２４０１では、スキャナアプリ２４からＵＣＳ３７に対してライトロックが行われる。ステップＳ２４０２では、ＵＣＳ３７が、ユーザ情報の更新開始をスキャナアプリ２４に通知する。
【０１４５】
なお、ファックスアプリ２３は、この時点でＵＣＳ３７に対して利用申請を行っていないため、ユーザ情報の更新開始が通知されない。ステップＳ２４０３では、ファックスアプリ２３が、ＵＣＳ３７に対して利用申請を行っている。
【０１４６】
このようにユーザ情報の更新開始を通知したあとでファックスアプリ２３から利用申請が行われると、ＵＣＳ３７はステップＳ２４０４に進み、ユーザ情報の更新開始通知をファックスアプリ２３に通知する。したがって、ファックスアプリ２３はユーザ情報が更新される可能性を認識できる。
【０１４７】
ユーザ情報の更新が終了すると、スキャナアプリ２４はステップＳ２４０５でステップＳ２４０１に対応するアンロックをＵＣＳ３７に行う。ステップＳ２４０６では、ＵＣＳ３７が、ユーザ情報の更新終了をスキャナアプリ２４に通知する。また、ステップＳ２４０７では、ＵＣＳ３７が、ユーザ情報の更新終了をファックスアプリ２３に通知する。
【０１４８】
ユーザ情報の更新終了を通知されると、ファックスアプリ２３およびスキャナアプリ２４はユーザ情報の取得を行う。図２４の変化通知処理では、既に行った更新開始通知を必要に応じて後から行うことができる。
【０１４９】
ところで、ファックスアプリ２３，スキャナアプリ２４などは、ＵＣＳ３７から取得するユーザ情報以外に、オペレータから直接入力されたユーザ情報も利用できる。例えばオペレータは、オペレーションパネル７０に表示されたソフトキーボードを操作することで電子メールアドレスやファックス番号などの宛先を直接入力し、その宛先を選択することもできる。オペレータから直接入力されたユーザ情報は、ショートカット登録を利用することでＵＣＳ３７がＨＤＤ６８に格納して管理しているユーザ情報に追加できる。
【０１５０】
通常、オペレータが宛先を選択したあと、前述したようなライトロック及びアンロックが行われると、ファックスアプリ２３，スキャナアプリ２４などは、宛先が変化した可能性があると判断し、オペレータにより選択された宛先を全て解除する。ユーザ情報の更新開始及び更新終了は、例えば図１２及び図１３のような画面をオペレーションパネル７０に表示することでオペレータに通知される。
【０１５１】
しかし、オペレータが選択した宛先が直接入力された宛先である場合、前述したようなライトロック及びアンロックが行われても宛先が変化する可能性がないため、オペレータにより選択された宛先を無駄に解除していることになる。したがって、オペレータが選択した宛先が直接入力された宛先である場合、その宛先を無駄に解除しないことが効率的である。以下、オペレータが選択した宛先が直接入力された宛先である場合に、その宛先が無駄に解除されないショートカット登録処理について説明する。
【０１５２】
図２５は、本発明によるユーザ情報のショートカット登録処理を表す第１実施例のシーケンス図である。ステップＳ２５０１では、オペレータからのショートカット登録要求に基づき、スキャナアプリ２４からＳＣＳ３８に対してアドレス帳追加のためのアプリオフライン要求が行われる。
【０１５３】
アプリオフライン要求を受信すると、ＳＣＳ３８はステップＳ２５０２に進み、ＵＣＳ３７に対してアドレス帳追加のためのアプリオフライン問い合せを行う。また、ＳＣＳ３８はステップＳ２５０３に進み、スキャナアプリ２４に対してアドレス帳追加のためのアプリオフライン問い合せを行う。
【０１５４】
ステップＳ２５０４では、スキャナアプリ２４が、ＳＣＳ３８に対してアプリオフラインＯＫを通知する。また、ステップＳ２５０５ではＵＣＳ３７が、ＳＣＳ３８に対してアプリオフラインＯＫを通知する。
【０１５５】
アプリオフライン問い合せに対する全てのアプリオフラインＯＫを受信すると、ＳＣＳ３８はステップＳ２５０６に進み、ＵＣＳ３７に対してアドレス帳追加のためのアプリオフライン確定結果を通知する。また、ＳＣＳ３８はステップＳ２５０７に進み、スキャナアプリ２４に対してアドレス帳追加のためのアプリオフライン確定結果を通知する。
【０１５６】
アプリオフライン確定結果を通知したあと、ＳＣＳ３８はステップＳ２５０８でＵＣＳ３７に対してライトロックを行う。ステップＳ２５０９では、ＵＣＳ３７が、ユーザ情報の更新開始をＳＣＳ３８に通知する。また、ステップＳ２５１０では、ＵＣＳ３７が、ユーザ情報の更新開始をスキャナアプリ２４に通知する。
【０１５７】
ユーザ情報の使用および更新が終了すると、ＳＣＳ３８はステップＳ２５１１でステップＳ２５０８に対応するアンロックをＵＣＳ３７に対して行う。ステップＳ２５１２では、ＵＣＳ３７が、ユーザ情報の更新終了をＳＣＳ３８に通知する。また、ステップＳ２５１３では、ＵＣＳ３７が、ユーザ情報の更新終了をスキャナアプリ２４に通知する。
【０１５８】
ユーザ情報の更新終了を通知されると、スキャナアプリ２４はステップＳ２５１４でＵＣＳ３７に対してリードロックを行う。ステップＳ２５１５に進み、スキャナアプリ２４はアドレス帳再取得を行う。アドレス帳の再取得が終了すると、スキャナアプリ２４はステップＳ２５１６でステップＳ２５１４に対応するアンロックをＵＣＳ３７に対して行って、ユーザ情報のショートカット登録処理を終了する。
【０１５９】
図２５のショートカット登録処理では、オペレータが選択した宛先が直接入力された宛先である場合に、その宛先が無駄に解除されないため、オペレータが同じ宛先を何度も直接入力して選択することが無くなり、融合機１のリソースを節約できる。
【０１６０】
ところで、融合機１では個人またはグループによる文書データのアクセス権を文書アクセスコントロールリスト（以下、文書ＡＣＬという）により管理している。通常、文書ＡＣＬはユーザ情報が更新されたとき、そのユーザ情報の内容を反映させる見直し処理が行われる。
【０１６１】
しかし、ユーザ情報に含まれる例えば名前やグループ等が更新されたとしても文書ＡＣＬは影響を受けないため、ユーザ情報が更新されたときに無駄な見直し処理を行っていることになる。したがって、更新されたユーザ情報の内容が文書ＡＣＬに影響を与えない場合、文書ＡＣＬの見直し処理を行わないことが効率的である。以下、更新されたユーザ情報の内容が文書ＡＣＬに影響を与えない場合、文書ＡＣＬの見直し処理を直ぐに行わないショートカット登録処理について説明する。
【０１６２】
図２６は、本発明によるユーザ情報のショートカット登録処理を表す第２実施例のシーケンス図である。ステップＳ２６０１では、オペレータからのショートカット登録要求に基づき、ＭＣＳ３６からＳＣＳ３８に対してアドレス帳追加のためのアプリオフライン要求が行われる。
【０１６３】
アプリオフライン要求を受信すると、ＳＣＳ３８はステップＳ２６０２に進み、ＵＣＳ３７に対してアドレス帳追加のためのアプリオフライン問い合せを行う。また、ＳＣＳ３８はステップＳ２６０３に進み、ＭＣＳ３６に対してアドレス帳追加のためのアプリオフライン問い合せを行う。ステップＳ２６０４では、ＭＣＳ３６が、ＳＣＳ３８に対してアプリオフラインＯＫを通知する。また、ステップＳ２６０５ではＵＣＳ３７が、ＳＣＳ３８に対してアプリオフラインＯＫを通知する。
【０１６４】
アプリオフライン問い合せに対する全てのアプリオフラインＯＫを受信すると、ＳＣＳ３８はステップＳ２６０６に進み、ＵＣＳ３７に対してアドレス帳追加のためのアプリオフライン確定結果を通知する。また、ＳＣＳ３８はステップＳ２６０７に進み、ＭＣＳ３６に対してアドレス帳追加のためのアプリオフライン確定結果を通知する。
【０１６５】
アプリオフライン確定結果を通知したあと、ＳＣＳ３８はステップＳ２６０８でＵＣＳ３７に対してライトロックを行う。ステップＳ２６０９に進み、ＵＣＳ３７はユーザ情報の更新開始をＳＣＳ３８に通知する。また、ＵＣＳ３７はステップＳ２６１０に進み、ＭＣＳ３６に対してユーザ情報の更新開始を通知する。そして、ＵＣＳ３７はユーザ情報の更新を行う。ここでは、更新されたユーザ情報の内容が文書ＡＣＬに影響を与えない例として、アドレス帳のメンバが増減しないユーザ情報の更新が行われたとする。
【０１６６】
ユーザ情報の使用および更新が終了すると、ＳＣＳ３８はステップＳ２６１１でステップＳ２６０８に対応するアンロックをＵＣＳ３７に対して行う。ステップＳ２６１２に進み、ＵＣＳ３７はユーザ情報の更新終了をＳＣＳ３８に通知する。また、ステップＳ２６１３に進み、ＵＣＳ３７はユーザ情報の更新終了をＭＣＳ３６に通知する。
【０１６７】
なお、ステップＳ２６１２及びＳ２６１３で通知される更新終了通知には、アドレス帳のメンバが増減しなかったことを表す情報として「メンバ増減なし」が含まれる。したがって、ステップＳ２６１３の更新終了通知を受信したＭＣＳ３６は、更新されたユーザ情報の内容が文書ＡＣＬに影響を与えないと判定し、文書ＡＣＬの見直し処理を省略することができる。図２６のショートカット登録処理では、無駄な文書ＡＣＬの見直し処理を省略することで、融合機１のリソースを節約できる。
【０１６８】
一方、更新されたユーザ情報の内容が文書ＡＣＬに影響を与える場合、文書ＡＣＬの見直し処理を直ぐに行うショートカット登録処理について説明する。図２７は、本発明によるユーザ情報のショートカット登録処理を表す第３実施例のシーケンス図である。
【０１６９】
ステップＳ２７０１〜Ｓ２７０７の処理は、図２６のステップＳ２６０１〜Ｓ２６０７の処理と同様であるため、説明を省略する。ＭＣＳ３６及びＵＣＳ３７にアプリオフライン確定結果を通知したあと、ＳＣＳ３８はステップＳ２７０８でＵＣＳ３７に対してライトロックを行う。ステップＳ２７０９に進み、ＵＣＳ３７はユーザ情報の更新開始をＳＣＳ３８に通知する。また、ＵＣＳ３７はステップＳ２７１０に進み、ＭＣＳ３６に対してユーザ情報の更新開始を通知する。そして、ＵＣＳ３７はユーザ情報の更新を行う。ここでは、更新されたユーザ情報の内容が文書ＡＣＬに影響を与える例として、アドレス帳のメンバを減少させるユーザ情報の更新が行われたとする。
【０１７０】
ユーザ情報の使用および更新が終了すると、ＳＣＳ３８はステップＳ２７１１でステップＳ２７０８に対応するアンロックをＵＣＳ３７に対して行う。ステップＳ２７１２に進み、ＵＣＳ３７はユーザ情報の更新終了をＳＣＳ３８に通知する。また、ステップＳ２７１３に進み、ＵＣＳ３７はユーザ情報の更新終了をＭＣＳ３６に通知する。
【０１７１】
なお、ステップＳ２７１２及びＳ２７１３で通知される更新終了通知には、アドレス帳のメンバが減少したことを表す情報として「アドレス帳削除」が含まれる。ステップＳ２７１３の更新終了通知を受信したＭＣＳ３６は、更新されたユーザ情報の内容が文書ＡＣＬに影響を与えると判定し、文書ＡＣＬの見直し処理を開始する。
【０１７２】
ステップＳ２７１４では、ＭＣＳ３６が、ＵＣＳ３７に対してリードロックを行う。ステップＳ２７１５に進み、ＭＣＳ３６はＵＣＳ３７からアドレス帳を再取得する再取得処理を行う。アドレス帳の再取得が終了すると、ＭＣＳ３６はステップＳ２７１６でステップＳ２７１４に対応するアンロックをＵＣＳ３７に対して行う。ＭＣＳ３６は、取得したアドレス帳に基づき文書ＡＣＬの見直し処理を行う。図２７のショートカット登録処理では、更新されたユーザ情報の内容が文書ＡＣＬに影響を与える場合に、文書ＡＣＬの見直し処理を行うことができる。
【０１７３】
ところで、融合機１ではオペレータに使用されない時間帯の消費電力を容易に減少するために、消費電力の小さい省エネモードが用意されている。通常、省エネモードに移行した後でリードロック又はライトロックが行われると、融合機１はリードロック又はライトロックに関するロック制御を以下のように行っている。
【０１７４】
図２８は、省エネモード時のロック制御処理を表す一例のシーケンス図である。ステップＳ２８０１では、ＳＣＳ３８が、ＵＣＳ３７に対して省エネモード移行問い合せを行う。また、ＳＣＳ３８はステップＳ２８０２に進み、ＮＦＡ２５に対して省エネモード移行問い合せを行う。ステップＳ２８０３では、ＵＣＳ３７が、ＳＣＳ３８に対して省エネモード移行ＯＫを通知する。また、ステップＳ２８０４ではＮＦＡ２５が、ＳＣＳ３８に対して省エネモード移行ＯＫを通知する。
【０１７５】
省エネモード移行問い合せに対する全ての省エネモード移行ＯＫを受信すると、ＳＣＳ３８はステップＳ２８０５に進み、ＵＣＳ３７に対して省エネモード移行確定結果を通知する。また、ＳＣＳ３８はステップＳ２８０６に進み、ＮＦＡ２５に対して省エネモード移行確定結果を通知する。ステップＳ２８０６の処理後、融合機１は省エネモードに移行する。
【０１７６】
省エネモードに移行したあと、例えば外部のネットワーク機器３３１のＷｅｂブラウザからユーザ情報に対するアクセスがあると、ＮＦＡ２５はステップＳ２８０７に進み、ＵＣＳ３７に対してリードロックを行う。ステップＳ２８０８に進み、ＵＣＳ３７は省エネモードに移行しているため、ＳＣＳ３８に対して電力復帰要求を行う。電力復帰要求を受信すると、ＳＣＳ３８は電力モードを復帰させるための処理を行う。
【０１７７】
ＳＣＳ３８は、ステップＳ２８０９に進み、ＵＣＳ３７に対して電力モード復帰を通知する。また、ＳＣＳ３８はステップＳ２８１０に進み、ＭＣＳ３６に対して電力モード復帰を通知する。電力モードが復帰すると、融合機１はＨＤＤ６８等に必要な電力が供給される。
【０１７８】
電力モード復帰を通知されると、ＮＦＡ２５はＵＣＳ３７から必要なユーザ情報の取得する。必要なユーザ情報の取得が終了すると、ＮＦＡ２５はステップＳ２８１１でステップＳ２８０７に対応するアンロックをＵＣＳ３７に対して行う。
【０１７９】
図２８の例では、省エネモード時のロック制御処理に何ら問題がない、しかし、図２９の例では以下のような問題が発生する。図２９は、省エネモード時のロック制御処理に発生する問題を説明するためのシーケンス図である。
【０１８０】
ステップＳ２９０１〜Ｓ２９０６の処理は、図２８のステップＳ２８０１〜Ｓ２８０６の処理と同様であるため、説明を省略する。ステップＳ２９０６の処理後、融合機１は省エネモードに移行する。
【０１８１】
省エネモードに移行したあと、例えばスキャナアプリ２４は文書データの保存のためのキャプチャ画面の描画を行う場合、ステップＳ２９０７でＳＣＳ３８に対してキャプチャ画面描画要求を行う。キャプチャ画面描画要求を受信すると、ＳＣＳ３８はステップＳ２９０８に進み、ＵＣＳ３７に対してリードロックを行う。
【０１８２】
ステップＳ２９０９に進み、ＵＣＳ３７は省エネモードに移行しているため、ＳＣＳ３８に対して電力復帰要求を行う。しかしながら、ＳＣＳ３８はステップＳ２９０８に対応する応答を受信していないため、ステップＳ２９０９でＵＣＳ３７から電力復帰要求を受信しても電力モードを復帰させるための処理を行わない。言い換えれば、省エネモードに移行したあと、ＳＣＳ３８が電力モードの復帰を必要とする要求を他のプロセスに要求すると、他のプロセスからの電力復帰要求によりデッドロックしてしまう。つまり、図２９の省エネモード時のロック制御処理は、デッドロックしてしまうという問題があった。
【０１８３】
したがって、省エネモード時のロック制御処理では、上記のようなデッドロックに対処する必要がある。図３０は、本発明による省エネモード時のロック制御処理を表す一例のシーケンス図である。
【０１８４】
ステップＳ３００１〜Ｓ３００８の処理は、図２９のステップＳ２９０１〜Ｓ２８０８の処理と同様であるため、説明を省略する。ＳＣＳ３８がＵＣＳ３７に対してリードロックを行うと、ＵＣＳ３７は省エネモードに移行しているか否かを判定し、省エネモードに移行していれば上記のようなデッドロックを避けるため、ＳＣＳ３８に対して電力復帰要求を行わない。そして、ＵＣＳ３７はステップＳ３００９に進み、ＳＣＳ３８に対して省エネモードのためリードロックがＮＧである旨をＳＣＳ３８に通知する。また、ステップＳ３０１０に進み、ＳＣＳ３８はステップＳ２９０７のキャプチャ画面描画要求がＮＧである旨をスキャナアプリ２４に通知する。
【０１８５】
図示はしていないが、この後、ＳＣＳ３８は電力モードを復帰したあとでステップＳ３００８のリードロックを行うことにより、デッドロックさせることなくキャプチャ画面描画要求を行うことができる。
【０１８６】
図３０の省エネモード時のロック制御処理では、省エネモードに移行したあと、ＳＣＳ３８が電力モードの復帰を必要とする要求を他のプロセスに要求すると、他のプロセスからの電力復帰要求によりデッドロックしてしまうという問題を解消できる。この結果、融合機１のリソースを節約できる。
【０１８７】
本発明は上記の実施例に限定されるものではなく、本発明の範囲内で種々の変形や変更が可能である。
【図面の簡単な説明】
【０１８８】
【図１】本発明による融合機の一実施例の構成図である。
【図２】本発明による融合機の一実施例のハードウェア構成図である。
【図３】本発明による共有データ管理方法を説明するためのシステム構成図である。
【図４】ユーザ情報の一例の構成図である。
【図５】リードロックの基本的な処理を表す一例のシーケンス図である。
【図６】リードロックの基本的な処理を表す他の一例のシーケンス図である。
【図７】ライトロックの基本的な処理を表す一例のシーケンス図である。
【図８】ライトロックの基本的な処理を表す他の一例のシーケンス図である。
【図９】リードロックおよびライトロックの基本的な処理を表す一例のシーケンス図である。
【図１０】リードロックおよびライトロックの基本的な処理を表す他の一例のシーケンス図である。
【図１１】ユーザ情報の変化通知処理を表す一例のシーケンス図である。
【図１２】更新開始通知画面の一例のイメージ図である。
【図１３】更新終了通知画面の一例のイメージ図である。
【図１４】拒絶されたライトロックまたはリードロックの管理について説明するための図である。
【図１５】本発明によるライトロック予約処理を表す第１実施例のシーケンス図である。
【図１６】本発明によるライトロック予約処理を表す第２実施例のシーケンス図である。
【図１７】本発明によるリードロック予約処理を表す第１実施例のシーケンス図である。
【図１８】本発明によるアンロック省略処理を表す第１実施例のシーケンス図である。
【図１９】本発明によるアンロック省略処理を表す第２実施例のシーケンス図である。
【図２０】ロックの一例の状態遷移図である。
【図２１】本発明によるユーザ情報の変化通知処理を表す第１実施例のシーケンス図である。
【図２２】本発明によるユーザ情報の変化通知処理を表す第２実施例のシーケンス図である。
【図２３】本発明によるユーザ情報の変化通知処理を表す第３実施例のシーケンス図である。
【図２４】本発明によるユーザ情報の変化通知処理を表す第４実施例のシーケンス図である。
【図２５】本発明によるユーザ情報のショートカット登録処理を表す第１実施例のシーケンス図である。
【図２６】本発明によるユーザ情報のショートカット登録処理を表す第２実施例のシーケンス図である。
【図２７】本発明によるユーザ情報のショートカット登録処理を表す第３実施例のシーケンス図である。
【図２８】省エネモード時のロック制御処理を表す一例のシーケンス図である。
【図２９】省エネモード時のロック制御処理に発生する問題を説明するためのシーケンス図である。
【図３０】本発明による省エネモード時のロック制御処理を表す一例のシーケンス図である。
【符号の説明】
【０１８９】
１    融合機
２    ソフトウェア群
３    融合機起動部
４    ハードウェア資源
５    アプリケーション層
６    プラットフォーム
９    コントロールサービス層
１０    ハンドラ層
１１    白黒レーザプリンタ（Ｂ＆Ｗ  ＬＰ）
１２    カラーレーザプリンタ（Ｃｏｌｏｒ  ＬＰ）
１３    ハードウェアリソース
２１    プリンタアプリ
２２    コピーアプリ
２３    ファックスアプリ
２４    スキャナアプリ
２５    ネットファイルアプリ
３１    ネットワークコントロールサービス（ＮＣＳ）
３２    デリバリーコントロールサービス（ＤＣＳ）
３３    オペレーションパネルコントロールサービス（ＯＣＳ）
３４    ファックスコントロールサービス（ＦＣＳ）
３５    エンジンコントロールサービス（ＥＣＳ）
３６    メモリコントロールサービス（ＭＣＳ）
３７    ユーザインフォメーションコントロールサービス（ＵＣＳ）
３８    システムコントロールサービス（ＳＣＳ）
３９    システムリソースマネージャ（ＳＲＭ）
４０    ファックスコントロールユニットハンドラ（ＦＣＵＨ）
４１    イメージメモリハンドラ（ＩＭＨ）
５３    アプリケーションプログラムインターフェース（ＡＰＩ）
５４    エンジンＩ／Ｆ
６０    コントローラ
６１    ＣＰＵ
６２    システムメモリ（ＭＥＭ−Ｐ）
６３    ノースブリッジ（ＮＢ）
６４    サウスブリッジ（ＳＢ）
６５    ＡＧＰ（Accelerated Graphics Port）
６６    ＡＳＩＣ
６７    ローカルメモリ（ＭＥＭ−Ｃ）
６８    ハードディスク装置（ＨＤＤ）
６９    ネットワークインターフェースコントローラ
７０    オペレーションパネル
８０    ファックスコントロールユニット（ＦＣＵ）
９０    ＵＳＢデバイス
１００    ＩＥＥＥ１３９４デバイス
１１０    エンジン部
３３０    ネットワーク
３３１，３３２    ネットワーク機器
【図１】
2008118672.tif 000003
【図２】
2008118672.tif 000004
【図３】
2008118672.tif 000005
【図４】
2008118672.tif 000006
【図５】
2008118672.tif 000007
【図６】
2008118672.tif 000008
【図７】
2008118672.tif 000009
【図８】
2008118672.tif 000010
【図９】
2008118672.tif 000011
【図１０】
2008118672.tif 000012
【図１１】
2008118672.tif 000013
【図１２】
2008118672.tif 000014
【図１３】
2008118672.tif 000015
【図１４】
2008118672.tif 000016
【図１５】
2008118672.tif 000017
【図１６】
2008118672.tif 000018
【図１７】
2008118672.tif 000019
【図１８】
2008118672.tif 000020
【図１９】
2008118672.tif 000021
【図２０】
2008118672.tif 000022
【図２１】
2008118672.tif 000023
【図２２】
2008118672.tif 000024
【図２３】
2008118672.tif 000025
【図２４】
2008118672.tif 000026
【図２５】
2008118672.tif 000027
【図２６】
2008118672.tif 000028
【図２７】
2008118672.tif 000029
【図２８】
2008118672.tif 000030
【図２９】
2008118672.tif 000031
【図３０】
2008118672.tif 000032
【手続補正書】
【提出日】平成19年11月30日(2007.11.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
共有データを格納する格納手段と、
前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求をアプリケーション又はプログラムの何れかから受信すると前記取得開始要求又は更新開始要求を一時的に保留し、
前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を許可するプログラムの一つである共有データ管理手段とを有し、
前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする画像形成装置。
【請求項２】
共有データを格納する格納手段と、
アプリケーション又はプログラムの何れかから受信した前記共有データに対する更新開始要求に基づき、前記共有データの取得及び更新を禁止するときに、アプリケーション又はプログラムから前記共有データの更新開始を通知すべき通知先を選択し、選択した通知先に前記共有データの更新開始を通知する一方、
前記共有データに対する更新開始要求元からの前記共有データに対する更新終了要求に基づき、前記共有データの取得及び更新を可能とするときに、前記共有データの更新開始を通知した通知先に前記共有データの更新終了を通知するプログラムの一つである共有データ管理手段とを有し、
前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする画像形成装置。
【請求項３】
共有データを格納する格納手段と、
前記格納手段に新たに追加する共有データが操作者から入力される前に、前記共有データの入力処理に利用するアプリケーション又はプログラムの何れか以外からの前記共有データの取得及び更新を禁止し、アプリケーション又はプログラムに前記共有データの更新開始を通知する一方、
アプリケーション又はプログラムの何れかからの前記共有データに対する更新終了要求に基づき、前記共有データの取得及び更新を可能とするときに、前記共有データの更新開始を通知した通知先に前記共有データの更新終了を通知する共有データ管理手段とを有し、
前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする画像形成装置。
【請求項４】
共有データを格納手段が格納する段階と、
プログラムの一つである共有データ管理手段が、前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求をアプリケーション又はプログラムの何れかから受信すると前記取得開始要求又は更新開始要求を一時的に保留する段階と、
前記共有データ管理手段が、前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を許可する段階とを有し、
前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする画像形成装置の共有データ管理方法。
【請求項５】
共有データを格納手段が格納する段階と、
プログラムの一つである共有データ管理手段が、アプリケーション又はプログラムの何れかから受信した前記共有データに対する更新開始要求に基づき、前記共有データの取得及び更新を禁止するときに、アプリケーション又はプログラムから前記共有データの更新開始を通知すべき通知先を選択し、選択した通知先に前記共有データの更新開始を通知する段階と、
前記共有データ管理手段が、前記共有データに対する更新開始要求元からの前記共有データに対する更新終了要求に基づき、前記共有データの取得及び更新を可能とするときに、前記共有データの更新開始を通知した通知先に前記共有データの更新終了を通知する段階とを有し、
前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする画像形成装置の共有データ管理方法。
【請求項６】
共有データを格納手段が格納する段階と、
プログラムの一つである共有データ管理手段が、前記格納手段に新たに追加する共有データが操作者から入力される前に、前記共有データの入力処理に利用するアプリケーション又はプログラムの何れか以外からの前記共有データの取得及び更新を禁止し、アプリケーション又はプログラムに前記共有データの更新開始を通知する段階と、
アプリケーション又はプログラムの何れかからの前記共有データに対する更新終了要求に基づき、前記共有データの取得及び更新を可能とするときに、前記共有データの更新開始を通知した通知先に前記共有データの更新終了を通知する段階とを有し、
前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする画像形成装置の共有データ管理方法。
【請求項７】
１つ以上の外部のネットワーク機器と、前記外部のネットワーク機器にネットワークを介して接続された画像形成装置とを用いて、前記画像形成装置のプログラムが利用する書き換え可能な共有データの管理を行う共有データ管理システムであって、
前記画像形成装置は、
前記共有データを格納する格納手段と、
前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求をアプリケーション又はプログラムの何れかから受信すると前記取得開始要求又は更新開始要求を一時的に保留し、
前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を許可するプログラムの一つである共有データ管理手段とを有し、
前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする共有データ管理システム。
【請求項８】
１つ以上の外部のネットワーク機器と、前記外部のネットワーク機器にネットワークを介して接続された画像形成装置とを用いて、前記画像形成装置が利用する書き換え可能な共有データの管理を行う共有データ管理システムであって、
前記画像形成装置は、
前記共有データを格納する格納手段と、
アプリケーション又はプログラムの何れかから受信した前記共有データに対する更新開始要求に基づき、前記共有データの取得及び更新を禁止するときに、アプリケーション又はプログラムから前記共有データの更新開始を通知すべき通知先を選択し、選択した通知先に前記共有データの更新開始を通知する一方、
前記共有データに対する更新開始要求元からの前記共有データに対する更新終了要求に基づき、前記共有データの取得及び更新を可能とするときに、前記共有データの更新開始を通知した通知先に前記共有データの更新終了を通知するプログラムの一つである共有データ管理手段とを有し、
前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする共有データ管理システム。
【請求項９】
１つ以上の外部のネットワーク機器と、前記外部のネットワーク機器にネットワークを介して接続された画像形成装置とを用いて、前記画像形成装置が利用する書き換え可能な共有データの管理を行う共有データ管理システムであって、
前記画像形成装置は、
前記共有データを格納する格納手段と、
前記格納手段に新たに追加する共有データが操作者から入力される前に、前記共有データの入力処理に利用するアプリケーション又はプログラムの何れか以外からの前記共有データの取得及び更新を禁止し、アプリケーション又はプログラムに前記共有データの更新開始を通知する一方、
アプリケーション又はプログラムの何れかからの前記共有データに対する更新終了要求に基づき、前記共有データの取得及び更新を可能とするときに、前記共有データの更新開始を通知した通知先に前記共有データの更新終了を通知する共有データ管理手段とを有し、
前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする共有データ管理システム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】変更
【補正の内容】
【００１１】
そこで、上記課題を解決するため、本発明の画像形成装置は、共有データを格納する格納手段と、前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求をアプリケーション又はプログラムの何れかから受信すると前記取得開始要求又は更新開始要求を一時的に保留し、前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を許可するプログラムの一つである共有データ管理手段とを有し、前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】変更
【補正の内容】
【００１２】
また、本発明の画像形成装置の共有データ管理方法は、共有データを格納手段が格納する段階と、プログラムの一つである共有データ管理手段が、前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求をアプリケーション又はプログラムの何れかから受信すると前記取得開始要求又は更新開始要求を一時的に保留する段階と、前記共有データ管理手段が、前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を許可する段階とを有し、前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１３
【補正方法】変更
【補正の内容】
【００１３】
また、本発明は、１つ以上の外部のネットワーク機器と、前記外部のネットワーク機器にネットワークを介して接続された画像形成装置とを用いて、前記画像形成装置のプログラムが利用する書き換え可能な共有データの管理を行う共有データ管理システムであって、前記画像形成装置は、前記共有データを格納する格納手段と、前記共有データの更新又は前記共有データの取得及び更新が禁止されているときに、その禁止により処理できない前記共有データに対する取得開始要求又は更新開始要求をアプリケーション又はプログラムの何れかから受信すると前記取得開始要求又は更新開始要求を一時的に保留し、前記共有データの更新又は前記共有データの取得及び更新が可能となると、前記保留した取得開始要求又は更新開始要求に応じて前記共有データの更新又は前記共有データの取得及び更新を許可するプログラムの一つである共有データ管理手段とを有し、前記共有データ管理手段は、消費電力を抑えるための省電力モードであるときに、前記共有データに対する取得開始要求又は更新開始要求を受信すると、前記取得開始要求又は更新開始要求の要求元と前記省電力モードから通常電力モードに移行させるための電力復帰要求の要求先とが同一のとき、前記共有データに対する取得開始要求又は更新開始要求を拒絶することを特徴とする。