特許 6810079 プラットフォームを用いて、様々な分野に渡る複数のサービスプロバイダーを統合するためのシステムおよびプロトコル

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6810079

(24)【登録日】2020年12月14日

(45)【発行日】2021年1月6日

(54)【発明の名称】プラットフォームを用いて、様々な分野に渡る複数のサービスプロバイダーを統合するためのシステムおよびプロトコル

(51)【国際特許分類】

   G06F 9/54 20060101AFI20201221BHJP

   G06Q 50/10 20120101ALI20201221BHJP

   G06F 13/00 20060101ALI20201221BHJP

【ＦＩ】

   G06F9/54 F

   G06Q50/10

   G06F13/00 351B

【請求項の数】11

【外国語出願】

【全頁数】19

(21)【出願番号】特願2018-54269(P2018-54269)

(22)【出願日】2018年3月22日

(65)【公開番号】特開2019-125330(P2019-125330A)

(43)【公開日】2019年7月25日

【審査請求日】2018年4月18日

(31)【優先権主張番号】201821001416

(32)【優先日】2018年1月12日

(33)【優先権主張国】IN

(73)【特許権者】

【識別番号】510337621

【氏名又は名称】タタ コンサルタンシー サービシズ リミテッド

【氏名又は名称原語表記】ＴＡＴＡ Ｃｏｎｓｕｌｔａｎｃｙ Ｓｅｒｖｉｃｅｓ Ｌｉｍｉｔｅｄ

(74)【代理人】

【識別番号】100137095

【弁理士】

【氏名又は名称】江部 武史

(74)【代理人】

【識別番号】100091627

【弁理士】

【氏名又は名称】朝比 一夫

(72)【発明者】

【氏名】ヴァイラル プラカシ シャー

(72)【発明者】

【氏名】ガウラヴ タンダン

(72)【発明者】

【氏名】モーヒト シュクラ

(72)【発明者】

【氏名】ジャイ シャンカー

【審査官】 漆原 孝治

(56)【参考文献】

【文献】 特開２０１１−１２９１１７（ＪＰ，Ａ）

【文献】 特開２００５−２５８６８２（ＪＰ，Ａ）

【文献】 特表２０１７−５２９６３３（ＪＰ，Ａ）

【文献】 API Documentation for libcloud，米国，The Apache Software Foundation，２０１３年 ９月 ４日，version 0.13.1，Module Index欄，ＵＲＬ，http://libcloud.apache.org/apidocs/0.13.1/

【文献】 日本ＣｌｏｕｄＳｔａｃｋユーザー会，Ｃｌｏｕｄ Ｓｔａｃｋ徹底入門，日本，株式会社翔泳社，２０１３年 ３月 ５日，第1版，pp.333-336

【文献】 池田 大輔，Ｚａｂｂｉｘ統合監視徹底活用 複雑化・大規模化するインフラの一元管理，日本，株式会社技術評論社，２０１４年 ３月 ５日，第1版，pp.113-116

【文献】 松本 修、川合 康太、武田 俊男，デジタルビジネス・プラットフォーム，ＦＵＪＩＴＳＵ Ｖｏｌ．６７ Ｎｏ．５，日本，富士通株式会社，２０１６年 ９月 １日，第67巻，pp.17-18、pp.20-21

【文献】 フォーブス ジャパン編集部，「働き方」のテクノロジー，フォーブス ジャパン 第４巻 第５号 Forbes JAPAN，日本，株式会社アトミックスメディア，２０１７年 ３月２８日，第4巻，p.60

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／５４

Ｇ０６Ｆ １３／００

Ｇ０６Ｑ ５０／１０

(57)【特許請求の範囲】

【請求項1】

プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するための方法であって、該方法は、
前記複数のサービスプロバイダーおよびそれらの複数の分野を、前記プラットフォームにメタデータとして登録するプロセッサー実施工程と、
前記登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスを、前記プラットフォームにメタデータとして登録するプロセッサー実施工程と、
前記登録されている複数のサービスプロバイダーのそれぞれの前記複数のサービスのそれぞれ用のパラメーターのセットを、前記プラットフォームにメタデータとして登録するプロセッサー実施工程と、
前記複数のサービスプロバイダーと統合される前記アプリケーションを、メタデータベースのリクエストビルダーモジュールへの入力として提供するプロセッサー実施工程であって、前記入力は、ラッパープロトコルによって規定されたフォーマットで提供され、前記アプリケーションは、前記ラッパープロトコルを用いて前記プラットフォームと通信を行い、さらに、前記ラッパープロトコルは、
前記複数のサービスプロバイダーのタイプを取得し、
前記複数のサービスプロバイダーのリストを取得し、
前記複数のサービスのリストを取得し、
前記複数のサービスを提供し、
前記複数のサービスのＵＲＬを取得し、
ライセンスリポジトリにアクセスするための６つの事前規定されたメソッドを含む、前記アプリケーションを提供するプロセッサー実施工程と、
前記メタデータベースのリクエストビルダーモジュールを用いて、前記入力を、前記ラッパープロトコルによって規定された前記フォーマットから、前記複数のサービスの１つに特有のフォーマットに変換するプロセッサー実施工程であって、前記変換は、前記複数のサービスの前記１つおよびそれに対応するサービスプロバイダーの前記登録されたメタデータに基づく、前記入力を、前記複数のサービスの前記１つに特有の前記フォーマットに変換するプロセッサー実施工程と、
応答取得モジュールを用いて、前記ラッパープロトコルに対応する前記複数のサービスプロバイダーから、応答を取得するプロセッサー実施工程と、
応答標準化モジュールを用いて、前記複数のサービスプロバイダーからの前記応答を、前記ラッパープロトコルによって規定された標準フォーマットに変換するプロセッサー実施工程と、
統合モジュールを用いて、前記プラットフォームにおいて、前記複数のサービスの前記１つに特有の前記フォーマットと前記標準フォーマットを統合するプロセッサー実施工程と、を含むことを特徴とする方法。

【請求項2】

前記プラットフォームによって、前記複数のサービスプロバイダー用のライセンスデータを管理する工程をさらに含む請求項１に記載の方法。

【請求項3】

前記プラットフォームにおいて、前記複数のサービスプロバイダーのライセンスのライセンスリポジトリを維持する工程をさらに含む請求項１に記載の方法。

【請求項4】

前記ラッパープロトコルは、ＲＥＳＴ（representational state transfer）プロトコルに従って作成されている請求項１に記載の方法。

【請求項5】

前記複数の分野は、ビデオ会議開催、盗用、学習管理システムコンテンツ、およびヴァーチャル研究室の少なくとも１つである請求項１に記載の方法。

【請求項6】

前記プラットフォームは、利用可能な前記複数のサービスプロバイダーの単一サインオン（ＳＳＯ）ロジックで構築されている請求項１に記載の方法。

【請求項7】

前記プラットフォームは、プラットフォームプロバイダーによってホスティングされている請求項１に記載の方法。

【請求項8】

プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのシステムであって、該システムは、
メモリーと、
前記メモリーと通信を行うプロセッサーと、を含み、
前記プロセッサーは、
登録モジュールであって、
前記複数のサービスプロバイダーおよびそれらの複数の分野を、前記プラットフォームにメタデータとして登録し、
前記登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスを、前記プラットフォームにメタデータとして登録し、さらに、
前記登録されている複数のサービスプロバイダーのそれぞれの前記複数のサービスのそれぞれ用のパラメーターのセットを、前記プラットフォームにメタデータとして登録するよう構成された、登録モジュールと、
前記複数のサービスプロバイダーと統合される前記アプリケーションを、メタデータベースのリクエストビルダーモジュールへの入力として提供するためのＡＰＩインターフェースであって、前記入力は、ラッパープロトコルによって規定されたフォーマットで提供され、前記アプリケーションは、前記ラッパープロトコルを用いて前記プラットフォームと通信を行い、さらに、前記ラッパープロトコルは、
前記複数のサービスプロバイダーのタイプを取得し、
前記複数のサービスプロバイダーのリストを取得し、
前記複数のサービスのリストを取得し、
前記複数のサービスを提供し、
前記複数のサービスのＵＲＬを取得し、
ライセンスリポジトリにアクセスするための６つの事前規定されたメソッドを含む、ＡＰＩインターフェースと、
前記入力を、前記ラッパープロトコルによって規定された前記フォーマットから、前記複数のサービスの１つに特有のフォーマットに変換するための前記メタデータベースのリクエストビルダーモジュールであって、前記変換は、前記複数のサービスの前記１つおよびそれに対応するサービスプロバイダーの前記登録されたメタデータに基づく、前記メタデータベースのリクエストビルダーモジュールと、
前記ラッパープロトコルに対応する前記複数のサービスプロバイダーから、応答を取得するための応答取得モジュールと、
前記複数のサービスプロバイダーからの前記応答を、前記ラッパープロトコルによって規定された標準フォーマットに変換するための応答標準化モジュールと、
前記プラットフォームにおいて、前記複数のサービスの前記１つに特有の前記フォーマットと前記標準フォーマットを統合するための統合モジュールと、をさらに含むことを特徴とするシステム。

【請求項9】

前記複数のサービスプロバイダーのライセンスを管理するためのライセンス管理モジュールをさらに含み、
前記ライセンス管理モジュールは、前記ラッパープロトコルの前記６つの事前規定されたメソッドの１つを介して、アクセス可能に構成されている請求項８に記載のシステム。

【請求項10】

前記複数のサービスプロバイダーのライセンスを保存するためのライセンスリポジトリをさらに含む請求項８に記載のシステム。

【請求項11】

プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのコンピュータープログラムを具体化している非一時的コンピューター可読媒体であって、前記コンピュータープログラムは、
前記複数のサービスプロバイダーおよびそれらの複数の分野を、前記プラットフォームにメタデータとして登録するプロセッサー実施工程と、
前記登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスを、前記プラットフォームにメタデータとして登録するプロセッサー実施工程と、
前記登録されている複数のサービスプロバイダーのそれぞれの前記複数のサービスのそれぞれ用のパラメーターのセットを、前記プラットフォームにメタデータとして登録するプロセッサー実施工程と、
前記複数のサービスプロバイダーと統合される前記アプリケーションを、メタデータベースのリクエストビルダーモジュールへの入力として提供するプロセッサー実施工程であって、前記入力は、ラッパープロトコルによって規定されたフォーマットで提供され、前記アプリケーションは、前記ラッパープロトコルを用いて前記プラットフォームと通信を行い、さらに、前記ラッパープロトコルは、
前記複数のサービスプロバイダーのタイプを取得し、
前記複数のサービスプロバイダーのリストを取得し、
前記複数のサービスのリストを取得し、
前記複数のサービスを提供し、
前記複数のサービスのＵＲＬを取得し、
ライセンスリポジトリにアクセスするための６つの事前規定されたメソッドを含む、前記アプリケーションを提供するプロセッサー実施工程と、
前記メタデータベースのリクエストビルダーモジュールを用いて、前記入力を、前記ラッパープロトコルによって規定された前記フォーマットから、前記複数のサービスの１つに特有のフォーマットに変換するプロセッサー実施工程であって、前記変換は、前記複数のサービスの前記１つおよびそれに対応するサービスプロバイダーの前記登録された前記メタデータに基づく、前記入力を、前記複数のサービスの前記１つに特有の前記フォーマットに変換するプロセッサー実施工程と、
応答取得モジュールを用いて、前記ラッパープロトコルに対応する前記複数のサービスプロバイダーから、応答を取得するプロセッサー実施工程と、
応答標準化モジュールを用いて、前記複数のサービスプロバイダーからの前記応答を、前記ラッパープロトコルによって規定された標準フォーマットに変換するプロセッサー実施工程と、
統合モジュールを用いて、前記プラットフォームにおいて、前記複数のサービスの前記１つに特有の前記フォーマットと前記標準フォーマットを統合するプロセッサー実施工程と、のためのコンピュータープログラムを含むことを特徴とする非一時的コンピューター可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願への相互参照および優先権
本出願は、２０１８年１月１２日付けで出願されたインド国特許出願第２０１８２１００１４１６号に基づく優先権を主張し、該出願の全ての開示の全体が、参照によりここに援用される。

【0002】

本発明は、一般的に、共通プラットフォームでの複数のベンダーの統合の分野に関し、より具体的には、共通プラットフォームを用いて、様々な分野に渡って複数のサービスを提供する複数のサービスプロバイダーを統合するためのシステムおよびプロトコルに関する。

【背景技術】

【0003】

最近２０〜３０年間の情報技術の急速な進化は、オンラインサービスプロバイダーの数および彼らの製品数の何倍もの増加をもたらしている。会社・法人も、これらの製品の使用に、より大きく依存するようになってきている。学習管理システム、盗用の検出、通信、ビデオ等に関する製品のように、組織により多く関連する様々な製品が存在する。もし、これら製品の使用およびアクセスを、１つの場所において可能とすることができる単一のプラットフォームまたはフレームワークが存在したならば、組織にとって、その利益は膨大なものとなるであろう。これら製品の統合を可能とするために、ソフトウェアが利用可能であることは良く知られている。本分野において、複数の製品を統合するために、いくつかの方法が用いられている。

【0004】

既存の技術は、製品ベースのサービスを提供する各マーケットプレイヤーを統合するカスタム統合（custom integration）を含んでいる。複数のベンダーの統合のために、コーダー（coder：プログラムを書く人）は、プログラムコードを複数回書かなければならず、さらに、これに加えて、複数のベンダーの統合のために、各製品に対する詳細な検討が必要となる。さらに、以前の複数のフレームワークは、複数の異なるベンダーを１つ１つ統合することができ、以前の複数のフレームワークを用いるアプリケーション開発者に対して、プラットフォーム／標準（スタンダード）についての多くを提供している。これらの方法は、コーダーの多大な時間と労力を消費するものである。

【0005】

これに加えて、エンドユーザーのビジネスモデルに応じて工夫し、フレームワーク内でのライセンス管理のようなサービスを提供するプレイヤーもいない。統合レイヤーによって管理される共通ライセンス管理モジュールも存在しない。様々な製品の複数のライセンスを管理することは、やはり、困難だが挑戦的なタスクであり、労力と時間を要するものである。十分な労力および時間を投資することなく、繰り返して使用可能な、明確に定義されたプラットフォームまたはフレームワークは、存在していない。

【発明の概要】

【発明が解決しようとする課題】

【0006】

実施形態の基本的な理解を提供するために、本開示のいくつかの実施形態の簡略化された概要が、以下に提供される。本概要は、実施形態の詳細な概説ではない。また、本概要は、実施形態の極めて重要な／決定的な要素を特定したり、実施形態の範囲を正確に記述したりする意図はない。そのただ１つの目的は、以下に提供されるより詳細な説明の前段階として、簡略化された様態で、いくつかの実施形態を提供することにある。

【0007】

前述の事情を鑑み、本発明の実施形態は、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのシステムを提供する。システムは、登録モジュールと、ＡＰＩインターフェースと、メモリーと、プロセッサーと、を含む。登録モジュールは、複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータを、プラットフォームに登録する。メタデータは、プラットフォームに登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応しており、さらに、メタデータは、プラットフォームに登録されている複数のサービスプロバイダーのそれぞれの複数のサービスのそれぞれ用のパラメーターのセットに対応している。ＡＰＩインターフェースは、プラットフォームを介して、統合のためのアプリケーションを提供する。ここで、該アプリケーションは、ラッパー（wrapper）プロトコルを有している。プロセッサーは、メタデータベースのリクエストビルダー（metadata based request builder）モジュールと、応答取得モジュールと、応答標準化モジュールと、統合モジュールと、をさらに含む。メタデータベースのリクエストビルダーモジュールは、アプリケーションのラッパープロトコルを、複数のサービスの１つに特有のフォーマットに変換する。ここで、該変換は、アプリケーションに対応するサービスプロバイダーおよびサービス用に登録されたメタデータに基づいて実行される。応答取得モジュールは、ラッパープロトコルに対応する複数のサービスプロバイダーから、応答を取得する。応答標準化モジュールは、複数のサービスプロバイダーからの応答を、ラッパープロトコルによって規定された標準フォーマットに変換する。統合モジュールは、プラットフォームにおいて、アプリケーションに特有のフォーマットと標準フォーマットを統合する。

【0008】

本発明の実施形態の別の態様は、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するための方法を提供する。最初に、複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータを、プラットフォームに登録する。同時に、登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応するメタデータが、プラットフォームに登録され、さらに、登録されている複数のサービスプロバイダーのそれぞれの複数のサービスのそれぞれ用のパラメーターのセットに対応するメタデータが、プラットフォームに登録される。次の工程において、プラットフォームを介して、統合のためのアプリケーションが提供される。ここで、該アプリケーションは、ラッパープロトコルを有している。次の工程において、メタデータベースのリクエストビルダーを用いて、アプリケーションのラッパープロトコルが、複数のサービスの１つに特有なフォーマットに変換される。ここで、該変換は、アプリケーションに対応するサービスプロバイダーおよびサービス用に登録されたメタデータに基づいて実行される。次の工程において、応答取得モジュールを用いて、応答が、ラッパープロトコルに対応する複数のサービスプロバイダーから、取得される。その後、応答標準化モジュールを用いて、複数のサービスプロバイダーから取得された応答が、ラッパープロトコルによって規定された標準フォーマットに変換される。そして最後に、統合モジュールを用いて、プラットフォームにおいて、アプリケーションに特有のフォーマットと標準フォーマットとが統合される。

【0009】

別の実施形態において、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのコンピュータープログラムを具体化（embodied）している非一時的コンピューター可読媒体（non-transitory computer-readable medium）が提供される。最初に、複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータを、プラットフォームに登録する。同時に、登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応するメタデータが、プラットフォームに登録され、さらに、登録されている複数のサービスプロバイダーのそれぞれの複数のサービスのそれぞれ用のパラメーターのセットに対応するメタデータが、プラットフォームに登録される。次の工程において、プラットフォームを介して、統合のためのアプリケーションが、提供される。ここで、該アプリケーションは、ラッパープロトコルを有している。次の工程において、メタデータベースのリクエストビルダーを用いて、アプリケーションのラッパープロトコルが、複数のサービスの１つに特有なフォーマットに変換される。ここで、該変換は、アプリケーションに対応するサービスプロバイダーおよびサービス用に登録されたメタデータに基づいて実行される。次の工程において、応答取得モジュールを用いて、応答が、ラッパープロトコルに対応する複数のサービスプロバイダーから、取得される。その後、応答標準化モジュールを用いて、複数のサービスプロバイダーから取得された応答が、ラッパープロトコルによって規定された標準フォーマットに変換される。そして最後に、統合モジュールを用いて、プラットフォームにおいて、アプリケーションに特有のフォーマットと標準フォーマットが統合される。

【0010】

本明細書中の任意のブロック図は、本発明の原理を具体化する例示的なシステムの概念図を表すものであることは、本分野における当業者によって適切に理解されるべきである。同様に、任意のフローチャート、フロー図、状態遷移図、疑似コード等は、コンピューター可読媒体内において実質的に表現することができ、さらに、演算デバイスまたはプロセッサーが明示的に示されているか否かに関係なく、演算デバイスまたはプロセッサーによって実行可能な様々な処理を表していることは理解されるであろう。

【図面の簡単な説明】

【0011】

本発明の実施形態は、以下に述べる図面を含む添付の図面を参照した以下の詳細な説明から、より良く理解されるであろう。

【0012】

【図1】図１は、本発明の実施形態に係る、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーを統合するためのシステムのブロック図を示している。

【0013】

【図2】図２は、本発明の実施形態に係るシステムの概念アーキテクチャ図を示している。

【0014】

【図3A】図３Ａは、本発明の実施形態に係る、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーを統合するためのプロトコルに含まれる工程を示すフローチャートである。

【図3B】図３Ｂは、本発明の実施形態に係る、プラットフォームを用いて、複数の分野に渡る複数のサービスプロバイダーを統合するためのプロトコルに含まれる工程を示すフローチャートである。

【発明を実施するための形態】

【0015】

本発明の実施形態、並びに、それらの様々な特徴および利点が、添付の図面に示され、さらに、以下の記述において詳細に述べられている非限定的な実施形態を参照して、より十分に説明される。本明細書で用いられている例は、本明細書中の実施形態が実施可能となり、さらに、本分野における当業者が、本明細書中の本実施形態を実施可能となるような理解を容易にするためだけの意図で提供される。したがって、例は、本発明の実施形態の範囲の限定を構成するものではない。

【0016】

用語解説−実施形態において用いられる用語
本開示の文脈における「複数のサービスプロバイダー」、「サービスプロバイダー」、または「ベンダー」との表現は、「複数のサービス」または「製品」を提供する主体を意味する。さらに、これらのサービスは、本システムを介して呼び出される。

【0017】

本開示の文脈における「分野（domain）」または「ベンダータイプ（vendor types）」との表現は、ベンダーのサブカテゴリー、それらのサービスが提供されている領域または分野を意味する。例えば、「ブラウザーベースのビデオ会議開催」は、分野の１つである。

【0018】

本開示の文脈における「アプリケーション」、「統合アプリケーション」、または「ウェブアプリケーション」は、本プロトコルを用いて、既存の複数のサービスと統合されるべきアプリケーションを意味する。

【0019】

ここで、図面、より具体的には、図１から図３を参照すると、各図を通して対応する特徴には、同様の参照番号が一貫して付されており、各図において、好ましい実施形態が示され、これら実施形態が、以下の例示的なシステムおよび／または方法の文脈において記述される。

【0020】

本開示の実施形態に係る、プラットフォーム１０２を用いて、複数の分野に渡る複数のサービスプロバイダーとアプリケーションとを統合するためのシステム１００が、図１に示されている。プラットフォーム１０２は、プラットフォーム所有者によって提供される。また、本開示において、プラットフォームを、ホストプラットフォーム（hosted platform）と称することができる。システム１００は、共通プロトコルを用いて、複数のサービスプロバイダーを統合するためのメタデータベースのアプローチを提供する。共通プロトコルは、サポートされている分野内において、複数のサービスを提供する複数のサービスプロバイダーのそれぞれに対するカスタム統合のための労力を減らす。システム１００は、複数の同様の製品／サービスに渡るラッパープロトコル（wrapper protocol）を規定することにより、複数の同様の製品（ビデオ、学習、盗用の検出等）に渡る統合アプローチを標準化するよう構成されている。また、本開示の１つの例において、システム１００を、ｉＯＮサードパーティーフレームワークおよびプロトコル（ｉＯＮ ＴＰＦＰ：iON Third Party Framework and Protocol）と称することができる。ｉＯＮ ＴＰＦＰは、クラウドベースのフレームワークである。また、システム１００は、動的リクエストの生成を含んでおり、このプロトコルは、任意のサービスプロバイダーに拡張可能である。

【0021】

本開示の実施形態によれば、図１のブロック図に示されているように、システム１００は、登録モジュール１０４と、ＡＰＩインターフェース１０６と、メモリー１０８と、プロセッサー１１０と、をさらに含む。プロセッサー１１０は、メモリー１０８と通信して機能する。プロセッサー１１０は、複数のモジュールをさらに含む。複数のモジュールは、メモリー１０８内に保存されているアルゴリズムのセットにアクセスし、特定のタスクを実行する。プロセッサー１１０は、メタデータベースのリクエストビルダー（metadata based request builder）モジュール１１２と、応答取得モジュール１１４と、応答標準化モジュール１１６と、統合モジュール１１８と、をさらに含む。

【0022】

本開示の実施形態によれば、登録モジュール１０４は、ホストプラットフォーム１０２に、３種類のメタデータを登録するよう構成されている。すなわち、３種類のメタデータは、１．プラットフォーム１０２上の複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータ、２．プラットフォーム１０２上の登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応し、複数のサービスコンポーネントを含むメタデータ、および３．プラットフォーム１０２上の登録されている複数のサービスプロバイダーのそれぞれの複数のサービスのそれぞれ用のパラメーターのセットに対応するメタデータである。また、システム１００は、複数のサービスをグループ化するよう構成されており、さらに、同様のサービスを提供する複数の製品に渡る同じタイプのサービスの全ての標準化された入力および出力をグループ化するよう構成されている。システム１００と一体化される任意のアプリケーションが、多くの製品を統合する準備を行う。この製品リポジトリ（repository：ソフトウェア設計情報のデータベース）は、拡張に伴う増加を維持することになる。

【0023】

本開示の実施形態によれば、アプリケーション・プログラミング・インターフェース（ＡＰＩ）インターフェース１０６は、システム１００への入力を提供するよう構成されている。ＡＰＩインターフェース１０６は、プラットフォームを介して、統合のためのアプリケーションを提供するよう構成されている。アプリケーションは、統合アプリケーションである。統合アプリケーションは、誰によっても構築されることができ、任意の技術によって構築されることができ、さらに、任意のフレームワークによって構築されることができる。よって、システム１００は、技術に依存せず、さらに、フレームワークに依存しない。ＡＰＩインターフェース１０６は、例えば、ウェブインターフェース、グラフィカルユーザーインターフェース等の様々なソフトウェアおよびハードウェアインターフェース等を含み得、さらに、有線ネットワーク（例えば、ＬＡＮ、ケーブル等）および無線ネットワーク（ＷＬＡＮ、セルラー、衛星等）を含む広範な種類のネットワークＮ／Ｗおよびプロトコルタイプにおける相互通信を容易にすることができる。

【0024】

本開示の実施形態によれば、統合アプリケーションは、ラッパープロトコルを含む。このような統合に関するアプリケーションは、明確に定義され、再現性のある、解決のための標準（standard）を有している。ラッパープロトコルは、６つの事前規定されたメソッドをさらに含んでいる。これら６つの事前規定されたメソッドは、複数のサービスプロバイダーのタイプを取得するためのメソッド、複数のサービスプロバイダーのリストを取得するためのメソッド、複数のサービスのリストを取得するためのメソッド、複数のサービスを提示（post）するためのメソッド、複数のサービスのＵＲＬを取得するためのメソッド、およびライセンスリポジトリにアクセスするためのメソッドである。６つの事前規定されたメソッドのそれぞれは、ＨＴＴＰ ＲＥＳＴ（REpresentational State Transfer：分散ハイパーメディアシステムのためのソフトウェアアーキテクチャスタイルの１つ） ＵＲＬとして利用可能である。また、本開示の例において、６つの事前規定されたメソッドを、それぞれ、ＧｅｔＶｅｎｄｏｒＴｙｐｅｓ、ＧｅｔＶｅｎｄｏｒＬｉｓｔ、ＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＬｉｓｔ、ＰｏｓｔＶｅｎｄｏｒＳｅｒｖｉｃｅ、ＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＵＲＬ、およびＬｉｃｅｎｓｅＭｇｍｔと称することができる。これらメソッドは、本開示の後の部分において、詳細に説明される。

【0025】

本開示の実施形態によれば、プロセッサー１１０は、メタデータベースのリクエストビルダーモジュール１１２を含む。メタデータベースのリクエストビルダーモジュール１１２は、アプリケーションのラッパープロトコルを、複数のサービスの１つに特有のフォーマットに変換するよう構成されている。ここで、該変換は、統合アプリケーションに対応するサービスプロバイダーおよびサービスのために登録されたメタデータに基づいて実行される。メタデータベースのリクエストビルダーモジュール１１２は、ラッパープロトコルのフォーマットでの入力を、ＲＥＳＴ（Representational State Transfer）でのＪＳＯＮ（JavaScript（登録商標） Object Notation）形式のキー値ペア（key value pairs）として取得する。

【0026】

本開示の実施形態によれば、プロセッサー１１０は、応答取得モジュール１１４と、応答標準化モジュール１１６と、をさらに含む。応答取得モジュール１１４は、ラッパープロトコルに対応する複数のサービスプロバイダーから、応答を取得する。一方、応答標準化モジュール１１６は、複数のサービスプロバイダーから取得した応答を、ラッパープロトコルによって規定された標準フォーマットに変換する。本開示の別の実施形態において、応答標準化モジュール１１６も、応答を取得するよう構成されていてもよいことは、理解されるべきである。さらに、統合モジュール１１８は、プラットフォーム１０２内において、標準フォーマットと、アプリケーションに特有のフォーマットとを統合する。よって、ｉＴＰＦＰは、ごく少数のタイプのトランザクションのために、複数のサービスプロバイダーと通信を行い、統合アプリケーションがラッパープロトコルに従うものであれば、その後、統合アプリケーションの所有者は、それらを統合するために、ベンダーのセットを知る必要がない。よって、プログラムを書く代わりに、統合アプリケーションは、多数のサービスプロバイダーと、途切れなく、相互通信を行うことができる。

【0027】

本開示の実施形態によれば、システム１００は、ライセンス管理モジュール１２０をさらに含む。ライセンス管理モジュール１２０は、複数のサービスプロバイダーのライセンスおよび対応データを管理するよう構成されている。ライセンス管理モジュール１２０は、ラッパープロトコルの６つの事前規定されたメソッドの１つを介してアクセス可能に構成されている。また、ライセンス管理モジュール１２０は、複数のサービスプロバイダーのライセンスを保存するためのライセンスリポジトリ１２２を保持している。ライセンスリポジトリ１２２は、キー値ペアのリポジトリ（ＡＰＩ上に露出している）を有することができる。ここで、エンドユーザーは、複数のキー値（ライセンスコード、登録済みメール、アプリケーションＩＤ等）を、ベンダーリストの中のベンターに対して登録することができる。また、任意のライセンスパラメーター（例えば、登録されたメールＩＤ、アプリケーションＩＤ、管理認証情報等）が取得されてもよく、さらに、任意のライセンスパラメーターが、ｉＯＮ ＴＰＦＰを通り、サードパーティー商品との統合を行うために、用いられてもよい。

【0028】

本開示の実施形態によれば、システム１００は、コーダーの統合労力を大幅に減らす。また、システム１００は、プラットフォーム１０２と既に統合されている複数のベンダーの準備リポジトリ（ready repository）を提供する。よって、労力の削減に加えて、統合アプリケーションは、同様に統合された複数の製品を迅速に取得するという観点からも、付加価値を取得している。

【0029】

本開示の実施形態によれば、図２に示すような概念アーキテクチャを活用して、システム１００を説明することができる。図２中の図表は、３つのタイプのサービスプロバイダー、すなわち、ビデオ会議開催ベンダー、盗用ベンダー、およびコンテンツ管理ベンダーを参照して、説明される。プラットフォーム１０２によって登録され得る様々なベンダーが存在し得る。統合される必要がある全てのアプリケーションが、左手側に記載されている。また、全ての統合アプリケーションが、ライセンス管理モジュール１２０と通信可能となっている。ライセンス管理モジュール１２０は、統合アプリケーションに必要な全てのライセンス情報を提供することができる。全ての統合アプリケーションは、ＲＥＳＴ／ＪＳＯＮプロトコルに従って（over REST/JSON protocol）構築される。統合アプリケーションは、メタデータベースのリクエストビルダーモジュール１１２に対する入力を提供可能である。ベンダーのタイプに応じて、複数のベンダーのそれぞれ用のカスタムリクエストが送信される。カスタムリクエストは、複数のベンダーのリポジトリに送信される。このリポジトリは、登録されている複数のサービスプロバイダーのメタデータの全てを有している。カスタム出力が、複数のベンダーのそれぞれから受信され、その後、カスタム出力が、応答標準化モジュール１１６に提供される。その後、応答標準化モジュール１１６は、統合アプリケーションの統合に利用可能な標準フォーマットで、出力を提供する。

【0030】

動作において、図３Ａ−３Ｂに示されているように、フローチャート２００は、プラットフォーム１０２を用いて、複数の分野に渡る複数のサービスプロバイダーと統合アプリケーションを統合するためのプロトコルの工程を示している。最初に、工程２０２において、複数のサービスプロバイダーおよびそれらの複数の分野に対応するメタデータが、プラットフォーム１０２に登録される。同様に、工程２０４において、登録されている複数のサービスプロバイダーのそれぞれによって提供される複数のサービスに対応するメタデータが、プラットフォーム１０２に登録され、さらに、工程２０６において、登録されている複数のサービスプロバイダーのそれぞれの複数のサービスのそれぞれ用のパラメーターのセットに対応するメタデータが、プラットフォーム１０２上に登録される。

【0031】

次の工程２０８において、統合アプリケーションが、プラットフォーム１０２を介して、統合のために提供される。統合アプリケーションは、ラッパープロトコルを有している。ラッパープロトコルは、６つの事前規定されたメソッドを含んでいる。ラッパープロトコルを用いて、任意のアプリケーションは、ホストプラットフォーム１０２と通信を行うことができ、さらに、ホストプラットフォーム１０２は、続いて、複数の分野に渡る複数のサービスプロバイダーと内部的に接続することによって、統合アプリケーションのリクエストを実行し、さらに、標準フォーマットで、出力を提供することができる。

【0032】

次の工程２１０において、メタデータベースのリクエストビルダーモジュール１１２を用いて、アプリケーションのラッパープロトコルが、複数のサービスの１つに特有のフォーマットに変換される。この変換は、アプリケーションに対応するサービスプロバイダーおよびサービス用に登録されたメタデータに基づいて実行される。工程２１２において、応答取得モジュール１１４を用いて、ラッパープロトコルに対応する複数のサービスプロバイダーからの応答が、取得される。次の工程２１４において、応答標準化モジュール１１６を用いて、複数のサービスプロバイダーから取得された応答が、ラッパープロトコルによって規定された標準フォーマットに変換される。最後に、工程２１６において、プラットフォーム１０２内において、標準フォーマットと、アプリケーションに特有のフォーマットとが統合される。ラッパープロトコルは、通信（入力＆出力）の形式／フォーマットを規定／標準化するので、統合アプリケーションの終端（the end of the integrating application）における労力が実質的に低減される。

【0033】

また、本開示の別の実施形態によれば、システム１００またはｉＴＰＦＰを、以下の例を用いて説明することができる。本開示の現在のバージョンにおいて、ｉＴＰＦＰは、４つの分野に渡る７つのベンダーによって提供される２０タイプのサービスをサポートしている。本開示は、将来の拡張および開発を含むさらなる範囲も有していることは、理解されるべきである。４つの分野は、ビデオ会議開催、ＬＭＳ（Learning Management System:学習管理システム）コンテンツ管理、盗用、およびヴァーチャル研究室を含む。表Ｉは、システム１００によってサポートされている複数のサービスのリストを示している。

表Ｉ

【0034】

表２は、システム１００によってサポートされている複数のサービスプロバイダーのリストを示している。
表ＩＩ

【0035】

上で説明したように、ラッパープロトコルは、６つの事前規定されたメソッドを有している。これらメソッドの全ては、ＨＴＴＰ ＲＥＳＴ ＵＲＬｓとして利用可能である。全ての相互通信は、これら６つのメソッドを介してのみ実行される。入力／出力は、いくつかの場合において変化し得る（起動される「ベンダーサービス」のタイプに応じて変化し得る）。いくつかのメソッドは、メタデータベースであり、公に利用可能である。一方、いくつかのメソッドは、メタデータベースではなく、ｉＴＰＦＰライセンスが必要であり、登録された分野から呼び出されることが必要である。６つの事前規定されたメソッドは、以下の通りである。

【0036】

ＧｅｔＶｅｎｄｏｒＴｙｐｅｓ（メタデータベース）：このメソッドは、ＪＳＯＮ出力として、ｉＴＰＦＰの現在のバージョンにおいてサポートされている「分野」のリストを提供する。

【0037】

ＧｅｔＶｅｎｄｏｒＬｉｓｔ（メタデータベース）：このメソッドは、ＪＳＯＮ出力として、ｉＴＰＦＰの現在のバージョンにおいてサポートされているベンダーのリストを提供する。

【0038】

ＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＬｉｓｔ（メタデータベース）：このメソッドは、ＪＳＯＮ出力として、特定のベンダーとの相互通信のために利用可能なベンダーサービスのリストを提供する（本メソッドは、動作のための入力として、ベンダーＩＤまたはベンダータイプＩＤを必要とする）。

【0039】

ＰｏｓｔＶｅｎｄｏｒＳｅｒｖｉｃｅ（メタデータベースではない）：このメソッドは、通過したサービスを起動した後に、入力として、入力ＪＳＯＮ（ベンダーのタイプおよび起動されているベンダーのサービスによって変化する）を受け付け、標準出力ＪＳＯＮを与える。このメソッドは、標準入力／出力を介して、サードパーティベンダーのサービスを起動する実際のタスクを実行する。このメソッドのための入力／出力フォーマットは、各分野のサービス毎に事前に規定されており、これは、例えば、任意のサポートされている盗用ベンダーのテキストファイルスキャン用のＰｏｓｔＶｅｎｄｏｒＳｅｒｖｉｃｅフォーマットが同じものであり、プロトコル仕様書内において規定されていることを意味する。

【0040】

ＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＬｉｓｔ（メタデータベースではない）：このメソッドは、ＪＳＯＮ入力（ベンダーのタイプおよび起動されているベンダーのサービスによって変化する）を受け付け、ポストパラメーターと共に、完全形式ＵＲＬを返す。このＵＲＬは、統合アプリケーションによって直接呼び出され、ベンダーと直接接続することによって、ベンダーサービスを起動する。しかしながら、この場合、出力は標準化されない。

【0041】

ＬｉｃｅｎｓｅＭｇｍｔ：１．Ｄｅｆａｕｌｔ（メタデータベース）：「ＬｉｃｅｎｓｅＭｇｍｔ」メソッドは、パラメーター無しで呼び出された場合、ベンダーのリストと、必要なライセンスパラメーター（例えば、秘密鍵、パスワード、登録されたｅメール等）を与え、これらベンダーとの認証を行う。２．Ｗｉｔｈ ｉＴＰＦＰ Ｌｉｃｅｎｓｅ（メタデータベースではない）：このメソッドは、ｉＴＰＦＰライセンス情報と共に呼び出された場合、あなたのライセンスパラメーターをフェッチおよび保存するよう機能する。

【0042】

さらなる既述のために、プロトコルの事前規定されたメソッドの組が以下に提供される。実際のＵＲＬ、ＪＳＯＮ入力／出力は、詳細に提供されている。

【0043】

メソッド仕様書
ＧｅｔＶｅｎｄｏｒＴｙｐｅｓ（メタデータベース）
説明：ｉＴＰＦＰの現在のバージョンにおいてサポートされている「分野」のリストを返す。
ＵＲＬ：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）によって提供されるサービスであり、サブスクリプションを必要とする。

例１：盗用ベンダーのための画像スキャン
ＲＥＳＴパラメーター
＜サービス＿ｉｄ＞ →任意のサポートされている盗用ベンダーのサービスのＩＤである。ここで、サービス＿名前＝“画像スキャン”（同じプロトコルのメソッドＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＬｉｓｔからのもの）
＜ｏｒｇ＿ｉｄ＞＆＜ライセンス＿コード＞ →統合アプリケーションに提供されたｉＴＰＴＰライセンスパラメーター
（ＰＯＳＴにおける）ＪＳＯＮフォーマット →｛‘トークン’：‘有効化認証トークン’，‘ファイル’：‘スキャンすべきファイルのＵＲＬ／経路’｝）

出力
｛“ファイル名”：“＜提出されたファイルの名前＞”，“プロセスＩｄ”：“＜あなたが開始したスキャンプロセスの識別子＞”，“ＣｒｅａｔｉｏｎＴｉｍｅＵＴＣ”：“＜タイムスタンプ＞”｝

例２．任意の盗用ベンダーへのあなたの提出されたファイルのフェッチステータス
ＲＥＳＴパラメーター
＜サービス＿ｉｄ＞ →任意のサポートされている盗用ベンダーのサービスのＩＤである。ここで、サービス＿名前＝“ステータス”（同じプロトコルのメソッドＧｅｔＶｅｎｄｏｒＳｅｒｖｉｃｅＬｉｓｔからのもの）
＜ｏｒｇ＿ｉｄ＞＆＜ライセンス＿コード＞ →統合アプリケーションに提供されたｉＴＰＴＰライセンスパラメーター
（ＰＯＳＴにおける）ＪＳＯＮフォーマット →｛‘トークン’：‘有効化認証トークン’，‘プロセスＩｄ’：‘＜有効化プロセスＩｄ＞’｝）

出力
｛‘ステータス’：‘＜終了／進行中＞’，‘進捗パーセント’：＜１，１００の間の整数＞｝

【0044】

記載された記述は、本発明を記述し、本分野における当業者が、本実施形態を実施および使用することを可能とする。本発明の実施形態の範囲は、特許請求の範囲によって規定され、さらに、本分野における当業者が想到可能な他の変形を含んでいてもよい。このような他の変形は、特許請求の範囲の文言と異ならない同様の要素を有している、または、特許請求の範囲の文言とは非実質的に異なる同等の要素を含んでいたとしても、本発明の範囲に含まれるものである。

【0045】

本明細書における本開示の実施形態は、単一のプラットフォームを用いて、様々な分野における複数のサービスプロバイダーとアプリケーションとを統合するためのプロトコルを提供する。よって、該プロトコルは、ホストプラットフォームにおいて統合アプリケーションのカスタム統合に必要な労力と時間を低減するものである。

【0046】

しかしながら、保護の範囲は、内部にメッセージを保持するコンピューター可読手段に加えて、プログラムにまで及ぶことは理解されるべきである。そのようなコンピューター可読保存手段は、プログラムが、サーバー、携帯デバイス、または任意の好適なプログラム可能デバイス上で実行されたときに、本方法の１つまたは複数の工程を実行するためのプログラムコード手段を含む。ハードウェアデバイスは、例えば、サーバー、パーソナルコンピューターのような任意の種類のコンピューター、および、これらの任意の組み合わせを含む任意の好適なプログラム可能デバイスである。また、デバイスは、ハードウェア手段（例えば、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ））、ハードウェア手段とソフトウェア手段の組み合わせ（例えば、ＡＳＩＣとＦＰＧＡ）、少なくとも１つのマイクロプロセッサー、内部にソフトウェアモジュールを有する少なくとも１つのメモリーを含む手段であってもよい。よって、手段は、ハードウェア手段とソフトウェア手段の双方を含む。本明細書において記述された方法の実施形態は、ハードウェアおよびソフトウェアにおいて実施することができる。また、デバイスは、ソフトウェア手段を含む。代替的に、実施形態は、例えば、複数のＣＰＵを用いて、複数の異なるハードウェアデバイス上において実施されていてもよい。

【0047】

ここで記述された実施形態は、ハードウェア要素とソフトウェア要素を含み得る。ソフトウェアにおいて実施される実施形態は、これに限定されるものではないが、ファームウェア、常駐ソフトウェア、マイクロコード等を含む。本明細書で記述された様々なモジュールによって実行される機能は、他のモジュールまたは他のモジュールの組み合わせにおいて実施されてもよい。記述の目的のため、コンピューター使用可能またはコンピューター可読媒体は、使用のために、命令実行システム、装置、またはデバイスによって使用され、または、接続され、プログラムを、含有、保存、通信、伝搬、または送信することができる任意の装置であってもよい。

【0048】

媒体は、電気的、磁気的、光学的、電磁気的、赤外、若しくは半導体システム（若しくは、装置やデバイス）、または、伝搬媒体であってもよい。コンピューター可読媒体の例としては、半導体または固体状メモリー、磁気テープ、取り外し可能コンピューターディスケット、ランダムアクセスメモリー（ＲＡＭ）、リードオンリーメモリー（ＲＯＭ）、固体磁気ディスク、および光学ディスクが挙げられる。光学ディスクの現在の例としては、コンパクトディスク−リードオンリーメモリー（ＣＤ−ＲＯＭ）、コンパクトディスク−読み込み／書き込み（ＣＤ−Ｒ／Ｗ）、およびＤＶＤが挙げられる。

【0049】

プログラムコードを保存および／または実行するのに適したデータ処理システムは、システムバスを介して、メモリー要素に直接的または間接的に接続された少なくとも１つのプロセッサーを含む。メモリー要素は、プログラムコードの実際の実行中に用いられるローカルメモリー、大容量記憶装置、実行中に大容量記憶装置から読み出さなければならないコードの読み出し回数を減らすために、少なくともいくつかのプログラムコードの一時的な記憶を提供するキャッシュメモリーを含むことができる。

【0050】

入力／出力（Ｉ／Ｏ）デバイス（これに限定されるものではないが、キーボード、ディスプレイ、ポインティングデバイス等を含む）は、直接、または、介在Ｉ／Ｏコントローラーを介してシステムに接続可能である。また、ネットワークアダプターがシステムに接続され、データ処理システムが、介在プライベートまたはパブリックネットワークを介して、他のデータ処理システム、遠隔プリンター、またはストレージデバイスに接続可能となっていてもよい。モデム、ケーブルモデム、およびイーサネット（登録商標）カードが、ごく少数の現在利用可能なネットワークアダプターである。

【0051】

実施形態を実施するための代表的なハードウェア環境は、本明細書において述べられた実施形態に従う情報操作／コンピューターシステムのハードウェア構成を含んでいてもよい。本システムは、少なくとも１つのプロセッサーまたは中央演算ユニット（ＣＰＵ）を含む。ＣＰＵは、システムバスを介して、ランダムアクセスメモリー（ＲＡＭ）、リードオンリーメモリー（ＲＯＭ）、および入力／出力（Ｉ／Ｏ）アダプターのような様々なデバイスに相互接続されている。Ｉ／Ｏアダプターは、ディスクユニットやテープドライブのような周辺機器、または、システムによって読み込み可能な他のプログラムストレージデバイスを接続可能である。システムは、プログラムストレージデバイス上の発明の命令を読み込み、これら命令に従って、本明細書の実施形態の技術を実行する。

【0052】

システムは、キーボード、スピーカー、マイク、および／または、タッチスクリーン（図示せず）のような他のユーザーインターフェースデバイスを、ユーザー入力を集めるバスに接続する、ユーザーインターフェースアダプターをさらに含む。さらに、例えば、通信アダプターは、バスを、データ処理ネットワークに接続し、ディスプレイアダプターは、バスを、モニター、プリンター、送信機のような出力デバイスとして用いることができる表示装置に接続する。

【0053】

以上の記述が、様々な実施形態を参照して提供された。本出願が属する分野および技術における当業者であれば、本発明の原理、考え方、および範囲から有意に逸脱することなく、記述された構成および動作の方法における変形や変更が可能であることを理解できるであろう。

【図1】

【図2】

【図3A】

【図3B】