(57)【要約】ニュートラルなアプリケーションプログラミングインタフェースに関するシステム及び方法が開示される。一実施形態では、本開示はニュートラルなアプリケーションプログラミングインタフェースに関する。システムはデバイスを含んでよい。デバイスはリクエストを受信するよう構成されてよい。リクエストは外部ペイロード及び内部ペイロードを含んでよい。デバイスは更に、外部ペイロードの共通定義に基づいて外部ペイロードをパースするよう構成されてよい。デバイスは更に、外部ペイロードから、アクションの情報を抽出するよう構成されてよい。デバイスは更に、アクションの定義に基づいて、内部ペイロードをパースするよう構成されてよい。デバイスは更に、アクションを処理するよう構成されてよい。
2018508067.tif 000002
【特許請求の範囲】
【請求項１】
ニュートラルなアプリケーションプログラミングインタフェースのためのシステムにおいて、
デバイスを含み、
当該デバイスは、
外部ペイロードと内部ペイロードとを含むリクエストを受信し、
前記外部ペイロードの共通定義に基づいて前記外部ペイロードをパースし、
前記外部ペイロードからアクションの情報を抽出し、
前記アクションの定義に基づいて前記内部ペイロードをパースし、
前記アクションを処理する、
システム。
【請求項２】
請求項１に記載のシステムにおいて、
前記リクエストが生成されるとき、前記外部ペイロードは時間のタイムスタンプを含む、
システム。
【請求項３】
請求項２に記載のシステムにおいて、
前記内部ペイロードは暗号化され、前記デバイスは更に前記内部ペイロードを復号化するよう構成される、
システム。
【請求項４】
請求項２に記載のシステムにおいて、
前記デバイスが前記リクエストを受信するときと前記タイムスタンプとの間の時間経過が閾値を超えるとき、前記デバイスは前記アクションを処理しないよう構成される、
システム。
【請求項５】
請求項４に記載のシステムにおいて、
前記閾値はネットワークの待ち時間に基づく、
システム。
【請求項６】
請求項４に記載のシステムにおいて、
前記閾値は１秒と等しい、
システム。
【請求項７】
請求項３に記載のシステムにおいて、
前記内部ペイロードの前記暗号化は、前記タイムスタンプ及び前記アクションに基づく、
システム。
【請求項８】
請求項７に記載のシステムにおいて、
前記内部ペイロードの前記暗号化は更に、前記リクエストを発する発信デバイス及び前記デバイスに基づく、
システム。
【請求項９】
請求項１に記載のシステムにおいて、
前記リクエストは、セキュアソケットレイヤを介して送信される、
システム。
【請求項１０】
請求項１に記載のシステムにおいて、
前記内部ペイロードは、アレイ、キーと値とのペア、オブジェクト、データファイル、又はバイナリファイルの少なくとも１つを含む、
システム。
【請求項１１】
請求項１に記載のシステムにおいて、
前記デバイスは更に、スクリプトを用いて前記アクションを処理するよう構成される、
システム。
【請求項１２】
請求項１１に記載のシステムにおいて、
前記デバイスは更に、サーバから前記アクションを検索するよう構成される、
システム。
【請求項１３】
請求項１２に記載のシステムにおいて、
前記サーバは、アクションについての情報を格納し、デバイスについての情報を格納するように構成される、
システム。
【請求項１４】
請求項１３に記載のシステムにおいて、
前記サーバは更に、発信デバイス及び宛先デバイスのピア関係を格納するよう構成される、
システム。
【請求項１５】
請求項１３に記載のシステムにおいて、
前記サーバは更に、アクションを更新するよう構成される、
システム。
【請求項１６】
請求項１４に記載のシステムにおいて、
前記デバイスは更に、そのピアの発信デバイスのリストをサーバから検索し、そのピアの発信デバイスの前記リスト上のデバイスからのリクエストをリスニングする、
システム。
【請求項１７】
請求項１３に記載のシステムにおいて、
前記サーバは更に、アクションを前記デバイスにプッシュするよう構成される、
システム。
【請求項１８】
請求項１３に記載のシステムにおいて、
前記サーバは更に、アクションをフラグして可用性を示すよう構成される、
システム。
【請求項１９】
請求項１に記載のシステムにおいて、
前記デバイスは更に、前記リクエストのレスポンスを送信するよう構成される、
システム。
【請求項２０】
請求項１９に記載のシステムにおいて、
前記デバイスは更に前記レスポンスにおいて、前記リクエストの一部を含むよう構成される、
システム。
【請求項２１】
ニュートラルなアプリケーションプログラミングインタフェースのための方法において、
外部ペイロードと内部ペイロードとを含むリクエストを受信するステップと、
前記外部ペイロードの共通定義に基づいて前記外部ペイロードをパースするステップと、
前記外部ペイロードからアクションの情報を抽出するステップと、
前記アクションの定義に基づいて前記内部ペイロードをパースするステップと、
前記アクションを処理するステップと、
を有する方法。
【請求項２２】
請求項２１に記載の方法において、
前記リクエストが生成されるとき、前記外部ペイロードは時間のタイムスタンプを含む、
方法。
【請求項２３】
請求項２２に記載の方法において、
前記内部ペイロードは暗号化され、前記方法は更に前記内部ペイロードを復号化するステップを含む、
方法。
【請求項２４】
請求項２２に記載の方法において、
前記デバイスが前記リクエストを受信する時間と前記タイムスタンプとの間の時間経過が閾値を超えるとき、前記デバイスは前記アクションを処理しないように構成される、
方法。
【請求項２５】
請求項２４に記載の方法において、
前記閾値はネットワークの待ち時間に基づく、
方法。
【請求項２６】
請求項２４に記載の方法において、
前記閾値は１秒と等しい、
方法。
【請求項２７】
請求項２３に記載の方法において、
前記内部ペイロードの前記暗号化は、前記タイムスタンプ及び前記アクションに基づく、
方法。
【請求項２８】
請求項２７に記載の方法において、
前記内部ペイロードの前記暗号化は更に、前記リクエストを発する発信デバイスと前記リクエストを受信するデバイスとに基づく、
方法。
【請求項２９】
請求項２１に記載の方法において、
前記リクエストは、セキュアソケットレイヤを介して送信される、
方法。
【請求項３０】
請求項２１に記載の方法において、
前記内部ペイロードは、アレイ、キーと値とのペア、オブジェクト、データファイル、又はバイナリファイルの少なくとも１つを含む、
方法。
【請求項３１】
請求項２１に記載の方法において、
スクリプトを用いて前記アクションを処理するステップを更に含む、
方法。
【請求項３２】
請求項２１に記載の方法において、
サーバから前記アクションを検索するステップを更に含む、
方法。
【請求項３３】
請求項２２に記載の方法において、
前記サーバによって、アクションについての情報を格納するステップと、
前記サーバによって、デバイスについての情報を格納するステップとを更に有する、
方法。
【請求項３４】
請求項３３に記載の方法において、
前記サーバによって、発信デバイスと宛先デバイスとのピア関係を格納するステップを更に含む、
方法。
【請求項３５】
請求項３３に記載の方法において、
前記サーバによってアクションを更新するステップを更に含む、
方法。
【請求項３６】
請求項３４に記載の方法において、
ピアの発信デバイスのリストを前記サーバから検索するステップと、
前記ピアの発信デバイスの前記リスト上のデバイスからのリクエストをリスニングするステップと、
を更に含む方法。
【請求項３７】
請求項３３に記載の方法において、
前記サーバによって、アクションをデバイスへプッシュするステップを更に含む、
方法。
【請求項３８】
請求項３３に記載の方法において、
前記サーバによって、アクションをフラグして可用性を示すステップを更に含む、
方法。
【請求項３９】
請求項２１に記載の方法において、
前記リクエストへのレスポンスを送信するステップを更に含む、
方法。
【請求項４０】
請求項３９に記載の方法において、
前記レスポンスにおいて、前記リクエストの一部を含むステップを更に含む、
方法。
【請求項４１】
ニュートラルなアプリケーションプログラミングインタフェースのコンピュータ可読プログラムを格納する非一時的コンピュータ可読媒体において、
外部ペイロードと内部ペイロードとを含むリクエストを受信するコンピュータ可読命令と、
前記外部ペイロードの共通定義に基づいて前記外部ペイロードをパースするコンピュータ可読命令と、
前記外部ペイロードからアクションの情報を抽出するコンピュータ可読命令と、
前記アクションの定義に基づいて前記内部ペイロードをパースするコンピュータ可読命令と、
前記アクションを処理するコンピュータ可読命令と
を含む媒体。
【請求項４２】
請求項１に記載のシステムにおいて、
前記デバイスは更に、処理のために前記アクションをキューイングするよう構成される、
システム。
【請求項４３】
請求項１に記載のシステムにおいて、
前記デバイスは更に、前記リクエストと前記アクションとのログをとるよう構成される、
システム。
【請求項４４】
請求項２１に記載の方法において、
処理のために前記アクションをキューイングするステップを更に含む、
方法。
【請求項４５】
請求項２１に記載の方法において、
前記リクエストと前記アクションとをロギングするステップを更に含む、
方法。
【請求項４６】
ニュートラルなアプリケーションプログラミングインタフェースのためのシステムにおいて、
デバイスを含み、
当該デバイスは、
アクションを含む内部ペイロードを、前記アクションの定義に基づいて生成し、
外部ペイロードを、当該外部ペイロードの共通定義に基づいて生成し、
前記外部ペイロードと前記内部ペイロードとを含むリクエストを生成し、
前記リクエストを送信する、
システム。
【発明の詳細な説明】
【関連出願へのクロスリファレンス】
【０００１】
本願は、米国仮特許出願６２／１００４０６号（２０１５年１月６日出願）、米国仮特許出願６２／１０８９８７号（２０１５年１月２８日出願）、米国仮特許出願６２／１４４２９３号（２０１５年４月７日出願）、米国仮特許出願６２／１５１１７４号（２０１５年４月２２日出願）、米国仮特許出願６２／１７４３９４号（２０１５年６月１１日出願）、国際出願ＰＣＴ／ＵＳ２０１５／０６４２４２号（２０１５年１２月７日出願）、及び米国仮特許出願６２／２６６０６０号（２０１５年１２月１１日出願）の優先権を主張するものであり、当該出願の開示全体をここに参照のために取り込む。米国仮特許出願６２／０８９１１３号（２０１４年１２月８日出願）の開示全体をここに参照のために取り込む。
【技術分野】
【０００２】
本開示は、ニュートラルなアプリケーションプログラミングインタフェース（ＡＰＩ）メカニズムを介したデバイスからデバイスへの通信におけるネットワークに関し、特に、自動化されたフロー及び情報交換に関する。
【背景技術】
【０００３】
デバイスが互いに通信する必要があることがある。時としてこの通信は、静的な情報（例えばログ記録、コンテンツアップデート、又は異なるデータ等）を伝達又は報告するものである。一のデバイスは他のデバイスへ問合せを行い、２つの通貨間の現在の為替レートを取得し、又は株価相場をフェッチする必要がある。これらは共に、定期的に変動する経時データである。他の通信はまた、本質的に取引上のもの（例えば購入を決済するために顧客によって売主に提示されるクレジットカードでの決済認証）であってよい。他のデバイス間の情報共有は、セキュアなトンネルの確立に関し、このとき、キー、証明書及び接続設定が各デバイスに要求される。
【０００４】
アプリケーションプログラミングインタフェース（ＡＰＩ）は、そのようなデバイス間通信のフレームワークであり、リスニングサーバへのクエリを生成するクライアントデバイスからの自動情報交換を容易にする。当該リスニングサーバは、当該発信クライアントデバイスへ応答し、レスポンスを返信する。クライアントデバイス及びサーバデバイスは、ピアのペアを構成する。
【０００５】
ＡＰＩの共通のタイプは、特定のデータ構造ペイロードを有するリクエストーレスポンスＡＰＩのポストメカニズムであり、特定のデータ構造ペイロードで返信されるレスポンスと共に、特定のURLにてクライアントピアからサーバピアへ提示される。これは一般に、ポストされた情報がリモートサーバで単一目的のスクリプトによって処理されるためのものであり、結果は発信クライアントデバイスに返送される。この使用方法としては、取引データ（例えばベンダの売主アカウント情報、購入者関連情報及び購入金額）と共に提示されるクレジットカード情報のリクエストがあり、承認又は不承認メッセージがレスポンスとして返される。このＡＰＩタイプはほとんどの場合、不完全、形式不備、又は不正確なデータ構造ペイロードを拒絶する。このタイプのＡＰＩは、従うべきセキュリティプロトコル（例えば証明書の提示、ＨＴＴＰＳ暗号化、キー又は他の方法）を要求する。このようなＡＰＩには利点と欠点がある。これは、単一目的の場合は理想的であり、高容量のために設計されている。これにより多くの第三者クライアントは、例えばクレジットカードの取引承認ＡＰＩ等の場合には、それに問合せることができる。他の使用例では、このタイプのＡＰＩが使用される目的にとって、実装は非常に複雑であり望ましくない。
【０００６】
特定のＵＲＬ及びパスに対してなされるＡＰＩコールが特定のハンドラによって処理されることは一般的である。他のタイプのＡＰＩ取引がなされる必要があるとき、それは他のURL及びパスに対してなされ、異なるハンドラ及び対応するスクリプトによって処理される。各個別のＡＰＩコールは、この機能をシステムに実装し統合するためにクライアント側で所定の開発量を要求する。他の検討事項は、セキュリティ、ロギング（ログ取り）及び他の要求されるタスクを実装するのに必要とされる、開発時間、作業及び努力である。これらは、機能をシステムに統合するときの各タイプのＡＰＩ情報交換インスタンスに関する、クライアントサイド及びサーバサイドに対するものである。
【０００７】
上記を考慮すると、単一目的のＡＰＩポストループの短所に対処し、より高い安全性及び柔軟性を可能にする重大な必要性が存在することを理解されたい。
【発明の概要】
【０００８】
ニュートラルなアプリケーションプログラミングインタフェースに関するシステム及び方法が開示される。一実施形態では、本開示はニュートラルなアプリケーションプログラミングインタフェースに関する。システムはデバイスを含んでよい。デバイスは要求を受信するよう構成されてよい。リクエストは外部ペイロード及び内部ペイロードを含んでよい。デバイスは更に、外部ペイロードの共通定義に基づいて外部ペイロードをパースするよう構成されてよい。デバイスは更に、外部ペイロードから、アクションの情報を抽出するよう構成されてよい。デバイスは更に、アクションの定義に基づいて、内部ペイロードをパースするよう構成されてよい。デバイスは更に、アクションを処理するよう構成されてよい。
【０００９】
本実施形態の他の態様によれば、外部ペイロードは、リクエストが生成されるときに時間のタイムスタンプを含む。
【００１０】
本実施形態の他の態様によれば、内部ペイロードは暗号化され、デバイスは更に内部ペイロードを復号化するよう構成される。
【００１１】
本実施形態の他の態様によれば、デバイスは更に、デバイスがリクエストを受信するときとタイムスタンプとの間の時間経過が閾値を超えていれば、アクションを処理しないよう構成される。
【００１２】
本実施形態の他の態様によれば、閾値はネットワークの待ち時間（レイテンシ）に基づく。
【００１３】
本実施形態の他の態様によれば、閾値は１秒と等しい。
【００１４】
本実施形態の他の態様によれば、内部ペイロードの暗号化は、タイムスタンプ及びアクションに基づく。
【００１５】
本実施形態の他の態様によれば、内部ペイロードの暗号化は、リクエストを発する発信デバイスと当該デバイスとに更に基づく。
【００１６】
本実施形態の他の態様によれば、リクエストはセキュアソケットレイヤを介して送信される。
【００１７】
本実施形態の他の態様によれば、内部ペイロードは、アレイ、キーと値とのペア、オブジェクト、データファイル及びバイナリファイルの少なくとも１つを含む。
【００１８】
本実施形態の他の態様によれば、デバイスは更にスクリプトを有するアクションを処理するよう構成される。
【００１９】
本実施形態の他の態様によれば、デバイスは更に、サーバからアクションを検索するよう構成される。
【００２０】
本実施形態の他の態様によれば、サーバはアクションについての情報を格納し、デバイスについての情報を格納するよう構成される。
【００２１】
本実施形態の他の態様によれば、サーバは発信デバイスと宛先デバイスとのピア関係を格納するよう構成される。
【００２２】
本実施形態の他の態様によれば、サーバは更にアクションを更新するよう構成される。
【００２３】
本実施形態の他の態様によれば、デバイスは更に、そのピアの発信デバイスのリストをサーバから検索するよう構成される。当該デバイスはそのピアの発信デバイスの当該リスト上のデバイスからのリクエストをリスニングする。
【００２４】
本実施形態の他の態様によれば、サーバは更にアクションをデバイスへプッシュするよう構成される。
【００２５】
本実施形態の他の態様によれば、サーバは更に、アクションをフラグして可用性を示すよう構成される。
【００２６】
本実施形態の他の態様によれば、デバイスは更に、リクエストのレスポンスを送信するよう構成される。
【００２７】
本実施形態の他の態様によれば、デバイスは更に、レスポンスに、リクエストの一部を含むよう構成される。
【００２８】
他の実施形態は、本開示はニュートラルなアプリケーションプログラミングインタフェースのための方法に関する。本方法によればリクエストが受信される。リクエストは外部ペイロード及び内部ペイロードを含んでよい。外部ペイロードは、外部ペイロードの共通定義に基づいてパースされてよい。アクション情報は外部ペイロードから抽出されてよい。内部ペイロードは、アクションの定義に基づいてパースされてよい。アクションは処理される。
【００２９】
他の実施形態では、本開示はニュートラルなアプリケーションプログラミングインタフェースについてのコンピュータ可読プログラムを格納する非一時的コンピュータ可読媒体に関する。プログラムはコンピュータ可読命令を含んでリクエストを受信してよい。リクエストは外部ペイロード及び内部ペイロードを含んでよい。プログラムは、外部ペイロードの共通定義に基づいて外部ペイロードをパースするコンピュータ可読命令を含んでよい。プログラムは、外部ペイロードから、アクションの情報を抽出するコンピュータ可読命令を含んでよい。プログラムは、アクションの定義に基づいて内部ペイロードをパースするコンピュータ可読命令を含んでよい。プログラムは、アクションを処理するコンピュータ可読命令を含んでよい。
【００３０】
本開示は、添付する図面に示されるように、その特定の実施形態を参照して一層詳細に開示される。本開示は特定の実施形態を参照して下記に開示されるが、本開示はそれに限定されるわけでないことを理解されたい。本開示の教示を入手可能な当業者は、他の使用分野に加えて、追加の実装、変形及び実施形態を認識する。これらは本開示の範囲内である。これに関して本開示は大いに有用性を有する。
【００３１】
本開示の理解を一層容易にするために、添付する図面が参照される。ここでは、類似の要素は類似の番号又は参照符号により参照される。これらの図面は、本開示を限定するものとして解釈してはならない。当該図面は例示のみを意図したものである。
【図面の簡単な説明】
【００３２】
【図１】本開示の実施形態によるアプリケーションプログラミングインタフェースがどのように動作するかについてのフローチャート図である。
【図２】本開示の実施形態による、内部ペイロード内でデータアレイを伝送するニュートラルなアプリケーションプログラミングインタフェース（ＡＰＩ）メカニズムを示すフローチャート図である。
【図３】本開示の実施形態による、ペイロードにかかわらないＡＰＩメカニズムの中立性を示すフローチャート図である。
【図４】本開示の実施形態による、ニュートラルなＡＰＩメカニズムのセキュリティ態様を示すブロック図である。
【図５Ａ】本開示の実施形態による、一例のリクエストペイロードアレイを示す図である。
【図５Ｂ】本開示の実施形態による、一例のレスポンスペイロードアレイを示す図である。
【図６】本開示の実施形態による、ニュートラルなＡＰＩメカニズムのデバイスのピアと中央制御サーバ（SRV_CNTRL）との協働を示す図である。
【図７】本開示の実施形態による、自動化されたデバイスの協働を示す図である。
【図８】本開示の実施形態による、デバイスと中央制御サーバとの間の情報フローを示す図である。
【図９】本開示の実施形態による、セキュリティを有するバックボーンの交換サーバトポロジと、オープンジョーのＡＰＩシーケンスとを示す図である。
【図１０】本開示の実施形態による、内部ＡＰＩコールの完了に依存するオープンジョーのＡＰＩコールを示す図である。
【図１１】本開示の実施形態による、ピアデバイス間及びデバイスと中央制御サーバとの間でのリクエスト／レスポンスを示す図である。
【図１２】本開示の実施形態による、クローズドループ及びオープンループを示す図である。
【図１３】本開示の実施形態による、リクエストペイロードにおける例示的トランザクションコードを示す図である。
【図１４】本開示の実施形態による、レスポンスペイロードにおける例示的トランザクションコードを示す図である。
【図１５】本開示の実施形態による、クローズドループでのリクエスト／レスポンスペイロードにおける例示的な要素マッピングを示す図である。
【図１６】本開示の実施形態による、オープン／RESTfulループにおけるリクエスト／レスポンスペイロードでの例示的な要素マッピングを示す図である。
【図１７】本開示の実施形態による、ニュートラルなＡＰＩメカニズムによって使用される主なモジュール間の協働及び関係を示す図である。
【発明を実施するための形態】
【００３３】
実施形態では、本開示のニュートラルなアプリケーションプログラミングインタフェース（ＡＰＩ）のメカニズム（NAPIM）は、複雑なタイプのネットワークのコンポーネントであってよい。当該ネットワークは例えばGlobal Virtual Network（ＧＶＮ）であり、多くのデバイスにわたって動的に広がる必要がある。次のような条件が存在する。すなわち、ＡＰＩコールの新しいパターンを追加すること、既存のＡＰＩコールのパターンを変更すること、共通のトランスポート、セキュリティ及びロギングフレームワークを使用すること、古いＡＰＩコールのパターンを撤収すること、発展的な特徴を有して任意のペイロードを伝達可能とすること、ピアのペア間でＡＰＩ関係の情報（ピア自体の情報、又は、当該ペアが接続し又は接続される関連ピアについての情報を含む）を動的に追加、削除又は編集すること、サーバ、クライアント又はそのクライアント及びサーバの両方として、異なる時点で、特定のピアのペアのＡＰＩトランザクション又は関係、処理関係における役割に応じて、デバイスがコンテキストに沿って動作することを可能にすること、全てのＡＰＩクライアント及びＡＰＩサーバを、ＡＰＩピアを介して中央サーバに登録して、ＡＰＩメカニズム構造情報マトリックスを動的に更新することを許可するサーバＡＰＩコールを制御すること、及び他の条件である。
【００３４】
実施形態では、NAPIMを用いて更新を伝達してよい。当該更新は、ピアのペアについての更新済みリストや、ピアのペア間の証明書を維持すること、ＡＰＩアクションのリスト、ログ及び他の情報を維持することを含む。
【００３５】
実施形態では、この柔軟性のあるトポロジの利点として、デバイスは一方の情報交換においてはクライアントとして動作し、ＡＰＩ情報の他方の交換においてはサーバとして動作することができる。ＡＰＩクライアントホストは、ＡＰＩコールをトリガして、ＡＰＩリクエストのサーバホストピアへの送信を開始する。クライアントは返信されたレスポンスをパース及び処理する。ＡＰＩサーバホストは、ＡＰＩクライアントホストから開始されたリクエストポストをリスニング（聴取）するリスナを有してよい。リクエストを受信すると、ＡＰＩサーバホストはそれをパース及び処理し、次いで、返信されるレスポンスを準備する。
【００３６】
実施形態では、セキュリティの理由で、デバイスのＡＰＩリスナは、サーバとして動作する必要がないときに閉じられる。その他のときは、ＡＰＩリスナは開かれ、ＡＰＩサーバとして動作することができる。
【００３７】
実施形態では、中央制御サーバ（SRV_CNTRL）は、本開示のNAPIMシステムに存在する。NAPIMシステムにおけるデバイスは中央制御サーバ上に登録されてよい。中央制御サーバはデバイス（デバイスの環境及びソフトウェアを含むがこれに限られない）を管理する。中央制御サーバは世界的な仮想ネットワーク（Global Virtual Network）に存在してよい。冗長性の理由で、様々な位置に中央制御サーバが複数存在してよい。
【００３８】
ＡＰＩの中立性は、伝達されるペイロードにかかわらず維持され、外部ペイロードのユニバーサルパターンによって記述されてよい。このとき、様々な可能な内部ペイロードの定義済みデータ構造のトリガ及び処理は特定のアクションコードによって判定される。したがって、NAPIMを通して、無限のＡＰＩアクションが可能である。
【００３９】
アクションの機能的な状態は、クライアントピア上の関連するスクリプトトリガにアクション情報を提示すると操作可能である。次いでこれは、クライアントピア上のNAPIMのリクエストセンダを介して、リクエストハンドラと、そこでスクリプトを動作させるサーバピア上のプロセッサスクリプトとへ転送される。クライアントピア上のレスポンスハンドラスクリプトは、サーバピアから受信したレスポンスを解釈し、適切なスクリプトを動作させる。ＡＰＩアクションの各タイプにつき、スクリプト、データ構造及びペイロードは、無制限の拡張性の目的で、ＡＰＩメカニズム自体を介してピアのペアにおける各デバイスへ複製されてよい。
【００４０】
したがって、一般的なNAPIMシステムが、ＡＰＩトランスポートのペイロード構造、センダ、リスナ、ハンドラ及び他の要素を利用する一方、無限の可能なアクションペイロードが内部ペイロードを介して伝送可能であり、NAPIMを介して処理可能である。
【００４１】
図１はアプリケーションプログラミングインタフェースがどのように動作するかを示すフローチャート図である。図１は、２つのデバイス間での、アプリケーションプログラミングインタフェース（ＡＰＩ）によるリクエストーレスポンスの自動情報交換トランザクションの自動処理フローを示す。図１に示すように、ピアデバイスD-01及びD-02のペアがある。ピアオリジンD-01は、ＡＰＩコールの元となるホストクライアントである。ステップ１にて、ピアオリジンD-01はリクエスト102として、送信すべきペイロードを有するＡＰＩリクエストを生成する。ステップ２にてリクエスト102はリスニングホストサーバのピアターゲットD-02によって受信される。ステップ３にて、ピアターゲットD-02によって受信されたＡＰＩリクエストはD-02のＡＰＩハンドラによって処理される。ＡＰＩコールの処理に基づいて、アクションが実行される。ステップ４にて、処理されたＡＰＩリクエストに基づくレスポンスが準備され、レスポンス104として返信される。ステップ５にて、レスポンス104はピアオリジンD-01によって受信される。ステップ６にて、レスポンス104はピアオリジンD-01によって処理される。
【００４２】
実施形態では、リクエスト及びレスポンスにセキュリティレイヤが付加されてよい。トランスポート方法はまた、証明書、プロトコル（例えばhttps又はhttp）又は他の方法によって保護されてよい。実施形態では、ピアホストD-01及びD-02の両方は、構造化されたデータペイロードを準備及び送信する。当該ペイロードは他のピアによって解釈、理解及び処理可能である。
【００４３】
図２は、本開示の実施形態による、外部ペイロード内で内部ペイロードとしてデータアレイを伝送するニュートラルなアプリケーションプログラミングインタフェース（ＡＰＩ）メカニズムを示すフローチャート図である。図２は、ＡＰＩメカニズムの中立性を図示し、ここでは全てのリクエスト及びレスポンスの外部ペイロードが同一のデータ構造パターンに関わる。換言すれば、全てのリクエスト及びレスポンスの外部ペイロードは、同一の一貫した構造、フィールド等を有する共通の定義に関わる。「同一パターン」の準備、伝送及びパースフレームワークにより、非常に柔軟的で動的な、無限のＡＰＩアクションの抽出が可能である。当該ＡＰＩアクションはメカニズムによって伝達される。このアプローチはまた、１以上のセキュリティレイヤに覆われるデータペイロードを安全にする機会を提供する。追加の効果としては、ＡＰＩ自体が自身の構造定義の伝達システムとなり、ＡＰＩ自体を介して、ＡＰＩアクション、関連スクリプト、データ構造定義及び他の関連情報の発行を通じて新たな機能性がそのアクションマトリックスに付加されることである。
【００４４】
各ピアデバイス上で動作するＡＰＩインスタンスのデータベースにより、テーブルはＡＰＩキュー、ピアのペアデータ、ＡＰＩトランザクション、ＡＰＩアクションインデックス及び、ピアのペアにおける各デバイスのＡＰＩモジュールが使用する他の関連情報、を格納することを可能にする。クライアント、サーバ及び中央サーバデバイスにおけるソフトウェアスタック、並びに、データベース間でのデータベース支援及びデータ複製の統合に関する詳細は、図６に関して下記で説明する。本開示で示されるデータベースのテーブル名、フィールド、及び構造は一例であり、異なってよい。ＡＰＩ関連データを格納する、より多い又は少ないテーブルが存在してよい。
【００４５】
内部ペイロードを暗号化して保護することと、不明瞭なペイロードを外部ペイロードのデータ要素として含むこととによって、必須のセキュリティが実現される。
【００４６】
図２は図１の全ての要素を含む。図２に示すように、ピアオリジンホスト（クライアント）ソースD-01において付加される開始点（ステップ０）は、ＡＰＩトランザクションコールのトリガを示す。ステップ０はD-01-AからD-01-Eまでのサブステップを含んでよい。ステップD-01-Aにて、データは共通クラス又は他のタイプのハンドラに渡され、内部ペイロードを作成する。ステップD-01-Bにて、内部ペイロードはメモリ内のキューに追加され、データベース、フラットファイル又は他のメカニズムに保存される。キューステップはバイパスされ、又は、特定の時間に実行するよう設定されてよい。ステップD-01-Cにて、クライアントデバイスD-01のハートビート機能の一部として、キュー内のＡＰＩコールの優先フラグによって、キュー内のペイロードは、負荷、キューの長さ、ネットワーク状況又は他の要因等に基づいて即座に処理され、特定の時間に処理され、又は延期されてよい。ステップD-01-Dにて、アイテムがキューから処理された後、外部ペイロードが準備される。ステップD-01-Eにて、関連トランザクションデータが特定の１回きりのＡＰＩコールのために生成される。暗号化は、時間、ペアにおけるピア、アクション及び他の要因に基づいた計算キーを循環させることにより、一意（ユニーク）であり得る。ステップ１にてＡＰＩリクエストペイロードPL01の送信準備ができると、それはニュートラルなＡＰＩメカニズムを介して送信され、ステップ２でピアターゲットホスト（サーバ）ＡＰＩ（D-02）によって受信される。図２に示すように、実施形態では、外部ペイロードPL01はデバイス、アクション、トランザクションコード、ペイロード、ＩＰアドレス、トランザクションタイプ及びタイムスタンプに関する情報を含んでよい。タイムスタンプはリクエスト又はペイロードが生成される時間であってよい。ペイロードは暗号化された内部ペイロードを特定してよい。
【００４７】
ステップ３にてＡＰＩリクエストペイロードPL01を受信すると、ピアターゲットD-02はＡＰＩリクエストペイロードPL01をパース及び解釈する。ステップ３はD-02-AからD-02-Dまでのサブステップを含んでよい。ステップD-02-Aにて、ＡＰＩリクエストペイロードPL01の処理において、セキュリティ及びデータ完全性のチェックが実行されてよい。また、ペイロードは復号化されて、内部ペイロードの内容を検出する。内部及び外部ペイロードを比較して、更なるセキュリティ及びデータ完全性のチェックが実行されてよい。実施形態では、外部ペイロードは、外部ペイロードの「同一パターン」（すなわち、共通）構造にしたがってパースされる。実行されるアクション（例えばAAPIAC）の情報（例えば、名称）が取得されてよい。内部ペイロードは、アクションの定義にしたがってパースされてよい。例えば内部ペイロードは、アクションAAPIACの定義にしたがってパースされてよい。実施形態では、アクションの定義はアクションのペイロードの構造を特定する。検証後、ステップD-02-Bにて、ペイロード（例えば内部ペイロード）は対応するスクリプトに渡され、所定のアクションを実行する。実施形態では、アクションはスクリプト又は他のハンドラによって処理される。ステップD-02-Cにて、リクエストされたアクションが完了すると、レスポンスについての内部ペイロードが作成される。これは、フィールドの暗号化を含んでよい。ステップD-02-Dにて、レスポンスについての外部ペイロードが作成される。ステップD-02-Eにて、関連トランザクションデータがレスポンス104について生成される。このとき、ＡＰＩレスポンスペイロードPL02が生成される。
【００４８】
実施形態では、ＡＰＩリクエストペイロードとＡＰＩレスポンスペイロードとの違いは、トランザクションタイプ（すなわち、REQ：リクエストとRSP：レスポンス）を含んでよい。実施形態では、トランザクションがD-01-E及びD-02-Eにて準備されるときにタイムスタンプが作成される。当該差は、異なるタイムスタンプを含んでよい。タイムスタンプはＵＮＩＸタイムスタンプであってよく、処理時間は様々なアクション間で異なる。システムの完全性を維持するために、全てのデバイスは定期的に内部クロックを自動的に更新して同時性を確保する。これにより、クロックのタイムドリフトを避けることができる。上記の差は、デバイスを含んでよい。例えば、ＡＰＩリクエストペイロードPL01における[Device]は、ピアオリジンD-01のデバイスコードを特定する。ＡＰＩレスポンスペイロードPL02における[Device]は、ピアターゲットD-02のデバイスコードを特定する。ＡＰＩリクエストペイロードPL01におけるトランザクションコードと、ＡＰＩレスポンスペイロードPL02におけるトランザクションコードとは異なってよい。ＩＰアドレスもまた、それらの間で異なってよい。
【００４９】
ペイロードもまた異なってよい。レスポンスペイロードPL02は、より冗長であってよい。というのも、データ構造の[Payload]要素は、暗号化されていないリクエストペイロードPL01とレスポンスペイロードとの両方を含む暗号化ブロックを含むからである。これにより、ピアオリジンD-01は、レスポンスのデータ構造の完全性を検証するだけでなく、D-01は、比較及び検証目的のため、元のリクエストの内部復号化版を受信可能である。ステップ６にて、ピアオリジンD-01はＡＰＩレスポンスペイロードPL02をパース及び解釈する。ステップ６は３つのサブステップを含んでよい。ステップD-01-Fにて、レスポンスペイロードは処理及び検証される。検証が成功すると、ステップD-01-Gにて、PL02の内部復号化レスポンスペイロードは、ピアオリジンD-01上の適切なアクションレスポンスハンドラスクリプトへ送信されてよい。ステップD-01-Hにて、ＡＰＩトランザクション、ＡＰＩのロギング及び終了が実行される。内部復号化レスポンスに[Callback]アレイが付加されているとき、それは１以上の新たなＡＰＩトランザクションコールのトリガとなる。当該ＡＰＩトランザクションコールはステップ０にて開始する。D-01-HはＡＰＩトランザクションコールの最終的なエンドポイントなので、全ての新たなコールバックＡＰＩコールは独立して処理されてよく、また、過去のコールに依存せず独立してよい。
【００５０】
実施形態では、内部ペイロードはアレイ、キーと値とのペア、オブジェクト、データファイル、及び／又はバイナリファイルを含んでよい。
【００５１】
図３は、本開示の実施形態による、ペイロードにかかわらないＡＰＩメカニズムの中立性を示すフローチャート図である。図３は、ステップ０乃至６、リクエスト102、レスポンス104、ピアオリジンD-01及びピアターゲットD-02を含む。
【００５２】
ＡＰＩコールのステップ０が開始点である。実行されるアクションに基づいて、特定のアクションスクリプトはスタンドアロンのファイル、デーモン、クラス、ファンクション、コードの埋め込みブロック、又は、実行される特定のＡＰＩアクションのための内部ペイロードデータ構造を準備する他のメカニズムであってよい。
【００５３】
例えば、アクションコードAのスクリプト0-Aはペイロードを準備し、ステップD-01-Aにてリクエストの内部ペイロードを作成する。本実施形態の簡便化の目的で、図２に示されるD-01-BからD-01-Eまでのステップは図示しないが、それらはステップD-01-Aとステップ１との間で実行されるものとして理解されたい。ステップ１にて、リクエストペイロードは、図１及び図２と類似の方法で、ピアターゲットD-02へ送信される。
【００５４】
ステップ２にて、リクエストペイロードはピアターゲットD-02によって受信される。ステップD-02-Aにて、リクエストペイロードはパース及び処理される。トリガによって特定されるアクションコード（この例ではアクションコードA）に基づいて、内部ペイロードの復号化が成功し、セキュリティ及びデータの完全性検証が完了すると、内部ペイロードにおけるデータ構造はアクションコードＡのスクリプト3-Aへ送信される。レスポンス内部ペイロードデータ構造のハンドリング、処理及び生成が成功すると、ステップD-02-Eにて、レスポンス104のために関連トランザクションデータが生成される。レスポンスペイロードはステップ４にてピアオリジンD-02へ送信され、ステップ５にてピアターゲットD-01によって受信される。
【００５５】
上記の通りステップD-01-Gでは、検証が成功すると、内部復号化レスポンスペイロードは、ピアオリジンD-01上の適切なアクションレスポンスハンドラスクリプトへ送信されてよい。図３に示すように、アクションコードに基づいて、内部復号化レスポンスペイロードは関連するアクションコードスクリプトへ送信される。この例の流れでは、アクションコードＡはアクションコードＡのスクリプト6-Aによって処理される。この例示的なＡＰＩコールトランザクションはD-01-Hで終了する。
【００５６】
同様に、アクションＢがペイロードに含まれる場合、アクションＢは0から0-Bに進み、その後D-01-Aから、１、２、３を通ってD-02-Aまで進む。リクエストは3-Bによって処理され、その後D-02-Eから４、５、６、D-01-Gを通って6-Bに進み、D-01-Hで終了する。
【００５７】
同様に、アクションＣがペイロードに含まれる場合、アクションＣは０から0-Cに進み、その後D-01-Aから、１、２、３を通ってD-02-Aまで進む。リクエストは3-Cによって処理され、その後D-02-Eから４、５、６、D-01-Gを通って6-Cに進み、D-01-Hで終了する。
【００５８】
図４は、本開示の実施形態による、ニュートラルなＡＰＩメカニズムのセキュリティ態様を示すブロック図である。
【００５９】
多くの方法では、ニュートラルなＡＰＩメカニズムは、キーファイル、証明書又は他の資格情報（すなわち、Ｆ３）を用いて、伝統的なクライアントーサーバのリクエスト−レスポンスＡＰＩコールのように動作し、インターネットＦ５から408を通ってＨＴＴＰＳ（すなわち、Ｆ４）トランスポートのセキュアソケットレイヤ（ＳＳＬ）を介してパケットを暗号化する。トランスポートセキュリティＬ２（406と404を含む）及びネットワークＬ１要素は、専用スクリプトに対してなされる他の伝統的なポストＡＰＩコールに類似する。
【００６０】
ニュートラルなＡＰＩメカニズムは、データ構造Ｌ３の追加保護を受けて、ステップを更に進む。
【００６１】
外部ペイロードは特定のデータ要素を有し、それをターゲットデバイスに向け、暗号化内部ペイロードを伝達する。当該暗号化内部ペイロードはパース及び処理のために適切なアクションコードスクリプトによって処理される。ＨＴＴＰＳ暗号化がインターネットＦ５を通してトランスポート408において妥協されてしまった場合、内部ペイロードＦ１と外部ペイロードＦ２との間での暗号化402がデータペイロードを安全にする。
【００６２】
内部ペイロードと外部ペイロードとの間での暗号化及び復号化402は、特定のピアのペア情報と他の要因（例えばクライアントとサーバデバイスとの間の関係に一意なキーアジャスタ）を使用してよい。他のセキュリティ要素は、特定のアクションのデータ構造が、期待されるパターンに関わるためのものである。実施形態では、ペイロードの暗号化は、様々な要因（タイムスタンプ、アクションタイプ、ピアのペア（及び関連するキーとその関係に関連するキー））を用いて算出された循環キーに基づいてよい。
【００６３】
セキュリティ情報、キー、キーアジャスタ、証明書及び、ピアのペア間でのＡＰＩトランスポートの安全化に関する他の情報は、ＡＰＩコールを介して動的に更新可能でよい。当該ＡＰＩコールは、ピアのペアにおけるデバイス間のものでよい。あるいは、各デバイスが、中央制御サーバ（SRV_CNTRL）に対するＡＰＩコール、バックチャネルメカニズム若しくは他の方法によりこの情報を受信してもよい。
【００６４】
タイムスタンプ、トランスポートコード及び他の要因に基づいてフレームワークに埋め込まれるアンチリプレイの特徴により、各ＡＰＩコールが一度だけ処理されるようにしてよい。これは、悪意の中間者攻撃に対抗し、又は、デバイス機能不全という否定的な結果を排除するためのものである。実施形態では、アンチリプレイはネットワーク待ち時間（レイテンシ）に基づいた閾値に基づく。例えば、発信デバイス（ピアオリジンD-01）と、宛先デバイス（ピアターゲットD-02）との間のネットワーク待ち時間（例えば、ネットワークにおいて予期される待ち時間）が１秒だけであり、且つ、宛先デバイスが、当該発信デバイスによって送信されたリクエストを（例えばリクエストペイロードにおけるタイムスタンプに基づいて）送信後１秒よりも遅れて受信する場合、宛先デバイスは当該リクエストを処理しないことを選択してよい。
【００６５】
図５Ａは、本開示の実施形態による、一例のリクエストペイロードアレイを示す図である。
【００６６】
図５Ａ及び５Ｂは、暗号化されその後外部ペイロードにおいて伝達される内部ペイロードを示す。図５Ａ及び５Ｂは図２に基づいており、その例示的な実施形態で記載される多くの要素を繰り返して図示している。図２は、図５Ａ及び図５Ｂとして定義される同等の図面に分割されている。例示的な実施形態として、図５Ａは、ＡＰＩコールのリクエスト部分を示し、図５Ｂはレスポンス部分を示す。
【００６７】
例示的な実施形態の一部である図５Ａの後述の要素は、図２に記載されるそれ（例えばデバイスD-01、D-02、それらの間の0から1までの通信パス、当該パスに含まれるD-01-AからD-01-Eまでの内部ステップ、そこから1、2、3までのステップ等）と同様である。この例示的な実施形態において、図２におけるペイロードPL01は更に、PL01-OUTER及びPL01-INNERと共に図示される。
【００６８】
ピアターゲットD-02によるリクエスト外部ペイロードPL01-OUTERの復号化に応じて、リクエスト内部ペイロードPL01-INNERが検出される。PL01-INNERのデータ構造は多次元のアレイ又は他のタイプのデータ構造であってよい。[WRAPPER]、[Meta Data]、[Payload]及び[Callback]要素は、例示目的で図示され、同一又は異なるサブフィールド、入れ子構造のアレイ、ファイルへのリンク、ファイルデータの群、又はＡＰＩトランザクションコールのピアのペアのサーバデバイスによって実行されるアクションにとって適切な他の情報、を含んでよい。
【００６９】
図５Ｂは、本開示の実施形態による、一例のレスポンスペイロードアレイを示す図である。
【００７０】
例示的な実施形態の一部である図５Ｂの後述の要素は、図２に記載されるそれ（例えばデバイスD-01、D-02、それらの間の3から4までの通信パス、当該パスに含まれるD-02-AからD-02-Eまでの内部ステップ、そこから4、5までのステップ等）と同様である。この例示的な実施形態において、図２におけるペイロードPL02は更に、PL02-OUTER及びPL02-INNERと共に図示される。
【００７１】
ピアオリジンD-01によるリクエスト外部ペイロードPL02-OUTERの復号化に応じて、レスポンス内部ペイロードPL02-INNERが検出される。PL02-INNERのデータ構造は、PL01-INNERに類似する。しかし、それはレスポンスなので、そのメインのペイロードはサーバによって実行されるアクションの処理結果である。レスポンスを返信するとき、元のリクエスト（例えば元のリクエストの一部、又は元のリクエスト）はデータ構造の要素として含まれてよい。PL02-INNERにおける[WRAPPER]、[Meta Data]、[Payload]及び[Callback]要素は、例示目的で図示され、同一又は異なるサブフィールド、入れ子構造のアレイ、ファイルへのリンク、ファイルデータの群、又はＡＰＩトランザクションコールのピアのペアのサーバデバイスによって実行されるアクションにとって適切な他の情報、を含んでよい。
【００７２】
図６は、本開示の実施形態による、ニュートラルなＡＰＩメカニズムのデバイスのピアと中央制御サーバ（SRV_CNTRL）との協働を示す図である。この例示的な実施形態は、３つのタイプのネットワークデバイスのソフトウェアアーキテクチャの論理図を示す。当該３つのネットワークデバイスは特定の実施形態による、世界的仮想ネットワーク（ＧＶＮ）におけるニュートラルなＡＰＩメカニズム（NAPIM）の一部として共に動作する。図示の通り、ソフトウェア及びハードウェアはネットワークデバイス内に分散されてよいし、異なる回路基板、プロセッサ、ネットワークインタフェースカード及びメモリにわたって分散されてよい。
【００７３】
記載されるネットワークデバイスの１つは、ＡＰＩクライアント（オリジン）デバイス100である。記載されるネットワークデバイスの他のものは、中央サーバSRV_CNTRL200である。３つ目のデバイスはＡＰＩサーバ（ターゲット）デバイス300である。
【００７４】
クライアントデバイス100は、通信パス6P1によって開示されるトンネルを介して存在点（ＰＯＰ）401へと接続され、更に6P2、ＷＡＮ402、通信パス6P4、ＰＯＰ403、通信パス6P5を介してサーバデバイス300に接続される。ＷＡＮ402を通過するパスは、通常のインターネットを介してよい。
【００７５】
各デバイスクライアント100及びサーバ300はまた、6P3を介してSRV_CNTRLデバイス200に接続してよい。
【００７６】
クライアント100とサーバ300とのソフトウェアアーキテクチャは、そのトランザクションにおける各デバイスの役割による差分を有しながらも非常に類似する。クライアント100はＡＰＩクライアントモジュールD176を有し、サーバ300はＡＰＩサーバモジュールD376を有する。この例示的な実施形態を簡便に説明する目的で、クライアント100上に１つのモジュールD176だけが示され、サーバ300上に１つのモジュールD376だけが示される。実際、デバイスは、ＧＶＮ内の機能に応じて、クライアント及びサーバの結合した役割を有してよい。実際、SRV_CNTRLは、ＡＰＩクライアント／サーバモジュールD276において、この特徴を有する。
【００７７】
各デバイスの最低レベルは、メモリD112／D212／D312と、プロセッサD110／D210／D310と、ネットワークインタフェークD120／D220／D320である。これら全ては、ハードウェアレベル上であってよい。オペレーティングシステム（Ｏ／Ｓ）D130／D230／D330は、ＬＩＮＵＸシステム又は同等のシステム（例えばＤＥＢＩＡＮ又は他のもの）であってよい。これは、ルーティング、ホスティング、通信及び他のシステムレベルの動作のためのパッケージ及び構成を含んでよい。
【００７８】
オペレーティングシステムの上には、世界的仮想ネットワークの（ＧＶＮの）オペレーティングシステムのシステムソフトウェアレイヤD150／D250／D350がある。カスタムコマンド、システムモジュール及びここで動作する他の構成物も存在する。ＧＶＮの他のコンポーネントも同様である。ＧＶＮのデバイスの各タイプは、役割に応じて、システムソフトウェアレイヤの一部又は全部を有してよい。
【００７９】
この例示的実施形態では、データベースモジュールD165／D265／D365及びホスティングモジュールD160／D260／D360は、リスニング、送信、処理、ストレージ、検索及びＧＶＮのNAPIMにおける他の関連する基礎レベル動作を行うために構成される。
【００８０】
D170／D270／D370で記載されるＧＶＮマネージャは、NAPIMへ依存機能を提供する。この例示的な実施形態において、D175／D275／D375で記載されるロガー（自動記録装置）は、ＡＰＩアクション及びトランザクションを記録する機能を有する。ロガーはまた、他の役割を有し、ＧＶＮ動作の他の態様のため処理を行う。
【００８１】
ＡＰＩD172/D272/D372は、NAPIMのエンジンを記載する。ＡＰＩクライアント100上では、ＡＰＩエンジンD172の上で、ＡＰＩクライアントモジュールD176がＡＰＩリクエストを準備し、また、受信したＡＰＩレスポンスを処理する。
【００８２】
ＡＰＩサーバ300上においてＡＰＩエンジンD372の上で、ＡＰＩサーバモジュールD376は、D372による処理対象の、入ってくるＡＰＩコールをリスニングし、且つ、D372を介して返信されるレスポンスを準備する。
【００８３】
SRV_CNTRL200上では、リポジトリマネージャD280の追加レイヤがあり、ピアのペア情報、資格情報、及び他の情報の共有について協働を処理する。当該共有は、他のピアへＧＶＮのＡＰＩメカニズムを介して接続する個々のデバイスに対する共有である。
【００８４】
オペレーティングシステムD150／D250／D350は、ファイルストレージHFS100／HFS200／HFS300を有してよい。
【００８５】
ＡＰＩ関連データベーステーブルB100／B200／B300のデータベース構造は、ＡＰＩクライアント100，中央サーバ200及びＡＰＩサーバ300の各々において同等である。
【００８６】
SRV_CNTRL200上において、リポジトリデータベースB208は、一意のピア情報が全てのピアについて格納されている場所である。この情報はリポジトリマネージャD280によって使用され、ピアのペア内のクライアント又はサーバについてＡＰＩ資格情報又は他の情報を通信して、それに関する又はそのピアに関する情報を受信する。
【００８７】
各デバイスのＡＰＩデータベースB100／B200／B300内に格納されるのは、デバイス自体又はそのピアのペアとなるパートナーのピア情報、トランザクションリスト及びキューデータである。
【００８８】
ＡＰＩ以外の事項についても、本開示の方法及びデータベースには他の使用方法があるが、この例示的実施形態は、関連するデバイスのＡＰＩ機能の態様だけに及ぶ。
【００８９】
図７は、本開示の実施形態による、自動化されたデバイスの協働を示す図である。
【００９０】
この例示的実施形態は、世界的仮想ネットワーク（ＧＶＮ）における異なるタイプのデバイス間におけるＡＰＩコールグループ7202、7206及び7208を開示する。各ＡＰＩコールは本質的に循環するものであり、クライアントからサーバへリクエストが送信され、レスポンスが返信される。ほとんどの場合、クライアントはピアのペアの一端又は他端である。これは、他のピアがリスニングを行ってサーバとして動作することが可能である限り妥当する。
【００９１】
ＡＰＩコールグループ7202は、中央制御サーバ（SRV_CNTRL）200からパスP7202-Cを経由しエンドポイントデバイス（EPD）100へP7202-Bを経由するコールと、アクセスポイントサーバ（SRV_AP）へP7202-Aを経由するコールとを示す。このタイプの通信は、リポジトリデータベースと、SRV_CNTRL200、EPD100、及びSRV_AP300上のファイルストアとの間で、トンネル情報、ログ情報、料金情報、デバイスピアのペアデータ及び他の形式の関連情報を交換する。
【００９２】
EPD100とSRV_AP300との間には２つのタイプの通信パスがある。直接のトンネルは、第三レイヤのトラフィック、情報及びバイナリファイルがパスP7206-Cを介してデータパケットとしてプッシュされ得る場所である。EPD100とSRV_AP300との間には、P7206-BからAPI7206を経由してP7206-Aに至るＡＰＩコールフレームワークが存在する。
【００９３】
API7206を経由するEPD100とSRV_AP300との間の直接接続は、情報共有、協働、検証及び他の情報のためのものである。例えばトンネルを再開する試みは通常、一方の側で開始され、他方の側で自動的にそれに応答して再度トンネルを確立する。しかし、トンネルがスタックし再確立不可能なとき、ＡＰＩを用いてコマンドを送信し、両端でトンネルを再開させるよう試みることができる。もし依然として失敗すれば、デバイス間で情報を共有することができる。この情報は、新たなトンネル情報を使用して２つのデバイス間で異なるトンネルを確立する必要性をトリガし、又は、両方のデバイスにSVR_CNTRL200に問合せさせて新たなトンネル確立情報を取得する必要性をトリガする。したがって、API7206を介してそれらの間で通信パスを有することは非常に有用である。
【００９４】
ＡＰＩコールグループ7208は、SRV_CNTRL200、内部バックエンドインフラデバイス及びＧＶＮの他のインフラ支援デバイスからパスP7208-Cを経由するコールを表す。この例示的な実施形態において、図示の簡便化の目的でいくつかのゲートウェイデバイスが図示される。ＧＶＮにおいて、このパスを介してSRV_CNTRLへ接続可能な他のタイプのインフラデバイス（図示せず）が存在する。
【００９５】
SRV_GW_Email7310はメールサーバを表し、P7200-B1、API7208及びP7208-Cを介してSRV_CNTRL200へリンクされる。Ｅメールは、Ｅメールネットワークアクセスポイント（NAP）7401とP7401とを介して送受信される。専用Ｅメールサーバは、他のデバイスがそれら自身の機能に集中することを可能にし、より簡素化された管理体制を提供する。その理由は、Ｅメールサーバ管理に関して維持される必要があるのは、そのデバイスタイプだけだからである。
【００９６】
SRV_GW_FIN7318は、金融ゲートウェイサーバを表す。これにより、P7501と外部API7501NAPとを介し、第三者に対してクレジットカード取引及び他の金融関連取引が実行される。SRV_GW_Email7310の例のように、デバイスタイプの単一目的の役割により、他のデバイスがそのコアとなる機能に集中することが可能であり、簡素化された管理が提供される。SRV_GW_FIN7318だけが、第三者との金融取引を保護するための追加の管理を要求する。
【００９７】
SRV_GW_Other7315は、ＧＶＮとインターネット上の他のサービスとの間の他のタイプのゲートウェイを表す。これらのタイプのゲートウェイサーバとSRV_CNTRL200との間の通信は、P7208-B3、API7208及びP7208-Cを介する。
【００９８】
SRV_AP300とSRV_CNTRL200との間のセカンダリＡＰＩパスは、P7208-A、API7208及びP7208-Cであり、これは冗長性、及び、このピアのペア間でのインフラ関連通信に理由で存在する。
【００９９】
SRV_APサーバからの他のコールグループは、SRV_AP300からパスP7208-A、API7208及びP7208-B1を介してSRV_GW_Email7310に至るパスと、P7208-A、API7208及びP7208-B2を介してSRV_GW_FIN7310に至るパスと、P7208-C、API7208及びP7208-B3を介してSRV_GW_Other7315に至るパスを可能にする。これらはＡＰＩコールにより、SRV_AP300からそれらのデバイスへの直接のデータ交換を実行するためのものである。
【０１００】
P7208-Aを通過するＡＰＩコールはまた、SRV_AP300を介した他のデバイスからの、中継ＡＰＩコール（例えばEPD100からパスP7206-B、API7206、P7206-A、SRV_AP300、P7208-A、API7208、P7208-B2を介してSRVGWFIN7318へのコール）を表す。このとき、SRV_AP300を介したＡＰＩコールの流れはチェーン内の他のホップである。クライアントは一端のEPD100であり、サーバは他端のSRV_GW_FIN7318である。
【０１０１】
ＡＰＩコール及び他のタイプの情報交換は、ＧＶＮ内のデバイスの動作にとって本質的である。実施形態では、自動化インフラ動作のタイプは次のものを含む。すなわち、デバイスオペレーティングシステム構成を最新の状態に維持すること、Ｏ／Ｓ及びモジュールのソフトウェアパッケージを信頼できるソースからリポジトリへ更新することであって、当該リポジトリはパッチング、更新及び新たなインストールの簡便性及び予測性のために最新のソフトウェアを格納可能であること、新たな世界的仮想ネットワークソフトウェアモジュールを展開し、インストールされたモジュールを最新の状態に維持すること、ＧＶＮデータベースの複製を制御すること、ＡＰＩアクションライブラリを最新の状態に維持すること等である。
【０１０２】
各デバイス上で、デーモン及びハートビート機能が存在してよく、ここでは自動化及びデバイス間相互作用が次の目的のために要求される。すなわち、デーモンの動作を維持すること（例えばサービスアップ、キューアップ、障害から解放すること、ハートビート機能、ログ機能）、接続性（コネクティビティ）、構造確立（例えば仮想インタフェース、トンネル、マルチトンネル、ルート、サーバ可用性、地理的宛先、ＤＮＳ、キャッシュ、及び、チェーンされたキャッシュが適切に機能すること）である。
【０１０３】
最新の情報はトンネル確立のために要求され、この情報はクライアントとサーバとの間で共有される必要がある。さもなければ、トンネルは確立不可能である。
【０１０４】
中心的に分析される結果データの報告に関し、テスト及び診断を行い、ＧＶＮの全体的な動作の可視性を得る必要性が存在する。テスト及び診断は次のものを含む。すなわち、第１レイヤの状態、トンネルの接続性、インターネット上のポイントからポイントへ最善のルート、ＧＶＮを介した最善のルートのためのアドバンストスマートルーティング（ＡＳＲ）及びデバイス動作等である。
【０１０５】
本開示のニュートラルなＡＰＩメカニズムは、それ自体の情報を伝達するために用いられる。当該情報とは、ピアのペア情報、キュー情報、トランザクションログ、セキュリティ／アカウンティング／ロギング及び他の関連データ、ＡＰＩアクション、パターン、データ構造、及びクライアント又はサーバのどちらかでのアクションを処理する関連スクリプトを含むが、これらに限られない。
【０１０６】
ＡＰＩのフレームワーク及びホスティングが起動及び動作することを確保するための必要条件が存在してよい。ホスティングサービスの状態及び構成に関する情報はまた、本開示のニュートラルＡＰＩメカニズムを介して、デバイスから中央制御サーバ又は他のデバイスへと伝達される。ニュートラルなＡＰＩメカニズムは、次の情報を伝達するために用いられてよい。すなわち当該情報とは、サービス起動状態、ＡＰＩモジュールが起動し応答可能であること、サイトのホスティング、データベースの動作、セキュアな（すなわち、ＨＴＴＰＳ通信のためのＳＳＬ証明書が最新状態の）通信、地理的宛先のコンポーネントが動作中であるか否か、を含むがこれらに限られない。
【０１０７】
セキュリティ／ファイアウォール／監視／協同作用／情報交換に関するニュートラルなＡＰＩメカニズムを介した情報交換／ネットワーク（例えばＧＶＮ等）環境における他のミッションに不可欠な態様、については、他の使用方法が存在してよい。
【０１０８】
ニュートラルなＡＰＩメカニズムは情報交換のための強力な媒体であってよく、したがって、全体的な自己回復能力をデバイス間で展開可能である。
【０１０９】
図８は、本開示の実施形態による、デバイスと中央制御サーバとの間の情報フローを示す図である。この例示的な実施形態は、世界的仮想ネットワークのデバイス間での情報フローを開示する。中央リポジトリはデータベースB200を有し、ファイルストレージHFS200は中央制御サーバ（SRV_CNTRL）200に連結されてよい。実施形態では、中央リポジトリはＡＰＩ／アクションの定義を格納してよい。例えば、中央リポジトリはＡＰＩ／アクションの定義と、ＡＰＩ／アクションを処理するのに用いられる、ＡＰＩ／アクションに関連付けられたスクリプトとを格納してよい。実施形態では、中央リポジトリはまた、デバイスのピア関係を格納してよい。
【０１１０】
P100200／P100300／P1008500／P200100／P200300／P2008500／P8500200／P3008500は、ピアのペアを有するＧＶＮデバイス間での通信を表し、それゆえ、互いの特権的な関係を表す。EPD100／SRV_AP300／他のデバイス8500は、ファイルストレージHFS100／HFS300／HFS8500及びデータベースB100/B300/B8500に接続されてよい。
【０１１１】
SRV_CNTRL200からP200100を介してEPD100へ、P200300を介してSRV_AP300へ、又はP2008500を介して他のデバイス8500へと図示されるピア−ペア通信の循環パターンが存在する。EPD100はPI00200を介してSRV_CNTRL200と通信し、P300200を介してSRV_AP300と通信し、P8500200を介して他のデバイス8500と通信する。
【０１１２】
実施形態では、デバイス間で共有される情報のループが存在する（例えばEPD100がSRV_CNTRL200からPI00200を介した情報をリクエストする場合、当該情報はP200100を介してEPD100へと返信される）。
【０１１３】
他の実施形態では、デバイスは他のデバイスへ関連情報を報告する。例えばSRV_AP300はP300200を介してSRV_CNTRL200へ報告し、SRV_CNTRL200はP200100を介してEPD100へ又はP2003001を介して他のデバイス8500へ情報を送信する。
【０１１４】
更に他の実施形態では、完全なループは必要でなくてよく、例えばEPD100等のデバイスからP100200を介してSRV_CNTRL200へログ情報を送信するときは、この情報を更にその先へ転送する必要はない。しかし、ログ情報はその後、SRV_CNTRL200上のリポジトリから、P2008500を介して、長期ログ格納サーバ8500へ移動される。
【０１１５】
直接リンクP100300は、デバイスEPD100とSRV_AP300との間にある。直接リンクP3008500はSRV_AP300から他のデバイス8500への間にある。直接リンクはSRV_CNTRLによる関わりを必要としないデバイス間の通信を伴う。
【０１１６】
SRV_CNTRL200からのプッシュ情報8306は、P8306を介して発行されるＲＳＳフィード又は他のタイプの情報であってよい。SRV_CNTRL200からのＡＰＩクエリ8302は、伝統的なＡＰＩトランザクション又はRESTfulなＡＰＩコールであってよく、リクエストはP8302REQを介して生成され、レスポンスはP8302RESPを介して受信される。プッシュ8306及びＡＰＩクエリ8302は、ピア−ペア関係、アクションコード又は定義（例えばアクションコード及び／又は定義は取得されなかった、アクションコード及び／又は定義は古い）、特権状態を共有しないデバイス、及び／又はＧＶＮデバイスを有する類似のシステムアーキテクチャを示すために提示される。
【０１１７】
図９は、本開示の実施形態による、セキュリティを有するバックボーンの交換サーバ（SRV_BBX）トポロジと、オープンジョーのＡＰＩシーケンスとを示す図である。この例示的な実施形態は、典型的な世界的仮想ネットワーク内のデバイスの例示的なトポロジ内のシーケンスにおける、一連のＡＰＩコールを示すものである。
【０１１８】
アクセスポイントサーバSRV_AP300から中央制御サーバSRV_CNTRL200への最初のＡＰＩコールリクエスト9A1が、SRV_CNTRL200によって受信、パース及び処理される。次いでそれは、更に３つのＡＰＩコールをトリガし、これら全てはSRV_CNTRL200によって開始される。通信の種類に応じて、これらは順に行われてよいし、同時に並行処理されてよい。これらの３つの追加コールは、バックボーン交換サーバSRV_BBX9800へのリクエスト9A2及びレスポンス9A3と、他のサーバSRV_BBX9810へのリクエスト9A4及びそのレスポンス9A5と、最後の第３の追加ＡＰＩコールとして、SRV_AP9302に対するリクエスト9A6及びSRV_CNTRL200に対するレスポンス9A7である。３つ全ての「内部」コールが完了すると、最後のレスポンス9A8がSRV_AP300へ、すなわち、最初のリクエスト9A1を開始したデバイスへ返信される。
【０１１９】
ＡＰＩリクエスト9A1及びレスポンス9A8は、SRV_BBX9800を伴うその内部コール9A2及び9A3と、SRV_BBX9810を伴う9A4及び9A5と、SRV_AP9302を伴う9A6及び9A7とが完了するまでは完了できないという条件を有するオープンジョーのコールとして特徴付けられる。その理由は、SRV_AP300が測定及び統合目的又は他の理由で次のアクションを実行可能となる前に、SRV_AP300によって情報が要求されるからである。例えばエンドツーエンドのトンネルはSRV_AP300からSRV_BBX9800、SRV_BBX9810及びSRV_AP9302へと、パス9P2、9P3及び9P8を介して確立される必要がある場合、これらのデバイス全ては適切な情報及び詳細で構成され又はトリガされる必要がある。このタイプのＡＰＩコールは、9A1を介してSRV_CNTRL200までこれをセットアップするリクエストを示し、次いで当該リクエストは内部の３つのＡＰＩコール、すなわち9A2及び9A3と、9A4及び9A5と、9A6及び9A7とを通る。レスポンス9A8は、SRV_AP300が使用する構成及び設定情報の両方や、他のピアデバイスが設定され準備ができたことを示す、SRV_CNTRL200からの通知を含むことができる。
【０１２０】
図９は、EIP9500から9P5、POP9600及び9P6を介してオープンなインターネット9700へのフローを含む。図９は、EIP9502から9P10、POP9602及び9P11を介してオープンなインターネット9702へのフローを含む。9P1はEPD100及びSRV_AP300を接続する。9P4はSRV_AP300及びEIP9500を接続する。9P7はEPD9102及びSRV_AP9302を接続する。9P9はSRV_AP及びEIP9502を接続する。
【０１２１】
実施形態では、A2／A3と、A4／A5と、A6／A7とは、連続性又は順番に関して独立したＡＰＩコールである。他の実施形態では、A2／A3と、A4／A5と、A6／A7とは並行して実行されてよい。
【０１２２】
セキュリティ要素は本願で図示されるＧＶＮトポロジ内の様々な位置に配置可能である。例えばファイアウォールFW9400及びFW9402は、9P2及び9P8上に配置されてよい。ファイアウォールFW9400及びFW9402はSRVBBXをインターネットの脅威から保護し、セキュアなバックボーン通信を確保してよい。
【０１２３】
セキュアな出入りポイント（EIP9500及び9502）はまた、この種のＡＰＩ交換における要因であってよい。
【０１２４】
図１０は、本開示の実施形態による、内部ＡＰＩコールの完了に依存するオープンジョーのＡＰＩコールを示す図である。この例示的な実施形態は図９に基づいており、世界的な仮想ネットワークにおける、ＧＶＮデバイスと中央制御サーバSRV_CNTRL200との間のＡＰＩコールのセットの異なる外観を提示する。オープンジョーのコールバックエンドAPI#1（9A1から9A8）は、内部ＡＰＩコールAPI#2（9A2から9A3）と、API#3（9A4から9A5）と、API#4（9A6から9A7）とを包含する。
【０１２５】
これらの内部ラウンドトリップ（往復）は、外部ラウンドトリップが完了したものとして構成されるのに要求される依存関係である。API#1（9A8）についてのレスポンスは、結果を評価してレスポンスとして返信する前に、内部のＡＰＩコールAPI#2（9A2及び9A3）、API#3（9A4及び9A5）及びAPI#4（9A6及び9A7）が完了するのを待つ。その後初めて、オープンジョーのＡＰＩが閉じてレスポンスが送信される。
【０１２６】
このタイプのシーケンスは、ＳＱＬステートメントのトランザクションセットに類似する。全てが完了する必要があり、さもなければ何も完了しない。したがって、コールの１つに障害がある場合には、ロールバックが可能である。
【０１２７】
図１１は、本開示の実施形態による、ピアデバイス間及びデバイスと中央制御サーバとの間でのリクエスト／レスポンスを示す図である。この例示的な実施形態は、ニュートラルなＡＰＩメカニズムを介した２つのタイプのデバイス間情報交換を示す。より具体的には、図１１は、11-Aと11-Bを介した既知のピアのペア間におけるクローズドループでの、２つのタイプのニュートラルなＡＰＩメカニズムのリクエストREQとレスポンスRESPとのポスティングを示す。
【０１２８】
実施形態では、デバイスからリポジトリへのコール／情報交換11-Aは、SRV_CNTRL200が、（11req100200／11resp100200を介した）EPD100、（11req300200／11resp300200を介した）SRV_AP300、若しくはクエリすべき他のデバイス等のＡＰＩペアのためのリポジトリモードで動作することができるものである。当該クエリは、デバイス自体について（例えばデバイスのピアのリスト）、デバイスのピアのペアのパートナーについて（例えばピアデバイスの情報）、又は、ＡＰＩメカニズムについて（例えばアクション（アクションコード、関連ハンドラ、スクリプト、ペイロード構造等）、アクションに関連付けられたスクリプト、アクションの定義／構造）のものである。
【０１２９】
実施形態では、SRV_CNTRL200は、１より多いモードで動作可能である。当該モードは、リポジトリ（クエリすべきピアのためのもの）、ピアオリジン（クライアント）、ピアターゲット（サーバ）を含む。
【０１３０】
（11req100300／11resp100200を介する）デバイス間情報交換11-Bは、デバイスが互いに直接対話可能とするためのものである。対話は例えば、ピアのペア関係がそれらの間で存在し、各々が、セキュリティキー、トンネル情報、ポート及びＩＰアドレス情報等を含み得る他方についての情報を有しているときのものである。
【０１３１】
全てのデバイスは、そのピアについての動的な設定にしたがって、リクエストを生成可能なクライアントの役割、能動的にリクエストをリスニングしてレスポンスを提供するサーバの役割、又はその両方で、動作可能である。
【０１３２】
図１２は、本開示の実施形態による、クローズドループ及びオープンループを示す図である。この例示的実施形態は、図１１に基づいており、図１１の全ての要素は図１２に組み入れられる。図１１に示されるクローズドループとは異なり、図１２は更に、（その特定のアクションに対し動的に許可される場合、）オープンアクセスフレームワークにおけるRESTfulなURLポスティングを示す。このポスティングは、リクエストREQ12R200及びレスポンスRESP12R200による、クエリ12R200からSRV_CNTRL200を介した未知のピアに対するものであってよい。例えば、URLとしてhttp://path.to/cntrl/time/checkを用いて、デバイスにより現在時刻を受信してよい。レスポンスはそのパスによって提供されるコンテンツにおいてエコーされる。レスポンスはプレーンテキスト、アレイ、キーと値とのペア、カプセル化されたアレイ、又は他のデータ表示であってよい。
【０１３３】
（REQ12R100と対応するRESP12R100とを介した）クエリ12R100は、EPD100に対するRESTfulなURLコールを示す。
【０１３４】
（REQ12R300と対応するRESP12R300とを介した）クエリ12R300は、SRV_AP300に対するRESTfulなURLコールを示す。
【０１３５】
実施形態において、ニュートラルなＡＰＩは可変アクセスポイント（例えばクローズドのみ、URLを介したオープンのみ、及びURLを介したクローズドとオープンの両方）を有してよい。実施形態では、オープン及び／又はクローズドなニュートラルなＡＰＩメカニズムに認証をリクエストしてよい。他の実施形態では、オープン及び／又はクローズドなニュートラルなＡＰＩメカニズムには認証をリクエストしなくてよい。
【０１３６】
実施形態では、RESTfulなニュートラルＡＰＩリクエスト／レスポンスにつき、そのURLアドレスを単に開くことによって情報が提供されてよいし、任意の情報が提供される前にリクエストクエリの一部として情報のポストがリクエストされてよい。例えば、時間を問い合わせるとき、リクエストを行うデバイスの正当なデバイスＩＤが、そのURLに対するデータのポストにおいて提示されるときだけ、SRV_CNTRL200は時間をエコーバックする。そうでなければ、デバイスが未知であることを示すメッセージと共にエラーが通知されてよいし、何らのメッセージ又はコンテンツがエコーバックされなくてよい。
【０１３７】
図１３は、本開示の実施形態による、リクエストペイロードにおける例示的トランザクションコードを示す図である。この例示的な実施形態は、クライアントによりサーバに対しニュートラルなＡＰＩ内で生成されたリクエストについての、例示的なトランザクションコード構造を示す。
【０１３８】
実施形態では、クライアントデータ13-AはTRC100、TRC200、及びTRC300を含む。サーバデータ13-BはTRC500を含む。リクエストトランザクションコードシーケンス13-REQは13-A及び13-Bを含む。Device_CodeTRC100は、クライアントの識別子を指す。Date_CodeTRC200は算出されてよいし、現在のUNIXタイムスタンプに基づいてもよい（UNIXタイムエポック時間又はPOSIX時間から数秒）。Transaction_CodeTRC300は、クライアントによって生成されるＡＰＩコールのシーケンシャルなレコードに基づく、世界的な一意の識別子（UUID）コードである。Device_CodeTRC500は、サーバのターゲット／宛先デバイスUUIDを指す。これらの値はハイフンによって分離され、角括弧によって囲まれ、又は、カプセル化されてこれらの値を示してよい。全てのコードについて、デバイス、時間又はトランザクションの整数値、関連付けられた名前、及び／又は、base-36のコンバージョン等の任意のものが使用されてよい。任意の他のデータ表示が用いられてよい。
【０１３９】
リクエストトランザクションコードシーケンス13-REQは全体的又は部分的に用いられて、ピアのペアを識別し、トランザクション番号を記録し、暗号／復号プロセスの一部として使用され、又は、他の目的で使用されてよい。
【０１４０】
図１４は、本開示の実施形態による、レスポンスペイロードにおける例示的トランザクションコードを示す図である。
【０１４１】
この例示的な実施形態は、サーバによりクライアントに対しニュートラルなＡＰＩメカニズム（NAPIM）内で生成されたレスポンス14-RESPについての、トランザクションコード構造を示す。これは、元のトランザクションコードTRC100／TRC200／TRC300／TRC500の基礎を含み、14-RESPの形式でピア（サーバ）によって回答されるＡＰＩコールのシーケンシャルレコードに基づいて、更にレスポンスの付加日付コードTRC600と、トランザクションコードTRC700（世界的な一意の識別子（UUID））との追加を伴う。図１４に示すように、レスポンストランザクションコードシーケンス14-PRESPは、クライアントデータ13-A及びサーバデータ14-Bを含む。クライアントデータ13-AはTRC100／TRC200／TRC300を含む。サーバデータ14-BはTRC500／TRC600／TRC700を含む。
【０１４２】
クライアントによって受信されると、元のTRC100、TRC200、TRC300及びTFC500要素はクライアントによって用いられ、返信された14-RESPの妥当性を確認すると共に、生成された元のリクエストとこの情報とを照合する。TRC600及びTRC700要素はまた、クライアントによってログを取られ、検証目的でレスポンスの詳細を記録してよい。
【０１４３】
レスポンストランザクションコードシーケンス14-RESPは全体的又は部分的に用いられて、ピアのペアを識別し、トランザクション番号を記録し、暗号／復号プロセスの一部として使用され、又は、他の目的で使用されてよい。
【０１４４】
図１５は、本開示の実施形態による、クローズドループでのリクエスト／レスポンスペイロードにおける例示的な要素マッピングを示す図である。この例示的な実施形態は、外部ペイロードにおけるアクションコードと内部ペイロードにおける拡張アクションコードとの関係を示す。これはまた、ニュートラルなＡＰＩメカニズムにおけるＡＰＩシーケンスの様々なステップでのアクションコード要素を、アクションコード／拡張アクションコードアイテムへマッピングする。これらのスクリプト、データベース及びアクションアイテムは、次の３つの段階で生じる。すなわち、段階STR1でのソースピア上（プレポスティング）、段階STR2での宛先ピア上（ポストされたリクエストを受信するとき）、及び、段階STR3でのソースピア上（返信されたレスポンスのポストを受信するとき）である。
【０１４５】
図１５に示す通り、実施形態では、ＡＰＩコールのリクエストMech012／レスポンスMech022は、ニュートラルなＡＰＩメカニズムのセキュアなフレームワークを介して、既知のピアと関連ピアとの間で生成される。NAPIMオペレーションMech100は、（Mech010を介した）Mech012及び（Mech010を介した）Mech022を含む。
【０１４６】
アクションコードは、外部ペイロードAC-Oに含まれる、公開のショートフォームである。拡張アクションコードは、暗号化された内部ペイロードAC-1に安全に含まれる、内部のロングフォームである。外部ペイロードから内部ペイロードを復号化するとき、これらのコードは互いに関連しなければならない。そうでなければ、中間者攻撃（MITM）、リプレイ攻撃、又は、ＡＰＩコールシーケンスを無効にする他の問題を意味する。これは、動作上且つ安全上の理由である。
【０１４７】
段階STR1のソースピア上（プレポスティング）で、ペイロードリクエストジェネレータスクリプトSTR1-02（その特定アクションについての内部ペイロードAC-1の構造）が準備され、集合し、次いで外部ペイロードAC-Oへと暗号化される。
【０１４８】
また、段階STR1のソースピア上（プレポスティング）で、リクエストペイロード構造定義（その特定アクションについての内部ペイロードAC-1構造）につきデータベース格納ペイロード定義STR1-04がここで定義され、特定のアクションに関連付けられる。これは、ペイロードの作成、有効性の確認、そのパース、及び、ＡＰＩコールの他の機能を支援する。
【０１４９】
段階NAPIM（リクエストのポストMech012）において、クライアントピアからリスニングサーバピアへのリクエストのポスティングが生じる。
【０１５０】
STR2で、宛先ピア上（ポストされたリクエストを受信するとき）では、ポストパーサ（構文解析プログラム）としてのスクリプトSTR2-02はPL01-OUTERをパースする（ジェネリックパーサへのリクエスト包含を処理する）。ジェネリックパーサは、外部ペイロードAC-Oにおけるアクションコードに基づいて支援パーサを含むことができる。PL01-INNERについてのデータベース格納ペイロード定義STR2-04は、PL01-INNERをパースするのに用いられてよい。スクリプトSTR2-06は、実行すべきアクションを処理する（実施形態では、STR2-06はサポートファイル、サポートモジュール及び／又はサポートクラス／機能を検索又は実行してよい）。ロガーSTR2-08はログをとる（ドゥーアラウンドアクションに対するロギング（logging to do around action）、及び／又は、アクションの記述、及び／又はアクションの記録）。スクリプトSTR2-10は、レスポンスペイロードPL02-OUTERをPL02-INNERから生成する（アクションに特化）。レスポンスペイロード構造PL02-INNER定義（アクションに特化）についてデータベース格納ペイロード定義STR2-12は、PL02-INNERを作成するのに用いられてよい。
【０１５１】
段階NAPIM（レスポンスのポストMech022）において、サーバピアから元クライアントピアへのレスポンスのポスティングバックが生じる。
【０１５２】
段階STR3にてソースピア上（返信されたレスポンスのポストを受信するとき）で、スクリプトSTR3-02はポストパーサとしてPL02-OUTERをパースし、PL02-INNERを分離する（ジェネリックパーサへのレスポンス包含を処理する）。データベース格納レスポンス／リクエスト結合ペイロード構造定義STR3-04が、PL02-INNERをパースするために用いられてよい。スクリプト3-06は、レスポンスPL02-INNERに含まれるアクションを処理する。ロガーSTR3-08はロギングを実行する。スクリプト3-10は、追加の新たなＡＰＩコールがトリガされる必要があるか否かを確認する。スクリプトSTR3-12は、ＡＰＩシーケンスのクロージング、終了、クリーンアップ、報告等を処理する。
【０１５３】
ニュートラルなＡＰＩメカニズムにおける、スクリプト、データベース格納ペイロード定義、定義されたアクションコード内で実行すべきアクション、アクションコードの他の要素についての上記した例は、他の要素と共に用いられて、１つのニュートラルなＡＰＩメカニズムフレームワークを通して、多様な範囲の多くの異なるアクションを実行してよい。
【０１５４】
図１６は、本開示の実施形態による、オープン／RESTfulループにおけるリクエスト／レスポンスペイロードでの例示的な要素マッピングを示す図である。この例示的な実施形態は、アクションURL変数AC-Pから抽出される変数のマッピングを示し、当該変数はURL変数と関連付けられるアクションを使用するためにアクションコードオープンAC-Uへとマッピングされる。これは、オープンURLのRESTfulな問合せを実行するためのニュートラルなＡＰＩメカニズムの一態様である。
【０１５５】
NAPIMオペレーションMech200は、（Mech210を介した）ポストされたパスのパースリクエストMech212と、（Mech220を介した）エコーレスポンスMech222とを含む。URLリクエストはパースされ、Mech212を介してURLから変数を抽出する。アクションURL変数は評価され、既知のアクションに関連付けられたアクションコードオープンAC-Uを検出する。
【０１５６】
実施形態では、URLリスナ及びパスパーサSTR5は次の要素を含む。スクリプトSTR5-02はパスパーサとして、ポストされたパス変数におけるアクションURL変数を識別する。データベース格納アクションコードオープンの構造定義（アクションに特化）STR5-04は、パースのために用いられてよい。スクリプトSTR5-06は、アクションを処理する。ロガーSTR5-08は、ロギングを実行する。スクリプトSTR5-10は、（アクション毎に）エコーすべきコンテンツを準備する。スクリプトSTR5-14は、このRESTFulなＡＰＩシーケンスのクロージング、終了、クリーンアップ、報告等を処理する。スクリプトSTR5-16は、URLパス上にポストされた変数においてオンＸトリガ（On-X-Trigger）をフック（hook）したか否かを確認する。
【０１５７】
STR5の上記の要素は、ニュートラルなＡＰＩメカニズムにおける定義されたアクションへとマッピングされるRESTfulなオープンリクエストを処理するために用いられる。全てが必要というわけではない。本例示的な実施形態で示されない他の要素が、１つの、多くの、又は全てのアクションに用いられてよい。結果はMech222を介してエコーバックされてよい。
【０１５８】
実施形態では、全ての各アクションがオープン／RESTfulなＡＰＩコールを介してアクセス可能というわけではない。これは、アクションごとに動的に定義され、多くの要因（元のURLパスリクエストから取得される変数以外のポストされた変数についての可能な条件を含む）に依存し又は依存されてよい。
【０１５９】
図１７は、本開示の実施形態による、ニュートラルなＡＰＩメカニズムによって使用される主なモジュール間の協働及び関係を示す図である。この例示的な実施形態は、デバイス間通信のための関連パスを含む、ニュートラルなＡＰＩメカニズムのコアモジュールを示す。
【０１６０】
示されるデバイスは、エンドポイントデバイスEPD100、中央制御サーバSRV_CNTRL200、及びアクセスポイントサーバSRV_AP300である。他のタイプのデバイスがNAPIMに加わり、互いに通信してよい。
【０１６１】
実施形態では、各ピアデバイス上で、情報リポジトリ（例えばEPD100上の情報リポジトリD193、SRV_AP300上の情報リポジトリD393）が存在する。各情報リポジトリは、関連データベース（例えばD193についてのB193や、D393についてのB393）を有してよい。全てのデバイスは、SRV_CNTRL200上の中央情報リポジトリD293からのＡＰＩコール又は他の情報伝達方法により、それらのローカル情報リポジトリに対する更新情報を受信してよい。この中央リポジトリD293は、関連データベースB293を有してよい。情報リポジトリD193／D293／D393は、ＡＰＩ／アクション情報（アクションに関連するスクリプト、アクションに関連する定義、（例えば可用性を示すフラグによる）アクションの可用性、（例えばアクションが推奨されていないことを示すフラグによる）アクションの非推奨性）を格納してよい。定義は、アクションのペイロード（例えばレスポンスペイロード及びリクエストペイロード）の作成及びパースを可能にしてよい。
【０１６２】
実施形態では、デバイスマネージャD191、D291及びD391は、データベースB191、B291及びB391等に格納される情報を有してよい。これは、デバイスが自身についての情報を有するためのものである。このことは、デバイスのセットアップ時に局所的に施されてよいし、デバイスの寿命にわたって施されてよい。またこのことは、SRV_CNTRL200への／からのＡＰＩコールによって施され又は更新されてよい。
【０１６３】
実施形態では、各デバイスは、NAPIMマネージャ（例えばEPD100上のD193、SRV_AP300上のD392、SRV_CNTRL200上のD292等）を有してよい。これらのマネージャは、NAPIMのフレームワークの動作を処理する。
【０１６４】
実施形態では、ＡＰＩアクションコード、スクリプト、クラス、定義、及び他の支援方法は、NAPIMマネージャによって管理される。当該管理は、メカニズムが最新であること又は依存関係が適切であることを保証することや、他の要素が機能して、NAPIMの円滑な動作を保証することを含む。
【０１６５】
実施形態では、デバイスからSRV_CNTRL200への更新は、PA1、PA2又は他の直接のP-2-CNTRLルート又はコールである。これはいずれかの端末から開始されてよい。
【０１６６】
実施形態では、CP03を介したTP01からTP02への通信パスは、EPD100とSRV_AP300との間のトラフィックを推し進めるトンネルを示す。又は、当該通信パスは、他のタイプの通信及び／又はデバイス間対話を示してよい。
【０１６７】
実施形態では、パスCP02は、デバイス間の直接トンネルを示してよいし、いずれかの方向のＡＰＩコールを示してよいし、EPD100とSRV_AP300との間の他のタイプの通信を示してよい。
【０１６８】
上記した９つのポイントは、可能な例示である。それ以上のものが可能であってよい。キーポイントは、動的に更新可能な、仮想的に無限な量のアクションと組み合わされたニュートラルなＡＰＩメカニズムにおける、強固な外部フレームワーク、ポスティング、リスニング、ハンドリング、及び他の側面が、すばらしい柔軟性を提供し、他方で同時に、そこでのＡＰＩフレームワーク及びピアの関係の多くの態様を、安全に自動化及び簡素化することができることである。
【０１６９】
本開示は、本明細書で記載される特定の実施形態による範囲に限定されない。実際、前述の記載及び添付図面によって、本開示の実施形態に加えて他の様々な実施形態及び変形例が当業者にとって自明である。したがって、そのような他の実施形態及び変形例は本開示の範囲内である。更に本開示は、少なくとも１つの特定の目的で、少なくとも１つの特定の環境における少なくとも１つの特定の実施形態の文脈で記載される。しかし、当業者であれば、その利便性は限定されないこと、及び、本開示は任意の数の目的のために任意の数の環境で有利に実装されてよいことを認識可能である。したがって、特許請求の範囲は、記載された本開示の最大限の範囲及び最大限の要旨に照らして解釈される。
【図１】
2018508067.tif 000003
【図２】
2018508067.tif 000004
【図３】
2018508067.tif 000005
【図４】
2018508067.tif 000006
【図５Ａ】
2018508067.tif 000007
【図５Ｂ】
2018508067.tif 000008
【図６】
2018508067.tif 000009
【図７】
2018508067.tif 000010
【図８】
2018508067.tif 000011
【図９】
2018508067.tif 000012
【図１０】
2018508067.tif 000013
【図１１】
2018508067.tif 000014
【図１２】
2018508067.tif 000015
【図１３】
2018508067.tif 000016
【図１４】
2018508067.tif 000017
【図１５】
2018508067.tif 000018
【図１６】
2018508067.tif 000019
【図１７】
2018508067.tif 000020
【国際調査報告】
2018508067.tif 000021
2018508067.tif 000022