JP7279558B2 - ライセンス管理システム及びプログラム - Google Patents

Description

本発明は、ライセンス管理システム及びプログラムに関する。

アプリケーションプログラムのライセンス契約の形態には、個別のユーザに付与する形態の他、組織に付与する形態がある。なお、組織に付与する形態には、組織内の管理者に対して組織内のユーザにライセンスを付与する権限を与える形態もある。このため、多様なライセンス契約の形態を統一的に管理するための仕組みが先行文献に提案されている。

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

各端末にインストールされているアプリケーションプログラムは、各端末のユーザにより個別にバージョンアップされることがある。その場合、バージョンアップの作業を行ったユーザは、アプリケーションプログラムの現在のバージョンを知っている。
しかし、組織内の管理者やアプリケーションプログラムを提供する側の管理者は、ユーザが操作する個別の端末にインストールされているアプリケーションプログラムのバージョンを知りえない。
このため、ユーザの使用環境において重大な不具合を起こす可能性があるバージョンのアプリケーションプログラムがアップデートされないまま残っていたり、サポートが切れているバージョンのアプリケーションプログラムが端末に残っていたりしても、管理者はその状態に気づくことができない。

本発明は、個々のユーザが使用する端末にインストールされているアプリケーションプログラムのバージョンを管理者が確認できるようにすることを目的とする。

請求項１に記載の発明は、使用中のアプリケーションプログラムのバージョンを識別する第１の情報を生成する生成手段と、前記第１の情報を管理者に送信する送信手段と、管理の対象であるアプリケーションの前記バージョンが推奨される状態にあることを検証した結果に応じて生成されるライセンスを表す第２の情報を、前記第１の情報が識別する当該バージョンに紐付ける紐付手段と、を有し、前記第２の情報は、使用中のアプリケーションプログラムへのアクセスを禁じる情報である、ライセンス管理システムである。
請求項２に記載の発明は、前記第２の情報は、前記バージョンに紐付けられたユーザに紐付けて管理される、請求項１に記載のライセンス管理システムである。
請求項３に記載の発明は、コンピュータに、使用中のアプリケーションプログラムのバージョンを識別する第１の情報を生成する機能と、前記第１の情報を管理者に送信する機能と、管理の対象であるアプリケーションの前記バージョンが推奨される状態にあることを検証した結果に応じて生成されるライセンスを表す第２の情報を、前記第１の情報が識別する当該バージョンに紐付ける機能と、を実現させるためのプログラムであり、前記第２の情報は、使用中のアプリケーションプログラムへのアクセスを禁じる情報である、プログラムである。

請求項１記載の発明によれば、ユーザの使用環境において重大な不具合を発生させる可能性があるバージョンについては使用を休止できる。
請求項２記載の発明によれば、バージョンが変化するまで現在のバージョンの使用をユーザ単位で休止できる。
請求項３記載の発明によれば、ユーザの使用環境において重大な不具合を発生させる可能性があるバージョンについては使用を休止できる。

実施の形態に係る情報処理システムのシステム構成の例を示す図である。 情報処理システムを構成するサーバと端末装置に設けられる機能の例を説明する図である。 ライセンス契約時におけるデータ構造の例を説明する図である。 使用中のバージョンの真正性に問題が確認された場合のデータ構造の例を説明する図である。 使用中のバージョンの真正性に問題がある場合の他のデータ構造の例を説明する図である。 ライセンシーがテナントである場合のデータ構造の例を説明する図である。 アプリケーションを提供するベンダーが利用する第１端末装置とサーバとの間で実行されるアプリケーションオブジェクトの生成処理を説明する図である。 アプリケーションを提供するベンダーが利用する第１端末装置とサーバとの間で実行されるバージョンオブジェクトの生成処理を説明する図である。 アプリケーションを提供するベンダーが利用する第１端末装置とサーバとの間で実行されるライセンスオブジェクトの生成処理を説明する図である。 アプリケーションのベンダーが利用する第１端末装置とサーバとの間で実行されるライセンス等管理画面の表示処理を説明する図である。 ライセンス等管理画面の一例を示す図である。

以下、図面を参照して、本発明の実施の形態を説明する。
＜実施の形態＞
＜システム構成＞
図１は、実施の形態に係る情報処理システム１のシステム構成の例を示す図である。
図１に示す情報処理システム１は、サーバ１０と、第１端末装置３０－１と、第２端末装置３０－２と、第３端末装置３０－３とを有する。
サーバ１０と、第１端末装置３０－１と、第２端末装置３０－２と、第３端末装置３０－３は、ネットワーク２を介して互いに通信が可能である。

本実施の形態の場合、第１端末装置３０－１は、アプリケーションプログラム（以下「アプリケーション」という）のライセンサーであるベンダーが利用する装置であり、第２端末装置３０－２は、アプリケーションのライセンシーが利用する装置であり、第３端末装置３０－３は、アプリケーションを契約するテナントの管理者が利用する装置である。
テナントは、アプリケーションのライセンスを、組織等を単位として管理する場合に使用される概念である。テナントは、１つの契約に対して１つ開設される。

本実施の形態におけるライセンシーは、個人の場合とテナントの場合がある。ライセンシーがテナントの場合、契約の範囲内において、テナントの管理者が、テナントに参加するユーザにライセンスを付与する。従って、第２端末装置３０－２は、ライセンシーとしての個人が操作する端末の場合の他、テナントに参加した個人が操作する端末の両方を含んでいる。
このように、情報処理システム１は、様々なライセンス形態にも柔軟に対応が可能である。
本実施の形態では、第１端末装置３０－１、第２端末装置３０－２、第３端末装置３０－３を総称する場合、端末装置３０を使用する。

本実施の形態におけるサーバ１０は、第２端末装置３０－２にインストールされているアプリケーションのバージョンを、ベンダーの管理者やテナントの管理者に提供するサービスを提供するコンピュータである。ここでのサーバ１０は、ライセンス管理システムの一例である。
図１に示すサーバ１０は、制御部１１、記憶部１２、通信部１３を含んでいる。
制御部１１は、ＣＰＵ（＝Central Processing Unit）と、ＢＩＯＳ（＝Basic Input Output System）等が記憶されたＲＯＭ（＝Read Only Memory）と、ワークエリアとして用いられるＲＡＭ（＝Random Access Memory）等を含んでいる。
ここでの制御部１１は、記憶部１２に記憶されているプログラムの実行を通じて各種の演算や自装置を構成する各部の動きを制御する。

記憶部１２は、第２端末装置３０－２にインストールされているアプリケーションのバージョン等の情報の他、基本ソフトウェアやアプリケーション等のプログラムを記憶する。記憶部１２は、例えばハードディスクドライブで構成される。もっとも、記憶部１２は、書き換え可能な不揮発性の半導体メモリでもよい。
通信部１３は、例えばＮＩＣ（＝Network Interface Card）を含み、ＮＩＣを介してネットワーク２に接続する。

端末装置３０は、例えば制御部３１、記憶部３２、通信部３３、入力部３４、表示部３５により構成される。
制御部３１は、ＣＰＵ、ＲＯＭ、ＲＡＭ等を含み、記憶部３２に記憶されているプログラムの実行を通じて各種の演算や自装置を構成する各部の動きを制御する。
記憶部３２には、基本ソフトウェアやアプリケーション等のプログラムに加え、基本ソフトウェアやアプリケーションで扱うデータが記憶される。記憶部３２は、例えばハードディスクドライブで構成される。記憶部３２は、書き換え可能な不揮発性の半導体メモリでもよい。
通信部３３は、例えばＮＩＣを含み、ＮＩＣを介してネットワーク２に接続する。

入力部３４は、例えばキーボード、マウス、タッチパネル等の入力デバイスで構成され、ユーザからの操作の受け付けに使用される。
表示部３５は、例えば液晶ディスプレイや有機ＥＬ（＝Electro Luminescence）ディスプレイで構成され、制御部３１により生成される画像を表示する。
なお、入力部３４及び表示部３５は、端末装置３０の周辺装置として装置本体に外付けされていてもよい。

＜サーバ１０によるデータ管理＞
本実施形態におけるサーバ１０は、プロトタイプをベースとしてオブジェクトを管理する。プロトタイプとは、新たな子オブジェクトの生成が可能なオブジェクトをいう。従って、子オブジェクトの側から見ると、自身の元になった親オブジェクトがプロトタイプである。
プロトタイプベースは、プロトタイプをベースとしてオブジェクトを扱う手法をいう。プロトタイプベースのオブジェクトは、オブジェクトの集合に唯一存在するルートオブジェクトを除けば、ただ１つのプロトタイプを持つ。なお、ルートオブジェクトは、自身のプロトタイプを持たない。

また、オブジェクトＡがオブジェクトＢのプロトタイプであるとき、オブジェクトＢを、オブジェクトＡのアーティファクト又は子オブジェクトという。
オブジェクト間のプロトタイプ関係により、プロトタイプベースのオブジェクトの集合は木構造で表現される。また、オブジェクトにより構成される木構造を破壊しないならば、プロトタイプを再接続することで木構造の変形が可能である。

サーバ１０で管理するオブジェクトには、属性及び属性値を持たせることが可能である。
ＲＥＳＴ（＝REpresentational State Transfer）アーキテクチャスタイルにおいては、オブジェクトをリソース、値を表現と呼ぶことがある。
オブジェクトには、単にオブジェクト識別子とプロトタイプのみからなる純粋なアイデンティティを表す情報、コンテント型の値を持つデータを表す情報、アクセス資格を証明するクレデンシャル情報を含むアクセストークン、オブジェクトにアクセスするアプリケーションの１つ又は複数が含まれる。アクセストークンは、アクセスの権限に関する情報が関連付けられるオブジェクトともいえる。
これらのオブジェクトが１つの木構造に含まれる。

また、バージョントークンは、管理の対象であるアプリケーションのバージョンを識別する情報が関連付けられるオブジェクトともいえる。バージョントークンは第１の情報の一例である。
また、ライセンストークンは、バージョンの真正性を検証した結果に応じて生成される情報が関連付けられるオブジェクトともいえる。ライセンストークンは、第２の情報の一例である。
本実施の形態の場合、真正性とは、管理の対象であるアプリケーションのバージョンが推奨される状態にあること、より具体的には、管理の対象であるアプリケーションのバージョンと基本ソフトウェアとの組み合わせが適正であること、使用中のアプリケーションのバージョンとベンダーがサポートの対象とするバージョンとの組み合わせが適正であること、管理の対象であるアプリケーションのバージョンに対するライセンスが適正であること等をいう。

適正なバージョンのアプリケーションの利用には何の問題も生じないが、適正でないバージョンのアプリケーションの利用には何らかの制限が必要である。
本実施の形態では、ユーザの利便性を考慮し、適正でないアプリケーションの利用を２段階で制御する。
１つは、利用できる期間を、アップデートやアンインストール等に必要な期間に限定する制御であり、他の１つは、アプリケーションの利用を即座に禁止する制御である。
本実施の形態では、前者の制御用に期限付きのアクセストークンを使用する。以下では、期限付きのアクセストークンを、インテリムトークン（＝interimToken）と呼ぶ。
また、後者の制御用に休止トークンを使用する。以下では、休止トークンを、ハイバネイショントークン（hibernationToken）と呼ぶ。

本実施の形態におけるサーバ１０は、リクエストに含まれるトークンの検証に成功した場合、トークンに対応する権限の範囲（以下「スコープ」ともいう）で、受け付けたリクエストを処理する。例えばアクセストークンにより特定されるスコープに基づき、オブジェクトの生成、オブジェクトの参照、オブジェクトの更新及びオブジェクトの削除等のいずれかを認可又は不認可する。
また例えばサーバ１０は、端末装置３０から受け付けたリクエストに従って、管理するオブジェクトの追加、更新、情報の読み出し、削除等を実行する。

＜情報処理システム１において実現される機能＞
図２は、情報処理システム１を構成するサーバ１０と端末装置３０に設けられる機能の例を説明する図である。
図２に示すサーバ１０には、プロトタイプベースのオブジェクトの情報を管理するデータ格納部１０１と、端末装置３０からリクエストを受信するリクエスト受信部１０２と、受信したリクエストに含まれるトークンを検証するトークン検証部１０３と、検証が成功した適正なトークンから取り出されたスコープを実行するスコープ実行部１０４と、リクエストから取り出したスコープを実行した結果又はトークンの検証の失敗を端末装置３０に返信するレスポンス送信部１０５とが設けられている。ここでのレスポンス送信部１０５は、送信手段の一例である。

データ格納部１０１には、オブジェクトを記憶するオブジェクトストア１１１と、データを記憶するデータストア１１２と、端末装置３０にインストールされているアプリケーションのバージョンを管理するバージョン管理テーブル１１３と、バージョンの整合性を管理するバージョン整合性情報１１４とが記憶されている。
本実施の形態におけるスコープ実行部１０４は、受信したリクエストを処理するための複数のサブ機能を含んでいる。もっとも、サブ機能の一部は、スコープ実行部１０４とは別に設けてもよい。

サブ機能の１つは、オブジェクト生成機能１４１である。
オブジェクト生成機能１４１は、例えばトークンで指定されたオーナ（すなわち所有者の情報）を親オブジェクトとするバージョンオブジェクトを生成する機能である。オブジェクト生成機能１４１は、生成手段の一例である。
サブ機能の他の１つは、オブジェクト変更機能１４２である。
オブジェクト変更機能１４２は、例えばトークンで指定されたオーナの子オブジェクトであるバージョンオブジェクトを変更する機能である。

サブ機能の他の１つは、オブジェクト取得機能１４３である。
オブジェクト取得機能１４３は、指定されたオブジェクトのrevokedAt属性が無定義の場合、etag属性から値のデータを取得する機能である。因みに、etag属性は、オブジェクトのデータ内容を格納したデータオブジェクトの識別情報を表す。
サブ機能の他の１つは、バージョン紐付け機能１４４である。
バージョン紐付け機能１４４は、バージョンをライセンスに紐付ける機能である。バージョン紐付け機能１４４は、紐付手段の一例である。
サブ機能の他の１つは、バージョンオブジェクト可視化機能１４５である。
バージョンオブジェクト可視化機能１４５は、アプリケーションのバージョンやライセンス等の情報を、管理者が操作する端末装置３０の画面に表示する機能である。バージョンオブジェクト可視化機能１４５は、管理手段の一例である。
図２に示す端末装置３０には、サーバ１０にリクエストを送信するリクエスト送信部３０１と、サーバ１０からのレスポンスを受信するレスポンス受信部３０２と、受信したレスポンスの表示や新たなリクエストの生成等を制御する制御部３０３とが設けられている。

＜プロトタイプベースのオブジェクトの具体例＞
＜ライセンシーがユーザの場合のデータ構造＞
図３は、ライセンス契約時におけるデータ構造の例を説明する図である。ライセンス契約時とは、例えばライセンス契約の締結による課金処理が完了した時点をいう。ここでの時点は、ライセンス契約の際の一例である。
前述したように、プロトタイプベースのオブジェクトの親子関係は木構造で表現される。
図３の場合、「root」オブジェクトＤ１の子オブジェクトとして、「apl」オブジェクトＤ２と「vendor」オブジェクトＤ３が設けられている。「vendor」オブジェクトＤ３は、ライセンス契約の対象であるアプリケーションのベンダーに対応する。

「apl」オブジェクトＤ２には、その子オブジェクトとして、「authLicenseScope」オブジェクトＤ４と「verifyTokenScope」オブジェクトＤ５が設けられている。
ここで、「authLicenseScope」オブジェクトＤ４は、ライセンス認証のスコープに対応し、「verifyTokenScope」オブジェクトＤ５は、トークン検証のスコープに対応するオブジェクトである。

「vendor」オブジェクトＤ３には、その子オブジェクトとして、「application」オブジェクトＤ６が設けられている。
「application」オブジェクトＤ６は、ライセンスの対象であるアプリケーションに対応するオブジェクトである。
更に、「application」オブジェクトＤ６には、その子オブジェクトとして、「user」オブジェクトＤ７と、「version」オブジェクトＤ８と、「VerifyToken」オブジェクトＤ９が設けられている。
「user」オブジェクトＤ７は、ライセンシーに対応する。この「user」オブジェクトＤ７には、その子オブジェクトとして、「licenseToken」オブジェクトＤ１０が設けられている。「licenseToken」オブジェクトＤ１０は、ユーザに付与されたライセンスに対応する。
ここでの「version」オブジェクトＤ８は、ライセンス契約時に生成される、アプリケーションのバージョンを表すオブジェクトである。「verifyToken」オブジェクトＤ９は、リクエストに含まれるトークンの真正性を検証するトークンであり、「application」オブジェクトＤ６の生成時に生成される。

「version」オブジェクトＤ８には、その子オブジェクトとして、「versionToken」オブジェクトＤ１１と、「LicenseUsage」オブジェクトＤ１２と、「auth License And Log Scope」オブジェクトＤ１３と、「userOnVersion」オブジェクトＤ１４が設けられている。
ここでの「LicenseUsage」オブジェクトＤ１２は、ライセンスの有効性の判定に用いる情報を表すオブジェクトである。また、「userOnVersion」オブジェクトＤ１４は、ライセンスされたユーザに対応するオブジェクトである。「userOnVersion」オブジェクトＤ１４には、その子オブジェクトとして、「licenseToken」オブジェクトＤ１５が設けられている。「licenseToken」オブジェクトＤ１５は、ユーザに付与されたライセンスを表現するトークンに対応するオブジェクトである。

図４は、使用中のバージョンの真正性に問題が確認された場合のデータ構造の例を説明する図である。
図４には、図３との対応部分に対応する符号を付して示している。
図４に示すデータ構造は、ユーザの利用が、期限付きの暫定ライセンスでの使用である場合に用いられる。
図４では、図３における「licenseToken」オブジェクトＤ１５の内容が、「interimToken」オブジェクトＤ１６に変更されている。「interimToken」オブジェクトＤ１６は、アップデートやアンインストール等に必要な期間に限り、ユーザによる現在のバージョンの利用を許可する暫定ライセンスを表すオブジェクトである。

図５は、使用中のバージョンの真正性に問題がある場合の他のデータ構造の例を説明する図である。
図５も、図３との対応部分に対応する符号を付して示している。
図５に示すデータ構造は、ユーザに対して休止ライセンスが適用される場合に用いられる。
図５では、図３における「licenseToken」オブジェクトＤ１５の内容が、「hibernationToken」オブジェクトＤ１７に変更されている。「hibernationToken」オブジェクトＤ１７は、現在のバージョンによるアプリケーションの利用を認められない場合等に用いる休止ライセンスを表すオブジェクトである。

＜ライセンシーがテナントの場合のデータ構造＞
図３～図５は、ライセンシーが個人の場合を想定したが、ここではライセンシーがテナントである場合について説明する。
図６は、ライセンシーがテナントである場合のデータ構造の例を説明する図である。
図６にも、図３との対応部分に対応する符号を付して示している。図６に示すデータ構造は、ライセンス契約時におけるデータ構造の例である。
図６の場合、「application」オブジェクトＤ６の子オブジェクトとして、「version」オブジェクトＤ８の代わりに「tenant」オブジェクトＤ２１が設けられる点で図３のデータ構造と相違する。
ここでの「tenant」オブジェクトＤ２１は、ライセンス契約時に生成されるテナントに対応するオブジェクトである。

「tenant」オブジェクトＤ２１には、その子オブジェクトとして、「tenantToken」オブジェクトＤ２２と、「LicenseUsage」オブジェクトＤ１２と、「tenant」オブジェクトＤ２３と、「userInTenant」オブジェクトＤ２４が設けられる。
「tenantToken」オブジェクトＤ２２は、テナントに付与されたライセンスに対応する。
「tenant」オブジェクトＤ２３は、テナントの契約者を表すオブジェクトである。この「tenant」オブジェクトＤ２３には、その子オブジェクトとして、「tenantToken」オブジェクトＤ２５が設けられる。「tenantToken」オブジェクトＤ２５は、テナントに付与されたライセンスに対応する。
「userInTenant」オブジェクトＤ２４は、テナントに属するライセンスされたユーザに対応するオブジェクトである。この「userInTenant」オブジェクトＤ２４には、その子オブジェクトとして、「versionToken」オブジェクトＤ２６が設けられる。「versionToken」オブジェクトＤ２６は、テナント内のユーザに付与されたバージョンを表現するトークンに対応する。

＜情報処理システム１で実行される処理動作＞
以下では、情報処理システム１で実行される処理動作の具体例を説明する。
＜アプリケーションオブジェクトの生成＞
図７は、アプリケーションを提供するベンダーが利用する第１端末装置３０－１とサーバ１０との間で実行されるアプリケーションオブジェクトの生成処理を説明する図である。図中に示す記号のＳはステップを意味する。

まず、第１端末装置３０－１が、サーバ１０に対し、アプリケーションオブジェクト（すなわち「application」オブジェクトＤ６）の生成をリクエストする（ステップ３０１）。
具体的には、第１端末装置３０－１が、「vendor」オブジェクトＤ３の子オブジェクトとしてのアプリケーションオブジェクトの生成をサーバ１０にリクエストする。
サーバ１０は、第１端末装置３０－１からアプリケーションオブジェクトの生成を求めるリクエストを受信すると（Ｓ１０１）、トークン検証部１０３（図２参照）でリクエストに含まれるアクセストークンを検証し、検証が成功した場合に、スコープ実行部１０４（図２参照）においてアプリケーションオブジェクトを生成する（Ｓ１０２）。アプリケーションオブジェクトは、オブジェクトストア１１１（図２参照）に生成される。
次に、サーバ１０は、生成したアプリケーションオブジェクトのＩＤ（すなわちオブジェクトＩＤ）を第１端末装置３０－１に対して送信する（Ｓ１０３）。

一方、第１端末装置３０－１は、サーバ１０からのレスポンスとして、オブジェクトＩＤを受信する（Ｓ３０２）。
次に、第１端末装置３０－１は、サーバ１０に対し、アプリケーションオブジェクト（すなわち「application」オブジェクトＤ６）の子オブジェクトを生成するためのトークン（すなわちアプリケーショントークン）の生成をサーバ１０にリクエストする（Ｓ３０３）。
サーバ１０は、第１端末装置３０－１からアプリケーショントークンの生成を求めるリクエストを受信すると（Ｓ１０４）、リクエストに含まれるアクセストークンを検証し、検証が成功した場合に、アプリケーショントークンを生成する（Ｓ１０５）。
次に、サーバ１０は、上述したアプリケーショントークンのＩＤ（すなわちトークンＩＤ）を第１端末装置３０－１に対して送信する（Ｓ１０６）。

一方、第１端末装置３０－１は、サーバ１０からのレスポンスとして、トークンＩＤを受信する（Ｓ３０４）。
この後、第１端末装置３０－１は、サーバ１０に対し、検証トークン（すなわち「VerifyToken」オブジェクトＤ９）の生成をリクエストする（Ｓ３０５）。検証トークンは、インストーラやアプリケーションに埋め込まれるトークン（例えばバージョントークン）を検証するために使用されるトークンであり、アプリケーションオブジェクト毎に定義される。
サーバ１０は、第１端末装置３０－１から検証トークンの生成を求めるリクエストを受信すると（Ｓ１０７）、リクエストに含まれるアクセストークンを検証し、検証が成功した場合に、検証トークンを生成する（Ｓ１０８）。検証トークンは、オブジェクトストア１１１（図２参照）に生成される。
次に、サーバ１０は、上述した検証トークンのＩＤ（すなわちトークンＩＤ）を第１端末装置３０－１に対して送信する（Ｓ１０９）。
一方、第１端末装置３０－１は、サーバ１０からのレスポンスとして、トークンＩＤを受信する（Ｓ３０６）。

＜バージョンオブジェクトの生成＞
図８は、アプリケーションを提供するベンダーが利用する第１端末装置３０－１とサーバ１０との間で実行されるバージョンオブジェクトの生成処理を説明する図である。
バージョンオブジェクトは、ベンダーがユーザとライセンス契約を結ぶ場合に生成される。図中に示す記号のＳはステップを意味する。

まず、第１端末装置３０－１が、サーバ１０に対し、バージョンオブジェクト（すなわち「version」オブジェクトＤ８）の生成をリクエストする（ステップ３１１）。
具体的には、第１端末装置３０－１が、「application」オブジェクトＤ６の子オブジェクトとしてのバージョンオブジェクトの生成をサーバ１０にリクエストする。このリクエストには、アクセストークンが含まれている。
サーバ１０は、第１端末装置３０－１からバージョンオブジェクトの生成を求めるリクエストを受信すると（Ｓ１１１）、トークン検証部１０３（図２参照）でリクエストに含まれるアクセストークンを検証し、検証が成功した場合に、スコープ実行部１０４（図２参照）においてバージョンオブジェクトを生成する（Ｓ１１２）。アプリケーションオブジェクトは、オブジェクトストア１１１（図２参照）に生成される。

バージョンオブジェクトには、メジャーバージョン、マイナーバージョン、組み合わせ情報が設定される。組み合わせ情報には、ライセンス契約の対象であるアプリケーションの動作が可能な基本ソフトウェア等の情報が含まれる。組み合わせ情報には、ライセンス契約時に確認された情報が記憶される他、不図示のサーバに対する確認により情報に変更がある場合には更新される。
次に、サーバ１０は、生成したバージョンオブジェクトのＩＤ（すなわちオブジェクトＩＤ）を第１端末装置３０－１に対して送信する（Ｓ１１３）。

一方、第１端末装置３０－１は、サーバ１０からのレスポンスとして、バージョンオブジェクトのＩＤを受信する（Ｓ３１２）。
次に、第１端末装置３０－１は、サーバ１０に対し、バージョントークン（すなわち「versionToken」オブジェクトＤ１１）の生成をリクエストする（Ｓ３１３）。具体的には、第１端末装置３０－１が、「version」オブジェクトＤ８の子オブジェクトとしてのバージョントークンの生成をサーバ１０にリクエストする。バージョントークンは、ライセンス契約の対象であるアプリケーションのバージョンの識別情報である。

サーバ１０は、第１端末装置３０－１からバージョントークンの生成を求めるリクエストを受信すると（Ｓ１１４）、リクエストに含まれるアクセストークンを検証し、検証が成功した場合に、バージョントークンを生成する（Ｓ１１５）。バージョントークンは、オブジェクトストア１１１（図２参照）に生成される。
次に、サーバ１０は、上述したバージョントークンのＩＤ（トークンＩＤ）を第１端末装置３０－１に対して送信する（Ｓ１１６）。
第１端末装置３０－１は、サーバ１０からのレスポンスとして、トークンＩＤを受信する（Ｓ３１４）。

＜ライセンスオブジェクトの登録＞
図９は、アプリケーションを提供するベンダーが利用する第１端末装置３０－１とサーバ１０との間で実行されるライセンスオブジェクトの生成処理を説明する図である。
ライセンスオブジェクトも、ベンダーがユーザとライセンス契約を結ぶ場合に生成される。図中に示す記号のＳはステップを意味する。

まず、第１端末装置３０－１が、サーバ１０に対し、ユーザオブジェクト（すなわち「userOnVersion」オブジェクトＤ１４）の生成をリクエストする（Ｓ３２１）。
具体的には、第１端末装置３０－１が、「version」オブジェクトＤ８の子オブジェクトとして、ユーザオブジェクトの生成をサーバ１０にリクエストする。このリクエストには、アクセストークンが含まれている。
サーバ１０は、第１端末装置３０－１からユーザオブジェクトの生成を求めるリクエストを受信すると（Ｓ１２１）、トークン検証部１０３（図２参照）でリクエストに含まれるアクセストークンを検証し、検証が成功した場合に、スコープ実行部１０４（図２参照）においてユーザオブジェクトを生成する（Ｓ１２２）。ユーザオブジェクトは、オブジェクトストア１１１（図２参照）に生成される。ユーザオブジェクトには、ユーザの属性情報が設定される。

次に、サーバ１０は、生成したバージョンオブジェクトのＩＤ（すなわちオブジェクトＩＤ）を第１端末装置３０－１に対して送信する（Ｓ１２３）。
一方、第１端末装置３０－１は、サーバ１０からのレスポンスとして、オブジェクトＩＤを受信する（Ｓ３２２）。
次に、第１端末装置３０－１は、サーバ１０に対し、ライセンストークン（すなわち「licenseToken」オブジェクトＤ１５）の生成をリクエストする（Ｓ３２３）。具体的には、第１端末装置３０－１が、「userOnVersion」オブジェクトＤ１４の子オブジェクトとしてのライセンストークンの生成をサーバ１０にリクエストする。ライセンストークンは、バージョンに付与されている現在のライセンスを表す。

なお、使用中のアプリケーションのバージョンの真正性が検証された結果として、使用中のアプリケーションのバージョンが適正でないと確認された場合、ユーザオブジェクトの子オブジェクトとしてインテリムオブジェクト（すなわち「interimToken」オブジェクトＤ１６）又はハイバネーションオブジェクト（すなわち「hibernationToken」オブジェクトＤ１７）が生成される。
次に、サーバ１０は、上述したライセンストークンのＩＤ（トークンＩＤ）を第１端末装置３０－１に対して送信する（Ｓ１２６）。
第１端末装置３０－１は、サーバ１０からのレスポンスとして、トークンＩＤを受信する（Ｓ３２４）。

図７～図９は、ライセンシーが個人である場合のデータ構造を想定しているが、ライセンシーがテナントである場合にも、同様の手順によるバージョンの管理やライセンスの管理が可能である。
ただし、テナントに参加している個々のユーザが使用する第２端末装置３０－２にインストールされているアプリケーションのバージョンを表現するトークンは、「userInTenant」オブジェクトＤ２４の子オブジェクトである「versionToken」オブジェクトＤ２６に生成される。

＜ライセンス等管理画面の表示＞
図１０は、アプリケーションのベンダーが利用する第１端末装置３０－１とサーバ１０との間で実行されるライセンス等管理画面の表示処理を説明する図である。
図１０に示す処理は、ライセンス契約後の任意の時点に実行される。
まず、第１端末装置３０－１が、サーバ１０に対し、ライセンス等管理画面の表示をリクエストする（Ｓ３３１）。このリクエストには、バージョントークン（すなわち「versionToken」オブジェクトＤ１１）が含まれる。

サーバ１０は、第１端末装置３０－１からライセンス等管理画面の表示を求めるリクエストを受信すると（ステップ１３１）、リクエストに含まれるバージョントークンを検証し、検証が成功した場合に、ライセンス等管理画面を生成する（Ｓ１３２）。
この後、サーバ１０は、生成したライセンス等管理画面を第１端末装置３０－１に対して送信する（Ｓ１３３）。
第１端末装置３０－１は、サーバ１０からのレスポンスとして、ライセンス等管理画面を受信する（Ｓ３３２）。
次に、第１端末装置３０－１は、受信したライセンス等管理画面を表示する（Ｓ３３３）。

図１１は、ライセンス等管理画面４００の一例を示す図である。
図１１に示すライセンス等管理画面４００は、検索の対象の指定に用いる入力欄と検索の実行ボタンが表示される領域４０１と、検索結果の表示欄４０２とを含んでいる。
図１１の場合、領域４０１において、検索の対象として「テナント内全ての商品」が指定されている。
図１１に示す表示欄４０２は、購入者４１１、シリアル番号４１２、商品４１３、ライセンス数４１４、バージョン４１５、使用数４１６、お知らせ４１７で構成される。
ここでの購入者４１１は、テナント内で商品４１３を使用しているユーザである。図１１の場合、「富士次郎」と「富士太郎」の２名である。

シリアル番号４１２は、商品４１３であるアプリケーションの個体を識別する番号である。
商品４１３は、アプリケーションの名称である。図１１の場合、「認証連携アプリ」、「ペーパーレスファックスアプリ」、「ドキュメントアプリ」の３つである。
ライセンス数４１４は、テナントが有するアプリケーション別のライセンスの数である。例えば「認証連携アプリ」と「ペーパーレスファックスアプリ」にはそれぞれ１つのライセンスが与えられている。また、「ドキュメントアプリ」には１０のライセンスが与えられている。
バージョン４１５は、購入者４１１が利用している商品４１３のバージョンである。例えば富士次郎さんが利用している「認証連携アプリ」のバージョン４１５は「１．０．２」である。
使用数４１６は、各商品４１３がテナント内で使用されている数である。図１１の場合、いずれの商品も１つだけ使用されている。

お知らせ４１７には、各ユーザが使用している商品４１３に関する情報が表示される。お知らせ４１７には、例えば商品４１３の使用の状況と推奨される使用の状況との差分を知らせる情報、差分に応じた管理の状態等が表示される。図１１の場合、富士太郎さんが使用中の「ペーパレスファックスアプリ」には、暫定ライセンスが付与されていることが分かる。また、富士次郎さんが使用中の「ドキュメントアプリ」は、利用不可バージョンであることが分かる。

このライセンス等管理画面４００は、テナントの管理者に対し、テナント内のユーザ（すなわち購入者４１１）が利用しているアプリケーションのバージョン４１５の確認を可能にする。
また、ライセンス等管理画面４００は、使用中のバージョンが推奨される状態か否かのお知らせ４１７を通じ、テナントの管理者に、アップデートやバージョンアップ等の対応を促すことを可能にする。
なお、ライセンス等管理画面４００は、ライセンサーであるベンダーが利用する第１端末装置３０－１でも、ライセンシーである個人のユーザが利用する第２端末装置３０－２でも表示することが可能である。

＜他の実施の形態＞
以上、本発明の実施の形態について説明したが、本発明の技術的範囲は前述した実施の形態に記載の範囲に限定されない。前述した実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。

１…情報処理システム、２…ネットワーク、１０…サーバ、３０…端末装置、３０－１…第１端末装置、３０－２…第２端末装置、３０－３…第３端末装置、１０２…リクエスト受信部、１０３…トークン検証部、１０４…スコープ実行部、１０５…レスポンス送信部、３０１…リクエスト送信部、３０２…レスポンス受信部、３０３…制御部、１１１…オブジェクトストア、１１２…データストア、１１３…バージョン管理テーブル、１１４…バージョン整合性情報、１４１…オブジェクト生成機能、１４２…オブジェクト変更機能、１４３…オブジェクト取得機能、１４４…バージョン紐付け機能、１４５…バージョンオブジェクト可視化機能、４００…ライセンス等管理画面

Claims (3)

1. 使用中のアプリケーションプログラムのバージョンを識別する第１の情報を生成する生成手段と、
   前記第１の情報を管理者に送信する送信手段と、
   管理の対象であるアプリケーションの前記バージョンが推奨される状態にあることを検証した結果に応じて生成されるライセンスを表す第２の情報を、前記第１の情報が識別する当該バージョンに紐付ける紐付手段と、
   を有し、
   前記第２の情報は、使用中のアプリケーションプログラムへのアクセスを禁じる情報である、ライセンス管理システム。
2. 前記第２の情報は、前記バージョンに紐付けられたユーザに紐付けて管理される、請求項１に記載のライセンス管理システム。
3. コンピュータに、
   使用中のアプリケーションプログラムのバージョンを識別する第１の情報を生成する機能と、
   前記第１の情報を管理者に送信する機能と、
   管理の対象であるアプリケーションの前記バージョンが推奨される状態にあることを検証した結果に応じて生成されるライセンスを表す第２の情報を、前記第１の情報が識別する当該バージョンに紐付ける機能と、
   を実現させるためのプログラムであり、
   前記第２の情報は、使用中のアプリケーションプログラムへのアクセスを禁じる情報である、プログラム。

Images