JP5585257B2 - 画像形成装置、機器システム、プログラム管理方法、プログラム - Google Patents

Description

本発明は、ユーザにライセンスされたプログラムを導入する画像形成装置に関し、特に、導入された機能の削除タイミングを管理する画像形成装置、機器システム、プログラム管理方法及びプログラムに関する。

コピー、スキャナ、プリンタ若しくはＦＡＸ、又は、これらの機能の複数が備わった複合機(ＭＦＰともいう)等の機器は、内部に情報処理装置を備えている。この情報処理装置に搭載可能なＣＰＵの性能が向上しており、また、大容量メモリが低価格で提供されるようになっている。

また、機器の利用形態もネットワーク化が進んでおり、予め機器にアプリケーションを記憶させておいて出荷する（箱売り）のではなく、ユーザが必要に応じてアプリケーションを購入しネットワーク経由でアプリケーションをダウンロードし、機器へインストールする販売形態も可能になってきた。

機器へのアプリケーションのインストールは、不正利用の防止を目的としてライセンス（使用権限）の有無により管理される。ライセンスの実体は、例えば、ユーザがアプリケーションの正式購入時に知らされるライセンスキーである。ユーザは、インストール時にライセンスキーを入力することで、機器へアプリケーションをインストールすることができる。

また、ライセンスサーバに使用権限のある機器の情報等を登録しておくことで、ライセンスが管理される場合もある。この場合、ユーザは、アプリケーションをインストール後、利用する際にライセンスサーバへアクセスし、機器のライセンス認証をライセンスサーバに要求する。認証が成立すれば、ユーザは機器のアプリケーションを利用できる。

しかし、これらのライセンスの管理では、認証対象があくまでアプリケーションを導入する"機器(ex 機器ユニークのシリアルコード)"である。

これに対し、ライセンスの有無をインストールしたアプリケーションの数により管理するフローティングライセンスというライセンス形態もある。フローティングライセンスは、ライセンスの契約時に予めライセンス上限数を決めておき、ライセンス上限数を超えなければ、アプリケーションの導入を特定の機器に限定することなく、複数の機器へ認めるライセンス形態である。

また、機器でもライセンス上限数でもなく、"個人"単位でライセンスを管理することが適切な状況もある。画像形成装置を例にすると、個人がサードベンダ作成のアプリケーション（ユーティリティ）などを購入して、職場にて自身が利用する機器に導入する場合が挙げられる。組織/部署がアプリケーションを購入するのではなく、あくまで個人が購入/導入するアプリケーションであるため、個人のみが利用可能である必要がある。以下、ユーザ単位のアプリケーションのライセンスを、ユーザと紐つくライセンスという。

なお、個人が購入するアプリケーションとしては、単純な電卓、各種ガジェットのような機能を提供するものから、画面や操作フロー等を個人が登録したユニークな内容にする見た目や使いやすさを変更させるものなどが想定される。

個人単位のライセンスが必要なアプリケーションの場合、ユーザがアプリケーションを導入した機器だけでなく、違う機器を利用時にもそのアプリケーションを使いたい場合がある。例えば、ユーザが、出張時やいつもと違うフロアで臨時的に業務を行う場合である。この場合、ライセンスの管理が機器単位であるならば、ユーザが事前に導入済みの機器から該当機能を削除（ライセンス返却）したうえで、臨時で使う機器に新たに導入しなおす必要がある。

しかし、個人単位でライセンスの管理する形態では、例えば、ライセンスサーバが、各ユーザのログイン（個人特定）に連動させログインユーザにライセンスが付与されているアプリケーションを特定することにより、ログインした機器に該当アプリケーションを即時導入するといったことが可能である（例えば、特許文献１参照。）。

特許文献１には、ユーザログイン時にユーザと紐づくライセンスの有無を判定し、ユーザがライセンスを有するアプリケーションがある場合、該当アプリケーションをユーザがログインした機器にダウンロード及びインストールさせるアプリケーションの管理方法が開示されている。

しかしながら、特許文献１に開示された技術は、ユーザの利用後には他機からダウンロードしたアプリケーションを自動削除してしまうため、ユーザがアプリケーションを削除するタイミングを調整できないという問題がある。例えば、アプリケーションの利用後といっても、ログアウトにより自動的に削除されてしまうと、臨時とはいえある程度の期間に渡ってユーザが頻繁に機器を利用する場合に、再び導入/削除といった処理が何度も実行されてしまう無駄が生じる。

また、臨時で利用するためにログインしたユーザによって導入されたアプリケーションが、ログインしたユーザとは別に該当機器に登録済のユーザにライセンスされている場合（ex ライセンスを購入してユーザとライセンスの関連付けは完了しているか機器には未導入の場合）がある。

この場合、該当機器に登録済みユーザの立場からすれば導入済みのままで削除して欲しくない。すなわち、該当機器に登録済みユーザがログインした際に、再度導入を行う必要があるため、ログアウトにより自動的に削除されてしまうと、操作性や作業効率を低下させてしまうという問題がある。

本発明は、上記課題に鑑み、個人単位でライセンスの管理されるライセンス形態において、アプリケーションを削除するタイミングを制御可能な画像形成装置、機器システム、プログラム管理方法及びプログラムを提供することを目的とする。

上記課題に鑑み、本発明は、機能を実現するプログラムの起動が、プログラムの正当利用者であることを示すライセンス情報により認められる画像形成装置であって、ユーザのログインを受け付けるログイン受け付け手段と、プログラムを記憶するプログラム記憶手段と、ユーザ個人にライセンスされたプログラムとライセンス情報を外部から取得し、前記プログラム記憶手段に記憶する機能導入手段と、前記機能導入手段が記憶したプログラムのライセンス情報が、ユーザＩＤに対応づけられたユーザ情報を記憶するユーザ情報記憶手段と、前記機能導入手段が記憶したプログラムが前記プログラム記憶手段から削除される削除タイミングの設定を受け付ける削除タイミング受け付け手段と、前記削除タイミング受け付け手段が受け付けた削除タイミングが到来した場合に、前記機能導入手段が前記プログラム記憶手段に記憶したプログラムを削除する削除手段と、を有し、前記削除タイミング受け付け手段は、ネットワークを介して接続された他の機器へのユーザのログイン時を削除タイミングの設定として受け付け、前記削除手段は、前記他の機器からログインしたユーザのユーザＩＤを受信した場合、該ユーザＩＤに対応づけられていたプログラムを前記プログラム記憶手段から削除する、ことを特徴とする。

個人単位でライセンスの管理されるライセンス形態において、アプリケーションを削除するタイミングを制御可能な画像形成装置、機器システム、プログラム管理方法及びプログラムを提供することができる。

機器へのアプリケーションの導入及び削除の概略を説明する図の一例である。 機器システムの構成図の一例である。 画像形成装置のハードウェア構成図の一例である。 画像形成装置の機能ブロック図の一例である。 ユーザ情報を模式的に示す図の一例である。 ライセンスの取得を説明する図の一例である。 画像形成装置がユーザ情報の紐つきライセンス情報を更新するタイミングを説明する図の一例である。 画像形成装置がユーザ情報を更新する手順を説明する図の一例である。 ユーザ情報更新部がユーザ情報を更新する手順を示すフローチャート図の一例である。 機能の自動導入を模式的に説明する図の一例である。 自動導入の手順を説明するフローチャート図の一例である。 ユーザ情報と操作画面の関係を示す図の一例である。 画面生成部が操作画面を生成する手順を示すフローチャート図の一例である。 ユーザ情報と操作画面の関係を示す図の一例である。 ウィザードによる誘導を模式的に説明する図の一例である。 画面生成部が操作画面を生成する手順を示すフローチャート図の一例である。 機器１００と機器２００の状態を説明する図の一例である。 機能の自動削除の削除タイミングを設定する画面の一例を示す図である。 削除タイミングを模式的に説明する図の一例である。 複数のユーザが共通の機能のライセンスを有する場合の削除タイミングを説明する図の一例である。 削除タイミングテーブルの一例を示す図である 機能削除部が自動導入した機能を自動削除する手順を示すフローチャート図の一例である。 複数のユーザが共通の機能のライセンスを有する場合の削除タイミングを説明する図の一例である。 削除タイミングテーブルの一例を示す図である。 機能削除部が自動導入した機能を自動削除する手順を示すフローチャート図の一例である。 削除タイミングの設定を受け付ける画面の一例である。 削除タイミングテーブルの一例を示す図である。 機能削除部が自動導入した機能を自動削除する手順を示すフローチャート図の一例である。 機能削除部が削除タイミングテーブルを更新する手順を示すフローチャート図の一例である。 削除タイミングテーブルの遷移例を示す図である。 削除タイミングテーブルに「削除しない」という削除タイミングを設定するか否かをユーザが設定する画面の一例である。 機能削除部が削除タイミングテーブルを更新する手順を示すフローチャート図の一例である。 再削除のタイミングの設定を受け付ける画面の一例を示す図である。 機能削除部が自動導入した機能を再度、削除する手順を示すフローチャート図の一例である。 他機へのログインを削除タイミングとする画像形成装置の動作を模式的に説明する図の一例である。 機能削除部が、機能を削除する手順を示すフローチャート図の一例である。 削除タイミングの設定を受け付ける画面の一例である。 機器システムの概略を説明する図の一例である。 機器システムに導入可能な機能の数の設定を受け付ける画面の一例である。 機器構成情報の一例である。 機能の削除の手順を説明するフローチャート図の一例である。

以下、本発明を実施するために形態について図面を参照しながら実施例を挙げて説明する。

図１は、機器２００へのアプリケーションの導入及び削除の概略を説明する図の一例である。機器１００はユーザaaaaが普段使用する機器であり、機器２００はユーザaaaaが臨時的に使用する機器である。機器１００と機器２００は、ライセンスサーバ４００に接続されている。
（１）ユーザaaaaは「○○機能」というユーザaaaaにライセンスされた紐付きライセンスを有している。「○○機能」はユーザaaaaが○○アプリの使用権利を有することを示すライセンスである。したがって、機器１００に○○アプリが導入されていても、ユーザaaaa以外のユーザは○○アプリを利用できない。
（２）ユーザaaaaが機器２００を使用する機会が訪れ機器２００にログインすると、機器２００はユーザaaaaのユーザＩＤをライセンスサーバ４００に送信し、紐付きライセンスの有無を問い合わせる。すると、ライセンスサーバ４００は、ユーザaaaaは「○○機能」の紐付きライセンスを有していることを機器２００に通知する。
（３）機器２００は、ライセンスサーバ４００から「○○機能」のライセンス情報と○○アプリを取得し導入する。こうすることで、ユーザaaaaはライセンスサーバ４００と接続された機器２００を使用する際、紐付きライセンスが付与されている機能を自動的に使用することができる。
（４）そして、本実施形態の機器２００は、○○アプリの導入時（または、導入後、ユーザが使用後等）、○○アプリの削除タイミングの設定をユーザaaaaから受け付ける。これが機器２００の特徴の１つとなる。

ユーザaaaaは、ログアウト後、日付変更時、設定した日時等、所望の削除タイミングを機器２００に設定することができる。図では、楕円の終端が、ユーザが設定した削除タイミングを意味し、楕円が占める期間、ユーザが○○アプリを使用できることを意味する。

このように、本実施形態の機器１００は、各ユーザが個人的に有する紐付きライセンスに基づきユーザ毎に使用可能な機能の削除タイミングをユーザが設定することができる。

なお、説明のため本実施形態で使用する用語を簡単に定義しておく。
「機能」とはアプリケーション（以下、単にアプリという）が提供する機能である。以下では、「機能」を「アプリ」と同じ意味で用いる場合がある。また、ユーザが機器１００でその機能を使用できるようにすることを機能の導入というが、これはインストール及びアクティベーションとほぼ同じ意味である（すでにインストールされている場合は、アクティベーションのみとなる）。なお、アクティベーションとは、正規のライセンスを持っていることが証明されアプリを使用可能となることである。

「アプリ」には、種々のプログラムが含まれる。例えば、電卓、電子カレンダ、スケジュール表などのユーティリティ、画面の色やアイコンの配置を規定したように並び替える画面変更ソフト、予め登録してある印刷条件・読み取り条件・ＦＡＸ送信先等を機器１００に設定する制御用ソフト、コピー機能・スキャナ機能・ＦＡＸ機能等の基本的な機能そのもののソフトがある。
「紐つきライセンス」とは機器ではなくユーザに機能の使用を認めるライセンス形態のライセンスをいい、「紐つきライセンス情報」とは、紐つきライセンスの実体（例えばライセンスキー）である。本実施形態では、紐つきライセンス情報が機能の機能名を兼ねる。これに対し、機器に使用を認めるライセンス形態を「通常ライセンス」という。また、ユーザが機器とは別に購入する必要のない機能もあり、このような機能を「デフォルト」の機能という（ライセンス情報がない）。

したがって、アプリの本体だけではユーザがアプリを起動することができず、アプリと一対の紐つきライセンス情報が機器に登録されることでユーザがそのアプリを起動できるようになる。または、紐つきライセンス情報にアクセス可能であることで機能の導入が可能になる。

〔全体的な構成〕
図２は、機器システム６００の構成図の一例を示す。機器１００及び機器２００が、ネットワーク５００を介して、販売サーバ３００、ライセンスサーバ４００及び管理サーバ７００と接続されている。機器１００、２００は、プリンタ機能、スキャナ機能、ＦＡＸ機能等の１つ以上の機能を備えた装置である。ＭＦＰ（Multifunction Peripheral）と呼ばれることもある。本実施形態の特徴部を有するのは、臨時にログインされる機器２００であるが、機器１００も機器２００と同様の機能を有するものとする。よって、機器１００と２００が区別して記述されていても便器上のものであり、どちらも同等の機能を有する。

販売サーバ３００は、機能をユーザや機器１００に販売するサーバである。ライセンスサーバ４００は、ユーザにライセンスされた機能を管理するサーバである。また、説明を容易にするため、ライセンスサーバ４００は、ユーザがログインした機器１００に機能を導入するサーバとしての役割を果たすサーバとするが、機能を蓄積したサーバはライセンスサーバ４００と別でもよい。管理サーバ７００は、ユーザを管理するサーバである。管理サーバ７００は、機器システム６００の全てのユーザのユーザＩＤとパスワードを管理する。

機器２００は、ユーザが臨時的に機能を使用する機器である。機能は自動的に機器２００に導入されるので、ユーザは機器１００だけでなく、機器２００でも購入した機能を使用することができる。このような点において、紐つきライセンスは通常ライセンスより有効となる。また、機器１００、２００はコンピュータを備えるので、これらが販売サーバ３００又はライセンスサーバ４００のいずれか１つ以上を兼ねることもできる。

ネットワーク５００は、ＬＡＮ，ＷＡＮ（ＶＬＡＮ、ＶＰＮ等）、又は、インターネットなどである。また、ネットワーク５００は有線でも無線でもよい。

図３は、機器１００のハードウェア構成図の一例を示す。機器１００は、コントローラ１３０と、オペレーションパネル１２５と、ファクシミリコントロールユニット（ＦＣＵ）１２６と、撮像部１２７及び印刷部１２８が有する。

コントローラ１３０は、ＣＰＵ１１４と、ＡＳＩＣ１１６と、ＮＢ（ノースブリッジ）１１５と、ＳＢ（サウスブリッジ）１１７と、ＭＥＭ−Ｐ（システムメモリ）１１１と、ＭＥＭ−Ｃ（ローカルメモリ）１１２と、ＨＤＤ（ハードディスクドライブ）１１３と、メモリカードスロット１２３と、ＮＩＣ（ネットワークインタフェースコントローラ）１１８と、ＵＳＢデバイス１１９と、ＩＥＥＥ１３９４デバイス１２１と、セントロニクスデバイス１２２とを有する。

ＣＰＵ１１４は、種々の情報処理を実行するためのＩＣであり、アプリやプラットフォーム、オプションパッケージをＵＮＩＸ（登録商標）等のＯＳによりプロセス単位で並列的に実行する。ＡＳＩＣ１１６は、画像処理用のＩＣである。ＮＢ１１５は、ＣＰＵ１１４とＡＳＩＣ１１６を接続するためのブリッジである。ＳＢ１１７は、ＮＢ１１５と周辺機器等を接続するためのブリッジである。ＡＳＩＣ１１６とＮＢ１１５は、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）を介して接続されている。

ＭＥＭ−Ｐ１１１は、ＮＢ１１５に接続されたメモリである。ＭＥＭ−Ｃ１１２は、ＡＳＩＣ１１６に接続されたメモリである。ＨＤＤ１１３は、ＡＳＩＣ１１６に接続されたストレージであり、画像データ蓄積・文書データ蓄積・プログラム蓄積・フォントデータ蓄積・フォームデータ蓄積等を行うために使用される。ＨＤＤ１１３には上記の種々のアプリ、及び、プログラム１３１が記憶されている。

メモリカードスロット１２３は、ＳＢ１１７に接続され、メモリカード１２４をセット（挿入）するために使用される。メモリカード１２４は、ＵＳＢメモリ等のフラッシュメモリであり、プログラム１３１を配布するために使用される。また、プログラム１３１は所定のサーバから機器１００にダウンロードして配布することもできる。

ＮＩＣ１１８は、ネットワーク５００等を介してＭＡＣアドレス等を使用したデータ通信を行うためのコントローラである。ＵＳＢデバイス１１９は、ＵＳＢ規格に準拠したシリアルポートを提供するためのデバイスである。ＩＥＥＥ１３９４デバイス１２１は、ＩＥＥＥ１３９４規格に準拠したシリアルポートを提供するためのデバイスである。セントロニクスデバイス１２２は、セントロニクス仕様に準拠したパラレルポートを提供するためのデバイスである。ＮＩＣ１１８と、ＵＳＢデバイス１１９と、ＩＥＥＥ１３９４デバイス１２１と、セントロニクスデバイス１２２と、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｅｃｔ）バスを介してＮＢ１１５とＳＢ１１７に接続されている。

オペレーションパネル１２５は、ユーザが機器１００に入力を行うためのハードウェア（操作部）であると共に、機器１００がオペレータに可視情報を提供するためのハードウェア（表示部）である。オペレーションパネル１２５は、ＡＳＩＣ１１６に接続されている。ＦＣＵ１２６と、撮像部１２７と、印刷部１２８は、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｅｃｔ）バスを介してＡＳＩＣ１１６に接続されている。

図４は、機器１００の機能ブロック図の一例を示す。機器１００は、ＣＰＵ１１４がプロラムを実行して実現される、ユーザ認証部１１、機能導入部１２、ユーザ情報更新部１３、画面生成部１５、起動部１６、機能削除部１８、削除タイミング受け付け部２７、及び、上限数受け付け部２５、ログイン通知部１７、及び、再削除タイミング受け付け部１９を有する。また、機器１００は、ＨＤＤ１３等に記憶されたユーザ情報２１、機器構成情報２２、及び、削除タイミングテーブル２６、並びに、ＨＤＤ１３等を実体とする機能記憶部２３及び部品記憶部２４を有する。

各機能ブロックについて間単に説明する。ユーザ認証部１１は、ユーザが入力したユーザＩＤとパスワードの組がユーザ情報２１に登録されているか否かに基づき、ユーザを認証する。機能導入部１２はログインしたユーザにライセンスされた機能が機器２００に登録されていない場合、ライセンスサーバ４００から機能を導入する。

ユーザ情報更新部１３は、ライセンスサーバ４００と通信してユーザ情報２１の紐つきライセンス情報を更新する。

画面生成部１５は、機能にリンクしたアイコンを部品記憶部２４から読み出し、オペレーションパネル１２５に表示される操作画面に表示する。起動部１６は、機能を自動起動させる。機能削除部１８は、機器２００に導入されている機能を削除する。

削除タイミング受け付け部２７はユーザによる削除タイミングの設定を受け付ける。上限数受け付け部２５は、機器システム６００において記憶可能な機能の数の上限の設定を受け付ける。ログイン通知部１７は、ユーザがログインしたことを示すログイン通知（ユーザＩＤ）を機器システム６００上の機器に同報送信する。再削除タイミング受け付け部１９は、機能削除部１８が削除に失敗した場合を想定して、再削除のタイミングの設定を受け付ける。

機能記憶部２３は機能（すなわちアプリ）を記憶する記憶手段であり、部品記憶部２４は操作画面を構成する各種のアイコンや文字などの部品を記憶する記憶手段である。削除タイミングテーブル２６は、機能毎に、削除するタイミングが登録されたテーブルである。

〔ユーザ情報〕
図５（ａ）は、ユーザ情報２１を模式的に示す図の一例である。ユーザ情報２１には、ユーザＩＤに対応づけられて、パスワード及び紐つきライセンス情報が登録されている。
・ユーザＩＤは、機器１００にログインする上で、ユーザを特定するためのユニークな識別情報である。
・パスワードは、ユーザを認証するための情報である。ユーザ認証部１１は、ユーザが機器にログインする際に入力したユーザＩＤとパスワードの組が、ユーザＩＤに対応付けて登録されているパスワードの組と一致するか否かに基づき、ユーザを認証する。なお、以下の図のユーザ情報２１ではパスワードを省略する。
・紐つきライセンス情報は、上述したように、ユーザ毎に機能のライセンスが与えられるライセンス形態にてライセンスされた機能の機能名（ライセンス情報）である。

ユーザＩＤと紐つきライセンス情報が登録されていることで、ユーザがその機能を起動できるようになる。

〔機器構成情報２２〕
図５（ｂ）は、機器構成情報２２を模式的に示す図の一例である。機器構成情報２２には、機器１００に導入されている機能の情報が登録されている。

α機能、β機能、γ機能、Σ機能などの各機能に対応づけて、ライセンス形態が登録されている。上述したように、ライセンス形態の「−（デフォルト）」は、その機能が、機器１００とは別にユーザが購入する必要のない機能であることを示す。「通常ライセンス」は、その機能が機器に使用が認められた機能であることを示す。

機器構成情報２２を参照することで、機器は機能が導入されているか否かを判定でき、導入されていない機能を必要に応じて導入することができる。

〔管理情報〕
図５（ｃ）は、管理サーバ７００が管理する管理情報の一例を示す。管理情報には、機器システム６００の全ユーザについてユーザＩＤとパスワードの組が登録されている。管理サーバ７００の管理情報は、各機器１００，２００がユーザ情報２１を更新するために利用される。

なお、図では紐つきライセンス情報も示したが、紐つきライセンス情報は、管理情報に登録されていなくてもよい。紐つきライセンス情報は、機器１００がユーザＩＤをキーにしてライセンスサーバ４００に問い合わせれば容易に取得できるためである。ただし、管理サーバ７００が紐つきライセンス情報を有することで、機器１００はライセンスサーバ４００にアクセスする必要がなくなるので、処理時間を短縮できる。

〔機能の購入とライセンス管理情報の更新〕
図６は、ライセンスの取得を説明する図の一例である。ユーザaaaaとユーザbbbbは、不図示のＰＣ（Ｐｅｒｓｏａｌ Ｃｏｍｐｕｔｅｒ）を操作してブラウザを立ち上げ、販売サーバ３００にアクセスする。ユーザaaaa、ユーザbbbbは、それぞれユーザＩＤを入力し、「α機能」「β機能」等から購入したい機能を選択する。

ブラウザは機能の選択を受け付け、ユーザＩＤと機能名を販売サーバ３００に送信する。なお、図では、ユーザaaaaとユーザbbbbのいずれも、α機能を購入しているがあくまで一例である。ユーザaaaaとユーザbbbbは所定の支払い方法で代金を支払う（支払い方法については省略する）ことで、α機能の紐つきライセンス情報を取得することができる。

α機能の現在のバージョンはＶｅｒ２であるので、「α機能」の隣に「Ｖｅｒ２」と記述されている。本実施形態では、ある機能の紐つきライセンスを購入したユーザはバージョンの制限なくその機能を使用することができるので、特にバージョンを表示しなくてもよい。しかし、このようにバージョンを表示することでユーザは購入した時のバージョンを知ることができる。また、購入した時よりも高いバージョンの機能がリリースされても、ユーザはバージョンアップされた機能を使用する際に、特に追加の料金は要求されないものとする。

販売サーバ３００はユーザに機能を販売すると、販売した機能名とユーザＩＤをライセンスサーバ４００に送信する。ライセンスサーバ４００はライセンス管理情報を管理する。ライセンス管理情報は、機能毎にユーザＩＤを関連付けた情報である。図ではα機能にユーザaaaaとユーザbbbbが登録されている。

ライセンス管理情報を参照することで、ライセンスサーバ４００は、ユーザＩＤ（ログインと連動できる他の情報でもよい）が特定されれば、ユーザに紐つけられた機能を全て特定することができる。また、機器１００、２００に機能をライセンスする通常ライセンスと異なり、ライセンスサーバ４００からＰＣにライセンスキーを発行する必要がない。
紐つきライセンスでは、ライセンスサーバ４００が機器を特定するためにユーザがライセンスキーを入力することが不要なためである。画像形成装置１００は、所望のタイミングでライセンスサーバ４００にアクセスすれば、ライセンスされた機能を導入できる。

なお、比較のため、機器に機能をライセンスする通常ライセンスについて説明する。ユーザが機器を特定して機能を導入させる場合には、販売サーバ３００で機能を購入する際にライセンスサーバがライセンスキーを発行する。ユーザは、このライセンスキーを用いて機能を導入したい機器から導入処理を実行する。導入の際、機器の情報（機器を特定するシリアルＩＤ等）がライセンスサーバ４００に転送され、これによりライセンスサーバ４００は機器とライセンスキーを対応づけて管理すること（「あるライセンスに基づく機能はある機器に導入されている」）ができる。したがって、第三者がライセンスキーを入手しても、ライセンスサーバがライセンスキーを対応づけたシリアル番号の機器以外ではアプリを利用することが防止できる。

〔ユーザ情報２１の更新タイミング〕
ライセンスサーバ４００のライセンス管理情報は、ユーザが機能を購入したり、紐つきライセンスを失うことで変更される。よって、機器１００は、ユーザ情報２１の紐つきライセンス情報を更新する必要が生じる。

図７は、機器１００がユーザ情報２１の紐つきライセンス情報を更新するタイミングを説明する図の一例である。このタイミングとして、
（１）機器１００の電源がＯＮになった直後
（２）電源ＯＮの間の一定間隔毎
（３）ライセンスサーバ４００からライセンス管理情報の変化通知を受けた時
の３つが挙げられる。機器１００には（１）〜（３）のいずれか１つ以上のタイミングが設定されている。機器１００はこれらのタイミングが到来したことを検知して、ライセンスサーバ４００にアクセスする。

図８は、機器１００がユーザ情報２１を更新する手順を説明する図の一例である。更新前の機器１００のユーザ情報２１によれば、ユーザaaaaとユーザbbbbの紐つきライセンス情報は「なし」、ユーザccccの紐つきライセンス情報は「β機能」となっている。

これに対し、ライセンスサーバ４００のライセンス管理情報によれば、ユーザaaaaとユーザbbbbには「α機能」が紐つけられている。したがって、機器１００は、ユーザ情報２１を更新する必要がある。

図９は、ユーザ情報更新部１３がユーザ情報２１を更新する手順を示すフローチャート図の一例である。

まず、ユーザ情報更新部１３は設定されたタイミングが到来したか否かを判定する（Ｓ１）。

タイミングが到来した場合（Ｓ１のＹｅｓ）、ユーザ情報更新部１３は、ユーザ情報２１のユーザＩＤを全てライセンスサーバ４００に送信する（Ｓ２）。

ライセンスサーバ４００は、ユーザＩＤに紐つけられた機能名を全て読み出す（Ｓ３）。例えば、ユーザaaaaについてα機能、ユーザbbbbについてα機能、ユーザccccについてβ機能、が読み出される。

ライセンスサーバ４００は、ユーザＩＤに関連付けて機能名を機器１００に送信する（Ｓ４）。なお、一つのユーザＩＤに複数の機能名（紐つきライセンス情報）が関連付けられることもある。
ユーザaaaa：α機能
：β機能
ユーザbbbb：α機能
ユーザcccc：β機能
：γ機能
ユーザ情報更新部１３は、受信した機能名をユーザＩＤに対応づけて、ユーザ情報２１に登録する（Ｓ５）。

例えば、ユーザ情報更新部１３はユーザaaaaとユーザbbbbに対応づけて、紐つきライセンス情報として「α機能」を登録する。こうすることで、機能を購入したばかりのユーザであるユーザaaaaとユーザbbbbにライセンス情報を設定することができる。

なお、ユーザccccには、紐つきライセンス情報としてすでにβ機能が登録されているので、ユーザ情報更新部１３は特に何もしないが上書きしてもよい。

以上のような処理により、機器１００のユーザ情報２１のユーザＩＤに紐つきライセンス情報を登録することができる。

〔機能の自動導入〕
ユーザがログインした機器２００に、紐つきライセンスをライセンス形態とする機能が導入されていないことが生じうる。このため、機器１００は、ログインしたユーザに応じて機能を自動的に導入する。機能を自動導入するためには、機器１００がログインしたユーザのユーザ情報２１を備える必要があるが、機器１００がユーザ情報２１を取得する（更新する）仕組みとしては次の２つがある。
（１）機器１００のユーザ情報２１に登録されていないユーザがログインを希望した際、機器１００が管理サーバ７００に、ログインを希望するユーザのユーザＩＤ及びパスワードを要求する。こうすることで、ユーザのログイン時に、機器１００はユーザＩＤとパスワードを取得できる。また、機器１００のリソースを節約できる。
（２）機器１００が、定期的に、管理サーバ７００にユーザＩＤ及びパスワードを要求する。この場合、機器１００は、管理サーバ７００と同じユーザＩＤ及びパスワードを常に有することができ、ユーザＩＤがログインを希望した際には、管理サーバ７００にアクセスすることなく機能の自動導入を開始することができる。

いずれの仕組みを採用するかは管理者が適宜設定することができる。また、いずれの仕組みを採用しても、自動導入の手順は同じである。本実施形態では機器２００が（１）の仕組みを採用したとして説明する。

図１０は、機能の自動導入を模式的に説明する図の一例を、図１１は自動導入の手順を説明するフローチャート図の一例である。

まず、ユーザは機器１００にログインする（Ｓ１０）。この段階でユーザはログインのため、ユーザＩＤとパスワードを入力した。

ユーザ認証部１１は、ユーザが入力したユーザIＤがユーザ情報２１に登録されているか否かを判定する（Ｓ２０）。ユーザＩＤがユーザ情報２１に登録されている場合（Ｓ２０のＹｅｓ）、ユーザ認証部１１はユーザを認証する（Ｓ６０）。

ユーザＩＤがユーザ情報２１に登録されていない場合（Ｓ２０のＮｏ）、ユーザＩＤに紐付いた紐つきライセンス情報の機能が導入されているか否か判断できないため、ユーザ認証部１１はまず管理サーバ７００から管理情報のユーザＩＤとパスワードを取得し、ユーザ情報２１に登録する（Ｓ３０）。

そして、ユーザ認証部１１は、管理サーバ７００から取得したユーザＩＤとパスワードに基づきユーザを認証する（Ｓ４０）。ユーザの認証が成立した場合、ユーザ情報更新部１３は、ライセンスサーバ４００からユーザＩＤに対応づけられた紐つきライセンスを取得し、ユーザ情報２１に登録する（Ｓ５０）。これにより、ユーザ情報２１に、ユーザＩＤ、パスワード及び紐つきライセンス情報が登録される。

次に、機能導入部１２はユーザ情報２１を参照し、ログインしたユーザのユーザＩＤに紐つきライセンス情報が登録されている否かを判定する（Ｓ７０）。紐つきライセンス情報が登録されていない場合（Ｓ７０のＮｏ）、機能を自動的に導入する必要はないので図１１の手順は終了する。

紐つきライセンス情報が登録されている場合（Ｓ７０のＹｅｓ）、機能導入部１２は、機器構成情報２２を参照して、紐つきライセンス情報の機能が機器１００に導入されているか否かを判定する（Ｓ８０）。

機能が機器１００に導入されている場合（Ｓ８０のＹｅｓ）、機能を導入する必要がないので、図１１の手順は終了する。

機能が機器１００に導入されていない場合（Ｓ８０のＮｏ）、機能を導入するため、機能導入部１２はライセンスサーバ４００に機能を指定して、その機能を要求する（Ｓ９０）。これにより、ライセンスサーバ４００から機能とライセンス情報が送信されるので、機能導入部１２は、ライセンス情報を用いて機能を機器１００に導入する（Ｓ１００）。これによりユーザがその機能を実行可能な状態となる。

次に、機能導入部１２は、機器構成情報２２を更新する（Ｓ１１０）。更新により、機器１００に実際に導入されている機能と、機器構成情報２２とを一致させることができる。

以上のように、機器１００はユーザが紐つきライセンスを有する機能を自動的に導入することができる。

そして、機器１００が機能を自動導入した場合、機器１００は削除タイミングを受け付ける（Ｓ１２０）ことが本実施形態の機器１００の特徴の一つとなっている。

〔ユーザが有するライセンスと画面の表示例〕
削除タイミングの説明の前に、操作画面の表示例について説明する。ユーザに、ユーザが紐つきライセンスを有する機能を提供するため、機器１００はユーザが紐つきライセンスを有する機能とリンクしたアイコンを、操作画面に表示する。したがって、操作画面はユーザによって変わりうる。

図１２は、ユーザ情報２１と操作画面の関係を示す図の一例である。ユーザaaaaとユーザddddは紐付きライセンス情報を有しておらず、ユーザbbbbは「○○機能」を、ユーザccccは「△△機能」及び「××機能」を有することがわかる。なお、「○○」「△△」「××」はそれぞれ機能名と共通であるとする。また、ユーザ情報２１の更新はすでに終了しているものとする。

図１２の、「Ａ機能アイコン」「Ｂ機能アイコン」「Ｃ機能アイコン」はデフォルトの機能のアイコンである（白抜きのアイコン）。すなわち、「Ａ機能アイコン」「Ｂ機能アイコン」「Ｃ機能アイコン」は、ログインするユーザに関わりなく表示されるアイコンである。

機器１００にユーザaaaaがログインした場合、ユーザaaaaは紐つきライセンス情報を有さないので、操作画面には「Ａ機能アイコン」「Ｂ機能アイコン」「Ｃ機能アイコン」のみが表示される。

一方、ユーザbbbbが機器１００にログインした場合、ユーザbbbbは「○○機能」の紐つきライセンス情報を有するので、操作画面には「Ａ機能アイコン」「Ｂ機能アイコン」「Ｃ機能アイコン」に加え「○○機能アイコン」が表示される（斜線のアイコン）。

これらのアイコンは、機能記憶部２３に記憶されたアプリとリンクされている。起動部１６は、オペレーションパネル１２５の操作位置に基づきユーザが指定したアイコンを特定し、アイコンにリンクされたアプリを機能記憶部２３から読み出して起動する。

図１３は画面生成部１５が操作画面を生成する手順を示すフローチャート図の一例をそれぞれ示す。

まずユーザがログインする（Ｓ２１０）。画面生成部１５はユーザ情報２１を参照し、ログインしたユーザのユーザＩＤに紐つきライセンス情報が登録されている否かを判定する（Ｓ２２０）。

紐つきライセンス情報が登録されている場合（Ｓ２２０のＹｅｓ）、紐つきライセンス情報の機能名に対応したアイコン画像を画面の部品が記憶された部品記憶部２４から読み出す（Ｓ２３０）。

次に、画面生成部１５は、紐つきライセンス情報に対応したアイコン画像を画面の部品が記憶された部品記憶部２４から読み出す（２４０）。このアイコン画像により、例えば、「○○機能アイコン」が可視化される。

次にＳ２２０に戻り、紐つきライセンス情報が登録されていない場合（Ｓ２２０のＮｏ）、紐つきライセンス情報の機能を提供する必要がないので、画面生成部１５は、機器構成情報２２からライセンス形態がデフォルトと通常ライセンスの機能を特定する（Ｓ２５０）。これらの機能は、ユーザに関係なく操作画面からユーザが選択可能な機能である。

また、画面生成部１５は、デフォルトと通常ライセンスの機能に対応したアイコン画像を画面の部品が記憶された部品記憶部２４から読み出す（Ｓ２６０）。

そして、画面生成部１５は、所定の位置に各アイコン画像を配置して、操作画面を生成する（Ｓ２７０）。

＜変形例＞
また、機器１００にログインしたユーザに関係なく、導入されている全ての機能のアイコンを表示してもよい。

図１４は、ユーザ情報２１と操作画面の関係を示す図の一例である。図１４において図１２と同一部の説明は省略する。図１４ではユーザaaaaがログインした際も、「○○機能アイコン」が表示されている。そして、ユーザaaaaが紐つきライセンスを有さない機能の「○○機能アイコン」を押下した場合に、機器１００は、例えば「ライセンスがないためこの機能は利用できません」というメッセージを表示する。このような操作画面では、ログインしたユーザに関係なく操作画面を共通にできる。一方、ユーザbbbbが紐つきライセンスを有する機能とリンクされた「○○機能アイコン」を押下した場合に、機器１００は、○○機能を起動する。

さらに、このメッセージの表示の際、機器１００は、ユーザに紐つきライセンスの購入を促すウィザートを実行してもよい。
図１５は、ウィザードによる誘導を説明する図の一例である。ユーザaaaaが図１４にて「詳細」ボタンを押下すると、機器１００は例えば「○○機能のライセンスを購入するためのウィザードを実行しますか？」というメッセージと「はい」ボタン及び「いいえ」ボタンを表示する。

ユーザaaaaが、「○○機能」を使用するためにはライセンスの購入が必要であることを把握し、「はい」又は「いいえ」のボタンを押下する。

ユーザが「はい」ボタンを押下した場合、機器１００はウィザードを開始する。図では、機器１００が上記の販売サイトにアクセスし、機能の一覧を表示している。ユーザは、販売サイトのＵＲＬを入力することなく「○○機能」のライセンスを購入できる。したがって、機器１００は、該当機能の利用を望むユーザがライセンスを購入するようにユーザを誘導することができる。

図１６は画面生成部１５が図１４のような操作画面を生成する手順を示すフローチャート図の一例を示す。まずユーザがログインする（Ｓ２１０）。

画面生成部１５は機器構成部を参照して、機器１００に導入されている全ての機能を特定する（Ｓ３１０）。すなわち、画面生成部１５は、デフォルト、通常ライセンス及び紐つきライセンスの全ての機能を特定する。

画面生成部１５は機能に対応したアイコン画像を部品記憶部２４から読み出す（Ｓ３２０）そして、画面生成部１５は所定の位置に各アイコン画像を配置して、操作画面を生成する（Ｓ３３０）。

ユーザがアイコンを押下すると、画面生成部１５は、紐付きライセンス情報が登録されていないアイコンが押下されたか否かを判定する（Ｓ３４０）。具体的には、画面生成部１５は、操作画面の押下された位置からアイコンを特定し、アイコンにリンクされた機能を特定する。そして、その機能がユーザ情報２１において、ログインしたユーザのユーザＩＤに対応づけられているか否かを判定する。

紐付きライセンス情報が登録されているアイコンが押下された場合（Ｓ３４０のＮｏ）、そのアイコンにリンクされた機能を起動できるので、起動部１６はユーザが押下したアイコンにリンクされた機能を起動させる（Ｓ３５０）。

紐付きライセンス情報が登録されていないアイコンが押下された場合（Ｓ３４０のＹｅｓ）、そのアイコンにリンクされた機能を起動できないので、起動部１６は上記のメッセージを表示する（Ｓ３６０）。

次に、画面生成部１５は、「詳細」が押下されたか否かを判定する（Ｓ３７０）。「詳細」が押下されない場合（Ｓ３７０のＮｏ）、機器１００は何もせずに例えばステップＳ３３０に戻りアイコンの押下を検出する。

「詳細」が押下された場合（Ｓ３７０のＹｅｓ）、画面生成部１５はライセンス購入する他ためのウィザードを開始する（Ｓ３８０）。これにより図１５（ａ）のような画面が表示される。したがって、操作画面を変えなくてもユーザ毎に機能の利用を制限できる。

〔臨時に機器にログインした際の機能の導入と削除タイミングの設定〕
上述したように、機器２００は自機に動的に機能を導入することができる。まず、機器３００が機能を導入する状況について簡単に説明する。

図１７は、機器１００と機器２００の状態を説明する図の一例である。図１７（ａ）に示すように、ユーザbbbbは、普段、９階の機器１００を使用している。９階の機器１００のユーザ情報２１によれば、ユーザaaaaは紐付きライセンスを有しておらず、ユーザbbbbは「○○機能」の紐付きライセンスを有している。

９階の機器１００に導入されている機能は、デフォルト機能の「コピー」、通常ライセンスの「マーキング」、紐付きライセンスの「○○機能」である。２階の機器２００のユーザ情報２１にはユーザccccとユーザddddが登録されているが、ユーザbbbbは登録されていない。なお、ユーザccccとユーザddddはいずれも紐付きライセンスを有していないので、機器２００に「○○機能」は導入されていない。

ユーザbbbbは臨時的に２階の機器２００を使用することがあるため、２階の機器２００にログインした。上述したように、２階の機器２００は、機器２００に未登録であるユーザＩＤ「bbbb」とパスワードが入力された際、ユーザＩＤを管理サーバ７００に送信して、ユーザＩＤとパスワードを取得し、ライセンスサーバ４００にユーザＩＤを送信して紐つきライセンス情報を取得する。こうすることで、図１７（ｂ）に示すように、２階の機器２００のユーザ情報２１に、ユーザＩＤ（aaaa）、パスワード（12345）及び紐つきライセンス情報（○○機能）が登録される。

そして、上述したように、機能１２は○○機能を２階の機器２００に導入するので、機器構成情報２２には、○○機能の機能名、ライセンス形態及び有効期限が登録される。

しかしながら、２階の機器２００はあくまでユーザbbbbが臨時に使用する機器なので、○○機能を定常的に導入しておく必要はない。そこで、機器２００は削除するタイミングの設定をユーザbbbbから受け付ける。

図１８は、機能の自動削除の削除タイミングを設定する画面の一例を示す図である。機能導入部１２が機能を導入すると、削除タイミング受け付け部２７は自動削除のタイミングの設定をユーザbbbbに促す。まず、削除タイミング受け付け部２７は、自動削除するか否かをユーザbbbbに問い合わせる。

図１８の画面１には次のメッセージが表示されている。
「ログインに伴い、ユーザと紐づくライセンス有無を確認し紐付く機能があるにも関わらず本機器では未導入であったため、自動で導入しました。以下設定をお願いします。
・本ログインは臨時であり、一定期間（設定可）後に導入を解除（削除）
・導入した機能は削除しない
※臨時ログインの場合は詳細設定を行ったうえでの解除（削除）を推奨します。」
普段使用する機器１００とは違うが、それでも比較的頻繁に本機器２００を使用する予定がある場合などは、毎回利用後の削除、再ログイン時の自動導入の手間を避けるため、ユーザbbbbは「削除しない」を選択すればよい。この場合、自動導入された機能は削除されずに、ユーザbbbbがログアウト後に再ログインしてもすぐに「○○機能」を使用可能となる。

逆に、臨時ログインが頻繁ではないような場合は、ユーザbbbbはログアウト後、削除してもかまわないため、また、リソースを考慮した結果、「設定に従い削除」を選択する。

ユーザbbbbが、「設定に従い削除」を選択した場合、機器２００はどのタイミングで自動で導入した機能を削除するかの設定を受け付ける。削除タイミング受け付け部２７は、図１８の画面２を表示する。図１８の画面２では、「ログアウト後」「翌日（本日０時に削除）「詳細設定：日時／時間指定」からユーザがタイミングを選択できるようになっている。

ユーザbbbbにとって、「○○機能」を現ログイン中に利用できればよく、その後使用する予定がない場合、ユーザbbbbは「ログアウト後」を選択すればよい。こうすることで、ログアウト後にはすぐに機器２００のリソースを開放できる。

また、ユーザbbbbが機器２００を使用した日は終日、断続的に機器２００を使用する可能性があるような場合、ユーザは「ログアウト後」ではなく「翌日」を選択すればよい。「ログアウト後」を選択するとユーザbbbbがログインする度に機能が導入され、ログアウトする毎に機能が削除されるが、「翌日」を選択することで、導入と削除が繰り替えされることを防止できる。ユーザbbbbが「翌日」を選択した場合、機器２００は、機能を自動的に導入した日を超過した後、速やかに機能を削除する。

さらに、出張など複数日に渡って機器２００を臨時で使用する予定がある場合、ユーザbbbbは「詳細設定」を選択する。この場合、ユーザは別画面として表示される画面から、日付と時刻指定することが可能になる。

ユーザが選択すると画面が変わり、削除タイミング受け付け部２７は図１８の画面３を表示する。画面３には「削除設定が完了しました。指定されたタイミングで臨時導入した機能を削除します。

※なお、本機能に紐付くユーザが本機能にログインした場合、その際のログイン設定に従うため削除されない可能性もありますのでご注意願います。」というメッセージが表示される。「※なお」以下の文章が意味することについては後述する。

図１９は、削除タイミングを模式的に説明する図の一例である。図１８では、時間経過と複数の楕円が描かれている。各楕円は、導入された紐つきライセンスの機能が使用可能な期間を示す。

楕円１は、ユーザが「ログアウト後」を選択した場合に、導入された機能が使用可能な期間を示す。したがって、楕円１の終端は、ログアウト時を示す。楕円２は、ユーザが「翌日」を選択した場合に、導入された機能が使用可能な期間を示す。したがって楕円２の終端はその日（５月１８日）の終わりを示す。楕円３は、ユーザが「詳細設定」と日時を設定した場合に、導入された機能が使用可能な期間を示す。したがって楕円３の終端は、ユーザが設定した日時と時刻と一致する。

このように、本実施形態の機器２００は、ユーザ単位にライセンスするライセンス形態の機能を導入した後、ユーザの所望のタイミングで自動的に削除することができる。したがって、機器２００は自動的に機能を導入でき、導入後、リソースを占有したままにすることを防止できる。

〔複数人が同じ機能の紐つきライセンスを有している場合〕
これまでは、あるユーザが紐つきライセンスを有する機能について、他のユーザが紐つきライセンスを有するかどうかを考慮していなかった。しかし、複数のユーザが共通の機能について紐つきライセンスを有する場合、削除する必要がない場合や、一度設定された削除タイミングが変動する場合が生じうる。以下、説明する。

図２０は、複数のユーザが共通の機能の紐つきライセンスを有する場合の削除タイミングを説明する図の一例である。５月１８日の午前に、ユーザbbbbが機器２００にログインすることで、機器２００は○○機能を導入した。導入時、ユーザbbbbは、削除のタイミングとして「翌日」を選択した。よって、○○機能が削除されるタイミングは、５月１９日の午前０時である。

次に、ユーザppppが○○機能のライセンスを購入し、臨時的に機器２００を使用することになった。５月１８日の午後に、ユーザppppが機器２００にログインすると、機器２００のユーザ情報２１が更新され、ユーザppppには紐付きライセンス情報として「○○機能」が登録される。

ユーザppppのログインは、機器２００に○○機能が導入されるタイミングとなりうるが、ユーザppppがログインした５月１８日の午後の時点では、○○機能はまだ機器２００から削除されていないので、導入する必要はない。

この場合、ユーザppppが機器２００にログインすると、削除タイミング受け付け手段２７が図１８の画面から削除タイミングの設定を受け付ける。ユーザppppは、○○機能を削除するタイミングとして「詳細設定」を選択し、５月２１日の午前０時に設定した。

したがって、ユーザbbbbが設定した削除タイミング「５月１９日の午前０時」と、ユーザppppが設定した削除タイミング「５月２１日の午前０時」と、が異なる。

このように共通の機能について、設定された削除タイミングが異なる場合、機能削除部１８は最も遅い削除タイミングを優先する。こうすることで、機能を使用したいユーザが複数いる場合に、各ユーザが設定した削除タイミングで削除することを防止できる。図１８の画面３の「※なお」以下の文章はこのことを意味する。

さらに、５月１８日の午後、ユーザddddが、○○機能のライセンスを購入したとする。ユーザddddにとって、機器２００は普段から使用している機器である。５月１８日の午後に、ユーザddddが機器２００にログインすると、機器２００のユーザ情報２１が更新され、ユーザddddには紐付きライセンス情報として「○○機能」が登録される。この場合も同様に、機器２００に○○機能は導入されない（すでに導入されている）。

そして、ユーザddddは、機器２００を普段から使用しているので、図１８で「削除しない」を選択し、機能ｂｐを削除するタイミングを設定しなかった（削除して欲しくない）。

このように共通の機能について、削除を望まないユーザが存在する場合、機器２００は機能を削除しない。こうすることで、機能を使用したいユーザがいる場合に削除することを防止できる。上記の「※なお」以下の文章は、必ずしもユーザが設定したタイミングで、機能が削除されないことをことわるために表示される。

削除タイミング受け付け部２７は、複数のユーザの削除タイミングを調整するため、削除タイミングテーブル２６を記憶する。
図２１は削除タイミングテーブル２６の一例を示す図である。削除タイミングテーブル２６には、紐つきライセンス情報（機能名）に、各ユーザが設定した削除タイミングが登録されている。機能削除部１８は、削除タイミングテーブル２６を参照して、削除の有無、削除する場合の削除タイミングを決定する。

なお、削除タイミングが到来しても、ユーザがログインしている状態では機能削除部１８は機能を削除しない。こうすることで、設定された削除タイミングが到来しても、ユーザが機器２００を使用している間はユーザは機能を利用できる。

図２２は、機能削除部１８が自動導入した機能を自動削除する手順を示すフローチャート図の一例である。

まず、機能削除部１８は、削除タイミングテーブル２６に登録されたユーザＩＤのユーザがログアウトしたか否かを判定する（Ｓ４１０）。ユーザがログアウトしていない場合（Ｓ４１０のＮｏ）、機能を削除することは好ましくないので図２２の手順は終了する。

ユーザがログアウトした場合（Ｓ４１０のＹｅｓ）、機能削除部１８は削除タイミングテーブル２６に「削除しない」が登録されているか否かを判定する（Ｓ４２０）。「削除しない」が登録されている場合（Ｓ４２０のＹｅｓ）、機能を削除することができないので、図２２の手順は終了する。

「削除しない」が登録されていない場合（Ｓ４２０のＮｏ）、機能削除部１８は削除タイミングテーブル２６から最も遅い削除タイミングを読み出す（Ｓ４３０）。そして、機能削除部１８は削除タイミングテーブル２６から読み出した削除タイミングになったか否かを判定し（Ｓ４４０）、削除タイミングになると機能を削除する（Ｓ４５０）。

以上のような処理により、複数のユーザが共通の機能について紐つきライセンスを有していても場合、機能削除部１８が機能を削除するタイミングを適切に調整できる。

〔削除タイミングの通知〕
また、上記のように削除タイミングが設定された後に削除タイミングを調整するのでなく、削除タイミングの設定時に調整することもできる。すなわち、すでに削除タイミングが設定されている機能に対し、各ユーザが自由に削除タイミングを設定する前に、機能削除部１８が設定変更の意志を問い合わせる。こうすることで、すでに設定された削除タイミングを有効に活用し、また、削除タイミングをすでに設定したユーザの意図を優先することが可能になる。

図２３は、複数のユーザが共通の機能のライセンスを有する場合の削除タイミングを説明する図の一例である。図２３において図２０と同一部の説明は省略する。図２３において、各ユーザが○○機能を購入したり、望む削除タイミングの状況は図２０と同じである。

ユーザbbbbが削除タイミングを設定したことで、削除タイミングテーブル２６には削除タイミングテーブル２６が登録されている。
図２４（ａ）は削除タイミングテーブル２６の一例を示す。この時点では、ユーザbbbbの削除タイミングのみが登録されている。

図２３ではユーザppppが、機器２００にログインした際、表示される画面が図１８と異なる。ユーザppppがログインした時には、すでに機器２００に「○○機能」が導入されているので、画面には「○○機能」のアイコンが表示される。そのアイコンにはポップアップマーク２０１が隣接して表示されている。ユーザppppがポップアップマーク２０１を選択すると、その下の画面が表示される。

画面には「ログインユーザによって○○機能は導入済みですが、あくまで臨時導入として以下設定で○○機能は削除されます。５月１９日０時に削除」
本設定にて問題ない場合は「設定変更しない」を選択し、設定変更を行う場合は「設定変更する」を選択してください。」と表示されている。したがって、ユーザppppは、すでに設定された削除タイミングで不都合がなければ削除タイミングを設定することを回避し、すでに設定された削除タイミングで不都合があれば削除タイミングを再設定する。したがって、削除タイミングテーブル２６には最後に設定した、削除タイミングが有効な削除タイミングとして登録される。

ここで、削除タイミング受け付け部２７は、後から設定される削除タイミングを削除タイミングテーブル２６に登録してよいか否かを判定する。すなわち、ユーザbbbbが５月１９日の午前０時まで使用したいと思っているのに、ユーザppppが故意又は間違って５月１８日の午後６時を削除タイミングとすることを認めると、ユーザbbbbが削除タイミングを設定した意義が薄れてしまう。

このため、削除タイミング受け付け部２７は、後から設定される削除タイミングがすでに設定されている削除タイミングよりも後の場合にのみ削除タイミングテーブル２６を更新する。図２３と同様に、ユーザppppが５月２１日の午前０時を削除タイミングに設定することで、削除タイミングテーブル２６は図２４（ｂ）に示すようになる。

また、更新の際、すでに設定されている削除タイミングは登録したままとすることが好適となる。すでに設定されている削除タイミングは、後から設定される削除タイミングが登録されるまでに限り有効であるが、仮に、ユーザppppが後から設定した削除タイミングを削除した場合、削除タイミングが１つもなくなってしまい、機能がリソースを圧迫するためである。したがって、図２４（ｂ）に示すように、削除タイミング受け付け部２７はすでに設定されている削除タイミングを無効化するが（カッコに囲まれる）、すでに設定されている削除タイミングを消去しない。

図２３でユーザddddが、機器２００にログインした際も、「○○機能」とポップアップマーク２０１が表示され、ユーザddddがポップアップマーク２０１を選択すると、図１８の画面１と同様に。「設定変更しない」ボタンと「設定変更する」ボタンが表示される。ユーザddddは削除して欲しくないので、「設定変更する」を選択すると考えられる。

削除タイミング受け付け部２７は、後から設定される削除タイミングが「設定変更しない」の場合、すでに設定されている日時の削除タイミングより優先して削除タイミングテーブル２６を更新する。したがって、削除タイミングテーブル２６は図２４（ｃ）に示すようになる。

図２５は、削除タイミングの設定時に削除タイミングが調整される場合に、機能削除部１８が機能を自動削除する手順を示すフローチャート図の一例である。

まず、削除タイミング受け付け部２７は、削除タイミングが設定されたか否かを判定する（Ｓ５１０）。削除タイミングが設定されない場合（Ｓ５１０のＮｏ）、処理はステップＳ５４０に進む。

削除タイミングが設定された場合（Ｓ５１０のＹｅｓ）、削除タイミング受け付け部２７は、後から設定される削除タイミングが、すでに設定されている削除タイミングよりも後、又は、「削除しない」が設定されたか否かを判定する（Ｓ５２０）。

後から設定される削除タイミングが、すでに設定されている削除タイミングよりも後、又は、「削除しない」が設定されていない場合（Ｓ５２０のＮｏ）、処理はステップＳ５４０に進む。

後から設定される削除タイミングが、すでに設定されている削除タイミングよりも後、又は、「削除しない」が設定されてる場合（Ｓ５２０のＹｅｓ）、削除タイミング受け付け部２７は、削除テーブルを更新する（Ｓ５３０）。

ついで、機能削除部１８は、削除タイミングテーブル２６に登録されたユーザＩＤのユーザがログアウトしたか否かを判定する（Ｓ５４０）。ユーザがログアウトしていない場合（Ｓ５４０のＮｏ）、機能を削除することは好ましくないので図２５の手順は終了する。

ユーザがログアウトした場合（Ｓ５４０のＹｅｓ）、機能削除部１８は削除タイミングテーブル２６に有効に登録された削除タイミングになった否かを判定する（Ｓ５５０）。

そして、機能削除部１８は削除タイミングになると（Ｓ５５０のＹｅｓ）、機能を削除する（Ｓ５６０）。

また、削除タイミング受け付け部２７は削除タイミングになるまで（Ｓ５５０のＮｏ）、削除タイミングテーブル２６から削除タイミングが消去されたか否かを判定する（Ｓ５７０）。

削除タイミングテーブル２６から削除タイミングが消去された場合（Ｓ５７０のＹｅｓ）、削除タイミング受け付け部２７は、削除された削除タイミングを除き最も削除タイミングが後の削除タイミングを有効にして削除タイミングテーブル２６を更新する（Ｓ５８０）。

以上のような処理により、複数のユーザが共通の機能について紐つきライセンスを有していても、ユーザの意図を反映させながら、機能削除部１８が機能を削除するタイミングを適切に調整できる。

実施例１では、自動導入した機能の削除タイミングとして、ログアウト時や設定日時をユーザが指定可能であることを説明した。この設定例は、いずれも日時による設定と同じである。しかし、削除タイミングは、ユーザは日時以外でも設定することが可能である。本実施例ではより多様な削除タイミングの設定について説明する。

図２６は、削除タイミングの設定を受け付ける画面の一例である。図２６において図１８と同じ画面の説明は省略する。図２６では画面２が図１８の画面２と異なっている。すなわち、図１８と比べ「機能の利用回数」「再起動後」「ユーザ情報連動」の３つが新たに選択可能になっている。

「機能の利用回数」は、ユーザが紐つきライセンスにてライセンスされた機能の起動回数を設定する画面を表示させるボタンである。ユーザは例えば「１０回」「２０回」などの回数を設定することができ、機能削除部１８は、機能の起動回数が設定された起動回数に等しくなると、ログアウトなどのタイミングで機能を削除する。

「再起動後」は、次回、機器２００が再起動したタイミングで、機能削除部１８が機能を削除するように削除タイミングを設定するためのボタンである。

「ユーザ情報連動」は、ユーザや管理者又は自動的にユーザ情報２１を削除した時（正確には、ユーザ情報２１を削除した後のログアウトなどのタイミング）を削除タイミングに設定するためのボタンである。機能が自動導入されるのは、ユーザ情報２１に紐つきライセンス情報が登録されているためなので、ユーザ情報２１が削除されれば機能を導入したままとする必要がないと考えられるからである。なお、ユーザ情報２１は、ユーザや管理者が意識的に削除することもできるし、ユーザ情報更新部１３が、所定期間ログインがないユーザのユーザ情報２１を削除することで削除される。

図２７は本実施例の削除タイミングテーブル２６の一例を示す図である。日時による設定と「機能の利用回数」等はどちらが時間的に後になるかの比較が困難である。このことは、図２３のように、削除タイミングテーブル２６の設定の受け付け時に削除タイミング受け付け部２７が判断する場合も同様である。このため、削除タイミング受け付け部２７は、ユーザが設定する全ての削除タイミングを削除タイミングテーブル２６に設定する。そして、機能削除部１８は削除タイミングテーブル２６の全ての条件が整った時に機能を削除する。

例えば、図２７では、ユーザbbbbが「５月１９日午前０時」に設定し、ユーザppppが「上限回数１０回」に設定し、ユーザeeeeが「再起動時」に設定し、ユーザffffが「ユーザ情報連動」に設定している。機能削除部１８は、これらの全ての条件が整うと○○機能を削除する。

図２８は、機能削除部１８が自動導入した機能を自動削除する手順を示すフローチャート図の一例である。

まず、機能削除部１８は、所定のサイクル時間毎に削除タイミングテーブル２６を読み出す（Ｓ６１０）。そして、削除タイミングテーブル２６に登録された削除タイミングの全ての条件が整ったか否かを判定する（Ｓ６２０）。全ての条件が整っていない場合（Ｓ６２０のＮｏ）、図２８の処理は終了する。

登録された削除タイミングの全ての条件が整った場合（Ｓ６２０のＹｅｓ）、機能削除部１８は、ユーザがログアウトしたか否かを判定する（Ｓ６３０）。そして、ユーザがログアウトした場合に（Ｓ６３０のＹｅｓ）、機能削除部１８は機能を削除する（Ｓ６４０）。

以上のように、本実施例の機器２００は、日時以外を削除タイミングを設定でき、より多様な削除タイミングの設定を受け付けることができる。

実施例１、２では遅い削除タイミングほど優先されるように機能を削除することができたが、普段、そのユーザが使用している機器２００であれば、ユーザは機能を削除しないことを望むと考えられる。このような場合にも、ユーザが図１８などで「削除しない」を選択することは煩わしい場合がある。

そこで、本実施例ではユーザが「削除しない」を選択することが不要な機器２００について説明する。

図２０にて説明した状況を利用する。ユーザbbbbとユーザppppは臨時的に機器２００を使用しているのに対し、ユーザddddは普段、機器２００を使用している。よって、機器２００には定常的にユーザddddのユーザ情報２１が登録されている。ユーザ情報更新部１３は、ログインしたユーザのユーザＩＤがユーザ情報２１に登録されていれば、ユーザ情報２１を更新しないので、機能削除部１８が更新の有無をユーザ情報更新部１３に問い合わせることでユーザddddが普段、ユーザddddが普段、機器２００を使用しているか否かを判定できる。または、ユーザ情報２１にユーザＩＤ等の登録日時を登録しておき、登録日時が所定以上前である場合に、機能削除部１８は、ユーザddddが普段、機器２００を使用していることを検出してもよい。

図２９は、機能削除部１８が削除タイミングテーブル２６を更新する手順を示すフローチャート図の一例であり、図３０は削除タイミングテーブル２６の遷移例を示す図である。なお、図２９の手順の前に、図１１により機能の導入の手順が行われており、図２９はステップＳ１２０の処理の一部に相当する。図２９の処理の前に図３０の削除タイミングテーブル２６には、すでにユーザbbbbとユーザppppが削除タイミングを設定している。

まず、ユーザddddがログインする（Ｓ７１０）。機能削除部１８は、このログインユーザが普段ログインするユーザが否かを判定する（Ｓ７２０）。判定方法は上記のとおりである。このログインユーザが普段ログインするユーザでない場合（Ｓ７２０のＮｏ）、機能削除部１８は何もしない。この場合は、図１８の画面が表示される。

普段ログインするユーザの場合（Ｓ７２０のＹｅｓ）、機能削除部１８はユーザＩＤに紐付けられた紐つきライセンスの機能があるか否かを判定する（Ｓ７３０）。ユーザＩＤに紐付けられた紐つきライセンスの機能がない場合（Ｓ７３０のＮｏ）、図２９の処理は終了する。

ユーザＩＤに紐付けられた紐つきライセンスの機能がある場合（Ｓ７３０のＹｅｓ）、機能削除部１８は、削除タイミングテーブル２６に「削除しない」という削除タイミングを設定する（Ｓ７４０）。これにより、削除タイミングテーブル２６は図３０の下側のようになる。

したがって、ユーザddddにとって普段使用している機器２００に紐つきライセンス情報の機能が導入されている場合、ユーザはログインするだけで、機能の削除を禁止できる。図３０の上側のように先に削除タイミングが設定されていても優先的に、削除を禁止できる。

〔「削除しない」の設定〕
本実施例で説明したように、普段、ユーザが使用している機器２００に機能が導入された場合、機能削除部１８は機能の削除を禁止できる。しかし、ユーザとしては普段、使用している機器２００でもあまり使用しない機能であれば、機能を削除してもよいと考えることがある。よって、機能削除部１８が、削除タイミングテーブル２６に「削除しない」という削除タイミングを設定するか否かは、ユーザが設定可能であること好ましい。

図３１（ａ）は、削除タイミングテーブル２６に「削除しない」という削除タイミングを設定するか否かをユーザが設定する画面の一例である。この画面には「紐つきライセンスの機能の自動削除を禁止しますか？」というメッセージと「はい」ボタンと「いいえ」ボタンが表示されている。

このような画面は、例えば初期設定画面に表示される項目からユーザ情報２１の変更を選択することで表示される。ユーザが「はい」ボタンを選択すると、ユーザ情報更新部１３は、ユーザ情報２１の「削除禁止」の設定をオンにする。

図３１（ｂ）はユーザ情報２１の一例を示す図である。このユーザ情報２１には「削除禁止」が登録可能になっている。「削除禁止」にオンが設定されたユーザＩＤのユーザに対しては、図２９のＳ７４０が実行されず、削除タイミングテーブル２６に「削除しない」が自動的に登録されないようになる。

図３２は、機能削除部１８が削除タイミングテーブル２６を更新する手順を示すフローチャート図の一例である。図３２において図２９と異なるのは、ステップＳ７３０の後、機能削除部１８がユーザ情報２１の「削除禁止」がオンになっているか否かを判定するステップである（Ｓ７３５）。

機能削除部１８は、「削除禁止」の設定を参照して、削除タイミングテーブル２６に「削除しない」を設定するか否かを判定する。すなわち、機能削除部１８は「削除禁止」がオンに設定されている場合（Ｓ７３５のＹｅｓ）、削除タイミングテーブル２６に「削除しない」という削除タイミングを設定し、「削除禁止」がオンに設定されていない場合（Ｓ７３５のＮｏ）、削除タイミングテーブル２６に「削除しない」という削除タイミングを設定しない。

このように、ユーザは「削除しない」という設定を自動で行うか否かを自分の好みに応じて設定することができる。

機能削除部１８が削除する際に、機能の削除がうまくいかない場合がある。例えば、機能の削除中に機器２００がジョブを実行した場合や、ログアウトせずに電源がオフされるような場合である。このような場合には、再度、機能削除部１８が削除を行うことが好ましい。また、削除するタイミングもユーザが設定できれば、ユーザは削除が可能と予想されるタイミングを設定できると考えられる。

図３３は、再削除のタイミングの設定を受け付ける画面の一例を示す。図３３では「再削除のタイミング」として「再起動後」と「一定時間後」のどちらか又は両方をユーザが選択できるようになっている。この画面は、例えば管理者が所定の操作により再削除タイミング受け付け部１９が表示させる。

「再起動後」は、機器２００が再起動したタイミングを、機能削除部１８が再度、機能を削除するタイミングに設定するためのボタンである。「一定時間後」は、削除が失敗してから、予め定められた時間が経過したタイミングを機能削除部１８が再度、機能を削除するタイミングに設定するためのボタンである。一定時間は、機器２００の出荷時に決まっているか、又は、管理者が設定することができる。なお、この一定時間は例えば「３０分」「１時間」等である。

再削除タイミング受け付け部１９は、削除タイミングテーブル２６に設定結果を登録しておく。したがって、機能削除部１８は、削除タイミングテーブル２６を参照するだけで、削除タイミングも再削除タイミングも検出できる。

図３４は、機能削除部１８が自動導入した機能を再度、削除する手順を示すフローチャート図の一例である。

まず、機能削除部１８は、削除タイミングテーブル２６を参照して再度の削除タイミングになったか否かを判定する（Ｓ８１０）。

再度の削除タイミングになった場合（Ｓ８１０のＹｅｓ）、機能削除部１８は、削除タイミングテーブル２６の全ての削除タイミングの条件が整っているか否かを判定する（Ｓ８３２）。全ての削除タイミングの条件が整っていない場合（Ｓ８２０のＮｏ）、機能を削除する必要がないので、図３４の手順は終了する。

全ての削除タイミングの条件が整っている場合（Ｓ８２０のＹｅｓ）、機能削除部１８は、機能が削除されていないか否かを判定する（Ｓ８３０）。すなわち、機能削除部１８は、機器構成情報２２を参照して、全ての削除タイミングの条件が整った削除タイミングテーブル２６の機能が、機器構成情報２２に残っているか否かを判定する。

機能が削除されていない場合（Ｓ８３０のＹｅｓ）、機能削除部１８は、削除タイミングが超過した機能を削除する（Ｓ８４０）。こうすることで、機能削除部１８は、１、２回、削除に失敗しても必ず機能を削除できる。

本実施例の機器２００によれば、削除タイミングが到来した機能を確実に削除することで、リソースを開放することができる。

実施例１〜４では、削除タイミングテーブル２６を参照して削除するタイミングを決定して、機能を削除する機器について説明したが、本実施例では削除タイミングテーブル２６が不要となる機器について説明する。

ある瞬間には一台の機器２００しかユーザが操作しないと考えれば、一つの機能は一台にだけ導入されていれば十分であることになる。そこで、本実施例では、他の機器１００にログインしたタイミングで、ログイン機でない機器２００の機能削除部１８が機能を削除することとする。

図３５は、他機へのログインを削除タイミングとする機器２００の動作を模式的に説明する図の一例である。
（１）機器１００にはすでに○○機能が導入されている。
（２）ユーザは機器２００にログインする。
（３）機器２００は機器１００に同報的にログインを通知する。
（４）機器１００は、ログインによりユーザが機器２００にログインしたことを検出し、○○機能を削除する。このとき、機器１００で他に○○機能を使用しているユーザがいる場合は、機能削除部１８は○○機能を削除しない。また、ユーザが機器１００を普段使用している場合、○○機能を削除しないように制限することも有効である。
（５）機器２００は、○○機能が導入されていなければ、○○機能を導入する。
（６）ユーザは機器２００での作業を終え、機器１００にログインする。
（７）機器１００は機器２００に同報的にログインを通知する。
（８）機器２００は、ログインによりユーザが機器１００にログインしたことを検出し、○○機能を削除する。このとき、機器２００で他に○○機能を使用しているユーザがいる場合は、機能削除部１８は○○機能を削除しない。また、ユーザが機器２００を普段使用している場合、○○機能を削除しないように制限することも有効である。

したがって、ユーザは機器２００に機能を導入する際、削除タイミングを設定する必要がなく、削除タイミングテーブル２６も不要になる。

図３６は、機能削除部１８が、機能を削除する手順を示すフローチャート図の一例である。
まず、ユーザがログインすると、ユーザ認証部１１はユーザのログインを受け付ける（Ｓ９１０）。認証が成立すると、ログイン通知部１７はログイン通知をネットワーク上に同報的に送信する（Ｓ９２０）。ログイン通知にはログインしたユーザのユーザＩＤが含まれる。

機能削除部１８は、ネットワークを介して接続された他機からログイン通知を受信したか否かを監視している（Ｓ９３０）。

ログイン通知を受信した場合（Ｓ９３０のＹｅｓ）、機能削除部１８は、ログイン通知に含まれるユーザＩＤがユーザ情報２１に登録されており、かつ、紐つきライセンス情報が登録されているか否かを判定する（Ｓ９４０）。

ユーザＩＤがユーザ情報２１に登録されていなかったり、又は、紐つきライセンス情報が登録されていない場合（Ｓ９４０のＮｏ）、機能を削除する必要はない。

ログイン通知に含まれるユーザＩＤがユーザ情報２１に登録されており、かつ、紐つきライセンス情報が登録されている場合（Ｓ９４０のＹｅｓ）、機能削除部１８は、そのユーザＩＤの紐つきライセンス情報に登録された機能名を全て読み出す（Ｓ９５０）。

そして、機能削除部１８は、機能名が他のユーザのユーザＩＤに対応づけて登録されているか否かを判定する（Ｓ９６０）。他のユーザＩＤに機能名が登録されていることは、そのユーザが機能を使用する可能性があることを意味するので、削除することは好ましくないためである。

機能削除部１８は、機能名が他のユーザのユーザＩＤに対応づけて登録されていない機能のみを、機能記憶部２３から削除する（Ｓ９７０）。削除したら、機能削除部１８は、機器構成情報２２を更新する（Ｓ９８０）。

以上のように、本実施例の機器２００は、ユーザに削除タイミングの設定を要求することなく、機能を削除することができる。臨時的に機器２００にユーザがログインした場合、機器１００にログインしなければ、機器２００の機能は削除されないので、短時間でも、出張の間の２〜３日でも、ユーザは機能を利用できる。

＜変形例＞
本実施例では削除タイミングテーブル２６を不要にすることができると説明したが、実施例１〜４と同様に削除タイミングテーブル２６を用いることもできる。この場合、ユーザがログイン通知を削除タイミングに設定できるよう、削除タイミングの設定を受け付ける画面において、「ログイン通知」が表示される。

図３７は、削除タイミングの設定を受け付ける画面の一例である。図３７において図２６と同じ画面の説明は省略する。図３７では画面２が１８の画面２と異なっており、「ログイン通知時」が新たに選択可能になっている。

ユーザがログイン通知時を選択した場合、削除タイミング受け付け部２７は削除タイミングテーブル２６に、「ログイン通知時」と登録する。機能削除部１８は、他の機器１００からログイン通知を受信した場合、他のユーザが設定した日付、上限起動回数及びユーザ情報連動、の全てが満たされた場合に、機能を削除する。削除の手順は例えば図２８に示したとおりである。

実施例１〜５では、ユーザが「削除しない」を選択できるとして説明した。しかしながら、多くのユーザが「削除しない」を選択すると、臨時にしか使用しないにもかかわらず、無駄にリソースを使用することになる。そこで、本実施例では、ユーザが「削除しない」を選択した場合でも、導入可能な機能の数を制限する機器２００について説明する。

しかしながら、その一方、ユーザがよく使用する機器２００に機能を導入する際は、導入可能な機能の数を制限すべきでなく、あくまでユーザが臨時的に使用する機器２００に機能を導入する際だけ、機能の導入を制限すべきであると考えられる。以上から、本実施例では、臨時的に使用する機器２００にユーザが機能を導入する際だけ、導入可能な機能の数を制限する機器２００について説明する。

図３８は、機器システム６００の概略を説明する図の一例である。ユーザが機器２００にログインしたため、機器２００はユーザが紐つきライセンスとして有する○○機能の導入を開始する。

まず、機器２００は機器システム６００の他の機器１００Ａ〜１００Ｃに、○○機能を臨時的に導入しているか否かを問い合わせる。図では機器１００Ａと１００Ｃが臨時的に○○機能を有しており、機器１００Ｂは有していない。このため、機器システム６００全体の○○機能の保有数は２個である。

ここで、機器システム６００の機器には、１つの機能の臨時的な導入の上限の導入数である上限数が共通に設定されている。図では上限数は３個である。よって、機器２００は機能の臨時的な導入数が上限数未満であると判定して、機器２００に○○機能を導入すると決定する。したがって、機器システム６００は、機器システム６００全体の臨時的に導入される機能の数を制限することができる。

また、機器２００は、機器システム６００の他の機器１００Ａ〜１００Ｃに、ユーザＩＤを送信して、該ユーザのログイン数を問い合わせる。機器１００Ａ〜１００Ｃはログインするユーザの履歴をログに記録するので、このユーザの過去の１年程度のログイン数を機器２００に送信する。

機器２００は自機のログイン数もログから抽出することで、機器２００が、ユーザが臨時的に使用する機器か否かを判定することができる。機器２００は、例えば、自機２００よりも所定値以上、ログイン数の大きい機器１００Ａ〜１００Ｃがある場合、機器２００をユーザが臨時的に使用する機器であると判定する。

または、ユーザが機能を「削除しない」を選択した場合、その機器２００はユーザがよく使用する機器の可能性が高いので、ユーザが機能を「削除しない」と設定した場合、その機器をユーザが臨時的に使用する機器でないと判定することもできる。

図３９（ａ）は、機器システム６００に導入可能な機能を数の設定を受け付ける画面の一例を示す。このような図面は、管理者が所定の操作を入力することで、上限数受け付け部２５が表示する。図では「機器システム全体に導入可能な１つの機能の上限数を設定して下さい。」というメッセージと、２種類の機能数の設定欄が表示されている。

管理者は数値として「機器システム全体に導入可能な１つの機能の上限数」を設定することもできるし、ネットワークに接続された「機器の数×ｎ（自然数）」のように設定することもできる。後者の場合、ネットワークに接続された機器１００，２００の数が多いほど、導入可能な機能の数も多くなるべきなので、ユーザが機器１００，２００の数をカウントすることなく適切な導入可能な機能の数を設定できる。

図３９（ａ）で設定された上限数は、各機器において共通であるべきなので、上限数が設定された上限数受け付け部２５は、上限数を同報的に他の機器に送信し、各機器の上限数受け付け部２５が同じ上限数をＨＤＤ１１３等に保持する。

図３９（ａ）の画面には「削除する機能の選択」ボタンが表示されている。管理者が「削除する機能の選択」ボタンを押下すると、図３９（ｂ）の画面が表示される。機能削除部１８は、この画面から削除する機能の選択方法の設定を受け付ける。なお、いずれも臨時的に導入されている機能のみが削除の対象となる。

機能削除部１８は以下のいずれかの選択方法に従い削除する機能を決定する。
（ａ）他機器ですでに導入されている機能の中で、最も古く導入された機能
（ｂ）他機器ですでに導入されている機能の中で、利用頻度が最も低い機能
（ｃ）他機器ですでに導入されている機能の中から、削除する機能をユーザが選択する
管理者は、（ａ）〜（ｃ）の３つの選択方法から、所望の選択方法を選択することができる。選択画面には上記（ａ）〜（ｃ）のそれぞれに対応づけて「はい」ボタンと「いいえ」ボタンが表示されている。

機能削除部１８は、管理者の選択を受け付けて記憶するとともに、選択方法を同報的に他の機器に送信し、各機器の機能削除部１８が同じ選択方法をＨＤＤ等に保持する。こうすることで、各機器において削除する機能の選択方法を共通にすることができる。

図４０は、本実施例の機器構成情報２２の一例を示す。（ａ）（ｂ）の選択方法に対応するため、各機器は、機器構成情報２２に「導入日時」「過去一年の利用頻度」が登録されている。各機器は、機能を導入した際に「導入日時」を登録し、起動部１６は機能を起動する毎に「過去一年の利用頻度」をカウントアップする。

また、本実施例では、ユーザが臨時的に機器２００を使用する際に、すでに導入されている機能の数を上限数と比較するので、臨時的に導入された機能の数をカウントすることが好ましい。このため、機器構成情報２２には、各機能が「臨時導入」が否かが登録されている。

各機器２００，１００Ａ〜１００Ｃは、ログインしたユーザが臨時的に自機を使用する場合に、導入した機能の「臨時導入」に「※」を登録する。これにより、各機器２００，１００Ａ〜１００Ｃは導入されている機能のうち臨時的に導入されている機能を特定できる。なお、各機器で一人でも機能を臨時的でなく使用しているユーザがいる場合、「臨時導入」に「※」は登録されない。

図４１は、機能の削除の手順を説明するフローチャート図の一例である。この手順は、図１１の「機能の自動導入」の手順のステップＳ１００の直前に実行される。なお、機能を導入する際に実行されればよいので、機能導入時であれば自動導入か手動導入かに関係なく実行されることができる。

まず、機能を導入する前、機能削除部１８は、他機から導入する対象の機能の導入数を算出するため、他機１００Ａ〜１００Ｃに臨時的に導入されている機能の導入数及びログインしたユーザのログイン数を問い合わせる（Ｓ１０１０）。他の機器１００Ａ〜１００Ｃは、機器構成情報２２を参照して、導入対象の機能が臨時的に導入されていれば「１」を、及び、ユーザのログイン数を機器に送信する。

次に、機能削除部１８は、ログイン数に基づき、機器２００がユーザが臨時的にログインした機器か否かを判定する（Ｓ１０２０）。機器２００が、ユーザが臨時的にログインした機器でない場合（Ｓ１０２０のＮｏ）、機能の導入を制限する必要はないので図４１の処理は終了する。この後、図１１のステップＳ１００に従い機能が導入される。

機器２００がユーザが臨時的にログインした機器の場合（Ｓ１０２０のＹｅｓ）、機能の導入数を制限するため、機能削除部１８は全ての他機から受信した数を合計する（Ｓ１０２５）。

機能削除部１８は、合計した数が上限数に達しているか否かを判定する（Ｓ１０３０）。

上限数に達していない場合（Ｓ１０３０のＮｏ）、機能を削除する必要がないので、図４１の手順は省略する。この後、図１１のステップＳ１００に従い機能が導入される。

上限数に達している場合（Ｓ１０３０のＹｅｓ）、機能を削除するため、機能削除部１８は設定されている削除対象の機能の選択方法を読み出す（Ｓ１０４０）。削除対象の機能の選択方法が上記（ｃ）の場合、機能削除部１８は、ステップＳ１０１０で取得した、対象機器の機能が導入されている他機１００Ａ、１００Ｃの一覧をオペレーションパネルに表示して、ユーザの選択を受け付ける。

削除対象の機能の選択方法が上記（ａ）の場合、機能削除部１８は、対象機器の機能が導入されている他機１００Ａ、１００Ｃに、「導入日時」を問い合わせ、（ｂ）の場合、機能削除部１８は、削除対象の機能が導入されている他機１００Ａ、１００Ｃに、「利用頻度」を問い合わせる（Ｓ１０５０）。なお、自機の機器構成情報２２も比較対象である。

そして、問い合わせた結果から、最も「導入日時」が古い他機の機能、又は、最も「利用頻度」が低い機能を有する他機を、機能を削除する他機に決定する（Ｓ１０６０）。なお、（ｃ）の場合、削除する他機の機能はユーザの選択により特定されている。

次に、機能削除部１８は、機能を削除する他機に、機能の削除を要求する（Ｓ１０７０）。これにより、他機の機能削除部１８は機能を削除することができる。この後は、図１１のステップＳ１００に従い機能が導入される。

以上説明したように、本実施例の機器は、ユーザが「削除しない」を選択する機会が多くても、導入可能な機能の数を制限することができる。

１１ ユーザ認証部
１２ 機能導入部
１３ ユーザ情報更新部
１５ 画面生成部
１６ 起動部
１７ ログイン通知部
１８ 機能削除部
１９ 再削除タイミング受け付け部
２１ ユーザ情報
２２ 機器構成情報
２３ 機能記憶部
２４ 部品記憶部
２５ 上限数受け付け部
２６ 削除タイミングテーブル
２７ 削除タイミング受け付け部
１００、２００ 機器
３００ 販売サーバ
４００ ライセンスサーバ
５００ ネットワーク
６００ 機器システム
７００ 管理サーバ

特開２００８−０４７０５６号公報

Claims (23)

1. 機能を実現するプログラムの起動が、プログラムの正当利用者であることを示すライセンス情報により認められる画像形成装置であって、
   ユーザのログインを受け付けるログイン受け付け手段と、
   プログラムを記憶するプログラム記憶手段と、
   ユーザ個人にライセンスされたプログラムとライセンス情報を外部から取得し、前記プログラム記憶手段に記憶する機能導入手段と、
   ユーザＩＤに対応づけて前記機能導入手段が記憶したプログラムのライセンス情報が登録されたユーザ情報を記憶するユーザ情報記憶手段と、
   前記機能導入手段が記憶したプログラムが前記プログラム記憶手段から削除される削除タイミングの設定を受け付ける削除タイミング受け付け手段と、
   前記削除タイミング受け付け手段が受け付けた削除タイミングが到来した場合に、前記機能導入手段が前記プログラム記憶手段に記憶したプログラムを削除する削除手段と、を有し、
   前記削除タイミング受け付け手段は、ネットワークを介して接続された他の機器へのユーザのログイン時を削除タイミングの設定として受け付け、
   前記削除手段は、前記他の機器からログインしたユーザのユーザＩＤを受信した場合、該ユーザＩＤに対応づけられていたプログラムを前記プログラム記憶手段から削除する、
   ことを特徴とする画像形成装置。
2. 前記削除タイミング受け付け手段は、日時にて指定された削除タイミングの設定を受け付ける、ことを特徴とする請求項１記載の画像形成装置。
3. 前記削除タイミング受け付け手段は、ユーザがログアウトしたタイミングを削除タイミングの設定として受け付ける、ことを特徴とする請求項１記載の画像形成装置。
4. 前記削除タイミング受け付け手段は、前記削除手段により前記プログラム記憶手段からプログラムを削除しないという設定を受け付ける、ことを特徴とする請求項１記載の画像形成装置。
5. 前記削除タイミング受け付け手段は、プログラムの起動回数の上限数を削除タイミングの設定として受け付け、
   前記削除手段は、プログラムの起動回数が前記上限数を超えた場合に、前記プログラム記憶手段に記憶されたプログラムを削除する、
   ことを特徴とする請求項１記載の画像形成装置。
6. 前記削除タイミング受け付け手段は、当該画像形成装置の再起動時を削除タイミングの設定として受け付け、
   前記削除手段は、当該画像形成装置の起動時、前記プログラム記憶手段に記憶されたプログラムを削除する、ことを特徴とする請求項１記載の画像形成装置。
7. 前記削除タイミング受け付け手段は、前記ユーザ情報からのユーザＩＤの削除時を削除タイミングの設定として受け付け、
   前記削除手段は、前記ユーザ情報からユーザＩＤが削除された場合、該ユーザＩＤに対応づけられていたプログラムを前記プログラム記憶手段から削除する、
   ことを特徴とする請求項１記載の画像形成装置。
8. 前記削除タイミング受け付け手段が異なる削除タイミングの設定を受け付けた場合、前記削除手段は、全ての削除タイミングが成立した時、プログラムを前記プログラム記憶手段から削除する、ことを特徴とする請求項１〜７いずれか１項記載の画像形成装置。
9. 前記削除手段は、前記削除タイミングが設定されたプログラムが、前記ユーザ情報に所定期間以上前から登録されているユーザＩＤに対応づけられたプログラムと同じ場合、
   前記削除タイミング受け付け手段が削除タイミングを受け付けても、前記削除タイミングが設定されたプログラムを前記プログラム記憶手段から削除しない、
   ことを特徴とする請求項１〜８いずれか１項記載の画像形成装置。
10. 前記削除タイミング受け付け手段は、前記ユーザ情報に所定期間以上前から登録されているユーザＩＤに対応づけられたプログラムを削除するか否かの設定を受け付ける、
    ことを特徴とする請求項９記載の画像形成装置。
11. 前記削除手段は、前記削除タイミングが到来してもプログラムが削除されていない場合、当該画像形成装置の起動時に、前記削除タイミングがすでに到来しているプログラムを削除する、ことを特徴とする請求項１〜１０いずれか１項記載の画像形成装置。
12. 前記削除手段は、前記削除タイミングが到来してもプログラムが削除されていない場合、一定時間の経過後に、前記削除タイミングがすでに到来しているプログラムを削除する、ことを特徴とする請求項１〜１０いずれか１項記載の画像形成装置。
13. 前記削除タイミングが到来してもプログラムが削除されていない場合に、前記削除手段が再度の削除を実行する再削除タイミングの設定を受け付ける再削除タイミング受け付け手段を有する、ことを特徴とする請求項１１又は１２記載の画像形成装置。
14. 前記削除手段は、ネットワークを介して接続された他の機器に導入対象のプログラムの導入数を問い合わせ、ネットワークを介して接続された他の機器に導入されているプログラムの合計数が、予め設定されている上限数以上の場合、前記他の機器のいずれかにプログラムの削除を要求する、
    ことを特徴とする請求項１〜１３いずれか１項記載の画像形成装置。
15. 前記上限数の設定を受け付ける上限数受け付け手段を有する、ことを特徴とする請求項１４記載の画像形成装置。
16. 前記削除手段は、前記他の機器から導入対象のプログラムの導入日時を問い合わせ、最も古い導入日時を送信した前記他の機器にプログラムの削除を要求する、
    ことを特徴とする請求項１４又は１５記載の画像形成装置。
17. 前記削除手段は、前記他の機器から導入対象のプログラムの利用頻度を問い合わせ、最も低い利用頻度を送信した前記他の機器にプログラムの削除を要求する、ことを特徴とする請求項１４又は１５記載の画像形成装置。
18. 前記削除手段は、プログラムの削除を要求する前記他の機器の選択をユーザから受け付ける、ことを特徴とする請求項１４又は１５記載の画像形成装置。
19. 前記削除手段は、プログラムの削除を要求する前記他の機器の選択を、プログラムの導入日時が最も古い機器、プログラムの利用頻度が最も低い機器、又は、ユーザ選択、の中から受け付ける、ことを特徴とする請求項１４又は１５記載の画像形成装置。
20. 前記削除手段は、ネットワークを介して接続された他の機器に導入対象のプログラムが臨時的に導入されている導入数を問い合わせ、
    ユーザが当該画像形成装置を前記他の機器と比べ臨時的に使用する場合、かつ、導入数の合計数が、予め設定されている上限数以上の場合、前記他の機器のいずれかにプログラムの削除を要求する、
    ことを特徴とする請求項１４〜１９いずれか１項記載の画像形成装置。
21. 機能を実現するプログラムの起動が、プログラムの正当利用者であることを示すライセンス情報により認められる画像形成装置と、プログラムとライセンス情報を画像形成装置に配信するサーバと、を有する機器システムであって、
    前記サーバは、
    ライセンス情報にユーザＩＤが対応づけられたライセンス管理情報、を有し、
    前記画像形成装置は、
    ユーザのログインを受け付けるログイン受け付け手段と、
    プログラムを記憶するプログラム記憶手段と、
    ユーザ個人にライセンスされたプログラムとライセンス情報を外部から取得し、前記プログラム記憶手段に記憶する機能導入手段と、
    ユーザＩＤに対応づけて前記機能導入手段が記憶したプログラムのライセンス情報が登録されたユーザ情報を記憶するユーザ情報記憶手段と、
    前記機能導入手段が記憶したプログラムが前記プログラム記憶手段から削除される削除タイミングの設定を受け付ける削除タイミング受け付け手段と、
    前記削除タイミング受け付け手段が受け付けた削除タイミングが到来した場合に、前記機能導入手段が前記プログラム記憶手段に記憶したプログラムを削除する削除手段と、を有し、
    前記削除タイミング受け付け手段は、ネットワークを介して接続された他の機器へのユーザのログイン時を削除タイミングの設定として受け付け、
    前記削除手段は、前記他の機器からログインしたユーザのユーザＩＤを受信した場合、該ユーザＩＤに対応づけられていたプログラムを前記プログラム記憶手段から削除する、ことを特徴とする機器システム。
22. 機能を実現するプログラムの起動が、プログラムの正当利用者であることを示すライセンス情報により認められる画像形成装置のプログラム管理方法であって、
    ログイン受け付け手段が、ユーザのログインを受け付けるステップと、
    機能導入手段が、ユーザ個人にライセンスされたプログラムとライセンス情報を外部から取得し、プログラム記憶手段に記憶するステップと、
    ユーザ情報更新手段が、前記機能導入手段が記憶したプログラムのライセンス情報を、ユーザＩＤに対応づけてユーザ情報記憶手段のユーザ情報に記憶するステップと、
    削除タイミング受け付け手段が、前記機能導入手段が記憶したプログラムが前記プログラム記憶手段から削除される削除タイミングとして、ネットワークを介して接続された他の機器へのユーザのログイン時を削除タイミングの設定として受け付けるステップと、
    削除手段が、前記削除タイミング受け付け手段が受け付けた削除タイミングとして、前記他の機器からログインしたユーザのユーザＩＤを受信した場合、該ユーザＩＤに対応づけられていたプログラムを前記プログラム記憶手段から削除するステップと、を有することを特徴とするプログラム管理方法。
23. 機能を実現するプログラムの起動が、プログラムの正当利用者であることを示すライセンス情報により認められる画像形成装置が実行するプログラムであって、
    画像形成装置に、
    ユーザのログインを受け付けるログイン受け付けステップと、
    ユーザ個人にライセンスされたプログラムとライセンス情報を外部から取得し、プログラム記憶手段に記憶する機能導入ステップと、
    前記機能導入ステップにより記憶されたプログラムのライセンス情報を、ユーザＩＤに対応づけてユーザ情報記憶手段のユーザ情報に記憶するユーザ情報更新ステップと、
    前記機能導入ステップにより記憶されたプログラムが前記プログラム記憶手段から削除される削除タイミングとして、ネットワークを介して接続された他の機器へのユーザのログイン時を削除タイミングの設定として受け付ける削除タイミング受け付けステップと、
    前記削除タイミング受け付けステップにより受け付けられた削除タイミングとして、前記他の機器からログインしたユーザのユーザＩＤを受信した場合、該ユーザＩＤに対応づけられていたプログラムを前記プログラム記憶手段から削除する削除ステップと、
    を実行させるプログラム。

Images