JP2022045324A - 情報処理装置、サービス提供システム、方法およびプログラム - Google Patents

Abstract

【課題】各アプリケーションの実行回数に応じたプランを提案する情報処理装置、システム、方法及びプログラムを提供する。【解決手段】ユーザ環境に配置される１以上の画像形成装置と、サービス提供環境に配置される情報処理装置とが、ネットワークを通じて１以上の画像形成装置と連携して動作するサービス提供システムにおいて、情報処理装置は、契約内容の変更を提案する装置であって、複数のアプリケーションを利用する契約において、実行したアプリケーションの情報を蓄積する蓄積手段として機能するアプリ実行時データ蓄積データベース７２と、蓄積した各アプリケーションの情報から得られる各アプリケーションの実行回数に応じて、契約内容の変更を提案する提案部８１と、を含む。【選択図】図４

Description

本発明は、契約内容の変更を提案する情報処理装置、サービス提供システム、方法およびその提案する処理をコンピュータに実行させるためのプログラムに関する。

ＭＦＰ(Multi-Function Peripheral)等の機器には、クラウドサービスと連携し、スキャンした文書の配信や保存した文書の印刷等のサービスを提供できる機器がある。サービスとして提供する機能は、アプリケーションにより実現され、アプリケーションの利用に関して料金プランが設定される。ユーザは、設定された料金プランを選択し、選択した料金プランで契約を結び、契約内容に従ってアプリケーションを利用することができる。

アプリケーションの利用状況等によっては契約した料金プランより安いプランがある場合があり、ユーザにそのプラン内容を提案できれば、ユーザの満足度を向上させることができる。

契約内容の変更を提案する技術として、ＡＰＩ(Application Programming Interface)の呼び出し回数をカウントし、呼び出し回数の上限数に到達した場合に、呼び出し回数の上限数加算を選択するＵＩ(User Interface)を表示する技術が知られている（例えば、特許文献１参照）。

しかしながら、上記の技術では、複数のアプリケーションをまとめてプラン（パッケージ）としてユーザに提供する構成において、各アプリケーションの実行回数に応じて、別のプランを提案することができないという問題があった。

本発明は上述した課題を解決するものであり、各アプリケーションの実行回数に応じたプランを提案することができる情報処理装置、サービス提供システム、方法およびプログラムを提供することを目的とする。

本発明によれば、契約内容の変更を提案する情報処理装置であって、
複数のアプリケーションを利用する契約において、実行したアプリケーションの情報を蓄積する蓄積手段と、
蓄積された各アプリケーションの情報から得られる各アプリケーションの実行回数に応じて、契約内容の変更を提案する提案手段と
を含む、情報処理装置を提供する。

本発明によれば、各アプリケーションの実行回数に応じたプランを提案することが可能となる。

サービス提供システムの構成例を示した図。 画像形成装置のハードウェア構成の一例を示した図。 情報処理装置のハードウェア構成の一例を示した図。 情報処理装置の機能構成の一例を示したブロック図。 データ蓄積処理の流れを示したシーケンス図。 アプリ実行時データ蓄積データベースに蓄積される情報の一例を示した図。 料金プランの提案頻度等を設定する画面の一例を示した図。 ユーザ・デバイスライセンス料金データベースに登録されるユーザライセンス料金プランの一例を示した図。 ユーザ・デバイスライセンス料金データベースに登録されるデバイスライセンス料金プランの一例を示した図。 アプリケーション毎の実行回数の一例を示した図。 アプリケーションＡのユーザ毎の実行回数の一例を示した図。 ユーザ数を減らした料金プランを提案する処理の流れを示したフローチャート。 デバイスライセンス契約への切り替えを提案する画面の一例を示した図。 アプリを減らした料金プランを提案する処理の流れを示したフローチャート。 ユーザ数を減らした料金プランを提案する処理の流れを示したフローチャート。 ユーザライセンス契約がテナントに紐付く場合の契約内容の変更を提案する画面の一例を示した図。 パッケージ、アプリを減らせる場合の契約内容の変更を提案する画面の一例を示した図。 料金の比較について説明する図。 デバイスライセンス契約を提案する画面の一例を示した図。 ユーザライセンス契約を提案する画面の一例を示した図。 アプリケーションを削除する理由を作成する処理の一例を示したフローチャート。 理由を併記しないでアプリケーションの削除を提案する画面の一例を示した図。 理由を併記してアプリケーションの削除を提案する画面の一例を示した図。 ユーザ数削減理由を作成する処理の一例を示したフローチャート。 理由を併記してユーザの削減を提案する画面の一例を示した図。 理由を併記してゲストユーザの削減を提案する画面の一例を示した図。

以下、本発明について実施形態をもって説明するが、本発明は後述する実施形態に限定されるものではない。

図１は、サービス提供システムの構成例を示した図である。サービス提供システムは、ユーザ環境Ｅ１に配置される１以上の画像形成装置１０と、サービス提供環境Ｅ２に配置される情報処理装置１１とを含む。１以上の画像形成装置１０と、情報処理装置１１とは、インターネット等のネットワーク１２により接続され、ネットワーク１２を介して通信を行う。情報処理装置１１は、ネットワーク１２を通じて１以上の画像形成装置１０と連携して動作する。

ここでは、ユーザ環境Ｅ１に配置される機器を、ＭＦＰ等の画像形成装置１０として説明するが、情報処理装置１１と連携して動作する機器としては、通信機能を備えた装置であれば画像形成装置１０に限定されるものではない。機器は、例えば、ＰＪ(Projector：プロジェクタ)、ＩＷＢ(Interactive White Board：相互通信が可能な電子式の黒板機能を有する白板)、産業機械、撮像装置、集音装置、医療機器、ネットワーク家電、自動車(Connected Car)、ノートＰＣ(Personal Computer)、携帯電話、スマートフォン、タブレット端末、ゲーム機、ＰＤＡ(Personal Digital Assistant)、ウェアラブルＰＣ、デスクトップＰＣ等であってもよい。

画像形成装置１０は、スキャン機能、コピー機能、印刷機能、ファックス送受信機能、通信機能等の複数の機能を備え、画像形成を行う機器である。画像形成装置１０は、ユーザの入力を受け付け、処理の状況やエラー等を表示する操作部と、各機能を実現する画像形成部とを備える。画像形成装置１０は、Ｗｅｂブラウザを使用して情報処理装置１１にアクセスし、情報処理装置１１に実装される各種のアプリケーション（以下、アプリと略す。）を実行し、各機能を実現する。

情報処理装置１１は、Ｗｅｂサーバを実装する機器で、画像形成装置１０と通信を行い、各種のアプリの処理を実行し、ユーザに対してサービスを提供する。アプリの処理としては、クラウドストレージの特定のディレクトリへのファイル保存やデータの読み出し、特定の配信先へのデータ配信等を挙げることができる。なお、これらの処理は一例であるので、アプリの処理はこれらに限定されるものではない。

情報処理装置１１は、アプリを利用するユーザを、テナントと呼ばれる単位で管理する。テナントには、１人または複数のユーザが所属可能である。テナントには、アプリを登録することができるが、アプリを直接テナントに登録することはできない。アプリは、パッケージと呼ばれる単位でまとめられてテナントに登録される。パッケージは、１つ、または複数のアプリをまとめたものである。したがって、パッケージは、１つのアプリで構成することもできるし、複数のアプリで構成することもできる。

パッケージは、無料のパッケージと有料のパッケージがあり、有料パッケージには月額・年額課金等の料金プランがあり、デバイス毎に契約することが可能である。パッケージは、ユーザライセンス毎に契約することも可能である。デバイス毎の課金では、利用可能なデバイス数が設定され、ユーザライセンス毎の課金では、利用可能なユーザ数が設定されている。顧客は、有料パッケージを利用するにあたって、デバイス毎にするか、ユーザライセンス毎にするかを、料金プランを考慮して利用契約を結ぶことができる。顧客は、契約を結ぶ対象であり、個人のユーザであってもよいし、複数のユーザに使用させる会社等であってもよい。

ユーザは、パッケージを利用するにあたって、画像形成装置１０に、契約時に定めたユーザ情報を入力し、アプリを指定して実行を要求する。画像形成装置１０は、入力されたユーザ情報を情報処理装置１１へ送信し、認証処理を要求する。ユーザ情報は、認証に必要なユーザＩＤやパスワード等である。ここでは、ユーザ情報を、ユーザが入力しているが、これに限られるものではなく、ＩＣ(Integrated Circuit)カード等に登録されたユーザ情報を、読取装置で読み取る形式であってもよいし、ユーザＩＤやパスワードに代えて生体情報を用いてもよい。

情報処理装置１１は、ユーザと利用契約を結んだ際に、ユーザ情報の登録を受け付け、ユーザ情報を登録する。このため、情報処理装置１１は、画像形成装置１０が入力を受け付け、送信したユーザ情報と、登録されたユーザ情報とを比較し、一致する場合に認証成功とし、アプリの利用を許可することができる。一方、情報処理装置１１は、一致しない場合、認証失敗とし、アプリの利用を拒否する。

サービス提供システムは、１以上の画像形成装置１０と、１つの情報処理装置１１とで構成されるシステムに限定されるものではなく、情報処理装置１１の機能を、１以上の画像形成装置１０のうちの１つ、または複数に実装し、１以上の画像形成装置１０のみで構成されていてもよい。また、サービス提供システムは、情報処理装置１１が直接アプリの実行要求を受けて、アプリの処理を実行するものであってもよく、情報処理装置１１のみで構成されていてもよい。なお、情報処理装置１１は、１つに限られるものではなく、複数であってもよい。

図２は、サービス提供システムを構成する画像形成装置１０のハードウェア構成の一例を示した図である。ここでは、画像形成装置１０をＭＦＰとして説明する。ＭＦＰは、コントローラ２０と、近距離通信回路２１と、エンジン制御部２２と、操作パネル２３と、ネットワークＩ／Ｆ２４とを備える。

コントローラ２０は、コンピュータの主要部であるＣＰＵ(Central Processing Unit)３０と、システムメモリ(MEM-P)３１と、ノースブリッジ(NB)３２と、サウスブリッジ(SB)３３と、ＡＳＩＣ(Application Specific Integrated Circuit)３４と、ローカルメモリ(MEM-C)３５と、ＨＤＤ(Hard Disk Drive)コントローラ３６と、ＨＤ３７とを含む。ＮＢ３２とＡＳＩＣ３４との間は、ＡＧＰ(Accelerated Graphics Port)バス３８により接続されている。

ＣＰＵ３０は、ＭＦＰの全体制御を行う制御部である。ＮＢ３２は、ＣＰＵ３０と、ＭＥＭ－Ｐ３１、ＳＢ３３およびＡＧＰバス３８とを接続するためのブリッジであり、ＭＥＭ－Ｐ３１に対する読み書き等を制御するメモリコントローラと、ＰＣＩ(Peripheral Component Interconnect)マスタおよびＡＧＰターゲットとを有する。

ＭＥＭ－Ｐ３１は、コントローラ２０の各機能を実現させるためのプログラムやデータの格納用メモリであるＲＯＭ３１ａと、プログラムやデータの展開、およびメモリ印刷時の描画用メモリ等として用いるＲＡＭ３１ｂとを含む。なお、ＲＡＭ３１ｂに記憶されているプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＤＶＤ等のコンピュータにより読み取り可能な記録媒体に記録して提供するように構成してもよい。

ＳＢ３３は、ＮＢ３２とＰＣＩデバイス、周辺デバイスと接続するためのブリッジである。ＡＳＩＣ３４は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣであり、ＡＧＰバス３８、ＰＣＩバス３９、ＨＤＤコントローラ３６およびＭＥＭ－Ｃ３５をそれぞれ接続するブリッジの役割を有する。ＡＳＩＣ３４は、ＰＣＩターゲットおよびＡＧＰマスタ、ＡＳＩＣ３４の中核をなすアービタ(ARB)、ＭＥＭ－Ｃ３５を制御するメモリコントローラ、ハードウェアロジック等により画像データの回転等を行う複数のＤＭＡＣ(Direct Memory Access Controller)を含む。また、ＡＳＩＣ３４は、スキャナ部４０およびプリンタ部４１との間でＰＣＩバス３９を介したデータ転送を行うＰＣＩユニットを含む。なお、ＡＳＩＣ３４には、ＵＳＢ(Universal Serial Bus)のインターフェースや、ＩＥＥＥ１３９４(Institute of Electrical and Electronics Engineers 1394)のインターフェースを接続するように構成されていてもよい。

ＭＥＭ－Ｃ３５は、コピー用画像バッファおよび符号バッファとして用いるローカルメモリである。ＨＤ３７は、画像データの蓄積、印刷時に用いるフォントデータの蓄積、フォームの蓄積を行うためのストレージである。ＨＤ３７は、ＣＰＵ３０の制御に従ってＨＤ３７に対するデータの読み出し、または書き込みを制御する。ＡＧＰバス３８は、グラフィック処理を高速化するために提案されたグラフィックアクセラレータカード用のバスインタフェースであり、ＭＥＭ－Ｐ３１に高スループットで直接アクセスすることにより、グラフィックアクセラレータカードを高速にすることができる。

近距離通信回路２１は、ＮＦＣ(Near Field Communication)、Ｂｌｕｅｔｏｏｔｈ（登録商標）等を使用した通信回路である。

エンジン制御部２２は、スキャナ部４０およびプリンタ部４１により構成される。操作パネル２３は、現在の設定値や選択画面等を表示させ、ユーザからの入力を受け付けるタッチパネル等のパネル表示部２３ａと、濃度の設定条件等の画像形成に関する条件の設定値を受け付けるテンキーやコピー開始指示を受け付けるスタートキー等からなる操作パネル部２３ｂとを備えている。

コントローラ２０は、例えば描画、通信、操作パネル２３からの入力等を制御する。スキャナ部４０またはプリンタ部４１は、誤差拡散やガンマ変換等の画像処理部分が含まれている。

なお、ＭＦＰは、操作パネル２３のアプリケーション切り替えキーにより、ドキュメントボックス機能、コピー機能、プリンタ機能、ファクシミリ機能を順次切り替えて選択することができる。各機能の選択時、各モードとなる。

ネットワークＩ／Ｆ２４は、ネットワーク１２を利用してデータ通信を行うためのインターフェースである。近距離通信回路２１やネットワークＩ／Ｆ２４は、ＰＣＩバス３９を介してＡＳＩＣ３４に電気的に接続されている。

図３は、情報処理装置１１のハードウェア構成の一例を示した図である。情報処理装置１１は、一般的なコンピュータで、ＣＰＵ５０と、ＲＯＭ５１と、ＲＡＭ５２と、ＨＤ５３と、ＨＤＤコントローラ５４と、ディスプレイ５５と、外部機器接続Ｉ／Ｆ５６と、ネットワークＩ／Ｆ５７と、データバス５８と、キーボード５９と、ポインティングデバイス６０と、ＤＶＤ－ＲＷ(Digital Versatile Disk Rewritable)ドライブ６１と、メディアＩ／Ｆ６２とを備える。

ＣＰＵ５０は、情報処理装置１１全体の動作を制御する。ＲＯＭ５１は、ＩＰＬ(Initial Program Loader)等のＣＰＵ５０の駆動に用いられるプログラムを記憶する。ＲＡＭ５２は、ＣＰＵ５０の作業領域を提供する。ＨＤ５３は、プログラム等の各種データを記憶する。ＨＤＤコントローラ５４は、ＣＰＵ５０の制御に従ってＨＤ５３に対する各種データの読み出し、または書き込みを制御する。ディスプレイ５５は、カーソル、メニュー、ウィンドウ、文字、画像等の各種情報を表示する。

外部機器接続Ｉ／Ｆ５６は、各種の外部機器を接続するためのインターフェースである。外部機器としては、例えばＵＳＢメモリやプリンタ等が挙げられる。ネットワークＩ／Ｆ５７は、ネットワーク１２を利用してデータを通信するためのインターフェースである。データバス５８は、ＣＰＵ５０等の各構成要素を電気的に接続するためのアドレスバスやデータバス等である。

キーボード５９は、文字、数値、各種指示等の入力のための複数のキーを備えた入力手段の一種である。ポインティングデバイス６０は、各種指示の選択や実行、処理対象の選択、カーソルの移動等を行う入力手段の一種である。ＤＶＤ－ＲＷドライブ６１は、着脱可能な記録媒体の一例であり、ＤＶＤ－ＲＷ６３に対する各種データの読み出し、または書き込みを制御する。ここでは、ＤＶＤ－ＲＷ６３を例に挙げたが、これに限定されるものではなく、ＤＶＤ－Ｒ等であってもよい。メディアＩ／Ｆ６２は、フラッシュメモリ等の記録メディア６４に対するデータの読み出し、または書き込みを制御する。

情報処理装置１１は、ＨＤ５３をデータベースとして使用することができるが、データベースは、情報処理装置１１とは別個に設けてもよい。

図４は、情報処理装置１１の機能構成の一例を示したブロック図である。情報処理装置１１が備える各機能は、ＣＰＵ５０等の処理回路により実現することが可能である。処理回路は、電子回路により実装されるプロセッサのようにソフトウェアにより各機能を実行するようにプログラミングされたプロセッサや、上記で説明した各機能を実行するように設計されたＡＳＩＣ、ＤＳＰ(Digital Signal Processor)、ＦＰＧＡ(Field Programmable Gate Array)や従来の回路モジュール等のデバイスを含むものとする。

情報処理装置１１は、データベース７０として、ユーザ・デバイスライセンス料金データベース７１と、アプリ実行時データ蓄積データベース７２と、テナントデータベース７３とを含む。

ユーザ・デバイスライセンス料金データベース７１は、パッケージがユーザライセンス契約の場合の料金情報と、デバイスライセンス契約の場合の料金情報とを登録する。アプリ実行時データ蓄積データベース７２は、アプリを実行した際の時刻等の情報を記憶する。テナントデータベース７３は、複数のテナントの情報を記憶する。図４に示す例では、テナントＡについてのみ示すが、テナントＢ等の他のテナントの情報を含むことができる。

テナントデータベース７３は、テナントに所属するユーザの情報を記憶するユーザデータベース７４と、パッケージの情報を記憶するパッケージデータベース７５と、デバイスの情報を記憶するデバイスデータベース７６とを含む。

ユーザの情報は、テナントの管理者の情報と、一般ユーザの情報とを含む。パッケージの情報は、アプリの販売単位となる各パッケージに関する情報であり、パッケージに何のアプリが登録されているかという情報を含む。デバイスの情報は、アプリが利用できる画像形成装置１０の個体情報（デバイスＩＤ等）を含む。

契約情報７７は、テナントがデバイスライセンス契約であるか、ユーザライセンス契約であるかを示す情報、ライセンス契約が切り替え可能であるかを示す情報を含む。契約情報７７は、契約時に登録され、契約が更新されると更新される。

情報処理装置１１は、表示部７８と、実行部７９と、認証部８０と、提案部８１と、収集部８２と、設定部８３とを含む。

表示部７８は、Ｗｅｂに公開しているＷｅｂサイトで、管理者に対して提案する料金プランを表示する。提案する料金プランの表示時期は、一般ユーザが設定してもよいし、管理者が設定してもよい。表示する内容には、提案部８１により計算された計算結果を用いることができる。

提案部８１は、データベースを参照し、ユーザが契約した料金プランと、計算により導出された料金プランとを比較し、安価なプランを提案する案として生成し、生成した案を表示部７８へ通知し、表示させる。提案部８１が実行する計算および案の生成は、表示部７８が通知する前であればいつ実行してもよい。

認証部８０は、画像形成装置１０からアプリを実行したユーザの情報を取得する。ユーザの情報は、ユーザが画像形成装置１０に対して認証情報として入力した情報（ログイン情報）から取得することができる。

設定部８３は、アプリ実行時の設定を管理する。設定内容としては、ファイルをアップロードする際に、クラウドストレージのどのディレクトリに保存するかという保存場所の設定を一例として挙げることができる。これに限られるものではなく、データ配信する場合の配信先のＵＲＬ(Uniform Resource Locator)の設定等であってもよい。

実行部７９は、画像形成装置１０と通信を行い、画像形成装置１０から実行されたアプリの処理を実行する。アプリの処理としては、文書ファイルをクラウドストレージにアップロードする処理等が挙げられる。アップロードする処理では、設定部８３が設定した保存場所に文書ファイルを保存する。

収集部８２は、実行部７９により実行されたアプリの実行内容をデータとして収集し、蓄積手段として機能するアプリ実行時データ蓄積データベース７２にアプリの実行内容の情報を記憶する。

提案部８１は、アプリ実行時データ蓄積データベース７２に記憶された情報に基づき、アプリの実行回数を計算する。提案部８１は、計算した実行回数に基づき、料金プランの変更を判断し、料金プラン変更の提案を行う。

情報処理装置１１は、画像形成装置１０からアプリの実行要求を受けてアプリを実行し、アプリ実行時にデータを蓄積し、蓄積したデータに基づき、料金プランの変更を提案する。このため、情報処理装置１１は、アプリ実行時のデータ蓄積処理と、料金プラン提案処理とを実行する。以下、２つの処理に分け、各処理の詳細を順に説明する。

先に、アプリ実行時のデータ蓄積処理について説明する。図５は、データ蓄積処理の流れを示したシーケンス図である。ユーザ９０は、アプリ９１を実行し(S1)、アプリ９１が実行部７９に対して実行要求を送信する(S2)。ユーザ９０は、文書ファイルをクラウドストレージにアップロードする処理を、アプリ９１に対して要求すると、その処理を実行するため、アプリ９１は、実行部７９に対してその処理の実行を要求する。実行部７９は、要求された処理の実行時に収集部８２に対して実行要求を受信したこと、アプリ９１の実行時刻、アプリ９１を識別するためのアプリＩＤ、認証情報を通知する(S3)。

収集部８２は、認証部８０に対して認証情報を送付し、ユーザ情報の照会を要求する(S4)。認証部８０は、収集部８２から受け取った認証情報から、どのユーザがアプリ９１を実行したかを照会し、収集部８２に対してユーザ情報を通知する(S5)。また、収集部８２は、設定部８３に対してアプリＩＤを送付し、アプリ情報の照会を要求する(S6)。設定部８３は、収集部８２から受け取ったアプリＩＤから、どのアプリを実行したかを照会し、収集部８２に対してアプリ情報を通知する(S7)。

収集部８２は、認証部８０および設定部８３から収集したユーザ情報およびアプリ情報をアプリ実行時データ蓄積データベース７２に送信して蓄積させる(S8)。

図６は、アプリ実行時データ蓄積データベース７２に蓄積される情報の一例を示した図である。アプリ実行時データ蓄積データベース７２には、アプリ９１の実行時刻、アプリＩＤ、アプリタイプ、互換性を有するアプリのアプリＩＤ、所属パッケージＩＤがアプリ情報として登録され、ユーザＩＤ、ユーザロール、ゲストユーザ、テナントＩＤがユーザ情報として登録される。これらは、収集部８２により収集され、アプリ実行時データ蓄積データベース７２に蓄積される。

互換性を有するアプリは、置換可能なアプリであり、付加機能が付いたアプリが挙げられる。外部ストレージサービスと連携するアプリの場合、互換性を有するアプリとしては、領収書認識やバーコード読み取り等の付加機能を付いたアプリが挙げられる。アプリタイプは、アプリの種類を示し、スキャン、プリント、スキャンとプリント、処理実行、機器管理等がある。

ユーザロールは、ユーザのグループを示し、例えばテナント管理者、一般ユーザ等である。ゲストユーザは、テナントに属しないユーザである。

次に、料金プラン提案処理について説明する。料金プランは、デバイスライセンス契約の料金、ユーザライセンス契約の料金、パッケージ毎の契約の料金、アプリ（単体アプリパッケージ）毎の契約の料金を合算したものとなる。この中で、顧客が利用していない不要な契約がないかどうかを検出し、検出した不要な契約を削除し、低額な料金プランを１つの案として提案する。不要な契約の検出は、データベース７０に蓄積されたデータを用いて計算し、計算した結果を用いて行われる。計算に使用するデータは、設定された期間に蓄積されたデータを用いることができる。期間は、顧客により予め入力し、設定された値を用いることができる。

図７は、料金プランの提案頻度等を設定する画面の一例を示した図である。図７に示す画面は、期間、使用回数の閾値を入力するフィールドを有している。期間は、料金プランを提案するために検査する期間である。

使用回数は、特定のアプリを使用した回数と、特定のユーザのアプリ使用回数とを含む。特定のアプリを使用した回数は、特定のアプリを使用可能な全ユーザの使用回数で、特定のユーザのアプリ使用回数は、特定のアプリを使用可能な特定のユーザの使用回数である。特定のアプリを使用した回数の閾値は、特定のアプリが不要か否かを判断する基準となる回数を示し、閾値以下であれば全ユーザにとって特定のアプリが不要なアプリとみなすことができる。特定のユーザのアプリ使用回数の閾値は、特定のユーザにとって特定のアプリが不要か否かを判断する基準となる回数を示し、閾値以下であれば特定のユーザにとって特定のアプリが不要なアプリとみなすことができる。

図８は、ユーザ・デバイスライセンス料金データベース７１に登録されるユーザライセンス料金プランの一例を示した図である。ユーザライセンス料金プランは、パッケージ毎の１ユーザ当たりの料金、契約ユーザ数、アプリ当たりの合計料金を含む。１ユーザ当たりの料金は、１か月当たりの料金であってもよいし、３か月、６か月、１年当たりの料金等であってもよい。合計料金は、１ユーザ当たりの料金に契約ユーザ数を乗じて算出される料金である。ユーザ・デバイスライセンス料金データベース７１は、ユーザライセンス契約の場合の料金を取得する際に参照される。

図９は、ユーザ・デバイスライセンス料金データベース７１に登録されるデバイスライセンス料金プランの一例を示した図である。デバイスライセンス料金プランは、パッケージ毎の１デバイス当たりの料金、契約デバイス数、アプリ当たりの合計料金を含む。１デバイス当たりの料金は、１ユーザ当たりの料金と同様、１か月当たりの料金であってもよいし、３か月、６か月、１年当たりの料金等であってもよい。合計料金は、１デバイス当たりの料金に契約デバイス数を乗じて算出される料金である。ユーザ・デバイスライセンス料金データベース７１は、デバイスライセンス契約の場合の料金を取得する際に参照される。

各アプリの使用回数は、設定された一定期間における各アプリの実行回数として各アプリの実行時にカウントされる。図１０に、アプリ毎の実行回数の一例をグラフに示す。パッケージは、アプリＡ、アプリＢ、アプリＣの３つのアプリを含む。グラフは、パッケージに含まれるアプリを横軸に、各アプリの使用回数を縦軸に示す。この例では、アプリＡ、アプリＢは使用されているが、アプリＣは使用されていない。

図１０に示す例では、アプリＣは一定期間使用されていないため、顧客に対してアプリＣを削除した料金プランを提案することができる。

各アプリの使用回数は、各アプリを使用可能なユーザ毎にカウントされる。図１１に、特定のアプリ（アプリＡ）のユーザ毎の実行回数の一例をグラフに示す。アプリＡを使用するユーザには、ユーザＡ、ユーザＢ、ユーザＣが含まれる。グラフは、アプリＡを使用するユーザを横軸に、アプリＡの使用回数を縦軸に示す。この例では、ユーザＡ、ユーザＢは使用しているが、ユーザＣは使用していない。

図１１に示す例では、ユーザＣはアプリＡを使用していないため、顧客に対してアプリＡを使用可能なユーザライセンスの削減を提案することができる。

図１２は、ユーザ数を減らした料金プランを提案する処理の流れを示したフローチャートである。料金プランを提案する処理は、図７に示す画面で設定された期間が経過する毎に実施される。ステップ１００から処理を開始し、テナントデータベース７３の契約情報７７を参照し、テナントの契約形態を確認する。この例では、テナントの契約形態がユーザライセンス契約とする。

ステップ１０１では、アプリ実行時データ蓄積データベース７２に蓄積された情報のうち、現在の処理対象となっているテナントの情報のみを抽出する。そして、現在の処理対象となっているテナントに属するユーザ毎に、アプリ毎の使用回数を計算する。計算結果に基づき、アプリ毎に、使用回数が一定値以下のユーザがいるかどうかを判断する。いない場合、ステップ１０６へ進み、処理を終了する。全てのユーザが全てのアプリを、一定値を超えて使用しており、ユーザ数を減らす必要はないからである。

ステップ１０１で使用回数が一定値以下のユーザがいる場合、ステップ１０２へ進み、一定値以下のユーザは不要と判断し、不要と判断したユーザを除いたユーザ一覧を作成する。そして、作成したユーザ一覧に基づき、ユーザライセンス契約した場合の料金を計算する。

ステップ１０２のアプリを不要と判断する処理について説明する。なお、ユーザライセンスがテナントに紐付いている場合と、パッケージに紐付いている場合と、アプリに紐付く場合とでは、処理が異なるため、各場合の処理について順に説明する。

テナントに紐付く場合（テナント毎に契約するライセンス数が決定されている場合）は、テナントで管理するユーザのユーザ数と同じライセンス数でパッケージの全てのアプリを使用する契約となっている。このため、特定のユーザが、パッケージの特定のアプリしか使用していなくても、一定期間の使用回数が一定値以下でなければ特定のユーザにとって必要なライセンスである。そこで、各ユーザにつき、全てのアプリの使用回数が一定値以下かどうかを判断し、一定値以下のユーザを不要と判断する。全てのユーザにつき判断した後、不要と判断したユーザを減らした場合の料金を算出する。

パッケージに紐付く場合（パッケージ毎に契約するライセンス数が決定されている場合）は、テナントのユーザ数に関係なく、任意のユーザ数でパッケージの全てのアプリを使用する契約となっている。ユーザ毎の使用回数が一定以下のアプリの一覧を作成し、作成したアプリの一覧に基づき、各ユーザにつき、全てのアプリの使用回数が一定値以下かどうかを判断する。全てのアプリの使用回数が一定値以下のユーザがいる場合、そのユーザを不要と判断する。全てのユーザにつき判断した後、不要と判断したユーザを減らした場合の料金を算出する。

なお、あるユーザが使用していないアプリが全て１つのパッケージに属し、一定値を超えて使用されているアプリがそのパッケージに属していない場合、そのユーザは不要と判断する。

アプリに紐付く場合、ユーザ毎の使用回数が一定値以下のアプリの一覧を作成し、作成したアプリの一覧に基づき、アプリ毎に使用回数が一定値以下のユーザを不要と判断し、アプリ毎にユーザ数を減らした場合の料金を算出する。

テナントに紐付く場合と、パッケージに紐付く場合またはアプリに紐付く場合とが同時に起こる得ることはない。一方、パッケージに紐付く場合と、アプリに紐付く場合とは、パッケージ単位での販売と、アプリ単位での販売とが混在する場合があることから、同時に起こり得る。

ステップ１０３では、減らしたユーザ数でデバイスライセンス契約に切り替え可能であるか否かを判断する。デバイスライセンス契約に切り替え可能であるか否かは、テナントデータベース７３の契約情報７７を参照して判断する。切り替え可能であると判断した場合は、ステップ１０４へ進み、切り替え不可と判断した場合は、ステップ１０５へ進む。

ステップ１０４では、デバイスライセンス契約に切り替えた場合の料金を計算する。デバイスライセンス契約に切り替え可能な場合、最初にデバイス数１で料金を計算する。ユーザ数を減らした場合のユーザライセンス契約の料金と比較し、計算したデバイス数１の料金が安い場合、デバイス数を１増加してデバイスライセンス契約の料金を再度計算する。この処理は、ユーザライセンス契約の料金より高くなるまで繰り返し、高くなったときのデバイス数から１減算したデバイス数をデバイスライセンス契約可能な最大のデバイス数とする。

デバイスライセンス契約可能な最大のデバイス数は、デバイスライセンス契約している顧客のデータを利用した方法を用いることができる。例えば、最も多くデバイスを利用している顧客のデバイス数を利用して二分探索を行い、デバイスライセンス契約が可能な最大デバイス数を探索することができる。なお、デバイスライセンス契約可能な最大のデバイス数が０である場合、デバイスライセンスに切り替え可能であるが、切り替えないほうがよいと判断する。

ステップ１０５では、契約した料金と、算出された料金とから、どれだけ料金が安くなるかを計算し、計算結果を表示する。また、デバイスライセンス契約に切り替えた場合に、ユーザライセンス契約より安くなる場合、その旨、どれだけ安くなるかを表示する。これにより、契約内容の変更を提案する。

デバイスライセンス契約可能な最大のデバイス数と、今のテナントが契約しているデバイス数とを比較して、今のテナントが契約しているデバイス数のほうが多い場合、提案時に警告を出すことができる。このとき、切り替えないほうがよい旨を表示してもよい。デバイスライセンス契約可能な最大のデバイス数のほうが多い場合、今のテナントが契約しているデバイス数で利用料金を計算する。提案時には、最大のデバイス数で契約した場合の料金と、計算した今のテナントが契約しているデバイス数の料金とを両方提示することもよいし、片方のみを提示してもよい。

提案内容は、管理者に対してＷｅｂサイト上に表示してもよいし、画像形成装置１０の操作パネル２３上に管理者がログインした際に表示してもよい。

図１３は、デバイスライセンス契約への切り替えを提案する例を示した図である。図１３（ａ）は、デバイスライセンス契約への切り替えを提案する画面の一例を示した図で、図１３（ｂ）は、その画面の変形例を示した図である。図１３（ａ）に示す画面は、計算結果が今のテナントが契約しているデバイス数より１台多くでき、そのときの料金をそのまま表示している。また、今のテナントが契約しているデバイス数のまま切り替えた場合の差額も表示している。この提案内容から、顧客は、デバイス数を１台増加したデバイスライセンス契約、また、デバイス数を変えることなくデバイスライセンス契約に切り替えることができる。

図１３（ｂ）に示す画面も、計算結果が今のテナントが契約しているデバイス数より１台多くでき、今のテナントが契約しているデバイス数のまま切り替えた場合の差額を表示するが、さらに、契約プランの変更を行うか否かを選択するボタンが表示され、ＹＥＳボタンを選択することで、契約プランの変更を行うＷｅｂページへ遷移し、そのＷｅｂページを表示することができるようになっている。一方、ＮＯボタンを選択することで、画面を閉じることができる。このため、情報処理装置１１は、提案部８１が提案した案へ変更するか否かの選択を受け付ける入力部を含むことができる。表示部７８は、入力部が受け付けた選択結果に応じて、画面を切り替えることができる。すなわち、表示部７８は、変更するとの選択結果を受けて、契約プランの変更を行うＷｅｂページへ画面を遷移させる。

この画面では、この契約プランの変更を行うか否かを選択する表示部分を、これ以降に表示しないようにするボタンも表示されている。このボタンを押下することで、それ以降、図１３（ａ）に示すような切り替えの提案のみの画面となる。

図１４は、アプリを減らした料金プランを提案する処理の流れを示したフローチャートである。料金プランを提案する処理は、図７に示す画面で設定された期間が経過する毎に実施される。ステップ２００から処理を開始し、テナントデータベース７３の契約情報７７を参照し、テナントの契約形態を確認する。この例では、テナントの契約形態がユーザライセンス契約とする。

ステップ２０１では、アプリ実行時データ蓄積データベース７２に蓄積された情報のうち、現在の処理対象となっているテナントの情報のみを抽出する。そして、現在の処理対象となっているテナントに登録されているアプリで使用回数が一定値以下のアプリがあるかどうかを判断する。使用回数が一定値以下のアプリがない場合、ステップ２０６へ進み、処理を終了する。全てのアプリが一定値を超えて使用しており、パッケージ単位でも、アプリ単位でも減らす必要はないからである。

ステップ２０１で使用回数が一定値以下のアプリがある場合、ステップ２０２へ進み、テナントに登録されているアプリで一定値以下のアプリを不要と判断し、判断した不要のアプリを除いてアプリ一覧を作成する。

ステップ２０３では、テナント単位でパッケージを契約している場合、またはユーザ単位でパッケージを契約している場合において、減らせる不要なアプリがあるかどうかを判断する。不要なアプリがある場合、ステップ２０４へ進み、ない場合、ステップ２０６へ進み、処理を終了する。

ステップ２０４では、パッケージ単位でしか減らせない場合、アプリ単位でしか減らせない場合は、片方の処理のみを実施することができる。なお、パッケージ単位でも、アプリ単位でも減らせる場合、両方の処理を実施することができる。

パッケージ、アプリがテナントに紐付いている場合とユーザに紐付いている場合があるため、それぞれの処理について以下に説明する。

パッケージがテナントに紐付いており、パッケージ単位で減らせる場合、テナントに属する各ユーザの使用回数の合計が一定以下のアプリ一覧を作成する。テナントに登録されたパッケージのアプリの全ての使用回数が一定値以下である場合、そのパッケージは不要と判断する。そして、不要なパッケージを除いたときの料金を計算する。この判断および計算を、テナントに属する全てのユーザに対して行い、その合計料金を計算する。

パッケージがユーザに紐付いており、パッケージ単位で減らせる場合、各ユーザにつき、使用回数が一定値以下のアプリ一覧を作成する。テナントに登録されたパッケージのアプリ全ての使用回数が一定値以下のアプリに該当する場合、そのパッケージは不要と判断する。そして、不要なパッケージを除いたときの料金を計算する。これをテナントに属する全てのユーザに対して行い、その合計料金を計算する。

アプリがテナントに紐付いており、アプリ単位で減らせる場合、各ユーザにつき、使用回数が一定値以下のアプリ一覧を作成する。テナントに属する各ユーザの使用回数の合計が一定値以下のアプリを不要と判断する。そして、不要なアプリを除いたときの料金を計算する。これをテナントに属する全てのユーザに対して行い、その合計料金を計算する。

アプリがユーザに紐付いており、アプリ単位で減らせる場合、各ユーザにつき、使用回数が一定値以下のアプリを不要と判断する。そして、不要なアプリを除いたときの料金を計算する。これをテナントに属する全てのユーザに対して行い、その合計料金を計算する。

ステップ２０５では、契約した料金と、計算した料金とから、どれだけ料金が安くなるかを計算し、計算結果やどれだけ安くなるかを表示する。これにより、契約内容の変更を提案する。

図１２～図１４に示した例は、現状、ユーザライセンス契約をしているときのデバイスライセンス契約への切り替え、ユーザ数を減らす処理、パッケージ、アプリを減らす処理について説明してきた。次に、現状、デバイスライセンス契約をしているときのユーザライセンス契約への切り替え、ユーザを減らす処理、パッケージ、アプリを減らす処理について説明する。

ユーザを減らす処理、パッケージ、アプリを減らす処理については、図１２のステップ１０１、１０２、１０５、図１４に示した処理と同様である。したがって、図１５を参照して、デバイスライセンス契約への切り替え部分についてのみ説明する。図１５のステップ３０３では、減らしたユーザ数でユーザライセンス契約に切り替え可能であるか否かを判断する。ユーザライセンス契約に切り替え可能であるか否かは、テナントデータベース７３の契約情報７７を参照して判断する。切り替え可能であると判断した場合は、ステップ３０４へ進み、切り替え不可と判断した場合は、ステップ３０５へ進む。

図１６は、ユーザライセンス契約がテナントに紐付く場合の契約内容の変更を提案する例を示した図である。図１６（ａ）は、契約内容の変更を提案する画面の一例を示した図で、図１６（ｂ）は、その画面の変形例を示した図である。図１６（ａ）に示す例では、テナントに紐付くユーザライセンス数を１５０から１００へ減らす旨、現状のユーザライセンス契約とユーザライセンス数を減らしたときの料金の差額を表示している。

図１６（ｂ）に示す画面も、ユーザライセンス数を減らし、減らしたときの料金の差額を表示するが、さらに、契約プランの変更を行うか否かを選択するボタンが表示されている。ＹＥＳボタンを選択することで、契約プランの変更を行う画面へ遷移することができ、ＮＯボタンを選択することで、画面を閉じることができる。また、この画面でも、この契約プランの変更を行うか否かを選択する表示部分を、これ以降に表示しないようにするボタンも表示されている。このボタンを押下することで、それ以降、図１６（ａ）に示すような契約内容変更の提案のみの画面となる。

図１７は、パッケージ、アプリを減らせる場合の契約内容の変更を提案する例を示した図である。図１７（ａ）は、契約内容の変更を提案する画面の一例を示した図で、図１７（ｂ）は、その画面の変形例を示した図である。図１７（ａ）に示す例では、パッケージＤおよびアプリＥを減らし、現状のユーザライセンス契約の料金がそれぞれ１００００円、２００００円安くなることを示している。そのとき、ユーザライセンス数がそれぞれ２５ほど減ることを示している。

図１７（ｂ）に示す画面も、パッケージＤおよびアプリＥを減らし、減らしたときに料金がどれだけ安くなるかを表示するが、さらに、契約プランの変更を行うか否かを選択するボタンが表示されている。ＹＥＳボタンを選択することで、契約プランの変更を行う画面へ遷移することができ、ＮＯボタンを選択することで、画面を閉じることができる。また、この画面でも、この契約プランの変更を行うか否かを選択する表示部分を、これ以降に表示しないようにするボタンも表示されている。このボタンを押下することで、それ以降、図１７（ａ）に示すような契約内容変更の提案のみの画面となる。

図１８は、提案部８１が行う料金の比較について説明する図である。ユーザＡ、Ｂ、Ｃについてユーザライセンス契約をし、料金プランを提案する処理の実行に伴い、ユーザＣの使用回数が少ないことから、ユーザＣのユーザライセンス契約を解除する場合について考える。

提案部８１は、ユーザライセンス契約したときの料金試算と、デバイスライセンス契約したときの料金試算とを行い、試算した各料金と現在契約している料金プランの料金とを比較する。現在契約している料金プランより安くなる場合、顧客に対し、より安いプランを提案する。これにより、顧客の満足度を向上させることができる。

図１９は、デバイスライセンス契約を提案する例を示した図である。図１９（ａ）は、デバイスライセンス契約を提案する画面の一例を示した図で、図１９（ｂ）は、その画面の変形例を示した図である。図１９（ａ）に示す例では、比較の結果、現在契約しているユーザライセンスよりデバイスライセンスの方が月額４００００円安くなっている。そこで、顧客に提案する画面では、提案する契約プランとして、デバイスライセンス契約を表示し、現在の契約よりどれだけ安くなるかも併せて表示する。

図１９（ｂ）に示す画面も、デバイスライセンス契約を表示するが、さらに、契約プランの変更を行うか否かを選択するボタンが表示されている。ＹＥＳボタンを選択することで、契約プランの変更を行う画面へ遷移することができ、ＮＯボタンを選択することで、画面を閉じることができる。また、この画面でも、この契約プランの変更を行うか否かを選択する表示部分を、これ以降に表示しないようにするボタンも表示されている。このボタンを押下することで、それ以降、図１９（ａ）に示すようなデバイスライセンス契約の提案のみの画面となる。

図２０は、ユーザライセンス契約を提案する例を示した図である。図２０（ａ）は、ユーザライセンス契約を提案する画面の一例を示した図で、図２０（ｂ）は、その画面の変形例を示した図である。図２０（ａ）に示す例では、比較の結果、現在契約しているデバイスライセンスよりユーザライセンスの方が月額５００００円安くなっている。そこで、顧客に提案する画面では、提案する契約プランとして、ユーザライセンス契約を表示し、現在の契約よりどれだけ安くなるかも併せて表示する。

図２０（ｂ）に示す画面も、ユーザライセンス契約を表示するが、さらに、契約プランの変更を行うか否かを選択するボタンが表示されている。ＹＥＳボタンを選択することで、契約プランの変更を行う画面へ遷移することができ、ＮＯボタンを選択することで、画面を閉じることができる。また、この画面でも、この契約プランの変更を行うか否かを選択する表示部分を、これ以降に表示しないようにするボタンも表示されている。このボタンを押下することで、それ以降、図２０（ａ）に示すようなユーザライセンス契約の提案のみの画面となる。

現在より安い料金プランの契約内容は、現在の契約内容よりユーザ数、パッケージ、アプリを減らした内容となる。アプリの削除を提案する際、料金が安くなるという情報だけでは実際の業務効率が低下することを危惧し、顧客がアプリの削除をためらう可能性がある。アプリを削除する理由が分かれば、その不安を低減させることができる。そこで、アプリの削除とともに、蓄積データを用いてアプリを削除する理由を表示することができる。

１つの理由として、互換性を有するアプリを使用していることを挙げることができる。アプリには、外部ストレージサービスと連携する比較的単純なアプリのほか、領収書認識、バーコード読み取り等、付加処理付きのアプリがある。すると、単純なアプリと付加処理付きアプリとは、互換性を有するアプリと言える。

初期契約では、単純なアプリと付加処理付きの上位互換アプリの両方とも契約していたが、実際の業務データを参照すると、下位互換アプリまたは上位互換アプリのどちらか片方しか使われていない場合がある。そのような場合、互換性を有するアプリを使用していることを、アプリ削除理由とすることができる。

別の理由として、機器管理タイプのアプリを使用していないことを挙げることができる。アプリは、実行内容によって種々のタイプに分類される。アプリのタイプとしては、スキャン、プリント、スキャンとプリント、処理実行、機器管理等がある。初期契約では、有料の機器管理アプリを利用する予定で契約したが、実際の業務データを参照すると、機器管理アプリが実行された形跡がない場合がある。そのような場合、機器管理タイプのアプリを使用していないことを、アプリ削除理由とすることができる。

図２１は、アプリ削除理由を作成する処理の一例を示したフローチャートである。提案部８１が上記の比較を行い、契約内容の変更を提案する際、その内容がアプリ削除を伴うものである場合に、ステップ４００から処理を開始する。アプリを削除した場合の料金が計算されている場合、アプリを削除する場合と判断することができる。データベースに料金が計算されたかどうかを示すデータを登録しておき、そのデータを参照してもよいし、計算結果があるかどうかをプログラム内の変数を参照してもよい。

なお、この処理は、実行しなくてもよい。実行しない場合、理由を併記した表示ができなくなる。実行しない場合の例としては、理由を併記すると、表示する画面の情報量が多くなりすぎ、提案する内容が伝わりにくくなるような場合が挙げられる。実行する場合、この処理は、図１４のステップ２０４とステップ２０５との間に実行することができる。この理由の作成処理は、別途設けられる作成部により実行することができる。

ステップ４０１では、削除アプリの上位互換または下位互換のアプリがあるか否かを判断する。図６に示した蓄積データに、削除アプリのアプリＩＤに対応する互換性を有するアプリのＩＤがあるか否かにより判断することができる。上位互換または下位互換のアプリがある場合、ステップ４０２へ進み、ない場合、ステップ４０４へ進む。

ステップ４０２では、削除アプリと上位互換または下位互換のアプリの使用頻度が一定値を超えているかを判断する。超えている場合、ステップ４０３へ進み、アプリ削除を提案する際の理由に、互換性のアプリが使用されていることを追加する。ステップ４０２で使用頻度が一定値以下である場合、ステップ４０４へ進む。

ステップ４０４では、削除を提案するアプリのアプリタイプが他のアプリタイプと異なっているかを判断する。削除アプリのアプリタイプとテナントで使用可能なアプリ（削除アプリ以外のアプリ）のアプリタイプが異なっているかどうかを調べる。削除アプリのアプリタイプとそれ以外のアプリのアプリタイプが全て異なっている場合にのみ、削除アプリのアプリタイプがそれ以外のアプリのアプリタイプと異なっていると判断する。異なっている場合、ステップ４０５へ進み、異なっていない場合、ステップ４０６へ進む。

ステップ４０５では、アプリの削除を提案する際の理由に、特定のアプリタイプは業務で使用されていないことを追加する。ステップ４０６では、アプリ削除を提案する際に追加した理由を併記して表示する。そして、ステップ４０７で理由の作成処理を終了する。

図２２は、理由を併記しないでアプリの削除を提案する例を示した図である。図２２（ａ）は、アプリの削除を提案する画面の一例を示した図で、図２２（ｂ）は、その画面の変形例を示した図である。図２２（ａ）では、アプリに代えてパッケージＣを削除する旨と、現在契約している料金プランよりどの程度安くなるかを示している。

図２２（ｂ）に示す画面も、アプリ、パッケージを削除する旨、どの程度安くなるかを表示するが、さらに、契約プランの変更を行うか否かを選択するボタンが表示されている。ＹＥＳボタンを選択することで、契約プランの変更を行う画面へ遷移することができ、ＮＯボタンを選択することで、画面を閉じることができる。また、この画面でも、この契約プランの変更を行うか否かを選択する表示部分を、これ以降に表示しないようにするボタンも表示されている。このボタンを押下することで、それ以降、図２２（ａ）に示すようなアプリの削除の提案のみの画面となる。

図２３は、理由を併記してアプリの削除を提案する例を示した図である。図２３（ａ）は、アプリの削除を提案する画面の一例を示した図で、図２３（ｂ）は、その画面の変形例を示した図である。図２３（ａ）では、パッケージＣを削除する旨と、現在契約している料金プランよりどの程度安くなるかに加えて、理由が追加されている。図２３（ａ）に示す例では、理由として、互換アプリが削除アプリの代わりに使用されている旨を併記して表示している。

図２３（ｂ）に示す画面も、パッケージを削除する旨、どの程度安くなるか、理由を表示するが、さらに、契約プランの変更を行うか否かを選択するボタンが表示されている。ＹＥＳボタンを選択することで、契約プランの変更を行う画面へ遷移することができ、ＮＯボタンを選択することで、画面を閉じることができる。また、この画面でも、この契約プランの変更を行うか否かを選択する表示部分を、これ以降に表示しないようにするボタンも表示されている。このボタンを押下することで、それ以降、図２３（ａ）に示すようなアプリの削除の提案のみの画面となる。

これまでアプリ削除の理由作成について説明したが、ユーザ数削減の理由作成について説明する。ユーザ数削減の理由としては、特定のロールのユーザがアプリを使用しなくなったこと、ゲストユーザのみがアプリを使用していることを挙げることができる。

初期契約では、どのロールのユーザでもアプリを使用できる料金プランであったが、実際の業務データを参照すると、特定のロールのユーザがアプリを使用していない場合がある。そのような場合、特定のロールのユーザがアプリを使用していないことを、ユーザ数削減理由とすることができる。例えば、初期契約時にはテナントの管理者もアプリを使用できる料金プランであったが、顧客の業務が変わってしまい、テナントの管理者がアプリを使用することがほとんどなくなった場合が該当する。

初期契約では、ゲストユーザが使用できるアプリがテナント内でも使用できるようにテナントに所属するユーザ全員にアプリのユーザライセンス契約またはデバイスライセンス契約をしていたが、実際の業務データを参照すると、ゲストユーザしかアプリを使用していない場合がある。そのような場合、ユーザライセンスを減らし、例えば１ユーザのみのユーザライセンス契約にすることを提案することができ、使用しているユーザがゲストユーザのみであることを、ユーザ数削減理由とすることができる。

図２４は、ユーザ数削除理由を作成する処理の一例を示したフローチャートである。提案部８１が上記の比較を行い、契約内容の変更を提案する際、その内容がユーザ数削除を伴うものである場合に、ステップ５００から処理を開始する。ユーザ数を削除した場合の料金が計算されている場合、ユーザ数を削除する場合と判断することができる。データベースに料金が計算されたかどうかを示すデータを登録しておき、そのデータを参照してもよいし、計算結果があるかどうかをプログラム内の変数を参照してもよい。

なお、この処理は、実行しなくてもよい。実行しない場合、理由を併記した表示ができなくなる。実行しない場合の例としては、理由を併記すると、表示する画面の情報量が多くなりすぎ、提案する内容が伝わりにくくなるような場合が挙げられる。実行する場合、この処理は、図１４のステップ２０４とステップ２０５との間に実行することができる。

ステップ５０１では、削除するユーザのロールとテナント内の他のユーザとではロールが異なっているか否かを判断する。テナントのユーザデータを参照し、削除するユーザのロールと、他のユーザのロールとを比較する。削除するユーザのロールと等しいユーザが他のユーザの中に一人もいない場合、削除を提案するユーザのロールは、他のユーザのロールとは異なっていると判断する。ロールが異なっている場合、ステップ５０２へ進み、同じロールのユーザがいる場合、ステップ５０３へ進む。

ステップ５０２では、ユーザの削除を提案する際の理由に、あるロールのユーザはアプリを使用していないことを追加する。

ステップ５０３では、削除するユーザがゲストユーザではなく、ゲストユーザ以外はアプリを使用していないか否かを判断する。テナントのユーザデータを参照し、削除するユーザが全てゲストユーザではなく、削除しないユーザが全てゲストユーザである場合、ゲストユーザのみがアプリを使用していると判断する。反対に、削除するユーザが全てゲストユーザで、削除しないユーザが全てゲストユーザ以外である場合、ゲストユーザはアプリを使用していないと判断する。

ステップ５０４では、ユーザの削除を提案する際の理由に、ゲストユーザ以外はアプリを使用していない、またはゲストユーザ以外しかアプリを使用していないことを追加する。ステップ５０５では、ユーザの削除を提案する際に追加した理由を併記して表示する。そして、ステップ５０６で理由の作成処理を終了する。

図２５は、理由を併記してユーザの削減を提案する例を示した図である。図２５（ａ）は、ユーザの削減を提案する画面の一例を示した図で、図２５（ｂ）は、その画面の変形例を示した図である。図２５（ａ）では、ユーザ数を削減し、ユーザ数を５０とするプランを提案し、その理由として、管理者ユーザがアプリを使用していないことを併記して表示している。

図２５（ｂ）に示す画面も、プランを提案し、その理由を表示するが、さらに、契約プランの変更を行うか否かを選択するボタンが表示されている。ＹＥＳボタンを選択することで、契約プランの変更を行う画面へ遷移することができ、ＮＯボタンを選択することで、画面を閉じることができる。また、この画面でも、この契約プランの変更を行うか否かを選択する表示部分を、これ以降に表示しないようにするボタンも表示されている。このボタンを押下することで、それ以降、図２５（ａ）に示すようなアプリの削除の提案のみの画面となる。

図２６は、理由を併記してゲストユーザを削減することを提案する例を示した図である。図２６（ａ）は、ゲストユーザの削減を提案する画面の一例を示した図で、図２６（ｂ）は、その画面の変形例を示した図である。図２６（ａ）では、ゲストユーザを通常ユーザよりも権限を制限したユーザとして削減提案をしている。ゲストユーザは権限が制限されたユーザであってもよいし、テナントに紐付く匿名ユーザというサービスとして提供されてもよい。匿名ユーザの場合、ゲストユーザサービスを停止するか否かが表示される。

図２６（ｂ）に示す画面も、ゲストユーザの削減の提案を表示するが、さらに、契約プランの変更を行うか否かを選択するボタンが表示されている。ＹＥＳボタンを選択することで、契約プランの変更を行う画面へ遷移することができ、ＮＯボタンを選択することで、画面を閉じることができる。また、この画面でも、この契約プランの変更を行うか否かを選択する表示部分を、これ以降に表示しないようにするボタンも表示されている。このボタンを押下することで、それ以降、図２６（ａ）に示すようなゲストユーザの削減の提案のみの画面となる。

以上に説明してきたように、契約内容の変更を提案することで、顧客が受け取っている価値相応の料金プランをサービス側から受け取ることができ、顧客満足度の低下を防ぐことができる。

これまで本発明の一実施形態について説明してきたが、本発明は、上述した実施形態に限定されるものではなく、本実施形態の構成要素を変更若しくは削除し、または本実施形態の構成要素を他の構成要素を追加するなど、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用効果を奏する限り、本発明の範囲に含まれるものである。

１０…画像形成装置
１１…情報処理装置
１２…ネットワーク
２０…コントローラ
２１…近距離通信回路
２２…エンジン制御部
２３…操作パネル
２３ａ…パネル表示部
２３ｂ…操作パネル部
２４…ネットワークＩ／Ｆ
３０…ＣＰＵ
３１…ＭＥＭ－Ｐ
３２…ＮＢ
３３…ＳＢ
３４…ＡＳＩＣ
３５…ＭＥＭ－Ｃ
３６…ＨＤＤコントローラ
３７…ＨＤ
３８…ＡＧＰバス
３９…ＰＣＩバス
４０…スキャナ部
４１…プリンタ部
５０…ＣＰＵ
５１…ＲＯＭ
５２…ＲＡＭ
５３…ＨＤ
５４…ＨＤＤコントローラ
５５…ディスプレイ
５６…外部機器接続Ｉ／Ｆ
５７…ネットワークＩ／Ｆ
５８…データバス
５９…キーボード
６０…ポインティングデバイス
６１…ＤＶＤ－ＲＷドライブ
６２…メディアＩ／Ｆ
６３…ＤＶＤ－ＲＷ
６４…記録メディア
７０…ユーザ・デバイスライセンス料金データベース
７１…アプリ実行時データ蓄積データベース
７２…テナントデータベース
７３…契約情報
７４…ユーザデータベース
７５…パッケージデータベース
７６…デバイスデータベース
７７…契約情報
７８…表示部
７９…実行部
８０…認証部
８１…提案部
８２…収集部
８３…設定部
９０…ユーザ
９１…アプリ

特開２０１６－４３０７号公報

Claims (12)

1. 契約内容の変更を提案する情報処理装置であって、
   複数のアプリケーションを利用する契約において、実行したアプリケーションの情報を蓄積する蓄積手段と、
   蓄積された前記各アプリケーションの情報から得られる各アプリケーションの実行回数に応じて、契約内容の変更を提案する提案手段と
   を含む、情報処理装置。
2. 前記提案手段が提案した案を表示する表示手段を含み、
   前記提案手段は、前記複数のアプリケーションのうち、実行回数が一定回数以下のアプリケーションを削除した案を生成し、生成した前記案を前記表示手段へ通知する、請求項１に記載の情報処理装置。
3. 前記契約は、前記複数のアプリケーションを複数のユーザが利用する契約であり、
   前記蓄積手段は、アプリケーションを実行したユーザの情報を蓄積し、
   前記提案手段は、蓄積された前記複数のアプリケーションの情報と前記複数のユーザの情報とから得られる各ユーザの各アプリケーションの実行回数に応じて、利用するユーザ数を変更した案を生成する、請求項１または２に記載の情報処理装置。
4. 前記契約内容の変更を提案する際の変更理由を作成する作成手段を含む、請求項１～３のいずれか１項に記載の情報処理装置。
5. 前記蓄積手段は、前記各アプリケーションにつき、該各アプリケーションと互換性を有するアプリケーションの有無を示す情報を蓄積し、
   前記作成手段は、前記提案手段が前記契約内容に含まれるアプリケーションの削除を提案する場合であって、削除するアプリケーションに互換性を有するアプリケーションがある場合、蓄積された前記互換性を有するアプリケーションの情報から得られる実行回数に応じて、互換性を有するアプリケーションがあることを変更理由として作成する、請求項４に記載の情報処理装置。
6. 前記蓄積手段は、前記各アプリケーションの種類を示す情報を蓄積し、
   前記作成手段は、前記提案手段が前記契約内容に含まれるアプリケーションの削除を提案する場合、蓄積された前記各アプリケーションの情報から得られる実行回数に応じて、使用していない種類のアプリケーションであることを変更理由として作成する、請求項４に記載の情報処理装置。
7. 前記蓄積手段は、前記各アプリケーションを実行する各ユーザの種類を示す情報を蓄積し、
   前記作成手段は、利用するユーザの削減を提案する場合、蓄積された前記各ユーザの前記各アプリケーションの実行回数に応じて、削減対象の種類に属するいずれのユーザも利用していないことを変更理由として作成する、請求項４に記載の情報処理装置。
8. 前記蓄積手段は、前記各アプリケーションを実行した各ユーザがゲストユーザか否かを示す情報を蓄積し、
   前記作成手段は、蓄積された前記各ユーザの前記各アプリケーションの実行回数に応じて、前記ゲストユーザのみが利用していること、または前記ゲストユーザは利用していないことを変更理由として作成する、請求項４に記載の情報処理装置。
9. 前記提案手段が提案した案へ変更するか否かの選択を受け付ける入力手段を含む、請求項１～８のいずれか１項に記載の情報処理装置。
10. サービスを提供するサービス提供システムであって、
    複数のアプリケーションを利用する契約において、実行したアプリケーションの情報を蓄積する蓄積手段と、
    蓄積された前記各アプリケーションの情報から得られる各アプリケーションの実行回数に応じて、契約内容の変更を提案する提案手段と
    を含む、サービス提供システム。
11. 契約内容の変更を提案する情報処理装置により実行される方法であって、
    複数のアプリケーションを利用する契約において、実行したアプリケーションの情報を蓄積手段に蓄積するステップと、
    蓄積された前記各アプリケーションの情報から得られる各アプリケーションの実行回数に応じて、契約内容の変更を提案するステップと
    を含む、方法。
12. 請求項１１に記載の方法に含まれる各ステップをコンピュータに実行させるためのプログラム。

Images