(57)【要約】      （修正有）【課題】ホストプラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのシステムおよびプロトコルを提供する。【解決手段】システム１００において、複数のサービスプロバイダー、それらのサービス、それらのタイプ、およびそれらのパラメーターのセットに対応するメタデータを登録する。ラッパープロトコルを含む新しい統合アプリケーションは、６つの事前規定されたメソッドを含む。ホストプラットフォームは、複数の分野に渡る複数のサービスプロバイダーと内部的に接続し、統合アプリケーションのリクエストを実行し、標準フォーマットで出力する。ラッパープロトコルは、通信のフォーマットを標準化し、統合アプリケーションの末端における労力を低減する。プラットフォームのサービスプロバイダーのリストを増やす能力は、リクエスト生成および実行のためのメタデータに応じて、拡大する。【選択図】図１
2019125330.tif 000002
【特許請求の範囲】
【請求項１】
プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのプロトコルであって、該プロトコルは、
前記複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータを、前記プラットフォームに登録するプロセッサー実施工程と、
前記登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応するメタデータを、前記プラットフォームに登録するプロセッサー実施工程と、
前記登録されている複数のサービスプロバイダーのそれぞれの前記複数のサービスのそれぞれ用のパラメーターのセットに対応するメタデータを、前記プラットフォームに登録するプロセッサー実施工程と、
前記プラットフォームを介して、統合のための前記アプリケーションを提供するプロセッサー実施工程であって、前記アプリケーションは、ラッパープロトコルを有している、統合のための前記アプリケーションを提供するプロセッサー実施工程と、
メタデータベースのリクエストビルダーモジュールを用いて、前記アプリケーションの前記ラッパープロトコルを、前記複数のサービスの１つに特有のフォーマットに変換するプロセッサー実施工程であって、前記変換は、前記アプリケーションに対応する前記サービスプロバイダーおよび前記サービス用に登録された前記メタデータに基づいて実行される、前記アプリケーションの前記ラッパープロトコルを、前記複数のサービスの１つに特有の前記フォーマットに変換するプロセッサー実施工程と、
応答取得モジュールを用いて、前記ラッパープロトコルに対応する前記複数のサービスプロバイダーから、応答を取得するプロセッサー実施工程と、
応答標準化モジュールを用いて、前記複数のサービスプロバイダーからの前記応答を、前記ラッパープロトコルによって規定された標準フォーマットに変換するプロセッサー実施工程と、
統合モジュールを用いて、前記プラットフォームにおいて、前記アプリケーションに特有の前記フォーマットと前記標準フォーマットを統合するプロセッサー実施工程と、を含むことを特徴とするプロトコル。
【請求項２】
前記プラットフォームによって、前記複数のサービスプロバイダー用のライセンスデータを管理する工程をさらに含む請求項１に記載のプロトコル。
【請求項３】
前記プラットフォームにおいて、前記複数のサービスプロバイダーのライセンスのライセンスリポジトリを維持する工程をさらに含む請求項１に記載のプロトコル。
【請求項４】
前記ラッパープロトコルは、
前記複数のサービスプロバイダーのタイプを取得するためのメソッドと、
前記複数のサービスプロバイダーのリストを取得するためのメソッドと、
前記複数のサービスのリストを取得するためのメソッドと、
前記複数のサービスを提示するためのメソッドと、
前記複数のサービスのＵＲＬを取得するためのメソッドと、
ライセンスリポジトリにアクセスするためのメソッドと、からなる６つの事前規定されたメソッドを含む請求項１に記載のプロトコル。
【請求項５】
前記ラッパープロトコルは、ＲＥＳＴ（representational state transfer）プロトコルに従って作成されている請求項１に記載のプロトコル。
【請求項６】
前記複数の分野は、ビデオ会議開催、盗用、学習管理システムコンテンツ、およびヴァーチャル研究室の少なくとも１つである請求項１に記載のプロトコル。
【請求項７】
前記プラットフォームは、利用可能な前記複数のサービスプロバイダーの単一サインオン（ＳＳＯ）ロジックで構築されている請求項１に記載のプロトコル。
【請求項８】
前記プラットフォームは、プラットフォームプロバイダーによってホスティングされている請求項１に記載のプロトコル。
【請求項９】
プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのシステムであって、該システムは、
登録モジュールであって、
前記複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータを、前記プラットフォームに登録し、
前記登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応するメタデータを、前記プラットフォームに登録し、さらに、
前記登録されている複数のサービスプロバイダーのそれぞれの前記複数のサービスのそれぞれ用のパラメーターのセットに対応するメタデータを、前記プラットフォームに登録するよう構成された、登録モジュールと、
前記プラットフォームを介して、統合のためのアプリケーションを提供するためのＡＰＩインターフェースであって、前記アプリケーションは、ラッパープロトコルを有する、ＡＰＩインターフェースと、
メモリーと、
前記メモリーと通信を行うプロセッサーと、を含み、
前記プロセッサーは、
前記アプリケーションの前記ラッパープロトコルを、前記複数のサービスの１つに特有のフォーマットに変換するためのメタデータベースのリクエストビルダーモジュールであって、前記変換は、前記アプリケーションに対応する前記サービスプロバイダーおよび前記サービス用に登録された前記メタデータに基づいて実行される、メタデータベースのリクエストビルダーモジュールと、
前記ラッパープロトコルに対応する前記複数のサービスプロバイダーから、応答を取得するための応答取得モジュールと、
前記複数のサービスプロバイダーからの前記応答を、前記ラッパープロトコルによって規定された標準フォーマットに変換するための応答標準化モジュールと、
前記プラットフォームにおいて、前記アプリケーションに特有の前記フォーマットと前記標準フォーマットを統合するための統合モジュールと、をさらに含むことを特徴とするシステム。
【請求項１０】
前記複数のサービスプロバイダーのライセンスを管理するためのライセンス管理モジュールをさらに含み、
前記ライセンス管理モジュールは、前記ラッパープロトコルの６つの事前規定されたメソッドの１つを介して、アクセス可能に構成されている請求項９に記載のシステム。
【請求項１１】
前記複数のサービスプロバイダーのライセンスを保存するためのライセンスリポジトリをさらに含む請求項９に記載のシステム。
【請求項１２】
プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのコンピュータープログラムを具体化している非一時的コンピューター可読媒体であって、前記コンピュータープログラムは、
前記複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータを、前記プラットフォームに登録するプロセッサー実施工程と、
前記登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応するメタデータを、前記プラットフォームに登録するプロセッサー実施工程と、
前記登録されている複数のサービスプロバイダーのそれぞれの前記複数のサービスのそれぞれ用のパラメーターのセットに対応するメタデータを、前記プラットフォームに登録するプロセッサー実施工程と、
前記プラットフォームを介して、統合のための前記アプリケーションを提供するプロセッサー実施工程であって、前記アプリケーションは、ラッパープロトコルを有している、統合のための前記アプリケーションを提供するプロセッサー実施工程と、
メタデータベースのリクエストビルダーモジュールを用いて、前記アプリケーションの前記ラッパープロトコルを、前記複数のサービスの１つに特有のフォーマットに変換するプロセッサー実施工程であって、前記変換は、前記アプリケーションに対応する前記サービスプロバイダーおよび前記サービス用に登録された前記メタデータに基づいて実行される、前記アプリケーションの前記ラッパープロトコルを、前記複数のサービスの１つに特有の前記フォーマットに変換するプロセッサー実施工程と、
応答取得モジュールを用いて、前記ラッパープロトコルに対応する前記複数のサービスプロバイダーから、応答を取得するプロセッサー実施工程と、
応答標準化モジュールを用いて、前記複数のサービスプロバイダーからの前記応答を、前記ラッパープロトコルによって規定された標準フォーマットに変換するプロセッサー実施工程と、
統合モジュールを用いて、前記プラットフォームにおいて、前記アプリケーションに特有の前記フォーマットと前記標準フォーマットを統合するプロセッサー実施工程と、のためのコンピュータープログラムを含むことを特徴とする非一時的コンピューター可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願への相互参照および優先権
本出願は、２０１８年１月１２日付けで出願されたインド国特許出願第２０１８２１００１４１６号に基づく優先権を主張し、該出願の全ての開示の全体が、参照によりここに援用される。
【０００２】
本発明は、一般的に、共通プラットフォームでの複数のベンダーの統合の分野に関し、より具体的には、共通プラットフォームを用いて、様々な分野に渡って複数のサービスを提供する複数のサービスプロバイダーを統合するためのシステムおよびプロトコルに関する。
【背景技術】
【０００３】
最近２０〜３０年間の情報技術の急速な進化は、オンラインサービスプロバイダーの数および彼らの製品数の何倍もの増加をもたらしている。会社・法人も、これらの製品の使用に、より大きく依存するようになってきている。学習管理システム、盗用の検出、通信、ビデオ等に関する製品のように、組織により多く関連する様々な製品が存在する。もし、これら製品の使用およびアクセスを、１つの場所において可能とすることができる単一のプラットフォームまたはフレームワークが存在したならば、組織にとって、その利益は膨大なものとなるであろう。これら製品の統合を可能とするために、ソフトウェアが利用可能であることは良く知られている。本分野において、複数の製品を統合するために、いくつかの方法が用いられている。
【０００４】
既存の技術は、製品ベースのサービスを提供する各マーケットプレイヤーを統合するカスタム統合（custom integration）を含んでいる。複数のベンダーの統合のために、コーダー（coder：プログラムを書く人）は、プログラムコードを複数回書かなければならず、さらに、これに加えて、複数のベンダーの統合のために、各製品に対する詳細な検討が必要となる。さらに、以前の複数のフレームワークは、複数の異なるベンダーを１つ１つ統合することができ、以前の複数のフレームワークを用いるアプリケーション開発者に対して、プラットフォーム／標準（スタンダード）についての多くを提供している。これらの方法は、コーダーの多大な時間と労力を消費するものである。
【０００５】
これに加えて、エンドユーザーのビジネスモデルに応じて工夫し、フレームワーク内でのライセンス管理のようなサービスを提供するプレイヤーもいない。統合レイヤーによって管理される共通ライセンス管理モジュールも存在しない。様々な製品の複数のライセンスを管理することは、やはり、困難だが挑戦的なタスクであり、労力と時間を要するものである。十分な労力および時間を投資することなく、繰り返して使用可能な、明確に定義されたプラットフォームまたはフレームワークは、存在していない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
実施形態の基本的な理解を提供するために、本開示のいくつかの実施形態の簡略化された概要が、以下に提供される。本概要は、実施形態の詳細な概説ではない。また、本概要は、実施形態の極めて重要な／決定的な要素を特定したり、実施形態の範囲を正確に記述したりする意図はない。そのただ１つの目的は、以下に提供されるより詳細な説明の前段階として、簡略化された様態で、いくつかの実施形態を提供することにある。
【０００７】
前述の事情を鑑み、本発明の実施形態は、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのシステムを提供する。システムは、登録モジュールと、ＡＰＩインターフェースと、メモリーと、プロセッサーと、を含む。登録モジュールは、複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータを、プラットフォームに登録する。メタデータは、プラットフォームに登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応しており、さらに、メタデータは、プラットフォームに登録されている複数のサービスプロバイダーのそれぞれの複数のサービスのそれぞれ用のパラメーターのセットに対応している。ＡＰＩインターフェースは、プラットフォームを介して、統合のためのアプリケーションを提供する。ここで、該アプリケーションは、ラッパー（wrapper）プロトコルを有している。プロセッサーは、メタデータベースのリクエストビルダー（metadata based request builder）モジュールと、応答取得モジュールと、応答標準化モジュールと、統合モジュールと、をさらに含む。メタデータベースのリクエストビルダーモジュールは、アプリケーションのラッパープロトコルを、複数のサービスの１つに特有のフォーマットに変換する。ここで、該変換は、アプリケーションに対応するサービスプロバイダーおよびサービス用に登録されたメタデータに基づいて実行される。応答取得モジュールは、ラッパープロトコルに対応する複数のサービスプロバイダーから、応答を取得する。応答標準化モジュールは、複数のサービスプロバイダーからの応答を、ラッパープロトコルによって規定された標準フォーマットに変換する。統合モジュールは、プラットフォームにおいて、アプリケーションに特有のフォーマットと標準フォーマットを統合する。
【０００８】
本発明の実施形態の別の態様は、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するための方法を提供する。最初に、複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータを、プラットフォームに登録する。同時に、登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応するメタデータが、プラットフォームに登録され、さらに、登録されている複数のサービスプロバイダーのそれぞれの複数のサービスのそれぞれ用のパラメーターのセットに対応するメタデータが、プラットフォームに登録される。次の工程において、プラットフォームを介して、統合のためのアプリケーションが提供される。ここで、該アプリケーションは、ラッパープロトコルを有している。次の工程において、メタデータベースのリクエストビルダーを用いて、アプリケーションのラッパープロトコルが、複数のサービスの１つに特有なフォーマットに変換される。ここで、該変換は、アプリケーションに対応するサービスプロバイダーおよびサービス用に登録されたメタデータに基づいて実行される。次の工程において、応答取得モジュールを用いて、応答が、ラッパープロトコルに対応する複数のサービスプロバイダーから、取得される。その後、応答標準化モジュールを用いて、複数のサービスプロバイダーから取得された応答が、ラッパープロトコルによって規定された標準フォーマットに変換される。そして最後に、統合モジュールを用いて、プラットフォームにおいて、アプリケーションに特有のフォーマットと標準フォーマットとが統合される。
【０００９】
別の実施形態において、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのコンピュータープログラムを具体化（embodied）している非一時的コンピューター可読媒体（non-transitory computer-readable medium）が提供される。最初に、複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータを、プラットフォームに登録する。同時に、登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応するメタデータが、プラットフォームに登録され、さらに、登録されている複数のサービスプロバイダーのそれぞれの複数のサービスのそれぞれ用のパラメーターのセットに対応するメタデータが、プラットフォームに登録される。次の工程において、プラットフォームを介して、統合のためのアプリケーションが、提供される。ここで、該アプリケーションは、ラッパープロトコルを有している。次の工程において、メタデータベースのリクエストビルダーを用いて、アプリケーションのラッパープロトコルが、複数のサービスの１つに特有なフォーマットに変換される。ここで、該変換は、アプリケーションに対応するサービスプロバイダーおよびサービス用に登録されたメタデータに基づいて実行される。次の工程において、応答取得モジュールを用いて、応答が、ラッパープロトコルに対応する複数のサービスプロバイダーから、取得される。その後、応答標準化モジュールを用いて、複数のサービスプロバイダーから取得された応答が、ラッパープロトコルによって規定された標準フォーマットに変換される。そして最後に、統合モジュールを用いて、プラットフォームにおいて、アプリケーションに特有のフォーマットと標準フォーマットが統合される。
【００１０】
本明細書中の任意のブロック図は、本発明の原理を具体化する例示的なシステムの概念図を表すものであることは、本分野における当業者によって適切に理解されるべきである。同様に、任意のフローチャート、フロー図、状態遷移図、疑似コード等は、コンピューター可読媒体内において実質的に表現することができ、さらに、演算デバイスまたはプロセッサーが明示的に示されているか否かに関係なく、演算デバイスまたはプロセッサーによって実行可能な様々な処理を表していることは理解されるであろう。
【図面の簡単な説明】
【００１１】
本発明の実施形態は、以下に述べる図面を含む添付の図面を参照した以下の詳細な説明から、より良く理解されるであろう。
【００１２】
【図１】図１は、本発明の実施形態に係る、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーを統合するためのシステムのブロック図を示している。
【００１３】
【図２】図２は、本発明の実施形態に係るシステムの概念アーキテクチャ図を示している。
【００１４】
【図３Ａ】図３Ａは、本発明の実施形態に係る、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーを統合するためのプロトコルに含まれる工程を示すフローチャートである。
【図３Ｂ】図３Ｂは、本発明の実施形態に係る、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーを統合するためのプロトコルに含まれる工程を示すフローチャートである。
【発明を実施するための形態】
【００１５】
本発明の実施形態、並びに、それらの様々な特徴および利点が、添付の図面に示され、さらに、以下の記述において詳細に述べられている非限定的な実施形態を参照して、より十分に説明される。本明細書で用いられている例は、本明細書中の実施形態が実施可能となり、さらに、本分野における当業者が、本明細書中の本実施形態を実施可能となるような理解を容易にするためだけの意図で提供される。したがって、例は、本発明の実施形態の範囲の限定を構成するものではない。
【００１６】
用語解説−実施形態において用いられる用語
本開示の文脈における「複数のサービスプロバイダー」、「サービスプロバイダー」、または「ベンダー」との表現は、「複数のサービス」または「製品」を提供する主体を意味する。さらに、これらのサービスは、本システムを介して呼び出される。
【００１７】
本開示の文脈における「分野（domain）」または「ベンダータイプ（vendor types）」との表現は、ベンダーのサブカテゴリー、それらのサービスが提供されている領域または分野を意味する。例えば、「ブラウザーベースのビデオ会議開催」は、分野の１つである。
【００１８】
本開示の文脈における「アプリケーション」、「統合アプリケーション」、または「ウェブアプリケーション」は、本プロトコルを用いて、既存の複数のサービスと統合されるべきアプリケーションを意味する。
【００１９】
ここで、図面、より具体的には、図１から図３を参照すると、各図を通して対応する特徴には、同様の参照番号が一貫して付されており、各図において、好ましい実施形態が示され、これら実施形態が、以下の例示的なシステムおよび／または方法の文脈において記述される。
【００２０】
本開示の実施形態に係る、プラットフォーム１０２を用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのシステム１００が、図１に示されている。プラットフォーム１０２は、プラットフォーム所有者によって提供される。また、本開示において、プラットフォームを、ホストプラットフォーム（hosted platform）と称することができる。システム１００は、共通プロトコルを用いて、複数のサービスプロバイダーを統合するためのメタデータベースのアプローチを提供する。共通プロトコルは、サポートされている分野内において、複数のサービスを提供する複数のサービスプロバイダーのそれぞれに対するカスタム統合のための労力を減らす。システム１００は、複数の同様の製品／サービスに渡るラッパープロトコル（wrapper protocol）を規定することにより、複数の同様の製品（ビデオ、学習、盗用の検出等）に渡る統合アプローチを標準化するよう構成されている。また、本開示の１つの例において、システム１００を、ｉＯＮサードパーティーフレームワークおよびプロトコル（ｉＯＮ  ＴＰＦＰ：iON Third Party Framework and Protocol）と称することができる。ｉＯＮ  ＴＰＦＰは、クラウドベースのフレームワークである。また、システム１００は、動的リクエストの生成を含んでおり、このプロトコルは、任意のサービスプロバイダーに拡張可能である。
【００２１】
本開示の実施形態によれば、図１のブロック図に示されているように、システム１００は、登録モジュール１０４と、ＡＰＩインターフェース１０６と、メモリー１０８と、プロセッサー１１０と、をさらに含む。プロセッサー１１０は、メモリー１０８と通信して機能する。プロセッサー１１０は、複数のモジュールをさらに含む。複数のモジュールは、メモリー１０８内に保存されているアルゴリズムのセットにアクセスし、特定のタスクを実行する。プロセッサー１１０は、メタデータベースのリクエストビルダー（metadata based request builder）モジュール１１２と、応答取得モジュール１１４と、応答標準化モジュール１１６と、統合モジュール１１８と、をさらに含む。
【００２２】
本開示の実施形態によれば、登録モジュール１０４は、ホストプラットフォーム１０２に、３種類のメタデータを登録するよう構成されている。すなわち、３種類のメタデータは、１．プラットフォーム１０２上の複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータ、２．プラットフォーム１０２上の登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応し、複数のサービスコンポーネントを含むメタデータ、および３．プラットフォーム１０２上の登録されている複数のサービスプロバイダーのそれぞれの複数のサービスのそれぞれ用のパラメーターのセットに対応するメタデータである。また、システム１００は、複数のサービスをグループ化するよう構成されており、さらに、同様のサービスを提供する複数の製品に渡る同じタイプのサービスの全ての標準化された入力および出力をグループ化するよう構成されている。システム１００と一体化される任意のアプリケーションが、多くの製品を統合する準備を行う。この製品リポジトリ（repository：ソフトウェア設計情報のデータベース）は、拡張に伴う増加を維持することになる。
【００２３】
本開示の実施形態によれば、アプリケーション・プログラミング・インターフェース（ＡＰＩ）インターフェース１０６は、システム１００への入力を提供するよう構成されている。ＡＰＩインターフェース１０６は、プラットフォームを介して、統合のためのアプリケーションを提供するよう構成されている。アプリケーションは、統合アプリケーションである。統合アプリケーションは、誰によっても構築されることができ、任意の技術によって構築されることができ、さらに、任意のフレームワークによって構築されることができる。よって、システム１００は、技術に依存せず、さらに、フレームワークに依存しない。ＡＰＩインターフェース１０６は、例えば、ウェブインターフェース、グラフィカルユーザーインターフェース等の様々なソフトウェアおよびハードウェアインターフェース等を含み得、さらに、有線ネットワーク（例えば、ＬＡＮ、ケーブル等）および無線ネットワーク（ＷＬＡＮ、セルラー、衛星等）を含む広範な種類のネットワークＮ／Ｗおよびプロトコルタイプにおける相互通信を容易にすることができる。
【００２４】
本開示の実施形態によれば、統合アプリケーションは、ラッパープロトコルを含む。このような統合に関するアプリケーションは、明確に定義され、再現性のある、解決のための標準（standard）を有している。ラッパープロトコルは、６つの事前規定されたメソッドをさらに含んでいる。これら６つの事前規定されたメソッドは、複数のサービスプロバイダーのタイプを取得するためのメソッド、複数のサービスプロバイダーのリストを取得するためのメソッド、複数のサービスのリストを取得するためのメソッド、複数のサービスを提示（post）するためのメソッド、複数のサービスのＵＲＬを取得するためのメソッド、およびライセンスリポジトリにアクセスするためのメソッドである。６つの事前規定されたメソッドのそれぞれは、ＨＴＴＰ  ＲＥＳＴ（REpresentational State Transfer：分散ハイパーメディアシステムのためのソフトウェアアーキテクチャスタイルの１つ）  ＵＲＬとして利用可能である。また、本開示の例において、６つの事前規定されたメソッドを、それぞれ、ＧｅｔＶｅｎｄｏｒＴｙｐｅｓ、ＧｅｔＶｅｎｄｏｒＬｉｓｔ、ＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＬｉｓｔ、ＰｏｓｔＶｅｎｄｏｒＳｅｒｖｉｃｅ、ＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＵＲＬ、およびＬｉｃｅｎｓｅＭｇｍｔと称することができる。これらメソッドは、本開示の後の部分において、詳細に説明される。
【００２５】
本開示の実施形態によれば、プロセッサー１１０は、メタデータベースのリクエストビルダーモジュール１１２を含む。メタデータベースのリクエストビルダーモジュール１１２は、アプリケーションのラッパープロトコルを、複数のサービスの１つに特有のフォーマットに変換するよう構成されている。ここで、該変換は、統合アプリケーションに対応するサービスプロバイダーおよびサービスのために登録されたメタデータに基づいて実行される。メタデータベースのリクエストビルダーモジュール１１２は、ラッパープロトコルのフォーマットでの入力を、ＲＥＳＴ（Representational State Transfer）でのＪＳＯＮ（JavaScript（登録商標） Object Notation）形式のキー値ペア（key value pairs）として取得する。
【００２６】
本開示の実施形態によれば、プロセッサー１１０は、応答取得モジュール１１４と、応答標準化モジュール１１６と、をさらに含む。応答取得モジュール１１４は、ラッパープロトコルに対応する複数のサービスプロバイダーから、応答を取得する。一方、応答標準化モジュール１１６は、複数のサービスプロバイダーから取得した応答を、ラッパープロトコルによって規定された標準フォーマットに変換する。本開示の別の実施形態において、応答標準化モジュール１１６も、応答を取得するよう構成されていてもよいことは、理解されるべきである。さらに、統合モジュール１１８は、プラットフォーム１０２内において、標準フォーマットと、アプリケーションに特有のフォーマットとを統合する。よって、ｉＴＰＦＰは、ごく少数のタイプのトランザクションのために、複数のサービスプロバイダーと通信を行い、統合アプリケーションがラッパープロトコルに従うものであれば、その後、統合アプリケーションの所有者は、それらを統合するために、ベンダーのセットを知る必要がない。よって、プログラムを書く代わりに、統合アプリケーションは、多数のサービスプロバイダーと、途切れなく、相互通信を行うことができる。
【００２７】
本開示の実施形態によれば、システム１００は、ライセンス管理モジュール１２０をさらに含む。ライセンス管理モジュール１２０は、複数のサービスプロバイダーのライセンスおよび対応データを管理するよう構成されている。ライセンス管理モジュール１２０は、ラッパープロトコルの６つの事前規定されたメソッドの１つを介してアクセス可能に構成されている。また、ライセンス管理モジュール１２０は、複数のサービスプロバイダーのライセンスを保存するためのライセンスリポジトリ１２２を保持している。ライセンスリポジトリ１２２は、キー値ペアのリポジトリ（ＡＰＩ上に露出している）を有することができる。ここで、エンドユーザーは、複数のキー値（ライセンスコード、登録済みメール、アプリケーションＩＤ等）を、ベンダーリストの中のベンターに対して登録することができる。また、任意のライセンスパラメーター（例えば、登録されたメールＩＤ、アプリケーションＩＤ、管理認証情報等）が取得されてもよく、さらに、任意のライセンスパラメーターが、ｉＯＮ  ＴＰＦＰを通り、サードパーティー商品との統合を行うために、用いられてもよい。
【００２８】
本開示の実施形態によれば、システム１００は、コーダーの統合労力を大幅に減らす。また、システム１００は、プラットフォーム１０２と既に統合されている複数のベンダーの準備リポジトリ（ready repository）を提供する。よって、労力の削減に加えて、統合アプリケーションは、同様に統合された複数の製品を迅速に取得するという観点からも、付加価値を取得している。
【００２９】
本開示の実施形態によれば、図２に示すような概念アーキテクチャを活用して、システム１００を説明することができる。図２中の図表は、３つのタイプのサービスプロバイダー、すなわち、ビデオ会議開催ベンダー、盗用ベンダー、およびコンテンツ管理ベンダーを参照して、説明される。プラットフォーム１０２によって登録され得る様々なベンダーが存在し得る。統合される必要がある全てのアプリケーションが、左手側に記載されている。また、全ての統合アプリケーションが、ライセンス管理モジュール１２０と通信可能となっている。ライセンス管理モジュール１２０は、統合アプリケーションに必要な全てのライセンス情報を提供することができる。全ての統合アプリケーションは、ＲＥＳＴ／ＪＳＯＮプロトコルに従って（over REST/JSON protocol）構築される。統合アプリケーションは、メタデータベースのリクエストビルダーモジュール１１２に対する入力を提供可能である。ベンダーのタイプに応じて、複数のベンダーのそれぞれ用のカスタムリクエストが送信される。カスタムリクエストは、複数のベンダーのリポジトリに送信される。このリポジトリは、登録されている複数のサービスプロバイダーのメタデータの全てを有している。カスタム出力が、複数のベンダーのそれぞれから受信され、その後、カスタム出力が、応答標準化モジュール１１６に提供される。その後、応答標準化モジュール１１６は、統合アプリケーションの統合に利用可能な標準フォーマットで、出力を提供する。
【００３０】
動作において、図３Ａ−３Ｂに示されているように、フローチャート２００は、プラットフォーム１０２を用いて、複数の分野に渡る複数のサービスプロバイダーと統合アプリケーションを統合するためのプロトコルの工程を示している。最初に、工程２０２において、複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータが、プラットフォーム１０２に登録される。同様に、工程２０４において、登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応するメタデータが、プラットフォーム１０２に登録され、さらに、工程２０６において、登録されている複数のサービスプロバイダーのそれぞれの複数のサービスのそれぞれ用のパラメーターのセットに対応するメタデータが、プラットフォーム１０２上に登録される。
【００３１】
次の工程２０８において、統合アプリケーションが、プラットフォーム１０２を介して、統合のために提供される。統合アプリケーションは、ラッパープロトコルを有している。ラッパープロトコルは、６つの事前規定されたメソッドを含んでいる。ラッパープロトコルを用いて、任意のアプリケーションは、ホストプラットフォーム１０２と通信を行うことができ、さらに、ホストプラットフォーム１０２は、続いて、複数の分野に渡る複数のサービスプロバイダーと内部的に接続することによって、統合アプリケーションのリクエストを実行し、さらに、標準フォーマットで、出力を提供することができる。
【００３２】
次の工程２１０において、メタデータベースのリクエストビルダーモジュール１１２を用いて、アプリケーションのラッパープロトコルが、複数のサービスの１つに特有のフォーマットに変換される。この変換は、アプリケーションに対応するサービスプロバイダーおよびサービス用に登録されたメタデータに基づいて実行される。工程２１２において、応答取得モジュール１１４を用いて、ラッパープロトコルに対応する複数のサービスプロバイダーからの応答が、取得される。次の工程２１４において、応答標準化モジュール１１６を用いて、複数のサービスプロバイダーから取得された応答が、ラッパープロトコルによって規定された標準フォーマットに変換される。最後に、工程２１６において、プラットフォーム１０２内において、標準フォーマットと、アプリケーションに特有のフォーマットとが統合される。ラッパープロトコルは、通信（入力＆出力）の形式／フォーマットを規定／標準化するので、統合アプリケーションの終端（the end of the integrating application）における労力が実質的に低減される。
【００３３】
また、本開示の別の実施形態によれば、システム１００またはｉＴＰＦＰを、以下の例を用いて説明することができる。本開示の現在のバージョンにおいて、ｉＴＰＦＰは、４つの分野に渡る７つのベンダーによって提供される２０タイプのサービスをサポートしている。本開示は、将来の拡張および開発を含むさらなる範囲も有していることは、理解されるべきである。４つの分野は、ビデオ会議開催、ＬＭＳ（Learning Management System:学習管理システム）コンテンツ管理、盗用、およびヴァーチャル研究室を含む。表Ｉは、システム１００によってサポートされている複数のサービスのリストを示している。
表Ｉ
2019125330.tif 000003
2019125330.tif 000004
2019125330.tif 000005
【００３４】
表２は、システム１００によってサポートされている複数のサービスプロバイダーのリストを示している。
表ＩＩ
2019125330.tif 000006
【００３５】
上で説明したように、ラッパープロトコルは、６つの事前規定されたメソッドを有している。これらメソッドの全ては、ＨＴＴＰ  ＲＥＳＴ  ＵＲＬｓとして利用可能である。全ての相互通信は、これら６つのメソッドを介してのみ実行される。入力／出力は、いくつかの場合において変化し得る（起動される「ベンダーサービス」のタイプに応じて変化し得る）。いくつかのメソッドは、メタデータベースであり、公に利用可能である。一方、いくつかのメソッドは、メタデータベースではなく、ｉＴＰＦＰライセンスが必要であり、登録された分野から呼び出されることが必要である。６つの事前規定されたメソッドは、以下の通りである。
【００３６】
ＧｅｔＶｅｎｄｏｒＴｙｐｅｓ（メタデータベース）：このメソッドは、ＪＳＯＮ出力として、ｉＴＰＦＰの現在のバージョンにおいてサポートされている「分野」のリストを提供する。
【００３７】
ＧｅｔＶｅｎｄｏｒＬｉｓｔ（メタデータベース）：このメソッドは、ＪＳＯＮ出力として、ｉＴＰＦＰの現在のバージョンにおいてサポートされているベンダーのリストを提供する。
【００３８】
ＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＬｉｓｔ（メタデータベース）：このメソッドは、ＪＳＯＮ出力として、特定のベンダーとの相互通信のために利用可能なベンダーサービスのリストを提供する（本メソッドは、動作のための入力として、ベンダーＩＤまたはベンダータイプＩＤを必要とする）。
【００３９】
ＰｏｓｔＶｅｎｄｏｒＳｅｒｖｉｃｅ（メタデータベースではない）：このメソッドは、通過したサービスを起動した後に、入力として、入力ＪＳＯＮ（ベンダーのタイプおよび起動されているベンダーのサービスによって変化する）を受け付け、標準出力ＪＳＯＮを与える。このメソッドは、標準入力／出力を介して、サードパーティベンダーのサービスを起動する実際のタスクを実行する。このメソッドのための入力／出力フォーマットは、各分野のサービス毎に事前に規定されており、これは、例えば、任意のサポートされている盗用ベンダーのテキストファイルスキャン用のＰｏｓｔＶｅｎｄｏｒＳｅｒｖｉｃｅフォーマットが同じものであり、プロトコル仕様書内において規定されていることを意味する。
【００４０】
ＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＬｉｓｔ（メタデータベースではない）：このメソッドは、ＪＳＯＮ入力（ベンダーのタイプおよび起動されているベンダーのサービスによって変化する）を受け付け、ポストパラメーターと共に、完全形式ＵＲＬを返す。このＵＲＬは、統合アプリケーションによって直接呼び出され、ベンダーと直接接続することによって、ベンダーサービスを起動する。しかしながら、この場合、出力は標準化されない。
【００４１】
ＬｉｃｅｎｓｅＭｇｍｔ：１．Ｄｅｆａｕｌｔ（メタデータベース）：「ＬｉｃｅｎｓｅＭｇｍｔ」メソッドは、パラメーター無しで呼び出された場合、ベンダーのリストと、必要なライセンスパラメーター（例えば、秘密鍵、パスワード、登録されたｅメール等）を与え、これらベンダーとの認証を行う。２．Ｗｉｔｈ  ｉＴＰＦＰ  Ｌｉｃｅｎｓｅ（メタデータベースではない）：このメソッドは、ｉＴＰＦＰライセンス情報と共に呼び出された場合、あなたのライセンスパラメーターをフェッチおよび保存するよう機能する。
【００４２】
さらなる既述のために、プロトコルの事前規定されたメソッドの組が以下に提供される。実際のＵＲＬ、ＪＳＯＮ入力／出力は、詳細に提供されている。
【００４３】
メソッド仕様書
ＧｅｔＶｅｎｄｏｒＴｙｐｅｓ（メタデータベース）
説明：ｉＴＰＦＰの現在のバージョンにおいてサポートされている「分野」のリストを返す。
ＵＲＬ：www.tcsion.com/LX/iONThirdPartyFwNProtocol/GetVendorTypesを入手
ＵＲＬパラメーター：なし
タイプ：これは、公に使用可能にオープンにされたサービスであり、如何なるサブスクリプションも必要としない。
出力：フォーマット：ＪＳＯＮ
サンプル：
［｛“ベンダー＿コンセプト＿マスター＿ｉｄ”：１，“名前”：“盗用”｝，
｛“ベンダー＿コンセプト＿マスター＿ｉｄ”：２，“名前”：“コンテンツ”｝，
｛“ベンダー＿コンセプト＿マスター＿ｉｄ”：３，“名前”：“会議”｝］
属性：
１．ベンダー＿コンセプト＿マスター＿ｉｄ  −「ベンダータイプ」／「分野」のユニーク識別子
２．名前  −分野の名前
ＰｏｓｔＶｅｎｄｏｒＳｅｒｖｉｃｅ（メタデータベースではない）
説明：このメソッドは、通過したサービスを起動した後に、入力として、入力ＪＳＯＮ（ベンダーのタイプおよび起動されているベンダーのサービスによって変化する）を受け付け、標準出力ＪＳＯＮを与える。
ＵＲＬ：ＰＯＳＴ  
www.tcsion.com/LX/iONThirdPartyFwNProtocol/PostVendorService?service_id=x&org_id=y&license_code=z
ＵＲＬパラメーター：
サービス＿ｉｄ  −特定のベンダー（ＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＬｉｓｔメソッドを介してフェッチされたベンダー）のサービスのタイプのユニークな識別子。
ｏｒｇ＿ｉｄ  −ｉＯＮ（www.tcsion.com）に承認されたときに統合アプリケーションのＯｒｇに提供されるユニークな識別子。
ライセンス＿コード  −ｉＴＰＦＰを用いた統合アプリケーションに提供されるライセンスであり、特定のウェブサイト分野のみを有効化する。
ＰＯＳＴパラメーター：ＪＳＯＮが、ＵＲＬと共に、（提示コンテンツにおいて）提示される。このＪＳＯＮは、サービスのタイプによって変化するが、１つの分野内の複数のベンダーの間では一定である。
タイプ：これは、ＳＡＳモデル上のｉＯＮ（www.tcsion.com）によって提供されるサービスであり、サブスクリプションを必要とする。
例１：盗用ベンダーのための画像スキャン
ＲＥＳＴパラメーター
＜サービス＿ｉｄ＞  →任意のサポートされている盗用ベンダーのサービスのＩＤである。ここで、サービス＿名前＝“画像スキャン”（同じプロトコルのメソッドＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＬｉｓｔからのもの）
＜ｏｒｇ＿ｉｄ＞＆＜ライセンス＿コード＞  →統合アプリケーションに提供されたｉＴＰＴＰライセンスパラメーター
（ＰＯＳＴにおける）ＪＳＯＮフォーマット  →｛‘トークン’：‘有効化認証トークン’，‘ファイル’：‘スキャンすべきファイルのＵＲＬ／経路’｝）
出力
｛“ファイル名”：“＜提出されたファイルの名前＞”，“プロセスＩｄ”：“＜あなたが開始したスキャンプロセスの識別子＞”，“ＣｒｅａｔｉｏｎＴｉｍｅＵＴＣ”：“＜タイムスタンプ＞”｝
例２．任意の盗用ベンダーへのあなたの提出されたファイルのフェッチステータス
ＲＥＳＴパラメーター
＜サービス＿ｉｄ＞  →任意のサポートされている盗用ベンダーのサービスのＩＤである。ここで、サービス＿名前＝“ステータス”（同じプロトコルのメソッドＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＬｉｓｔからのもの）
＜ｏｒｇ＿ｉｄ＞＆＜ライセンス＿コード＞  →統合アプリケーションに提供されたｉＴＰＴＰライセンスパラメーター
（ＰＯＳＴにおける）ＪＳＯＮフォーマット  →｛‘トークン’：‘有効化認証トークン’，‘プロセスＩｄ’：‘＜有効化プロセスＩｄ＞’｝）
出力
｛‘ステータス’：‘＜終了／進行中＞’，‘進捗パーセント’：＜１，１００の間の整数＞｝
【００４４】
記載された記述は、本発明を記述し、本分野における当業者が、本実施形態を実施および使用することを可能とする。本発明の実施形態の範囲は、特許請求の範囲によって規定され、さらに、本分野における当業者が想到可能な他の変形を含んでいてもよい。このような他の変形は、特許請求の範囲の文言と異ならない同様の要素を有している、または、特許請求の範囲の文言とは非実質的に異なる同等の要素を含んでいたとしても、本発明の範囲に含まれるものである。
【００４５】
本明細書における本開示の実施形態は、単一のプラットフォームを用いて、様々な分野における複数のサービスプロバイダーとアプリケーションとを統合するためのプロトコルを提供する。よって、該プロトコルは、ホストプラットフォームにおいて統合アプリケーションのカスタム統合に必要な労力と時間を低減するものである。
【００４６】
しかしながら、保護の範囲は、内部にメッセージを保持するコンピューター可読手段に加えて、プログラムにまで及ぶことは理解されるべきである。そのようなコンピューター可読保存手段は、プログラムが、サーバー、携帯デバイス、または任意の好適なプログラム可能デバイス上で実行されたときに、本方法の１つまたは複数の工程を実行するためのプログラムコード手段を含む。ハードウェアデバイスは、例えば、サーバー、パーソナルコンピューターのような任意の種類のコンピューター、および、これらの任意の組み合わせを含む任意の好適なプログラム可能デバイスである。また、デバイスは、ハードウェア手段（例えば、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ））、ハードウェア手段とソフトウェア手段の組み合わせ（例えば、ＡＳＩＣとＦＰＧＡ）、少なくとも１つのマイクロプロセッサー、内部にソフトウェアモジュールを有する少なくとも１つのメモリーを含む手段であってもよい。よって、手段は、ハードウェア手段とソフトウェア手段の双方を含む。本明細書において記述された方法の実施形態は、ハードウェアおよびソフトウェアにおいて実施することができる。また、デバイスは、ソフトウェア手段を含む。代替的に、実施形態は、例えば、複数のＣＰＵを用いて、複数の異なるハードウェアデバイス上において実施されていてもよい。
【００４７】
ここで記述された実施形態は、ハードウェア要素とソフトウェア要素を含み得る。ソフトウェアにおいて実施される実施形態は、これに限定されるものではないが、ファームウェア、常駐ソフトウェア、マイクロコード等を含む。本明細書で記述された様々なモジュールによって実行される機能は、他のモジュールまたは他のモジュールの組み合わせにおいて実施されてもよい。記述の目的のため、コンピューター使用可能またはコンピューター可読媒体は、使用のために、命令実行システム、装置、またはデバイスによって使用され、または、接続され、プログラムを、含有、保存、通信、伝搬、または送信することができる任意の装置であってもよい。
【００４８】
媒体は、電気的、磁気的、光学的、電磁気的、赤外、若しくは半導体システム（若しくは、装置やデバイス）、または、伝搬媒体であってもよい。コンピューター可読媒体の例としては、半導体または固体状メモリー、磁気テープ、取り外し可能コンピューターディスケット、ランダムアクセスメモリー（ＲＡＭ）、リードオンリーメモリー（ＲＯＭ）、固体磁気ディスク、および光学ディスクが挙げられる。光学ディスクの現在の例としては、コンパクトディスク−リードオンリーメモリー（ＣＤ−ＲＯＭ）、コンパクトディスク−読み込み／書き込み（ＣＤ−Ｒ／Ｗ）、およびＤＶＤが挙げられる。
【００４９】
プログラムコードを保存および／または実行するのに適したデータ処理システムは、システムバスを介して、メモリー要素に直接的または間接的に接続された少なくとも１つのプロセッサーを含む。メモリー要素は、プログラムコードの実際の実行中に用いられるローカルメモリー、大容量記憶装置、実行中に大容量記憶装置から読み出さなければならないコードの読み出し回数を減らすために、少なくともいくつかのプログラムコードの一時的な記憶を提供するキャッシュメモリーを含むことができる。
【００５０】
入力／出力（Ｉ／Ｏ）デバイス（これに限定されるものではないが、キーボード、ディスプレイ、ポインティングデバイス等を含む）は、直接、または、介在Ｉ／Ｏコントローラーを介してシステムに接続可能である。また、ネットワークアダプターがシステムに接続され、データ処理システムが、介在プライベートまたはパブリックネットワークを介して、他のデータ処理システム、遠隔プリンター、またはストレージデバイスに接続可能となっていてもよい。モデム、ケーブルモデム、およびイーサネット（登録商標）カードが、ごく少数の現在利用可能なネットワークアダプターである。
【００５１】
実施形態を実施するための代表的なハードウェア環境は、本明細書において述べられた実施形態に従う情報操作／コンピューターシステムのハードウェア構成を含んでいてもよい。本システムは、少なくとも１つのプロセッサーまたは中央演算ユニット（ＣＰＵ）を含む。ＣＰＵは、システムバスを介して、ランダムアクセスメモリー（ＲＡＭ）、リードオンリーメモリー（ＲＯＭ）、および入力／出力（Ｉ／Ｏ）アダプターのような様々なデバイスに相互接続されている。Ｉ／Ｏアダプターは、ディスクユニットやテープドライブのような周辺機器、または、システムによって読み込み可能な他のプログラムストレージデバイスを接続可能である。システムは、プログラムストレージデバイス上の発明の命令を読み込み、これら命令に従って、本明細書の実施形態の技術を実行する。
【００５２】
システムは、キーボード、スピーカー、マイク、および／または、タッチスクリーン（図示せず）のような他のユーザーインターフェースデバイスを、ユーザー入力を集めるバスに接続する、ユーザーインターフェースアダプターをさらに含む。さらに、例えば、通信アダプターは、バスを、データ処理ネットワークに接続し、ディスプレイアダプターは、バスを、モニター、プリンター、送信機のような出力デバイスとして用いることができる表示装置に接続する。
【００５３】
以上の記述が、様々な実施形態を参照して提供された。本出願が属する分野および技術における当業者であれば、本発明の原理、考え方、および範囲から有意に逸脱することなく、記述された構成および動作の方法における変形や変更が可能であることを理解できるであろう。
【図１】
2019125330.tif 000007
【図２】
2019125330.tif 000008
【図３Ａ】
2019125330.tif 000009
【図３Ｂ】
2019125330.tif 000010
【外国語明細書】
2019125330.tif 000011
2019125330.tif 000012
2019125330.tif 000013
2019125330.tif 000014
2019125330.tif 000015
2019125330.tif 000016
2019125330.tif 000017
2019125330.tif 000018
2019125330.tif 000019
2019125330.tif 000020
2019125330.tif 000021
2019125330.tif 000022
2019125330.tif 000023
2019125330.tif 000024
2019125330.tif 000025
2019125330.tif 000026
2019125330.tif 000027
2019125330.tif 000028
2019125330.tif 000029
2019125330.tif 000030
2019125330.tif 000031
2019125330.tif 000032
2019125330.tif 000033
2019125330.tif 000034
2019125330.tif 000035
2019125330.tif 000036
2019125330.tif 000037
2019125330.tif 000038
2019125330.tif 000039
2019125330.tif 000040
2019125330.tif 000041