JP4677346B2 - 通信装置及び印刷装置及びこれらを含む印刷システムとその制御方法 - Google Patents

Description

本発明は、通信装置及び印刷装置及びこれら通信装置及び印刷装置を含む印刷システムとその制御方法に関するものである。

近年、携帯電話やデジタルカメラを代表とする様々の携帯機器からプリンタに画像データを送信して印刷させる直接印刷が一般化されている。その場合の通信プロトコルとして、PictBridge、IrDA或はBluetooth等が用いられている。この直接印刷では、当初は写真データや、或はvCardやvCalender等に代表される特定フォーマットのデータだけが印刷可能であった。しかし現在では、BluetoothのBasic Printing Profile（以下、ＢＰＰ）に定められた手法による印刷が可能になっている。これにより、文書も写真も同時に扱えるXHTML-Print形式のデータをやり取りする機器が登場してきている。

ＢＰＰの通信プロトコルでは、プリンタから携帯機器に対してステータスを応答する手法、及び応答可能なステータスが各種定義されている。しかし、応答可能なステータスとして定義されているのはごく一般的なものに限られている。例えば、プリンタのインクが無くなったというステータスは定義されているが、どの色のインクが無くなったかという情報までは定義されていない。よって、このような手法では、各種ステータス情報を追加することは不可能であり、またベンダー独自の定義の追加も禁止されている。更に、ベンダー独自の情報を記述できるフィールドも定義されていないため、ベンダー独自に機能を追加するのは不可能であった。

このような独自情報のやり取りが定義されていない通信プロトコルを使用して独自情報のやり取りをするための技術として特許文献１の技術が提案されている。これによれば、直接印刷システム（ＤＰＳ）のプロトコルにおいて、拡張機能を有する場合には、その拡張機能を予め機能情報の取得の際に通知しておく。その後、ＤＰＳファンクションの実行時に、ＸＭＬで記述したＤＰＳ機能のタグに、その拡張機能に関するタグを追加して追加機能に関する指定を行っている。また技術的な解決以外にも、ＢＰＰ接続を行うベンダー間で新たに追加する情報やその取得方法に関する取り決めを行い、その取り決めに従って通信を行うという手法によって解決する方法もある。
特開２００４−３０３１９４号公報

ＢＰＰの通信プロトコルでは、このような独自情報をやり取りする方法として、唯一、ＢＰＰの下層プロトコルであるＯＢＥＸの特定フィールドに、ある種の情報を記述することが許されている。但し、このフィールドは、テキスト形式のデータであることだけが定義されており、何の目的でいつどのような記述がなされるかは自由である。従って、あるベンダーが記述した内容が別のベンダーの機器では全く異なって解釈される虞がある。例えば、記述した内容がそのままユーザに表示されてしまったり、最悪、解析に失敗して接続が切れたりハングアップしてしまうなどの接続時の不具合を発生させる懸念がある。そのため結局、そのヘッダをベンダー独自で使用することは難しく、実情としてベンダー独自のプリンタステータスを応答することができない状態にあった。

そのような課題に対して、ＢＰＰ接続を行うベンダー間で取り決めを行うという手法による解決も可能であるが、この方法は取り決め自体に非常に時間を要する。また、取り決めに参加していないベンダー機器相手や、それまでに登場した機器相手の接続では不具合が発生する可能性がある。また、その取り決めでは、接続時に互いの機能を確認するためのネゴシエーションを行うという手法が採用されることが多い。しかし、そのような新たなネゴシエーションを設けた場合、ネゴシエーションのためのデータ自体が、それを知らない相手機器に対して不具合を発生させてしまう懸念があった。

また特許文献１に開示されている手法では、機能情報の取得時に拡張機能の情報を通知している。しかし現状のＢＰＰでは、そのような拡張機能に関する情報を通知する手段が存在しない。また、その情報の通知のためにＯＢＥＸの特定フィールドを使用すると、上述したようなステータス情報の通知の際と同様の問題が発生してしまう虞がある。従って、予め拡張機能に関する通知を行うことができないため、特許文献１に開示されている手法をＢＰＰに採用することはできない。更に、特許文献１で示されたＸＭＬのタグ追加による拡張機能の指定という手法は、ＸＭＬ解析能力が不明な不特定相手との通信では、相手機器がどのように動作するかの保証が得られないという問題がある。例えば、ＸＭＬでは、同じ名前の要素や属性が異なる意味で定義される混乱を避けるために、名前空間を利用することがあり、その名前空間の及ぼす範囲を検出して処理を行わなければ、解釈に間違いが起こる。ＸＭＬを解釈・処理するパーサーの能力もＷ３Ｃの仕様どおりのものばかりでなく、必要最小限に機能をおさえたものもある。

本発明の目的は、上記従来技術の問題点を解決することにある。

また本願発明の特徴は、通信装置と印刷装置とが互いに構造化言語を処理可能であることを確認した後、構造化言語で記述した記述データで通信方法を宣言することにより、その後の通信でも相手機器に不具合を発生させてしまう虞がなく、また新たな通信方法の設定をも可能にできる点にある。

上記目的を達成するために本発明の一態様に係る印刷システムは以下のような構成を備える。即ち、
印刷装置に印刷データを供給する通信端末と前記印刷データを受信して印刷する印刷装置とを具備する印刷システムであって、
前記通信端末は、
構造化言語で記述された情報を解析する解析手段を有している場合に、前記情報を解析可能であることを前記印刷装置に対して宣言する手段と、
前記印刷装置が前記構造化言語で記述された情報を解析可能である場合、前記構造化言語で記述した通信方法に関する記述データを前記印刷装置に送信する送信手段と、
前記記述データで記述した前記通信方法に従って前記印刷装置と通信する通信制御手段とを有し、
前記印刷装置は、
前記構造化言語で記述された情報を解析する解析手段を有している場合に、前記情報を解析可能であることを前記通信端末に対して宣言する手段と、
前記通信端末から送信される前記構造化言語で記述された通信方法に関する記述データを解釈する解釈手段と、
前記記述データで記述された前記通信方法に従って前記通信端末と通信する印刷通信制御手段とを有することを特徴とする。

上記目的を達成するために本発明の一態様に係る印刷装置は以下のような構成を備える。即ち、
構造化言語で記述された情報を解析する解析手段と、
前記解析手段を有していることを通信端末に対して宣言する手段と、
前記通信端末から送信される前記構造化言語で記述された通信方法に関する記述データを解釈する解釈手段と、
前記記述データで記述された前記通信方法に従って前記通信端末と通信する印刷通信制御手段と、
前記印刷通信制御手段により通信された印刷データに基づいて印刷を行う印刷制御手段とを有することを特徴とする。

上記目的を達成するために本発明の一態様に係る通信装置は以下のような構成を備える。即ち、
構造化言語で記述された情報を解析する解析手段と、
前記解析手段を有していることを相手機器に対して宣言する手段と、
前記相手機器が前記構造化言語で記述された情報を解析可能である場合、前記構造化言語で記述した通信方法に関する記述データを前記相手機器に送信する送信手段と、
前記記述データで記述した前記通信方法に従って前記相手機器と通信する通信制御手段とを有することを特徴とする。

上記目的を達成するために本発明の一態様に係る印刷装置の制御方法は以下のような工程を備える。即ち、
構造化言語で記述された情報を通信端末から受信して印刷する印刷装置の制御方法であって、
前記通信端末から発行される検索コマンドに応答して、当該印刷装置が構造化言語で記述された情報を解析可能かどうかを通知する通知工程と、
構造化言語で記述された情報を解析する解析機能を有していることを通信端末に対して宣言する工程と、
前記通信端末から送信される前記構造化言語で記述された通信方法に関する記述データを解釈する解釈工程と、
前記記述データで記述された前記通信方法に従って前記通信端末と通信する印刷通信制御工程と、
前記印刷通信制御工程で通信された印刷データに基づいて印刷を行う印刷制御工程と、を有することを特徴とする。

上記目的を達成するために本発明の一態様に係る通信装置の制御方法は以下のような工程を備える。即ち、
構造化言語で記述された情報を印刷装置に送信して印刷させる通信装置の制御方法であって、
印刷装置の識別情報を取得して当該印刷装置が構造化言語で記述された情報を解析可能かどうかを判定する判定工程と、
前記構造化言語で記述された情報を解析可能である旨を前記印刷装置に対して宣言する工程と、
前記判定工程で前記印刷装置が前記構造化言語で記述された情報を解析可能であると判定した場合、前記構造化言語で記述した通信方法に関する記述データを前記印刷装置に送信する送信工程と、
前記記述データで記述した前記通信方法に従って前記印刷装置と通信する通信制御工程とを有することを特徴とする。

本発明によれば、通信方法に関する宣言で相手機器に不具合を発生させる虞がなくなる。また多種の通信方法の適用に柔軟に対応できるという効果がある。

以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

［実施の形態１］
図１は、本発明の実施の形態に係る印刷システムの構成を説明するブロック図である。このシステムでは、プリンタ１０１と通信装置１１０とが無線により接続されている。

プリンタ１０１において、プリンタ制御部１０６は、プリンタエンジンを含み印刷処理を実行する。ＣＰＵ１０２は、ＲＯＭ１０４に記憶された制御プログラムに従って、プリンタ１０１全体の動作を制御する。ＲＡＭ１０５は、ＣＰＵ１０２による制御処理時にワークエリアとして使用され、各種データを一時的に記憶する。またブルーツース（Bluetooth）による通信を制御する部分として、Bluetoothでの通信を制御する無線通信Ｉ／Ｆ制御部１０３、ベースバンド部１０７、ＲＦ部１０８及びアンテナ１０９を備えている。

プリンタ１０１から相手機器へのデータ送信の際には、送信データがBluetooth規格で定められている方式に従って無線通信Ｉ／Ｆ制御部１０２からベースバンド部１０６に転送される。そしてＲＦ部１０７で変調され、アンテナ１０８によって他の無線通信機器に送信される。一方、データ受信の際には、送信の場合とは逆の経路でデータが転送される。

通信装置１１０も同様に、ＣＰＵ１１１、無線通信Ｉ／Ｆ制御部１１４、ＲＯＭ１１２、ＲＡＭ１１３、ベースバンド部１１５、ＲＦ部１１６、及びアンテナ１１７を有している。無線通信Ｉ／Ｆ制御部１１４を通じて、Bluetooth通信によりプリンタ１０１と接続し、各種印刷データや制御データを送受信することにより、プリンタ１０１に印刷を行わせる。通信装置１１０は表示装置（不図示）を備えており各種表示を行うことが可能な構成となっている。

ここでプリンタ１０１は、Bluetooth通信規格のBasic Printing Profile（以下ＢＰＰ）に定められた通信を行うことができ、これに従って印刷を行う。同様に、通信装置１１０もＢＰＰに定められた通信を行うことができ、これによりプリンタ１０１に印刷を指示することができる。通信装置１１０は、ＢＰＰに定められた方式に従って印刷データをプリンタ１０１に送信して印刷を行わせるように制御する。

プリンタ１０１が通信装置１１０からＢＰＰ通信のための接続を受け付ける際の動作について図２のフローチャートを用いて詳細に説明する。

図２は、本実施の形態に係るプリンタ１０１における処理を説明するフローチャートである。この処理を実行するプログラムはＲＯＭ１０４に記憶されており、ＣＰＵ１０２の制御の下で実行される。

この処理は、ＢＰＰの接続に先立ってBluetooth通信規格に定められたサービス検索の通信（以下、ＳＤＰ）を受け付けることにより開始され、まずステップＳ２０１で、プリンタ１０１は、通信装置１１０から受信したＳＤＰ検索に対して、ＢＰＰで定められた１２８４ＩＤ情報で応答する。ここで応答する１２８４ＩＤには、プリンタ１０１がＸＭＬを処理可能であることを示すキー情報が含まれている。このキー情報は、ＸＭＬ規格に定められた名前空間をプリンタ１０１が処理できることを示すとともに、フォーマットが特に定められていない各種ヘッダやフィールドにＸＭＬ情報が含まれていた場合に、ＸＭＬによる処理が可能であることを示す。

図３は、本実施の形態に係るプリンタ１０１が応答するキー情報を含んだ１２８４ＩＤの一例を示す図で、ここではＸＭＬを処理可能であることが記述されている。

ここでは「EXT:XML10」により、ＸＭＬ記述を解釈できることが宣言されている。

次にステップＳ２０２で、相手機器である通信装置１１０に対して予め定めたＳＤＰ属性であるDeviceNameの検索を試みる。ここでDeviceNameの取得が成功するとステップＳ２０３に進み、このDeviceNameに通信装置１１０がＸＭＬを処理可能であることを示す情報を含んでいるかどうかを判断する。この情報は、通信装置１１０がＸＭＬ規格に定められた名前空間を処理可能であることを示すとともに、フォーマットが特に定められていない各種ヘッダやフィールドにＸＭＬ情報が含まれていた場合にＸＭＬによる処理が可能であることを示す情報である。ステップＳ２０３で、この情報がDeviceNameに含まれていなければステップＳ２０９に進み、プリンタ１０１は通信装置１１０が名前空間等のＸＭＬ処理を不可能であると解釈し、その後のステータス処理を通常のＢＰＰに定められた範囲で行う。

尚、本実施の形態では、ＸＭＬを処理可能であることを示すために１２８４ＩＤやDeviceNameを使用しているが、予め定めたその他のＳＤＰ属性やBluetooth通信に伴う情報を採用しても良い。

ステップＳ２０３で、前述の情報がDeviceNameに含まれていればステップＳ２０４に進み、続いて送られくるＢＰＰ用のＯＢＥＸ接続のパケットがDescriptionヘッダ（DescriptionHeader）を含んでいるかどうかを判断する。ここでＯＢＥＸ接続のパケットにDescriptionヘッダが含まれていなければ、プリンタ１０１は通信装置１１０が特定のヘッダやフィールドを使用した拡張通信を行わないと判断する。そしてステップＳ２１０に進み、その後の独自ステータス応答はＢＰＰに定められたＳＯＡＰ応答を利用して行われる。

一方ステップＳ２０４で、ＯＢＥＸ接続のパケットにDescriptionヘッダが含まれているとステップＳ２０５に進み、Descriptionヘッダに含まれるデータがＸＭＬで記述されているかを確認し、ＸＭＬデータであればその内容を解析する。このDescriptionヘッダの内容を解析処理することは、１２８４ＩＤでＸＭＬデータを処理可能であることを示したことに合致する動作である。このように、ＸＭＬデータを解析できることが１２８４ＩＤで示されて保証されていることにより、ヘッダ内にＸＭＬデータを記述しても、それが解釈できないことによる異常処理が発生しないことが保証される。

ステップＳ２０５でのDescriptionヘッダの解析の結果、ステップＳ２０６では、その後の拡張通信にDescriptionヘッダを用いる宣言であると確認できたかどうかを判断する。ここで確認できなければステップＳ２１０に進み、その後の独自ステータス応答では、ＢＰＰに定められたＳＯＡＰ応答を利用して行うようにする。尚ここで、ＸＭＬデータの解析の際、後述するような特定フィールドやヘッダを拡張使用することを示すタグの意味を理解できなかった場合も同様の結果となる。このようなケースは、プリンタ１０１がＸＭＬデータを解釈可能であっても、そのＸＭＬデータで指定されている名前空間を認識できない場合などに発生する。但し、解析処理された結果、名前空間を認識できないことが正しく判定されるため、ここでも想定外の接続問題、例えばタグを認識できないことによる異常処理等が発生しないことが保証される。

一方、ステップＳ２０６で、その後の拡張通信にDescriptionヘッダを用いる宣言であると確認できた場合はステップＳ２０７に進み、プリンタ１０１自身の通信能力に応じて、Descriptionヘッダをその後の拡張通信に使用するかどうかを判断する。ここで拡張通信を行わない、或はDescriptionヘッダを使用しないと判断した場合はステップＳ２１０に進み、その後の独自ステータス応答にはＢＰＰに定められたＳＯＡＰ応答を利用して行うようにする。

ステップＳ２０７で、Descriptionヘッダを拡張通信に使用すると判断した場合はステップＳ２０８に進み、ＯＢＥＸ接続の応答パケットにDescriptionヘッダを付加し、ＸＭＬ形式でDescriptionヘッダの使用に応じるＡＣＫ応答を通信装置１１０に返す。次にステップＳ２１１に進み、その後の独自ステータス応答は、Descriptionヘッダを利用して行うようにする。

図４は、本実施の形態に係るＸＭＬ形式で記述したDescriptionヘッダの使用に応じるＡＣＫ応答の一例を示す図である。

この例では、＜bt-ext:UsedHeader＞で「OBEX:Description:05」により、Descriptionヘッダの使用が宣言されている。そしてこれに対して、ＡＣＫ応答が、＜bt-ext:UsedHeaderResponse＞で「ACK:00」によりＡＣＫ返答がなされている。

尚、本実施の形態では、ヘッダの使用宣言のためにＯＢＥＸのDescriptionヘッダを使用しているが、予め定めた別のヘッダ等を採用しても良い。その後の拡張通信のためにも同じくDescriptionヘッダを用いているが、こちらも予め定めた別のヘッダ等を用いても良い。

また上記説明では、プリンタ１０１は独自のステータス応答を行うことを前提に記述している。しかし独自ステータス応答を行わない場合には、応答する１２８４ＩＤにＸＭＬデータが処理可能であることを示さない。或は示したとしても、その後のステータス処理を通常のＢＰＰに定められた範囲で行うようにすれば良い。

図５は、本実施の形態に係る印刷システムの通信装置１１０におけるＢＰＰ通信のための接続処理を説明するフローチャートで、この処理を実行するプログラムはＲＯＭ１１２に記憶されており、ＣＰＵ１１１の制御の下に実行される。

まずステップＳ３０１で、ＢＰＰの接続に先立って、ＢＰＰで定められた１２８４ＩＤ情報のＳＤＰ検索をプリンタ１０１に対して行う。またステップＳ３０２で、プリンタ１０１からの予め定めたＳＤＰ属性であるDeviceNameの検索があれば、このDeviceNameに通信装置１１０がＸＭＬデータを処理可能であることを示す情報を入れて応答する。

ここで通信装置１１０が応答するＸＭＬデータを処理可能であることを示す情報を含んだDeviceNameの例は、前述の図３に示す通りである。

次にステップＳ３０３で、取得した１２８４ＩＤに、ＸＭＬによる処理が可能であることを示すキー情報が含まれているかどうかを判断し、含まれていなければステップＳ３０９に進み、その後のステータス処理を、通常のＢＰＰで定められた範囲で行うようにする。

一方、ステップＳ３０３で、取得した１２８４ＩＤに、ＸＭＬによる処理が可能であることを示すキー情報が含まれているとステップＳ３０４に進み、自身の通信能力に応じて、Descriptionヘッダをその後の拡張通信に使用するかどうかを判断する。ここでDescriptionヘッダをその後の拡張通信に使用しないと判断するとステップＳ３１０に進み、その後、プリンタ１０１からのＳＯＡＰ応答を利用した独自ステータス応答を取得できるように処理を行う。ここで通信装置１１０は、フィールドやヘッダを拡張使用した拡張は行わないが、ＸＭＬデータが解釈可能ではあるという状態にある。よって、仮にプリンタ１０１が通信装置１１０の知らない名前空間を利用して独自ステータス情報を付加してきたとしても、単純に読み捨てるだけの動作となる。従って、想定外の接続問題、例えばタグを認識できないことによる異常処理等が発生しないことを保証した動作となっている。

ステップＳ３０４で、Descriptionヘッダをその後の拡張通信に使用すると判断した場合はステップＳ３０５に進む。ここでは、続くＢＰＰ用のＯＢＥＸ接続のパケットにDescriptionヘッダを付加し、その後の拡張通信にDescriptionヘッダを使用する宣言をＸＭＬ形式で記述してプリンタ１０１に送信する。

このＸＭＬ形式で記述したDescriptionヘッダの拡張使用宣言の一例は前述の図４に示す通りである。

ここで仮に、プリンタ１０１が図４に示した「bt-ext」の名前空間を理解できなくても、その名前空間上で使用されたタグに含まれる情報は１２８４ＩＤで宣言されているＸＭＬ処理に従って読み捨てられる。このため、安全に動作することが保証される。

次にステップＳ３０６に進み、その後のＯＢＥＸ接続に対する応答パケットにDescriptionヘッダが含まれているかどうかを判断し、Descriptionヘッダに含まれるデータがＸＭＬによって記述されているか否かを確認する。そうでなければステップＳ３１０に進むが、ＸＭＬデータであればステップＳ３０７に進み、そのＸＭＬデータの内容を解析する。そしてステップＳ３０８に進み、そのデータがＸＭＬ形式で記述されたDescriptionヘッダの使用に応じるＡＣＫ応答かどうかを判断し、そうでなければステップＳ３１０に進み、その後、プリンタ１０１からのＳＯＡＰ応答を利用しての独自ステータス応答を取得できるように処理する。

一方、ステップＳ３０８で、Descriptionヘッダの使用に応じるＡＣＫ応答であった場合はステップＳ３１１に進み、その後のDescriptionヘッダを利用しての独自ステータス応答を取得できるよう処理を行う。ここでは通信装置１１０はDescriptionヘッダを拡張使用してＸＭＬデータを解釈できる状態にある。よって、プリンタ１０１が通信装置１１０の知らない名前空間を利用して独自のステータス情報を付加してきたとしても、単純に読み捨てるだけの動作となり、異常処理等が発生しないことが保証される。

以上説明した手順で処理を行う事により、例えば、通信装置１１０が特定のヘッダを扱えないケースであっても、プリンタ１０１から独自ステータスを送信することにより、通信装置が異常な動作を引き起こしてしまう可能性を排除できる。

また同様に、例えば、プリンタ１０１が特定のヘッダを扱えないケースであっても、プリンタ１０１に送信したネゴシエーションパケットがプリンタ１０１の異常な動作を引き起こしてしまう可能性を排除できる。

このように本実施の形態に係る印刷システムによれば、お互いの処理能力を知らないプリンタと通信装置との間での安全なネゴシエーションが可能となる。また、独自のステータス応答通信を安全に行うことが可能となっている。

更に、この処理手順は、ＳＤＰによるＸＭＬの処理表明と、接続時に使用するヘッダだけが予め定められている事項であり、最小限の取り決め事項で安全に拡張性の高い通信を行うことができる利点がある。また、この手順を採用する機器から順に実装可能であるという点もメリットである。

図６は、本実施の形態において、プリンタ１０１及び通信装置１１０がＢＰＰ通信を行いつつ独自ステータスを応答する際の動作例を説明する図である。

ここでは、プリンタ１０１及び通信装置１１０が、ＢＰＰのJobBasedModelで規定されたGetEventによるステータス応答を行う際の動作の流れを示している。また図６において、前述のフローチャートに従って、Descriptionヘッダを拡張使用して独自ステータス応答を行う際のパケットの様子も示している。

プリンタ１０１及び通信装置１１０は、前述のフローチャートに従って、Ｓ４０１〜Ｓ４０４で示す動作を実行して、お互いの装置がＸＭＬデータを処理可能であることを確認する。通信装置１１０は、プリンタ１０１がＸＭＬデータを処理可能であることを確認すると、Ｓ４０５で示すように、続くＢＰＰ用のＯＢＥＸ接続のパケットにDescriptionヘッダを付加し、ＸＭＬデータで記述したDescriptionヘッダ使用宣言を入れる。これに対してプリンタ１０１は、Ｓ４０６で示すように、ＯＢＥＸ接続の応答パケットにDescriptionヘッダを付加し、ＸＭＬデータで記述したＡＣＫ応答を入れる。

その後、Ｓ４０７で、通信装置１１０からのGetEvent要求がプリンタ１０１に送信される。このときプリンタ１０１は、独自のステータスが存在すれば、Ｓ４０８で示すように、通常のGetEvent応答パケットにDescriptionヘッダを付加し、ＸＭＬデータで記述した独自ステータスを入れて応答する。ＸＭＬデータで記述する独自ステータスの内容としては、GetEventで応答しないステータスを記述するだけでなく、GetEventで応答しているステータスと同等の内容を重ねて記述しても良い。この様にして、通信装置１１０からのGetEvent要求に対して、プリンタ１０１は独自ステータスを付加して応答する。

図７は、本実施の形態に係るプリンタ１０１により応答される独自ステータスの一例を示す図である。

ここで通信装置１１０が、この独自ステータスに含まれる「ganon-IJ」や「iPXX」の名前空間を理解して、その内容を解釈できれば、通信装置１１０はプリンタ１０１の独自ステータスを取得できることになる。仮に、通信装置１１０が、この図７の「ganon-IJ」や「iPXX」の名前空間を理解できない場合であっても、その名前空間上で使用されたタグに含まれる情報はServiceNameで宣言したＸＭＬ処理に従って読み捨てられる。このため、安全に動作することが保証される。

図８は、本実施の形態において、プリンタ１０１及び通信装置１１０がＢＰＰ通信を行いつつ独自ステータスを応答する際の別の動作例を説明する図である。

図８は、プリンタ１０１及び通信装置１１０がＢＰＰのJobBasedModelで規定されたGetEventによるステータス応答を行う際の動作の流れを示している。ここでは図６とは異なり、ＳＯＡＰ応答を利用しての独自ステータス応答を行う際のパケットの様子を示している。

プリンタ１０１及び通信装置１１０は、前述のフローチャートに従って、Ｓ５０１〜Ｓ５０４の動作を行って、お互いの機器がＸＭＬデータを処理できることを確認する。通信装置１１０は、プリンタ１０１がＸＭＬデータを処理できることを確認すると、Ｓ５０５で示すように、続くＢＰＰ用のＯＢＥＸ接続のパケットにDescriptionヘッダを付加し、ＸＭＬで記述したDescriptionヘッダ使用宣言を入れる。ここでプリンタ１０１がDescriptionヘッダの使用を拒否する場合には、Ｓ５０６で示すように、ＯＢＥＸ接続の応答パケットにDescriptionヘッダを付加せず応答する。

その後、Ｓ５０７で、通信装置１１０からのGetEvent要求がプリンタ１０１に送信される。このときプリンタ１０１は、独自のステータスが存在すれば、Ｓ５０８で示すように、通常のGetEventのＳＯＡＰ応答部分に、ＸＭＬデータで名前空間を拡張して記述した独自ステータスを入れて応答する。このＸＭＬデータで記述する独自ステータスの内容としては、GetEventで応答しないステータスを記述するだけでなく、GetEventで応答しているステータスと同等の内容を重ねて記述しても良い。この様にして、通信装置１１０からのGetEvent要求に対して、プリンタ１０１が独自ステータスを付加して応答する。

図９は、本実施の形態において、ＳＯＡＰ応答にＸＭＬデータで独自ステータスを追加した記述例を示す図である。

図において、９００は独自ステータスによる応答部分を示している。ここで、通信装置１１０が図に示した「ganon-IJ」や「iPXX」の名前空間を理解し、その内容を解釈することができれば、通信装置１１０はプリンタ１０１の独自ステータスを取得できる。仮に、通信装置１１０が図９に示した「ganon-IJ」や「iPXX」の名前空間を理解できなくとも、その名前空間上で使用されたタグに含まれる情報はServiceNameで宣言したＸＭＬ処理に従って読み捨てられるため、安全に動作することが保証される。

図１０は、本実施の形態に係るプリンタ１０１及び通信装置１１０がＢＰＰ通信を行いながら独自ステータスを応答する際の更なる別の動作例を説明する図である。ここでは、プリンタ１０１及び通信装置１１０がＢＰＰのSimplePushModelで規定されたFilePush時に独自のステータス応答を行う際の動作を示している。また図１０は、通信装置１１０がFilePushを行う際のＯＢＥＸ通信をパケットごとに図示している。

前提として、プリンタ１０１及び通信装置１１０は、前述のフローチャートに従ってＸＭＬの処理確認及びDescriptionヘッダの使用確認を行う。このSimplePushModelではＳＯＡＰ通信が行われないので、仮にDescriptionヘッダを使用しない状態となった場合は独自ステータス応答は行わず、通常のＢＰＰ処理を行うのみとなる。図１０では、Descriptionヘッダを使用して独自ステータス応答を行う際の例を示している。

SimplePushModelのFilePushでは、印刷データのファイルサイズがＯＢＥＸのMAXパケットサイズ以上であれば、図１０に示すようにいくつかのパケットに分割されて複数回のＰＵＴで送信される。そして各ＰＵＴに対するContinueもしくはSuccess応答のパケットに、図１０に示すようにDescriptionヘッダを付加し、ＸＭＬで記述した独自ステータスを入れて応答する。

ここで仮に、プリンタ１０１がＯＢＥＸの各ＰＵＴ送信に対して即座にContinueもしくはSuccess応答を行った場合、印刷データの受信は印刷の開始前もしくは印刷の早い段階で終了してしまう可能性が高い。従って、プリンタ１０１のステータスを応答する機会は、印刷の開始前、もしくは印刷の早い段階に限られる。そのような状況を回避するために本実施の形態では、図１０に示すように各ContinueもしくはSuccess応答を返す前に、ウエイト時間（Wait）を入れている。このようなウエイト時間を入れることにより、ステータス応答する機会を、印刷の間際、或は印刷の終了まで持つことが可能となっている。

図１１は、本実施の形態において、プリンタ１０１がContinueもしくはSuccess応答を行う際のウエイト動作に関する処理を説明するフローチャートである。この処理を実行するプログラムはＲＯＭ１０４に記憶されており、ＣＰＵ１０２の制御の下で実行される。尚、図１１も図１０と同様に、プリンタ１０１がSimplePushModel でDescriptionヘッダによる独自ステータス応答を行う際の処理の流れを示している。また印刷データとしてはＸＨＴＭＬ形式の印刷データを受信して印刷するものとする。

まずステップＳ１１０１で、プリンタ１０１がＯＢＥＸのＰＵＴパケットを受信するとステップＳ１１０２に進み、そのパケットが最終パケットであるかどうかを判断する。最終パケットかどうかは、ＯＢＥＸ通信規格で定められた特定のBITで確認できる。ここで最終パケットであればステップＳ１１０３に進み、そのEnd of Body部から印刷データの最終パケットを取り出す。次にステップＳ１１０４で、その取り出した最終の印刷データのＸＨＴＭＬ解析を行う。そしてステップＳ１１０５で、そのＸＨＴＭＬデータをレンダリングして印刷を行う。そしてステップＳ１１０６で印刷の終了を待ち、印刷が終了するとステップＳ１１０７で、最終の応答で返すプリンタ１０１のステータスを作成する。そしてステップＳ１１０８に進み、そのステータスをDescriptionヘッダに付加してSuccess応答を行う。

一方、ステップＳ１１０１で、受信したＰＵＴパケットが最終パケットではない場合はステップＳ１１０９に進み、そのBody部から印刷データの途中パケットを取り出し、ステップＳ１１１０でＸＨＴＭＬデータを解析する。このＸＨＴＭＬデータの解析の結果、例えば受信したデータがヘッダ部分のみだけであるなどの理由により印刷できない場合かどうかを判定し、印刷できない場合はステップＳ１１１８に進む。ここでは、プリンタ１０１のステータスを付加せず、即座に通常のContinue応答を行って、次のＰＵＴパケットの受信に備える。

ステップＳ１１１１で、受信したデータの範囲で印刷が可能であると判断した場合はステップＳ１１１２に進み、ＸＨＴＭＬデータをレンダリングをして印刷を行う。次にステップＳ１１１３で、その印刷の終了を待つ。次にステップＳ１１１４で、この印刷の終了までプリンタ１０１のステータスの変化がなく印刷が正常に行われたかどうか判断する。正常であればステップＳ１１１５に進み、正常ステータスを作成し、それをDescriptionヘッダに付加してContinue応答を行う。一方、ステップＳ１１１４で、この印刷中にプリンタ１０１の何らかの異常やステータスの変化があるとステップＳ１１１６に進み、そのステータスを作成する。そしてステップＳ１１１７に進み、Descriptionヘッダに付加してContinue応答を行う。そして、次のＰＵＴパケットの受信に備える。

以上説明したように本実施の形態によれば、受信したデータ分の印刷を確認してから、そのステータス応答を行っている。このため、ステータス応答する機会を印刷の間際もしくは終了まで持つことが可能となっている。

（他の実施形態）
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、また一つの機器からなる装置に適用しても良い。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、様々なものが使用できる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などである。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。その場合、ダウンロードされるのは、本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルであってもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する形態としても良い。その場合、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムが実行可能な形式でコンピュータにインストールされるようにする。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される形態以外の形態でも実現可能である。例えば、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。

更に、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれるようにしてもよい。この場合、その後で、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって前述した実施形態の機能が実現される。

本発明の実施の形態に係る印刷システムの構成を説明するブロック図である。 本実施の形態に係るプリンタにおける処理を説明するフローチャートである。 本実施の形態に係るプリンタが応答するキー情報を含んだ１２８４ＩＤの一例を示す図である。 本実施の形態に係るＸＭＬ形式で記述したDescriptionヘッダの使用に応じるＡＣＫ応答の一例を示す図である。 本実施の形態に係る印刷システムの通信装置におけるＢＰＰ通信のための接続処理を説明するフローチャートである。 本実施の形態において、プリンタ及び通信装置がＢＰＰ通信を行いつつ独自ステータスを応答する際の動作例を説明する図である。 本実施の形態に係るプリンタにより応答される独自ステータスの一例を示す図である。 本実施の形態において、プリンタ及び通信装置がＢＰＰ通信を行いつつ独自ステータスを応答する際の別の動作例を説明する図である。 本実施の形態において、ＳＯＡＰ応答にＸＭＬデータで独自ステータスを追加した記述例を示す図である。 実施の形態に係るプリンタ及び通信装置がＢＰＰ通信を行いながら独自ステータスを応答する際の更なる別の動作例を説明する図である。 本実施の形態において、プリンタがContinueもしくはSuccess応答を行う際のウエイト動作に関する処理を説明するフローチャートである。

Claims (16)

1. 印刷装置に印刷データを供給する通信端末と前記印刷データを受信して印刷する印刷装置とを具備する印刷システムであって、
   前記通信端末は、
   構造化言語で記述された情報を解析する解析手段を有している場合に、前記情報を解析可能であることを前記印刷装置に対して宣言する手段と、
   前記印刷装置が前記構造化言語で記述された情報を解析可能である場合、前記構造化言語で記述した通信方法に関する記述データを前記印刷装置に送信する送信手段と、
   前記記述データで記述した前記通信方法に従って前記印刷装置と通信する通信制御手段とを有し、
   前記印刷装置は、
   前記構造化言語で記述された情報を解析する解析手段を有している場合に、前記情報を解析可能であることを前記通信端末に対して宣言する手段と、
   前記通信端末から送信される前記構造化言語で記述された通信方法に関する記述データを解釈する解釈手段と、
   前記記述データで記述された前記通信方法に従って前記通信端末と通信する印刷通信制御手段と、
   を有することを特徴とする印刷システム。
2. 前記構造化言語はＸＭＬであることを特徴とする請求項１に記載の印刷システム。
3. 前記通信端末と前記印刷装置とはBluetoothにより通信することを特徴とする請求項１に記載の印刷システム。
4. 前記宣言は、Bluetoothの通信規格に定められたサービス検索の通信により実行されることを特徴とする請求項３に記載の印刷システム。
5. 前記記述データは、ＯＢＥＸのDescriptionヘッダで送信されることを特徴とする請求項３又は４に記載の印刷システム。
6. 構造化言語で記述された情報を解析する解析手段と、
   前記解析手段を有していることを相手機器に対して宣言する手段と、
   前記相手機器が前記構造化言語で記述された情報を解析可能である場合、前記構造化言語で記述した通信方法に関する記述データを前記相手機器に送信する送信手段と、
   前記記述データで記述した前記通信方法に従って前記相手機器と通信する通信制御手段と、
   を有することを特徴とする通信装置。
7. 構造化言語で記述された情報を解析する解析手段と、
   前記解析手段を有していることを通信端末に対して宣言する手段と、
   前記通信端末から送信される前記構造化言語で記述された通信方法に関する記述データを解釈する解釈手段と、
   前記記述データで記述された前記通信方法に従って前記通信端末と通信する印刷通信制御手段と、
   前記印刷通信制御手段により通信された印刷データに基づいて印刷を行う印刷制御手段と、
   を有することを特徴とする印刷装置。
8. 構造化言語で記述された情報を印刷装置に送信して印刷させる通信装置の制御方法であって、
   印刷装置の識別情報を取得して当該印刷装置が構造化言語で記述された情報を解析可能かどうかを判定する判定工程と、
   前記構造化言語で記述された情報を解析可能である旨を前記印刷装置に対して宣言する工程と、
   前記判定工程で前記印刷装置が前記構造化言語で記述された情報を解析可能であると判定した場合、前記構造化言語で記述した通信方法に関する記述データを前記印刷装置に送信する送信工程と、
   前記記述データで記述した前記通信方法に従って前記印刷装置と通信する通信制御工程と、
   を有することを特徴とする通信装置の制御方法。
9. 前記通信装置と前記印刷装置とはBluetoothにより通信することを特徴とする請求項８に記載の制御方法。
10. 前記宣言は、Bluetoothの通信規格に定められたサービス検索の通信により実行されることを特徴とする請求項９に記載の制御方法。
11. 前記記述データは、ＯＢＥＸのDescriptionヘッダで送信されることを特徴とする請求項９又は１０に記載の制御方法。
12. 構造化言語で記述された情報を通信端末から受信して印刷する印刷装置の制御方法であって、
    前記通信端末から発行される検索コマンドに応答して、当該印刷装置が構造化言語で記述された情報を解析可能かどうかを通知する通知工程と、
    構造化言語で記述された情報を解析する解析機能を有していることを通信端末に対して宣言する工程と、
    前記通信端末から送信される前記構造化言語で記述された通信方法に関する記述データを解釈する解釈工程と、
    前記記述データで記述された前記通信方法に従って前記通信端末と通信する印刷通信制御工程と、
    前記印刷通信制御工程で通信された印刷データに基づいて印刷を行う印刷制御工程と、を有することを特徴とする印刷装置の制御方法。
13. 前記印刷装置と前記通信装置とはBluetoothにより通信することを特徴とする請求項１２に記載の制御方法。
14. 前記宣言は、Bluetoothの通信規格に定められたサービス検索の通信により実行されることを特徴とする請求項１３に記載の制御方法。
15. 前記記述データは、ＯＢＥＸのDescriptionヘッダで送信されることを特徴とする請求項１２又は１３に記載の制御方法。
16. 請求項８乃至１５のいずれか１項に記載の制御方法をコンピュータに実行させるためのプログラム。

Images