JP6069995B2 - 情報処理システム及び情報送信方法 - Google Patents

Description

この発明は、複数のモジュールを備えた情報処理システムと、このような情報処理システムにおける情報送信方法に関する。

従来から、情報処理装置に複数のモジュールを設け、そのモジュール間で通信を行うことが知られている。例えば、ＭＦＰ（デジタル複合機）のような情報処理機能を備えた画像処理装置において、コントローラ部とＵＩ（ユーザインタフェース）部を設け、これらの間でデータを送受信することが知られている。
また、このような通信を行う際、パケットという情報の伝達単位を用い、パケットサイズを一定にして通信を行う技術が既に知られている。

例えば、特許文献１には、簡単なハードウェア構成で、かつ、プロトコルオーバヘッドが少ないコントローラとエンジンの通信方法を実現するため、以下の（１）〜（３）に示すような構成について開示されている。
（１）共有メモリを使用したデータの受け渡しを行う。
（２）共有メモリサイズを超えるデータは、複数回に分けてパケット送信を行う。
（３）送信側と受信側で１パケット毎にハンドシェーク（書き込み完了と読み込み完了の通知）を行う。

しかしながら、このようにパケットサイズ固定の通信を行う場合、サイズの小さいコマンドの伝送等の際にオーバヘッドが大きくならないよう、パケットサイズは比較的小さくすることが通常である。しかし、このようにすると、描画データのような大量のデータ通信を実施する場合、パケット数が膨大になってしまう。更に、１パケット毎にハンドシェークが実行されるため、ハンドシェークにかかる処理時間が大きくなってしまう。その結果、全体の通信時間が長くなるという問題があった。

特許文献１に記載の印刷装置においても、画像データのような大量なデータを送る場合は、多くのパケットを送信する必要がある。よって、１パケット毎にハンドシェークをするため、パケット数が増えるとハンドシェークも比例して増えるため、無駄な時間がかかってしまう。また、パケット数が増えるとそれに比例してハンドシェークによるオーバヘッドも増える。つまり、大量のデータを送る場合のハンドシェークの問題は解消できていない。
また、このような問題は、コントローラ部とＵＩ部の間の通信以外でも、画像処理装置以外の情報処理装置においても、同様に発生するものである。

この発明は、上記の点に鑑みてなされたものであり、情報処理システムにおいて、モジュール間のデータ送信を短時間で行えるようにすることを目的とする。

この発明は、第１のモジュールと第２のモジュールとを備え、上記第１のモジュールと上記第２のモジュールとの間でデータを送受信する際に、該データを一定サイズのパケットに分割して送受信する情報処理システムであって、上記の目的を達成するため、上記第１のモジュールが、上記第２のモジュールに送信しようとするデータの種類又はサイズに応じて、動的に上記パケットのサイズを所定の基本サイズから変更する変更手段を備え、
上記第２のモジュールに、上記変更手段による変更後のパケットサイズでデータを受信中に上記第１のモジュールへ送信すべきデータを検出した場合に、上記第１のモジュールに対してパケットのサイズを上記基本サイズに戻すことを要求する要求手段を備えるものである。

上記構成によれば、モジュール間のデータ送信を短時間で行えるようにすることができる。

この発明による情報処理システムの一実施形態である画像形成装置のハードウェア構成例を示すブロック図である。 図１のコントローラ部のソフトウェア構成およびエンジン部のハードウェア構成を示すブロック図である。 図２に示した画像形成装置のうちコントローラ部と操作部との間の通信に関する機能の構成を示すブロック図である。 図１のコントローラ部によるデータ送信処理の一例を示すフローチャートである。 図１のコントローラ部とＵＩ部との間のパケット通信のシーケンスの一例を示す図である。 比較例におけるコントローラ部とＵＩ部との間のパケット通信のシーケンスの一例を示す図である。

以下、この発明を実施するための形態について具体的に説明する。
図１は、この発明による情報処理システムの一実施形態である画像形成装置のハードウェア構成例を示すブロック図である。
この画像形成装置１は、例えば複合機であり、図１に示すように、コントローラ部１０、ＵＩ（ユーザインタフェース）部２０、およびエンジン部３０を備え、それらをシステムバス５０により接続した構成としている。

コントローラ部１０は、第１のモジュールであり、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、通信Ｉ／Ｆ（インタフェース）１４、およびＨＤＤ（ハードディスク装置）１５を備えている。そして、ＣＰＵ１１が、ＲＡＭ１３をワークエリアとしてＲＯＭ１２又はＨＤＤ１５に記憶されたプログラムを実行することにより、後述するＵＩ部２０との通信に係る機能をはじめとする各種機能を実現し、ＵＩ部２０及びエンジン部３０をはじめとする画像形成装置１全体を制御する。

通信Ｉ／Ｆ１４は、図示しないネットワークを介してコンピュータ等の外部機器と通信するためのインタフェースである。
ＨＤＤ１５は、不揮発性記憶媒体であり、後述するアプリケーションやプラットフォーム等の各種処理を実現するためのプログラムを含む各種データを格納している。

ＵＩ部２０は、第２のモジュールであり、ユーザの操作を受け付けるための操作部や、ユーザに情報を提示するための表示部と、操作部および表示部の制御やコントローラ部１０との通信制御を行う制御部とを備えている。
エンジン部３０は、後述するプリンタ機能，スキャナ機能，コピー機能，ＦＡＸ機能を実現させるため、原稿の画像をスキャンして読み取るスキャナ部（画像読取部）、シート材への印刷を行うプロッタ部（画像形成部）、ファクシミリ通信を行う通信部等を備えている。

図２は、図１のコントローラ部１０のソフトウェア構成およびエンジン部３０のハードウェア構成を示すブロック図である。なお、説明の都合上、ＣＰＵ１１が以下に示す各プログラムに従って動作することによって実行する処理について、それらのプログラムが処理を実行するものとして説明する。
エンジン部３０のハードウェア構成は、上述したプロッタ部を構成する白黒画像形成部３０１およびカラー画像形成部３０２と、スキャナ部を含むその他ハードウェアリソース３０３とを含んで構成される。

コントローラ部１０のソフトウェア構成は、最上位のアプリケーションモジュール（アプリ）層、その下位のサービスモジュール層からなる。そして、これらのソフトウェアを構成するプログラムはＨＤＤ１５やＲＯＭ１２に記憶され、必要に応じて読み出されてＣＰＵ１１によって実行される。そしてＣＰＵ１１は、これらのプログラムを必要に応じて実行することにより、各種機能を実現することができる。
ＯＳ１０１は、ＵＮＩＸ（登録商標）などのオペレーティングシステムであり、サービスモジュール層およびアプリケーションモジュール層の各プログラムをそれぞれプロセスとして並列実行する。

サービスモジュール層には、ブラウザコントロールサービス（ＢＣＳ）１１１、エンジンコントロールサービス（ＥＣＳ）１１２、メモリコントロールサービス（ＭＣＳ）１１３、ファクスコントロールサービス（ＦＣＳ）１１４、オペレーションコントロールサービス（ＯＣＳ）１１５、ネットワークコントロールサービス（ＮＣＳ）１１６、システムコントロールサービス（ＳＣＳ）１１７、およびシステムリソースマネージャ（ＳＲＭ）１１８を実装している。
アプリケーションモジュール層には、ブラウザアプリ２０１、プリンタアプリ２０２、コピーアプリ２０３、ファクスアプリ２０４、ネットファイルアプリ２０５、および工程検査アプリ２０６を実装している。

これらを更に詳述する。
ＢＣＳ１１１は、Ｗｅｂページに関する処理制御を行う。
ＥＣＳ１１２は、ハードウェアリソース等のエンジン部３０を制御するモジュールである。
ＭＣＳ１１３は、メモリ制御をするモジュールであり、例えば、ＲＡＭ１３の画像メモリの取得および開放、ＨＤＤ１５の利用等を行う。
ＦＣＳ１１４は、ファクシミリ送受信、ファクシミリ読み取り、ファクシミリ受信印刷等を行うモジュールである。

ＯＣＳ１１５は、ＵＩ部２０を制御するモジュールである。
ＮＣＳ１１６は、ネットワークとアプリケーションモジュール層の各アプリケーションプログラムとの仲介処理を行わせるモジュールである。
ＳＣＳ１１７は、コマンドの内容に応じたアプリケーションモジュール層の各アプリケーションプログラムの起動管理および終了管理を行うモジュールである。
ＳＲＭ１１８は、システムの制御およびリソースの管理を行うモジュールである。

ブラウザアプリ２０１は、Ｗｅｂブラウザの操作感を提供するＧＵＩ（Graphical User Interface）をＵＩ部２０に表示させる。つまり、画像形成装置１のユーザは、ブラウザアプリ２０１を利用して、Ｗｅｂブラウザと同様の操作によって、任意のＷｅｂページにアクセスすることができる。
プリンタアプリ２０２は、プリンタサービスを実現するためのアプリケーションプログラムである。
コピーアプリ２０３は、コピーサービスを実現するためのアプリケーションプログラムである。

ファクスアプリ２０４は、ファクスサービスを実現するためのアプリケーションプログラムである。
ネットファイルアプリ２０５は、ネットファイルサービスを実現するためのアプリケーションプログラムである。
工程検査アプリ２０６は、各処理工程の検査サービスを実現するためのアプリケーションプログラムである。

以下、この画像形成装置１におけるこの発明に直接関わるデータ送信処理について図３〜図５を参照して具体的に説明するが、その説明に入る前に、理解の便宜のため、比較例のデータ送信処理およびそれによる課題等について、図６を参照して説明する。なお、説明の都合上、図１のハードウェア構成を前提として説明する。

図６は、比較例におけるコントローラ部１０とＵＩ部２０との間のパケット通信のシーケンスの一例を示す図である。
この比較例におけるパケット通信のシーケンスは、パケットサイズが固定である。
ＵＩ部２０は、コントローラ部１０へデータを送信する場合、図６の（ａ）に示すように、基本サイズのパケットに分割したデータを順次コントローラ部１０に送信する（Ｓ１０１ａ〜Ｓ１０１ｎ）。

例えば、基本サイズが１パケット６４バイトのパケット通信の場合、６４バイト以上のデータを６４バイトに分割して順次コントローラ部１０へ送信する。このとき、図示は省略するが、パケット情報も送信する。そのパケット情報とは、パケットを送信する際に必要な後述するＡＣＫ，ＰＡＫ等の制御信号（制御コード）や対応するパケットに関する情報に相当するものであるが、パケットに関する情報は先頭又は最終のパケットのヘッダ等に付加されていてもよい。
パケットに関する情報の中には、データ全体のパケット数を示す情報が含まれているため、データを受信する側のコントローラ部１０では、次の判断を行う。

すなわち、受信したパケット情報に基づいて、ＵＩ部２０から全部のデータが正常に送信されたかどうかを判断する。
そして、全部のデータが正常に送信されたと判断した場合に、データを正常に受信できた旨を伝える信号ＡＣＫをデータ送信元のＵＩ部２０に送信する（Ｓ１０２）。もし、ＵＩ部２０からデータが正常に送信されていないと判断した場合には、データを正常に受信できなかった旨を伝える信号ＮＡＣＫをデータ送信元のＵＩ部２０に送信する。

一方、コントローラ部１０がＵＩ部２０へデータを送信する場合、図６の（ｂ）に示すように、基本サイズのパケットに分割したデータ、例えば６４バイトに分割したデータを順次ＵＩ部２０に送信する（Ｓ２０１ａ〜Ｓ２０１ｎ）。
ＵＩ部２０は、コントローラ部１０から１パケットのデータを受信する毎に、次のパケット送信を許可する信号ＰＡＫをコントローラ部１０に送信するという通信を繰り返す（Ｓ２０２ａ〜Ｓ２０２ｎ）。
コントローラ部１０は、ＵＩ部２０から信号ＰＡＫを受信する毎に、次の１パケットのデータを送信するという通信を繰り返す（Ｓ２０１ｂ〜Ｓ２０１ｎ）。

ここで、１パケット６４バイトとしたパケット通信の場合、信号ＡＣＫ，ＰＡＫ、ＮＡＣＫのパケットサイズもデータと同じ６４バイトとなる。
この比較例では、コントローラ部１０からＵＩ部２０へデータ送信を行う場合、ＵＩ部２０へ１パケットのデータ毎に信号ＰＡＫが送られるため、オーバヘッドが大きくなる。特に、画像データ（描画データ）など大量のデータ通信が行われる場合は、信号ＡＣＫ、ＰＡＫ、ＮＡＣＫによるオーバヘッドが通信性能に影響を与える可能性がある。

これを踏まえ、この実施形態についてより具体的に説明する。
図３は、図２に示した画像形成装置１の主要機能の構成を示すブロック図である。
この画像形成装置１のコントローラ部１０は、図３に示すように、送信部５００、受信部５１０、および調整部５２０を備えている。それらは、図１のＣＰＵ１１が図２に示したプログラムのうちの対応するプログラムを実行することにより実現することができる。

送信部５００は、パケット送信手段５０１と、パケット情報送信手段５０２とを備えている。
パケット送信手段５０１は、パケットのデータ（以下単に「パケット」ともいう）を指定された通信相手（ここではＵＩ部２０）へ送信する手段であり、送信しようとするデータを一定サイズのパケットに分割する手段としての機能も有している。
パケット情報送信手段５０２は、パケット情報を上記通信相手に送信する手段である。

受信部５１０は、パケット受信手段５１１と、パケット情報受信手段５１２とを備えている。
パケット受信手段５１１は、通信相手からパケットを受信する手段である。
パケット情報受信手段５１２は、通信相手からパケットの情報を受信する手段である。
調整部５２０は、パケットサイズ変更手段５３０を備えている。

パケットサイズ変更手段５３０は、以下の（Ａ１）〜（Ａ４）および（Ｂ１），（Ｂ２）に示す各機能を備えている。
（Ａ１）通信相手に送信しようとするデータの種類又はサイズに応じて、動的に送信パケットのサイズを予め定められた所定の基本サイズ（「通常サイズ」ともいう）からより大きなサイズに変更する。
（Ａ２）送信パケットのサイズの変更に先立ち、パケットサイズが変更される旨を伝える信号ＰＳＥをパケット送信手段５０１によって通信相手へ送信させる。

（Ａ３）パケット情報受信手段５１２が通信相手から割り込み要求（送信パケットのサイズを基本サイズに戻すことの要求）を受信すると、送信パケットのサイズを基本サイズに戻す。その後、パケット情報受信手段５１２が通信相手から送信されるデータを受信し、その受信が完了した後、再度送信パケットのサイズを基本サイズから変更する。
（Ａ４）送信パケットのサイズ変更を無効にする。この機能は、通信相手からの指示により、送信パケットのサイズ変更を無効にする設定がなされていた場合に、実現することができる。

（Ｂ１）パケット情報受信手段５１２が通信相手から信号ＰＳＥを受信すると、その信号ＰＳＥに応じて受信パケットサイズを所定の基本サイズから変更する。
（Ｂ２）変更後のパケットサイズでデータを受信中に通信相手へ送信すべきデータを検出した場合に、通信相手に対してデータを割り込みで送信する旨を伝える信号ＰＡＫ２（割り込み要求）をパケット情報送信手段５０２によって送信させる（受信パケットのサイズを基本サイズに戻すことを要求させる）。

パケットサイズ変更手段５３０はまた、パケットサイズ復帰手段５３１、パケットサイズ自動リセット手段５３２、割り込み拒否手段５３３、およびパケット送受信中断・再開・切替制御手段５３４としての機能も有している。
パケットサイズ復帰手段５３１は、パケット送信手段５０１による変更したサイズでのパケットの送信が完了した場合に、送信パケットのサイズを基本サイズに戻す手段である。
パケットサイズ自動リセット手段５３２は、送信パケットのサイズが所定の基本サイズから変更された後のパケットサイズでパケット送信手段５０１によって所定パケット数の送信が実行された場合に、送信パケットのサイズを基本サイズに戻す（自動リセットする）手段である。

割り込み拒否手段５３３は、通信相手に対して信号ＰＡＫ２（割り込み要求）を拒否する手段である。この機能は、信号ＰＡＫ２を拒否する設定がなされている場合に有効となる。
パケット送受信中断・再開・切替制御手段５３４は、パケット送信手段５０１によるパケットの送信及びパケット受信手段５１１によるパケットの受信の中断、再開、パケットサイズの切り替えを制御する手段である。

一方、画像形成装置１のＵＩ部２０は、図３に示すように、送信部６００、受信部６１０、調整部６２０、および検知部６３０を備えている。それらも、図１のＣＰＵ１１が図２に示したプログラムのうちの対応するプログラムを実行することにより実現することができる。

送信部６００は、パケット送信手段６０１と、パケット情報送信手段６０２とを備えている。これらの機能は、コントローラ部１０の送信部５００における各手段と同様である。
受信部６１０は、パケット受信手段６１１と、パケット情報受信手段６１２とを備えている。これらの機能も、コントローラ部１０の受信部５１０における各手段と同様である。

調整部６２０内のパケットサイズ変更手段６５０は、パケットサイズ復帰手段６５１と、パケットサイズ自動リセット手段６５２と、割り込み拒否手段６５３と、パケット送受信中断・再開・切替制御手段６５４としての機能も有している。これらの機能を含むパケットサイズ変更手段６５０の機能も、コントローラ部１０のパケットサイズ変更手段５３０及びそこに備える各手段と同様である。
検知部６３０は、キー操作検知手段６３１を備えている。このキー操作検知手段６３１は、ＵＩ部２０の操作部上のキーの押下（ユーザの操作）を検知する手段である。また、検知した操作の内容をコントローラ部１０に伝えるための操作データを生成する機能も有する。

また、パケットサイズ変更手段６５０は、パケット受信手段６１１が変更後のパケットサイズでデータを受信中に、キー操作検知手段６３１がキー操作を検知すると、その操作に係る操作データを即時にコントローラ部１０に送信すべく、コントローラ部１０に対して信号ＰＡＫ２（割り込み要求）をパケット情報送信手段６０２によって送信させることができる。

次に、図４に、図１のコントローラ部１０のＣＰＵ１１が実行するデータ送信処理の一例を示すフローチャートを示す。なお、説明の便宜上、そのデータ送信処理をコントローラ部１０が行うものとして説明する。
コントローラ部１０は、いずれかの送信先（ここではＵＩ部２０とする）へのデータ送信を行う際に図４の処理を開始し、まずステップＳ１で送信しようとしているデータの種類を検知する。
そして、ステップＳ２へ進み、その検知したデータの種類が画像データであるか否かを判断し、ＹＥＳであればステップＳ３へ、ＮＯであればステップＳ１１へそれぞれ移行する。

ここで、図４の例では、画像データは一般的にデータサイズが大きいことから、データサイズの大きいデータを検出するための判断基準として、画像データであるか否かを用いている。送信しようとするデータのサイズが大きい場合に、送信パケットサイズを変更（拡大）すると好ましいためである。この観点からは、送信しようとするデータのサイズを直接の判断基準としてもよい。

ステップＳ１１では、データを基本サイズのパケットに分割してＵＩ部２０への送信を開始する。このデータ送信時のＵＩ部２０との信号のやりとりは、図６の（ｂ）に示した比較例と同様である。
その後、ステップＳ１２へ進み、ＵＩ部２０への送信完了を待って、図４の処理を終了する。

ステップＳ３では、送信しようとするデータが画像データであり、送信パケットサイズを拡大する必要があるため、パケットサイズを拡大する旨を伝える信号ＰＳＥをＵＩ部２０へ送信する（拡大を通知する）。
このとき、拡大したサイズで送信するパケット数も決定し、合わせて通知する。このパケット数は、送信すべきデータのサイズをもとに、送信完了に必要なパケット数としてもよいし、常に一定の数としてもよい。また、常に一定の数であれば、これをＵＩ部２０に記憶させておくことにより、ＵＩ部２０と通信を行う場合には、当該パケット数の通知を不要とすることができる。
その後、ステップＳ４でＵＩ部２０からの次のパケット送信を許可する信号ＰＡＫの受信（許可通知受信）を待って、ステップＳ５へ進む。

ステップＳ５では、送信パケットサイズを基本サイズから予め定められた所定の拡大サイズに拡大する。
次に、ステップＳ６へ進み、画像データを拡大サイズのパケットに分割してＵＩ部２０への送信を開始する。それによって、分割した各拡大サイズのデータ（パケット）を順次ＵＩ部２０へ送信することになる。

次に、ステップＳ７へ進み、送信パケット数がステップＳ３で通知した所定パケット数に達したか否かを判断し、ＹＥＳであればステップＳ１３へ進んで、送信パケットサイズを基本サイズに戻した後、ステップＳ３の処理へ戻って上述と同様の処理を行う。

なお、ステップＳ３で通知される所定パケット数をＵＩ部２０側で記憶しておけば、送信パケット数が所定パケット数に達した後にＵＩ部２０からデータが正常に受信できた旨を伝える信号ＡＣＫを送信することができる。コントローラ部１０がこれを受信することにより、ステップＳ７で送信パケット数が所定パケット数に達したと判断することができる。

ステップＳ７において、ＮＯと判断した場合には、ステップＳ８へ進み、ＵＩ部２０から信号ＰＡＫ２（割り込み要求）を受信したか否かを判断し、ＹＥＳであればステップＳ１４へ、ＮＯであればステップＳ９へそれぞれ移行する。
ステップＳ１４では、ＵＩ部２０へのデータ送信を中断する。
次に、ステップＳ１５へ進み、送信パケットサイズを基本サイズに戻した後、ＵＩ部２０からのデータの受信完了を待って、ステップＳ３の処理へ戻る。

ステップＳ９では、ＵＩ部２０へのデータ送信が完了したか否かを判断する。
そして、ＵＩ部２０へのデータ送信がまだ完了していない場合には、ステップＳ７の判断へ戻って、上述と同様の処理を行う。
ＵＩ部２０へのデータ送信が完了した場合には、ステップＳ１０へ進み、送信パケットサイズを基本サイズに戻し、図４の処理を終了する。

次に、図５に、図１のコントローラ部１０とＵＩ部２０との間のパケット通信のシーケンスの一例を示す。
この例では、送信しようとしているデータの種類が画像データである例である。従って、コントローラ部１０は、図４のステップＳ２の処理でＹＥＳと判断する。そして、パケットサイズが拡大される旨を伝える信号ＰＳＥをＵＩ部２０へ送信して（Ｓ５１）、ＵＩ部２０に受信パケットサイズを拡大するように指示する。

信号ＰＳＥを受けたＵＩ部２０は、受信パケットサイズを予め定められた拡大サイズに拡大し、次のパケット送信を許可する信号ＰＡＫをコントローラ部１０へ送信する（Ｓ５２ａ）。
信号ＰＡＫを受けたコントローラ部１０は、送信パケットサイズを予め定められた拡大サイズ（ＵＩ部２０側の受信パケットサイズと同一サイズ）に拡大して、画像データをその拡大サイズのパケットに分割して、ＵＩ部２０への各パケットデータの送信をする（Ｓ５３ａ〜Ｓ５３ｎ）。
例えば、送信パケットサイズを６４バイトから１０２４バイトに拡大することが考えられる。この場合、画像データを１０２４バイトのパケットに分割し、各１０２４バイトのパケットの送信を行う。この際、ＵＩ部２０からコントローラ部１０への送信は、パケットを拡大せず、６４バイトのまま行われる。信号ＰＡＫも６４バイトのままとなる。

また、コントローラ部１０は、ＰＳＥを送信する際に、その信号ＰＳＥの送信に伴いパケットサイズ拡大状態でデータ送信できる回数（所定のパケット数）をＵＩ部２０に通知する。そして、その規定回数のデータ送信を実施した場合（Ｓ５３ａ〜Ｓ５３ｎ）に、まだ全てのデータ送信が終了していない場合でも、ＵＩ部２０は信号ＡＣＫを送信する。それによって、規定回数のデータ送信を実施した際には、コントローラ部１０はＵＩ部２０から信号ＡＣＫを受信する（Ｓ５４）ことにより、送信パケットサイズを基本サイズ（通常サイズ）に戻す。

その後、コントローラ部１０は、必要であれば再び信号ＰＳＥをＵＩ部２０に送信して（Ｓ５５）、そのＵＩ部２０に受信パケットサイズを拡大するように指示する。
それによって、ＵＩ部２０では再び受信パケットサイズを拡大し、コントローラ部１０へ信号ＰＡＫを送信する（Ｓ５６）。コントローラ部１０は、これを受信すると、再びステップＳ５３ａと同様にＵＩ部２０への拡大サイズのパケット送信を開始する（Ｓ５７ａ〜Ｓ５７ｎ）。

また、その拡大サイズのパケット送信を実施している最中に、ＵＩ部２０の操作部上でキーが押下されると、ＵＩ部２０は次の処理を行う。
すなわち、キーの押下に応じて、コントローラ部１０に即時に送信すべき操作データが発生するため、実行中の通信に割り込んでこれを送信するための処理を行う。具体的には、パケットデータの受信に対して、信号ＡＣＫの代わりに、データを割り込みで送信する旨を伝える信号ＰＡＫ２（割り込み要求）をコントローラ部１０へ送信する（Ｓ５８）。続いて、押下されたキーに関するデータをコントローラ部１０へ送信する（Ｓ５９）。

信号ＰＡＫ２を受信したコントローラ部１０は、ＵＩ部２０への拡大サイズのパケットの送信を中断し、パケットサイズを基本サイズに戻す。そして、ＵＩ部２０から送信されるデータ（ここでは操作データ）を受信すると、信号ＡＣＫを基本サイズのパケットでＵＩ部２０ヘ送信し（Ｓ６０）、データを正常に受信できた旨を伝える。また、受信したデータの処理も行う。
操作データが正しくコントローラ部１０へ送信されたことを確認したＵＩ部２０は、信号ＰＡＫをコントローラ部１０へ送信する（Ｓ６１）。

以上の信号ＰＡＫ２から信号ＰＡＫまでのパケットサイズは全て基本サイズとなる。
操作データはサイズが小さいため、拡大サイズのパケットを行っても徒に送信データ量が増すだけであるので、このように小さいサイズのパケットを用いる方が高速な通信が可能となる。
また、信号ＰＡＫ２から信号ＰＡＫまでの間は割り込みを行ったＵＩ部２０からの送信を優先し、コントローラ部１０は、ハンドシェークに必要なもの以外、ＵＩ部２０へのパケット送信が禁止される。

また、ステップＳ６１の信号ＰＡＫを受信したコントローラ部１０は、中断していた拡大サイズでのパケット送信を再開することを許可されたので、再び信号ＰＳＥをＵＩ部２０へ送信し（Ｓ６２）、パケットサイズを拡大した状態でデータ送信を再開する。

なお、コントローラ部１０が、送信パケットサイズを拡大するだけでなく、適当なアプリにより画像データを圧縮（例えばビットマップ→ＪＰＥＧ）してからＵＩ部２０へ送信するようにしてもよい。この場合、画像データ（ＪＰＥＧデータ等）を受信したＵＩ部２０は、それを伸張（例えばハードウェア伸張）するようにする。そうすれば、送信パケット数が更に少なくなり、データ送信の更なる短縮化につながる。

この実施形態による作用効果を以下の（ａ）〜（ｆ）に示す。
（ａ）第１のモジュール（コントローラ部１０又はＵＩ部２０）は、第２のモジュール（ＵＩ部２０又はコントローラ部１０）に送信しようとするデータの種類又はサイズに応じて、動的に送信パケットのサイズを基本サイズから変更（拡大）する。このことにより、送信すべきデータの特性に合ったパケットサイズを選択し、第１のモジュールから第２のモジュールへのデータ送信に要する時間を短縮することができる。

（ｂ）第２のモジュールは、変更後のパケットサイズでデータを受信中に第１のモジュールへ送信すべきデータを検出した場合に、第１のモジュールに対して信号ＰＡＫ２により受信パケットのサイズを基本サイズに戻すことを要求する。このことにより、拡大したパケットサイズでデータを受信中の場合でも、検出した自己のデータを速やかに第１のモジュールへ送信することができる。

（ｃ）第１のモジュールは、信号ＰＡＫ２の受信に応じて送信パケットのサイズを基本サイズに戻した後、第２のモジュールから送信されるデータを受信し、その受信が完了した後、再度送信パケットのサイズを基本サイズから拡大する。そうすれば、速やかに拡大サイズのパケットでのデータ送信に復帰でき、データ送信を効率的に行うことができる。

（ｄ）なお、第１のモジュールが、第２のモジュールに対して信号ＰＡＫ２（割り込み要求）を拒否する（送信パケットのサイズを基本サイズに戻すことを要求した手段を動作させないことを要求する）ことを可能にすることも考えられる。このようにすれば、装置特有の様々な動作の影響（第１のモジュールと第２のモジュールとの間で行われるデータ通信の影響等）を考慮しつつ、第１のモジュールから第２のモジュールへのデータ送信を短時間で行うことができる。例えば、第１のモジュールからのデータ送信を優先したい場合に第１のモジュールから第２のモジュールへのデータ送信を確実に短時間で行うことができる。

（ｅ）第１のモジュールは、送信パケットのサイズが基本サイズから変更された後のパケットサイズで所定パケット数の送信を実行した場合に、送信パケットのサイズを基本サイズに戻す。このことにより、優先度の高い他のデータ送信を待たせることなく、割り込ませることが可能になる。
（ｆ）また、第１のモジュールに対し、送信パケットのサイズ変更を行わない設定を可能としてもよい。この場合、第１のモジュールは信号ＰＳＥの送信を行わない。このようにすれば、装置特有の様々な動作の影響を考慮し、第１のモジュールから第２のモジュールへのデータ送信を確実に行うことができる。

〔この実施形態におけるプログラム〕
この発明の実施形態であるプログラムは、コントローラ部１０のＣＰＵ１１に上述した機能を実現させるためのプログラムである。そして、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。

このようなプログラムは、はじめからコンピュータに備えるＨＤＤ（ハードディスク装置）、あるいはＲＯＭや他の不揮発性記憶媒体（フラッシュメモリ，ＥＥＰＲＯＭ等）などに格納しておいてもよい。しかし、記録媒体であるＣＤ−ＲＯＭ、あるいはメモリカード，フレキシブルディスク，ＭＯ，ＣＤ−Ｒ，ＣＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，又はＤＶＤ−ＲＡＭ等の不揮発性記録媒体に記録して提供することもできる。それらの記録媒体に記録されたプログラムをコンピュータにインストールして実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードし、コンピュータにインストールして実行させることも可能である。

以上で実施形態の説明を終了するが、この発明において、各部の具体的な構成や処理の内容、通信の手順等は、実施形態で説明したものに限るものではない。
例えば、上述した実施形態ではコントローラ部１０とＵＩ部２０が同等なパケットサイズ変更手段５３０，６５０を備えている例について説明したが、これには限られない。一方のみがパケットサイズの変更を要求する機能（信号ＰＳＥを送信する機能）を備えていてもよい。この場合、信号ＰＡＫ２を送信する機能は、他方のみが備えていればよい。

上述した実施形態では、変更後のパケットサイズは基本サイズよりも大きい例について説明したが、変更後の方がサイズが小さいことを排除するものではない。基本サイズでは送信すべきデータに対して大きすぎて余分な通信時間が発生するため、送信しようとするデータの種類又はサイズに応じて、パケットのサイズを小さくすることも考えられる。
また、パケットのサイズを３段階以上に変更可能とすることも考えられる。この場合、例えば信号ＰＳＥにより変更後のパケットサイズを伝達したり、信号ＰＳＥと対応する機能の信号として、変更後のパケットサイズに対応して信号ＰＳＥａ，ＰＳＥｂ等の複数の信号を用意したりすることが考えられる。

例えば、上述した実施形態では第１のモジュールをコントローラ部１０、第２のモジュールをＵＩ部２０としたが、これに限られないことは勿論である。コントローラ部１０とエンジン部３０との通信に適用してもよい。さらに、スキャナ等の画像形成機能を含まない画像処理装置や、パーソナルコンピュータを含む他の任意の情報処理システムにもこの発明を適用可能であることは勿論である。

この場合において、モジュール間で通信を行うのであれば、情報処理システムを構成するどの部分をモジュールとするかも任意である。第１及び第２のモジュールは、ハードウェアモジュールだけでなく、ソフトウェアモジュールであってもよい。また、第１及び第２のモジュールは、それぞれ独立して動作可能な情報処理システムであってもよい。
さらに、この発明は上述した実施形態に限定されるものではなく、特許請求の範囲に記載された技術思想に含まれる技術的事項の全てが対象となることは言うまでもない。
さらにまた、以上説明してきた実施形態、動作例及び変形例の構成は、相互に矛盾しない限り任意に組み合わせて実施可能であることは勿論である。

１：画像形成装置 １０：コントローラ部 １１：ＣＰＵ １２：ＲＯＭ
１３：ＲＡＭ １４：通信Ｉ／Ｆ １５：ＨＤＤ ２０：ＵＩ部
３０：エンジン部 ５０：システムバス １０１：オペレーティングシステム
１１１：ブラウザコントロールサービス
１１２：エンジンコントロールサービス １１３：メモリコントロールサービス
１１４：ファクスコントロールサービス
１１５：オペレーションコントロールサービス
１１６：ネットワークコントロールサービス １１７：システムコントロールサービス
１１８：システムリソースマネージャ ２０１：ブラウザアプリ
２０２：プリンタアプリ ２０３：コピーアプリ ２０４：ファクスアプリ
２０５：ネットファイルアプリ ２０６：工程検査アプリ
３０１：白黒画像形成部 ３０２：カラー画像形成部
３０３：その他ハードウェアリソース ５００，６００：送信部
５０１，６０１：パケット送信手段 ５０２，６０２：パケット情報送信手段
５１０，６１０：受信部 ５１１，６１１：パケット受信手段
５１２，６１２：パケット情報受信手段 ５２０，６２０：調整部
５３０，６５０：パケットサイズ変更手段 ５３１，６５１：パケットサイズ復帰手段
５３２，６５２：パケットサイズ自動リセット手段
５３３，６５３：割り込み拒否手段
５３４，６５４：パケット送受信中断・再開・切替制御手段
６３０：検知部 ６３１：キー操作検知手段

特開２００６−０１９８３１号公報

Claims (7)

1. 第１のモジュールと第２のモジュールとを備え、前記第１のモジュールと前記第２のモジュールとの間でデータを送受信する際に、該データを一定サイズのパケットに分割して送受信する情報処理システムであって、
   前記第１のモジュールが、前記第２のモジュールに送信しようとするデータの種類又はサイズに応じて、動的に前記パケットのサイズを所定の基本サイズから変更する変更手段を備え、
   前記第２のモジュールに、前記変更手段による変更後のパケットサイズでデータを受信中に前記第１のモジュールへ送信すべきデータを検出した場合に、前記第１のモジュールに対してパケットのサイズを前記基本サイズに戻すことを要求する要求手段を備えることを特徴とする情報処理システム。
2. 前記変更手段は、前記要求手段による要求の後前記第２のモジュールから送信されるデータの受信完了後、再度前記パケットのサイズを所定の基本サイズから変更する手段であることを特徴とする請求項１に記載の情報処理システム。
3. 前記第１のモジュールが、前記第２のモジュールに対して前記要求手段を動作させないことを要求する手段を備えることを特徴とする請求項１又は２に記載の情報処理システム。
4. 請求項１乃至３のいずれか一項に記載の情報処理システムにおいて、
   前記変更手段による変更後のパケットサイズで所定パケット数の送信を実行した場合、パケットのサイズを前記基本サイズに戻す手段を備えることを特徴とする情報処理システム。
5. 請求項１乃至４のいずれか一項に記載の情報処理システムにおいて、
   前記変更手段による前記パケットのサイズ変更を無効にする手段を備えることを特徴とする情報処理システム。
6. 前記第２のモジュールが操作部と表示部を備えたユーザインタフェースであり、
   前記第１のモジュールが前記ユーザインタフェースを制御する制御手段であることを特徴とする請求項１乃至５のいずれか一項に記載の情報処理システム。
7. 第１のモジュールと第２のモジュールとを備え、前記第１のモジュールと前記第２のモジュールとの間でデータを送受信する際に、該データを一定サイズのパケットに分割して送受信する情報処理システムにおける情報送信方法であって、
   前記第１のモジュールが、前記第２のモジュールに送信しようとするデータの種類又はサイズに応じて、動的に前記パケットのサイズを所定の基本サイズから変更し、
   前記第２のモジュールが、前記基本サイズから変更後のパケットサイズでデータを受信中に前記第１のモジュールへ送信すべきデータを検出した場合に、前記第１のモジュールに対してパケットのサイズを前記基本サイズに戻すことを要求することを特徴とする情報送信方法。

Images