JP6127559B2 - 画像処理装置 - Google Patents

Description

本発明は、画像処理装置の制御技術に関する。

ＭＦＰ（Multi Function Peripheral、Multi Function Printer）等の画像処理装置として、外部のＰＣ（Personal Computer）等の端末装置に対して画像処理装置の機能を利用することのできる共通インタフェース（Web API）を設けたものがある。

一方、画像処理装置として、画面表示やキー入力の操作を行う部分を操作部として本体部から独立させ、本体部の負荷が高くても操作レスポンスを低下させないようにすることが考えられている。操作部にはAndroid OS等の独立したＯＳ（Operating System）が搭載され、本体部とは独立に動作する。

この場合、操作部は前述の共通インタフェースを通して本体部の機能を利用するのが効率的である。

上述したように、本体部と操作部に分離された画像処理装置では、本体部の提供する共通インタフェースを通して操作部から本体部の機能を利用するのが効率的であるが、共通インタフェースという性質上、同じ要求に対しては同じ処理を行うこととなり、外部のＰＣ等の端末装置と操作部の特性に応じて処理を変えることができないという問題があった。

例えば、外部の端末装置はインターネット等のネットワークを経由して本体部に接続してくるのに対し、操作部は専用線で本体部に接続されることが多いため、送受信できるデータ量にも違いがある。また、外部の端末装置のユーザは画像処理装置から離れて操作していることが多いのに対し、操作部のユーザは画像処理装置の前に立って操作しており、ユーザに何らかの対処を求めたり、ユーザに対して何らかの情報を提供したりする場合の意味も異なってくる。

外部の端末装置と操作部に対して共通インタフェースを別々に設けるということも考えられるが、そもそも共通インタフェースという意義を薄めるとともに、共通インタフェースの大幅な改造が必要となり、その後のメンテナンスの負担も増大する。

一方、特許文献１には、携帯端末から画像処理装置へ指示を行った際、２つの時点の距離を計測し、その距離に応じて処理を切り替える手法について開示されている。例えば、印刷用の指示を近付きながら行っている場合は、用紙を取りに来る可能性が高いため、印刷物を出力するといった処理を行う。

しかし、特許文献１は本体部と操作部が独立した画像処理装置を対象としたものではなく、上述した問題点を解決できるものではない。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、共通インタフェースへの要求であっても、その要求元が特定の装置であるかどうかを判断することで、要求元の特性に合わせた適切な処理を行えるようにすることにある。

上記の課題を解決するため、本発明にあっては、ユーザが直接に操作を行う操作部と、当該操作部からの要求に基づき動作する本体部とを備えた画像処理装置であって、前記本体部のＷｅｂ ＡＰＩによる共通インタフェースが前記操作部もしくは外部の端末装置より処理要求を受けた際に、要求元のＩＰアドレスに基づいて当該処理要求を発した装置を特定する特定手段と、特定された装置の特性に応じて処理内容を変更して処理を実行する処理手段とを備えるようにしている。

本発明にあっては、共通インタフェースへの要求であっても、その要求元が特定の装置であるかどうかを判断することで、要求元の特性に合わせた適切な処理を行うことができる。

本発明の一実施形態にかかる画像処理装置の構成例を示す図である。 操作部もしくは端末装置のアプリが本体部の機能を利用する場合のアプリ操作データの流れを示す図である。 本体部コントローラおよび操作部コントローラの構成例を示す図である。 実施形態の処理例を示すシーケンス図（その１）である。 スキャン時の処理例を示すフローチャートである。 実施形態の処理例を示すシーケンス図（その２）である。 エラー通知時の処理例を示すフローチャートである。 実施形態の処理例を示すシーケンス図（その３）である。 印刷開始時の処理例を示すフローチャートである。

以下、本発明の好適な実施形態につき説明する。

＜構成＞
図１は本発明の一実施形態にかかる画像処理装置１の構成例を示す図である。

図１において、画像処理装置１は本体部２と操作部３とを備え、本体部２と操作部３はケーブル４により接続されている。本体部２と操作部３は物理的に非常に近い距離で有線により接続されことにより、高速なデータ通信が可能である。なお、本体部２と操作部３は、ケーブル４による有線接続に代えて、無線（赤外線を含む）接続としてもよい。

本体部２は、本体部２の制御動作を司る本体部コントローラ２１と、原稿の読み取りを行うスキャナデバイス２２と、用紙に印刷を行うプロッタデバイス２３とを備えている。

本体部２は、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット等のネットワーク５を介してＰＣ（Personal Computer）等の端末装置６からアクセスを受け付けることができるとともに、無線アクセスポイント７を介してスマートフォン、タブレット等の端末装置８からアクセスを受け付けることができるようになっている。端末装置８からBluetooth（登録商標）等の近距離無線を使って本体部２に直接にアクセスするようにしてもよい。

操作部３は、操作部３の制御動作を司る操作部コントローラ３１と、ユーザが操作するハードキー３２と、画面表示および操作入力受付を行う液晶タッチパネル３３と、着脱が可能なメモリカード等の外部記憶装置３４とを備えている。

図２は操作部３もしくは端末装置６、８のアプリが本体部２の機能を利用する場合のアプリ操作データの流れを示す図である。

図２において、操作部３は、本体部２からケーブル４により制御線と電源線が供給される。操作部３のアプリ層からのアプリ操作データは、ケーブル４を介して本体部２のサービス層に伝えられる。端末装置６、８のアプリ層からのアプリ操作データは、ネットワーク５を介して本体部２のサービス層に伝えられる。

図３は本体部コントローラ２１および操作部コントローラ３１の構成例を示す図である。

図３において、本体部コントローラ２１は、ＯＳ２１１とモジュール２１２＃１〜２１２＃４、・・と共通インタフェース（Web API）２１３とを備えている。

ＯＳ２１１は、本体部コントローラ２１の基本ソフトウェアである。

モジュール２１２＃１〜２１２＃４、・・は、コピー、スキャン、ＦＡＸ、プリンタ等の機能を実現するプログラムモジュールである。

共通インタフェース２１３は、モジュール２１２＃１〜２１２＃４、・・の機能を外部から利用できるようにしたものであり、その仕様は公開されており、操作部コントローラ３１の本体機能を利用する操作部アプリ３１２＃２や端末装置６の一般アプリ６１や端末装置８の一般アプリ８１からアクセスできるようになっている。なお、共通インタフェース（Web API）２１３を利用する際には、本実施形態では、プロトコルとしてＴＣＰ／ＩＰを使用し、専用のＩＰアドレスを使用するものとしている。

なお、図示を省略しているが、各モジュール２１２＃１〜２１２＃４は、一般的な共通インタフェース２１３だけでなく、画像処理装置１内のみで利用する直接利用のための専用インタフェースも提供している。

操作部コントローラ３１は、ＯＳ３１１と操作部アプリ３１２＃１〜３１２＃３、・・とを備えている。

ＯＳ３１１は、操作部コントローラ３１の基本ソフトウェアである。

操作部アプリ３１２＃１〜３１２＃３、・・は、操作部３において動作するアプリケーションプログラムである。操作部アプリ３１２＃１〜３１２＃３、・・としては、共通インタフェース２１３を経由せずに専用インタフェースで本体機能を利用する本体部コントローラ２１と密接な関係にあるもの（操作部アプリ３１２＃１として図示）、共通インタフェース２１３を経由して本体機能を利用するもの（操作部アプリ３１２＃２として図示）、本体機能を利用しないもの（操作部アプリ３１２＃３として図示）がある。

なお、本体部２もしくは操作部３に含まれる機能は、必ずしも本体部２もしくは操作部３の内部に実装される必要はなく、ネットワーク上で利用可能な機能として実現してもよい。

＜動作＞
図４は上記の実施形態の処理例を示すシーケンス図であり、（ａ）は操作部３の操作部アプリ３１２から共通インタフェース２１３を経由して本体部２のコピー機能を利用する場合、（ｂ）は端末装置６の一般アプリ６１もしくは端末装置８の一般アプリ８１から共通インタフェース２１３を経由して同じく本体部２のコピー機能を利用する場合である。

図４（ａ）において、操作部３の操作部アプリ３１２からスキャンおよびプレビュー画像の取得を本体部２の共通インタフェース２１３に要求すると（ステップＳ１０１）、共通インタフェース２１３はモジュール２１２にスキャンおよびプレビュー画像の取得を要求する（ステップＳ１０２）。

モジュール２１２は、要求してきたのが操作部３であるのか端末装置６、８であるのかを判断した上で、スキャンを行う（ステップＳ１０３）。スキャン時の詳細処理については後述する。

モジュール２１２は、要求してきたのが操作部３であると判断した場合、ケーブル４による高速な専用線により画像データを送信できるとともに、ユーザが画像処理装置１の前にいて高画質が期待されるため、サイズの大きい高品質なロスレス形式で、かつ受信しながら随時表示できる形式でプレビュー画像を共通インタフェース２１３に送信する（ステップＳ１０４）。共通インタフェース２１３はプレビュー画像を操作部アプリ３１２に転送し（ステップＳ１０５）、操作部アプリ３１２は受信したプレビュー画像を表示する。

その後、操作部アプリ３１２から共通インタフェース２１３に印刷を要求すると（ステップＳ１０６）、共通インタフェース２１３はモジュール２１２に印刷を要求する（ステップＳ１０７）。

図４（ｂ）において、端末装置６の一般アプリ６１もしくは端末装置８の一般アプリ８１からスキャンおよびプレビュー画像の取得を本体部２の共通インタフェース２１３に要求すると（ステップＳ１１１）、共通インタフェース２１３はモジュール２１２にスキャンおよびプレビュー画像の取得を要求する（ステップＳ１１２）。

モジュール２１２は、要求してきたのが操作部３であるのか端末装置６、８であるのかを判断した上で、スキャンを行う（ステップＳ１１３）。スキャン時の詳細処理については後述する。

モジュール２１２は、要求してきたのが端末装置６、８であると判断した場合、ケーブル４による高速な専用線により画像データを送信できないため、サイズの小さいロッシー形式による高圧縮のプレビュー画像を共通インタフェース２１３に送信する（ステップＳ１１４）。共通インタフェース２１３はプレビュー画像を操作部アプリ３１２に転送し（ステップＳ１１５）、操作部アプリ３１２は受信したプレビュー画像を表示する。

その後、一般アプリ６１、８１から共通インタフェース２１３に印刷を要求すると（ステップＳ１１６）、共通インタフェース２１３はモジュール２１２に印刷を要求する（ステップＳ１１７）。

図５はスキャン時（図４のステップＳ１０３、Ｓ１１３）の処理例を示すフローチャートである。

図５において、モジュール２１２はスキャンを実行し（ステップＳ１２１）、所定のＩＰアドレス、すなわち操作部３に割り当てられたＩＰアドレスからの要求であるか否かを、要求を示すＩＰパケットのヘッダ情報等から判断する（ステップＳ１２２）。

所定のＩＰアドレスからの要求であると判断した場合（ステップＳ１２２のＹｅｓ）、ロスレス形式による画質優先画像に変換する（ステップＳ１２３）。

所定のＩＰアドレスからの要求でないと判断した場合（ステップＳ１２２のＮｏ）、ロッシー形式による小サイズ画像に変換する（ステップＳ１２４）。

そして、共通インタフェース２１３にプレビュー画像を返す（ステップＳ１２５）。

図６は上記の実施形態の他の処理例を示すシーケンス図であり、（ａ）は操作部３の操作部アプリ３１２から共通インタフェース２１３を経由して本体部２のプリンタ機能を利用する場合、（ｂ）は端末装置６の一般アプリ６１もしくは端末装置８の一般アプリ８１から共通インタフェース２１３を経由して同じく本体部２のプリンタ機能を利用する場合である。

図６（ａ）において、操作部３の操作部アプリ３１２から印刷開始を本体部２の共通インタフェース２１３に要求すると（ステップＳ２０１）、共通インタフェース２１３はモジュール２１２に印刷開始を要求する（ステップＳ２０２）。

モジュール２１２は、印刷を開始するが（ステップＳ２０３）、印刷の途中で本体システムから用紙切れのエラー通知を受けると（ステップＳ２０４）、元々の印刷要求をしてきたのが操作部３であるのか端末装置６、８であるのかを判断した上で、その後の処理を変更する。エラー通知時の詳細処理については後述する。

モジュール２１２は、要求してきたのが操作部３であると判断した場合、ユーザは画像処理装置１の前にいると推定することができ、ユーザに用紙を補充させるとか、別のサイズの用紙に変更させるとかのユーザ操作によりエラーを解除し、正しく印刷完了した方がよいため、印刷を停止する（ステップＳ２０５）。

そして、モジュール２１２は、共通インタフェース２１３に用紙切れエラーを通知し（ステップＳ２０６）、共通インタフェース２１３は操作部アプリ３１２に用紙切れエラーを通知する（ステップＳ２０７）。

図６（ｂ）において、端末装置６の一般アプリ６１もしくは端末装置８の一般アプリ８１から印刷開始を本体部２の共通インタフェース２１３に要求すると（ステップＳ２１１）、共通インタフェース２１３はモジュール２１２に印刷開始を要求する（ステップＳ２１２）。

モジュール２１２は、印刷を開始するが（ステップＳ２１３）、印刷の途中で本体システムから用紙切れのエラー通知を受けると（ステップＳ２１４）、元々の印刷要求をしてきたのが操作部３であるのか端末装置６、８であるのかを判断した上で、その後の処理を変更する。エラー通知時の詳細処理については後述する。

モジュール２１２は、要求してきたのが端末装置６、８であると判断した場合、ユーザは画像処理装置１から離れた場所にいると推定することができ、ユーザに用紙を補充させるとか、別のサイズの用紙に変更させるとかの対応を行わせるのは困難であるため、自動継続処理により強制印刷を続行する（ステップＳ２１５）。自動継続処理とは、例えば、条件を変更することで強制的に印刷継続可能であれば強制印刷で継続し、印刷不可の場合には印刷ジョブをキャンセルする等である。

そして、モジュール２１２は、強制印刷が完了した場合、共通インタフェース２１３に強制印刷の完了を通知し（ステップＳ２１６）、共通インタフェース２１３は操作部アプリ３１２に強制印刷の完了を通知する（ステップＳ２１７）。

図７はエラー通知時（図６のステップＳ２０４〜Ｓ２０６、Ｓ２１４〜Ｓ２１６）の処理例を示すフローチャートである。

図７において、モジュール２１２はエラー通知によりエラーを検知すると（ステップＳ２２１）、元々の印刷処理が所定のＩＰアドレス、すなわち操作部３に割り当てられたＩＰアドレスからの要求であるか否かを、要求を示すＩＰパケットのヘッダ情報等から判断する（ステップＳ２２２）。

所定のＩＰアドレスからの要求であると判断した場合（ステップＳ２２２のＹｅｓ）、印刷を停止し（ステップＳ２２３）、共通インタフェース２１３にエラーを通知する（ステップＳ２２３）。

所定のＩＰアドレスからの要求でないと判断した場合（ステップＳ２２２のＮｏ）、自動継続処理を行ない（ステップＳ２２５）、共通インタフェース２１３に自動継続処理結果を通知する（ステップＳ２２６）。

図８は実施形態の更に他の処理例を示すシーケンス図であり、（ａ）は操作部３の操作部アプリ３１２＃２から共通インタフェース２１３を経由して本体部２のプリンタ機能を利用する場合におけるサイネージアプリ（操作部アプリ３１２＃３）の制御、（ｂ）は端末装置６の一般アプリ６１もしくは端末装置８の一般アプリ８１から共通インタフェース２１３を経由して同じく本体部２のプリンタ機能を利用する場合におけるサイネージアプリ（操作部アプリ３１２＃３）の制御である。

図８（ａ）において、操作部３の操作部アプリ３１２＃２から印刷開始を本体部２の共通インタフェース２１３に要求すると（ステップＳ３０１）、共通インタフェース２１３はモジュール２１２に印刷開始を要求する（ステップＳ３０２）。

モジュール２１２は、印刷を開始するが（ステップＳ３０３）、印刷要求をしてきたのが操作部３であるのか端末装置６、８であるのかを判断した上で、サイネージアプリである操作部アプリ３１２＃３に起動依頼を行うか否か処理を変更する。

モジュール２１２は、要求してきたのが操作部３であると判断した場合、ユーザが画像処理装置１の前にいると推定でき、操作部３に広告を表示した場合に広告効果があると考えられるため、印刷開始の後にサイネージアプリである操作部アプリ３１２＃３に起動依頼を行う（ステップＳ３０４）。これに応じ、操作部アプリ３１２＃３は操作部３の液晶タッチパネル３３に広告表示を行う。

モジュール２１２は、印刷が完了すると、共通インタフェース２１３に印刷完了を通知し（ステップＳ３０５）、共通インタフェース２１３は操作部アプリ３１２＃２に印刷完了を通知する（ステップＳ３０６）。

図８（ｂ）において、端末装置６の一般アプリ６１もしくは端末装置８の一般アプリ８１から印刷開始を本体部２の共通インタフェース２１３に要求すると（ステップＳ３１１）、共通インタフェース２１３はモジュール２１２に印刷開始を要求する（ステップＳ３１２）。

モジュール２１２は、印刷を開始するが（ステップＳ３１３）、印刷要求をしてきたのが操作部３であるのか端末装置６、８であるのかを判断した上で、サイネージアプリである操作部アプリ３１２＃３に起動依頼を行うか否か処理を変更する。

モジュール２１２は、要求してきたのが端末装置６、８であると判断した場合、ユーザが画像処理装置１の前にいないので操作部３を見ていない、または異なるユーザが操作部３を利用していると推定でき、操作部３に広告を表示した場合に広告効果がないため、印刷開始の後にサイネージアプリである操作部アプリ３１２＃３に起動依頼を行わない。

モジュール２１２は、印刷が完了すると、共通インタフェース２１３に印刷完了を通知し（ステップＳ３１４）、共通インタフェース２１３は操作部アプリ３１２＃２に印刷完了を通知する（ステップＳ３１５）。

図９は印刷開始時（図８のステップＳ３０３、Ｓ３１３）の処理例を示すフローチャートである。

図９において、モジュール２１２は印刷を開始すると（ステップＳ３２１）、印刷処理が所定のＩＰアドレス、すなわち操作部３に割り当てられたＩＰアドレスからの要求であるか否かを、要求を示すＩＰパケットのヘッダ情報等から判断する（ステップＳ３２２）。

所定のＩＰアドレスからの要求であると判断した場合（ステップＳ３２２のＹｅｓ）、サイネージアプリへ起動依頼を行う（ステップＳ３２３）。

所定のＩＰアドレスからの要求でないと判断した場合（ステップＳ３２２のＮｏ）、サイネージアプリへ起動依頼は行わない。

その後、印刷が完了すると（ステップＳ３２４）、共通インタフェース２１３に印刷完了を通知する（ステップＳ３２５）。

＜総括＞
以上説明したように、本実施形態によれば、共通インタフェースへの要求であっても、その要求元が特定の装置であるかどうかを判断することで、要求元の特性に合わせた適切な処理を行うことができる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

１ 画像処理装置
２ 本体部
２１ 本体部コントローラ
２１１ ＯＳ
２１２、２１２＃１〜２１２＃４ モジュール
２１３ 共通インタフェース
２２ スキャナデバイス
２３ プロッタデバイス
３ 操作部
３１ 操作部コントローラ
３１１ ＯＳ
３１２、３１２＃１〜３１２＃３ 操作部アプリ
３２ ハードキー
３３ 液晶タッチパネル
３４ 外部記憶装置
４ ケーブル
５ ネットワーク
６ 端末装置
６１ 一般アプリ
７ 無線アクセスポイント
８ 端末装置
８１ 一般アプリ

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

Claims (6)

1. ユーザが直接に操作を行う操作部と、当該操作部からの要求に基づき動作する本体部とを備えた画像処理装置であって、
   前記本体部のＷｅｂ ＡＰＩによる共通インタフェースが前記操作部もしくは外部の端末装置より処理要求を受けた際に、要求元のＩＰアドレスに基づいて当該処理要求を発した装置を特定する特定手段と、
   特定された装置の特性に応じて処理内容を変更して処理を実行する処理手段と
   を備えたことを特徴とする画像処理装置。
2. 請求項１に記載の画像処理装置において、
   前記特定手段は、処理要求を発した装置を前記操作部であるか否かを特定する
   ことを特徴とする画像処理装置。
3. 請求項１または２のいずれか一項に記載の画像処理装置において、
   前記処理手段は、処理要求を発した装置が前記操作部であると特定された場合に、前記本体部と前記操作部の間が、前記本体部と前記外部の端末装置との間の通信手段に比して高速な通信手段で接続されていることを前提とした処理を行う
   ことを特徴とする画像処理装置。
4. 請求項１乃至３のいずれか一項に記載の画像処理装置において、
   前記処理手段は、処理要求を発した装置が前記操作部であると特定された場合に、ユーザが前記本体部の前にいることを前提とした処理を行う
   ことを特徴とする画像処理装置。
5. ユーザが直接に操作を行う操作部と、当該操作部からの要求に基づき動作する本体部とを備えた画像処理装置と、
   前記本体部のＷｅｂ ＡＰＩによる共通インタフェースが前記操作部もしくは外部の端末装置より処理要求を受けた際に、要求元のＩＰアドレスに基づいて当該処理要求を発した装置を特定する特定手段と、
   特定された装置の特性に応じて処理内容を変更して処理を実行する処理手段と
   を備えたことを特徴とする画像処理システム。
6. ユーザが直接に操作を行う操作部と、当該操作部からの要求に基づき動作する本体部とを備えた画像処理装置の制御部を構成するコンピュータを、
   前記本体部のＷｅｂ ＡＰＩによる共通インタフェースが前記操作部もしくは外部の端末装置より処理要求を受けた際に、要求元のＩＰアドレスに基づいて当該処理要求を発した装置を特定する特定手段、
   特定された装置の特性に応じて処理内容を変更して処理を実行する処理手段
   として機能させる画像処理プログラム。