(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-09-06
(54)【発明の名称】通知管理システム及び方法
(51)【国際特許分類】
H04L 41/026 20220101AFI20230830BHJP
H04L 41/084 20220101ALI20230830BHJP
【ＦＩ】
H04L41/026
H04L41/084
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023512416
(86)(22)【出願日】2021-08-20
(85)【翻訳文提出日】2023-04-10
(86)【国際出願番号】 US2021046999
(87)【国際公開番号】W WO2022040591
(87)【国際公開日】2022-02-24
(31)【優先権主張番号】63/068,334
(32)【優先日】2020-08-20
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】523057714
【氏名又は名称】シメトリック、インコーポレイテッド
(74)【代理人】
【識別番号】110000855
【氏名又は名称】弁理士法人浅村特許事務所
(72)【発明者】
【氏名】ブーン、リチャード エイ．、ジュニア
(72)【発明者】
【氏名】スリヴァスタヴァ、サンジェイ
(57)【要約】
例示の通知管理システム及び方法が記載される。一実装形態では、技術によって、あるキャリアを使用して通信する複数のデバイスが特定され、また複数のデバイスのうちの少なくとも１つと関連付けられたトリガが特定される。トリガを特定することに基づいて、これらの技術は、複数のデバイスのうちの少なくとも１つと関連付けられた少なくとも１つの業務ルールを適用し得る。これらの技術は更に、業務ルールを適用することに応答して、少なくとも１つの通知を生成し得る。
【特許請求の範囲】
【請求項1】
１つ又は複数のプロセッサと、前記１つ又は複数のプロセッサによって実行可能な命令を保存した、１つ又は複数の非一時的コンピュータ可読媒体と、を備え、前記命令は実行されるとシステムに、
キャリアを使用して通信する複数のデバイスを特定することと、
前記複数のデバイスのうちの少なくとも１つと関連付けられたトリガを特定することと、
前記トリガを特定することに応答して、前記複数のデバイスのうちの前記少なくとも１つと関連付けられた少なくとも１つの業務ルールを適用することと、
前記少なくとも１つの業務ルールを適用することに応答して、少なくとも１つの通知を生成することと、を含む動作を実行させる、システム。
【請求項2】
前記トリガは、タイマの満了、データ変更、又はユーザが定義したトリガの作動のうちの少なくとも１つである、請求項１に記載のシステム。
【請求項3】
前記トリガは、事前に定義されたトリガ、又はユーザが作成したトリガのうちの少なくとも一方である、請求項１に記載のシステム。
【請求項4】
前記通知は電子メール又はショート・メッセージ・サービス（ＳＭＳ：ｓｈｏｒｔ ｍｅｓｓａｇｅ ｓｅｒｖｉｃｅ）のメッセージのうちの少なくとも一方を含む、請求項１に記載のシステム。
【請求項5】
前記通知は前記トリガと関連付けられたアラートを含む、請求項１に記載のシステム。
【請求項6】
前記動作は前記通知をユーザ又はシステムに通信することを更に含む、請求項１に記載のシステム。
【請求項7】
前記動作は、ある特定の時間までのメッセージ要求の非同期キューイング、又は
あるアクティビティの成功した完了若しくは失敗に応答した前記メッセージ要求の同期キューイング、のうちの一方を更に含む、請求項１に記載のシステム。
【請求項8】
前記動作は前記通知と関連付けられたメッセージを作成する際に使用されるテンプレートを選択することを更に含む、請求項１に記載のシステム。
【請求項9】
前記動作は前記テンプレートを完成させるための少なくとも１つのデータ要素を取得することを更に含む、請求項８に記載のシステム。
【請求項10】
前記動作は、前記テンプレート及び前記少なくとも１つのデータ要素を使用して前記メッセージを作成することと、
前記メッセージを少なくとも一人の受信者に送信することと、を更に含む、請求項９に記載のシステム。
【請求項11】
キャリアを使用して通信する複数のデバイスを特定することと、前記複数のデバイスのうちの少なくとも１つと関連付けられたトリガを特定することと、
前記トリガを特定することに応答して、前記複数のデバイスのうちの前記少なくとも１つと関連付けられた少なくとも１つの業務ルールを適用することと、
前記少なくとも１つの業務ルールを適用することに応答して、少なくとも１つの通知を生成することと、
を含む、方法。
【請求項12】
前記トリガは、タイマの満了、データ変更、又はユーザが定義したトリガの作動のうちの少なくとも１つである、請求項１１に記載の方法。
【請求項13】
前記トリガは、事前に定義されたトリガ、又はユーザが作成したトリガのうちの少なくとも一方である、請求項１１に記載の方法。
【請求項14】
前記通知は電子メール又はショート・メッセージ・サービス（ＳＭＳ）のメッセージのうちの少なくとも一方を含む、請求項１１に記載の方法。
【請求項15】
前記通知は前記トリガと関連付けられたアラートを含む、請求項１１に記載の方法。
【請求項16】
ある特定の時間までの前記メッセージ要求の非同期キューイング、又はあるアクティビティの成功した完了若しくは失敗に応答した前記メッセージ要求の同期キューイング
の一方を更に含む、請求項１１に記載の方法。
【請求項17】
前記通知と関連付けられたメッセージを作成する際に使用されるテンプレートを選択することを更に含む、請求項１１に記載の方法。
【請求項18】
実行されると１つ又は複数のプロセッサに、キャリアを使用して通信する複数のデバイスを特定することと、
前記複数のデバイスのうちの少なくとも１つと関連付けられたトリガを特定することと、
前記トリガを特定することに応答して、前記複数のデバイスのうちの前記少なくとも１つと関連付けられた少なくとも１つの業務ルールを適用することと、
前記少なくとも１つの業務ルールを適用することに応答して、少なくとも１つの通知を生成することと、を含む動作を実行させる命令を保存している、１つ又は複数の非一時的コンピュータ可読媒体。
【請求項19】
前記トリガは、タイマの満了、データ変更、又はユーザが定義したトリガの作動のうちの少なくとも１つである、請求項１８に記載の１つ又は複数の非一時的コンピュータ可読媒体。
【請求項20】
前記通知は前記トリガと関連付けられたアラートを含む、請求項１８に記載の１つ又は複数の非一時的コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本願は２０２０年８月２０日に出願された米国仮特許出願第６３／０６８，３３４号の優先権の利益を主張し、その開示の全体を参照によって本願に組み込む。
【0002】
本開示は、ＩｏＴ（モノのインターネット（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ））デバイスなどのデバイス及び関連するデータの管理に関する。
【背景技術】
【0003】
多くの状況下で、ある事業体が自らＩｏＴスマート・デバイスを配備するときに、単一のセルラ・キャリアを活用できない場合がある。例えば、ビジネスＩｏＴ配備は、異なるセルラ・キャリアが存在する複数の領域にまたがる可能性があるか、又は逆に、単一のＩｏＴ配備（例えばコネクテッド・カー）が、複数のセルラ・キャリア・ネットワークを移動する可能性がある。また更に、セルラ・キャリア管理システム及びＩｏＴ管理プラットフォームは多種多様である。この結果、ビジネスのＩｏＴ配備は、複数のセルラ・キャリア及びＩｏＴ管理プラットフォームからの断片化した費用関連（ｆｉｎａｎｃｉａｌ）データ及び運用データで構成されている場合があり、そのビジネスが自らのＩｏＴ配備を評価する際に複雑な事態が生じる。これらの問題を克服できるシステム及び方法の必要性が存在する。
【0004】
本開示の非限定的且つ非網羅的な実施例について以下の図を参照して記載するが、これら個々の図を通して同様の参照符号は、そうではないと明記されない限りは同様の部分を指す。
【図面の簡単な説明】
【0005】
【図1】例示の実施例が実施され得る環境を示すブロック図である。
【図2】デバイス及び関連するデータを管理するためのプロセスの実施例を示すフロー図である。
【図3】最適化エンジンの実施例を示すブロック図である。
【図4A】最適化アルゴリズムを作成、編集、及びテストするためのプロセスの実施例を示すフロー図である。
【図4B】最適化プロセスの実施例を示すフロー図である。
【図5】最適化アルゴリズムを実行するためのプロセスの実施例を示すフロー図である。
【図6】通知エンジンの実施例を示すブロック図である。
【図7】通知を生成及び通信するためのプロセスの実施例を示すフロー図である。
【図8】様々なタイプの通知を生成するためのプロセスの実施例を示すフロー図である。
【図9】通知設定を選択及び構成する例示の実施例を示す図である。
【図10】ＩｏＴデバイスに関連する複数のＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）要求を処理するためのプロセスの実施例を示すフロー図である。
【図11A】バルクＡＰＩ処理を行うためのプロセスの例示の実施例を示す図である。
【図11B】バルクＡＰＩエンジンの様々な特徴の例示の実施例を示す図である。
【図12】ビジネス・プロセス自動化のためのプロセスの例示の実施例を示す図である。
【図13A】ＡＰＩカタログの様々な特徴の例示の実施例を示す図である。
【図13B】サービス型ＡＰＩ（ＡＰＩａａＳ：ＡＰＩ ａｓ ａ Ｓｅｒｖｉｃｅ）を実施するためのプロセスの例示の実施例を示す図である。
【図14】最適化エンジンの実装の例示の実施例を示す図である。
【図15】最適化エンジンの実装の別の例示の実施例を示す図である。
【図16】ルール・ベースの最適化エンジンの例示の実施例を示す図である。
【図17】バルクＡＰＩエンジンの実装の例示の実施例を示す図である。
【図18】デバイス管理システムのユーザに様々な情報を提示するＧＵＩの例示の実施例を示す図である。
【図19】デバイス管理システムのユーザに様々な情報を提示するＧＵＩの例示の実施例を示す図である。
【図20】デバイス管理システムのユーザに様々な情報を提示するＧＵＩの例示の実施例を示す図である。
【図21】１つ又は複数のクエリを構築するために使用され得るＧＵＩの例示の実施例を示す図である。
【図22】複数のポッドを包含した最適化アンサンブルの例示の実施例を示す図である。
【図23】コンピューティング・デバイスの例示のブロック図を示す図である。
【発明を実施するための形態】
【0006】
いくつかの実施例では、本明細書で検討するシステム及び方法は、複数のデバイスと関連付けられた様々な情報管理タスクを行う。特定の実施例では、これらのシステム及び方法は、任意の数の地理的エリア内に配備されたＩｏＴ（モノのインターネット）デバイスと関連付けられたセルラ接続性データの情報管理と関連付けられている。
【0007】
以下の開示では、その一部を形成する添付の図面を参照するが、これらの図面には例示として、本開示が実施され得る具体的な実装形態が示されている。本開示の範囲から逸脱することなく他の実装形態を利用してもよくまた構造の変更が行われてもよいことが理解される。明細書中の「一実施例」、「ある実施例」、「例示の実施例」等への言及は、その記載される実施例が特定の特徴、構造、又は特性を含み得ることを示唆しているが、全ての実施例がその特定の特徴、構造、又は特性を必ずしも含んでいる訳ではない場合がある。また更に、そのような句は必ずしも同じ実施例を指すものではない。更に、特定の特徴、構造、又は特性をある実施例との関連において記載するが、明示的に記載されているか否かに関わらず、そのような特徴、構造、又は特性を他の実施例との関連において変更することが当業者の知見の範囲内にあることは論を待たない。
【0008】
本明細書に開示するシステム、デバイス、及び方法の実装形態は、本明細書で検討するように、例えば１つ又は複数のプロセッサ及びシステム・メモリなどのコンピュータ・ハードウェアを含む、専用又は汎用コンピュータを備え得るか、又は利用し得る。本開示の範囲内にある実装形態はまた、コンピュータ実行可能命令及び／又はデータ構造を担持又は保存するための、物理的な及び他のコンピュータ可読媒体も含み得る。そのようなコンピュータ可読媒体は、汎用又は専用コンピュータ・システムがアクセス可能な任意の利用可能な媒体であり得る。コンピュータ実行可能命令を保存するコンピュータ可読媒体はコンピュータ・ストレージ媒体（デバイス）である。コンピュータ実行可能命令を担持するコンピュータ可読媒体は伝達媒体である。このように、限定ではなく例として、本開示の実装形態は、少なくとも２つの明確に種類の異なるコンピュータ可読媒体、すなわちコンピュータ・ストレージ媒体（デバイス）と、伝達媒体と、を備え得る。
【0009】
コンピュータ・ストレージ媒体（デバイス）としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭ、（例えばＲＡＭベースの）ソリッド・ステート・ドライブ（ＳＳＤ：ｓｏｌｉｄ ｓｔａｔｅ ｄｒｉｖｅ）、フラッシュ・メモリ、相変化メモリ（ＰＣＭ：ｐｈａｓｅ－ｃｈａｎｇｅ ｍｅｍｏｒｙ）、他のタイプのメモリ、他の光学ディスク・ストレージ、磁気ディスク・ストレージ若しくは他の磁気ストレージ・デバイス、又は、コンピュータ実行可能命令若しくはデータ構造の形態の所望のプログラム・コード手段を保存するために使用可能且つ汎用若しくは専用コンピュータによってアクセス可能な、任意の他の媒体が挙げられる。
【0010】
本明細書に開示するデバイス、システム、及び方法の実装形態は、コンピュータ・ネットワークを介して通信し得る。「ネットワーク」は、コンピュータ・システム間及び／又はモジュール間及び／又は他の電子デバイス間での電子データの伝送を可能にする、１つ又は複数のデータ・リンクとして定義される。情報がネットワーク或いは別の通信接続（ハードウェア組込の、ワイヤレスの、又はハードウェア組込若しくはワイヤレスの組合せのいずれか）を介してコンピュータに伝送又は提供されるとき、コンピュータはその接続を伝達媒体と見なしても差し支えない。伝達媒体は、汎用又は専用コンピュータによってアクセス可能な、コンピュータ実行可能命令又はデータ構造の形態の所望のプログラム・コード手段を担持するために使用可能な、ネットワーク及び／又はデータ・リンクを含み得る。上記したものの組合せもコンピュータ可読媒体の範囲に含めるべきである。
【0011】
コンピュータ実行可能命令は例えば、プロセッサにおいて実行されると、汎用コンピュータ、専用コンピュータ、又は専用処理デバイスに特定の機能又は機能の群を実施させる命令及びデータを含む。コンピュータ実行可能命令は例えば、バイナリ、アセンブリ言語などの中間形式命令、又は更にはソース・コードであってもよい。主題は構造的な特徴及び／又は方法論的な動作に特有の言語で記載されているが、付属の特許請求の範囲において規定される主題は、必ずしも記載されている特徴又は本明細書に記載されている動作に限定されないことが理解されるべきである。むしろ記載されている特徴及び動作は、各請求項を実施する例示の形態として開示されている。
【0012】
当業者は、本開示が、パーソナル・コンピュータ、デスクトップ・コンピュータ、ラップトップ・コンピュータ、メッセージ・プロセッサ、ハンド・ヘルド・デバイス、マルチ・プロセッサ・システム、マイクロプロセッサ・ベースの又はプログラム可能な消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ、携帯電話、ＰＤＡ、タブレット、ポケットベル、ルータ、スイッチ、様々なストレージ・デバイス、などを含む、多くのタイプのコンピュータ・システム構成を有するネットワーク・コンピューティング環境において実施され得ることを諒解するであろう。本開示はまた、ネットワークを介して（実線接続データ・リンク、ワイヤレス・データ・リンクによって、又は実線接続及びワイヤレスのデータ・リンクの組合せによってのいずれかで）リンクされたローカル及びリモートの両方のコンピュータ・システムが、タスクを実行する、分散型システム環境においても実施され得る。分散型システム環境では、プログラム・モジュールを、ローカル及びリモートの両方のメモリ・ストレージ・デバイス内に配置し得る。
【0013】
更に、適切である場合、本明細書に記載する機能を、ハードウェア、ソフトウェア、ファームウェア、デジタル構成要素、又はアナログ構成要素のうちの、１つ又は複数において実施することができる。例えば、１つ又は複数の特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）を、本明細書に記載するシステム及び手順のうちの１つ又は複数を実行するようにプログラムすることができる。特定のシステム構成要素に言及するために、本明細書及び特許請求の範囲の全体を通して特定の用語が使用される。当業者は構成要素が異なる名称で呼ばれる場合のあることを諒解するであろう。本文書は、名称が異なるが機能は異ならない構成要素を区別することは意図していない。
【0014】
本明細書で検討するセンサ実施例は、コンピュータ・ハードウェア、ソフトウェア、ファームウェア、又はこれらの機能の少なくとも一部を実施するためのこれらの任意の組合せを備え得ることに留意すべきである。例えば、センサは、１つ又は複数のプロセッサにおいて実行されるように構成されているコンピュータ・コードを含んでもよく、また、コンピュータ・コードによって制御されるハードウェア・ロジック／電気回路を含んでもよい。これらの例示のデバイスは本明細書において例示の目的で提供されており、限定を行うようには意図されていない。本開示の実施例は、当業者には知られているであろう更に別のタイプのデバイスにおいて実装され得る。
【0015】
本開示の少なくともいくつかの実施例は、任意のコンピュータ使用可能媒体に保存されるそのような（例えばソフトウェアの形態の）ロジックを備えるコンピュータ・プログラム製品に向けられている。そのようなソフトウェアは、１つ又は複数のデータ処理デバイスにおいて実行されると、本明細書に記載するようにデバイスを動作させる。
【0016】
いくつかの実施例では、本明細書に記載するシステム及び方法は、（企業業務などの）ビジネスＩｏＴ配備に関するデータの情報管理を提供し、ＩｏＴデバイスなどの配備されたアセットの目録を受信し得る。管理されるデータは、事業体からの加入者識別モジュール（ＳＩＭ：ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）と関連付けられた情報、並びに、要求される接続性データ、例えば、１つ又は複数のセルラ・キャリアのＳＩＭと関連付けられた使用量及び評価データ（例えば価格決定プラン）などを含み得る。記載されているシステム及び方法はまた、セルラ・キャリアからＳＩＭと関連付けられたデータを受信し、複数のセルラ・キャリアにまたがるデータＳＩＭ、使用量、及び評価要素を、単一の統一された業務ビューへと標準化及び集約し得る。更に、システム及び方法は、私設のセキュアなウェブサイト又はウェブ・ベースのアプリケーションを介して、配備されたＳＩＭ（例えば、エンタープライズＩｏＴ配備）からの費用関連情報及び運用情報を事業体に提供し得る。本明細書で使用する場合、セルラ・キャリアは、キャリア、データ・キャリア、セルラ・サービス・プロバイダ、サービス・プロバイダなどと呼ばれる場合がある。
【0017】
ビジネスにおいて、ネットワークを形成するインテリジェントな物理的構成要素を備えるＩｏＴスマート・デバイスの配備がますます拡大している。例えば、これらのＩｏＴデバイスは、モニタリング、制御、最適化、及び自動化によって業績を改善するための、データの収集、分析、送信、及び受信のために使用され得る。いくつかの実施例では、ＩｏＴデバイスは産業及び産業の各分野の見直しを行うために使用される。例えば、風力タービンの場合、小型マイクロコントローラによって、各ロータ・ブレードを最大の風力エネルギーが使用されるような方法で回転ごとに制御することができる。別の実例として、いくつかの自律型車両の会社では、車両周囲の物体を常時スキャンする、及び交通管制、交通標識などを継続的に読み取るために、センサ及びソフトウェアを活用している。構築されセルラ接続機能性を介して車両に送達される詳細な三次元マップと結合されて、自律型車両の配備が増加し続けている。本明細書で検討するシステム及び方法は、事業体が顧客、他のシステムなどと対話する様式を変えることで、新しく登場してきた技術に対しても有用である。
【0018】
本明細書に記載するシステム及び方法は、ビジネスＩｏＴ配備におけるマルチ・セルラ・キャリア接続性に関連する問題の克服を助ける。本明細書で検討するシステム及び方法を使用して、既存のシステムの限界を緩和又は排除することができる。
【0019】
いくつかの状況では、従来の情報管理システムは多くの場合、サーバ又はデスクトップ・コンピュータなどの固定されたコンピューティング・デバイスからのデータの組織化、保護、及び回復に注力している。その結果、人が管理しているデータ及びモバイル・データが従来の情報管理システムの管理範囲の外部に分散される場合があり、そのデータにはしたがってバック・アップ又はそれ以外の能動的管理が行われないことになる。したがって、モバイル・デバイスが紛失若しくは破損したか又はホストされているサービスにサービス中断があった場合、人の非常に重要なデータが失われ、それを回復する方法が何もなくなるというリスクが存在する。
【0020】
本明細書に記載するシステム及び方法は、上記の問題を克服すること、及び追加の利益を提供することができる。例えば、本明細書に記載するシステム及び方法は、セルラＩｏＴデバイスなどの複数のデバイスへの最適なデータ・キャリア割り当てを特定するために、様々なタイプのデータを受信及び分析し得る。これらのシステム及び方法では、複数のシナリオを同時に実行して、それらのデバイスにサービスを提供する及びデバイスのパフォーマンスを最適化するコストを最適化するために、特定のキャリア（及び特定のキャリア・プラン）にどのデバイスを割り当てるべきかを決定することによって、この割り当てが最適化される。特定の最適化及び分析に基づいて、記載されているシステム及び方法は、決定された最適化を満足するような、１つ又は複数のデバイスと関連付けられたサービスの変更の勧告を生成する。
【0021】
更に、本明細書で検討するシステム及び方法は、対話型クエリ・ビルダ（「対話型クエリ・エンジン」とも呼ばれる）、通知エンジン、報告エンジン、及び他の構成要素、方法などの、様々な実施例及び特徴を記載する。
【0022】
図１は、例示の実施例が実施され得る環境１００を示すブロック図である。図１に示すように、デバイス管理システム１０２は、第１のデバイス１０４、第２のデバイス１０６、第１のデータ・ソース１０８、第２のデータ・ソース１１０、第１のサービス・プロバイダ１１２、及び第２のサービス・プロバイダ１１４に結合されている。デバイス１０２及び１０４は、ＩｏＴデバイス、又はセルラ・ネットワーク若しくは他のデータ通信システムを介して通信する他のデバイスなどの、任意のタイプのデバイスであり得る。いくつかの実施例では、デバイス１０２、１０４は、起動、キャンセル、停止、及び不明などの、関連するデバイス状態を有し得る。図１には２つのデバイス１０２及び１０４が示されているが、特定の実装形態は、デバイス管理システム１０２に結合された任意の数のデバイス１０２、１０４を含み得る。
【0023】
データ・ソース１０８及び１１０は、デバイス管理システム１０２に任意のタイプのデータを提供する（又はデバイス管理システム１０２から任意のタイプのデータを受信する）、任意のタイプのデータ・ソースとすることができる。データ・ソース１０８及び１１０は、１つ又は複数のサード・パーティ企業又は他のエンティティと関連付けられ得る。いくつかの実施例では、データ・ソース１０８、１１０は、製造者情報、ハードウェア情報、ネットワーク情報、オペレーティング・システム情報、プログラム可能性情報、地理位置情報などに関連するデータを提供し得る。図１には２つのデータ・ソース１０８及び１１０が示されているが、特定の実装形態は、デバイス管理システム１０２に結合された任意の数のデータ・ソース１０８、１１０を含み得る。
【0024】
サービス・プロバイダ１１２及び１１４は、デバイス管理システム１０２にサービスを提供する（又はデバイス管理システム１０２から任意のタイプのサービスを受信する）、任意のタイプのサービス・プロバイダとすることができる。例えば、サービス・プロバイダ１１２及び／又は１１４は、セルラ・サービス・プロバイダ又は任意の他のタイプのサービスを提供するエンティティであってもよい。図１には２つのサービス・プロバイダ１１２及び１１４が示されているが、特定の実装形態は、デバイス管理システム１０２に結合された任意の数のサービス・プロバイダ１１２、１１４を含み得る。
【0025】
いくつかの実施例では、デバイス管理システム１０２は、任意の数のデータ通信ネットワーク、セルラ通信ネットワーク、又は他の通信ネットワークを介して、デバイス１０４、１０６、データ・ソース１０８、１１０、及びサービス・プロバイダ１１２、１１４に結合される。デバイス管理システム１０２と、デバイス１０４、１０６、データ・ソース１０８、１１０、及びサービス・プロバイダ１１２、１１４との間の通信は、任意の通信プロトコルを使用する任意のタイプのネットワーク・トポロジを使用してもよい。
【0026】
図１に示されているように、デバイス管理システム１０２はまた、デバイス管理システム１０２と関連付けられた様々な情報を保存する、データベース１１６にも結合される。例えば、データベース１１６は、任意の数の管理されるデバイス１０４、１０６と関連付けられたデータ、任意の数のセルラ・キャリアと関連付けられたサービス／料金データ、ＣＤＲ（呼詳細記録（Ｃａｌｌ Ｄｅｔａｉｌ Ｒｅｃｏｒｄ））及び使用量データ、並びに統計データを保存し得る。データベース１１６はまた、任意の他のタイプのデータ、例えばデバイス管理システム１０２によって生成又は受信される任意のデータも保存し得る。
【0027】
いくつかの実施例では、デバイス管理システム１０２は、通信管理部１１８と、プロセッサ１２０と、メモリ１２２と、を含む。通信管理部１１８は、デバイス管理システム１０２が、図１に示すデバイス１０４、１０６及びデータ・ソース１０８、１１０などの、他のシステムと通信するのを可能にする。プロセッサ１２０は、本明細書で検討するように、デバイス管理システム１０２によって提供される機能性を実施するための様々な命令を実行する。メモリ１２２はこれらの命令を、プロセッサ１２０並びにデバイス管理システム１０２に含まれる他のモジュール及び構成要素によって使用される他のデータと共に保存する。
【0028】
更に、デバイス管理システム１０２は、グラフィカル・クエリ・ビルダ１２４と、通知エンジン１２６と、最適化エンジン１２８と、を含む。グラフィカル・クエリ・ビルダ１２４は、システム又はユーザ（例えばシステム管理者）が、デバイス管理システム１０２の動作の少なくとも一部を定義できるクエリを構築するのを可能にし得る。いくつかの実施例では、本明細書で検討する対話型クエリ・ビルダ上にグラフィカル・クエリ・ビルダ１２４が拡張される。例えば、対話型クエリ・ビルダは、ユーザが１つ又は複数の基礎となるデータ・カタログと対話することを可能にする、ＧＵＩ（グラフィカル・ユーザー・インターフェース（ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ））を含む。このＧＵＩによって、図２４に示すように、ユーザが情報のセットから選択を行うこと及び各々に対して基準を適用することが可能になる。グラフィカル・クエリ・ビルダ１２４の代替の実施例では、図２５に示すように、ユーザが対話型ウィジェット及びチャート／グラフの使用を介して、関心のあるデバイスの場所を視覚的に特定できる。
【0029】
通知エンジン１２６は、１つ又は複数のシステム又はユーザに、様々なアラート、報告、メッセージ、及び他の通知を提供し得る。これらの通知は、本明細書に記載するように、ルール、ビジネス・プロセス、及び他の技術に基づいていてもよい。最適化エンジン１２８は、複数のデバイスのデータ・プラン、キャリア、及び他の側面を最適化して、複数のデバイスと関連付けられたセルラ・サービスのコストを最適化する（例えば最小限にする）又は複数のデバイスと関連付けられた他の要因を最適化するために、複数のデバイス（例えば、デバイス１０４、１０６）、使用量データ、料金プランなどを分析し得る。例示のアラートとしては、高使用量アラート、新規起動アラート、使用量なしアラート、デバイスごとの使用量アラート、閾値超過の使用量、などが挙げられる。例示のルールとしては、会社情報、通知タイプ、閾値などが挙げられる。
【0030】
デバイス管理システム１０２は、バルクＡＰＩ（アプリケーション・プログラミング・インターフェース）エンジン１３０と、統計的分析エンジン１３２と、評価及び仲介エンジン１３４と、を更に含む。バルクＡＰＩエンジン１３０は、本明細書で検討するように、複数のＡＰＩ要求をグループに分け、ＡＰＩ要求のそれらのグループを処理することによって、ＩｏＴデバイスに関連する複数のＡＰＩ要求を処理することができる。バルクＡＰＩエンジン１３０はまた、最初に成功裡に実施されなかったＡＰＩ要求を再提出することを含む、様々なＡＰＩ要求も管理する。
【0031】
統計的分析エンジン１３２は、デバイス管理システム１０２によって受信及び管理されるデータに対して様々な統計的操作を行う。いくつかの実施例では、統計的分析エンジン１３２は、統計的操作を行うときに、デバイス・プロファイル情報及び使用量データを使用してもよい。いくつかの実施例では、統計的分析エンジン１３２は、データベース１１６にデータを保存すること、及びデータベース１１６からデータを取得することができる。例えば、統計的分析エンジン１３２は、デバイスのプロファイル、ユーザが作成したタグ、サード・パーティのデバイス情報、使用量情報などの複数のデータセットを組み合わせ、相関させてもよい。統計的分析エンジン１３２はまた複数の分析を実行してもよく、ユーザが容易に利用できるフォーマットで提示できるように分析の結果をマイニングする。いくつかの実施例では、統計的分析エンジン１３２によって生成された結果を、本明細書で検討する対話型クエリ・ビルダによって使用されるデータ・カタログに追加してもよい。統計的分析エンジン１３２によって行われ得る例示の分析には、標準偏差及び分散、平均、全期間（ｌｉｆｅｔｉｍｅ）、直近１２カ月、並びに月次集約などの、様々な使用パターンが含まれる。
【0032】
評価及び仲介エンジン１３４は、デバイス管理システム１０２のプロバイダのサード・パーティの顧客及びパートナーである顧客に支払い義務のある、接続性、デバイス管理、及び他のサービスの料金を計算し得る。評価及び仲介エンジン１３４はまた、会社の異なる部門又は部署への社内コスト割り当てのためにも使用され得る。いくつかの実施例では、以下の３タイプの評価モデルが存在する。
【0033】
１．コスト・プラス・マークアップ－このモデルでは、顧客がそのキャリアに支払うコストが各ＩｏＴデバイスに分散され、その後マークアップが加算されて、下流の顧客が支払うべき料金が計算される。
【0034】
２．単一価格リスト－このモデルでは、下流の顧客は自らが使用するサービスについての価格リストに基づいて課金される。
【0035】
３．複数価格リスト－このモデルでは、下流の顧客は２つ以上の価格リストを選択することができ、その後デバイスの使用事例に基づいて、複数の価格リストのうちの１つを特定のデバイスに割り当てる。
【0036】
評価及び仲介エンジン１３４の仲介の側面は、下流の顧客によって使用（及び計測）される特定のタイプのサービスが課金可能である又は課金可能でないとして識別されるような能力を提供する。評価及び仲介エンジン１３４はまた、以下のような１つ又は複数の統合も実現し得る。
【0037】
１．特定の下流の顧客／部門へのデバイス割り当ては、顧客のＥＲＰ又は注文管理システムから発生する。
【0038】
２．料金計算は、請求処理システム又は他のシステムと統合されることになる１つ又は複数のＡＰＩを介して利用可能となり得る。
【0039】
図１に示すように、デバイス管理システム１０２はまた、ビジネス・プロセス自動化エンジン１３６及びサービス／料金プラン管理システム１３８も含む。ビジネス・プロセス自動化エンジン１３６は、本明細書で検討するような様々な業務ルール、業務活動トリガなどをユーザ（例えば管理者）又はシステムが定義することを可能にする。特定の実装形態では、ビジネス・プロセス自動化エンジン１３６は、複数の業務ルールを同時に又は同じプロセス内で連続的に適用（又は実施）し得る。このことを「積層型（ｓｔａｃｋｉｎｇ）」業務ルールと呼ぶ場合がある。いくつかの実施例では、ビジネス・プロセス自動化エンジン１３６は、業務ルール、業務活動トリガなどに応答して様々な通知を提供するための通知エンジン１２６と組み合わされて機能する。サービス／料金プラン管理システム１３８は、任意の数の異なるキャリアによって提示される、様々なサービス及び料金プランをモニタする。
【0040】
デバイス管理システム１０２中の様々な構成要素（例えばエンジン）は、バス１４０又は他の通信機構によって相互接続され得る。図１には単一のバス１４０が示されているが、他の実施例は、特定の構成要素が互いに通信するのを可能にする、任意の数のバス１４０を含み得る。
【0041】
いくつかの実施例では、デバイス管理システム１０２は、任意の数のキャリアから様々なタイプのデータを受信し得る。例示のタイプのデータとしては、ＳＩＭ目録データ、デバイス情報、使用量データ、変更履歴、アカウント情報などが挙げられる。
【0042】
特定の実施例では、本明細書に開示するシステム及び方法は、複数のデバイスの制御を、任意の数のキャリア、料金プランなどにわたって同時にサポートできる。更に、記載されているシステム及び方法は、単一のデバイスと関連付けられたデータを制御及び識別し得る。この場合、これらのシステムは、多種多様なデバイス分析及びデバイス制御を、低粒度のレベルからデバイスの大きなグループへの対処まで、同時に提供する。
【0043】
図１の実施例は単なる実例として与えられていることが諒解されるであろう。他の実施例は、本開示の範囲から逸脱することなくより少ない又は追加の構成要素を含み得る。更に、限定するものではないが、図示されている構成要素が組み合わされても、又は他の構成要素内に含まれてもよい。
【0044】
図２は、デバイス及び関連するデータを管理するためのプロセス２００の実施例を示すフロー図である。最初に、デバイス管理システムは、複数のデバイスからデバイスのデータを受信する２０２。複数のデバイスは異なるタイプのデバイスであっても、異なる地理的エリア内に配置されても、及び異なるサービス・プロバイダ（例えば、異なるセルラ通信ネットワーク）からサービスを受けてもよい。プロセス２００は、デバイス管理システムが複数のデータ・ソースからデータを受信して２０４継続する。デバイス管理システムはまた、複数のサービス・プロバイダからサービス／料金データも受信する２０６。
【0045】
プロセス２００は、最適化エンジンが、複数のデバイスに関する全体的なサービス料金を最適化するために、複数のデバイス、複数のデータ・ソース、及び複数のサービス・プロバイダから受信されるデータを分析して２０８継続する。デバイス管理システムは更に、最適化エンジンの分析に基づいて、推奨されるサービス／料金変更を生成する２１０。いくつかの実施例では、デバイス管理システムは、１つ又は複数のデバイスの過去の使用量データ並びに他の要因及びデータに基づいて、第１の料金プランを第２の料金プランと比較し得る。
【0046】
プロセスは、デバイス管理システムが推奨されるサービス／料金変更をサービス／料金プラン管理システムに通信して２１２継続する。デバイス管理システムは次いで、複数のデバイス、複数のデータ・ソース、複数のサービス・プロバイダ、及び分析／最適化の結果と関連付けられたデータを保存する２１４。プロセス２００は、デバイス管理システムが、デバイスのデータ、複数のデータ・ソースからのデータ、及びサービス／料金データの受信及び分析を継続して２１６継続する。いくつかの実施例では、デバイス管理システムは受信されるデータを規則的にモニタし、受信されるデータの変化に基づいて全体的なサービス料金を継続的に最適化する。
【0047】
図３は、最適化エンジン１２８の実施例を示すブロック図である。図３に示すように、最適化エンジン１２８は、通信管理部３０２と、プロセッサ３０４と、メモリ３０６と、を含む。通信管理部３０２は、最適化エンジン１２８が他のシステム及び構成要素と通信するのを可能にする。プロセッサ３０４は、本明細書で検討するように、最適化エンジン１２８によって提供される機能性を実施するための様々な命令を実行する。メモリ３０６はこれらの命令を、プロセッサ３０４並びに最適化エンジン１２８に含まれる他のモジュール及び構成要素によって使用される他のデータと共に保存する。
【0048】
更に、最適化エンジン１２８は、シナリオ実行管理部３０８と、キャリア・データ管理部３１０と、変曲点モジュール３１２と、を含む。シナリオ実行管理部３０８は、例えば様々なデバイスに関するサービス・プランを異なるキャリアに変更することによる、価格決定及びサービスの様々な結果を比較するための、様々なシナリオを実施する。キャリア・データ管理部３１０は、異なる料金プラン、対象地理的エリアなどの異なるキャリアに関する現在のデータを、識別及び維持する。変曲点モジュール３１２は、ある料金プランから別の料金プランに移動するべきデバイスの最適な数を決定し得る。いくつかの実施例では、変曲点モジュール３１２は、２つの料金プランに関する組み合わされたコストが最適化されるように料金プラン間を移動するべきデバイスの最適な数を決定するための、局所極小を識別し得る。この実施例は、料金プラン移動の最適な数を見付けるために複数の手法をテストし得る。いくつかの実装形態では、変曲点モジュール３１２は、ユーザが視覚的エディタを使用して異なる手法をテストするのを可能にする方法を含み得る。
【0049】
最適化エンジン１２８はまた、デバイス・タグ付け管理部３１４、予測及びシミュレーション・モジュール３１６、及びキャリア横断最適化モジュール３１８も含む。デバイス・タグ付け管理部３１４はユーザに、タグ又は使用量プロファイルなどの任意のデバイス属性を使用して定義されることになるデバイスの「ポッド（ｐｏｄ）」を作成させる。これらのポッドは、最適化ルール及び適用される制約の様々なセットを有し得る。
【0050】
予測及びシミュレーション・モジュール３１６は、予測機能及びシミュレーション機能の両方を実施する。予測に関して、通常は請求サイクルの終了前に最適化が行われるが、このことは、最適化が完了し料金プランが変更された後で、デバイスが引き続きデータを使用することを意味する。この状況を緩和するために、本明細書に記載するシステム及び方法は、請求サイクルが終了する前の最後の最適化実行の時点で利用可能な直近の使用量データに、「予測」を追加する。これらの予測は顧客の必要に応じて、デバイス・レベル、ポッド・レベル、料金プラン・レベル、又は集計レベルにおけるものであり得る。
【0051】
シミュレーションに関して、予測及びシミュレーション・モジュール３１６は、１つ又は複数の将来の請求処理期間中のデバイスの数及びデータ使用量を予想するために、モンテ・カルロ・シミュレーションを使用し得る。次いでシミュレートされた使用量に対して評価エンジンが適用され得る。いくつかの実施例では、予測及びシミュレーション・モジュール３１６は、現地に配備されたＩｏＴデバイスに対するＯＴＡ（ｏｖｅｒ ｔｈｅ ａｉｒ）ソフトウェア更新及び他の技術マイグレーションの計画などのシナリオのコストを推定するために使用され得る。
【0052】
キャリア横断最適化モジュール３１８は、様々なキャリアによって提示される料金プランを収集した目録を使用する。いくつかの実施例では、現在のキャリアによって提示される料金プランに対して最適化が行われ、また１つ又は複数の他のキャリアによって提示される料金プランのリストに対して、別の最適化が行われる。
【0053】
他の実施例では、最適化エンジン１２８は、ユーザが、例えばＧＵＩを介して最適化プロセス（最適化アルゴリズムとも呼ばれる）を定義するルール及び機能を定義することを可能にする、視覚的エディタを使用してもよい。ユーザは、複数のより小さい個々のルール及び機能をより大きい最適化プロセスに組み込むことによって、より大きい最適化プロセスを作成し得る。将来の最適化プロセスを作成するときに、より大きい最適化プロセスの特定の部分を再利用することができる。更に、ユーザは、個々の各ステップ／機能の挙動及び動作をテストし、より大きい最適化プロセスの構築を継続する前に、最適化アクティビティに対する個々のステップ／機能の結果を分析することができる。いくつかの実施例では、この視覚的エディタは、新しい最適化シナリオの高速モデリング及び新しい最適化プロセスの作成をサポートする。
【0054】
図４Ａは、最適化アルゴリズムを作成、編集、及びテストするためのプロセス４００の実施例を示すフロー図である。最初に、プロセスは最適化プロセスの目標を決定する４０２。プロセスは、最適化プロセスと関連付けられたルールを定義すること４０４によって継続される。ある特定の最適化アルゴリズムは任意の数のルールを含み得る。いくつかの実施例では、最適化アルゴリズムを作成するユーザ又はシステムは、ルールを最適化アルゴリズムに追加する前に、それらを個別に選択及びテストし得る。
【0055】
プロセス４００は４０４で定義されたルールがテストされる４０６ことで継続し、ルールのテストの結果が評価される。４０８においてテストの結果が成功でない場合、プロセスはルールの編集を継続し４１０、編集されたルールを４０６において再テストする。４０８においてテストの結果が成功であった場合、そのルールが最適化アルゴリズムに追加される４１２。次いでユーザ又はシステムは別のルールを定義し４１４、次いで４０６において新しいルールのテスト及び評価を行う。４００のプロセスは、最適化アルゴリズムが最適化プロセスの目標を満たすまで新しいルールを追加及びテストすることによって継続される。
【0056】
図４Ｂは、最適化プロセス４５０の実施例を示すフロー図である。最初に、プロセス４５０は１つ又は複数のポッド、例えばデバイスのグループを作成する４５２。上述したように、ポッドは、タグ又は使用量プロファイルなどの任意のデバイス属性を使用して定義された、デバイスのグループであり得る。プロセス４５０は、異なるシナリオをカバーするための複数の最適化アルゴリズムを生成すること４５４によって継続される。次いでプロセスは、適用可能であれば、ポッドごとに各最適化アルゴリズムを実行する４５６。プロセス４５０は、ポッドごとに各最適化アルゴリズムから最良の結果を選択すること４５８によって継続される。いくつかの実施例では、プロセスは、新しい最適化アルゴリズム及び改善された最適化アルゴリズムを識別するために、パフォーマンス統計（例えば、最適化アルゴリズム及びコード）を分析し得る４６０。
【0057】
いくつかの実施例では、最適化アンサンブル（又はモデル）とは、各々がデバイスへの料金プランの最良の割り当てを予測することのできる、相互排他的な最適化アルゴリズムの集合を表す。最適化アンサンブルはまた、様々なステップを実行すること、エラー・シナリオに対処すること、パフォーマンス統計を分析すること、及び適切なキャリアについて料金プラン変更を実施するための（本明細書で検討する）バルクＡＰＩエンジンによって使用されるプラン変更マニフェストを作成することが可能な、一般化されたオーケストレーション・モジュールも含み得る。
【0058】
いくつかの実施例では、本明細書で検討する様々な機能を実施するべく、新しいルールを編集又は追加する、新しい最適化アルゴリズムを編集又は追加する、新しいアンサンブルを編集又は追加する、及び新しいポッドを編集又は追加するために、視覚的エディタが使用され得る。特定の実装形態では、ルール・ベースのアーキテクチャによって、ルールと呼ばれる場合のある小さい機能へのコードの分解がサポートされ得る。記載されているシステム及び方法は、任意の数のルールのバージョン制御を提供し得る。いくつかの実施例では、システム及び方法は、ルール、最適化アルゴリズムなどの開発及びテストのための、様々なテスト用の、デバグ用の、状態管理用の、及び他のツールを含み得る。特定の実装形態では、システム及び方法は、様々なロギング機能及び調整機能を実施し得る。ユーザは、任意の数のアルゴリズム（例えば最適化アルゴリズム）及びアンサンブルの作成と、アルゴリズム及びアンサンブルのテストと、テストが成功であった場合の１つ又は複数のアルゴリズム及び／又はアンサンブルの配備と、を行い得る。
【0059】
図５は、最適化アルゴリズムを実行するためのプロセス５００の実施例を示すフロー図である。最初に５０２において、プロセスはポッドごとに、料金プランＡから料金プランＢへの変更、又は料金プランＢから料金プランＡへの変更などの、全ての有益な料金プラン変更シナリオを生成する。いくつかの実施例では、料金プラン変更シナリオは各々が一意的（例えば相互排他的）であり、可能なあらゆる組合せを包含する。例えば、１０個のデバイスと２つの利用可能なキャリア（各キャリアが１つの料金プランを有する）とが存在する場合、可能な組合せは以下を含む：キャリア１のデバイス１～９とキャリア２のデバイス１０、キャリア１のデバイス１～８とキャリア２のデバイス９～１０、キャリア１のデバイス１及び３とキャリア２のデバイス２及び４～１０、以下同様。どの特定の組合せが最も費用効果があるかを知るために、全ての組合せを決定及びテストすることができる。プロセスは５０４において、コスト削減の増分の観点で各シナリオを評価するべく評価及び他の計算ルールを適用することで継続する。いくつかの実施例では、プロセス５００は、デバイスのルール、料金プラン・ルール、デバイス制約などの全てに従う。次いでプロセス５００は、最良のシナリオ（例えば最良のコスト削減の増分を伴う変更）を選択する５０６。
【0060】
プロセス５００は変曲点計算を行うこと５０８によって継続される。図５に示すように、プロセスは、料金プランＡから料金プランＢに移動するべきＮ個のデバイスを特定し得る。例えば、いくつかの状況では、Ｎ＋１個又はＮ－１個のデバイスの移動の結果はいずれも、Ｎ個のデバイスの移動よりも小さいコスト削減となり得る。プロセスは先立つアクティビティにおいて特定された変更を実施し５１０、その後５０２に戻り、このプロセスを有意な増分利益が可能でなくなるまで繰り返す。最後に、最良の結果に到達する５１２と、プロセスは結果をログする、料金プラン間のデバイスの移動を記録する、パフォーマンス統計を記録する、などを行う。
【0061】
図６は通知エンジン１２６の実施例を示すブロック図である。図６に示すように、通知エンジン１２６は、通信管理部６０２と、プロセッサ６０４と、メモリ６０６と、を含む。通信管理部６０２は、通知エンジン１２６が他のシステム及び構成要素と通信するのを可能にする。プロセッサ６０４は、本明細書で検討するように、通知エンジン１２６によって提供される機能性を実施するための様々な命令を実行する。メモリ６０６はこれらの命令を、プロセッサ６０４並びに通知エンジン１２６に含まれる他のモジュール及び構成要素によって使用される他のデータと共に保存する。
【0062】
更に、通知エンジン１２６は、電子メール・テンプレート保存部６０８と、タイマ及びスケジューラ・モジュール６１０と、トリガ及びリスナ・モジュール６１２と、を含む。電子メール・テンプレート保存部６０８には、様々な通知を提供するための任意の数の電子メール・テンプレートが含まれている。いくつかの実施例では、保存部６０８中の電子メール・テンプレートは、ユーザによって編集可能である。タイマ及びスケジューラ・モジュール６１０によって、ユーザがカスタム・アラートを作成すること、及びそのアラートに関する特定のスケジュールを選択することが可能になる。いくつかの実施例では、タイマ及びスケジューラ・モジュール６１０は、特定のタイプのアラートに関する事前設定されたタイマを含み得る。トリガ及びリスナ・モジュール６１２は、異常検出、ジョブ障害などを行うことができる。トリガ及びリスナ・モジュール６１２は、必要であれば特定の問題を自動的にエスカレートさせてもよい。いくつかの実施例では、他のシステム又は方法が、問題のエスカレーションを自動的に検出し、適切な通知を生成してもよい。
【0063】
通知エンジン１２６は、メッセージ編集モジュール６１４と、メッセージ送信モジュール６１６と、ユーザ選好６１８と、ポータル管理部６２０と、を更に含む。メッセージ編集モジュール６１４は、検出されたトピックに基づいてメッセージにとって適当なテンプレートを選択し得る。例示のトピックとしては、最適化完了通知、料金プラン変更完了通知、請求サイクル・リマインダ、データ・パイプ・ジョブ失敗通知、データ・パイプ・ジョブ完了通知、ビジネス・プロセス自動化（ＢＰＡ：ｂｕｓｉｎｅｓｓ ｐｒｏｃｅｓｓ ａｕｔｏｍａｔｉｏｎ）実行失敗通知、ＢＰＡ実行完了通知、バルクＡＰＩ実行失敗通知、バルクＡＰＩ実行完了通知、利用可能報告通知などを挙げることができる。例示のデータ変更トピックとしては、新料金プラン通知、料金プラン変更通知、データ品質及び完全性チェック通知、新ユーザ通知などを挙げることができる。メッセージ編集モジュール６１４はまた、ユーザが、使用規約、状態変化、及び他の基準に基づいてカスタム・アラートを定義し、その後アラート通知用のタイマを設定することも可能にし得る。
【0064】
メッセージ送信モジュール６１６は、メッセージを電子メール、ＳＭＳなどの様々なフォーマットで送信することができる。ユーザ選好６１８はユーザによって、例えば、電子メールのみ、テキストのみ、電子メール及びテキスト、全通知停止、１日の割り当てに対する制限通知、などを含むように設定され得る。ポータル管理部６２０は、関心のある通知を選択すること、主題に応じて通知タイプごとに分配リストを追加すること、などといった、様々な機能を実施し得る。
【0065】
いくつかの実施例では、通知は、１つ又は複数のルール、設定などによってトリガされ得る。例えば、デバイスの使用量が閾値を上回ったときにルールがトリガされる場合、通知エンジン１２６は、過剰なデバイス使用量の通知を自動的に生成し、その通知を任意の数のシステム、デバイス、ユーザなどに、任意のフォーマットで通信し得る。
【0066】
図７は、通知を生成及び通信するためのプロセス７００の実施例を示すフロー図である。最初に、プロセスはメッセージ要求を受信する７０２。いくつかの実装形態では、１つ又は複数のメッセージ要求を作成するために、ユーザが定めたスケジュールで特定のプロセスが実施され得る。
【0067】
いくつかの実施例では、受信された要求を、以下の方法のうちの１つでログするか又は待ち行列に入れることができる。
【0068】
１．タイマ・ベース（非同期）：タイマ・ベース（例えば、請求サイクル・リマインダ）のトピックの場合、通知エンジン自体が要求のロギングを開始し得る。
【0069】
２．プロセス・ベース（同期）：この状況では、動作（例えば、最適化又は料金プラン変更バルクＡＰＩ）自体が成功した完了又は失敗についての要求をログする。
【0070】
プロセス７００はメッセージ要求を実行する７０４。いくつかの実施例では、メッセージ・コンパイラによって、トピックに関連する電子メール／ＳＭＳテンプレートを使用して電子メール又はＳＭＳメッセージを作成することができ、テンプレートを完成させるために必要なデータが取得される。いくつかの実施例では、メッセージのコンテンツ、サブジェクト行、及び受信者リストを作成するために、カスタマイズされたクエリが実行され得る。プロセス７００はメッセージ・スロットルを実施してもよい。いくつかの実装形態では、プロセス７００は、新しいメッセージに関するアラート又はクエリと関連付けられた受信者を使用してもよい。ある状況では、ユーザの役割に基づいて受信者のリストが決定され得る。
【0071】
プロセスは次いで、実行されたメッセージ要求に基づいて、１つ又は複数のメッセージを送信する７０６。いくつかの実施例では、作成された電子メール又はＳＭＳメッセージ（又は両方）が、メッセージ送信部によって送信される。次いでプロセス７００は、ポータルにおける１つ又は複数のメッセージ・テーブルを同期させて７０８、それらを通知ペイン又はウィンドウ内に示すことができるようにする。いくつかの実施例では、サービスによって、通知データベースを、ポータルにおいて示されているものと同期させることができる。最後にプロセス７００は、報告ファイルをポータル管理部にアップロードする７１０。更に、いくつかの実施例では、デバイスが影響を受けている場合、ユーザにリストを提供することをトピックが要求する場合がある。この状況では、通知エンジンによって、必要なクエリを実行し、Ｅｘｃｅｌ／ＣＳＶファイルを作成し、それをクラウド・レポジトリ又は他のデータ・ストレージ・システムにセーブすることができる。この情報はポータルを介してユーザが利用可能である。
【0072】
いくつかの実施例では、複数の異なるキャリアを介してメッセージ及び通知を受信することができる。更に、メッセージ及び通知を複数のキャリアにわたって送信することができる。この場合、図７に関して検討したメッセージ・テーブル及びポータルは、複数のキャリア、（任意のキャリアの）複数のデバイスなどからの、任意のメッセージ及び通知に対処できる。
【0073】
図８は、様々なタイプの通知を生成するためのプロセス８００の実施例を示すフロー図である。図８に示すように、プロセス８００は、少なくとも３つの異なるタイプの最適化アラートを生成し得る：１）近付いている請求書サイクルについてのリマインダ、２）最適化完了に関する通知、及び３）バルクＡＰＩ（例えば料金プラン変更）の完了を示す通知。他の実施例では、任意の数のユーザ又はシステムに、任意のタイプの最適化アラートが生成及び通信され得る。
【0074】
図９は、通知設定を選択及び構成する例示の実施例９００を示す。図９に示すように、ポータルのユーザ又はポータルと関連付けられたシステムは、関心のあるトピックを選択し、通知の分配リストを割り当てることができる。送られたのが電子メールであるかＳＭＳメッセージであるかに関わらず、最近の全ての通知を、通知ペイン（例えばウィンドウ）に表示することができる。通知ペインはまた、使用量アラート又は変更追跡アラートなどの特定のアラートに関する電子メール及び／又はＳＭＳメッセージの設定をサポートし得る。
【0075】
図１０は、ＩｏＴデバイスに関連する複数のＡＰＩ要求を処理するためのプロセス１０００の実施例を示すフロー図である。いくつかの実施例では、プロセス１０００は少なくとも部分的に、バルクＡＰＩエンジン１３０によって実施される。バルクＡＰＩエンジン１３０によって実装される特徴及び機能のうちのいくつかとして、以下が挙げられる。
【0076】
要求、応答、接続プロトコルなどに関してキャリア・アグノスティック
【0077】
複数の並列スレッドを実行する
【0078】
単一の及びバルクの要求
【0079】
非同期のフォールト・トレラントな実行
【0080】
複数のビークルを介したリアル・タイム更新／通知
【0081】
リアル・タイム・データ同期
【0082】
顧客及びサード・パーティのアプリケーションとの複数の統合方法をサポート
【0083】
機能性をエンド・ツー・エンドの実際のビジネス・プロセスとしてラップ
【0084】
キャリア固有の認証プロトコルを統合
【0085】
キャリア実装に無関係に全ＡＰＩをＲＥＳＴに変換
【0086】
プロセス１０００を参照すると、プロセスは最初に、ＩｏＴデバイスに関連するデバイス動作を実行するための複数のＡＰＩ要求を受信する１００２。デバイス動作は例えば、デバイスの料金プランの変更、デバイスのサービス・プロバイダの変更、などを含む。プロセスは、モバイル・ネットワーク（キャリア）及びプラットフォームによるＡＰＩ要求をソートすること１００４によって継続される。各ＡＰＩ要求が、スロットリング、同時呼、バッチ・サイズ、待ち時間などといったキャリアＡＰＩルールに基づいて確認される１００６。
【0087】
プロセス１０００は、ＡＰＩ呼の１つ又は複数のバッチを作成すること１００８、及びＡＰＩ呼のバッチの並列実行のための複数のスレッドを作成すること１０１０によって継続される。プロセスは成功しなかった任意のＡＰＩ呼を再試行する１０１２（例えば再実行する）。プロセス１０００は次いで全ての応答を連結し１０１４、ＡＰＩ呼と関連付けられた１つ又は複数のデータ・ビューを更新する。プロセスは要求の状態を表示する１０１６（例えば、バッチ及び個々のＩｏＴデバイス）。最後に方法１０００は、１つ又は複数のシステム、ユーザなどに、要求の結果及び状態の通知を提供する１０１８。
【0088】
図１１Ａは、バルクＡＰＩ処理を行うためのプロセス１１００の例示の実施例を示す。いくつかの実施例では、バルクＡＰＩ処理はサービス型ＡＰＩによって呼び出されるか、又はポータルによって呼び出される。図１１Ｂは、バルクＡＰＩエンジンの様々な特徴１１５０の例示の実施例を示す。
【0089】
図１２には、ビジネス・プロセス自動化のためのプロセス１２００の例示の実施例が図示されている。いくつかの実装形態では、プロセス１２００は、バルクＡＰＩエンジン及び対話型クエリ・エンジンを使用してもよい。
【0090】
図１３Ａは、ＡＰＩカタログの様々な特徴１３００の例示の実施例を示す。いくつかの実装形態では、ＡＰＩカタログは、複数のビジネス・プロセスＡＰＩを含み得る。図１３Ｂには、サービス型ＡＰＩ（ＡＰＩａａＳ）を実施するためのプロセス１３５０の例示の実施例が示されている。いくつかの実装形態では、プロセス１３５０は、バルクＡＰＩエンジンをＡＰＩカタログと統合する。
【0091】
図１４は、最適化エンジンの実装１４００の例示の実施例を示す。
【0092】
【0093】
図１６には、様々な初期化、計算グループ、最適化アルゴリズムのアンサンブル、特定のルール、及び１つ又は複数の最適化アルゴリズムの実行の結果を示す、ルール・ベースの最適化エンジンの例示の実施例１６００が図示されている。
【0094】
【0095】
図１８～図２０には、デバイス管理システムのユーザに様々な情報を提示する、ＧＵＩ１８００、１９００、及び２０００の例示の実施例が図示されている。図１８～図２０に示す例示のＧＵＩには、様々な請求処理データ、使用量データ、デバイス・アクティビティ、平均データ使用量、などが図示されている。例えば、ＧＵＩ１８００は、複数のキャリア、複数のプラットフォーム、複数のデバイスなどから集約され得る様々なデータを有する、ダッシュボード・フォーマットを示す。図１９の実例では、ＧＵＩ１９００にはデータのデバイス・レベルのスナップショットが図示されている。例えば、ＧＵＩ１９００は、ユーザが自らのデバイスの全てを複数のキャリア又はデータ・プラットフォームにわたって確認するのを可能にし得る。ＧＵＩ２０００の実例では、ユーザは、自分自身の下流の顧客階層、又は社内部署／部門階層を作成することができる。いくつかの実施例では、顧客／部署／部門にわたってデータが集約され、ユーザは集約された全てのデータ又はデータの特定のグループを閲覧できるようになっている。いくつかの実装形態では、ＧＵＩ２０００は、ユーザがより粒度の高いデータを求めて特定のＩｏＴデバイスをドリル・ダウンするのを可能にする。いくつかの実施例では、１つ又は多数のキャリアにわたって、及び１つ又は多数の顧客／部署／部門にわたって、クエリが構築され得る。
【0096】
図２１には、１つ又は複数のクエリを構築するために使用され得るＧＵＩ２１００の例示の実施例が図示されている。いくつかの実装形態では、ＧＵＩ２１００はクエリのドラッグ・アンド・ドロップ構築をサポートし、１つ又は複数のクエリの結果を表示するための複数のオプションを提供し得る。
【0097】
図２２は、複数のポッドを包含した最適化アンサンブル２２００の例示の実施例を示す。いくつかの実装形態では、最適化アンサンブル２２００は、複数のデバイスについて最善の（例えば最低コストの）料金プランをまとめて予測できる、複数の互いに排他的な最適化エンジンを含む。最適化アンサンブル２２００はまた、様々なステップを実行する、エラー・シナリオに対処する、パフォーマンス統計をマイニングする、及びプラン変更マニフェストを作成するための、一般化されたオーケストレーション・モジュールも含み得る。プラン変更マニフェストは、キャリアに対して料金プラン変更を実際に実施するために、バルクＡＰＩエンジンによって使用され得る。最適化アンサンブル２２００の動作に関する追加の詳細が、本明細書で、例えば図４Ａ、図４Ｂ、及び図５に関して検討されている。
【0098】
対話型クエリ・ビルダ
技術革新及び新しい体験を求める消費者需要によってビジネス・モデルの見直しが進んでいる－競争の熾烈な消費者環境に遅れず着いて行くための手段として、ＩｏＴ戦略とスケーリングされた複雑な配備とが推進されている。従来のＩＴの意味においては、そのような配備によって、接続性のフレキシブルでセキュアで効率的な基盤、標準化されたデバイス及びデータ管理、並びに自動化されたプロセスが提供されることが重要である。しかしながらＩｏＴ配備の多くは、従来のビジネスＩＴ又はネットワーク配備以上のものである。それらによって、膨大で多様な断片化したデータの単なる取り込みではない、リアル・タイムのインテリジェントな洞察が要求されるビジネス・モデルの見直しが進んでいる。対話型クエリ・ビルダはビジネス・オーナーを念頭において構築され、その非常に複雑で途切れることのないビジネス・バリューの追及において、ビジネス・オーナーとＩＴパートナーを、営業に即した業績ベースの配備のビューで結び付け直す。対話型クエリ・ビルダは当日の実行及び成果を告知し、また翌日の展開（ｔｒａｊｅｃｔｏｒｙ）の定義も行う。
技術革新及び新しい体験を求める消費者需要によってビジネス・モデルの見直しが進んでいる－競争の熾烈な消費者環境に遅れず着いて行くための手段として、ＩｏＴ戦略とスケーリングされた複雑な配備とが推進されている。従来のＩＴの意味においては、そのような配備によって、接続性のフレキシブルでセキュアで効率的な基盤、標準化されたデバイス及びデータ管理、並びに自動化されたプロセスが提供されることが重要である。しかしながらＩｏＴ配備の多くは、従来のビジネスＩＴ又はネットワーク配備以上のものである。それらによって、膨大で多様な断片化したデータの単なる取り込みではない、リアル・タイムのインテリジェントな洞察が要求されるビジネス・モデルの見直しが進んでいる。対話型クエリ・ビルダはビジネス・オーナーを念頭において構築され、その非常に複雑で途切れることのないビジネス・バリューの追及において、ビジネス・オーナーとＩＴパートナーを、営業に即した業績ベースの配備のビューで結び付け直す。対話型クエリ・ビルダは当日の実行及び成果を告知し、また翌日の展開（ｔｒａｊｅｃｔｏｒｙ）の定義も行う。
【0099】
サード・パーティ／企業業務参照データ、統計的プロファイリング、及びＡＩ／ＭＬを、補強され標準化された相関するデータセットに組み込むことによって、データは、対話型クエリ・ビルダを介して非技術系ビジネスの戦略家が直接利用できるような、情報及び洞察に翻訳される。以下は、補強されたデータがどのようにリアル・タイムの判定処理を促すかのいくつかの実例である。
【0100】
産業ＩｏＴによって工場の操業の改善が進んでいる。ストリーミング・データをリアル・タイムで使用することによって、接続された工場を有する製造者は、状況の変化により速く対応し、自らの操業をピーク処理能力に合わせて調整し、工場投資から得られる価値を最大化することができる。例えば、工業用油産業では、データを収集するためにＩｏＴセンサ及びトランスデューサが配備される。セルラ・サービスを利用することによって、これらのデバイスをゲートウェイに接続することができ、次いでゲートウェイからクラウドへとデータが送信される。記載されているシステム及び方法は、キャリア又は接続性プラットフォームからＡＰＩを介して直接、キャリア、料金プラン、消費傾向及び異常報告、料金プラン、コスト、及び最適化評価を含むがこれらに限定されない、各デバイスからのデータ消費情報を取得することができ、このときデバイスのライフサイクル履歴の記録及び保持も行う。
【0101】
いくつかの実施例では、デバイスは、施設、地理的条件、及び業務別部門、並びに／又は、ＩｏＴアプリケーションの測定、報告、及び通知を含むアクティビティといった属性についての、エンド・ユーザによる定義に従って区分され得る。
【0102】
例えば、本明細書に記載するシステム及び方法は、事業体が種類の異なるデータを１）接続性、２）デバイス、及び３）デバイス・アプリケーションに関して横断的に相関させることを可能にして、ビジネス戦略及び技術配備に関して横断的なより全体的な戦略を推し進めるための、企業の機能及び意向を超越した１つの全体的な筋書きを作成することができる。
【0103】
自動車及び技術などいくつかの産業の会社で、新世代のスマート・コネクテッド・カーの構築が進められている。会社は車の運転をより安全にしているだけでなく、顧客体験の向上、製品開発及び製造工程の改善、並びに業績の拡大のために、車両からのデータに対する直接のアクセス及び分析も行っている。
【0104】
いくつかの状況では、小売業界は、デジタル手段及び物理的手段の両方を介した、利便性、応答性、及びパーソナライゼーションについての顧客の期待に基づいて見直されてきた。複数のタッチ・ポイントにわたる顧客データの収集、統一、及び管理は複雑であるが、ＩｏＴからのイン・ストア・データをデジタル顧客データと組み合わせることには、ショッピング体験のパーソナライゼーションの追及において価値がある。
【0105】
本明細書で検討する対話型クエリ・ビルダは、（非技術系ビジネスのユーザを含む）ユーザが、様々なデータセットと対話型の様式で対話して、関心のあるデータの場所を特定し、そこに注目することを可能にするインターフェースを提供する。対話型クエリ・ビルダを使用する場合、ユーザに要求されるインターフェースの使用方法を基礎とする訓練は最小限である。
【0106】
いくつかの実施例では、対話型クエリ・ビルダは、選択された列にとって意味のある入力制御を行いながら、属性、ファクト、及び測定の列を、直観的なＧＵＩでユーザに提示する。クエリ・カタログに対する実際のクエリは、コンテキストに動的に依存して、コードを用いない完全に構成ベースのルールの保存を活用することによって生成される。いくつかの実施例では、クエリ・カタログは、キャリアのデータセット、ユーザが作成した追加の属性、及びサード・パーティのデータセットを組み合わせた、キュレーションされ補強されたデータセットである。クエリ・カタログはまた、非技術系ビジネスのユーザが直観的な高品質の対話を行えるように調整され得る。
【0107】
いくつかの実例では、１つ又は複数のキャリアから様々なタイプの未加工データが受信される。この未加工データは、ＳＩＭ目録、デバイス情報、使用量情報、変更履歴、アカウント情報などを含み得る。未加工データからキュレーションされたデータが作成され、このデータが、ユーザが作成したカスタムのタグ及びグループに基づいて補強され、サード・パーティのデータ（例えば、製造者、ハードウェア、ネットワーク、オペレーティング・システム、プログラム可能性、地理位置などに関連するデータ）に基づいて更に補強される。
【0108】
対話型クエリ・ビルダに、対話型クエリ・ビルダが１つ又は複数のユーザ・クエリへの応答を生成することを可能にする、１つ又は複数のクエリ・カタログが提供される。いくつかの実施例では、生成された応答は、本明細書で検討するような報告エンジン及び／又は通知エンジンに提供される。
【0109】
いくつかの実施例では、対話型クエリ・ビルダはまた、複数のバケット、すなわちデバイス情報、ライフ・サイクル履歴、及び使用量データを包含する、補強され標準化された相関するデータセットも含む。デバイス情報はＩｏＴ又は電話デバイスを記述するあらゆるものを含むが、ライフ・サイクル履歴、接続性、及び使用量情報を例外とする。対話型クエリ・ビルダは、キャリアのデータ・プラットフォームから受信した基本情報を、ユーザがポータル又はＡＰＩを使用して提供する追加の情報と、デバイス・タイプ、ハードウェア、ネットワーキング、及びソフトウェアの仕様に関連するサード・パーティのデータと、マーケティング用語とで増強する。システム及び方法はまた、この情報の標準的な高品質の統計的プロファイリングを実行し、このことによりシステム及び方法が、デバイス・プロファイルに追加の属性として推論を加えることが可能になる。
【0110】
ライフ・サイクル履歴は、キャリアによって追跡されない動作及びイベントと関連付けられたデータを含む。記載されているシステム及び方法は、キャリアからデータが発生するたびに、動作及びイベントを記録する。このことは、最近キャリアから発生したデータを既に取得済みのデータと比較することによって達成される。いくつかの実施例では、変化をより速く捕捉でき、それらがより小さい時間窓と関連付けられるときにより精確となるように、データ取り込みは連続的である。更にユーザは、キャリアによってサポートされていない追加の動作、例えば、下流側の顧客、地理別の部署、及び業務別の部門への、デバイスのポートフォリオの分配を行うことができる。ユーザはまた、デバイスのグループをウォッチ・リスト及びセグメントに追加することもできる。ユーザがこれらの追加の特性のいずれかを変更した場合、記載されているシステム及び方法はそれらの変更を、いかなる追加のコードも必要とせずに、スイッチを介して追跡することができる。この結果ユーザは、対話型クエリ・ビルダを使用することによって、デバイスのライフ・サイクル、及びその存続過程において実行される追加の動作について、完全な可視性を得ることができる。
【0111】
いくつかの実施例では、追跡されるライフ・サイクル・イベントは以下を含み得る。
【0112】
－ＳＩＭチップの配備（例えば、目録から使用可能状態への移動）
【0113】
－起動、耐用年数経過（ＥＯＬ：ｅｎｄ－ｏｆ－ｌｉｆｅ）、及びＥＯＬによらない停止
【0114】
－実際の物理的デバイスからの取り外し、及び物理的デバイスへの取り付け
【0115】
－物理的デバイスと関連付けられた電話番号の変更
【0116】
－ある請求処理アカウントから別の請求処理アカウントへのＳＩＭカードの移動
【0117】
－ある最終顧客から別の最終顧客へのＳＩＭカードの移動
【0118】
－あるキャリアから別のキャリアへのＳＩＭカードの移動
【0119】
－ＳＩＭカード又は電話番号と関連付けられた料金プラン又はサービスＳＫＵの変更
【0120】
－本明細書に記載するシステム及び方法を基本とする属性の変更
【0121】
－統計的プロファイリングに基づく属性の変更
【0122】
－運用の主たる場所（例えば、地理上、ネットワーク、等）の変更
【0123】
本明細書で使用する場合、「使用量」は、広くキャリアによって提供されるサービスの消費量を指す。使用量データは、データ、ＳＭＳテキスト、音声、及びビデオを含み得る。使用量データは典型的には、キャリアによってＳＩＭカード／電話回線ごとに、月次集計、日次集計、又はセッション・レベル・データ（ＣＤＲ：ｓｅｓｓｉｏｎ－ｌｅｖｅｌ ｄａｔａ）として提供される。
【0124】
いくつかの実施例では、月次集計は、キャリアの仲介及び評価プロセスを経た請求対象記録である。日次の集計及びセッション・データには、未仲介及び未評価の呼が含まれ得る。
【0125】
いくつかのキャリアでは、日次又は月次のフィードに関して一貫していないものの、追加のスライスが利用可能とされる。これら追加のスライスは、例えば、使用の地理位置（例えば、国、国－地域、ネットワーク区域、等）、及び方向（例えば、発生／発出、終了／入来、等）、及び場合によってはネットワーク自体に関するより精密な粒度の情報（例えば、塔の場所、サーバＩＰなど）を含む。
【0126】
記載されているシステム及び方法はまた、どのデータ・フィードを使用すべきかを決定するための精緻化されたユース・ケースも含み得る。例えば、日次フィードとして与えられる事前に仲介され事前に評価された情報を使用すること、及び予測技術を追加することで、この情報によって、将来の不測の事態を避けるために、ユーザが請求書サイクルの早期に料金プラン最適化を実行することが可能になる。この手法はまた財務予算管理及び在庫計画においても有用である。
【0127】
本明細書に記載するシステム及び方法はまた、安価な汎用のストレージと、何百万という記録の迅速な取り込み及び処理を支援するクラウドでの処理能力とを使用して実施される、データ・パイプも含み得る。この手法は、データ要求に応答するキャリアの能力によってのみ制限される。ＣＤＲの場合、システム及び方法が呼セッションごとにデータを受信し、システム及び方法は、通常であれば未加工の日次及び月次フィードからは失われているデータのスライス（例えば、地理位置、方向性など）に関して、日次及び月次集計を再構築することができる。
【0128】
本明細書に記載するシステム及び方法によって生成及び使用されるデータセットは、データセットが、キャリア、データ・プラットフォーム、音声対ＩｏＴ、サービスのタイプ（例えば、データ、音声、テキスト、ビデオなど）、発生対終了、有料対無料、及び他の多くの次元及び特性に対して、アグノスティックとなるように標準化されている。このデータセットの標準化によって、対話型クエリ・ビルダと関連付けられこれによって実装される様々な特徴及びアクティビティがサポートされる。これらの特徴によって、単一のスクリーン上への情報の迅速な表示を実現する、単純化されたＵＩ及びＧＵＩが提供される。ＩｏＴデバイスと電話機との間の境界がより不明確になるにつれ、並びにｅＳＩＭ及び５Ｇネットワークの出現に伴い、対話型クエリ・ビルダによって提供される特徴は、エンド・ユーザにとってより有用且つより価値あるものになる。
【0129】
いくつかの実施例では、データセット標準化は、顧客が任意の数のキャリア又は他のサービス・プロバイダと交わした全てのサービス契約にわたって、データを集約することを含む。例えば、ある顧客が、Ｖｅｒｉｚｏｎで３つのアカウントを、及びＡＴ＆Ｔでもう１つのアカウントを持っている場合がある。従来のシステム及び方法を用いて、４つの異なるアカウントからデータを閲覧する、何らかのデバイス管理アクションを行う、又は概略的分析を作成するためには、顧客は、Ｖｅｒｉｚｏｎの各アカウント及びＡＴ＆Ｔの１つのアカウントに別々にログインし、必要なデータを引き出し、データの照合及び標準化を行って初めて、財務、運用、又は他の部門に関して、何らかの概略的な報告又は分析を行うことが可能になるであろう。本明細書に記載するシステム及び方法は、改善されたより効率的な手法を提供する。これらのシステム及び方法では、システム統合、キャリアが新しい特徴をリリースした際のこれらの統合の維持、並びにそれに続く避けられない人員の再訓練及び離職に関連するコストの、かなりの部分が節約される。
【0130】
通知エンジン
ＩｏＴの採用には通常、不正検出、ネットワーク・モニタリング、ｅコマース及びリスク管理、ネットワーク・セキュリティ等の膨大なパラメータの中で、異常なアクティビティを継続的に評価するために、リアル・タイム又は準リアル・タイムのデータ及び処理が要求される。
ＩｏＴの採用には通常、不正検出、ネットワーク・モニタリング、ｅコマース及びリスク管理、ネットワーク・セキュリティ等の膨大なパラメータの中で、異常なアクティビティを継続的に評価するために、リアル・タイム又は準リアル・タイムのデータ及び処理が要求される。
【0131】
本明細書で検討する統計的プロファイリングを用いて、対話型クエリ・ビルダは、及びエンド・ユーザが設定した確立された業務ルールと組み合わせて、データ構造は、データ上で事前に定義された式を実行し、同時に洗練された処理技術を使用してデータ・パターンを継続的に探索する。
【0132】
通知及び報告は最も単純な分析形態である－その主目的は、複雑なデータを洞察に富んだ情報の有用な要約に変換することによって、エンド・ユーザに関連する「イベント」をリアル・タイムで提示することである。
【0133】
通知及び報告は、デバイス・シナリオをモニタすること、アプリケーション・ワークフローを作成すること、及び電子メール又はテキスト・アラートを介してワークフローを実施することによって、ＩｏＴ配備に対するリアル・タイムの気付きを促すことができる。
【0134】
いくつかの実例では、産業用ＩｏＴの実装形態は、アプリケーションの不具合を特定するＩｏＴセンサ・アプリケーションを含み得る。同時に、本明細書に記載するシステム及び方法は、そのセルラ・キャリアＡＰＩを介した事前に定義されたライフサイクル通知トリガを介して、デバイス状態の「停止」への変更を識別する。記載されているシステム及び方法は、セルラ接続機能性に再接続するためにＳＩＭ状態を「起動」し得る。エンド・ユーザのＩｏＴセンサ・アプリケーションは、通常の機能をリセット及び再開し得る。この実例には、１）デバイス・センサ・アプリケーション、及び２）セルラ接続機能性を介して特定された、リアル・タイムのデバイス「インシデント」が反映されている。いくつかの実施例では、人との対話を行わずに、接続性トラブルシューティングによって根本原因を特定し、セルラ・サービスを再接続し、デバイスをオン・ラインに復帰させた。
【0135】
追加の用途としては、事前に構成されたトリガ及び頻出する異常に関するリアル・タイム使用量解析が挙げられる。更なる用途としては、コストを最適化しサービス・レベルを評価するための、リアル・タイム又は準リアル・タイムのデバイス使用量についての接続性サービス・プランの作成及び管理を挙げることができる。
【0136】
いくつかの実施例では、通知エンジンは、本明細書で検討するデータセット及び対話型クエリ・ビルダを基礎として構築される。通知エンジンは、自動化されたデバイス・ライフサイクル管理を提供するシステム及び方法の、重要な部分である。ユーザが異常動作しているデバイスを特定するためのカスタム・アラートを作成する場合、ユーザには、異常動作の通知を受けること、又は、通知を受け自動化されたデバイス管理アクションをトリガすることの、２つのオプションがある。例えば、国内用途用にプロビジョニングされたデバイスが国際ローミング・データに対して突如課金を開始する場合、ユーザは、請求を防ぐことができるように、ユーザによるその事態の調査の間のデバイスの停止を自動化することができる。いくつかの実施例では、これらの異常動作しているデバイスは統計的異常検出を使用して特定されるが、このことは様々なビジネス・プロセスの自動化を促進する継続的なデータ処理システム及び方法の一部であり得る。
【0137】
アド・ホック報告エンジン
いくつかの実施例では、本明細書で検討する標準化されたデータセット及び対話型クエリ・ビルダを基礎として、アド・ホック報告エンジン（「報告エンジン」とも呼ばれる）が構築される。ユーザはデータセットと対話し、結果を（例えばＥｘｃｅｌスプレッドシート・フォーマットで）対話式に閲覧及び／又はダウンロードして、より深く分析することができる。いくつかの実施例では、ユーザは、ユーザだけがアクセスできるセキュアなＦＴＰロケーションに報告が送達されるように選択することができる。このことはデータセット（例えばデータ結果）が大きいときに特に有用である。この特徴によって、キャリア及びユーザが報告インフラストラクチャに費やす時間及び金銭を、実質的に減らすことができる。
いくつかの実施例では、本明細書で検討する標準化されたデータセット及び対話型クエリ・ビルダを基礎として、アド・ホック報告エンジン（「報告エンジン」とも呼ばれる）が構築される。ユーザはデータセットと対話し、結果を（例えばＥｘｃｅｌスプレッドシート・フォーマットで）対話式に閲覧及び／又はダウンロードして、より深く分析することができる。いくつかの実施例では、ユーザは、ユーザだけがアクセスできるセキュアなＦＴＰロケーションに報告が送達されるように選択することができる。このことはデータセット（例えばデータ結果）が大きいときに特に有用である。この特徴によって、キャリア及びユーザが報告インフラストラクチャに費やす時間及び金銭を、実質的に減らすことができる。
【0138】
図２３には、本明細書に記載するシステム及び方法を実施するのに適したコンピューティング・デバイス２３００の例示のブロック図が図示されている。いくつかの実施例では、本明細書で検討するシステムの任意の１つ又は複数の構成要素を実装するために、ネットワークによって相互接続されたコンピューティング・デバイスのクラスターが使用され得る。
【0139】
コンピューティング・デバイス２３００は、本明細書で検討した手順などの、様々な手順を行うように使用され得る。コンピューティング・デバイス２３００は、サーバ、クライアント、又は任意の他のコンピューティング・エンティティとして機能し得る。コンピューティング・デバイスは本明細書で検討するような様々な機能を実施することができ、本明細書に記載するアプリケーション・プログラムなどの１つ又は複数のアプリケーション・プログラムを実行することができる。コンピューティング・デバイス２３００は、デスクトップ・コンピュータ、ノートブック・コンピュータ、サーバ・コンピュータ、ハンドヘルド・コンピュータ、タブレット・コンピュータなどの多種多様なコンピューティング・デバイスのうちの任意のものであり得る。
【0140】
コンピューティング・デバイス２３００は、１つ又は複数のプロセッサ２３０２と、１つ又は複数のメモリ・デバイス２３０４と、１つ又は複数のインターフェース２３０６と、１つ又は複数のマス・ストレージ・デバイス２３０８と、１つ又は複数の入力／出力（Ｉ／Ｏ：Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）デバイス２３１０と、ディスプレイ・デバイス２３３０と、を含み、これらは全てバス２３１２に結合される。プロセッサ２３０２は、メモリ・デバイス２３０４及び／又はマス・ストレージ・デバイス２３０８に保存されている命令を実行する、１つ又は複数のプロセッサ又は制御装置を含む。プロセッサ２３０２はまた、様々なタイプのコンピュータ可読媒体、例えばキャッシュ・メモリも含み得る。
【0141】
メモリ・デバイス２３０４は、揮発性メモリ（例えばランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）２３１４）及び／又は不揮発性メモリ（例えば読み出し専用メモリ（ＲＯＭ：ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）２３１６）などの、様々なコンピュータ可読媒体を含む。メモリ・デバイス２３０４はまた、フラッシュ・メモリなどの書き換え可能ＲＯＭも含み得る。
【0142】
マス・ストレージ・デバイス２３０８は、磁気テープ、磁気ディスク、光学ディスク、ソリッド・ステート・メモリ（例えば、フラッシュ・メモリ）などといった、様々なコンピュータ可読媒体を含む。図２３に示すように、特定のマス・ストレージ・デバイスはハード・ディスク・ドライブ２３２４である。マス・ストレージ・デバイス２３０８にはまた、様々なコンピュータ可読媒体に対して読み取り及び／又は書込みを行うことを可能にするための、様々なドライブも含まれ得る。マス・ストレージ・デバイス２３０８は、取り外し可能な媒体２３２６及び／又は取り外し不可能な媒体を含む。
【0143】
Ｉ／Ｏデバイス２３１０は、データ及び／又は他の情報をコンピューティング・デバイス２３００に入力する又はそこから取得することを可能にする、様々なデバイスを含む。例示のＩ／Ｏデバイス２３１０としては、カーソル制御デバイス、キーボード、キーパッド、マイクロフォン、モニタ又は他のディスプレイ・デバイス、スピーカ、プリンタ、ネットワーク・インターフェース・カード、モデム、レンズ、ＣＣＤ又は他の画像取り込みデバイスなどが挙げられる。
【0144】
ディスプレイ・デバイス２３３０は、コンピューティング・デバイス２３００の一人又は複数のユーザに情報を表示できる任意のタイプのデバイスを含む。ディスプレイ・デバイス２３３０の実例としては、モニタ、ディスプレイ端末、ビデオ・プロジェクション・デバイスなどが挙げられる。
【0145】
インターフェース２３０６は、コンピューティング・デバイス２３００が他のシステム、デバイス、又はコンピューティング環境と対話することを可能にする、様々なインターフェースを含む。例示のインターフェース２３０６としては、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ワイド・エリア・ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ワイヤレス・ネットワーク、及びインターネットへのインターフェースなどの、任意の数の異なるネットワーク・インターフェース２３２０が挙げられる。他のインターフェースとしては、ユーザ・インターフェース２３１８及び周辺デバイス・インターフェース２３２２が挙げられる。インターフェース２３０６はまた、１つ又は複数のユーザ・インターフェース要素２３１８も含み得る。インターフェース２３０６はまた、プリンタ、ポインティング・デバイス（マウス、トラック・パッド、等）、キーボードなどのためのインターフェースなどの、１つ又は複数の周辺インターフェースも含み得る。
【0146】
バス２３１２は、プロセッサ２３０２、メモリ・デバイス２３０４、インターフェース２３０６、マス・ストレージ・デバイス２３０８、及びＩ／Ｏデバイス２３１０が互いに、及びバス２３１２に結合されている他のデバイス又は構成要素と、通信するのを可能にする。バス２３１２は、システム・バス、ＰＣＩバス、ＩＥＥＥ１３９４バス、ＵＳＢバスなどといったいくつかのタイプのバス構造のうちの、１つ又は複数を表す。
【0147】
例示の目的で、本明細書ではプログラム及び他の実行可能なプログラム構成要素が個別のブロックとして示されているが、そのようなプログラム及び構成要素は、コンピューティング・デバイス２３００の異なるストレージ構成要素内に様々な時間において存在してもよく、プロセッサ２３０２によって実行されることが、理解される。別法として、本明細書に記載するシステム及び手順は、ハードウェア、又はハードウェア、ソフトウェア、及び／若しくはファームウェアの組合せにおいて実装され得る。例えば、１つ又は複数の特定用途向け集積回路（ＡＳＩＣ）を、本明細書に記載するシステム及び手順のうちの１つ又は複数を実行するようにプログラムすることができる。
【0148】
本明細書には本開示の様々な実施例が記載されているが、それらは限定ではなく単なる例として提示されていることが理解されるべきである。それらの実施例において、本開示の精神及び範囲から逸脱することなく形態及び詳細の様々な変更を行うことのできることが、当業者には明らかであろう。したがって、本開示の広さ及び範囲は記載されている例示的な実施例のいずれによっても限定されるものではなく、以下の請求項及びそれらの等価物にのみ従って規定されるものである。本明細書の説明は例示及び説明の目的で提示されている。網羅的であること又は本開示を開示されている厳密な形態に限定することは意図していない。開示されている教示に照らして多くの修正及び変更が可能である。更に、本開示の混成された追加の実装形態を形成するために、本明細書で検討する代替の実装形態のいずれか又は全てを、任意の所望の組合せで使用してもよいことに留意すべきである。
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11A】
【図11B】
【図12】
【図13A】
【図13B】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【国際調査報告】