JP6464607B2 - 管理装置及び管理システム - Google Patents

Description

この発明は、通信手段を介して通信可能な複数のデバイスを管理するための管理装置及び管理システムに関する。

従来から、画像形成装置などのデバイスに対し、状態情報、故障通報、消耗品自動発注などのサービスを遠隔で実施するため、デバイスと管理装置とが相互に通信する管理システムがある。また、このような管理システムにおいて、管理装置が管理対象のデバイスと通信するための通信方式として、ＰＨＳ（Personal Handy-phone System）や３Ｇ（3rd generation）のような無線通信を用いることがある。そしてこの場合、管理装置を運用してデバイスを管理する会社が、無線通信サービス提供会社と契約して無線通信サービスを利用することが考えられる。

この場合の契約形態としては、デバイス１台当たり一月に何ＭＢ（メガバイト）といった通信量で価格が決まる、パケットシェアリングの契約が一般的である。この契約によれば、管理装置は、契約対象のデバイスとの間で、合計で一月に（契約台数×１台当たりの通信量）の分だけ通信を利用することができる。

以上のような管理システムに関する技術としては、例えば特許文献１に記載のものが知られている。特許文献１には、管理サーバを複数の機器と通信回線を介して接続し、機器毎に関連付けられたサポート契約情報に基づいて各機器がファームウェアのアップデートを許可されているか否か判定し、許可されている場合のみファームウェアをその機器に送信することが記載されている。

ところで、上述のパケットシェアリング契約の場合、料金を抑えるため、デバイス１台当たりの通信量を低く抑えることが望ましい。しかしながら、通信量をあまり低くしてしまうと、ファームウェアのように容量の大きいデータをデバイスに送信できなくなってしまうという問題がある。

しかしながら、一方で、担当者がデバイスを１台１台回ってファームウェアをインストールするのは極めて非効率的であり、なるべく管理装置から管理対象のデバイスにファームウェアを送信したいという要求もあった。
また、ファームウェアの送信以外でも、管理対象デバイスとの間で通常の管理動作以上の通信が必要になるサービスについては、同様な問題がある。
この点につき、特許文献１に記載の技術は、通信量について考慮しておらず、解決をもたらすものではない。

この発明は、このような事情に鑑みてなされたものであり、通信量の制約がある場合でも、なるべく効率よく管理対象デバイスに通信が必要なサービスを提供できるようにすることを目的とする。

以上の目的を達成するため、この発明は、通信手段を介して通信可能な複数のデバイスを管理する管理装置において、管理対象のデバイス毎に、そのデバイスとの通信に使用する通信方式及び、そのデバイスとの間の通信データ量を管理する第１の管理手段と、通信方式毎に通信許容量を設定する設定手段と、上記デバイスに対する通信を伴うサービスの提供可否を、そのサービスの提供に要する通信データ量と、そのデバイスが使用する通信方式についての通信許容量と、その通信方式を使用する各デバイスの通信データ量の合計とに基づき判断する判断手段とを備えたものである。

上記構成によれば、通信量の制約がある場合でも、なるべく効率よく管理対象デバイスに通信が必要なサービスを提供できるようにすることができる。

この発明の一実施形態である管理装置と、その管理装置が管理するデバイスとの関係について説明するための図である。 図１に示した管理装置のハードウェア構成を示す図である。 図１に示した管理装置及びデバイスの機能構成を示す図である。 通信方式テーブルの例を示す図である。 デバイス管理テーブルの例を示す図である。 管理装置への通信方式の登録時及び管理対象のデバイスの登録時の、管理装置及びデバイスの動作の例を示す図である。 デバイスから管理装置へ通知を送信した場合の管理装置の動作の例を示す図である。 通信方式Ａの締め日が経過した場合の管理装置の動作の例を示す図である。 管理装置のオペレータがデバイスに対するサービスの実行を指示した場合の管理装置の動作の例を示す図である。 通信方式Ａの締め日における管理装置の動作の例を示す図である。 通信データ量の集計を行う場合の管理装置の動作の例を示す図である。 デバイスからの通知を受信した場合の管理装置の動作の、図７とは異なる例を示す図である。 この発明の実施形態の変形例である管理システムと、その管理システムが管理するデバイスとの関係について説明するための図である。

以下、この発明を実施するための形態について、具体的に説明する。
まず図１を用いて、この発明の一実施形態である管理装置と、その管理装置が管理するデバイスとの関係について説明する。
管理装置１０は、この発明の管理装置の一実施形態である。そして、管理対象の複数のデバイス２０と、通信網３０を介して通信可能である。管理対象は、随時追加及び削除が可能である。

そして、管理装置１０は、デバイス２０から通知を受けてデバイス２０の動作状態の把握や診断を行ったり、それに応じて消耗品の発送や修理担当者の派遣を手配したりといった管理動作を行う。逆に、管理装置１０からデバイス２０に要求を送信して、デバイス２０に何らかの動作を行わせることもできる。例えば、自己診断を実行させてその結果を送信させたり、ファームウェアを送信してインストールさせたりすることが考えられる。

デバイス２０は、通信網３０を介して管理装置１０と通信を行う機能と、管理装置１０との間で通知や要求を送受信して管理装置１０に管理を受ける機能とを備えていれば、任意の電子装置でよい。例えば、プリンタ、複写機、ファクリミリ装置等の画像形成装置、プロジェクタ等の投影装置等が考えられる。
図ではデバイス２０を３台示しているが、台数がこれに限られないことはもちろんである。

通信網３０は、有線無線を問わず、任意の規格のものを利用可能である。インターネットのようなオープンなネットワークでも、専用線によるクローズなネットワークでもよい。ただし、この実施形態の特徴による効果は、回線の利用契約等により通信可能なデータ量に制約がある通信網を利用する場合に、よく発揮される。
なお、管理装置１０と各デバイス２０との間の通信には、デバイスによって異なる通信方式を用いて構わない。

次に、図２に、管理装置１０のハードウェア構成を示す。
管理装置１０は、ハードウェアとしては一般的なコンピュータでよい。すなわち、管理装置１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ＨＤＤ（ハードディスクドライブ）１４、通信Ｉ／Ｆ（インタフェース）１５、表示部１６、及び操作部１７を備え、それらをシステムバス１８により接続した構成としている。

そして、ＣＰＵ１１が、ＲＡＭ１３をワークエリアとしてＲＯＭ１２又はＨＤＤ１４に記憶されたプログラムを実行することにより、管理装置１０全体を制御し、デバイス２０の管理、デバイス２０へのサービス提供可否判断等の各種機能を実現する。
ＨＤＤ１４は、不揮発性記憶媒体（記憶手段）であり、ＣＰＵ１１が実行する各種プログラムや後述するテーブルを含む各種データを格納（記憶）している。
通信Ｉ／Ｆ１５は、デバイス２０をはじめとする外部装置と通信するためのインタフェースである。使用する通信規格は、通信網３０を介した通信に適したものであれば、有線、無線を問わず、任意でよい。複数種類の規格に対応したインタフェースを備えてもよい。

表示部１６は、ディスプレイ等の、オペレータに情報を提示するための表示手段である。
操作部１７は、キーボード、マウス、タッチパネル等の、オペレータから操作を受け付けるための操作手段である。
なお、表示部１６や操作部１７が外付けであったり、管理装置１０がネットワークを介して外部の端末装置から操作を受け付けることができるようにしたりしてもよい。

また、デバイス２０も、同様に、ＣＰＵ、ＲＯＭ、ＲＡＭ、記憶手段、通信Ｉ／Ｆ等を備えたコンピュータによる制御部を備える。また、それ以外に、デバイスの機能によって異なるエンジン部を備える。デバイス２０がプリンタであればプリントエンジン、スキャナであればスキャナエンジン、プロジェクタであれば投光光学系等である。これらは、ハードウェアとしては公知のものでよいので説明を省略する。

次に、図３に、管理装置１０及びデバイス２０の機能構成を示す。図３には、この実施形態の特徴に関連する部分の構成を中心に示した。また、図３に示す各部の機能は、管理装置１０のＣＰＵ１１あるいはデバイス２０のＣＰＵが所要のプログラムを実行することにより実現するものである。

図３に示すように、管理装置１０は、通信方式管理部１０１、デバイスリスト管理部１０２、通信許容量算出部１０３、通信データ量算出部１０４、通知処理部１０５、サービス提供部１０６、サービス提供判断部１０７を備える。
これらのうち、通信方式管理部１０１は、管理装置１０とデバイス２０との間の通信に使用する通信方式に関する情報を管理する機能を備える。この情報は、後述の通信方式テーブル（図４）に登録しておく。

デバイスリスト管理部１０２は、管理装置１０の管理対象となるデバイス２０のリストを管理する機能を備える。このリストは、後述するデバイス管理テーブル（図５）に登録し、デバイスリスト管理部１０２は、管理対象のデバイス毎に、該デバイスとの通信に使用する通信方式及び、該デバイスとの間の通信データ量を管理する。

通信許容量算出部１０３は、通信方式テーブルに登録されている各通信方式について通信許容量を算出する機能を備える。通信許容量は、ユーザが入力した、該当の通信方式に関する通信契約の内容に従って算出する。その具体例については後述する。
通信データ量算出部１０４は、管理装置１０とデバイス２０とが通信を行った場合に、送受信したデータの量を算出してデバイス毎の累計を管理する機能を備える。その累計値は、デバイス管理テーブル（図５）に登録する。また、通信データ量算出部１０４は、通信方式毎に、その通信方式を使用するデバイスの通信量の合計を算出する機能も備える。その合計値は、通信方式テーブル（図４）に登録する。

通知処理部１０５は、デバイス２０からの通知を受信し、その通知に応じて必要な、デバイス２０の管理のための処理を行う機能を備える。例えば、動作状態の通知に応じてデバイス毎の動作履歴を作成したり、消耗品残量わずかの通知に応じて消耗品の配送を手配したり等である。通知処理部１０５が、管理装置１０からデバイス２０への要求を送信できるようにしてもよい。

サービス提供部１０６は、デバイス２０に対して、通信を伴うサービスであって、通常の管理のプロセスにおいてはあまり発生しないサービスを提供する機能を備える。このサービスは、例えば、ファームウェアの更新や、故障が疑われる場合の通常より詳細な診断等である。定期通知や消耗品発注など、ルーチンで発生するサービスについては、通知処理部１０５が提供する。どのサービスを、通知処理部１０５が提供し、どのサービスをサービス提供部１０６が提供するかは、管理装置１０の管理者が適宜定めればよい。サービス提供判断部１０７にサービス提供の可否を判断させるような、通常は必要なくかつ大容量のデータの転送が必要になるサービスを、サービス提供部１０６が提供するようにするとよい。
サービス提供判断部１０７は、デバイス２０に対してサービス提供部１０６が提供するサービスの提供可否を判断する機能を備える。具体的な判断手法については後述する。

次に、デバイス２０は、通知送信部２０１、機器情報保持部２０２及び要求受信部２０３を備える。
このうち通知送信部２０１は、管理装置１０の通知処理部１０５に対して、管理装置１０による管理を受けるために必要な通知を送信する機能を備える。この通知には、デバイス２０の動作履歴の通知、消耗品ニアエンドの通知、エラー発生の通知等がある。管理装置１０に対する何らかの要求を含んでいてもよい。また、通知にはデバイス２０の識別情報を含める。
また、通知送信部２０１は、デバイス２０を管理装置１０の管理対象として登録する場合に、管理装置１０に対して登録要求を送信する。この点については後述する。

機器情報保持部２０２は、デバイス２０の動作履歴、設定、識別情報等、デバイス２０の動作のために必要な情報や、管理装置１０による管理を受けるために必要な情報を記憶する機能を備える。また、機器情報保持部２０２は、デバイス２０のファームウェアも記憶する。
要求受信部２０３は、管理装置１０から送信される要求を受信し、要求に応じた動作を実行する機能を備える。この動作としては例えば、ファームウェアの更新や、自己診断の実施等が考えられるが、これに限られることはない。

次に、管理装置１０が記憶する、サービス提供判断部１０７におけるサービス提供可否の判断に用いるデータについて説明する。
まず図４に、通信方式テーブルの例を示す。
この通信方式テーブルは、管理装置１０とデバイス２０との通信に用いる通信方式に関する情報を登録するテーブルであり、通信方式ＩＤ、通信データ量、通信許容量、台数、１台当たり通信許容量、締め日の項目を含む。

これらのうち通信方式ＩＤは、通信方式を特定するための識別情報である。
通信データ量は、該当の通信方式を使用する全デバイスについて、管理装置１０とそのデバイス２０との間の通信データ量を合計した値である。すなわち、管理装置１０が該当の通信方式を用いて送受信したデータ量の合計である。この値は、集計期間（ここでは一月とするが、これに限られない）毎にリセットする。

通信許容量は、管理装置１０が該当の通信方式で一集計期間内に通信できるデータ量の上限である。この許容量を超えた場合にどうなるか（追加料金が発生する、通信に制約が生じる、など）は、通信サービス提供会社との契約条件による。また、ここでは通信契約はパケットシェアリングであるとし、通信許容量は、利用台数と１台当たり通信許容量とを乗じた値であるとする。また、デバイス１台毎ではなく、全デバイスについての通信データ量の合計、すなわち上記の通信データ量の項目の値により、許容量超過有無を管理する。しかし、他の契約条件の場合には、その契約条件に従って適宜通信許容量を算出及び運用すればよい。

台数は、該当の通信方式で管理装置１０との通信を行うことを登録したデバイス２０の台数である。
１台当たり通信許容量は、管理装置１０が、登録したデバイス２０の１台当たり一集計期間内に通信できるデータ量の上限である。
締め日は、通信データ量の集計期間の末日である。

以上のうち、１台当たり通信許容量と締め日、及び通信許容量の算出方式は、通信サービス提供会社との契約条件に従って定められる値であり、オペレータが管理装置１０に入力した契約条件の内容に従って管理装置１０が設定する。なお、１台当たり通信許容量は、通信許容量の算出のために用いるものであり、上述と異なる方式で通信許容量を算出する場合、１台当たり通信許容量の値が不要であることも考えられる。

なお、この実施形態においては、技術的な規格が異なる場合だけでなく、通信サービスの提供会社が異なる場合や、通信サービス利用契約の内容が異なる場合、パケットシェアリングを行う場合において通信量を集計するグループが異なる場合も、異なる通信方式であるとして取り扱う。もちろん、通信方式テーブルへの登録も別々に行う。これらの場合には個別に通信データ量及び通信許容量を管理する必要があるためである。
以上の通信方式テーブルにおける締め日を設定する場合に、管理装置１０のＣＰＵ１１が第２の管理手段として機能する。また、通信許容量を設定する場合に、ＣＰＵ１１が設定手段として機能する。

次に、図５に、デバイス管理テーブルの例を示す。
このデバイス管理テーブルは、管理装置１０の管理対象となっているデバイス２０を登録するためのテーブルであり、デバイスＩＤ、通信方式ＩＤ及び通信データ量の項目を含む。
これらのうちデバイスＩＤは、デバイス２０を特定するための識別情報である。

通信方式ＩＤは、該当のデバイス２０が管理装置１０との通信に使用する通信方式を特定する識別情報である。図４の通信方式テーブルに登録されている通信方式ＩＤのいずれかをここに登録する。
通信データ量は、管理装置１０と該当のデバイス２０との間で、現在の集計期間内に送受信したデータ量である。この値は、集計期間毎にリセットする。
以上のデバイス管理テーブルにおける通信データ量を登録する場合に、管理装置１０のＣＰＵ１１が第１の管理手段として機能する。

次に、管理装置１０及びデバイス２０が実行する動作及び処理について説明する。以下の説明する動作及び処理は、管理装置１０のＣＰＵ１１あるいはデバイス２０のＣＰＵが所要のプログラムを実行することにより実現するものである。しかし、説明を簡単にするため、管理装置１０あるいはデバイス２０がこれを実行するとして説明する。

まず図６に、管理装置１０への通信方式の登録時及び管理対象のデバイス２０の登録時の、管理装置１０及びデバイス２０の動作の例を示す。
管理装置１０通信方式を登録する場合、管理装置１０のオペレータが、管理装置１０に対し契約条件の情報を入力し登録を指示する（Ｓ１１）。ここで入力するのは、設定する通信方式ＩＤ（自動設定の場合は不要）、契約で定められているデバイス１台当たりの通信許容量及び締め日の情報である。

管理装置１０は、通信方式の登録指示を受けると、入力された情報に基づき通信方式テーブルに新しい通信方式のエントリを追加する（Ｓ１２）。このとき、通信方式ＩＤ、１台当たり通信許容量及び締め日の項目に、ステップＳ１１で入力された情報を登録する。その他の項目は初期値である。この登録をもって、管理装置１０は、デバイス２０からの、新たな通信方式を用いて通信を行う旨の登録要求を受け付けるようになる。
図６には、ステップＳ１２において、通信方式ＩＤが「Ａ」の通信方式を新たに登録した状態の通信方式テーブルの例を示している。

また、デバイス２０を管理装置１０の管理対象として登録する場合、デバイス２０が管理装置１０にデバイス登録依頼を送信する（Ｓ２１）。このデバイス登録依頼は、デバイス２０のデバイスＩＤ及び、通信に使用する通信方式を特定するための通信方式ＩＤを含む。

ステップＳ２１での送信は、デバイス２０が、デバイス２０のオペレータの操作に従い行うものである。また、デバイス登録依頼に記載すべき通信方式ＩＤは、管理契約の締結時等に何らかの方法で予めオペレータに通知しておくとよい。あるいは、デバイス登録依頼の送信前にデバイス２０が管理装置１０にアクセスして、どのような通信方式が利用可能かを確認できるようにすることも考えられる。

いずれにせよ、管理装置１０は、デバイス登録依頼を受信し、これを管理装置１０に予め登録されている管理契約の内容と照合する等して登録を許可できると判断すると、登録依頼により通知された情報をデバイス情報テーブルに登録する（Ｓ２２）。ここで登録する情報は、デバイスＩＤと通信方式ＩＤであり、通信量は初期値である。この登録をもって、管理装置１０は、デバイス２０を管理対象として認識する。
図６には、ステップＳ２２において、デバイスＩＤが「００３」のデバイスを新たに登録した状態のデバイス情報テーブルの例を示している。デバイスＩＤが「００１」のデバイスは、ステップＳ１２の後でステップＳ２１の前に既に登録されていたとする。

また、管理装置１０は、新たなデバイスの登録に伴い、通信方式テーブルの台数及び通信許容量の項目を更新する（Ｓ２３）。すなわち、新たに登録したデバイスが使用する通信方式について台数を１加算し、それに伴って通信許容量の値も１台分増加させる。図６には、ステップＳ２３において、通信方式ＩＤが「Ａ」の通信方式についてデータを更新した状態のデバイス情報テーブルの例を示している。

以上の登録及び更新が完了すると、管理装置１０はデバイス２０に対し、デバイス登録依頼に対する応答を送信する（Ｓ２４）。この応答により、デバイス２０は、自身が管理装置１０に管理対象として登録されたことを認識し、管理装置１０に管理を受けるための定期通知の送信等の動作を開始する。

次に図７に、デバイス２０から管理装置１０へ通知を送信した場合の管理装置１０の動作の例を示す。
デバイス２０は、管理装置１０による管理を受けるため、管理装置１０に対して定期的に自己の動作状態や動作履歴を通知したり、不具合があった場合にその旨を管理装置１０に通知したりする（Ｓ３１）。この通知には、通知すべき内容を示すデータの他、デバイス２０のデバイスＩＤを含める。また、この通知は、図６のステップＳ２１で登録を依頼した通信方式にて行う。以降の通信についても同様である。

一方、ステップＳ３１の通知を受けた管理装置１０は、通知内容に応じた処理を行い（Ｓ３２）、通知に対する応答を返す（Ｓ３３）。この処理は、動作状態の記録や、不具合に応じた状況確認の手配等である。
そしてその後、管理装置１０は、今回送受信した通知及び応答のデータ量だけ、デバイス情報テーブルにおける送信元のデバイス２０についての通信データ量を加算する（Ｓ３４）。この処理により、管理装置１０は、管理対象のデバイス毎に、そのデバイスとの間の通信データ量を管理する。図６には、通知受信前及びステップＳ３４での更新後のデバイス管理テーブルの状態の例を示した。

次に図８に、通信方式Ａの締め日が経過した場合の管理装置１０の動作の例を示す。
管理装置１０は、不図示のカレンダ及び時計により、通信方式Ａについて締め日が経過した（ここでは締め日である２５日が終了した）ことを検知すると（Ｓ４１）、デバイス情報テーブルを検索し、通信方式Ａを使用するデバイスの通信データ量をリセットする（Ｓ４２）。また、通信方式テーブルにおいて、通信方式Ａについての通信データ量をリセットする（Ｓ４３）。図８には、ステップＳ４２のリセット前とリセット後のデバイス情報テーブルの例を示した。

以上の処理は、次の集計期間に入る際に、次の集計期間の通信データ量を計測できるようにするめに行うものである。
管理装置１０は、通信方式Ａ以外にも、通信方式テーブルに登録されている全ての通信方式について、その通信方式に関する締め日が経過したことを検出すると、同様な処理を行う。

次に図９に、管理装置１０のオペレータがデバイス２０に対するサービスの実行を指示した場合の管理装置１０の動作の例を示す。
管理装置１０のオペレータは、管理対象のデバイス２０の何れかのデバイスＩＤ及び、提供するサービスの種類を指定して、そのデバイスに対するサービスの提供を管理装置１０に指示することができる。ここでは、オペレータが指示するのはサービス提供部１０６が提供するサービスであるとする。

管理装置１０は、この指示を受けると（Ｓ５１）、指示に係るサービスを提供するために必要な通信データ量を算出する（Ｓ５２）。この算出は、サービス提供に際してデバイス２０との間で送受信することが予想されるデータのサイズに基づき行うことができる。

管理装置１０は次に、サービスの提供対象として指定されたデバイスが使用する通信方式について、通信方式テーブル中の通信データ量の集計を更新する（Ｓ５３）。すなわち、該通信方式を使用する各デバイスについての通信データ量をデバイス管理テーブルから取得して合計し、通信方式テーブルに登録する。この集計は、管理装置１０がデバイス２０と通信する度に行っているのであればここで改めて行う必要はない。しかし、処理負荷軽減のためリアルタイムでの集計を行っていない場合には、次のステップＳ５４の処理の前に行っておく必要がある。

管理装置１０は次に、ステップＳ５２で算出したサービス提供のためのデータ量と、ステップＳ５３において集計した、対象デバイスが使用する通信方式の通信データ量と、その通信方式の通信許容量とに基づき、サービス提供可否を判断する（Ｓ５４）。このステップＳ５４の処理において、ＣＰＵ１１が判断手段として機能する。
この判断基準はここでは、通信許容量が、該当通信方式の通信データ量と、サービス提供のために必要な通信データ量との合計よりも大きければ提供可、そうでなければ提供不可と判断する、というものである。通信許容量の方が大きい場合、今回サービスを提供しても、通信方式毎の通信データ量が通信許容量を超えないと考えられるためである。
しかし、集計期間内の今後の定期動作に悪影響を与えないよう、一定のマージンを設ける等、他の基準を用いることも考えられる。

また、サービスの提供対象のデバイスが使用する通信方式について、通信方式テーブルに登録されているその通信方式の通信データ量と締め日とに基づき、次の締め日までのその通信方式の通信データ量を予測し、現在の通信データ量に代えてその予測値をステップＳ５４の判断に用いることも考えられる。この予測は、現在のペースでの通信が続くと仮定して、単に、（現在の通信データ量）／（現在の集計期間における経過日数）×（現在の集計期間の総日数）として行ってもよいし、その他適当な手法で行ってもよい。
このような予測値を用いることにより、今回サービスを提供しても、集計期間内の今後の定期動作に悪影響を与えないと予想できる場合のみ、サービス提供を許可すると判断するようにすることができる。

いずれにせよ、管理装置１０は、ステップＳ５４で提供可と判断した場合に、ステップＳ５１で受け付けた指示に従い、デバイス２０に対するサービスを実行する（Ｓ５５）。そして、これに対しデバイス２０から応答を受信する（Ｓ５６）。その後、管理装置１０は、今回のサービス提供に際し実際にデバイス２０との間で送受信したデータ量に従い、デバイス管理テーブルにおける該デバイスの通信データ量を更新（加算）する（Ｓ５７）。

以上の動作により、管理装置１０は、通信方式毎の通信許容量を考慮しつつ、サービス提供可否を判断することができる。このため、この通信許容量の範囲であれば、デバイス１台毎の通信許容量を超えるようなデータ送受信を伴うサービスも提供することができる。従って、通信量の制約がある場合でも、効率よく管理対象デバイスに通信が必要なサービスを提供可能である。

次に図１０に、通信方式Ａの締め日における管理装置１０の動作の例を示す。
図１０の動作は、通信方式毎の締め日において、まだその通信方式の通信データ量に余裕がある場合に、その範囲で管理装置１０がデバイス２０に対してサービスを提供するものである。

この動作において管理装置１０は、通信方式Ａについての締め日の所定時刻になったことを検出すると（Ｓ６１）、その通信方式Ａについて、図９のステップＳ５３の場合と同様に、通信方式テーブル中の通信データ量の集計を更新する（Ｓ６２）。なお、所定時刻は、以後あまりデバイス２０との間に通信が発生せず、かつサービス提供のための時間は残っているような時刻を、適宜定める。また、図１０には、ステップＳ６２における更新後の通信方式テーブルの例を示した。

その後、管理装置１０は、予め締め日に提供すべきことを定めておいたサービスについて、そのサービスをデバイス２０に提供するための通信データ量を算出する（Ｓ６３）。この算出は、図９のステップＳ５２の場合と同様に行えばよい。ただし、対象のデバイスによって通信データ量が大きく変わることが予想される場合は、ステップＳ６５のデバイス選択を、ステップＳ６３に先立って行うことが好ましい。

次に、管理装置１０は、図９のステップＳ５４の場合と同様に、サービスの提供可否を判断する（Ｓ６４）。ただし、ここで用いるデータは、ステップＳ６３で算出したサービス提供のためのデータ量と、ステップＳ６２において集計した、締め日を迎えた通信方式の通信データ量と、その通信方式の通信許容量である。そして、その通信方式の通信データ量に、通信許容量と比べて、サービスを提供できる程度に余裕がある場合に、提供可と判断する。ただしここでは、図９の説明で述べたマージンや予測値を考慮する必要はない。このステップＳ６４の処理においても、ＣＰＵ１１が判断手段として機能する。

この場合、管理装置１０は、通信方式Ａを使用するデバイス２０の中から１台を選択して（Ｓ６５）、そのデバイス２０に対して、上記の予め定めておいたサービスを実行し（Ｓ６６）、応答を受け取る（Ｓ６７）。その後、今回のサービス提供に際し実際にデバイス２０との間で送受信したデータ量に従い、デバイス管理テーブルにおける該デバイスの通信データ量を更新（加算）すると共に、使用した通信方式Ａの通信データ量も再集計する（Ｓ６８）。

その後、管理装置１０は、ステップＳ６４乃至Ｓ６８（必要があればＳ６３も）の処理を繰り返し、サービスを提供する必要のあるデバイスがなくなるか、又はステップＳ６４で許可できないと判断するまで続ける。そして、これらのいずれかが満たされると図１０の動作を終了する。
なお、ステップＳ６５での選択では、基本的にはサービスを未実行のデバイスを選択する。しかし、同じデバイスに複数回提供して意味のあるサービスであれば、同じデバイスを繰り返し選択することも妨げられない。

以上の動作により、管理装置１０は、締め日までに使わず残っていた通信許容量を利用して、節約や追加費用を特段意識することなく、データ送受信を伴うサービスも提供することができる。従って、通信量の制約がある場合でも、効率よく管理対象デバイスに通信が必要なサービスを提供可能である。
管理装置１０は、通信方式Ａ以外にも、通信方式テーブルに登録されている全ての通信方式について、その通信方式に関する締め日の所定時刻になったことを検出すると、同様な処理を行う。

次に図１１に、通信データ量の集計を行う場合の管理装置１０の動作の例を示す。
管理装置１０は、一定周期毎など、予め定めた通信データ量確認タイミングになったことを検出すると（Ｓ７１）、通信方式テーブルにおける各通信方式の通信データ量の値を更新する（Ｓ７２）。すなわち、各通信方式について、その通信方式を使用する各デバイスについての通信データ量をデバイス管理テーブルから取得して合計し、通信方式テーブルに登録する。なお、一周期の中で複数回の確認タイミングを設けることも妨げられない。

その後、管理装置１０は、通信データ量が、通信許容量に所定の係数を乗じた値を超えている、すなわち通信データ量が通信許容量に対して所定の割合に達した通信方式があるか否か判断する（Ｓ７３）。所定の割合とは、もうすぐ通信データ量が通信許容量を超えそうであることを意味する値である。具体的な数値は、管理装置１０の管理者が予め管理装置１０に設定しておく。
そして、ステップＳ７３でこのような通信方式があった場合、管理装置１０は、所定の通知先であるオペレータにその旨及び該当通信方式の通信方式ＩＤを通知する（Ｓ７４）。通知の方式は、画面への表示、音声、電子メール送信など、任意の方式で行うことができる。このステップＳ７４の処理において、ＣＰＵ１１は通知手段として機能する。

以上の動作により、管理装置１０のオペレータは、通信データ量が通信許容量を超える前に、その前兆を把握でき、これに基づきサービス提供指示の内容や頻度を調整することができる。
また、通信方式毎の通信データ量の集計をこのように所定の確認タイミングで行うようにすれば、集計に要する処理負荷を軽減することができる。

次に図１２に、デバイスからの通知を受信した場合の、管理装置１０の図７とは異なる動作の例を示す。
図１２の動作において、ステップＳ８１乃至Ｓ８４の動作は、図７のステップＳ３１乃至Ｓ３４と同様である。すなわち、管理装置１０は、デバイス２０から受信した通知に関する動作を実行して応答を返し、そのデバイスに関する通信データ量を、このとき送受信したデータ量だけ加算する。

その後、管理装置１０は、今回通信したデバイスが使用する通信方式について、通信方式テーブルにおける通信データ量の値を更新する（Ｓ８５）。すなわち、その通信方式を使用する各デバイスについての通信データ量をデバイス管理テーブルから取得して合計し、通信方式テーブルに登録する。
次に管理装置１０は、該当の通信方式について、図１１のステップＳ７３の場合と同様、通信データ量が通信許容量に所定の係数を乗じた値を超えている否か判断する（Ｓ８６）。そして、超えていれば、オペレータにその旨及び該当通信方式の通信方式ＩＤを通知する（Ｓ８７）。

以上の動作によっても、管理装置１０のオペレータは、通信データ量が通信許容量を超える前に、その前兆を把握でき、これに基づきサービス提供指示の内容や頻度を調整することができる。
また、通知受信時の動作を図１２のものとし、通信方式毎の通信データ量の集計をデバイス２０から通知を受信したことをトリガに行うようにすれば、リアルタイムに各通信方式の通信データ量を把握し、ニアフルの通知を迅速に行うことができる。

以上で実施形態の説明を終了するが、この発明において、各部の具体的な構成や処理の手順、取り扱うデータの構成及び形式、判断の基準等は、実施形態で説明したものに限るものではない。
例えば、上述した管理装置１０の機能は、１台の装置に全て設けるだけでなく、複数の装置に分散して設けることができる。後者については、図１３に示すように、複数の装置（例えば、第１要素装置１０１０、第２要素装置１０２０、第３要素装置１０３０、・・・、および主要素装置１１００）が協働して、上述の管理装置１０と同等の機能を備える管理システム１０００として機能するようにすることが考えられる。

また、管理装置１０と管理対象のデバイス２０とが、これらの間の通信を仲介する仲介装置を介して通信を行う場合でも、この発明を適用可能である。この場合、管理装置１０からデバイス２０までの通信経路のうち、契約により通信データ量に制約のある箇所の通信データ量を、上述の実施形態の場合と同様に管理し、サービス提供可否の判断に用いればよい。

また、管理対象のデバイス２０は、画像形成装置や投影装置に限られず、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム，自動車，航空機あるいは汎用コンピュータ等の種々の電子装置に通信機能を持たせた通信装置を管理対象とすることが考えられる。
また、以上説明してきた実施形態及びその変形の構成は、相互に矛盾しない限り任意に組み合わせて実施可能であることは勿論である。

１０：管理装置、１１：ＣＰＵ、１２：ＲＯＭ、１３：ＲＡＭ、１４：ＨＤＤ、１５：通信Ｉ／Ｆ、１６：表示部、１７：操作部、１８：システムバス、２０：デバイス、３０：通信網、１０１：通信方式管理部、１０２：デバイスリスト管理部、１０３：通信許容量算出部、１０４：通信データ量算出部、１０５：通知処理部、１０６：サービス提供部、１０７：サービス提供判断部、２０１：通知送信部、２０２：機器情報保持部、２０３：要求受信部

特開２００６−５９１５４号公報

Claims (7)

1. 通信手段を介して通信可能な複数のデバイスを管理する管理装置であって、
   管理対象のデバイス毎に、該デバイスとの通信に使用する通信方式及び、該デバイスとの間の通信データ量を管理する第１の管理手段と、
   通信方式毎に通信許容量を設定する設定手段と、
   前記デバイスに対する通信を伴うサービスの提供可否を、該サービスの提供に要する通信データ量と、該デバイスが使用する通信方式についての通信許容量と、該通信方式を使用する各デバイスの通信データ量の合計とに基づき判断する判断手段とを備えたことを特徴とする管理装置。
2. 請求項１に記載の管理装置であって、
   前記通信方式毎に締め日を管理する第２の管理手段を備え、
   前記判断手段は、サービスの提供対象のデバイスが使用する通信方式について、該通信方式を使用する各デバイスの通信データ量の合計と、該通信方式の締め日とに基づき、次の締め日までの該各デバイスの通信データ量の合計を予測し、前記デバイスに対する通信を伴うサービスの提供可否を、該サービスの提供に要する通信データ量と、前記予測により得られた予測値と、該通信方式の通信許容量とに基づき判断することを特徴とする管理装置。
3. 請求項１又は２に記載の管理装置であって、
   いずれかの通信方式の締め日において、該通信方式を使用する各デバイスの通信データ量の合計が該通信方式の通信許容量に達していなかった場合、該通信方式を使用するデバイスのいずれかに対し、通信を伴うサービスのうち予め定めたものを提供するサービス提供手段を備えることを特徴とする管理装置。
4. 請求項１乃至３のいずれか一項に記載の管理装置であって、
   前記第１の管理手段は、管理対象のデバイスから通知を受信したことをトリガに、該デバイスが使用する通信方式について、該通信方式を使用する各デバイスの通信データ量の合計を更新することを特徴とする管理装置。
5. 請求項１乃至３のいずれか一項に記載の管理装置であって、
   前記第１の管理手段は、一定周期で、各通信方式について、該通信方式を使用する各デバイスの通信データ量の合計を更新することを特徴とする管理装置。
6. 請求項１乃至５のいずれか一項に記載の管理装置であって、
   いずれかの通信方式について、該通信方式を使用する各デバイスの通信データ量の合計が該通信方式の通信許容量に対して所定の割合に達したことを検知すると、該通信方式を使用する各デバイスの通信データ量の合計が該通信方式の通信許容量に対して所定の割合に達した旨を所定の通知先に通知する通知手段を備えたことを特徴とする管理装置。
7. 通信手段を介して通信可能な複数のデバイスを管理する管理システムであって、
   管理対象のデバイス毎に、該デバイスとの通信に使用する通信方式及び、該デバイスとの間の通信データ量を管理する第１の管理手段と、
   通信方式毎に通信許容量を設定する設定手段と、
   前記デバイスに対する通信を伴うサービスの提供可否を、該サービスの提供に要する通信データ量と、該デバイスが使用する通信方式についての通信許容量と、該通信方式を使用する各デバイスの通信データ量の合計とに基づき判断する判断手段とを備えたことを特徴とする管理システム。

Images