JP2006517697A

JP2006517697A - 使用後支払いビジネスモデルに対し構成可能なソフトウェアライセンス管理システム

Info

Publication number: JP2006517697A
Application number: JP2005518480A
Authority: JP
Inventors: ミラベラ，リチャード
Original assignee: マクロビジョン・コーポレーション
Priority date: 2003-02-14
Filing date: 2004-02-02
Publication date: 2006-07-27
Also published as: CA2514785A1; EP1599817A1; WO2004075088A1; TW200502818A; KR100740446B1; CN1751316A; KR20060079139A; US20040167859A1; AU2004214234A1

Abstract

使用後支払いビジネスモデル用に構成されたソフトウェアライセンス管理システムが説明される。フロントエンドサーバは、当該フロントエンドサーバを含むネットワーク内のコンピュータ上に分散されるライセンスされたソフトウェアの利用を制御し、通知スケジュールに従ってそのような利用の認証可能通知を生成し、ベンダにより指定された宛先に認証可能通知を安全に送信するよう構成される。当該宛先に対応するバックエンドサーバは、認証可能通知の受信、認証及び処理を行って処理情報を生成し、使用後支払いビジネスモデル用及びソフトウェアベンダの他の業務処理用の業務処理ソフトウェアに処理情報を提供するよう構成される。

Description

発明の詳細な説明

［発明の技術分野］
本発明は、一般にソフトウェアライセンス管理システムに関し、より詳細には、使用後支払いビジネスモデル（ｐｏｓｔ−ｕｓｅｐａｙｍｅｎｔｂｕｓｉｎｅｓｓｍｏｄｅｌ）用に構成可能なソフトウェアライセンス管理システムに関する。

［発明の背景］
従来のソフトウェアライセンス管理システムは、ライセンスマネージャを利用してライセンスされたソフトウェアの利用をそれのライセンス条件に従って管理する（または管理を支援する）。このようなライセンスマネージャの一例として、カリフォルニア州サンタクララに本社を置くマクロビジョンコーポレイションの製品であるＦＬＥＸｌｍ（登録商標）がある。

サービス拒否は、ライセンスされたソフトウェアの利用がそれのライセンス条件内にあるということを適切に保証するため（例えば、システムが「ハッキング」されていないと仮定する）、ソフトウェアライセンス管理システムにおいて一般的に用いられる技術である。この技術を利用して、ライセンスされたソフトウェアと協調することによりライセンス管理システムは、ライセンス条件を超過したユーザリクエストを単に拒否する。例えば、ソフトウェアライセンスが期間ライセンスである場合、当該期間の経過後のソフトウェアの利用またはアクセスを行うリクエストは、拒否されるであろう。他の例として、ソフトウェアライセンスが同時使用ユーザ数ライセンスである場合、同時に使用するユーザの最大数に達した後のソフトウェアの利用またはアクセスを行うリクエストは、拒否されるであろう。これらのシステムでは、ライセンスはライセンスされたソフトウェアのライセンス条件を超える。ライセンスがユーザリクエストを許可することにより超える場合、当該情報はライセンスされたソフトウェアに通信され、これにより当該リクエストは拒否される。

しかしながら特定のアプリケーションでは、ライセンスの受け手はサービスの拒否を許容できないライセンス履行であると考える。例えば、人命や財産が重大な危険状態にある基幹アプリケーションにおけるサービスの拒否は、一般には許容できないものである。また、サービスの中断から重大なビジネスへの悪影響が生じるビジネスアプリケーションでもまた、サービスの拒否は許容できないものである。他の例として、ソフトウェアに対する予想外のピーク要求が生じるアプリケーションがあり、ソフトウェアに対する要求は、追加的なライセンスの購入を待機する必要がある場合には戻されない。

これらのアプリケーションでは、それのソフトウェアをライセンスするため、ライセンス許諾者は、ライセンス管理者によりユーザリクエストがライセンス条件を超えたと決定されたにも関わらず、サービスの提供を継続するようライセンスされたソフトウェアを設定したり、あるいは単にライセンスマネージャを不可または削除とするよう一般には強制される。このように継続されたサービスには警告や減縮された（主要なもののみ）機能が与えられるかもしれないが、ライセンス許諾者がこのような延長された利用に対する補償を受けることを適切に確実とするための機構は、このようなシステムにはない。従って、これらのシステムは、ライセンスの受け手が警告に従い、追加的な利用に対するライセンス許諾者からの権利を以降に購入することを信頼する信頼に基づくシステムとなりがちである。

このような延長された利用（ここではまた「超過利用（ｏｖｅｒｕｓａｇｅ）」と呼ぶ）に対する補償をライセンス許諾者が受け取ることを適切に補償する機構は、ライセンスの受け手による利用がそれのライセンス条件を超えるという警告を単に無視するライセンスの受け手を処理するため、ライセンス許諾者にとって有用なものとなるであろう。このような機構は、ライセンス許諾者とライセンスの受けての双方にとって公平なものであり、必要または特に効果的である場合には、ライセンスの受け手がライセンスされたソフトウェアをそれのライセンス条件を超えて利用するのを防ぐものではない。当事者間の契約上のビジネス条件と組み合わされたこのような機構はまた、ライセンスの受け手を犠牲にしてライセンス許諾者に有利なサービス拒否技術と、ライセンス許諾者を犠牲にしてライセンスの受け手に有利な信頼に基づく技術との間の公平な妥協となるであろう。従って、このような機構は、ライセンス許諾者やソフトウェアベンダの収入を増加させると共に、ライセンスの受け手やソフトウェアカスタマーの満足度を向上させるものとなるであろう。

従って、上記及び他のアプリケーションにおいて、ソフトウェアをライセンスするための使用後支払い（ＰＵＰ）ビジネスモデルが、サービス拒否または信頼ベースライセンス管理スキームの有用な代替となる。このライセンシングモデルでは、超過利用が許可されてから（すなわち、ライセンスされたソフトウェアの利用が、ライセンス条件で規定された限度を超えることを許容する）、超過利用を追跡する必要があり、これにより、カスタマーまたはライセンスの受け手は、ペイ・パー・ユーズ（ｐａｙ−ｐｅｒ−ｕｓｅ）ライセンシングスキームによるこのような超過利用に対し最終的に課金されたり、あるいはそれまでの利用に基づき追加的なライセンスが販売されることが可能となる。

［発明の課題及び概要］
従って、本発明の課題は、使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムを提供することである。

他の課題は、ライセンスされたソフトウェアのライセンス許諾者またはライセンスの受け手に対する過度な負担を課することのない実際的なレベルのセキュリティを提供するある範囲内の使用後支払いビジネスモデルに対し構成可能なソフトウェアライセンス管理システムを提供することである。

他の課題は、信頼できる使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムを提供することである。

他の課題は、認証可能な通知を作成し、当該通知をベンダにより指定された送信先に所定の回数送信する使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムを提供することである。

上記及び他の課題が、本発明の各特徴により伴われ、簡潔に述べると一特徴は、使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムであって、ライセンスされたソフトウェアの利用を制御し、通知スケジュールに従って前記利用に関する情報を含む認証可能通知を生成し、前記認証可能通知を指定された宛先に安全に送信するよう構成されるフロントエンドサーバと、前記指定された宛先に対応し、前記認証可能通知を受信、認証及び処理して処理情報を生成し、使用後支払いビジネスモデル用の業務処理に前記処理情報を提供するよう構成されるバックエンドサーバとから構成されることを特徴とするシステムである。

他の特徴は、使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムであって、通知スケジュールに従ってカスタマーによるライセンスされたソフトウェアの利用に関する情報を含む認証可能通知を生成し、前記ライセンスされたソフトウェアのベンダにより指定された宛先に前記認証可能通知を安全に送信する手段と、前記宛先に対応し、前記認証可能通知の受信、認証及び処理を行って使用後支払いビジネスモデル用の業務処理ソフトウェアに提供される処理情報を生成する手段とから構成されることを特徴とするシステムである。

さらなる他の特徴は、使用後支払いビジネスモデル用のライセンスされたソフトウェアの利用を通知する方法であって、通知スケジュールに従ってライセンス受け手によるライセンスされたソフトウェアの利用に関する情報を含む認証可能通知を生成するステップと、前記認証可能通知をカスタマーにより指定されたソースからベンダにより指定された宛先に送信するステップと、前記認証可能通知を前記ベンダにより指定された宛先において受信及び認証するステップと、認証されると、使用後支払いビジネスモデル用の業務処理ソフトウェアに提供されるよう前記認証された通知から処理情報を生成するステップと、
から構成されることを特徴とする方法である。

他の特徴は、ライセンスされたソフトウェアのライセンス条件を超えた超過利用を条件付きで許可し、前記超過利用の情報を含む認証可能通知を生成し、使用後支払いビジネスモデル用の宛先に前記認証可能通知を送信するよう構成される少なくとも１つのコンピュータから構成されることを特徴とする装置である。

他の特徴は、ライセンスされたソフトウェアの利用を通知する方法であって、複数の認証可能通知の各々が、ソフトウェアモジュールにより生成される前記複数の認証可能通知の直前及び直後のものと重複する複数の期間におけるライセンスされたソフトウェアの利用に関する情報を含むように、前記複数の認証可能通知をスケジュールされた時点に生成するよう構成されるソフトウェアモジュールを提供するステップを有することを特徴とする方法である。

さらなる他の特徴は、ライセンスされたソフトウェアの利用を通知する方法であって、ユーザまたは計数されるコンピュータリソースのＮ，Ｎ−１，Ｎ−２，．．．，Ｍが前記ライセンスされたソフトウェアのある機能を用いてアクティブとされているとき、合計時間が通知期間を超えるように、構成された前記ライセンスされたソフトウェアの利用に関する情報を含む認証可能通知を生成するよう構成されるソフトウェアモジュールを提供するステップから構成される（ただし、Ｎは前記通知期間における前記機能を同時に利用する前記計数されたコンピュータリソースまたはユーザの最大数であり、Ｍはゼロ以上の整数である）ことを特徴とする方法である。

他の特徴は、ライセンスされたソフトウェアの超過利用に関する情報を含む認証可能通知を安全に受信し、使用後支払いビジネスモデル用の業務処理ソフトウェアに利用可能とするため、前記認証された認証可能通知からの情報を格納するよう構成される少なくとも１つのコンピュータから構成されることを特徴とする装置である。

さらなる他の特徴は、使用後支払いビジネスモデルを実現する方法であって、ライセンスされたソフトウェアの利用に関する情報を含む認証可能通知を受信するステップと、前記認証可能通知を認証するステップと、前記ライセンスされたソフトウェアの利用に関する情報を処理して、使用後支払い要求をトリガーするため、前記利用が所定量だけライセンス条件を超過した事例を特定するステップとから構成されることを特徴とする方法である。

本発明の各種特徴のさらなる課題、特徴及び効果は、添付された図面と共に与えられる好適な実施例の以下の説明から明らかとなるであろう。

［好適実施例の詳細な説明］
ここで用いられるとき、以下の用語はそれの上限または下限の場合の利用に関係なく、以下の意味を有する。

「認証可能な通知（ＡｕｔｈｅｎｔｉｃａｔａｂｌｅＲｅｐｏｒｔ）」とは、デジタル署名などを介し認証可能な通知を意味する。

「バックエンド（Ｂａｃｋ−ｅｎｄ）」とは、ベンダによってカスタマーにライセンスされたソフトウェアの使用に関するカスタマーから受信した情報を受信及び処理するため、ソフトウェアベンダにより認証または制御されているサーバ、コンピュータあるいはシステムを意味する。

「業務処理ソフトウェア（ＢｕｓｉｎｅｓｓＯｐｅｒａｔｉｏｎｓＳｏｆｔｗａｒｅ）」とは、以下に限定されるものではないが、カスタマー課金、ライセンス遵守監査、製品マーケティングのためのデータ収集及び解析、サポートまたは製品開発目的を含む業務主体の業務処理における主要な利用を有するソフトウェアを意味する。

「カスタマー（Ｃｕｓｔｏｍｅｒ）」とは、ライセンスされたソフトウェアのライセンスの受け手を意味する。

「デジタル署名（ＤｉｇｉｔａｌＳｉｇｎａｔｕｒｅ）」とは、データや他の情報に対する安全なハッシュアルゴリズム（ＳＨＡ−１など）やメッセージダイジェスト（ＭＤ５など）を用いて一方向ハッシュ値を計算し、暗号化されたデータや他の情報が秘密鍵を所有するソフトウェやユーザにより暗号化（または、「署名」）されたものであるということを検証するため、公開鍵（解読を行う当事者に利用可能とされる）により解読可能とするため、当該ハッシュ値を秘密鍵（好ましくは、暗号化を実行した当事者のみにより知られている）により暗号化することにより生成されるようなデジタル署名を意味する。

「ファイル」とは、一般にコンピュータファイルとして理解されるものを意味するが、ここで用いられるときには、さらにデータベースマネージャ、レジストリ、ディレクトリ及びデータオブジェクトを含む、デジタルデータを格納及び抽出するための任意のシステムを含む。

「フロントエンド（Ｆｒｏｎｔ−ｅｎｄ）」とは、カスタマーにライセンスされたソフトウェアの使用を実行、管理及び／または通知するためカスタマーにより認証または制御されたサーバ、コンピュータまたはシステムを意味する。

「使用後支払いモデル（Ｐｏｓｔ−Ｕｓｅ−ＰａｙｍｅｎｔＭｏｄｅｌ）」とは、カスタマーの実際の利用が購入を「トリガー」するペイ・パー・ユーズビジネスモデル及び他のビジネスモデル、あるいはそのような利用を反映してソフトウェアライセンスを購入したり、あるいは購入を求める要求を含む、カスタマーによるソフトウェアの使用後のソフトウェアの利用に対する支払い、あるいはベンダからのソフトウェアの購入をカスタマーが行う任意のフォーマルまたはインフォーマルなソフトウェアライセンシングの実現を意味する。

「サーバ」とは、他のコンピュータアプリケーション、オペレーティングシステム、システムソフトウェアまたはコンピュータサービスがやりとりするコンピュータプロセスを意味する。この定義には、「クライアントサーバ」、「多層計算」、「３層計算」、「ネットワークサービス」または「ウェブサービス」などの用語において用いられるサーバが含まれる。

「ベンダ」とは、著作権所有者、及びライセンスされたソフトウェアを利用するためカスタマーにライセンスを販売または配布するために、著作権所有者により権利が付与された他の当事者を含むライセンスされたソフトウェアのライセンス許諾者を意味する。

図１〜５は、使用後支払いビジネスモデルに対し構成可能な代表的なソフトウェアライセンス管理システムの一例としてのブロック図を示す。上記システムに加えて、ここでの様々な教示を利用した他のシステムを用いて、本発明の各種機能を実現してもよく、またそれの完全な範囲内に属すると認識されるべきである。ファイアウォールを含むプロキシサーバは、セキュリティのため、あるいは他のネットワーキング技術をサポートするため上記システムに従来は挿入されていたかもしれないが、以下の説明を簡単化するためここでは図示または記載されず、そのような省略は本発明の完全な範囲を限定するものではないということは理解されるべきである。

図１において、フロントエンドサーバ１０１は、ライセンスされたソフトウェアの使用を制御し、このような使用の情報を含む認証可能な通知を生成し、当該認証可能な通知をダイレクトダイアルアップ電話番号、インターネットＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）、電子メールアドレスまたは他のネットワーキングアドレスなどの指定された送信先に対応するバックエンドサーバ１０２に安全に送信するよう構成可能である。ライセンスされたソフトウェアは配布され、フロントエンドサーバ１０１やコンピュータ１０４〜１０６として表される他のコンピュータを含むネットワーク１０７に接続されている各種フロントエンドコンピュータ上で実行される。ネットワーク１０７は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、バーチャルプライベートネットワーク（ＶＰＮ）、あるいはライセンスされたソフトウェアのカスタマーにより制御または管理されている他のネットワークであってもよい。好ましくはライセンスされたソフトウェアのカスタマーにより指定または承認された場所に設けられているフロントエンドサーバ１０１と、好ましくはライセンスされたソフトウェアのベンダにより指定または承認された場所に設けられているバックエンドサーバとの間の通信は、インターネット、プライベートネットワークあるいはダイレクトダイアルアップ接続などの通信媒体１０３を介し実行される。インターネットの場合には、好ましくは、認証可能な通知の安全な送信が、例えば、ＳＳＬ（ＳｅｃｕｒｅＳｏｃｋｅｔＬａｙｅｒ）プロトコル、ＶＰＮ及び／または暗号化された電子メールへの添付を利用して実行される。

あるいは、ネットワーク１０７上のフロントエンドコンピュータ１０４〜１０６により表されるフロントエンドコンピュータの１以上が、フロントエンドサーバ１０１の代わりに、あるいはそれに加えて、それのライセンスされたソフトウェア及び／またはそのような他のコンピュータのライセンスされたソフトウェアの利用を制御し、そのような利用の情報を含む認証可能な通知を生成し、当該認証可能な通知をバックエンドサーバ１０２に安全に送信するよう構成されてもよい。従って、明細書及び以下の請求項において用いられるとき、「フロントエンドサーバ」という用語は、このような機能を実行するとき、フロントエンドコンピュータを含むよう理解される。ライセンスされたソフトウェアを実行するよう構成されるフロントエンドコンピュータに加えて、フロントエンドサーバ１０１はまたそのように構成されてもよい。

バックエンドサーバ１０２は、認証可能な通知を受信、認証及び処理し、処理された情報を生成し、使用後支払いビジネスモデルのため、あるいは他の利用のため業務処理ソフトウェアに当該処理された情報を提供するよう構成される。このような業務処理ソフトウェアの例として、ＥＲＰ（ＥｎｔｅｒｐｒｉｓｅＲｅｓｏｕｒｃｅＰｌａｎｎｉｎｇ）ソフトウェア、電子商取引ソフトウェア（インターネットを介し取引を実行するのに利用されるものなど）、ＣＲＭ（ＣｕｓｔｏｍｅｒＲｅｌａｔｉｏｎｓｈｉｐＭａｎａｇｅｍｅｎｔ）ソフトウェア、及びＳＦＡ（ＳａｌｅｓＦｏｒｃｅＡｕｔｏｍａｔｉｏｎ）ソフトウェアがあげられる。

図２は、認証可能な通知が処理のため複数のバックエンドサーバに送信可能な使用後支払いビジネスモデルに対し構成可能なソフトウェアライセンス管理システムの一変形を示す。本例では、バックエンドサーバ２０２と２０８は、同一の認証可能通知を重複して受信するか、あるいはフロントエンドコンピュータ２０４〜２０６により表されるコンピュータ、フロントエンドサーバ２０１、ネットワーク２０７及び通信媒体２０３は好ましくは、図１の各自の対応する部分として機能するが、そのような処理動作を分割することにより認証可能な通知を処理するよう協調してもよい。

図３は、複数のフロントエンドサーバがバックエンドサーバ３０２に認証可能な通知を安全に送信する使用後支払いビジネスモデルに対し構成可能なソフトウェアライセンス管理システムの他の変形を示す。本例では、フロントエンドサーバ３０１と３０９は、バックエンドサーバ３０２に同一の認証可能な通知を提供する重複したサーバであってもよいし、あるいはバックエンドサーバ３０２に異なる認証可能な通知を提供する独立したサーバであってもよい。重複したフロントエンドサーバが利用される場合、認証可能な通知の良好な送信は、フロントエンドサーバの１つが「ダウン」（すなわち、動作不能）したときでさえ、適切に保証される。「ダウン」したフロントエンドサーバが「アップ」に回復した後、それらは何れも同一の情報を格納しているようにするため（例えば、各自の通知ログなどに）、当該フロントエンドサーバは他方のフロントエンドサーバに「同期」され、そのような情報は重複したフロントエンドサーバの１つが「ダウン」した結果として「消失」されることはない。独立したサーバが利用される場合、通知ログ及び／または通知生成責任は、２つのフロントエンドサーバ３０１と３０９に分割されるかもしれない。この後者のケースの一例として、各フロントエンドサーバがカスタマーの異なる部門またはプロフィットセンターの利用を通知する場合があげられる。重複または独立したフロントエンドサーバのケースの何れかにおいて、フロントエンドコンピュータ３０４〜３０６、ネットワーク３０７、通信媒体３０３及びバックエンドサーバ３０２は、好ましくは、図１の各自の対応するものとして機能する。

図４は、複数のフロントエンドサーバが複数のバックエンドサーバに１以上の認証可能な通知を安全に送信する使用後支払いビジネスモデルに対するソフトウェアライセンス管理システムの他の変形を示す。本例では、フロントエンドコンピュータ４０４〜４０６は、好ましくは、図１のそれらの対応するものとして機能し、ネットワーク４０７及びフロントエンドサーバ４０１と４０９は、好ましくは、図３のそれらの対応するものとして機能し、通信媒体４０３及びバックエンドサーバ４０２と４０８は、好ましくは、図２のそれらの対応するものとして機能する。

図５は、複数のネットワークがカスタマーにより利用される使用後支払いビジネスモデルに対し構成可能なソフトウェアライセンス管理システムのさらなる他の変形を示す。本例では、第１ネットワーク５０７は、通信媒体５０３を介し互いに、そして一方または両方のバックエンドサーバ５０２と５０８と通信するため、第１フロントエンドサーバ５０１及び代表とされるフロントエンドコンピュータ５０４〜５０６を接続する。ここで、これらすべては、好ましくは、それら各自の図２における対応するものとして機能する。また、第２ネットワーク５１７は、通信媒体５０３を介し互いに、そして一方または両方のバックエンドサーバ５０２と５０８と通信するため、第２フロントエンドサーバ５１１と第３フロントエンドサーバ５１９及び代表するフロントエンドコンピュータ５１４〜５１６を接続する。ここで、これらすべては、好ましくは、図４におけるそれら各自の対応するものとして機能する。異なるネットワークが、カスタマーの異なる子会社または部門により利用されてもよい。

図６は、図１を参照して上述された機能を実行するようフロントエンドサーバ１０１を構成するのに利用されるフロントエンドサーバ１０１上に備えられるソフトウェアモジュール及びファイルの一例としてのブロック図を示す。本例では、情報はファイルに格納されるものとして示されるが、情報はまた、マイクロソフトウィンドウズ（登録商標）レジストリなどのレジストリに格納することも可能であるし、あるいはＬＤＡＰなどのネットワークワイドシステムディレクトリにさえ、またはデータを格納するのに用いられる他の同様のシステムに格納することも可能であるということは、理解されるべきである。図１〜５を参照して説明されたものなどの他のフロントエンドサーバまたはフロントエンドコンピュータがさらに、あるいは代わりにこれらの機能を実行する場合、以下に説明されるソフトウェアモジュールとファイルの対応するコピーがまた、サーバまたはコンピュータに配置または少なくとも利用可能となることは理解されるべきである。ライセンスファイル６０５は、通知スケジュールライン６０５１（ここではまた、単に「通知スケジュール」と呼ばれる）、機能ライン６０５２、及びライセンスされたソフトウェアのライセンス条件６０５３を有する。あるいはラインの代わりに、そのようなデータは各自の通知スケジュール、機能またはライセンス条件を記述したタグ付データ、またはデータベーススキームまたはレジストリ内のデータとして格納されてもよい。ライセンスマネージャ６０４は、ライセンス条件６０５３に従ってライセンスされたソフトウェアの利用を制御し、必要に応じて、そのような利用の通知ログ６０６を生成する。

各通知スケジュールライン６０５１は、通知生成器６１０により生成される通知に対する情報を提供し、各機能ライン６０５２は、ライセンスされたソフトウェアの１以上の機能に対するライセンシング情報を提供する。一般に、ライセンスされたソフトウェア製品には複数の機能が存在し、ときには１つの機能が複数のライセンスされたソフトウェア製品にわたるものであるかもしれない。通知スケジュールと機能ラインの分離は、例えば、異なる機能ラインにおいて個々に特定される異なるベンダ業務ユニットが、それらの製品に関する機能の利用の同一にフォーマット化された通知を受信することが可能となるように、複数の機能ラインが同一の通知スケジュールラインにインデックス付けされるのを可能にする。あるいは、同一の機能の利用が、異なる業務ユニットの異なるまたは一意的な方法により通知されてもよい。

フロントエンドサーバ１０１上のバックグラウンドプロセスとして実行されるエージェント、サービスまたはデーモン（以降では、単に「エージェント」として呼ばれる）は、通知ログ６０６の情報から認証可能な通知を生成するため、通知生成器６１０を実行するタイミングをライセンスマネージャ６０４に通知するためのスケジューラとして利用される。エージェント６０８は、通知スケジュールライン６０５１のスケジュール情報からそのような動作のスケジューリングされた時間を読取る。エージェント６０８は図６に示されるように独立したモジュールであってもよいが、好ましくは、常時実行されているライセンスマネージャ６０４の一部であってもよい。認証可能な通知６１２は、現在実行されている通知スケジュールライン６０５１の「Ｒｅｐｏｒｔ＿Ｖａｌｉｄａｔｉｏｎ＿Ｃｏｄｅ」を用いてそのようなデータが認証される通知スケジュールラインの設定データを利用して生成される。好ましくは、結果として得られる認証可能な通知６１２は、インタフェースソフトウェアの開発を簡単化し、当該データを特定用途ソフトウェアを必要とすることなくユーザにより容易に閲覧可能にするため、ＸＭＬタグを有するＨＴＭＬまたはＳＧＭＬファイルとされる。

設定ファイル６１１は、認証可能な通知６１２を生成するのに必要なパラメータをフィルタリングするデータ及びフォーマットを通知生成器６１０に示す。好ましくは、この設定情報はＸＭＬファイルである。このファイルの一部は、認証可能な通知６１２などの認証可能な通知に対するＨＴＭＬ／ＸＭＬ出力のためのテンプレートである。このようにして、ライセンスされたソフトウェアのベンダは、ウェブブラウザを介し表示されるテキストラベルを含む通知をそれの所望するようにフォーマット化することが可能である。通知生成器６１０がテーブルを生成するとき、当該テーブルのフォーマット化方法の制御がまた、好ましくは、設定ファイル６１１に含まれる。デジタル署名が、好ましくは、ＸＭＬタグ付けされたフィールドの１つとして認証可能な通知に挿入される。この場合のデジタル署名の計算は、ヘッダ及びフッタテキストを除く通知テキストの本体全体をハッシュ処理する。

ライセンスマネージャ６０４は、それの他の機能と共に、通知生成器６１０が認証可能な通知６１２を生成する前に、通知生成器６１０とそれの設定ファイル６１１の真正性を検証する。好ましくは、そのような認証は、ライセンスマネージャの少なくとも起動時に実行され、それ以降は１時間ごとなど定期的に実行されてもよい。

設定ファイル６１１を介し選択可能な通知フォーマットの一例は、フル機能カスケードである。このフル機能カスケードでは、ユーザまたはカウントされたコンピュータリソース（ホストまたはＣＰＵなど）のうちのＮ，Ｎ−１，Ｎ−２，．．．，Ｍが、ライセンスされたソフトウェアのある機能を用いてアクティブであった通知期間における合計時間が提供される。ここで、Ｎはこの期間に当該機能を同時に利用するユーザまたはカウントされたコンピュータリソースの最大数であり、Ｍはゼロ以上の整数である。機能の利用と共にライセンスされたソフトウェアの利用が決定できるように、これは機能単位で実行される。この情報は、ソフトウェアのライセンシングが機能単位で行われる場合、特に有用である。通知期間は、日、週、月または他の周期ベースのものであってもよい。この通知フォーマットの設定情報の一部として、トリガー時間がまた提供される。このトリガー時間は、超過利用をカバーするための追加的なライセンスの購入をトリガーする前にライセンスされたソフトウェアの超過利用を可能にする最大期間を特定する。この情報の重要性のため、それは認証可能な通知においてある方法により強調されることが好ましい。

有用な通知フォーマットの他の例として、超過利用機能カスケードがある。この通知は、それが超過利用を通知のみ行うということを除いて、フル機能カスケードと同様のものである。有用な通知フォーマットの他の例には、ソフトウェアの利用がライセンスされた期間を超過したときの通知ログデータの追加的な詳細を提供する詳細な超過利用通知、ユーザまたはホストコンピュータにより通知された累積利用追跡、累積取引ライセンシング通知、及びペイ・パー・ユーズライセンシング構成により請求額を計算するためのデータを提供するよう構成されるペイ・パー・ユーズ通知が含まれる。

有用な通知フォーマットのさらなる他の例には、詳細な超過利用通知ログ、累積利用追跡（指定されたユーザまたはホストにより）、累積取引ライセンシング、及びペイ・パー・ユーズが含まれる。詳細な超過利用通知ログフォーマットでは、ライセンス条件６０５３を超過したとき、通知ログ６０６のデータが与えられる。データ完全性を適切に保証するため、通知された期間の前後のライセンスマネージャ６０４の設定または状態は、当該データと共に与えられる。ユーザ及びホストの特定は、ベンダがユーザプライバシーを適切に保証するため、ユーザとユーザの利用を関連付けることができないように、カスタマーにより符号化されてもよい。しかしながら、このような情報は、それの企画のためカスタマーに利用可能とされるであろう。累積利用追跡フォーマットでは、長期間にわたって利用が個々のユーザまたはホストにより追跡される。このモードでは、通知生成器６１０は、スケジュールごとの複数の通知生成のための蓄積情報を通知し、図８を参照して説明されるバックエンドソフトウェアモジュールはさらに、長期の利用概要通知を生成するため、受信した通知を蓄積する。累積取引ライセンシングフォーマットでは、日付、時刻、機能、ホスト及び／またはユーザによる取引または利用の情報が、アイテム化または要約されて与えられる。ライセンス条件６０５３に従ってライセンスされたものを超えた利用のみ、あるいはすべての利用に対する情報であってもよい。この場合、好ましくは超過利用が許可されるが、カスタマーによる追加的なソフトウェアライセンスの購入などをトリガーするようバックエンド業務処理ソフトウェアに提供される。ペイ・パー・ユーズフォーマットでは、ＣＰＵ時間、使用されたＩ／Ｏ、プラットフォームタイプ（ウィンドウＸＰ、アップル、ＵＮＩＸ（登録商標）など）、及び／またはある機能が利用された時間に関する情報が、アイテム化（チェックイン／チェックアウトなど）または要約されて（日付、ホスト及び／またはユーザの組み合わせなどにより）提供される。

ある機能がインタラクティブなライセンスされたソフトウェアに対し利用された時間を提供するとき、バックエンド業務処理ソフトウェアが、ライセンスされたソフトウェアが延長された期間（１０分など）アイドル状態にあるとき、使用後支払いビジネスも出るにおいて時間をカスタマーに課金しないように、認証可能な通知６１２にタイムアウト調整またはフラグを実現することが好ましい。多くの場合、ライセンスされたソフトウェアが延長された期間にアイドル状態となったとき（例えば、業務アプリケーションを利用している従業員が、アプリケーションを閉じずに週末に帰宅した）、ソフトウェアカスタマーはライセンスされたソフトウェアの利用に対し課金されることを不当であると考えるかもしれないため、これは重要である。

通知スケジュールライン６０５１と機能ライン６０５２の各々のエントリまたはフィールドの詳細な説明により、図６に示されるソフトウェアモジュールとファイルの処理のより明快な理解が提供される。ベンダにより与えられる機能ライン６０５２は、Ｒｅｐｏｒｔ＿Ｓｃｈｅｄｕｌｅ＿Ｎａｍｅ及びＲｅｐｏｒｔ＿Ｒｅａｄｙなどの通知スケジュール属性に対するエントリを含む。Ｒｅｐｏｒｔ＿Ｓｃｈｅｄｕｌｅ＿Ｎａｍｅは、通知スケジュールライン６０５１の対応するものに含まれる名前と一致させることによって、特徴が「関連付け」される通知スケジュールを特定する一意的な名前である。Ｒｅｐｏｒｔ＿Ｒｅａｄｙの値は、認証可能な通知６１２の処理方法を示す。「ＲＥＱＵＩＲＥ」の値は、認証可能な通知６１２が、図１〜５を参照して説明されるような１以上の指定された宛先に送信されることを求めることを意味する。この場合、通知生成器６１０は、機能ラインにおいて特定されたライセンスをイネーブルとする前に、ライセンスマネージャ６０４による良好な設定を有するものとして検証される必要がある。他方、「ＷＡＲＮ−ＯＮＬＹ」または「ＮＯＴ−ＲＥＱＵＩＲＥＤ」の値は、認証可能な通知６１２が何れの指定された宛先にも送信されることを求めないということを意味する。このような場合、機能ラインにおいて特定される機能に対するライセンス権は、通知生成器６１０が良好な設定を有するものとして検証されるか否かに関係なく、ライセンスマネージャ６０４によりイネーブルとされる。「ＷＡＲＮ−ＯＮＬＹ」モードでは、ライセンスされたソフトウェアがエラー警告を表示するよう構成される場合、ユーザ及び／またはシステム管理者がこの警告を観察できるように、エラー警告がライセンスされたソフトウェアに提供される。「ＮＯＴ−ＲＥＱＵＩＲＥＤ」モードでは、そのような警告はライセンスされたソフトウェアに提供されない。しかしながら、上記ケースの何れにおいても、検証が失敗すると、そのようなエラーの警告がデバッグログ（図示せず）及び通知ログ６０６に与えられる。

図７は、ライセンスされたソフトウェアのイネーブル化の一部として、図１のバックエンドサーバ１０２（または、図２〜５を参照して説明されるものなどの他のバックエンドサーバ）およびライセンスの受け手にベンダにより与えられた各通知スケジュールライン６０５１のフィールドまたはエントリを一例として示す。特に指定されていない場合、すべてのフィールドが通知スケジュールラインのデジタル署名計算に含まれる。

「Ｖｅｎｄｏｒ＿Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」は、複数のソフトウェアベンダの各々がそれの使用後支払いビジネスモデルに対する自らの一意的なライセンシング及び／または利用通知スキームを有することを可能にする一意的なベンダ名または識別コードである。

「Ｒｅｐｏｒｔ＿Ｓｃｈｅｄｕｌｅ＿Ｎａｍｅ」は、機能ライン６０５２における機能にリンクまたは「関連付け」された通知スケジュールを特定する一意的な名前である。

「Ｒｅｐｏｒｔ＿Ｎａｍｅ」は、通知生成器６１０の実行可能なものへのディレクトリパスとファイル名である。このフィールドは、通知スケジュールラインのデジタル署名に含まれる必要はなく、認証可能な通知が生成されない場合には空であってもよい。

「Ｒｅｐｏｒｔ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ」は、設定ファイル６１１へのディレクトリパスとファイル名である。このフィールドは、通知スケジュールラインのデジタル署名に含まれる必要はなく、認証可能な通知が生成されない場合には空であってもよい。

「Ｓｔａｒｔ＿Ｄａｔｅ」は、Ｒｅｐｏｒｔ＿Ｓｃｈｅｄｕｌｅ」が有効とされる最初の日付である。複数の通知スケジュールラインが同一のＲｅｐｏｒｔ＿Ｓｃｈｅｄｕｌｅ名と共に存在する場合、Ｅｎｄ−Ｄａｔｅのため通知スケジュールがすでに経過していなければ、複数の通知スケジュールラインの遅い日付が用いられる。

「Ｅｎｄ−Ｄａｔｅ」は、通知スケジュールライン６０５１が有効とされる最後の日付である。この属性は、使用後支払いモデルにおいて支払いを行っていないカスタマーが当該プログラムから削除可能となるようにすると共に、他の業務をサポートするようベンダにより利用することができる。スタート及びエンドの日付は、ベンダが通知スケジュールライン６０５１の定期的な更新を実行することを可能にする。

「Ｒｅｐｏｒｔ＿Ｖａｌｉｄａｔｉｏｎ＿Ｃｏｄｅ」は、３つの部分からなるコードである。コードの第１部分（ＣｏｄｅＡ）は、チャレンジレスポンス機構が通知生成器６１０の真正性を検証するのに利用される。これが実行可能となる１つの方法は、ライセンスマネージャ６０４が通知生成器に乱数（ＲＮ）をわたすことである。通知生成器６１０の内部において、ＲＮは、
ＣｏｄｅＢ＝Ｆ（ＣｏｄｅＡ）
（ただし、Ｆをある一対一関数である）となる通知生成器６１０に予めロードされるシークレットナンバー（ＣｏｄｅＢ）と日付と共に利用される。通知生成器の一意的な各バージョンに対し、一意的なＣｏｄｅＢとＣｏｄｅＡのペアが、ソフトウェアベンダにより選ばれる。通知生成器６１０は、
ＣｏｄｅＣ＝Ｇ（Ｆ^−１（ＣｏｄｅＢ），Ｄａｔｅ，ＲＮ）
（ただし、Ｇはハッシュ関数であり、Ｆ^−１はＦの逆関数である）によりライセンスマネージャ６０４に依存する。従って、ライセンスマネージャ６０４は、ＣｏｄｅＣを
ＣｏｄｅＣ＝Ｇ（ＣｏｄｅＡ，Ｄａｔｅ，ＲＮ）
により自ら計算することにより通知生成器６１０を認証することができる。Ｃの双方の計算結果が一致する場合、ライセンスマネージャ６０４は、ＣｏｄｅＣの計算が通知生成器６１０の具体的バージョンに対するソフトウェアベンダにより選択された一意的なＣｏｄｅＡとＣｏｄｅＢのペアに依存したため、真正性と正確なバージョンとするためこのテストをパスするものとして通知生成器６１０をみなす。

コードの第２部分は、設定ファイル６１１が真正であることを検証するため、ライセンスマネージャ６０４が利用する設定ファイル６１１のデジタル署名である。このデジタル署名は、設定ファイル６１１のコンテンツの一方向ハッシュ値であり、その後に一般にはライセンスファイル６０５のデジタル署名コンテンツで用いられるものと同一の鍵であることが好ましい秘密鍵を用いて暗号化される。その後、設定ファイル６１１のＤｉｇｉｔａｌ＿Ｓｉｇｎａｔｕｒｅは、ライセンスファイル６０５において利用されたものと同一の公開鍵によりこのＤｉｇｉｔａｌ＿Ｓｉｇｎａｔｕｒｅを解読し、その後に、それが設定ファイル６１１のコンテンツに対し同一の一方向ハッシュ計算を実行するときにライセンスマネージャ６０４が取得する結果と一致するか検証することによって、ライセンスマネージャ６０４により検証される。

さらなるセキュリティのため、設定ファイル６１１のハッシュ計算はまた、設定ファイル６１１と共にコードの第１部分と第３部分とを含むことが可能である。

コードの第３部分は、例えば、ライセンスされたソフトウェアのベンダに図６を参照して説明されたソフトウェアモジュールのベンダによって提供されるデジタル署名であり、それはライセンスされたソフトウェアのベンダに一意的なものである。このような場合、ライセンスされたソフトウェアのベンダは、ライセンスマネージャ６０４と通知生成器６１０を含むソフトウェアモジュールのベンダ（または、ライセンス許諾者）のカスタマー（または、ライセンスの受け手）である。このコードの第３部分は、ソフトウェアモジュールの提供者がそれらを複数のソフトウェアベンダに提供するとき、２つの可能性を提供する。第１の可能性は、ソフトウェアベンダが同一のソフトウェアモジュールを偶然に使用している他のベンダに対してではなく、自らの製品に対するライセンシングを特定することしかできないということである。第２の可能性は、ソフトウェアモジュールのベンダが当該モジュールの使用に対する期日やソフトウェアベンダが使用権を有する機能などの制御により、ソフトウェアベンダにソフトウェアモジュールを電子的にライセンスを付与することを可能にする。

このデジタル署名（すなわち、コードの第３部分）のハッシュ値は、Ｖｅｎｄｏｒ＿Ｉｄｅｎｔｉｆｉｃａｔｉｏｎに対する一方向ハッシュと、ソフトウェアモジュールを他のソフトウェアベンダにライセンス付与するとき、ソフトウェアモジュールのベンダが選ぶ他の各種ライセンシングパラメータとを利用することにより計算される。上記他のパラメータには、モジュールライセンススタート日付、モジュールライセンスエンド日付、ソフトウェアモジュールのバージョン、及びソフトウェアモジュールのエンハンスされた機能のライセンシングが含まれてもよい。ソフトウェアモジュールのベンダは、（ソフトウェアモジュールの）ベンダの秘密鍵により結果として得られるハッシュ値を暗号化する。その後、ソフトウェアモジュールは、ソフトウェアモジュールに埋め込まれた公開鍵を用いることにより当該デジタル署名を検証し、ソフトウェアモジュールのベンダにより指定された他のライセンスされたソフトウェアとＶｅｎｄｏｒ＿Ｉｄｅｎｔｉｆｉｃａｔｉｏｎをハッシュ処理することにより計算されるハッシュ値に対して解読されたハッシュ値をマッチさせる。ここでこの場合、ライセンスされたソフトウェアのベンダは、ライセンスマネージャ６０４と通知生成器６１０を含むソフトウェアモジュールのベンダ（または、ライセンス許諾者）のカスタマー（または、ライセンスの受け手）であるということに注意されたい。

Ｒｅｐｏｒｔ＿Ｖａｌｉｄａｔｉｏｎ＿Ｃｏｄｅのエントリは、ライセンスされたソフトウェアのカスタマーに対し当該ソフトウェアをイネーブルにするとき、ライセンスされたソフトウェアのベンダ（または、それの第三者である販売者）により運営される図１のバックエンドサーバ１０２（または、図２〜５を参照して説明されたものなどの他のバックエンドサーバ）に好ましくは配備される署名者モジュール（図示せず）により生成される。この署名者モジュールへの入力は、通知生成器６１０、設定ファイル６１１及び図７に示されるような対応する通知スケジュールラインの実行可能である。署名者モジュールの出力は、通知スケジュールラインのＲｅｐｏｒｔ＿Ｖａｌｉｄａｔｉｏｎ＿Ｃｏｄｅであるか、あるいはＲｅｐｏｒｔ＿Ｖａｌｉｄａｔｉｏｎ＿Ｃｏｄｅフィールドの「充填された」エントリを有する通知スケジュールラインである。署名者モジュールは、ライセンスされたソフトウェアの特定のベンダに一意的なエントリを生成するようＲｅｐｏｒｔ＿Ｖａｌｉｄａｔｉｏｎ＿Ｃｏｄｅの第３部分を介し構成されているため、他のライセンスされたソフトウェアの他のベンダは、通知生成器６１０、設定ファイル６１１及び図７に示されるような対応する通知スケジュールラインの同一の実行可能を入力したとしても、Ｒｅｐｏｒｔ＿Ｖａｌｉｄａｔｉｏｎ＿Ｃｏｄｅフィールドのエントリを複製することはできないであろう。従って、ライセンスされたソフトウェアのベンダへの追加的なセキュリティと共に、当該技術をライセンスするのに利用するＰＵＰシステムのベンダのためのライセンシング機構が与えられる。

「Ｈｏｓｔ＿ＩＤ」は、図６を参照して説明されたファイルを利用し、ソフトウェアモジュールを実行するよう認証される図１のフロントエンドサーバ１０１（または、図１〜５を参照して説明されたものなどの他のフロントエンドサーバまたはフロントエンドコンピュータ）の好ましくは一意的な識別であるエントリを含む。例えば、図３〜５に示されるような重複したサーバ構成では、重複サーバのそれぞれに対してエントリが行われる。

「Ｓｃｈｅｄｕｌｅ」は、時間インターバル（または期間）通知が通知生成器６１０により生成される日時を特定するエントリのリストである。時間インターバル通知は、認証可能な通知が後述されるような複数の時間インターバル通知を含む可能性があるため、認証可能な通知６１２などの個々の認証可能な通知とは区別されるべきである。日時は、好ましくは、ＵＮＩＸ（登録商標）「ｃｒｏｎ」ファイルなどの同様のシンタックス、好ましくは同一のシンタックスを用いて指定される。時間は、好ましくは、標準時（ＧＭＴ）またはバックエンドサーバ１０２のものなど他の特定のタイムゾーンに従って特定される。カスタマーにより定義可能なタイムゾーンは一般には受け入れられない。なぜなら、バックエンドサーバは、通知がタイムリーに提供されているか判断するため、実際のスケジュールを知る必要があるからである。

「Ｏｖｅｒｄｕｅ＿Ｓｃｈｅｄｕｌｅ」は、スケジューリングされた通知が指定されたタイムウィンドウ内の図１のバックエンドサーバ１０２（図２〜５を参照して説明されたものなどの他のバックエンドサーバ）により受信されないとき、エスカレーション（ｅｓｃａｌａｔｉｏｎ）ポリシーを定義する３つのフィールドを含む。第１フィールドは、電子メール（または他の通信）がバックエンドサーバからカスタマーに延滞を通知する「エラー」電子メールまたは他のカスタマーアドレスに送信されるべきトリガー期間を示す。第２フィールドは、電子メール（または他の通信）がバックエンドサーバからエスカレートされたカスタマーの担当者に送信されるべき他のトリガー期間を示す。第３フィールドは、電子メール（または他の通信）がバックエンドサーバからベンダのカスタマーサポート担当者に送信されるべきトリガー期間を示す。これら３つのフィールドのフォーマットは、ＤＤ：ＨＨ：ＭＭ（日付：時間：分）である。各フィールドは、通常業務時間を表し、週末や休日における追跡を回避するためのスキームによるローカルタイムに基づき、リアルタイムまたは通常の業務時間（例えば、月曜から金曜の午前９時から午後５時までなど）での追跡時間として指定されるかもしれない。

「Ｔｏ＿ＵＲＬ」は、認証された通知が送信されるべきすべてのインターネットＵＲＬに対するエントリを含む。好ましくは、追加的なＵＲＬが、オプションファイル６０５４の適切なフィールドにそれらを含めることにより、カスタマーのシステム管理者によってもとのリストに追加されるようにしてもよい。例えば、ＵＲＬのシンタックスは（ＨＴＴＰ、ＨＴＴＰＳまたはＦＴＰが利用されるとき）、
ｈｔｔｐ：ｄｏｍａｉｎ／ｐａｔｈ／ｎａｍｅＹＹＭＭＤＤＨＨＭＭＳＳ．ｆｂｒ
であってもよい。ここで、ｄｏｍａｉｎはインターネットドメインであり、ｐａｔｈはディレクトリパスであり、ｎａｍｅはこれらのファイルのネーミングへの固定されたテキストプリフィックスであり（例えば、カスタマー名、略語、識別番号など）、ＹＹＭＭＤＤＨＨＭＭＳＳはＧＭＴによる年、月、日、時間、分、秒の代替物であり、ｆｂｒは送信されているファイルのタイプが認証可能な通知であることを示す。認証可能な通知６１２または通知ログ６０６のコピーを指定されたＵＲＬに送信するためのプロトコルは、好ましくは、ＵＲＬシンタックスに基づくＨＴＴＰＳ（ＳＳＬを用いた）、またはＵＲＬシンタックスに基づくｍａｉｌｔｏである。

「Ｆｒｏｍ＿ＵＲＬ」は、ＨＴＴＰＳ及びｍａｉｌｔｏ送信モードが利用されるとき、人称可能な通知または通知ログのための有効なソースとして、ベンダバックエンドモジュール（図８のキャプチャコントローラ８０１を参照して説明されるような）により認識される予め認証されている電子メール、ＵＲＬまたはネットワークアドレスを示すエントリを含む。認識されていないソースから受信した通知は無視され、及び／またはベンダサイトのエラーログのエントリを生成する。

「Ｒｅｔａｉｎ＿Ｌｏｇ＿Ｗｉｎｄｏｗ」は、通知ログ６０６のデータがそれをアーカイブ６０７にアーカイブ処理する前に保持されるべきタイムウィンドウのエントリを含む。当該エントリのフォーマットは、ＤＤ：ＨＨ：ＭＭ（日付：時間：分）である。図１〜５を参照して説明されたようなソフトウェアライセンス管理システムで複数の通知スケジュールが利用される場合、最長のタイムウィンドウが優先される。通知ログ６０６の最も以前からあるエントリのアーカイブ処理は、通知スケジュール６０５１（または、システムの他の通知スケジュール）が認証可能な通知６１２または通知ログ６０６のコピーを図１のバックエンドサーバ１０２（または、図２〜５を参照して説明されるような他のバックエンドサーバ）に送信することをトリガーした後に行われる。

「Ｒｅｐｏｒｔ＿Ｗｉｎｄｏｗ」は、通知生成器６１０による認証可能な通知の生成の間の期間のエントリを含む。当該エントリのフォーマットは、ＤＤ：ＨＨ：ＭＭ（日付：時間：分）である。

好ましくは、Ｒｅｐｏｒｔ＿Ｗｉｎｄｏｗに従う各送信に対して、単独でなく最後に生成されたＮ個の期間通知が送信され、これにより、各期間通知は異なるＮ回のスケジューリングされた送信により実際にＮ回送信されるようにしてもよい。例えば、Ｎが３のとき、通知生成器６１０により生成される直近の３つの期間通知が各時送信される。これにより、連続的に生成された通知Ｒ（１）、Ｒ（２）及びＲ（３）が第１送信に含まれ、期間通知Ｒ（２）、Ｒ（３）及びＲ（４）が第２送信に含まれ、期間通知Ｒ（３）、Ｒ（４）及びＲ（５）が第３送信に含まれ、以下同様に行われる。従って、Ｓｃｈｅｄｕｌｅリストには、例えば、Ｒｅｐｏｒｔ＿Ｗｉｎｄｏｗごとに３回の期間通知の生成が含まれることになる。この冗長さが、認証可能な通知のすべての送信が成功する保証がないときには特に有用である。冗長さの直接的な結果として、信頼性を劇的に向上させることができる。例えば、送信の９０％しか良好に受信されない場合、Ｎが１のときには、１０回の期間通知のうちの１つは失敗することになる。しかしながら、Ｎが３のときには、平均的には１０００回のうち１つのみしか失敗しない。ここで、直近に生成されたＮ個の期間通知が送信のため常に利用可能であることを適切に保証するため、Ｒｅｔａｉｎ＿Ｌｏｇ＿ＷｉｎｄｏｗはＲｅｐｏｒｔ＿Ｗｉｎｄｏｗの少なくとも（Ｎ＋１）倍となるように選ばれるべきである。

「Ｖｅｒｉｆｙ＿Ｃｏｎｆｉｇ＿Ｆｒｅｑ」は、設定ファイル６１１がライセンスマネージャ６０４により検証されるべき頻度を特定するエントリを含む。そのような指定の例として、「なし」、ライセンスマネージャ６０４の「始動」時、「毎日」、「毎時」などがなる。対応する機能ラインのＲｅｐｏｒｔ＿Ｒｅａｄｙ属性がＲＥＱＵＩＲＥＤモードにある場合、設定ファイル６１１は、対応する機能ラインの機能がライセンス有効とされる前に正しいものとして検証される必要がある（上述のような通知生成器６１０と共に）。そうでない場合、カスタマーは超過利用許容モードにおいて当該機能へのアクセスを失い、この問題はＥｒｒｏｒ＿Ｅｍａｉｌ、デバッグログ（図示せず）及び通知ログ６０６に記録される。

「Ｃｏｍｐｌｅｔｅ＿Ｌｏｇ＿Ｌｉｓｔ」は、通知ログ６０６の全体のコピーが送信されるべきすべてのインターネットＵＲＬのエントリを含む。好ましくは、追加的なＵＲＬがオプションファイル６０５４の適切なフィールドにそれらを含めることにより、カスタマーのシステム管理者によってもとのリストに追加されるようにしてもよい。ＵＲＬのシンタックスは、Ｔｏ＿ＵＲＬフィールドと同一なものである。このフィールドは、デジタル署名計算に含まれる必要はない。

「Ｅｒｒｏｒ＿Ｅｍａｉｌ」は、エラーメッセージが送信されるすべての電子メールアドレスのエントリを含む。各電子アドレスに対し、メッセージの言語を特定するため補助フィールドが追加されてもよい（英語がデフォルトである）。

「Ｃｕｓｔｏｍｅｒ＿Ｉｎｆｏ」は、名前及び／または制約番号と共に、他の契約識別情報によりカスタマーを特定するエントリを含む。好ましくは、当該エントリは、ＸＭＬフォーマットデータである。

「Ｄｉｇｉｔａｌ＿Ｓｉｇｎａｔｕｒｅ」は、ＲｅｐｏｒｔＳｃｈｅｄｕｌｅの予め指定された（すなわち、サインされた）フィールドのデジタル署名であり、図１のバックエンドサーバ１０２（または、図２〜５を参照して説明されたものなどの他のバックエンドサーバ）により計算されるエントリに含まれる。

ライセンスマネージャ６０４は、通知スケジュールラインを検証するのに、それの一方向ハッシュ値（ここで注目されるフィールドを除く）を計算し、例えば、Ｄｉｇｉｔａｌ＿Ｓｉｇｎａｔｕｒｅフィールドの暗号化で用いられる秘密鍵に対応する公開鍵によりＤｉｇｉｔａｌ＿Ｓｉｇｎａｔｕｒｅフィールドを解読し、計算された一方向ハッシュ値とＤｉｇｉｔａｌ＿Ｓｉｇｎａｔｕｒｅフィールドの解読された値を比較することにより行われる。これら２つの値が一致する場合、ライセンスマネージャ６０４は、通知スケジュールラインに対応する機能をイネーブルとする（または、ライセンスされたソフトウェアに当該一致を実行のため通知する）。他方、これらの値が一致しない場合、ライセンスマネージャ６０４によりとられるアクションは、対応する機能ラインのＲｅｐｏｒｔ＿Ｒｅａｄｙ属性の値に依存する。この値がＲＥＱＵＩＲＥである場合、ライセンスマネージャ６０４は当該機能をイネーブルとせず（または、当該アクションを行うように、ライセンスされたソフトウェアにそのような不一致を通知し）、対応するエラーメッセージまたは警告が、Ｅｒｒｏｒ＿Ｅｍａｉｌアドレス、デバッグログ（図示せず）及び通知ログ６０６に送信される。この相対がＷＡＲＮＩＮＧ−ＯＮＬＹである場合、ライセンスマネージャ６０４は当該機能をイネーブルとし（または、ライセンスされたソフトウェアに実行のため通知し）、対応するエラーメッセージまたは警告が、Ｅｒｒｏｒ＿Ｅｍａｉｌアドレス、デバッグログ（図示せず）及び通知ログ６０６に送信される。当該値がＮＯＴ−ＲＥＱＵＩＲＥＤである場合、ライセンスマネージャ６０４は当該機能をイネーブルとし（または、実行のためライセンスされたソフトウェアに通知し）、Ｅｒｒｏｒ＿Ｅｍａｉｌに警告は送信されない。しかしながらこの場合、当該エラーはデバッグログ（図示せず）及び通知ログ６０６に送信されることが好ましい。

ライセンスの通知及び制御が上記例では機能単位で実行されるため、利用がソフトウェア製品単位で認証可能な通知６１２に通知されるように、あるいは利用がバックエンドサーバ１０２（図２〜５を参照して説明されるものなど他のバックエンドサーバ）上で好ましくは実行されるバックエンドソフトウェアにより通知されるように、機能から製品へのトランスレータを通知生成器６１０に備えることを有用である。英語のラベルを有する通知の他の言語への翻訳を容易にするユーティリティがまた、オプションファイル６０５４に示されるカスタマー選択を介し通知生成器６１０に配備されることが好ましい。

認証可能な通知６１２を生成するとき、通知生成器６１０は、認証可能な通知６１２のライセンスされたソフトウェアの利用情報に加えて、管理情報を含む。例えば、通知６１２を含むファイルが何れの方法によっても修正されるべきでないという通知が、通知６１２の先頭に備えられる。なぜなら、そのような修正は通知６１２をもはや認証可能なものとせず、このため通知６１２を受信したバックエンドシステムに処理のため当該通知６１２を拒否させるからである。好ましくは、他の情報がまた通知６１２のヘッダまたはフッタに置かれる。当該情報が図８を参照して説明されるようなウェブクエリモジュール８１５を介し閲覧されるときに表示可能であるか、あるいはＸＬＭタグにおいて「隠されている」かを示す設定スイッチが設けられてもよい。このような他の情報の例としては、通知６１２に対応する通知スケジュールライン全体、通知されている利用を有するライセンスされたソフトウェアのライセンスファイル６０５に含まれるライセンス条件、通知ログ６０６の時間差または通知に関する情報、及び図１のフロントエンドサーバ１０１（または、通知６１２を生成及び／または送信する他のフロントエンドサーバまたはコンピュータ）がシャットダウン及び／または再スタートされる時点に関する情報を含む。

上記説明の大部分は、認証可能な通知６１２が機能またはソフトウェアライセンスの利用のため、図１のフロントエンドサーバ１０１（または、図１〜５を参照して説明されたものなどの他のフロントエンドサーバまたはコンピュータ）上で自動的に生成され、図１のバックエンドサーバ１０２（または、図１〜５を参照して説明されるものなど他のバックエンドサーバ）に送信される状況に関するものである。しかしながら、通知スケジュールライン６０５１と機能ライン６０５２の適切な設定により、通知６１２の自動的送信は、カスタマーやライセンスの受け手のみが自発的に通知６１２を送信するよう抑制されてもよい。さらに、ライセンス条件６０５３によりサービス拒否がライセンシングモードであるべきだと示される場合、ライセンスマネージャ６０４は、これによりライセンスされたソフトウェアの利用を制御し、超過利用は許可されず、通知生成器６１０により生成される通知はそのような場合を示すであろう。

図８は、図１を参照して説明される機能を実行するよう構成するため、バックエンドサーバ１０２上のソフトウェアモジュール及びファイルの一例としてのブロック図を示す。図１〜５を参照して説明されるものなどの他のバックエンドサーバまたはコンピュータが、さらにまたは代わりにこれらの機能を実行する場合、以下に説明されるソフトウェアモジュール及びファイルの対応するコピーが、それらをそのような機能を実行するよう構成するため、これらのバックエンドサーバまたはコンピュータ上にも置かれるということは理解されるであろう。

キャプチャコントローラ８０１は、図１のフロントエンドサーバ１０１などのフロントエンドサーバまたはコンピュータから送信される認証可能な通知６１２を受信し、データベースまたはファイルシステム８１６に生データ８０２として認証可能な通知６１２を格納し、カスタマー契約名や識別番号、ファイルまたはレコード場所及び受信した日時などの情報を含むキャプチャログ８０４のレコードまたはエントリを介し認証可能な通知６１２の受信を示すキャプチャ表示を生成する。

スケジュールテーブル８０３は、次の認証可能な通知が受信されることが予想される時点に関する情報を含むフロントエンドサーバまたはコンピュータから受信されることが予想される送信リストを含む。また、送信のための認証情報が、スケジュールテーブルに含まれる。タイミング及び認証に関する情報は、ライセンスされたソフトウェアの始動または更新に応答してフロントエンドサーバまたはコンピュータに以前に提供されたライセンスファイル６０５の通知スケジュールライン６０５１に含まれる情報に一致する。認証可能な通知６１２の受信後（また、以降における各通知の受信後）、キャプチャコントローラ８０１は、次の認証可能な通知が受信される時点を示すように、スケジュールテーブル８０３の情報を更新する。

検証コントローラ８０５は、キャプチャログ８０４の次のレコードを読み出し、認証可能な通知６１２（図１２を参照して説明されたような）を認証し、スケジュールテーブル８０３の情報に従ってそれを受け取りの適時性を検証することにより、そこに格納されているキャプチャ表示に応答する。受信した認証可能な通知６１２が認証され、その受信タイミングが適時的であると検証されると、検証コントローラ８０５は、スケジュールテーブル８０３においてそのように示し、検証ログ８０６においてレコードまたはエントリを生成することにより、検証表示を生成する。他方、受信した認証可能な通知６１２の認証またはタイミング検証が失敗すると、図１１を参照して説明されるようなエラーメッセージルーティング及び復元動作が実行される。

計算機８０７は、検証ログ８０６の次のエントリを読み出し、生データ８０２と共にデータベースまたはファイルシステム８１６に好ましくは格納されている処理データまたは情報８１０を生成するため、生データ８０２として格納された認証可能な通知６１２から情報を処理するために格納された検証表示に応答する。その後、処理データ８１０は、ＥＲＰソフトウェア８１１、ＣＲＭソフトウェア８１２及びＳＦＡソフトウェア８１３などの業務処理ソフトウェア（ＢＯＳ）にＢＯＳインタフェース８１１を介しアクセス可能である。当該情報の処理は、ルールファイル８０８から（または、アプリケーションソフトウェアを介し）読み出されたルールとパラメータファイル８０９から読み出されたパラメータに従って実行される。例えば、計算機８０７は、週間利用通知などの短期間の通知を４半期利用通知などのより長期のサマリ通知に併合するため簡単な加算機能を実行するようにしてもよい。

ＢＯＳのため、処理情報には、ライセンス条件６０５３を超過したかに関する情報及びそのような超過利用に関する情報が含まれる。ＢＯＳインタフェース８１１は、処理情報を業務処理ソフトウェアが利用するのに適したフォーマットに変換する。

使用後支払いビジネスモデルのために計算機８０７により実行される重要な処理は、データベースまたはファイルシステム８１６の利用情報に基づく追加的なライセンスがカスタマーにより購入されるべき時点を示すライセンストリガー情報の生成である。この場合、ルールファイル８０８は、テスト条件とあるテスト条件が満たされる場合に行われるアクションを規定するルールのＸＭＬファイルである。パラメータファイル８０９は、ルールを定義するのに用いられるパラメータのＸＭＬファイルである。カスタマーが現在有するライセンス数、カスタマーに超過利用に関する特別な限度または特典が与えられているかなどのカスタマー固有情報を用いて共通のポリシー群が適用可能となるように、ルールとパラメータは分けられる。

いくつかの簡単な例は、そのようなライセンストリガー情報の生成を示すのに有用である。図９は、データベースまたはファイルシステム８１６において生データ８０２から生成されたグラフを一例として示す。このグラフは、ある月の各日にカスタマーの１日のピークライセンス利用のグラフである。本例では、カスタマーは３０のライセンスを所持しているが、当該カスタマーに超過利用が許可されているため、その月の利用機会に関して当該数を超えて利用してしまった。以下のテーブルは、この超過利用を要約している。

各種ルールが計算機によって用いられ、当該データを処理しライセンストリガー情報が生成されてもよい。例えば、カスタマーがこの月の間に最大超過利用に等しい追加的なライセンスを購入するよう要求されるというルールが規定されてもよい。この場合、月間の最大超過利用は、２７日に生じた９ライセンスである。このルールは、一般には「ベンダ」フレンドリーと考えられるであろう。他のルールとして、カスタマーが月間に３日間などの交渉された閾値を超える超過利用に等しい追加ライセンスを購入するよう求められるというものが規定されるかもしれない。この場合、９ライセンスの超過利用は、月間に１度しか（２７日）起こっておらず、８以上のライセンスの超過利用は、月間に２回しか（１７日と２７日）起こっていないが、６以上のライセンスの超過利用は、月間に４回起こっている（６日、１７日、２７日及び２８日）。従って、このルールを利用して、計算機８０７により生成されるトリガー情報は、カスタマーによって追加的に６つのライセンスが購入されるべきであるということを示すであろう。カスタマーが連続３日間などの交渉された閾値を超える超過利用に等しい追加的ライセンスを購入することを求められるさらなる他のルールが規定されてもよい。この場合、計算機８０７により生成されるトリガー情報は、４以上のライセンスの超過利用が当該月の２６日、２７日及び２８日に発生したため、４つの追加ライセンスがカスタマーにより購入されるべきであるということを示すであろう。理解可能なように、図９に示されるグラフまたは他のグラフを用いて、カスタマーの利用に基づくライセンスの購入をトリガーするための他の多くのルールが規定されてもよい。例えば、ライセンスされたソフトウェアプログラムの同時利用しているユーザ数を１日、１週間、１ヶ月などの時間に対しプロットした異なるグラフが生成されてもよい。本例では、同時利用するユーザの予めライセンスされているユーザ数を超えて超過利用された累積時間が所定の時間数を超える場合、カスタマーはある個数の追加ライセンスを購入するよう求められるというルールが規定されてもよい。これは、以前に説明したカスケード通知を用いて実行することができる。さらに、上記及び他の使用後支払いビジネスモデルのルールが、以前に説明されたフル機能カスケード、超過利用機能カスケード、詳細超過利用通知ログ、累積利用追跡、累積取引ライセンシング、ペイ・パー・ユーズなどの様々な方法により構成された利用情報に適用されてもよい。

図８を再び参照して、ウェブクエリモジュール８１５は、フロントエンドコンピュータ１０４〜１０６、図１のフロントエンドサーバ１０１、または他のコンピュータなどのコンピュータ上で実行されるウェブブラウザを介しデータベースまたはファイルシステム８１６のクエリを容易にする。ウェブクエリモジュール８１５へのアクセスは、例えば、従来のユーザ識別及びパスワード保護スキームを介し制御される。ウェブクエリモジュール８１５は、ＸＭＬ／ＨＴＭＬファイルにより交信するソフトウェアコンポーネント群である。それは、ＸＭＬによりタグ付けされたデータと、任意的なＨＴＭＬフォーマット化を提供する。これにより、他の一部のシステムは、容易にＨＴＭＬページを利用することができる。好ましくは、クエリは、カスタマー名、カスタマー契約、ホストコンピュータ識別、クエリを行う相手にのみ適用される通知スケジュール名または機能名などのパラメータを含む特定の検索、あるいはベンダまたはカスタマーにより認証された相手に限定される。さらに例えば、ＥＲＰシステムがライセンスされたソフトウェア利用のため、カスタマーに請求書を送信することが可能なシステムでは、カスタマーが現在及び過去の請求書と利用書と共に、ウェブクエリモジュール８１５を介し指定された期間にライセンスされたソフトウェアの利用及び／または超過利用などの認証された通知により送信される他の情報を読み取ることが可能であることは有用である。このウェブインタフェースを介し、ＸＭＬタグを有するデータを利用して、ソフトウェアカスタマーはまた、カスタマーのＥＲＰ、ソフトウェア資産管理またはソフトウェア在庫管理システムに統合可能なウェブサービスアプローチを利用して、ソフトウェア資産管理情報を提供するため、請求及び利用情報を抽出するようにしてもよい。

図１０〜１２は、使用後支払いビジネスモデルのためのライセンスされたソフトウェアの利用を通知する方法を例示的に示す。図１０は、図１のフロントエンドサーバ１０１（または、図１〜５を参照して説明されたものなどを含む他のフロントエンドサーバまたはコンピュータ）などのフロントエンドサーバに対し行われる本方法のフロントエンド部分を示し、図１１は、図１のバックエンドサーバ１０２（または、図１〜５を参照して説明されたものなどを含む他のバックエンドサーバまたはコンピュータ）などのバックエンドサーバに対し実行される本方法のバックエンド部分を示し、図１２は、本方法のバックエンド部分の処理エラーに関する追加的詳細を示す。図１〜５を参照して説明されるように、この場合において、ライセンスされたソフトウェアは、図１の１０４〜１０６などのフロントエンドコンピュータと共に、図１の１０１などのフロントエンドサーバ上にもまた分散されている。

図１０の１００１において、通知スケジュール６０５１に格納されている情報と共に、図６のエージェント６０８などのエージェントによって、ライセンスされたソフトウェアの利用に関する認証可能な通知をベンダ送信先に送信する時間であるか判断する。１００２及び１００３において、認証可能な通知を生成する前、通知生成器及び設定ファイルの真正性と、ライセンスマネージャ及び通知生成器の設定が検証される。この場合、図６の通知生成器６１０などの通知生成器が、通知を生成するのに用いられる。図６の通知ログ６０５などの通知ログの情報から通知を生成する前に、あるいは生成と同時に、通知生成器またはライセンスマネージャがまた、好ましくは、通知ログデータが改ざんされたか認証または検証する。

図６の設定ファイル６１１などの設定ファイルを用いて、通知のフォーマット及び選択されたコンテンツが規定される。好ましくは、図６のライセンスマネージャなどのライセンスマネージャを用いて、通知の送信をスケジューリングする。あるいは、この機能は、図６のエージェント６０８として実行されない場合には、独立したエージェントによって実行されてもよい。その後１００４において、通知生成器が、設定ファイルに規定される通知フォーマットに従って、ライセンスの受け手によるライセンスされたソフトウェアの利用に関する情報を含む認証可能な通知を生成するよう動作する。通知の生成はまた、予め指定されている通知日時間隔、通知の送信場所、セキュリティのため用いられる少なくとも１つのデジタル署名などの通知スケジュールに含まれる情報に従うものである（図７を参照して説明されたものなど）。認証可能な通知の生成において、通知の本体（ヘッダ及びフッタを除く）に対し一方向ハッシュ値を計算し、通知スケジュールを解読するのに用いられる公開鍵により一方向ハッシュ値を解読し、解読された一方向ハッシュ値（すなわち、デジタル署名）を認証可能な通知に含まれるヘッダまたはフッタのＤｉｇｉｔａｌ＿Ｓｉｇｎａｔｕｒｅフィールドに挿入することにより生成される。その後１００５において、認証可能な通知は、ＳＳＬ（ＳｅｃｕｒｅＳｏｃｋｅｔｓＬａｙｅｒ）プロトコル、暗号化された電子メールの添付、またはメッセージ処理に用いられる他のネットワーキングプロトコルの何れかを利用して、インターネットまたはダイレクトダイアルアップを介しカスタマーソースサイトからベンダ送信先に安全に送信される。

図１１の１１０１では、認証可能な通知がベンダの指定された宛先において受信される。１１０２において、受信した認証可能な通知は、データベースまたはファイルシステムに生データとして保存される。１１０３において、次の通知が到達するようスケジューリングされる時点を示すエントリを含むスケジュールテーブルが更新される。スケジュールテーブルの情報は通知スケジュールの情報に一致及び対応し、これにより、認証可能な通知をフロントエンドサーバ側で既知の時点で生成し、その後バックエンドサーバ側で認証することが可能となる。１１０４において、認証可能な通知を受信したことを示すキャプチャログにエントリが行われる。１１０５において、認証可能な通知が、スケジュールテーブルの情報に従って認証される（図１２の処理１２０１を参照して説明されるものなど）。１１０６において、認証可能な通知の適時性が、スケジュールテーブルの情報に従って検証され、１１０７において、スケジュールテーブルに受信と検証の成功が示される。１１０８において、認証可能な通知を受信及び検証したことを示す検証ログにエントリが行われる。１１０９において、認証されると、処理データまたは情報がデータベースまたはファイルシステムに格納されている認証可能な通知の生データから生成され、１１１０において、この処理データまたは情報は、使用後支払いビジネスモデル用の業務処理ソフトウェアに提供される。

図１２は、図１１を参照して説明された方法のバックエンド部分の１１０５〜１１０８の実行中の認証及び検証エラーの処理を示す。１２０１において、認証可能な通知の認証が実行される。これは、例えば、認証可能な通知の本体（ヘッダ及びフッタを除く）に関する一方向ハッシュ値を計算し（図１０の１００４を参照して説明されるようなＤｉｇｉｔａｌ＿Ｓｉｇｎａｔｕｒｅフィールドの生成に利用されるものと同一のアルゴリズムを利用して）、ベンダの秘密鍵により通知のヘッダまたはフッタに含まれるＤｉｇｉｔａｌ＿Ｓｉｇｎａｔｕｒｅフィールドを解読し、計算された一方向ハッシュ値と通知のＤｉｇｉｔａｌ＿Ｓｉｇｎａｔｕｒｅフィールドの解読されたエントリを比較することにより行われる。

ここで、１２０１において認証が失敗すると（すなわち、２つのデジタル署名が一致しない場合）、１２０２において、そのようなエラーを示すエラーメッセージがアクションのためベンダスタッフに通知される。認証失敗は、それがカスタマーによる不正な通知の送信試行を示す可能性があるため、特に重大なエラーとみなされる。従って、このタイプのエラーには、特別な取扱いが必要とされるかもしれない。

他方、通知６１２の認証が成功すると（すなわち、２つのデジタル署名が一致する場合）、１２０３において、通知スケジュールラインの情報が、通知６１２の受信方法と一致するか次に判断される。例えば、通知６１２が当該通知６１２に与えられる通知スケジュールラインのＳｃｈｅｄｕｌｅフィールドの関連するエントリに従って適時的に生成されたか判断される。また、通知６１２が当該通知６１２に与えられる通知スケジュールラインのＦｒｏｍ＿ＵＲＬフィールドのエントリに一致するインターネットＵＲＬから受信されたものであるか判断される。さらに、通知６１２が当該通知６１２に与えられる通知スケジュールラインのＣｕｓｔｏｍｅｒ＿Ｉｎｆｏフィールドの関連するエントリに従って適切なカスタマーから受信されたものであるか判断される。通知６１２に与えられる通知スケジュールラインの対応するものと比較される上記アイテムの何れかが失敗する場合、１２０４において、例えば、通知６１２に与えられる通知スケジュールラインのＥｒｒｏｒ＿Ｅｍａｉｌフィールドの適切なアドレスに電子メールすることにより、適切なエラーメッセージが送信される。この場合と共に以下の他の場合において、適切なアドレスは、通知６１２に与えられる通知スケジュールラインのＯｖｅｒｄｕｅ＿Ｓｃｈｅｄｕｌｅフィールドのエントリから判断されてもよい。

他方、通知スケジュールラインの情報が通知６１２の受信方法と一致する場合、１２０５において、時間間隔通知が通知６１２においてスキップされたか判断される。図７を参照して以前に説明されたように、通知６１２は、好ましくは、通知ログ６０６の直近に生成されたＮ個の時間間隔通知からの情報を含む（ただし、Ｎは整数である）。時間間隔通知がスキップされていない場合、１２０７において、例えば、以前に受信した認証可能な通知に与えられる情報が直近に受信した通知６１２の情報と一致するか、あるいは少なくとも相反していないことを確認することにより、通知６１２の情報が検証される。当該情報が検証されない場合、１２０８において、例えば、通知６１２に与えられる通知スケジュールラインのＥｒｒｏｒ＿Ｅｍａｉｌフィールドの適切なアドレスに電子メールすることにより、適切なエラーメッセージが送信される。本システムはまた、ＣＲＭや他のカスタマーサポートシステムへのイベントをトリガーすることも可能である。他方、情報が検証される場合、１２０９において、当該表示を通知６１２がわたされた日時と共に、スケジュールテーブル８０３に書き込み、当該成功の表示が、通知６１２が計算機８０７による処理の準備ができていることを示すため検証ログに書き込まれる。

１２０５において、時間間隔通知がスキップされたと判定されると、１２０６において、例えば、通知６１２に与えられる通知スケジュールラインのＥｒｒｏｒ＿Ｅｍａｉｌフィールドの適切なアドレスに電子メールすることにより、適切なエラーメッセージが送信される。本システムはまた、ＣＲＭや他のカスタマーサポートシステムへのイベントをトリガーすることが可能である。その後１２１０に移行して、欠落している時間間隔通知が以前に受信した認証可能な通知から「充填可能」であるか判断される。例えば、以前に受信した認証可能な通知において、時間間隔Ｔ１、Ｔ２及びＴ３における利用情報が対応する時間間隔通知Ｒ（１）、Ｒ（２）及びＲ（３）に対して受信されたが、現在受信した認証可能な通知６１２では、時間間隔Ｔ４及びＴ２のみの利用情報しか対応する時間間隔通知Ｒ（４）とＲ（２）に対して受信されていない場合、スキップされた時間間隔Ｔ３に対する情報が、以前に受信した認証可能な通知において受信した時間間隔通知Ｒ（３）から充填可能である。スキップされた時間間隔通知が充填可能な場合、本方法は１２０７に移行し、１２０７〜１２０９を参照して説明されたように移行する。他方、スキップされた時間間隔通知が充填可能でない場合、１２１１において、欠落した時間間隔通知のギャップが所定の閾値より大きいものか次に判断される。この閾値は、異なるカスタマーには異なるものであり、図１〜５を参照して説明されたものなどバックエンドサーバ上のテーブルに規定されてもよい。カスタマーがテーブルにエントリを持たない場合、デフォルト値が利用されてもよい。このギャップが超過している（すなわち、所定の閾値より大きい）と判断されると、例えば、通知６１２に与えられる通知スケジュールラインのＥｒｒｏｒ＿Ｅｍａｉｌフィールドの適切なアドレスに電子メールすることにより、適切なエラーメッセージが送信される。本システムはまた、ＣＲＭまたは他のカスタマーサポートシステムへのイベントをトリガーすることが可能である。他方、当該ギャップが超過していないと判定されると、本方法は１２０７に移行し、１２０７〜１２０９を参照して説明されたように処理を継続する。何れかのイベントにおいて、以降に受信した認証可能な通知に含まれる情報から、当該ギャップが充填される。

本発明の様々な特徴が好適な実施例に関して説明されたが、本発明に添付された請求項の完全な範囲に属する完全な保護の権利が与えられることが理解されるであろう。

図１は、本発明の一特徴を利用した使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムの一例であるブロック図を示す。図２は、本発明の他の特徴を利用した使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムの一例であるブロック図を示す。図３は、本発明の他の特徴を利用した使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムの一例であるブロック図を示す。図４は、本発明の他の特徴を利用した使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムの一例であるブロック図を示す。図５は、本発明の他の特徴を利用した使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムの一例であるブロック図を示す。図６は、本発明の各特徴を利用した使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムのフロントエンドサーバに設けられるソフトウェアモジュール及びファイルの一例であるブロック図を示す。図７は、本発明の各特徴を利用した通知スケジュールラインのフィールドに入力可能な属性を例示的に示す。図８は、本発明の各特徴を利用した使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムのバックエンドサーバに設けられるソフトウェアライセンス及びファイルのブロックを例示的に示す。図９は、１ヶ月の各日のカスタマーによる１日のピークライセンスの利用のグラフを例示的に示す。図１０は、本発明の各特徴を利用した使用後支払いビジネスモデル用のライセンスされたソフトウェアの使用を通知するための方法のフロントエンド部分を例示的に示す。図１１は、本発明の各特徴を利用した使用後支払いビジネスモデル用のライセンスされたソフトウェアの使用を通知するための方法のバックエンド部分を例示的に示す。図１２は、本発明の各特徴を利用した使用後支払いビジネスモデル用のライセンスされたソフトウェアの利用を通知するための方法のバックエンド部分の実行中の認証及び検証エラーの処理を例示的に示す。

Claims

使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムであって、
ライセンスされたソフトウェアの利用を制御し、通知スケジュールに従って前記利用に関する情報を含む認証可能通知を生成し、前記認証可能通知を指定された宛先に安全に送信するよう構成されるフロントエンドサーバと、
前記指定された宛先に対応し、前記認証可能通知を受信、認証及び処理して処理情報を生成し、使用後支払いビジネスモデル用の業務処理に前記処理情報を提供するよう構成されるバックエンドサーバと、
から構成されることを特徴とするシステム。
請求項１記載のシステムであって、
前記ライセンスされたソフトウェアは、前記フロントエンドサーバを含むネットワーク内のコンピュータ上に分散されることを特徴とするシステム。
請求項１記載のシステムであって、
前記フロントエンドサーバは、
前記通知スケジュールと前記ライセンスされたソフトウェアのライセンス条件を含むライセンスファイルと、
前記ライセンスされたソフトウェアの利用を制御し、前記利用の通知ログを生成するライセンスマネージャと、
前記通知スケジュールの情報に従って前記通知ログ内の情報から前記認証可能通知を生成する通知生成器と、
から構成されることを特徴とするシステム。
請求項３記載のシステムであって、
前記認証可能通知を認証するのに、少なくとも１つのデジタル署名が利用されることを特徴とするシステム。
請求項３記載のシステムであって、
前記ライセンスマネージャは、前記通知生成器が前記通知ログ内の情報から前記認証可能通知を生成する前に、前記通知スケジュール内の情報に従って前記通知生成器の真正性を検証することを特徴とするシステム。
請求項３記載のシステムであって、
前記ライセンスマネージャは、前記ライセンスされたソフトウェアの利用が前記ライセンス条件を超えることを許可する前に、前記通知スケジュール内の情報に従って前記通知生成器の真正性を検証することを特徴とするシステム。
請求項３記載のシステムであって、
前記フロントエンドサーバはさらに、前記通知生成器に前記認証可能通知を生成させ、前記認証可能通知を前記通知スケジュール内の情報に従って前記指定された宛先に安全に送信させるエージェントを有することを特徴とするシステム。
請求項７記載のシステムであって、
前記バックエンドサーバはさらに、前記認証可能通知を受信し、前記認証可能通知をファイルとして格納し、前記認証可能通知の受信を示すキャプチャ表示を生成するキャプチャコントローラを有することを特徴とするシステム。
請求項８記載のシステムであって、
前記バックエンドサーバはさらに、前記フロントエンドサーバから次の通知が受信されるようスケジューリングされる時点に関する情報を含むスケジュールテーブルを有し、
前記キャプチャコントローラは、前記フロントエンドサーバから前記認証可能通知を受信した後、次の通知が受信されるようスケジューリングされる時点に関する前記情報を更新することを特徴とするシステム。
請求項９記載のシステムであって、
前記バックエンドサーバはさらに、前記認証可能通知の適時性を検証し、前記スケジュールテーブルの情報に従って前記認証可能通知を認証するよう前記キャプチャ表示に応答し、前記スケジュールテーブルの検証及び認証の成功を示し、前記認証可能通知の検証及び認証の成功に応答して検証表示を生成する検証コントローラを有することを特徴とするシステム。
請求項１０記載のシステムであって、
前記バックエンドサーバはさらに、前記認証可能通知を処理して前記処理情報を生成するよう前記検証表示に応答する計算機を有することを特徴とするシステム。
請求項１１記載のシステムであって、
前記処理情報は、前記ライセンス条件が超過したかに関する情報を含むことを特徴とするシステム。
請求項１１記載のシステムであって、
前記認証可能通知は、ＸＭＬタグを有するＨＴＭＬファイルであることを特徴とするシステム。
請求項１１記載のシステムであって、
前記バックエンドサーバはさらに、アプリケーションソフトウェアによる前記認証可能通知を格納する前記ファイルのクエリを容易にするウェブクエリモジュールを有することを特徴とするシステム。
請求項１１記載のシステムであって、
前記バックエンドサーバはさらに、ウェブブラウザを介し前記認証可能通知を格納する前記ファイルのクエリを容易にするウェブクエリモジュールを有することを特徴とするシステム。
請求項１５記載のシステムであって、
前記ウェブブラウザは、前記フロントエンドサーバを含むネットワーク内のコンピュータ上で実行されることを特徴とするシステム。
請求項１記載のシステムであって、
前記フロントエンドサーバは、ＳＳＬ（ＳｅｃｕｒｅＳｏｃｋｅｔｓＬａｙｅｒ）プロトコルを用いてインターネットを介し前記指定された宛先に前記認証可能通知を安全に送信することを特徴とするシステム。
請求項１記載のシステムであって、
前記フロントエンドサーバは、暗号化された電子メール添付を用いてインターネットを介し前記指定された宛先に前記認証可能通知を安全に送信することを特徴とするシステム。
使用後支払いビジネスモデル用に構成可能なソフトウェアライセンス管理システムであって、
通知スケジュールに従ってカスタマーによるライセンスされたソフトウェアの利用に関する情報を含む認証可能通知を生成し、前記ライセンスされたソフトウェアのベンダにより指定された宛先に前記認証可能通知を安全に送信する手段と、
前記宛先に対応し、前記認証可能通知の受信、認証及び処理を行って使用後支払いビジネスモデル用の業務処理ソフトウェアに提供される処理情報を生成する手段と、
から構成されることを特徴とするシステム。
請求項１９記載のシステムであって、
前記ライセンスされたソフトウェアは、前記認証可能通知生成手段を含むネットワーク内のコンピュータ上に分散されることを特徴とするシステム。
請求項１９記載のシステムであって、
前記認証可能生成手段は、
前記通知スケジュールと前記ライセンスされたソフトウェアのライセンス条件を含むライセンスファイルと、
前記ライセンスされたソフトウェアの利用を制御し、前記利用の通知ログを生成するライセンスマネージャと、
前記通知スケジュールの情報に従って前記通知ログ内の情報から前記認証可能通知を生成する通知生成器と、
から構成されることを特徴とするシステム。
請求項２１記載のシステムであって、
前記認証可能通知を認証するのに、少なくとも１つのデジタル署名が利用されることを特徴とするシステム。
請求項２１記載のシステムであって、
前記ライセンスマネージャは、前記通知生成器が前記通知ログ内の情報から前記認証可能通知を生成する前に、前記通知生成器の真正性を検証することを特徴とするシステム。
請求項２１記載のシステムであって、
前記ライセンスマネージャは、前記ライセンスされたソフトウェアの利用が前記ライセンス条件を超えることを許可する前に、前記通知生成器の真正性を検証することを特徴とするシステム。
請求項２１記載のシステムであって、
前記認証可能通知生成手段はさらに、前記通知生成器を起動し、前記認証可能通知を前記通知スケジュール内の情報に従って前記指定された宛先に安全に送信させる前記ベンダにより提供されるエージェントを有することを特徴とするシステム。
請求項２５記載のシステムであって、
前記認証可能通知受信、認証及び処理手段は、前記認証可能通知を受信し、前記認証可能通知をファイルとして格納し、前記認証可能通知の受信を示すキャプチャログにキャプチャ表示を生成するキャプチャコントローラを有することを特徴とするシステム。
請求項２６記載のシステムであって、
前記認証可能通知受信、認証及び処理手段は、前記認証可能通知生成手段から次の通知が受信されるようスケジューリングされる時点に関する情報を含むスケジュールテーブルを有し、
前記キャプチャコントローラは、前記認証可能通知を受信した後、次の通知が受信されるようスケジューリングされる時点に関する前記情報を更新することを特徴とするシステム。
請求項２７記載のシステムであって、
前記認証可能通知受信、認証及び処理手段はさらに、前記認証可能通知の適時性を検証し、前記スケジュールテーブルの情報に従って前記認証可能通知を認証するよう前記キャプチャ表示に応答し、前記スケジュールテーブルの検証及び認証の成功を示し、前記認証可能通知の検証及び認証の成功に応答して検証ログにおいて検証表示を生成する検証コントローラを有することを特徴とするシステム。
請求項２８記載のシステムであって、
前記認証可能通知受信、認証及び処理手段はさらに、前記認証可能通知を処理して前記処理情報を生成するよう前記検証表示に応答する計算機を有することを特徴とするシステム。
請求項２９記載のシステムであって、
前記処理情報は、前記ライセンス条件が超過したかに関する情報を含むことを特徴とするシステム。
請求項２９記載のシステムであって、
前記認証可能通知は、ＸＭＬタグを有するＨＴＭＬファイルであることを特徴とするシステム。
請求項２９記載のシステムであって、
前記認証可能通知受信、認証及び処理手段はさらに、アプリケーションソフトウェアによる前記認証可能通知を格納する前記ファイルのクエリを容易にするウェブクエリモジュールを有することを特徴とするシステム。
請求項２９記載のシステムであって、
前記認証可能通知受信、認証及び処理手段はさらに、ウェブブラウザを介し前記認証可能通知を格納する前記ファイルのクエリを容易にするウェブクエリモジュールを有することを特徴とするシステム。
請求項３３記載のシステムであって、
前記ウェブブラウザは、前記認証可能通知生成手段を含むネットワーク内のコンピュータ上で実行されることを特徴とするシステム。
請求項１９記載のシステムであって、
前記認証可能通知生成手段は、ＳＳＬ（ＳｅｃｕｒｅＳｏｃｋｅｔｓＬａｙｅｒ）プロトコルを用いてインターネットを介し前記指定された宛先に前記認証可能通知を安全に送信することを特徴とするシステム。
請求項１９記載のシステムであって、
前記認証可能通知生成手段は、暗号化された電子メール添付を用いて前記指定された宛先に前記認証可能通知を安全に送信することを特徴とするシステム。
使用後支払いビジネスモデル用のライセンスされたソフトウェアの利用を通知する方法であって、
通知スケジュールに従ってライセンス受け手によるライセンスされたソフトウェアの利用に関する情報を含む認証可能通知を生成するステップと、
前記認証可能通知をカスタマーにより指定されたソースからベンダにより指定された宛先に送信するステップと、
前記認証可能通知を前記ベンダにより指定された宛先において受信及び認証するステップと、
認証されると、使用後支払いビジネスモデル用の業務処理ソフトウェアに提供されるよう前記認証された通知から処理情報を生成するステップと、
から構成されることを特徴とする方法。
請求項３７記載の方法であって、
前記ライセンスされたソフトウェアは、ネットワーク内のコンピュータ上に分散されることを特徴とする方法。
請求項３７記載の方法であって、
前記認証可能通知の生成において、少なくとも１つのデジタル署名が利用されることを特徴とする方法。
請求項３７記載の方法であって、
前記認証可能通知をカスタマーにより指定されたソースからベンダにより指定された宛先に送信するステップは、ＳＳＬ（ＳｅｃｕｒｅＳｏｃｋｅｔｓＬａｙｅｒ）プロトコルを利用してインターネットを介し前記認証可能通知を送信することを特徴とする方法。
請求項３７記載の方法であって、
認証可能通知をカスタマーにより指定されたソースからベンダにより指定された宛先に送信するステップは、暗号化された電子メール添付を利用して前記認証可能通知を送信することを特徴とする方法。
請求項３７記載の方法であって、
前記認証可能通知を前記ベンダにより指定された宛先において受信及び認証するステップは、前記通知スケジュールの情報に対応するスケジュールテーブルの情報に従って前記認証可能通知を認証することを特徴とする方法。
請求項３７記載の方法であって、さらに、
前記通知スケジュールの情報に対応するスケジュールテーブルの情報に従って、前記認証可能通知の受信の適時性を検証するステップを有することを特徴とする方法。
請求項３７記載の方法であって、
前記業務処理ソフトウェアに提供されるよう前記認証された通知から処理情報を生成するステップは、前記ライセンスされたソフトウェアのライセンス条件を超過する利用に関する情報を生成することを特徴とする方法。
ライセンスされたソフトウェアのライセンス条件を超えた超過利用を条件付きで許可し、前記超過利用の情報を含む認証可能通知を生成し、使用後支払いビジネスモデル用の宛先に前記認証可能通知を送信するよう構成される少なくとも１つのコンピュータから構成されることを特徴とする装置。
請求項４５記載の装置であって、
前記ライセンスされたソフトウェアのコピーは、前記少なくとも１つのコンピュータに通信可能に接続される１以上のコンピュータに関する前記ライセンス条件に従って配布可能であることを特徴とする装置。
請求項４５記載の装置であって、
前記超過利用は、前記少なくとも１つのコンピュータの対応するものにより個別に維持される１以上の通知ログに記録されることを特徴とする装置。
請求項４７記載の装置であって、
前記１以上の通知ログは、前記少なくとも１つのコンピュータの前記対応するものの１つが不具合を有する場合、前記１以上の通知ログの少なくとも他の１つが、前期少なくとも１つのコンピュータの不具合を有するものの通知ログを訂正するのに利用可能な訂正情報を含むことを特徴とする装置。
請求項４７記載の装置であって、
前記１以上の通知ログは、異なる通知主体に対応する非重複情報を含むことを特徴とする装置。
請求項４５記載の装置であって、
前記少なくとも１つのコンピュータはさらに、前記認証可能通知の複数の第１期間の情報を、前記少なくとも１つのコンピュータによって以前の認証可能通知に提供される複数の第２期間の情報と重複するため提供するよう構成されることを特徴とする装置。
請求項４５記載の装置であって、
前記少なくとも１つのコンピュータの各々は、
通知スケジュールとライセンス条件を含むライセンスファイルと、
ライセンスされたソフトウェアの利用を制御し、前記利用の通知ログを生成するライセンスマネージャと、
前記通知スケジュールの情報に従って、前記通知ログ内の情報から前記認証可能通知を生成する通知生成器と、
を有することを特徴とする装置。
請求項５１記載の装置であって、
少なくとも１つのデジタル署名が、前記認証可能通知の認証に利用されることを特徴とする装置。
請求項５１記載の装置であって、
前記ライセンスマネージャは、前記認証可能通知が前記宛先に送信される前に、前記通知スケジュール内の情報に従って、前記通知生成器の真正性を検証することを特徴とする装置。
請求項５１記載の装置であって、
前記少なくとも１つのコンピュータの各々はさらに、前記認証可能通知のフォーマットを示す設定ファイルを有し、
前記ライセンスマネージャは、前記認証可能通知が前記宛先に送信される前に、前記通知スケジュール内の情報に従って前記設定ファイルの真正性を検証する、
ことを特徴とする装置。
請求項５１記載の装置であって、
前記ライセンスマネージャは、前記ライセンスされたソフトウェアの超過利用を許可する前に、前記通知スケジュール内の情報に従って前記通知生成器の真正性を検証することを特徴とする装置。
請求項５１記載の装置であって、
前記ライセンスマネージャは、前記通知生成器に前記通知スケジュールの時間情報に従って前記認証可能通知を生成させることを特徴とする装置。
ライセンスされたソフトウェアの利用を通知する方法であって、
複数の認証可能通知の各々が、ソフトウェアモジュールにより生成される前記複数の認証可能通知の直前及び直後のものと重複する複数の期間におけるライセンスされたソフトウェアの利用に関する情報を含むように、前記複数の認証可能通知をスケジュールされた時点に生成するよう構成されるソフトウェアモジュールを提供するステップを有することを特徴とする方法。
請求項５７記載の方法であって、さらに、
前記ソフトウェアモジュールによって生成された認証可能通知を宛先に送信する前の各時点において、前記ソフトウェアモジュールの真正性を検証するステップを有することを特徴とする方法。
請求項５７記載の方法であって、さらに、
前記ライセンスされたソフトウェアの超過利用を許可する前の各時点において前記ソフトウェアモジュールの真正性を検証するステップを有することを特徴とする方法。
ライセンスされたソフトウェアの利用を通知する方法であって、
計数されるコンピュータリソースのＮ，Ｎ−１，Ｎ−２，．．．，Ｍ個が前記ライセンスされたソフトウェアのある機能を用いてアクティブとされているとき、合計時間が通知期間を超えるように、構成された前記ライセンスされたソフトウェアの利用に関する情報を含む認証可能通知を生成するよう構成されるソフトウェアモジュールを提供するステップから構成される（ただし、Ｎは前記通知期間における前記機能を同時に利用する前記計数されたコンピュータリソースの最大数であり、Ｍはゼロ以上の整数である）ことを特徴とする方法。
請求項６０記載の方法であって、
前記計数されたコンピュータリソースは、前記ライセンスされたソフトウェアのユーザにより利用されるホストコンピュータであることを特徴とする方法。
請求項６０記載の方法であって、
前記ソフトウェアモジュールはさらに、所定のトリガー値を超える前記ライセンスされたソフトウェアの超過利用に関する強調された情報を提供するため、前記認証可能通知を生成するよう構成されることを特徴とする方法。
請求項６２記載の方法であって、
前記所定のトリガー値は、所定の期間に基づくものであることを特徴とする方法。
請求項６２記載の方法であって、
前記所定のトリガー値は、所定のライセンス数に基づくものであることを特徴とする方法。
請求項６２記載の方法であって、
前記所定のトリガー値は、前記ライセンスされたソフトウェアのライセンス条件に従って、購入された利用値より大きいことを特徴とする方法。
請求項６０記載の方法であって、
前記ライセンスされたソフトウェアの利用の通知は、前記ライセンスされたソフトウェアの超過利用の通知に制限され、
前記超過利用は、前記ライセンスされたソフトウェアのライセンス条件から決定される、
ことを特徴とする方法。
ライセンスされたソフトウェアの利用を通知する方法であって、
アクティブであるユーザのＮ，Ｎ−１，Ｎ−２，．．．，Ｍ人が前記ライセンスされたソフトウェアのある機能を利用しているときの合計時間が通知期間を超えるように、構成された前記ライセンスされたソフトウェアの利用に関する情報を含む認証可能通知を生成するよう構成されるソフトウェアモジュールを提供するステップから構成される（ただし、Ｎは前記通知期間における前記機能を同時に利用する前記ユーザの最大数であり、Ｍはゼロ以上の整数である）ことを特徴とする方法。
ライセンスされたソフトウェアの超過利用に関する情報を含む認証可能通知を安全に受信し、使用後支払いビジネスモデル用の業務処理ソフトウェアに利用可能とするため、前記認証された認証可能通知からの情報を格納するよう構成される少なくとも１つのコンピュータから構成されることを特徴とする装置。
請求項６８記載の装置であって、
前記認証可能通知に含まれる少なくとも１つのデジタル署名は、前記認証可能通知を認証するのに利用されることを特徴とする装置。
請求項６８記載の装置であって、
前記少なくとも１つのコンピュータの各々は、前記認証可能通知を受信し、前記認証可能通知に与えられる情報をファイルに格納し、前記認証可能通知の受信を示すキャプチャ表示を生成するキャプチャコントローラを有することを特徴とする装置。
請求項７０記載の装置であって、
前記少なくとも１つのコンピュータの各々はさらに、次の認証可能通知が受信されるようスケジューリングされる時点に関する情報を含むスケジュールテーブルを有し、
前記キャプチャコントローラは、前記認証可能通知の受信後、前記次の認証可能通知が受信されるようスケジューリングされる時点に関する前記情報を更新する、
ことを特徴とする装置。
請求項７１記載の装置であって、
前記少なくとも１つのコンピュータの各々はさらに、前記認証可能通知の受信の適時性を検証するよう前記キャプチャ表示に応答する検証コントローラを有することを特徴とする装置。
請求項７２記載の装置であって、
前記検証コントローラはさらに、前記スケジュールテーブルの情報に従って前記認証可能通知を認証し、前記認証可能通知の検証及び認証に成功すると、検証表示を生成し、前記スケジュールテーブルにおいて前記検証及び認証を示すことを特徴とする装置。
請求項７３記載の装置であって、
前記少なくとも１つのコンピュータの各々はさらに、前記認証可能通知を処理して処理情報を生成するよう前記検証表示に応答する計算機を有し、使用後支払いビジネスモデル用の業務処理ソフトウェアに利用可能とするため、前記処理情報を前記ファイルに格納することを特徴とする装置。
請求項７４記載の装置であって、
前記少なくとも１つのコンピュータの各々はさらに、前記ファイルに格納されている情報に対する認証されたユーザにより操作されるウェブブラウザを介し制御されたデータベースクエリを容易にするウェブクエリモジュールを有することを特徴とする装置。
請求項６８記載の装置であって、
前記業務処理ソフトウェアは、ソフトウェアを企画する企業リソースを有することを特徴とする装置。
請求項６８記載の装置であって、
前記業務処理ソフトウェアは、電子商取引ソフトウェアを有することを特徴とする装置。
請求項６８記載の装置であって、
前記業務処理ソフトウェアは、カスタマーリレーションシップ管理ソフトウェアを含むことを特徴とする装置。
請求項６８記載の装置であって、
前記業務処理ソフトウェアは、販売強制自動ソフトウェアを含むことを特徴とする装置。
使用後支払いビジネスモデルを実現する方法であって、
ライセンスされたソフトウェアの利用に関する情報を含む認証可能通知を受信するステップと、
前記認証可能通知を認証するステップと、
前記ライセンスされたソフトウェアの利用に関する情報を処理して、使用後支払い要求をトリガーするため、前記利用が所定量だけライセンス条件を超過した事例を特定するステップと、
から構成されることを特徴とする方法。
請求項８０記載の方法であって、
前記ライセンス条件は、前記ライセンスされたソフトウェアの同時利用するユーザの最大数から構成され、
前記所定量は、前記ライセンスされたソフトウェアの利用が前記最大数を超過した累積期間である、
ことを特徴とする方法。