JP2004213578A - 電子機器の制御方法 - Google Patents

Abstract

【課題】ネットワーク接続が可能な電子機器において、簡単安価かつ確実に自動的に消耗品の発注を行なえるようにする。
【解決手段】運用を通じて消耗品の欠乏を生じる端末３１００（電子機器）において、インターネットサイト３０００からハードウェア非依存型のプログラムオブジェクトとしてのＪａｖａアプレットを受信し、Ｊａｖａ仮想マシン３１０４上で実行することにより、Ｊａｖａアプレットに登録された情報にしたがって端末３１００の運用に必要な消耗品を注文するための予め定められた形式に標準化された消耗品注文情報を生成し、プログラムオブジェクトの制御により、生成された消耗品注文情報をプログラムオブジェクトに含まれる情報にしたがってあらかじめ定められたサイトに送信する。
【選択図】 図３

Description

【０００１】
【発明の属する技術分野】
本発明は運用を通じて消耗品の欠乏を生じる電子機器の制御方法に関するものである。
【０００２】
【従来の技術】
従来より、オフィス機器、家庭用機器などの電子機器の状態を、電話回線、あるいは、ＬＡＮやインターネットを介してサービスセンターなどからリモートで診断するサービスが知られている。このようなリモート診断により、たとえば診断によってトナーなどの消耗品の交換時期が近づいていることが判ったとき、サービスセンター側から電話やファクシミリでアナウンスしたり、サービスマンを派遣したり、あるいは、通信販売のように消耗品をユーザ先に届けたりするサービスを行なうことも可能である。一般にこの種のリモート診断は、サービスセンター側の主導でユーザ機器を発呼（ポーリング）して行なうものが多い。
【０００３】
一方で、たとえば昨今の一般消費者向けファクシミリ装置のような安価な電子機器でも、単にファクシミリ通信をするだけでなく、データモデムなどを用いてプロバイダ経由でインターネットに接続することが可能な電子機器がある。
【０００４】
しかし、サービスセンターからユーザ機器の状況を確認するには、大きな設備と管理業務が必要である。すなわち、サービスセンター側の主導でユーザ機器を発呼（ポーリング）してリモート診断するような手法では、上記のようにインターネット接続機能を有する一般消費者向けの安価な機器をもサービス範囲とすると、各ユーザ機器をポーリングするためのサービスセンター側の負荷が非常に大きくなってしまう問題がある。
【０００５】
ここで、一般消費者向けの電子機器で、上記のようなリモート診断サービスを受けるための手段を持たない機器を使っているユーザが消耗品（たとえばプリンタやファクシミリ装置ではトナーやインクなどの記録材）を入手する方法を考えてみる。たとえば隣接地域にこの種の消耗品を扱っている小売店がない郊外のユーザは、消耗品が無くなったとき、わざわざ遠方の店まで足を運んで入手しなければならない。他方、都市圏のユーザは近隣に小売店があるものの、平日に小売店が営業している時間内に消耗品を購入するために店に出向くことが難しい場合も充分ありえる。
【０００６】
また、ネットワーク接続が可能なオフィス機器、家庭用機器などにおいて、装置埋め込み型のウェブ・ページを生成し、他の装置（ホストコンピュータなど）からその機器の状態を表示したり、セットアップを行なったりする技術が知られている（下記の特許文献１）。
【０００７】
特許文献１では、ネットワーク接続が可能な機器に装置埋め込みのウェブ・ページを生成する手段を設ける技術が提案されている。装置１０のためのサプライ用品を注文したり、装置１０の製造業者から将来の製品に関する情報を取得するためのハイパーリンクを装置ウェブ・ページ１８に設けることが記載されている。ただし、この特許文献１に記載の技術では、サプライ用品の注文はユーザが手動操作により装置ウェブ・ページ１８を操作して行なうものであり、ユーザの負担がそれほど大きく軽減されるものではない。
【０００８】
【特許文献１】
特開平１０−２５４８０６号公報（図１）
【０００９】
【発明が解決しようとする課題】
以上に鑑み、サービスセンター側の主導によらず、消耗品の欠乏（あるいは残量僅少）が生じた際にユーザ機器側の自動制御によりあらかじめ選択された消耗品取り扱い業者に対して自動的に消耗品の発注を行なえる構成が望まれる。
【００１０】
そして、このような自動的に消耗品の発注を行なう構成においては簡単安価かつ確実に消耗品の発注を行なえなければならない。
【００１１】
また、通常の通信販売（インターネット経由の注文を含む）による商品購入では、ユーザには業者選定の自由はもちろん、自由意思で、あるいは品切れなどの事情に応じて、標準以外の製品、たとえば安価な互換品を選択するような自由が保証されている。
【００１２】
したがって、ユーザ機器が消耗品やサプライ用品を自動注文できたとしても、ユーザが特定の業者からの購入、あるいは常に高価な標準品の購入を強制されたり、品切れの場合に他の互換品を選択できないのであれば非常に不都合である。
【００１３】
また、互換品が選択できるにしても、確実に互換性を有する消耗品やサプライ用品を注文できなければならない。
【００１４】
本発明の課題は、上記の問題点に鑑み、ネットワーク接続が可能な電子機器において、簡単安価かつ確実に自動的に消耗品の発注を行なえるようにすることにある。
【００１５】
また、本発明の他の課題は、この種の商品注文システムにおいて、ハードウェア非依存型のプログラムオブジェクトを用い、電子機器のメーカーや機種によらず、共通のプログラムオブジェクトをひとつ用意するだけで、本願に基づく電子機器と通信可能なサイトを構築することができるようにする、すなわち、メーカーに依存しない不特定多数の小売店も、本願に基づく受注業務に参入するチャンスが得られるシステムを提供することにある。
【００１６】
さらに、本発明の他の課題は、この種の商品注文システムにおいて、電子機器とハードウェア非依存型のプログラムオブジェクトとの間のデータ形式を一般的なコード体系とすることで、同プログラムオブジェクト側において独自サービスや独自アプリケーションを容易に提供できるようにすることにある。
【００１７】
【課題を解決するための手段】
上記の課題を解決するため、本発明によれば、運用を通じて消耗品の欠乏を生じる電子機器の制御方法において、インターネットサイトからハードウェア非依存型のプログラムオブジェクトを受信し、前記プログラムオブジェクトに含まれる情報にしたがって電子機器の運用に必要な消耗品を注文するための予め定められた形式に標準化された消耗品注文情報を生成し、前記プログラムオブジェクトの制御により、生成された前記消耗品注文情報を前記プログラムオブジェクトに含まれる情報にしたがってあらかじめ定められたサイトに送信する構成を採用した。
【００１８】
【発明の実施の形態】
以下、図を参照して本発明の実施の形態を説明する。以下では、電子機器の一例として、インターネット通信の可能な通信端末を例示する。
【００１９】
図１に本発明を採用した通信端末（以下では単に端末という）を示す。図１の端末は、回線に接続し、プロバイダ経由でインターネットに接続する機能と、回線を介して他の端末と通話や、国際規格ＩＴＵ−Ｔ勧告に基づいてファクシミリ通信を行なう通信機能を有する。
【００２０】
図１において符号１１は端末へのデータ入力のためのテンキー、１２はプロバイダ経由でインターネットに接続するために使用するＮＥＴキー、１３は端末のファクシミリ動作をスタートさせたりテンキーからの入力データを確定させるためのスタートキー、１４は端末の動作の中断や入力データのクリアを指示するためのストップキー、１５はＬＣＤによりグラフィック表示を行なうための表示部であり、１６はＪａｖａ（商標名、以下省略）アプリケーションの作動状況を表示するためのインジケータ、１７は通話用のハンドセット、１８は光学的に原稿を読み取るスキャナ部の原稿挿入口、１９は受信したファクシミリ画像をプリント出力するためのプリンタ部の記録紙排紙口である。
【００２１】
図２に図１の端末の制御系の構成を示す。
【００２２】
図２において符号２１は回線との接続インターフェースとして機能するＮＣＵ（Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）で、ハンドセット２２と接続する電話部、またはＭＯＤＥＭ２３のいずれかを選択的に回線に接続する。
【００２３】
符号２３はプロバイダとの通信を行ったり他の端末との間でファクシミリ通信を行なうための公知のＭＯＤＥＭ、２４はＬＣＤによる公知のグラフィックディスプレイ、２５はテンキーや各種キーを含むキーパネル、２６はＲＡＭ、２７は端末本体のハードウエアを制御するための固定プログラムなどを格納したＲＯＭ、２８は中央制御部としてのＣＰＵ、２９は原稿を光学的に読み取りファクシミリデータを生成するための公知のスキャナ部、２１０は受信したファクシミリ画像を記録紙に記録するためのインクジェット方式（あるいは電子写真方式など任意の記録方式）のプリンタ部である。
【００２４】
図３は、インターネット上のサイトとプロバイダと端末の関係、および、端末側のソフトウェアモジュールの構成を示すブロック図である。本実施形態では、ハードウェア非依存型のプログラムオブジェクトとして、Ｊａｖａアプレットを採用する。
【００２５】
サイト３０００と端末３１００は、インターネット３３００とプロバイダ３２００と回線３４００を介して接続される。端末３１００は、ソフトウェアモジュール３１０１〜３１０８から構成される。
【００２６】
ＲＴＯＳ（リアルタイムＯＳ：ただしリアルタイム性の程度は任意である）３１０１は、タスク３１０２〜３１０７の実行制御に加え、各タスク間の通信の制御や、Ｊａｖａアプリケーション格納領域３１０８をはじめとするメモリに対する各タスクのアクセス制御を行なう。
【００２７】
ＷＷＷブラウザ３１０２は、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に基づいて指示されたサイトとの間でデータのやり取りを行ったり、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）の解析を行ったりするためのものである。
【００２８】
Ｊａｖａアプリケーションマネージャー３１０３（以下ＪＡＭという）は、ＷＷＷブラウザ３１０２を介して指定されたサイトからＪａｖａアプレットなどをダウンロードしてＪａｖａアプリケーション格納領域３１０８に格納（同図破線３４０１）したり、ユーザの要求などに基づいてＪａｖａアプリケーション格納領域３１０８に格納されているＪａｖａアプレットを起動（同図破線３４０２）したり、同格納領域から削除したりする。
【００２９】
起動されたＪａｖａアプレットは、Ｊａｖａ仮想マシン３１０４（以下ＪＶＭという）上にロードされ、あらかじめ用意されているライブラリなどを使って実際に実行される。このライブラリの中には、ハードウェア依存のインク有無の情報をハードウェア非依存の形式で標準化して扱うためのソフトウェアインタフェース機構を有している。また、このインタフェースの仕様は、一般に公開されている。
【００３０】
記録系タスク３１０５は、記録系の制御全般を行なうほかに、本発明で必須であるインクの残量検知の処理を行なう。残量検知の詳細は後述する。
【００３１】
端末を制御するために、上記のほかに、図２のＮＣＵ２１やＭＯＤＥＭ２３を制御してダイヤルや通信を行なうタスク、キーパネル２５を監視してユーザからのキー入力を受け付けるタスク、表示部２４のデバイスを制御して実際に表示を行なうタスクなどがある。しかし本発明に直接関係ない部分なので、ここでは便宜上その他のタスク３１０６〜３１０７（タスク１〜ｎ）としてそれらを表すものとする。
【００３２】
図３のタスクやプログラムモジュールは図２のＣＰＵ２８により実行され、また、その際、ＲＡＭ２６がワークエリア（たとえばＪａｖａアプリケーション格納領域３１０８）として用いられる。ＲＴＯＳ３１０１の主要部、たとえば、Ｊａｖａアプリケーションマネージャー３１０３、Ｊａｖａ仮想マシン３１０４などのＪａｖａ実行環境、ハードウェア制御のためのタスク３１０６〜３１０７（タスク１〜ｎ）などのプログラムは上記のＲＯＭ２７にあらかじめ格納されているものとする。Ｊａｖａアプレットは、一部ＲＯＭ２７などの記憶手段に最初から格納されているものの他は、インターネット３３００からダウンロードされ、ＪＶＭ（Ｊａｖａ仮想マシン）３１０４上で実行される。
【００３３】
図４にＪａｖａアプレットのダウンロードと起動の流れに関する一例を示している。図４では、ユーザの手動操作を契機として消耗品の発注を行なう場合を例示する。
【００３４】
まず、ユーザは図１のＮＥＴキー１２を押して、図３のプロバイダ３２００を介して、インターネット３３００にアクセスする（ステップＳ４００１）。
【００３５】
次に、ユーザは発注アプレットがあるＵＲＬのサイトにアクセスする（ステップＳ４００２）。ここで重要なのは、本実施形態の発注アプレットはハードウェア非依存の言語であり、かつ、一般に公開されたインタフェース仕様を有する（Ｊａｖａ）ライブラリを介して、ハードウェア依存のインク有無の情報をハードウェア非依存の形式で標準化して扱うことができる点である。
【００３６】
すなわち、一般に公開されたインタフェース仕様を有する端末であれば、異なるメーカーの端末であっても、同一の発注アプレットを利用することができる。また、上記利点から、ごく一般の小売店であってもメーカーや端末に依存しない発注アプレットを作成することが可能で、従来よりも極めて容易に一種の通信販売業に参入することが可能になる。ステップＳ４００２の説明に戻れば、ユーザはインターネット３３００上の検索エンジンなどを活用して、発注アプレットのある任意のサイトを選択することが可能である。
【００３７】
続いて、ユーザは希望にあった発注アプレットを、図３のＪＡＭ３１０３を使って、同図中のＪａｖａアプリケーション格納領域３１０８にダウンロードかつ格納する（ステップＳ４００３）。ダウンロードが完了すると、ＪＡＭ３１０３の機能により、ダウンロードしたアプレットをその場で起動するか否かの問い合わせダイアログが図１のＬＣＤ１５に表示される（ステップＳ４００４）。もしユーザが起動を許可すれば、ダウンロード／格納された発注アプレットはＪＡＭ３１０３によってＪＶＭ３１０４上にロードされ、起動される（ステップＳ４００５）。このときのアプレットの流れは、図３の破線３４０１のようになる。
【００３８】
もしユーザが起動を許可しなければ、アプレットはＪａｖａアプリケーション格納領域３１０８に格納されたままになるが、ユーザはＪＡＭ３１０３の機能を使って任意のタイミングで格納領域に格納されている任意のアプレットを、ＪＶＭ３１０４上にロードして起動することも可能である。また、ユーザは、ＪＡＭ３１０３の機能を使ってＪＶＭ３１０４上で動作しているアプレットを停止したり、あるいは、Ｊａｖａアプリケーション格納領域３１０８に格納されているアプレットを削除したりすることで、本発明の発注機能を一時的に中断したり使用を中止したりすることも可能である。
【００３９】
図５は、発注アプレットの初期化の一例を示している。発注アプレットが起動されると、ステップＳ５００１からステップＳ５００３において、それぞれダイアログがＬＣＤ１５に表示され、ユーザに配送先住所情報、氏名、電話番号の入力を促し、入力が完了したらあらかじめ割り当てられた個々のアプレット専用の記憶領域にそれぞれの個人情報を保存して、初期化を終了する。セキュリティのため、Ｊａｖａアプレットは端末内部の固有情報にアクセスできないように、ＪＶＭ３１０４によって制限されている。このため、発注アプレットは、電話番号など端末内部に既に格納されている可能性のあるデータも、ユーザに改めて入力させる構成になっている。
【００４０】
図６は、インクの残量検知を行なうための機構を表す図である。本実施形態の装置では、１ページの記録が終了したとき、記録ヘッド５を発光素子である赤外線ＬＥＤ８１と受光部のフォトトランジスタ８２の光軸付近に移動させ、同光軸を横切るようにインクを吐出させてインクの残量検知を行なう。インクを吐出させたとき、フォトトランジスタ８２に到達する光量が定められた値より高いならば、インクが無くなりかけていることがわかる。また、光が遮断されていなければ、インクは全く無くなったことになる。
【００４１】
図７は、上記インク残量検知機構を用いたインク残量検知の処理を記述したフローチャートである。本実施形態の端末では、モノクロのファクシミリ画像のみでなく、カラーの画像も記録可能で、そのために黒色（Ｋ）インクのほかに、シアン（Ｃ）、マゼンダ（Ｍ）、イエロー（Ｙ）のインクも収容することができる。上記の通り、本実施形態の端末では、１ページの記録が終了するごとに図７のインク残量検知の処理を行なう。この処理は、発注アプレットが動作しているか否かに関わらず実行される。
【００４２】
まず、ステップＳ７００１で記録したページがカラー画像であったか否かを判断する。もしカラー画像であったならば、図６の機構により、シアン（Ｃ）、マゼンダ（Ｍ）、イエロ（Ｙ）のインクの吐出と残量値の更新をステップＳ７００２からＳ７００４で行い、さらに、黒色（Ｋ）インクの吐出と残量値の更新をステップＳ７００５で行って、処理を終了する。もし、カラー画像でなかったならば、ステップＳ７００５のみを行い、処理を終了する。カラー画像でないときにステップＳ７００２からＳ７００４をスキップすることで、カラー用インクの消費を低減することができる。
【００４３】
本発明では、図４のような手動操作によりインク（あるいは他の消耗品）をインターネット経由で発注する他、図６、図７のようなしくみを用いてインク（あるいは他の消耗品）の欠乏（ないし残量僅少）を検出し、これに応じて自動的にインク（あるいは他の消耗品）をインターネット経由で発注できるようにする。
【００４４】
図８は、図７のインク残量検知処理の結果に基づいて、発注データを生成する処理の詳細を示している。図８の処理は、発注アプレットが動作しているときのみ実行される。
【００４５】
発注データ生成の処理では、まずステップＳ８００１からＳ８００８において、上記図７の処理で更新された各インクの残量値を元に、インクが無くなりかけているか、あるいは、完全に空になっているか否かを判定し、もしインクがなくなりかけているか、完全に空になっているならば、その色のインクの発注データを図３の記録系タスク３１０５で生成する。
【００４６】
ステップＳ８００９では、上記ステップＳ８００１からＳ８００８において、発注データがひとつでも生成されたか否かを判定する。ここでもし発注データがひとつでも存在するならばステップＳ８０１０に進む。そうでなければ、インク発注データ生成の処理を終了する。
【００４７】
ステップＳ８０１０では、既に発注アプレットによってインクの注文がなされて、インクが手元に到着するのを待っている状態か否かを判定する。これは、多重発注を回避するための機能である。もしインクが手元に到着するのを待っている状態であるならば、インク発注データ生成の処理を終了する。一方、インクが手元に到着するのを待っている状態でない、すなわち、まだ発注を行っていない状態であるならば、ステップＳ８０１１に進む。
【００４８】
ステップＳ８０１１では、上記ステップＳ８００１からＳ８００８において得られた最大４種類の発注データを、上記図３のＪＶＭ３１０４とともに用意されたライブラリのインタフェース仕様で定義される形式に標準化し、ステップＳ８０１２で標準化された発注データをＪａｖａアプレットに通知して、ステップＳ８０１３に進む。
【００４９】
ステップＳ８０１３では、インク発注処理が実行され、ユーザはインクが手元に到着するのを待っている状態であることを示すフラグを設定し、インク発注データ生成の処理を終了する。ユーザは、図１のテンキー１１（あるいは他の適当なキー）を操作して、このフラグを解除する、すなわち、インクが手元に到着して新品のインクへの交換が完了した状態にすることができる。
【００５０】
図９は、アプレット内の処理で、図８のステップＳ８０１２で標準化された発注データが通知されたとき実行されるインク発注の処理を示している。
【００５１】
発注アプレットは発注データの通知を受けると、まずステップＳ９００１において発注アプレットの初期化時などに保存しておいた住所、氏名、電話番号の個人情報を読み出す。
【００５２】
次にステップＳ９００２において、読み出した個人情報と、通知された発注データを合成して、発注時に必要な書面の体裁に整えた注文伝票データを生成する。
【００５３】
ステップＳ９００３では、ステップＳ９００２で生成された注文伝票データを、発注アプレットの中にあらかじめ埋め込まれている注文伝票データ転送先ＵＲＬのサイトに対して転送する。
【００５４】
ステップＳ９００４では、伝票データが正常に転送されたか否かを監視する。もし正常に転送が終了したら、ステップＳ９００５に進む。サイトが何らかの理由でデータを受信できず、転送が正常に行えなかった場合などは、一定時間をおいた後、ステップＳ９００３に戻って再度伝票データの転送を試みる。ステップＳ９００５では、発注内容をユーザが再度確認できるように、発注の際に用いた伝票データを、不揮発性のメモリに保管し、インク発注処理を終了する。
【００５５】
図１０に注文伝票データ転送先ＵＲＬのサイトに送信される注文伝票データの一例を示す。図１０の場合であれば、東京都千代田区の山田太郎さんが、ＡＢＣ社のブラックインクとシアンインクを１つずつ注文したことがわかる。
【００５６】
以上に説明したように、本実施形態によれば、端末が消耗品欠乏（トナー切れやインク切れ）ないし残量僅少を検出したとき、端末がハードウェア非依存型のプログラムオブジェクトを用いて、ユーザによって選択された消耗品取り扱い業者に対して自動的にトナーやインクの発注を行なうことができる。
【００５７】
また、本実施形態によれば、ハードウェア非依存型のプログラムオブジェクトを用いて、消耗品の発注を制御するようにしているので、通信端末のメーカーや機種によらず、共通のプログラムオブジェクトをひとつ用意するだけで、本発明に基づく端末と通信可能なサイトを構築することができるようになる。すなわち、メーカーに依存しない不特定多数の小売店も本願に基づく受注システムに参入するチャンスが得られる。さらに、プログラムオブジェクトに注文データを転送するための宛先を埋め込む構造を用いているので、不特定多数の小売店がシステムに参入しやすくなる利点がある。
【００５８】
さらに、本実施形態においては、消耗品の発注において、ユーザが互換性のある消耗品（以下では代替記録材）を選択できるようにする構成を例示する。以下では、商品の識別情報としてＪＡＮコードのような共通商品コードを用いる構成も併せて例示する。
【００５９】
図１１は、図７のインク残量検知処理の結果に基づいて、インクコードデータを生成する異なる処理を示している。図１１の処理は、発注アプレットが動作しているときのみ実行される。なお、本実施形態における端末は、コードデータに共通商品コード体系のひとつであるＪＡＮ（Ｊａｐａｎｅｓｅ Ａｒｔｉｃｌｅ
Ｎｕｍｂｅｒ）コードを用いる。
【００６０】
インクコードデータ生成の処理では、まずステップＳ１８００１からＳ１８００８において、上記図７の処理で更新された各インクの残量値を元に、インクが無くなりかけているか、あるいは、完全に空になっているか否かを判定し、もしインクがなくなりかけているか、完全に空になっているならば、その色のインクのインクコードデータを図３の記録系タスク３１０５で生成する。
【００６１】
ステップＳ１８００９では、上記ステップＳ１８００１からＳ１８００８において、足りなくなっているインクに対応するインクコードデータがひとつでも生成されたか否かを判定し、もしインクデータがひとつでも存在するならばステップＳ１８０１０に進む。そうでなければ、インクコードデータ生成の処理を終了する。
【００６２】
ステップＳ１８０１０では、既に発注アプレットによってインクの注文がなされて、インクが手元に到着するのを待っている状態か否かを判定する。これは、多重発注を回避するための機能である。もしインクが手元に到着するのを待っている状態であるならば、インクコードデータ生成の処理を終了する。一方、インクが手元に到着するのを待っている状態でない、すなわち、まだ発注を行っていない状態であるならば、ステップＳ１８０１１に進む。
【００６３】
ステップＳ１８０１１では、本装置固有に設定されている装置コードデータと、上記ステップＳ１８００１からＳ１８００８において得られた最大４種類のインクコードデータを、上記図３のＪＶＭ３１０４とともに用意されたライブラリのインタフェース仕様で定義される形式に合成および標準化し、ステップＳ１８０１２で標準化されたコードデータをＪａｖａアプレットに通知してステップＳ１８０１３に進む。
【００６４】
ここで、図１３に、図１１の処理により得られた標準化されたコードデータの一例を示す。図１３の場合、ＪＡＮコードが「４９６０９９９ ２３９００２」なる装置において、そのＪＡＮコードが「４９６０９９９ ２３９０３３」および「４９６０９９９ ２３９０４０」に対応する品種のインクが不足していることを示している。
【００６５】
ステップＳ１８０１３では、コードデータ生成処理が実行され、ユーザはインクが手元に到着するのを待っている状態であることを示すフラグを設定し、インクコードデータ生成の処理を終了する。ユーザは、図１のテンキー１１などを操作して、このフラグを解除する、すなわち、インクが手元に到着して新品のインクへの交換が完了した状態にすることができる。
【００６６】
図１２は、アプレット内の処理で、図１１のステップＳ１８０１２で標準化されたコードデータが通知されたとき実行されるインク発注の処理を示している。
【００６７】
発注アプレットはコードデータの通知を受けると、まずステップＳ１９００１において、該アプレットにあらかじめ登録されている複数の記録材コードデータの中に、通知されたインクコードが含まれているか否かを判定する。
【００６８】
図１１以降の処理では、図４のようにしてダウンロードしたアプレットにあらかじめ消耗品情報、たとえば図１６のような消耗品名称とそのＪＡＮコードの対応テーブル、および互換性のある代替品の情報、たとえば図１５のような互換性のある消耗品の対応テーブルが登録されているものとする。
【００６９】
ステップＳ１９００１において、アプレットにあらかじめ登録されている複数の記録材コードデータ（図１６）の中に、通知されたインクコード（図１３）が含まれているならばステップＳ１９００２に、そうでなければＳ１９００５に進む。
【００７０】
ステップＳ１９００２では、さらにステップＳ１９００１でコードが一致した記録材に、通知されたコード以外の代替記録材が存在するか否かを発注アプレットに登録されたテーブル（図１５）を元に判定する。もし、存在するならばステップＳ１９００３に、そうでなければＳ１９００５に進む。
【００７１】
ステップＳ１９００３では、上記発注アプレットに登録されたテーブルを元に、代替記録材の一覧を示し、ユーザが発注する記録材を互換性のある代替記録材を選択できるようにするためのダイアログを図１の表示部１５に表示する。
【００７２】
ここで、図１４に同ダイアログ表示の一例を、また、図１５および図１６に上記アプレットにあらかじめ登録されている記録材コードデータのテーブルの一例を示す。
【００７３】
図１４は、図１３のコードデータを受け取ったアプレットが、図１２のステップＳ１９００１からＳ１９００３において図１５および図１６のテーブルを参照して、生成したダイアログの表示例を示している。
【００７４】
図１４のダイアログは、ラジオボタンとともにマゼンダインクに対応する代替記録材を表示し、その下に選択状態を確定するための選択ボタン（「Ｏｋ」および「Ｓｋｉｐ」）を配置したもので、これらのラジオボタンおよび選択ボタンにより、デフォルトないし互換品のいずれを選択するかをユーザに促している。
【００７５】
ステップＳ１９００４では、ステップＳ１９００３においてユーザが選択した記録材が発注の対象となるように、図１１の処理により通知されたインクコードをユーザが選択した記録材を示すコードに差し替える。
【００７６】
ステップＳ１９００５では、少なくとも１つ以上通知されたコードが示すインクに対する代替記録材の選択処理（ステップＳ１９００１からＳ１９００４まで）がすべて終了しているか否かを判定し、終了していればステップＳ１９００６に進み、そうでなければステップＳ１９００１に戻る。
【００７７】
ステップＳ１９００６では、発注アプレットの初期化時に保存しておいた住所、氏名、電話番号の個人情報を読み出す。
【００７８】
続いてステップＳ１９００７において、読み出した個人情報と、通知された装置コードおよび上記ステップＳ１９００１〜Ｓ１９００４で得られた記録材コードのデータを合成して、発注時に必要な書面の体裁に整えた注文伝票データを生成する。
【００７９】
ステップＳ１９００８では、ステップＳ１９００７で生成された注文伝票データを、発注アプレットの中にあらかじめ埋め込まれている注文伝票データ転送先ＵＲＬのサイトに対して転送する。
【００８０】
ステップＳ１９００９では、伝票データが正常に転送されたか否かを監視する。もし正常に転送が終了したら、ステップＳ１９０１０に進む。当該のサイトが何らかの理由でデータを受信できず、転送が正常に行えなかった場合などは、一定時間をおいた後、ステップＳ１９００８に戻って再度伝票データの転送を試みる。ステップＳ１９０１０では、発注内容をユーザが再度確認できるように、発注の際に用いた伝票データを、不揮発性のメモリに保管し、インク発注処理を終了する。
【００８１】
図１７に、消耗品の自動発注において生成される注文伝票データの一例を示す。図１７の場合、東京都千代田区の山田太郎さんが、ＪＡＮコードが「４９６０９９９ ２３９０３３」および「４９６０９９９ ２３９０４０」なるインクを注文したことがわかる。この注文伝票を受注した販売業者は、指定されたインクを指定された送り先に代金引換の宅配便などを用いて発送し、決済を行なう。このような決済の手法は任意であり、たとえばクレジットカードなどを利用するものであってもよい。
【００８２】
以上に説明したように、本発明によれば、端末がトナー切れやインク切れを検出したとき、端末がハードウェア非依存型のプログラムオブジェクトを用いて、ユーザによって選択された消耗品取り扱い業者に対して自動的にトナーやインクの発注を行なうことができる。
【００８３】
さらに、端末とハードウェア非依存型のプログラムオブジェクトとの間のデータ形式を一般的なコード体系とすることで、同プログラムオブジェクト側において独自サービスや独自アプリケーションを容易に提供できるようになる。すなわち、不特定多数の小売店がシステムに参入する際に、小売店独自のサービスをユーザに展開することが、従来に比べ容易になる。
【００８４】
＜変形例＞
以上に説明した実施形態では、本発明が適用される電子機器の一例としてカラー画像を記録可能なインクジェット方式の記録部を具備するファクシミリ装置を例示した。しかしながら、本発明はカラーに限定されるものではない。モノクロ記録しかできないファクシミリ装置であっても、第１の実施形態におけるインク残量検知の処理をモノクロインクのみの構成にすれば、本発明の目的を達成することができる。
【００８５】
また、以上に説明した実施形態では、インクジェット方式の記録部を用いたファクシミリ装置を例に示したが、本発明はこれに限定されるものではない。たとえば、その記録部に電子写真方式のレーザービームプリンタを用いても、その記録材であるトナーの残量を検知する機構を備えていれば、本発明の初期の目的を達成することができる。
【００８６】
さらに、上記説明した実施形態では、ファクシミリ装置について説明した。しかしながら、本発明はファクシミリ装置に限定されるものではない。たとえば、一般的なプリンタ、あるいは他のオフィス機器、家電製品であっても、本願請求の範囲にある手段さえ具備すれば、本発明が目的とするところの記録材の自動発注を実現することが可能である。もちろん、本発明で発注可能な電子機器の消耗品は上記のようなプリンタの記録材料（トナー、インク）などに限定されるものではない。すなわち、本発明の電子機器の制御方法は、運用を通じて消耗品の欠乏を生じるあらゆる電子機器、およびその電子機器を制御する制御プログラムに適用できる。
【００８７】
さらに、上記説明した実施形態では、インクが無くなりかけているか、あるいは、完全に空になっているか否かを判定することができるように構成されていた。しかし、インクが無くなりかけていること、いわゆるニアエンド状態は検出できなくても、完全に空になっていることは少なくとも検出できる機構を具備していれば、記録材の不足による記録不能状態がニアエンドを検出できる装置に比べれば長く続く可能性があるが、本発明の目的は充分達成することができる。
【００８８】
さらに、上記説明した実施形態では、ハードウェア非依存型のプログラムオブジェクトとして、Ｊａｖａアプレットを用いた。しかしながら、ハードウェア非依存を実現できる、いわゆるプログラムオブジェクト指向型の言語を採用すれば、本発明の目的を達成することが可能である。
【００８９】
図５、図７〜図９、図１１および図１２に示したアプレットの処理は、必ずしも図４のダウンロード処理により一回でダウンロードされる単一のＪａｖａアプレットに含まれている必要はなく、その任意の部分が別途ダウンロードされる、あるいは必要であればあらかじめＲＴＯＳ３１０１の一部に組み込みになっているような構成であってよい。
【００９０】
また、上記説明した実施形態では、Ｊａｖａアプレットの中にＪＡＮコードとそのコードが指す商品の名称のテーブル、および、ＪＡＮコードによる代替商品のテーブルを用意して、端末から通知された記録材のＪＡＮコードと上記テーブルを比較して、代替可能な商品のリストを表示し、ユーザが所望の記録材を選択できるように構成した。ここで、上記端末が通知する記録材のＪＡＮコードは、端末を制御している組み込み型プログラムが作成されたときにその内部に埋め込まれたものである。また、上述の発注アプレットをダウンロードするサイト、消耗品の注文情報を送信するサイトは必ずしも同一である必要はない。
【００９１】
また、端末が生産／販売されてから数年が経過したとき、販売当初に埋め込まれたＪＡＮコードの記録材は諸般の事情から生産が中止され、新たな対策品が市場に用意されている場合もあり得る。このような場合であっても、端末とハードウェア非依存型のプログラムオブジェクトとの間のデータ形式に一般的なコード体系であるＪＡＮコードを採用しているため、同オブジェクトのテーブルの構成やダイアログ表示の内容を適当に設定すれば、端末販売当初に設定されていた記録材は生産中止になって新たな対策品が用意されている旨を伝えることが可能である。
【００９２】
たとえば、図１６のテーブルに生産中止を示す列を追加し、もし端末から通知された記録材が生産中止の属性を持っているならば、図１８のようなダイアログ表示を行ない、該当の商品が生産中止となっていることをユーザに報知するとともに、上記同様にして互換性のある商品をユーザに選択させるようにしてもよい。
【００９３】
さらに、以上説明した実施形態では、端末とＪａｖａアプレットとの間で用いられる商品コード体系としてＪＡＮコードを利用した。ＪＡＮコードはバーコードパターンなどとの関連づけが存在し、このようなコード体系を利用すれば発注を受けた業者のその後の処理を実行する物流システムを構成するのが極めて容易になる。しかしながら、この種の共通商品コード体系はＪＡＮコードに限定されるものではない。たとえば、ＭＩＬ規格（米国国防省）として採用されたＣＯＤＥ３９や、標準物流コードとしてＪＩＳ Ｘ ０５０２に制定されているＩＴＦ（Ｉｎｔｅｒｌｅａｖｅｄ ２ ｏｆ ５）、あるいはＥＡＮ（Ｅｕｒｏｐｅａｎ Ａｒｔｉｃｌｅ Ｎｕｍｂｅｒ）コードなどを用いても本発明の目的は充分達成することができる。さらに言えば、メーカーや端末に依存しない標準化されたコードであれば、上記以外のコードシステムであっても本発明に適用できるのはいうまでもない。
【００９４】
＜実施態様＞
本発明の実施態様には次のような構成が含まれる。
【００９５】
＜実施態様１＞ 運用を通じて消耗品の欠乏を生じる電子機器の制御方法において、
インターネットサイトからハードウェア非依存型のプログラムオブジェクトを受信し、
前記プログラムオブジェクトに含まれる情報にしたがって電子機器の運用に必要な消耗品を注文するための予め定められた形式に標準化された消耗品注文情報を生成し、
前記プログラムオブジェクトの制御により、生成された前記消耗品注文情報を前記プログラムオブジェクトに含まれる情報にしたがってあらかじめ定められたサイトに送信することを特徴とする電子機器の制御方法。
【００９６】
＜実施態様２＞ 前記消耗品の残量を検出し、前記消耗品の残量が予め定められた量より少なくなった時、前記消耗品注文情報の生成および送信を行なうことを特徴とする実施態様１に記載の電子機器の制御方法。
【００９７】
＜実施態様３＞ 前記消耗品注文情報が共通商品コードを用いて記述されることを特徴とする実施態様１に記載の電子機器の制御方法。
【００９８】
＜実施態様４＞ 前記プログラムオブジェクトに複数の消耗品の互換関係を示す互換情報が含まれ、前記消耗品注文情報の送信に先立ち、この互換情報を参照し、電子機器の運用に必要な前記消耗品と互換性を有する消耗品が存在する場合、ユーザにこれら互換性を有する消耗品群を呈示し、前記消耗品注文情報により注文すべき消耗品を決定することを特徴とする実施態様１に記載の電子機器の制御方法。
【００９９】
＜実施態様５＞ 実施態様１〜４のいずれか１項に記載の電子機器の制御方法を実施する電子機器。
【０１００】
＜実施態様６＞ 実施態様１〜４のいずれか１項に記載の電子機器の制御方法を実施するプログラム実行環境を構成する電子機器の制御プログラム。
【０１０１】
【発明の効果】
以上の説明から明らかなように、本発明によれば、運用を通じて消耗品の欠乏を生じる電子機器の制御方法において、インターネットサイトからハードウェア非依存型のプログラムオブジェクトを受信し、前記プログラムオブジェクトに含まれる情報にしたがって電子機器の運用に必要な消耗品を注文するための予め定められた形式に標準化された消耗品注文情報を生成し、前記プログラムオブジェクトの制御により、生成された前記消耗品注文情報を前記プログラムオブジェクトに含まれる情報にしたがってあらかじめ定められたサイトに送信する構成を採用しているので、簡単安価かつ確実に自動的に消耗品の発注を行なえる、という優れた効果がある。
【図面の簡単な説明】
【図１】本発明を採用した電子機器の構成を示した斜視図である。
【図２】図１の機器のハードウエアブロック図である。
【図３】インターネット上のサイトとプロバイダと機器の関係、および、機器側のソフトウェアモジュールの構成を示したブロック図である。
【図４】アプレットのダウンロードと起動の流れに関する一例を示したフローチャート図である。
【図５】発注アプレットの初期化の一例を示すフローチャート図である。
【図６】インクの残量検知を行なうための機構を示した説明図である。
【図７】インク残量検知機構を用いたインク残量検知の処理を示したフローチャート図である。
【図８】図７のインク残量検知処理の結果に基づいて、発注データを生成する処理の詳細を示したフローチャート図である。
【図９】アプレット内の処理において、標準化された発注データが通知されたとき実行されるインク発注の処理を示すフローチャート図である。
【図１０】本発明の電子機器で生成される注文伝票データの一例を示した説明図である。
【図１１】図７のインク残量検知処理の結果に基づいて、インクコードデータを生成する処理の詳細を記述したフローチャート図である。
【図１２】アプレット内の処理で標準化されたコードデータが通知されたとき実行されるインク発注の処理を示すフローチャート図である。
【図１３】標準化されたコードデータの一例を示した説明図である。
【図１４】代替記録材の一覧を表示して選択を促すダイアログ表示の一例を示した説明図である。
【図１５】記録材コードデータのテーブルの一例を示した説明図である。
【図１６】記録材コードデータのテーブルの一例を示した説明図である。
【図１７】注文伝票データの一例を示した説明図である。
【図１８】代替記録材の一覧を表示して選択を促すダイアログ表示の異なる例を示した説明図である。
【符号の説明】
５ 記録ヘッド
１１ テンキー
１２ ＮＥＴキー
１３ スタートキー
１４ ストップキー
１５ 表示部
１６ インジケータ
１７ ハンドセット
１８ 原稿挿入口
１９ 記録紙排紙口
２１ ＮＣＵ
２２ ハンドセット
２３ ＭＯＤＥＭ
２４ 表示部
２５ キーパネル
２６ ＲＡＭ
２７ ＲＯＭ
２８ ＣＰＵ
２１０ プリンタ部
３０００ サイト
３１００ 端末
３１０１ ＲＴＯＳ
３１０３ Ｊａｖａアプリケーションマネージャー
３１０４ Ｊａｖａ仮想マシン
３１０５ 記録系タスク
３１０８ Ｊａｖａアプリケーション格納領域
３２００ プロバイダ
３３００ インターネット
３４００ 回線
８１ 赤外線ＬＥＤ
８２ フォトトランジスタ

Claims (1)

1. 運用を通じて消耗品の欠乏を生じる電子機器の制御方法において、
   インターネットサイトからハードウェア非依存型のプログラムオブジェクトを受信し、
   前記プログラムオブジェクトに含まれる情報にしたがって電子機器の運用に必要な消耗品を注文するための予め定められた形式に標準化された消耗品注文情報を生成し、
   前記プログラムオブジェクトの制御により、生成された前記消耗品注文情報を前記プログラムオブジェクトに含まれる情報にしたがってあらかじめ定められたサイトに送信することを特徴とする電子機器の制御方法。

Images