JP2016504687A - 情報技術サービスの管理 - Google Patents

Abstract

システムは、クライアントデバイスのセットのユーザによってネットワーク上にホスティングされる複数のソフトウェアアプリケーションの使用を特徴付けるデータを収集するように構成された収集モジュールと、収集されたデータを記憶するように構成されたデータ記憶モジュールと、前記記憶されたデータに基づいて、前記複数のソフトウェアアプリケーションの各々について少なくとも１つの使用メトリックを決定するように構成された処理モジュールとを含む。【選択図】図１

Description

優先権の主張

本出願は、参照により全体を本明細書において援用する、２０１２年１２月１９日に出願した米国特許仮出願第６１／７３９、６２３号の優先権を主張するものである。

情報技術（ＩＴ）プロセスの従来の管理は、施設内で実行しているハードウェアおよびソフトウェア（ＨＷおよびＳＷ）を管理することに基づいている。ＩＴマネージャは、ネットワーク、次いでサーバ、次いでデバイス（ワークステーション、またはＰＣ）を必要な大きさにする必要がある。インフラストラクチャが適切に配置されると、マネージャの注意は、インフラストラクチャにインストールされるべきＳＷに向かう。このシナリオにおいて、ＳＷバージョンは、ベンダーによって定期的に更新され、新しい製品として再度販売される。

従来のＩＴを管理することの主要な課題には、次の２つがある。

インフラストラクチャが許容可能なサービスレベルで継続的に機能することを確認すること
ＳＷを選択し、保守し、更新すること
ＳＷとデバイスとの間の一義的な関係は非常に強いので、ＳＷベンダーは、今日に至るまで、ＰＣ上のインストールの数に基づいてＳＷライセンスを販売している。フローティングライセンシングは、ソフトウェアアプリケーションに対して限定された数のライセンスが時間とともに多数のユーザ間で共有されるソフトウェアライセンシングの手法である。許可されたユーザがアプリケーションを実行しようとする場合、ユーザは中央ライセンスサーバにライセンスを要求する。ライセンスが使用可能である場合、ライセンスサーバは、アプリケーションが実行できるようにする。ユーザがアプリケーションの使用を終了するか、または許可されたライセンス期間が満了すると、ライセンスは、ライセンスサーバによって回収され、他の許可ユーザが使用できるようにされる。

クラウドコンピューティングの出現は、ＳＷがリモートサーバで実行し、ブラウザを通じてアクセスされるので、企業においてＩＴが管理される方法に重大な変化をもたらした。クラウドコンピューティングは、ネットワーク（通常はインターネット）を介したサービスとして提供されるコンピューティングリソース（ハードウェアおよびソフトウェア）の使用である。

ＳＷを保守して更新する責任は、ＳＷベンダーに移行する。ベンダーは、自社のＳＷを実行しているサーバも管理し、その結果、企業ＩＴ管理の責任は、社内ユーザが、接続先の円滑な作業およびデバイスを保証するのに十分なリモートサーバへの接続性を有するようにすることだけに軽減される。ＳＷはサービスとして販売される（ＳａａＳ−Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：最も一般的なモデルは月極めサブスクリプションである。

ＳａａＳアプリケーションの大多数は、「名前付きサブスクリプション（named subscription）」モデルの下で販売される。これは、ＳａａＳアプリケーションのサブスクリプションが実際には、加入者またはユーザといった、通常は各自の電子メールアドレス（一意の識別子）を通じて、ベンダーによって一意に識別される実在の個人に割り当てられることを意味する。ＳａａＳアプリケーションは、リモートサーバ上で実行し、ブラウザを通じてアクセスされる。したがって、ＳａａＳアプリケーションは広範にわたるデバイスを通じてアクセスされる可能性がある。ユーザとデバイスとの間の従来の一義的な関係は、もはや適用しない。

アプリケーションがＩＴマネージャによって選択されなくなり、多くの場合、ＩＴマネージャが尋ねられることもなく、または企業内でのアプリケーションの使用を知らされることすらなく、ユーザ各自によって選択される現状において実際の使用は重大なものとなる。複数のベンダーによって提案されるＩＴ資産管理の手法は、ユーザへのサブスクリプション割り当てを管理する際の助けとなり得るが、実際のアプリケーションの使用に関する情報を提供することはできない。ほぼ明らかなことに、これは、同一のＩＴ管理によって割り当てられなかったサブスクリプションに関する情報を提供することはできない。

現在のサービス−デバイスのパラダイムはもはや、ＩＴ世界を効率的に説明してないが、それはユーザが異なるデバイスを通じてアプリケーションにアクセスするという事実を無視するからであり、また実際の使用の重要性を無視することに起因している。したがって、ＩＴマネージャが会社またはその他の組織にわたりＳａａＳ使用を容易に測定および分析することができるシステムおよび／または方法を有することが有益であろう。

本発明の好ましい代替的な実施形態は、次の図面を参照して後段において詳細に説明される。

本発明の実施形態が実施され得る例示的な動作環境を示す概略図。 本発明の実施形態が実施され得る例示的な動作環境を示す機能ブロック図。 本発明の実施形態が実施され得る例示的な動作環境を示す機能ブロック図。 データが収集され得る本発明の代替の実施形態を示す図。 データが収集され得る本発明の代替の実施形態を示す図。 データが収集され得る本発明の代替の実施形態を示す図。 本発明の少なくとも１つの実施形態による生成され得る複数のグラフィック使用分析を示す図。 本発明の少なくとも１つの実施形態による生成され得る複数のグラフィック使用分析を示す図。 本発明の少なくとも１つの実施形態による生成され得る複数のグラフィック使用分析を示す図。 本発明の少なくとも１つの実施形態による生成され得る複数のグラフィック使用分析を示す図。

本特許出願は、本発明の１つまたは複数の実施形態について説明することが意図されている。具体的な数量と同様に「ｍｕｓｔ（しなければならない）」、「ｗｉｌｌ（であろう）」などのような絶対名辞の使用は、そのような実施形態の１つまたは複数に適用可能であると解釈されるべきであるが、必ずしもそのような実施形態すべてに適用可能ではないことを理解されたい。そのようなものとして、本発明の実施形態は、そのような絶対名辞のコンテキストにおいて説明される１つまたは複数の特徴または機能の変更を省略するかまたは含むことができる。

本発明の実施形態は、クラウドアプリケーションによって導入されるさまざまな認証メカニズムをサポートするためのユニバーサルメカニズムと、ＩＴ関係者がクラウドアプリケーションのサブスクリプションを管理して、アプリケーションをプロビジョンまたはプロビジョン解除するための環境および便利なツールと、デバイス独立の使用追跡と、ロケーション独立の使用追跡と、開発ツールと、さまざまなクラウドアプリケーションベンダーとのＳＯＡおよびオープンソース統合スクリプトとを含む特徴を提供する。

図１は、本発明の実施形態が実施され得るコンピューティングシステム環境１００の例を示す。コンピューティングシステム環境１００は、示されているように、適切なコンピューティング環境の例であるが、後段においてさらに詳細に説明されるように、その他の環境、システム、およびデバイスが本発明のさまざまな実施形態を実施するために使用されてもよいことを理解されたい。

本発明の実施形態は、ハードウェア、ファームウェア、ソフトウェア、または各々の２つ以上の組合せで実施されてもよい。本発明の実施形態は、数多くの汎用または特殊用途のコンピューティングシステム環境または構成で動作可能であってもよい。本発明の実施形態と共に使用するために最適となり得るよく知られたコンピューティングシステム、環境、および／または構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル消費者電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などを含むが、これらに限定されることはない。

本発明の実施形態は、コンピュータによって実行されるプログラムモジュールのような、コンピュータ実行可能命令の一般的なコンテキストに即して説明され得る。一般に、プログラムモジュールは、特定のタスクを実行するかまたは特定の抽象データタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明の実施形態はまた、タスクが通信ネットワークを通じてリンクされるリモート処理デバイスによって実行される分散コンピューティング環境において実施されてもよい。分散コンピューティング環境において、プログラムモジュールは、メモリ記憶デバイスを含むローカルおよびリモートのコンピュータ記憶媒体に配置されてもよい。

図１を参照すると、本発明の実施形態を実施するための例示的なシステムは、コンピューティングデバイス１００のようなコンピューティングデバイスを含む。コンピューティングデバイス１００は通常、少なくとも１つの処理ユニット１０２と、メモリ１０４とを含む。

適格な構成およびコンピューティングデバイスのタイプに応じて、メモリ１０４は、（ランダムアクセスメモリ（ＲＡＭ）のような）揮発性、（読み取り専用メモリ（ＲＯＭ）、フラッシュメモリなどのような）不揮発性、またはこの２つの任意の組合せであってもよい。この最も基本的な構成は、破線１０６によって図１に示される。

加えて、デバイス１００は、追加の特徴と、態様と、機能とを有することができる。たとえば、デバイス１００は、磁気または光ディスクまたはテープの形態をとり得る（ただし、これらに限定されない）追加の記憶装置（取り外し可能および／または固定式）を含むことができる。そのような追加の記憶装置は、取り外し可能記憶装置１０８および固定式記憶装置１１０により、図１に示される。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータのような情報の記憶のための任意の方法または技術で実施された揮発性および不揮発性の、取り外し可能および固定式媒体を含む。メモリ１０４、取り外し可能記憶装置１０８、および固定式記憶装置１１０はすべて、コンピュータ記憶媒体の例である。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、EEPROM(登録商標)、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）またはその他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、もしくは望ましい情報を記憶するために使用され得る、デバイス１００によってアクセスされ得る任意の他の媒体を含むが、これらに限定されることはない。任意のそのようなコンピュータ記憶媒体は、デバイス１００の一部であってもよい。

デバイス１００はまた、デバイスがその他のデバイスと通信できるようにする通信接続１１２を含むことができる。通信接続１１２は、通信媒体の例である。通信媒体は通常、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを搬送波もしくは他のトランスポート機構のような変調データ信号で具現し、任意の情報配信媒体を含む。「変調データ信号」という用語は、信号の特性セットの１つまたは複数を有する信号、または信号の情報を符号化するような方法で変更された信号を意味する。一例として、通信媒体は、有線ネットワークまたは直接有線接続のような有線媒体、ならびに音響、無線周波数（ＲＦ）、赤外線およびその他のワイヤレス媒体のようなワイヤレス媒体を含む。本明細書において使用されるコンピュータ可読媒体という用語は、記憶媒体および通信媒体の両方を含む。

デバイス１００はまた、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどのような入力デバイス１１４を有することができる。さらに、ディスプレイ、スピーカ、プリンタなどのような出力デバイス１１６もまた含まれてもよい。追加の入力デバイス１１４および出力デバイス１１６は、デバイス１００の望ましい機能に応じて含まれてもよい。

１つまたは複数の実施形態によれば、ソフトウェアまたはコンピュータ実行可能命令のコンピュータ可読媒体との組合せは、結果としてマシンまたは装置の創造をもたらす。同様に、処理デバイスによるソフトウェアまたはコンピュータ実行可能命令の実行は、結果としてマシンまたは装置の創造をもたらすが、これは実施形態により、処理デバイス自体とは区別可能であってもよい。

これに対して、コンピュータ可読媒体は、そこにソフトウェアまたはコンピュータ実行可能命令を記憶することによって変換されることを理解されたい。同様に、処理デバイスは、ソフトウェアまたはコンピュータ実行可能命令を実行する間に変換される。加えて、処理デバイスによるソフトウェアまたはコンピュータ実行可能命令の実行中、またはその実行に関連して、処理デバイスに入力されるデータの第１のセットは、そのような実行の結果としてデータの第２のセットに変換されることを理解されたい。続いて、この第２のデータセットは、記憶され、表示され、または伝達されてもよい。上記の例の各々において示される、そのような変換は、コンピュータ可読媒体の一部の物理的改変の結果であってもよいか、またはそのような改変を伴っていてもよい。上記の例の各々において示される、そのような変換はまた、たとえば、処理デバイスによるソフトウェアまたはコンピュータ実行可能命令の実行中の処理デバイスに関連付けられているレジスタおよび／またはカウンタの状態の物理的改変の結果であってもよいか、またはそのような改変を伴っていてもよい。

本明細書において使用されるように、「自動的に」実行されるプロセスとは、プロセスがマシンに実行される命令の結果として実行され、ユーザプリファレンスの確立以外に、手動の作業を必要としないことを意味することができる。

図２を参照すると、本発明の実施形態は、例示的なコンピュータネットワークシステム２００の形態をとることができ、および／または、そのコンピュータネットワークシステムの１つまたは複数の要素を使用して実施されてもよい。システム２００は、ネットワーク２２０（たとえば、インターネット）のような通信媒体を介してサーバ２３０のような電子デバイスまたはシステムにリンクされている、パーソナルコンピュータまたはワークステーション、タブレットまたはスマートフォンのような電子クライアントデバイス２１０を含む。サーバ２３０は、データベース２４０およびコンピュータシステム２６０に、さらに結合されてもよいか、またはこれらにアクセスすることができる。図２に示される実施形態は、ネットワーク２２０を介して１つのクライアントデバイス２１０に結合された１つのサーバ２３０を含むが、本発明の実施形態が１つまたは複数のそのようなサーバに結合された１つまたは複数のそのようなクライアントデバイスを使用して実施され得ることが理解されるべきである。

クライアントデバイス２１０およびサーバ２３０は、図１に示され、これを参照して説明されるデバイス１００に関連付けられている特徴の全部または一部を含むことができる。クライアントデバイス２１０は、コンピュータ画面またはディスプレイ２５０を含むか、またはこれに結合される。クライアントデバイス２１０は、ネットワークおよびローカルコンピューティングプロセスのようなさまざまな目的に使用されてもよい。

クライアントデバイス２１０は、たとえば、クライアントデバイス２１０上で実行しているブラウザのようなコンピュータプログラムがサーバ２３０と双方向通信で協働することができるように、ネットワーク２２０を介してサーバ２３０にリンクされる。サーバ２３０は、データベース２４０から情報を取り出して、そこに情報を記憶するために、データベース２４０に結合されてもよい。データベース２４０は、本発明の実施形態のさまざまな態様の実行を可能にするためにサーバ２３０によって使用され得るデータ（図示されず）を記憶している。加えて、サーバ２３０は、サーバが特定の処理機能をコンピュータシステムに委任できるようにする方法で、コンピュータシステム２６０に結合されてもよい。実施形態において、クライアントデバイス２１０は、ネットワーク２２０を迂回して、コンピュータシステム２６０と直接に通信することができる。

図３は、本発明の実施形態によるシステム３１０を示し、図３において説明される要素は、図２を参照して上記で説明されている要素と同一であってもよいか、またはこれらの要素と類似する方法で機能することができる。システム３１０は、収集モジュールとしての役割を果たすアプリケーションアダプタ３２０と、記憶モジュール３３０のようなメモリデバイスと、処理モジュール（プロセッサ）３４０とを含む。後段においてさらに詳細に説明されるように、アダプタ３２０は、エンドユーザによって採用されたクライアントデバイス３６０のセット、および／または１つまたは複数のサーバ３８０を含むネットワークでホスティングされた複数のソフトウェアアプリケーション３７０（たとえば、ＳａａＳアプリケーション）と対話するように構成される。実施形態において、アダプタ３２０は、ターゲットとなるアプリケーション３７０によって固有のオブジェクトタイプに適用され得る操作のオブジェクトモデルを認識するかまたは発見するように構成され得るアプリケーション固有のコンポーネントである。加えて、アダプタ３２０は、アプリケーション３７０の固有のオブジェクト言語を実施形態により汎用モデルに変換するように構成される。

システム３１０の１つまたは複数の実施形態の要素は、図３に示される実施形態の場合と同様に、サーバ３８０に関してファイアウォール３９０の後方に位置されてもよい。また図３に示されるように、アダプタ３２０は、監視されるエンドユーザ３６０に対してファイアウォール３９０のいずれの側に配置されてもよい。あるいは、アダプタ３２０の単一の実施形態の要素は、ファイアウォール３９０をまたぐように構成されてもよい。

示されている実施形態において、アダプタ３２０は、クライアントデバイス３６０を採用しているエンドユーザによって１つまたは複数のサーバ３８０でホスティングされたＳａａＳアプリケーション３７０の使用（「使用データ」）を特徴付けるデータを収集するように構成される。収集されたデータは、その後、記憶モジュール３３０に記憶される。後段においてさらに詳細に説明されるように、プロセッサ３４０は、記憶されたデータに基づいて、クライアントデバイス３６０（すなわち、エンドユーザ）および／または複数のソフトウェアアプリケーション３７０の各々について少なくとも１つの（たとえば、レーティングのような）使用メトリックを決定するように構成される。次いで、決定された使用メトリックは、たとえばディスプレイまたはプリンタのような出力デバイス３５０を介して表示可能にされる。

アダプタ３２０によって収集される使用データのタイプ、およびそのようなデータが収集される方法は、採用される特定の実施形態に応じて異なる場合がある。たとえば、図４を参照すると、実施形態のアダプタ３２０Ａは、アプリケーション３７０に関連付けられているプラグイン４３０およびＲＥＳＴ ＡＰＩ４４０とそれぞれ通信可能にインターフェースをとるように構成されたプラグインハンドラ４１０とＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ） ＡＰＩハンドラ４２０とを含むことができる。そのような配置は、アダプタ３２０Ａが、１つまたは複数のクライアントデバイス３６０によるそのようなアプリケーションの使用を特徴付けるデータをアプリケーション３７０から直接に収集することができるようにする。

ここで図５を参照すると、実施形態のアダプタ３２０Ｂは、クライアントデバイス３６０が構成要素であるローカルエリアネットワーク（ＬＡＮ）５３０（またはワイドエリアネットワーク（ＷＡＮ））に関連付けられている１つまたは複数のネットワークエージェント５４０およびログ処理エージェント５５０とそれぞれ通信可能にインターフェースをとるように構成されたネットワークエージェントハンドラ５１０とログエージェントハンドラ４２０とを含むことができる。そのような配置は、アダプタ３２０Ｂが、アプリケーション自体ではなく、（アプリケーションをホスティングするサーバ３８０に対してファイアウォール３９０の背後にあってもよい）ＬＡＮ５３０の要素から、１つまたは複数のクライアントデバイス３６０によるアプリケーション３７０の使用を特徴付けるデータを収集することができるようにする。

ここで図６を参照すると、実施形態のアダプタ３２０Ｃは、クライアントデバイス３６０およびアプリケーション３７０と通信可能にインターフェースをとるように構成されたプロキシハンドラ６１０を含むことができる。そのような配置は、アダプタ３２０Ｃが、１つまたは複数のクライアントデバイスによるそのようなアプリケーションの使用を特徴付けるデータを１つまたは複数のクライアントデバイス３６０およびアプリケーション３７０から直接に収集することができるようにする。

上記で示され説明される実施形態は、複数のＳａａＳアプリケーション３７０から多種多様な使用統計を収集するように構成される。上記で示されるように、これらの統計は、アプリケーションとの直接通信、アプリケーションＲＥＳＴ ＡＰＩまたはアプリケーションプラグイン、ネットワークトラフィックを監視するエージェント、システムログ、アプリケーションログ、ネットワークログ、ＶＰＮログ、ファイアウォールログ、ネットワークプロキシサービス、アプリケーション−ユーザ電子メール、および／または会社の課金システムを介して、ＳａａＳアプリケーション自体からもたらされ得る。

収集された使用統計は、各アプリケーション３７０ごとに一意であってもよく、以下のような項目を含むことができる。

１． ログインの数
２． 前回ログイン以降の時間
３． 合計アプリケーション使用時間
４． アプリケーションオブジェクトが読み取られた回数
５． アプリケーションオブジェクトが書き込まれたか変更された回数
６． 送信／受信されたバイトの数
７． 送信／受信されたパケットの数
８． 作成されたアプリケーションオブジェクトの数
９． アプリケーション使用に関連したポインタ「クリック」の回数
収集の複数の方法は、１つまたは複数の実施形態が、さまざまなクライアントデバイス３６０にわたり、および／またはＳａａＳベンダーのログとの統合を通じてデータを取り込み、固有のユーザに関連付けることができるようにし、その結果デバイスおよびロケーションから独立した使用統計をもたらすことができる。

アダプタ３２０によって収集されたすべての使用データは、将来の取り出しおよび分析のために記憶装置３３０に記憶されてもよい。記憶装置３３０は、リレーショナルデータベース、「ＮｏＳｑｌ」型のデータベース、およびフラットファイルのうちの１つまたは複数で構成されてもよい。さまざまなＳａａＳアプリケーション３７０および収集されるデータタイプを所与として、実施形態は、ＮｏＳｑｌデータベースおよびフラットファイルのような半構造化または非構造化データストアの一部の組合せを使用することができる。

実施形態において、デバイス３３０に記憶されたデータは、実施形態による、プロセッサ３４０によって実行される分析エンジンによって、ならびにアプリケーション３７０に関連付けられているメタデータおよび／またはエンドユーザ３６０の１つまたは複数に関連付けられている行動モデルを使用することで、分析されフォーマットされる。そのようなデータは、分散された方法で取り出されて分析されてもよい。実施形態において、半構造化または非構造化の特性を所与として、技法は、ＭａｐＲｅｄｕｃｅのようなビッグデータフレームワークを含むことができる。

さまざまな使用分析が、アプリケーション３７０に対して以下のように計算されてもよい。

１． 個別アプリケーションベース
２． 複数アプリケーションにわたる組合せ、および／または
３． 会社部門または事業単位にわたる組合せ
これらの使用分析は、プロセッサ３４０によって（予め定められた時間期間および／または固有の時間期間を含む）時間の経過に伴って計算および／または監視されてもよく、使用傾向分析を可能にする。各アプリケーションの使用メトリックは、アプリケーション３７０に関連する収集された統計に基づいて計算されてもよい。この使用メトリックは、各アプリケーション３７０ごとに異なっていてもよい。

そのような使用メトリックの例示的な計算は、関心対象の統計が以下のような場合である。

１． Ｌ＝ログインの数
２． Ｒ＝読み取りアクセスの数
３． Ｗ＝書き込み／変更アクセスの数
実施形態は、指定された単位時間期間（たとえば、１日）にわたりアプリケーションユーザ３６０を以下のように分類することができる。

１． フルアクセスユーザ：（Ｌ＞０、Ｗ＞０）である場合ＦＡ＝１、それ以外の場合ＦＡ＝０
２． 読取り専用ユーザ：（Ｌ＞０、Ｒ＞０、Ｗ＞０）である場合ＲＯ＝１、それ以外の場合ＲＯ＝０
３． 非ユーザ：（Ｌ＝０）である場合ＮＵ＝１、それ以外の場合ＮＵ＝０
したがって、簡単な使用統計は、それぞれ図７および図８に示されているように、絶対またはパーセントベースで出力３５０によって提示されてもよい。

実施形態はまた、アプリケーション間のより容易な比較を可能にする正規化使用レーティングを計算することもできる。所与のユーザＵｘについて、Ｎの単位時間期間数にわたるそのユーザ３６０の使用レーティングは、式１に従って計算され得る。

代替の実施形態において、上記の式の係数１０および５が、全体的段階および相対的重みを設定するために任意の加重係数に置き換えられてもよいことに留意されたい。Ｍのアプリケーションユーザ３６０を伴う組織の使用レーティングは、式２に従って計算されてもよい。

これは、０〜１０の段階でそのアプリケーションの組織全体の使用レーティングをもたらす。

同様に、「正規化」使用レーティングは、管理されている各アプリケーション３７０ごとに開発されてもよく、図９に示されるように、全般的な会社全体のＳａａＳ使用レーティングをもたらすように、それらの使用レーティングが組み合わされてもよい。

さまざまなＳａａＳアプリケーションが新しいＳａａＳアプリケーションを作成するために組み合わされるような、ＳａａＳアプリケーション「マッシュアップ」の場合、実施形態は、マッシュアップアプリケーションの新しい使用分析を作成するために基礎をなすアプリケーションの使用分析を組み合わせることができる。

代替の実施形態において、累積された使用インデックスおよびアクティビティレベル（ＫＰＩ）が、以下のように計算されて記憶されてもよい。

アプリケーション担当者ごと−アプリケーションサブスクリプションの直接割り当てを有するユーザ。計算された使用インデックおよびアクティビティレベルは、アプリケーションサブスクリプションのオブジェクトに保持される。

すべての割り当てられたアプリケーションのユーザごとの平均−割り当てられたアプリケーションの数で除算されたアプリケーションごとの対応するＫＰＩの合計。計算された平均使用インデックおよびアクティビティレベルは、ユーザオブジェクトに保持される。

すべてのアプリケーションのユーザグループごとの平均−は、０以外の使用基準を持つすべてのメンバー間の平均として計算される。計算された平均使用インデックおよびアクティビティレベルは、ユーザグループオブジェクトに保持される。

アプリケーションのユーザごとの平均−すべての担当者の平均−担当者の数で除算されたユーザ。計算された平均ＫＰＩは、アプリケーションオブジェクトに保持される。

組織ごとの平均−すべてのアプリケーション担当者の平均（そのようなサブスクリプションの数で除算された、計算されるべきすべてのサブスクリプションの合計）。

計算されるべきサブスクリプションは、ゼロ（０）以外の使用基準を持つ担当者を有するサブスクリプションである。

基準の定義
基準は、事前定義されたテンプレートの形態で提供されてもよい。

テンプレート１：
＜数＞＜期間＞における＜ログインの数＞
テンプレート２：
＜数＞＜期間＞おきの＜ログインの数＞
＜ログインの数＞は１〜９の範囲内であってもよい
＜期間＞の＜数＞は１〜９の範囲内であってもよい
＜期間＞は、日、週、月によって表されてもよい
各基準は、ＵＩで示されるテキスト記述によって表される。

解決策は、以下のような事前定義された基準のセットをユーザに提供する。

少なくとも１日１回−（１日に１）
少なくとも週１回−（１週間に１）
少なくとも月１回−（１か月に１）
少なくとも週２回−（１週間に２）
少なくとも週３回−（１週間に３）
少なくとも２日おきに１回のログイン−（２日おきに１）
ときどき（任意の期間に０）
その他
製品の第１のバーションにおいて、実施形態は、幅広い事前定義済みの使用利用率（Usage Utilization）基準を顧客に提供する。顧客は、各自の使用利用率基準を定義することができる。

計算アルゴリズム
以下に示すのは、実施形態による、アプリケーション／アプリケーション担当者ごとの使用インデックおよびアクティビティレベルを計算するための可能なアルゴリズムの１つである。

１． 予想される基準を日次（Ｄａｉｌｙ）表現に正規化することによってＤａｙＣｒｉｔｅｒｉｏｎを計算する。たとえば、
１日１回＝１
週１回＝１／ＮｏＯｆＷｏｒｋＤａｙｓａＷｅｅｋ＝０．２
週２回＝２／ＮｏＯｆＷｏｒｋＤａｙｓａＷｅｅｋ＝０．４
注：実施形態により就業日のみが考慮に入れられる。

２． ユーザのＤａｙＬｏｇｎｉｓ−１日に正規化されたログインの数を計算する。

ＤａｙＬｏｇｉｎｓ＝ＮｏＯｆＬｏｇｉｎｓＩｎＰｅｒｉｏｄ／ＮｏＯｆＷｏｒｋＤａｙｓＩｎＰｅｒｉｏｄ（以下のＤａｙＬｏｇｉｎｓの計算も参照）
３． ユーザインデックスは、以下のように計算される。

ＵｓａｇｅＩｎｄｅｘ＝ＤａｙＬｏｇｉｎｓ／ＤａｙＣｒｉｔｅｒｉｏｎ＊１００％
４． アクティビティレベルは、以下のものと等しい。

ａ． 高利用率 − ＵｓａｇｅＩｎｄｅｘ＞７５％である場合
ｂ． 中利用率 − ２５％＞＝ＵｓａｇｅＩｎｄｅｘ＝＜７５％である場合
ｃ． 低利用率 − ＵｓａｇｅＩｎｄｅｘ＜２５％である場合
ＮｏＯｆＬｏｇｉｎＩｎＰｅｒｉｏｄは、すべての日−就業および非就業についてシステムログから引き出される。１日内の複数のログインは、「１」で表されるものとする。

ＤａｙＬｏｇｉｎｓの計算
アプリケーションおよびアプリケーション担当者ごとの累積された基準は、以下の５つのフィールド内の対応するサブスクリプションオブジェクトで表される。

使用インデックス
アクティビティレベル
統計サンプルの就業日の数
サンプルのログインの数
サンプル開始日
累積されたＫＰＩを計算するために、実施形態は、累積されたＤａｙＬｏｇｉｎｓを以下によって計算する。

統計サンプルの就業日の数を増分する（就業日についてのみ）
計算日内に担当者の少なくとも１回のログインがあった場合、サンプルのログインの数を増分する
実施形態は、統計がいちばん最初に累積されるべきであることを考慮することができる。統計サンプルの就業日の数が引き続き「予想される期間＊２」よりも少ない場合、計算の結果はユーザには表示されなくてもよい。これらの場合の使用インデックスおよびアクティビティレベルは、値をＵＩに表示しないことをクライアントに伝える数字（たとえば、負）と等しくすべきである。

ＤａｙＬｏｇｉｎｓ＝サンプルのログインの数／統計サンプルの就業日の数
今日−サンプルの開始日＞年−統計サンプルの就業日の数：＝０およびサンプルのログインの数：＝０である場合。

計算ジョブ
平均累積ＫＰＩを計算するジョブは、真夜中に組織の時間帯ごとに実行することができる。非就業日の場合、ジョブは以下の２つの場合について異なる振る舞いをすることができる。

担当者がアプリケーションにログインしなかった場合、ジョブは、対応するアプリケーションに対してＫＰＩを再計算しなくてもよい。

担当者が少なくとも１回アプリケーションにログインした場合、ジョブは、統計サンプルで就業日の数を増分せずにＫＰＩを計算することができる。

実施形態において、顧客（つまり、エンドユーザ３６０が構成要素である組織）は、各自の詳細な使用分析にアクセスすることができる。実施形態は、組織および／または対組織または組織のグループにわたるベンチマーキング、および顧客のターゲットとなる使用目標を提供することができる。実施形態は、たとえば部門、拠点、事業単位への社内ＳａａＳアプリケーション予算割り振りを顧客に提供するために、この情報を、ＳａａＳライセンス価格設定と組み合わせることができる。

個々の顧客の使用分析を計算してレポートすることに加えて、実施形態は、匿名扱いの形態で複数の顧客の使用データを伴う分析を計算することができる。これにより、実施形態は、以下の事項を行うことができる。

どのＳａａＳアプリケーションが使用中であるかをカタログ作成する
アプリケーションが、全体的およびバーティカルマーケットにおいて、その競合アプリケーションに対してどのようなにランクを占めるかを決定する
ＳａａＳアプリケーション使用に関して「業界ベストプラクティス」を定量化する
顧客に、その相対的業界ランキングおよび改善のための提案を提供する
企業にわたり固有の機能に対する好ましいアプリケーションを示す
企業によるパフォーマンスレベルを比較するため、および／または監査の目的で、基準として使用されるように、固有のアプリケーションまたはアプリケーションのクラスに対して集約された使用データをマーケティングおよび販売する
会社に知られていないＳａａＳアプリケーションまたは使用を発見する
実施形態は、未知の（または既知でもある）各アプリケーション３７０の既存のユーザが誰であるかを識別する目的で、誰がアプリケーションを使用しているかを決定することができる。そのような機能は、各アプリケーション３７０ごとにいくつのユーザ３６０があるか、およびそれらの使用量に関する情報を提供することができる。

本明細書において上記で示されるように、１つまたは複数の実施形態により、この機能を達成するための方法は、以下のようなものであってもよい。

１． ネットワークトラフィックを検査すること、実施形態は、会社の公認ライセンシングになかったユーザ、たとえばクレジットカードを使用して個別にライセンスを購入した従業員を「発見」することができる。

２． どのアプリケーション３７０がどのデバイス３６０からアクセスされているかを確認するためにファイアウォールからのログを検査して、それらのデバイスの位置情報を使用すること。

３． 同様の目的でルータからのログを検査すること。

４． 同様の目的でＶＰＮログを検査すること。

５． モバイルデバイス上で発信トラフィックを監視するためにクライアントアプリケーションをインストールすること。

６． この目的で発信トラフィックを監視するためにｉＯＳでアプリケーションごとにＶＰＮを使用すること。

実施形態は、プロセッサ３４０による分析のために上記で説明される情報を統合することができる。

実施形態は、収集されたデータの比較対象先に対する「既知ユーザ」のリストを生成するように構成されてもよい。これは、次いで上記で説明される発見と比較される、Ａｃｔｉｖｅ ＤｉｒｅｃｔｏｒｙまたはＬＤＰＡのようなユーザデータベースを検査することによって達成されてもよい。次いで、出力デバイス３５０へのレポートが生成されてもよい。次いで、レポートの１つのクラスは、ユーザのこのリストと一致しないＳａａＳ使用に基づいてもよい。

ネットワークレベルにおいて、ユーザが行っていることを正確に見ることには複雑さがあるが、実施形態は、特定のアプリケーション３７０の各ユーザ３６０に関連するトラフィックボリューム（パケットまたは帯域幅のいずれか）に単に基づいて使用統計の１つのタイプに到達することができる。この使用またはアクティビティマッピングは、各アプリケーション３７０について異なっていてもよく、決定するために一部の調査を伴うことができる。

実施形態は、ユーザ３６０によって組織内でどの有料アプリケーションが使用中であるかを発見するための方法を含む。基本考慮点は、すべてのＳａａＳプロバイダが、電子メールを介して定期納品伝票をその顧客に送信することであり、納品伝票は組織がサービスを使用していることの明らかな証明である。顧客の許可を得て、および顧客の全メールサーバを検索することによって、実施形態は、どのＳａａＳアプリケーション３７０がその顧客においてエンドユーザ３６０によって契約されているかに関する情報を抽出することができる。１つのそのような実施形態は、電子メールデータベースを、既知のＳａａＳベンダーによって送信された納品伝票と比較することによるものである。実施形態は、次いで、契約されているＳａａＳサービスを見つけ出し、それらをユーザ３６０（電子メールの宛先であるユーザ）と照合することができる。それらのユーザ３６０はまた、ＳａａＳベンダーの支払い請求先であるので、それらのサービスの「社内所有者」でもある。

実施形態は、固有のベンダーによって送信された納品伝票を認識することができる。出力は、組織にサービスを提供するＳａａＳベンダーからのものであると実施形態が認識するすべてのそれらの納品伝票のリストであってもよい。実施形態は、合計支払い金額および納品伝票発行日のような納品伝票の内容から、少なくとも一部の最小の情報を抽出することができる。

実施形態はまた、購入されたライセンスの数、ライセンスの期間または更新、およびその他の関連データを決定することもできる。

実施形態において、複数年プランのベンダーであっても、すべてのベンダーが年間に少なくとも１つの納品伝票をその顧客に送信するので、過去１年以内に受信された電子メールは選別される。次いで、実施形態は、この情報を収集して、一部の価値を理解するために顧客が数週間実施形態を実行するのを待つ必要もなく、初期分析の後にこの情報を顧客に提示する。これはまた、ベンダーによる同一の顧客への支払い請求の履歴を証明することにもなる。

要約すると、実施形態は、ユーザ３６０のリスト、使用中おアプリケーション３７０の詳細、および過去に費やされた額および／または、外挿法による、将来費やされると見込まれる予想を提示することができる。

実施形態は、顧客がその効率および出費を改善できるようにするため、どのアプリケーション３７０が使用されているかを監視する。

実施形態は、ＳａａＳライセンスの使用に関連する分析およびレポートを提供し、これらは会社の予算および経費管理を支援する。実施形態は、ＳａａＳアプリケーションのユーザおよび適合ライセンス情報を収集して記憶することができる。このデータを使用統計とリンクすることで、ライセンスの追加／削除、ライセンスの割り当て、ライセンス更新、未使用ライセンスのレポート、および不適切に割り当てまたは割り振りされたライセンスのレポートを含む、高度なサブスクリプション管理が可能になる。

実施形態は、ユーザ３６０を含む組織のどれほど多くのＳａａＳ支出が所与の時点で引き続きアイドル状態にあるかを示すライセンス支出効率を計算して、図１０に示されるように、組織が浪費を最小限にするための計画立案を支援する。

実施形態は、ＳａａＳアプリケーションの価格設定モデルを収集して記憶することができる。この情報は、公的に使用可能なソース、および顧客ライセンシングデータからの匿名扱いの情報を含む複数のソースからもたらされる。次いで、実施形態は、それらのＳａａＳ価格設定モデルと、それらが顧客の配備にどのように影響を及ぼすかに関するさまざまな分析を提供することができる。２つの例は、使用に基づく会社のアプリケーションの最適コストを計算することと、同じカテゴリの複数のアプリケーションの最適コストを計算すること（たとえば、使用可能なライセンシングおよび会社全体にわたる使用のタイプに基づいて３つの異なるＳａａＳ記憶アプリケーション３７０の最適な配備を会社に示すこと）とを含む。

実施形態は、管理対象のＳａａＳアプリケーション３７０でユーザをプロビジョニング／プロビジョニング解除するための機構を提供することができる。このプロビジョニング情報は、実施形態に直接入力されてもよいか、またはＡｃｔｉｖｅ ＤｉｒｅｃｔｏｒｙまたはＬＤＡＰのようなユーザデータベースとの統合を経由してもよい。

実施形態は、ＳａａＳアプリケーション３７０の従業員ライフサイクル管理を提供することができる。実施形態は、会社における従業員の状況を、それらのＳａａＳプロビジョニングおよび使用を介して監視することができる。実施形態は、たとえば、従業員が１つまたは複数のアプリケーション３７０でプロビジョン解除される場合、従業員が退社したので他のアプリケーションでプロビジョン解除される必要はないという合図となり得るので、レポートおよびアラートを提供することができてもよい。

実施形態は、他の組織に対する組織のベンチマークを行うために、その組織内から収集されたデータを使用することができる。これは、同業者と比較して、組織が、ＳａａＳアプリケーションを使用する際の効率に関してどの位置にあるのかを組織に示すことになる。

実施形態は、「時間および動作」分析を含むことができる。ソフトウェアのコストの大きな構成要素は、ライセンシングコストに加えて、そのユーザによって費やされる時間のコストである。実施形態は、ユーザがそのジョブを行えるようにする際に、ソフトウェアがいかに効率的であるかを測定することができる。たとえば、ｓａｌｅｓｆｏｒｃｅ．ｃｏｍで販売員によって費やされる最適時間はどのくらいであるか？これは、ｓａｌｅｓｆｏｒｃｅ．ｃｏｍライセンスのコストが、直接的なソフトウェアコストだけにとどまらず、データを入力してレポートを調べる販売員によって費やされる時間のコストもあるからである。ソフトウェアはどのくらいの入力量を、どのくらいのコストで必要としているのか？入力のこのコストに対して、ソフトウェアはどのような出力を可能にするのか？
プロビジョニング能力により、実施形態は、ユーザが単に自分のデバイスを持ち込む（ｂｒｉｎｇ ｔｈｅｉｒ ｏｗｎ ｄｅｖｉｃｅｓ（ＢＹＯＤ）ことができるようにするだけではなく、ユーザがジョブを完了させるためにどのＳａａＳアプリケーションが好ましいかを選択できるようにする（ＢＹＯＳ＝Ｂｒｉｎｇ ｙｏｕｒ ｏｗｎ ＳａａＳ（自分のＳａａＳを持ち込む））。

複数のユーザが読み取り専用モードでＳａａＳアプリケーションを使用している限りにおいて、実施形態は、すべてのそうしたユーザが１つのログインを共有するための手段を提供して、組織がそのソフトウェアコストを削減できるようにすることができる。

実施形態は、使用分析サービスを複数の顧客に提供することができる。この場合、システムインテグレータ（ＳＩ）は、複数のその企業顧客によるアプリケーションの使用のより高度なビューを有する。ＳＩの顧客は、論理的な観点から完全に切り離される必要があり、相互を見ることができないが、一方、ＳＩは、企業のアプリケーションのサブセットについてのみ使用を表示する際に限定されるべきである。例：Ｇｏｏｇｌｅ Ａｐｐｌｉｃａｔｉｏｎｓ ＳＩは、Ｓａｌｅｓｆｏｒｃｅ使用ではなく、Ｇｏｏｇｌｅ Ａｐｐｌｉｃａｔｉｏｎを使用してすべての顧客の使用を見ることができる。

顧客の資格情報を使用してＳａａＳアプリケーション３７０を直接統合することによって、実施形態は、ユーザ３６０を同期させることができ、ユーザをプロビジョンおよびプロビジョン解除することができる。これは、従来のＳＳＯ−アイデンティティ管理モデルを完全に迂回する軽量のプロビジョニングシステムである。加えて、実施形態が、ユーザ３６０の電子メールアドレス（一意の識別子）を通じてユーザ３６０を一意に識別すると、次いで実施形態は、そのユーザを、実施形態が統合している任意のアプリケーション３７０に接続／プロビジョンすることができ、その結果自動軽量双方向プロビジョニングがもたらされる。

上記で述べられたように、本発明の好ましい実施形態が示され、説明されたが、多くの変更は、本発明の精神および範囲を逸脱することなく行われてもよい。したがって、本発明は、添付の特許請求の範囲による場合を除き限定されることはない。

Claims (18)

1. 少なくとも１つの処理デバイスによって実行されるとき、前記少なくとも１つの処理デバイスが、
   少なくとも１つのクライアントデバイスのセットのユーザによってネットワーク上にホスティングされる複数のソフトウェアアプリケーションの使用を特徴付けるデータを収集するステップと、
   前記収集されたデータを記憶するステップと、
   前記記憶されたデータに基づいて、前記複数のソフトウェアアプリケーションの少なくとも１つに対する少なくとも１つの使用メトリックを決定するステップとを備える方法を実行することができるようにする命令が格納された少なくとも１つのコンピュータ可読媒体。
2. 前記使用メトリックは、前記複数のソフトウェアアプリケーションのうちの単一のソフトウェアアプリケーションの少なくとも１つのクライアントデバイスの前記セットのクライアントデバイスによる使用のタイプを指示する請求項１に記載の媒体。
3. 前記使用メトリックは、前記複数のソフトウェアアプリケーションのうちの単一のソフトウェアアプリケーションの少なくとも１つのクライアントデバイスの前記セットによる使用のタイプを指示する請求項１に記載の媒体。
4. 前記データはファイアウォールに関連付けられているログから収集される請求項１に記載の媒体。
5. 前記データは前記複数のソフトウェアアプリケーションとの直接通信を介して収集される請求項１に記載の媒体。
6. 前記使用メトリックは、前記複数のソフトウェアアプリケーションの各ソフトウェアアプリケーションに固有のメタデータを使用して決定される請求項１に記載の媒体。
7. クライアントデバイスのセットのユーザによってネットワーク上にホスティングされる複数のソフトウェアアプリケーションの使用を特徴付けるデータを収集するように構成された収集モジュールと、
   前記収集されたデータを記憶するように構成されたデータ記憶モジュールと、
   前記記憶されたデータに基づいて、前記複数のソフトウェアアプリケーションの各々について少なくとも１つの使用メトリックを決定するように構成された処理モジュールとを備えるシステム。
8. 前記使用メトリックは、前記複数のソフトウェアアプリケーションのうちの単一のソフトウェアアプリケーションのクライアントデバイスの前記セットのクライアントデバイスによる使用のタイプを指示する、請求項７に記載のシステム。
9. 前記使用メトリックは、前記複数のソフトウェアアプリケーションのうちの単一のソフトウェアアプリケーションのクライアントデバイスの前記セットによる使用のタイプを指示する、請求項７に記載のシステム。
10. 前記データはファイアウォールに関連付けられているログから収集される請求項７に記載のシステム。
11. 前記データは前記複数のソフトウェアアプリケーションとの直接通信を介して収集される請求項７に記載のシステム。
12. 前記使用メトリックは、前記複数のソフトウェアアプリケーションの各ソフトウェアアプリケーションに固有のメタデータを使用して決定される請求項７に記載のシステム。
13. 少なくとも１つの処理デバイスによって実行されるとき、前記少なくとも１つの処理デバイスが、
    ファイアウォールの一方の側のユーザのセットによる、前記ファイアウォールのもう一方の側でホスティングされている複数のソフトウェアアプリケーションの使用を特徴付けるデータを収集するステップと、
    前記記憶されたデータに基づいて、前記複数のソフトウェアアプリケーションの各々に対する少なくとも１つの使用メトリックを決定するステップとを備える方法を実行することができるようにする、命令が格納された少なくとも１つのコンピュータ可読媒体。
14. 前記使用メトリックは、前記複数のソフトウェアアプリケーションのうちの単一のソフトウェアアプリケーションのユーザによる使用のタイプを指示する、請求項１３に記載の媒体。
15. 前記使用メトリックは、前記複数のソフトウェアアプリケーションのうちの単一のソフトウェアアプリケーションのユーザの前記セットによる使用のタイプを指示する、請求項１３に記載の媒体。
16. 前記データは前記ファイアウォールに関連付けられているログから収集される請求項１３に記載の媒体。
17. 前記データは前記複数のソフトウェアアプリケーションとの直接通信を介して収集される請求項１３に記載の媒体。
18. 前記使用メトリックは、前記複数のソフトウェアアプリケーションの各ソフトウェアアプリケーションに固有のメタデータを使用して決定される請求項１３に記載の媒体。

Images