説明

ネットワークジョブ通信システム

【課題】 他デバイスのジョブ状況によって、帯域制御しながら効率的にクラウド上のサーバからのジョブを受信できるようにする。
【解決手段】 他デバイス装置で、印刷ジョブ処理が実行されていて、かつ、そのジョブが優先ジョブである場合には、帯域制限受信を行い、優先ジョブでなければ、帯域制限指示を行い、高速受信を実行する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、サーバからデータのネットワーク送受信を行うネットワークジョブ通信システムに関する。
【背景技術】
【0002】
近年、クラウドサービスと呼ばれるインターネットのプリントデータ生成・配信機能,、ならびにスキャンデータの保存機能を有するサービス、インフラが整備されてきている。そして、このクラウドサービスを利用して、インターネット経由でのクラウドtoプリントやスキャンtoクラウドを行うサービス形態が開発されてきている。また、画像データの送受信をユーザストレスなく実行するために、マルチセッション等を行うことで、高速送受信を行う技術が開発されてきている。そして、これらシステムは今後ますます普及することが予想される。
【0003】
また、ネットワーク受信の負荷が高くなりすぎることもあり、これを回避するための帯域制限の技術として、特許文献1のように優先度の高い通信を保証しながら他通信を帯域制限していく技術や、端末機において、受信を一定期間の待ち時間(例えば100msec)を設定したり、受信要求データサイズを減らしたり(例えば1kByte)する技術が提案されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2005−210346号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、高速送受信を実行すると、ユーザ環境のネットワーク帯域を逼迫させてしまう可能性があり、同じセグメント内に複数のデバイスが存在すると、その可能性がさらに増幅されてしまう。また、一方で、ルーター等でIPアドレスやポート番号にて帯域制御を行う技術が確立されているが、各デバイスで利用されるジョブごとに帯域制御を行うことが困難であった。そのため、優先してクラウドtoプリントしたい場合があっても、帯域がFULLに近い状態だと、印刷時間が非常に遅くなってしまう可能性もあった。また、その原因をユーザが把握することも困難であるため、ユーザストレスがかかる可能性があった。
【課題を解決するための手段】
【0006】
第一のデバイス装置が、印刷指示を受け付ける手段(S901)と、1ないし複数の第二のデバイス装置からジョブ状態を取得する手段(S903)と前記ジョブ状態の中に優先ジョブがあるか否かを判別する手段(S906)と、
前記のジョブが非優先ジョブである場合には、第一のデバイス装置が、前記第二のデバイス装置に帯域制限通信の指示(S911)を行い、かつ、高速通信を行う手段(S912)と、前記のジョブが優先ジョブを含む場合には、帯域制限通信(S909)を行う。上記システムで前記の課題を解決することが可能となる。
【発明の効果】
【0007】
ユーザ環境のネットワーク帯域を逼迫させず、優先ジョブを待たせることなく印刷させることが可能となる。また、他デバイスでの優先ジョブ受信のために、ネットワーク負荷がかかっていることをユーザが把握することが可能となる。
【図面の簡単な説明】
【0008】
【図1】本発明の実施形態1に係わるデバイス装置の内部構成を示した図。
【図2】本発明の実施形態に係わるシステムの全体配置を説明する図。
【図3】本発明の実施形態に係わるデバイス装置内の内部モジュール構成図。
【図4】実施形態に係わるデバイス装置内部のジョブ処理状況データを説明する図。
【図5】実施形態に係わるジョブ状況を取得するSOAPスキーマの一例を示す図。
【図6】実施形態に係わる高速通信モードを設定するSOAPスキーマの一例を示す図。
【図7】本発明の実施形態に係わる他デバイス装置で優先ジョブ処理されている時のUI表示の一例を示す図。
【図8】本発明の実施形態に係わるサーバとデバイス2台の場合でジョブ処理が重なった場合のシーケンスの一例を示す図。
【図9】本発明の実施形態に係わる印刷データを受信するデバイス側のフローチャート。
【発明を実施するための形態】
【0009】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【0010】
<第1実施形態>
第1図は、本発明の実施形態に係わるデバイス装置の内部構成を示した図である。本内部構成では、1CPUにおいてネットワーク制御部とデバイス(プリンタ・スキャナ)制御部が動作する形態で実現されている。このデバイス装置は、1−3に格納されているプログラムを実行するCPU1−1を備え、システムバス1−11に接続される各デバイスを総括的に制御する。また、1−2はRAMで、CPU1−1の主メモリ、ワークエリア等として機能する。そして、各種の設定値を保存するバックアップRAMも構成される。1−5は、CRTコントローラ(CRTC)で、CRTディスプレイ(CRT)1−8の表示を制御する。1−8のCRTディスプレイを用いてユーザは、クラウド上のデータリストの印刷開始指示やスキャンデータをクラウド上に保存することができる。1−5はディスクコントローラで、画像や様々なユーザデータを保存する1−9のハードディスク(HD)を制御する。1−6は、デバイスコントローラ(DVC)で、1−10のプリンタおよびスキャナ(DV)を制御する。1−7はネットワークインタフェースカード(NIC)で、LAN1−12を介して、サーバと通信を行うことができる。
【0011】
なお、本実施例では、キーボードはないが、もちろんキーボードがあってもよい。また、HDはなくてもよいし、また、HDでなくとも、データを保存できれば、USBメモリ等でもよい。また、各種の設定値はバックアップRAMではなく、HDD等の別の格納装置内部に保存されていてもかまわない。
【0012】
第2図は、本発明の実施形態に係わるシステムの全体配置を説明する図である。図2において、2−1は、PCであり、クラウド上のサーバ(2−6)へのデータのアップロード、ダウンロードが可能である。2−11、2−12、2−13はデバイス装置であり、2−4のインターネットを経由して、2−6のクラウド上のサーバからの印刷ジョブの受信を行うことが可能である。また、デバイス装置でスキャンしたデータを2−6のクラウド上のサーバにアップロードすることも可能である。2−7、2−8、2−9は印刷データで各デバイス装置にて印刷することが可能である。2−10は、2−7の印刷データを圧縮したデータである。2−2は、ルーターであり、2−3、2−5はプロキシーサーバ装置である。2−14、2−15、2−16はLANである。
【0013】
なお、サーバ、デバイス、PCとも、図2の構成に限定されるものではなく、それぞれ1または複数の組み合わせでもかまわない。また、2−4のインターネットを経由せずに、2−6のサーバ装置を構成することでもかまわない。
【0014】
第3図は、本発明の実施形態に係わるデバイス装置内の内部モジュール構成図である。
【0015】
3−1はエンジン制御部で、プリンタエンジンの印刷制御や、デバイスの制御等を行う。3−2は、他デバイス情報保持部であり、例えば、図4のような印刷状況のデータを保持する。3−3は、クラウドデータ処理部であり、3−4のUIからのユーザ操作により、クラウド上のサーバからの印刷ジョブを取得したり、スキャンジョブをクラウド上のサーバに送信したりする。3−5はHTTP処理部であり、複数のタスクで同時に処理を行うことが可能である。3−6はネットワーク送受信部であり、3−5のHTTP処理部等からの指示で、ネットワークを経由して、サーバ等とデータの送受信を行うことが可能である。
【0016】
なお、3−5はHTTPとしたが、インターネット上で通信が可能であれば、特に言及されるものではない。また、3−3はクラウドデータ処理部としたが、特にサーバと通信が可能であれば、クラウドに言及されるものではない。また、スキャンに対してはなくてもかまわない。
【0017】
第4図は、実施形態に係わるデバイス装置内部のジョブ処理状況データを説明する図である。4(a)−1は、他デバイスのIPアドレスであり、図4(a)の例では、2台のデバイスでジョブ処理がされていることとなる。4(a)−2は、ジョブ種であり、クラウドtoプリントなのかスキャンtoクラウドなのかが設定される。4(a)−3は、処理しているジョブのデータサイズであり、4(a)−4は、一秒あたりの転送レート(MByte)となる。4(a)−5は、転送完了時間となる。4(a)−6は、高速通信モードの状態を示しており、ONであれば実施中で、OFFであれば、実施していないことを示す。4(a)−7は、優先モードの状態を示しており、優先モードがONであれば、実施中で、OFFであれば、実施していないことを示し、この場合は、優先モードがすべてOFFとなっている。図4(b)は、ジョブ処理中のデバイスが1台の場合であり、4(b)−1は、優先モードがONになっていることを示している。
【0018】
なお、本データには、ジョブ種を含んだが、特になくてもかまわない。
【0019】
第5図は、実施形態に係わるジョブ状況を取得するSOAPスキーマの一例を示す図である。図5(a)は、ステータス取得を要求するSOAPメソッドで、図5(b)は、図5(a)のメソッドのレスポンスでステータス情報を返信するSOAPメソッドである。図5(a)のメソッドは、getJobStatusというメソッド名であり、自デバイスのクライアント情報(ID、IPアドレス)、相手先デバイス情報(ID、IPアドレス)が含まれている。図5(b)は、getJobStatusResponseというメソッドであり、自デバイス情報と相手先デバイス情報と図4に示すような、ジョブ種、データサイズ、転送レート、転送完了時間、高速通信モード、優先モードが含まれている。
【0020】
第6図は、実施形態に係わる高速通信モードを設定するSOAPスキーマの一例を示す図である。図6(a)は、高速通信モードの設定を要求するSOAPメソッドで、図6(a)のメソッドのレスポンスで要求に対する結果を返信するSOAPメソッドである。図6(a)のメソッドは、setAccelerationというメソッド名であり、自デバイスのクライアント情報(ID、IPアドレス)、相手先デバイス情報(ID、IPアドレス)、高速通信をOFFにする要求が含まれている。図6(b)は、setAccelerationResponseというメソッドであり、自デバイス情報と相手先デバイス情報と要求に対する結果が含まれている。
【0021】
第7図は、本発明の実施形態に係わる他デバイス装置で優先ジョブ処理されている時のUI表示の一例を示す図である。図7(a)は、図4(b)のような優先ジョブが他デバイスで実施されている際に、デバイスのUIに他デバイスでクラウド印刷がされている旨の表示を行う。図7(b)は、図2の2−10のような圧縮データを用いて、画質劣化を前提にスピード優先で印刷させるかどうかの選択UIの表示を行う。
【0022】
第8図は、本発明の実施形態に係わるサーバとデバイス2台の場合でジョブ処理が重なった場合のシーケンスの一例を示す図である。8−1は、クラウド上サーバで、8−2は、印刷ジョブを取得中のデバイス1である。8−3は、デバイス1がジョブ取得中に印刷ジョブを取得開始したデバイス2である。8−4は、高速通信を3セッション同時通信で実現している。8−5は、8−4のデータ受信に関して、3セッションの同時に受信をしていることを示している。8−6は、図5(a)のSOAPメソッド(getJobStatus
)であり、デバイス1のジョブ状況を確認している。8−7は、図5(b)のSOAP
メソッド(getJobStatusResponse)であり、8−8は、デバイス1のジョブが図4(a)のような優先ジョブではなかったため、図6(a)のsetAccelerationを送信して、高速通信の解除を行っている。8−9では、図6(b)のsetAccelerationResponseであり、高速通信の解除の結果を返信している。8−10では、クラウド上サーバへの高速通信を解除し、1セッションでのシーケンシャルなジョブ取得の要求を行っている。8−11は、データ受信を行う。
【0023】
なお、本例では、3セッション同時接続の例を示したが、もちろん本数に限定されるものではない。また、本例では、HTTPのGETでジョブ取得を行ったが、FTPやWebDAV等の別のプロトコルでもかまわない。また、8−6〜8−9までSOAPプロトコルにて通信を実現したが、SNMPやSLP等の別のプロトコルでもかまわない。
【0024】
第9図は、本発明の実施形態に係わる印刷データを受信するデバイス側のフローチャートである。
【0025】
以下、第11図を用いて、本実施例のデバイス装置の動作を説明する。
【0026】
S901では、CPU(1−1)が、ユーザからのクラウドtoプリント指示を待つ。S902では、CPU(1−1)が、クラウドtoプリント指示があるかどうかを判別する。判別の結果、クラウドtoプリント指示があれば、S903へ進み、そうでなければ、S901へ戻る。S903では、CPU(1−1)が、別デバイスのステータスを取得する。S904では、CPU(1−1)が、現在時刻と図4(a)−5の転送完了時間を比較して、一定時間(1分)以上クラウド利用の予定であるかどうかを判別する。判別の結果、一定時間(1分)以上クラウド利用の予定であれば、S905へ進み、そうでなければ、S911へ進む。S905では、CPU(1−1)が、別デバイスのジョブの優先度(図4(a)−7、図4(b)−1)を確認する。S906では、CPU(1−1)が、優先ジョブがあるかどうかを判別する。判別の結果、優先ジョブがあれば、S907へ進み、そうでなければ、S911へ進む。S907では、CPU(1−1)が、図7(b)のように、他ジョブの通信状況をユーザに通知する。S908では、CPU(1−1)が、スピード優先受信をユーザが許可したか否かを判別する。判別の結果、スピード優先受信をユーザが許可したならば、S910へ進み、そうでなければ、S909へ進む。S909では、CPU(1−1)が、図8の8−10の帯域制限受信を行う。S910では、CPU(1−1)が、図2の2−10の圧縮データ受信を開始する。S911では、CPU(1−1)が、高速通信を行っているデバイスに対して、図6(a)のsetAccelerationを送信して、帯域制限受信指示を行う。S912では、CPU(1−1)が、図8の8−4の高速受信を行う。
【0027】
なお、優先ジョブの設定としては、例えば、カード認証中のジョブ処理を“優先ジョブ”、カード認証中でないジョブ処理を“非優先ジョブ”とユーザ環境の中で様々設定することができる。また、クラウドtoプリント中のジョブ処理を“優先ジョブ”、スキャンtoプリント中のジョブ処理を“非優先ジョブ”というような設定でもかまわない。また、S903の別デバイスへのステータス取得であるが、予め登録されているデバイスに問い合わせをしてもよいし、ブロードキャスト、マルチキャストで問い合わせをしてもかまわない。また、S908、S909、S910の制御はなくてもかまわない。また、帯域制限受信、高速通信の手段に関しては、本案では、マルチセッションか1セッションかを行うことで実現をしたが、特にこれに言及されるようなことはない。
【符号の説明】
【0028】
1−12、2−14、3−7 ネットワーク
2−11、2−12、2−13 デバイス装置

【特許請求の範囲】
【請求項1】
種々のネットワークデバイス装置と種々のサーバ装置ならびに種々のコンピュータが接続されたネットワークジョブ通信システムにおいて、
第一のデバイス装置が、印刷指示を受け付ける手段(S901)と、1ないし複数の第二のデバイス装置からジョブ状態を取得する手段(S903)と前記ジョブ状態の中に優先ジョブがあるか否かを判別する手段(S906)と、
前記のジョブが非優先ジョブを含む場合には、第一のデバイス装置が、前記第二のデバイス装置に帯域制限通信の指示(S911)を行い、かつ、高速通信を行う手段(S912)と、
前記のジョブが優先ジョブである場合には、帯域制限通信(S909)を行うことを特徴とするネットワークジョブ通信システム。
【請求項2】
前記ジョブが優先ジョブを含む場合には、前記ジョブ状況をユーザに通知する(S907)ことを特徴とする請求項1に記載のネットワークジョブ通信システム。
【請求項3】
前記ジョブが優先ジョブを含む場合には、速度優先か否かをユーザに選択させる手段(図7(b))と、ユーザ選択が速度優先か否かを判別する手段(S908)と、
前記ユーザ選択が速度優先である場合には、圧縮データの通信を行う手段(S910)と、ユーザ選択が速度優先でない場合には、帯域制限通信(S909)を行うことを特徴とする請求項1又は請求項2に記載のネットワークジョブ通信システム。
【請求項4】
前記高速通信とは、マルチセッションを行い、帯域制限通信とは、シングルセッションを行う(図9補足)ことを特徴とする請求項1乃至請求項3の何れか1項に記載のネットワークジョブ通信システム。
【請求項5】
前記優先ジョブとは、カード認証中のジョブであり、前記非優先ジョブとは、カード認証中でない、ジョブであること(図7補足)ことを特徴とする請求項1乃至請求項4の何れか1項に記載のネットワークジョブ通信システム。
【請求項6】
前記優先ジョブとは、サーバからの受信ジョブであり、前記非優先ジョブとは、サーバへの送信スキャンジョブであること(図7補足)ことを特徴とする請求項1乃至請求項4の何れか1項に記載のネットワークジョブ通信システム。


【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate


【公開番号】特開2012−155619(P2012−155619A)
【公開日】平成24年8月16日(2012.8.16)
【国際特許分類】
【出願番号】特願2011−15606(P2011−15606)
【出願日】平成23年1月27日(2011.1.27)
【出願人】(000001007)キヤノン株式会社 (59,756)
【Fターム(参考)】