(57)【要約】【課題】対話的ホワイトボード（IWB）での協働を管理する手法により、異なるサードパーティー協働サービスのユーザーたちがIWBでの協働会議に参加できるようにする。【解決手段】この手法は、たとえユーザーたちが異なるサードパーティー協働サービスを使っていても、ユーザーたちが、注釈付けのようなIWBによって提供される協働機能を使い、互いと通信することを許容する。この手法は、「単一ラッパー」アプリケーション・プログラム・インターフェース（API）および協働会議の中央集中した管理を提供する協働マネージャを使う。該管理は、ライセンス鍵およびトークン管理、クロスライセンス協働、ユーザー管理および会議管理を含む。協働マネージャは、異なるサードパーティー協働サービスのAPIを扱う仲介層のはたらきをし、不均一な協働クライアントを使っているユーザーたちが協働会議に参加できるようにする。【選択図】図１
2018101417.tif 000002
【特許請求の範囲】
【請求項１】
対話的ホワイトボード（IWB）装置であって：
一つまたは複数のプロセッサ；
一つまたは複数のメモリ；
ユーザー・インターフェース；
当該IWB装置上で実行される注釈付けアプリケーションであって、前記注釈付けアプリケーションは、当該IWB装置のユーザーが当該IWB装置の前記ユーザー・インターフェースに表示される電子コンテンツに注釈付けできるようにするよう構成されている、注釈付けアプリケーション；および
当該IWB装置上で実行される協働アプリケーションであって、前記協働アプリケーションは、それぞれ相異なるアプリケーション・プログラム・インターフェース（API）をサポートする複数のサードパーティー協働サービスに、管理サービスを介してアクセスするよう構成されており、該管理サービスは、前記協働アプリケーションおよび前記複数のサードパーティー協働サービスの両方と別個であり、前記複数のサードパーティー協働サービスの前記相異なるAPIとは異なるAPIをサポートし、前記協働アプリケーションは前記管理サービスのAPIをサポートするが、前記複数のサードパーティー協働サービスの前記相異なるAPIをサポートしない、協働アプリケーションとを有する、
装置。
【請求項２】
前記協働アプリケーションが、前記複数のサードパーティー協働サービスを横断して共通のグラフィカル・ユーザー・インターフェースを実装する、請求項１記載の装置。
【請求項３】
前記協働アプリケーションが、スタンドアローン・プロセス、プラグイン・モジュール、ウィジェットまたはライブラリのうちの一つまたは複数である、請求項１記載の装置。
【請求項４】
前記協働アプリケーションが、前記複数の協働サービスからの特定のサードパーティー協働サービスでの特定の協働機能にアクセスすることを、前記管理サービスのAPIの要件を満たすが前記特定のサードパーティー協働サービスのAPIの要件を満たさない、前記特定の協働機能にアクセスするための要求を生成して前記管理サービスに送信することによって行なうよう構成されている、請求項１記載の装置。
【請求項５】
前記管理サービスのAPI、前記管理サービスによって管理されるAPIデータの要件を満たす前記特定の協働機能にアクセスするための前記要求が第一の要求であり、
前記管理サービスは前記第一の要求を処理して前記特定のサードパーティー協働サービスでの前記協働機能にアクセスするための第二の要求を生成し、前記第二の要求は前記特定のサードパーティー協働サービスでのAPIの要件を満たす、
請求項３記載の装置。
【請求項６】
前記特定のサードパーティー協働サービスでの前記協働機能にアクセスするための前記第二の要求が、前記管理サービスのAPIの要件を満たす前記特定の協働機能にアクセスするための前記要求に関連付けられたユーザーと、前記特定のサードパーティー協働サービスとの両方に固有の認証トークンを含む、請求項４記載の装置。
【請求項７】
前記特定のサードパーティー協働サービスでの前記協働機能にアクセスするための前記第二の要求が、前記特定のサードパーティー協働サービスに固有だが、前記管理サービスのAPIの要件を満たす前記特定の協働機能にアクセスするための前記要求に関連付けられたユーザーに固有ではない認証トークンを含む、請求項４記載の装置。
【請求項８】
命令を記憶している一つまたは複数の非一時的なコンピュータ可読媒体であって、前記命令は、一つまたは複数のプロセッサによって処理されたときに：
対話的ホワイトボード（IWB）機器上で実行される注釈付けアプリケーションをして、前記IWB機器のユーザーが前記IWB機器のユーザー・インターフェースに表示される電子コンテンツに注釈付けすることを許容させるとともに；
前記IWB機器上で実行される協働アプリケーションをして、それぞれ相異なるアプリケーション・プログラム・インターフェース（API）をサポートする複数のサードパーティー協働サービスに、管理サービスを介してアクセスさせるものであり、該管理サービスは、前記協働アプリケーションおよび前記複数のサードパーティー協働サービスの両方と別個であり、前記複数のサードパーティー協働サービスの前記相異なるAPIとは異なるAPIをサポートし、前記協働アプリケーションは前記管理サービスのAPIをサポートするが、前記複数のサードパーティー協働サービスの前記相異なるAPIをサポートしない、
一つまたは複数の非一時的コンピュータ可読媒体。
【請求項９】
前記協働アプリケーションが、前記複数のサードパーティー協働サービスを横断して共通のグラフィカル・ユーザー・インターフェースを実装する、請求項８記載の一つまたは複数の非一時的コンピュータ可読媒体。
【請求項１０】
前記協働アプリケーションが、スタンドアローン・プロセス、プラグイン・モジュール、ウィジェットまたはライブラリのうちの一つまたは複数である、請求項８記載の一つまたは複数の非一時的コンピュータ可読媒体。
【請求項１１】
前記協働アプリケーションが、前記複数の協働サービスからの特定のサードパーティー協働サービスでの特定の協働機能にアクセスすることを、前記管理サービスのAPIの要件を満たすが前記特定のサードパーティー協働サービスのAPIの要件を満たさない、前記特定の協働機能にアクセスするための要求を生成して前記管理サービスに送信することによって行なうよう構成されている、請求項８記載の一つまたは複数の非一時的コンピュータ可読媒体。
【請求項１２】
前記管理サービスのAPI、前記管理サービスによって管理されるAPIデータの要件を満たす前記特定の協働機能にアクセスするための前記要求が第一の要求であり、
前記管理サービスは前記第一の要求を処理して前記特定のサードパーティー協働サービスでの前記協働機能にアクセスするための第二の要求を生成し、前記第二の要求は前記特定のサードパーティー協働サービスでのAPIの要件を満たす、
請求項１０記載の一つまたは複数の非一時的コンピュータ可読媒体。
【請求項１３】
前記特定のサードパーティー協働サービスでの前記協働機能にアクセスするための前記第二の要求が、前記管理サービスのAPIの要件を満たす前記特定の協働機能にアクセスするための前記要求に関連付けられたユーザーと、前記特定のサードパーティー協働サービスとの両方に固有の認証トークンを含む、請求項１１記載の一つまたは複数の非一時的コンピュータ可読媒体。
【請求項１４】
前記特定のサードパーティー協働サービスでの前記協働機能にアクセスするための前記第二の要求が、前記特定のサードパーティー協働サービスに固有だが、前記管理サービスのAPIの要件を満たす前記特定の協働機能にアクセスするための前記要求に関連付けられたユーザーに固有ではない認証トークンを含む、請求項１１記載の一つまたは複数の非一時的コンピュータ可読媒体。
【請求項１５】
コンピュータ実装される方法であって：
対話的ホワイトボード（IWB）機器上で実行される注釈付けアプリケーションが、前記IWB機器のユーザーが前記IWB機器のユーザー・インターフェースに表示される電子コンテンツに注釈付けすることを許容する段階と；
前記IWB機器上で実行される協働アプリケーションが、それぞれ相異なるアプリケーション・プログラム・インターフェース（API）をサポートする複数のサードパーティー協働サービスに、管理サービスを介してアクセスする段階とを含み、該管理サービスは、前記協働アプリケーションおよび前記複数のサードパーティー協働サービスの両方と別個であり、前記複数のサードパーティー協働サービスの前記相異なるAPIとは異なるAPIをサポートし、前記協働アプリケーションは前記管理サービスのAPIをサポートするが、前記複数のサードパーティー協働サービスの前記相異なるAPIをサポートしない、
コンピュータ実装される方法。
【請求項１６】
前記協働アプリケーションが、前記複数のサードパーティー協働サービスを横断して共通のグラフィカル・ユーザー・インターフェースを実装する、請求項１５記載のコンピュータ実装される方法。
【請求項１７】
前記協働アプリケーションが、スタンドアローン・プロセス、プラグイン・モジュール、ウィジェットまたはライブラリのうちの一つまたは複数である、請求項１５記載のコンピュータ実装される方法。
【請求項１８】
前記協働アプリケーションが、前記複数の協働サービスからの特定のサードパーティー協働サービスでの特定の協働機能にアクセスすることを、前記管理サービスのAPIの要件を満たすが前記特定のサードパーティー協働サービスのAPIの要件を満たさない、前記特定の協働機能にアクセスするための要求を生成して前記管理サービスに送信することによって行なうよう構成されている、請求項１５記載のコンピュータ実装される方法。
【請求項１９】
前記管理サービスのAPI、前記管理サービスによって管理されるAPIデータの要件を満たす前記特定の協働機能にアクセスするための前記要求が第一の要求であり、
前記管理サービスは前記第一の要求を処理して前記特定のサードパーティー協働サービスでの前記協働機能にアクセスするための第二の要求を生成し、前記第二の要求は前記特定のサードパーティー協働サービスでのAPIの要件を満たす、
請求項１７記載のコンピュータ実装される方法。
【請求項２０】
前記特定のサードパーティー協働サービスでの前記協働機能にアクセスするための前記第二の要求が、前記管理サービスのAPIの要件を満たす前記特定の協働機能にアクセスするための前記要求に関連付けられたユーザーと、前記特定のサードパーティー協働サービスとの両方に固有の認証トークンを含む、請求項１８記載のコンピュータ実装される方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願データ
本願は、2016年12月19日に出願された「ラッパー・アプリケーション・プログラム・インターフェースを使って対話的ホワイトボード機器上のサードパーティー・コンテンツ協働サービスにアクセスするための手法」と題する米国特許出願第＿＿号（代理人整理番号49986-0883）および2016年12月19日に出願された「クロスライセンス認証を使って対話的ホワイトボード機器上のサードパーティー・コンテンツ協働サービスにアクセスするための手法」と題する米国特許出願第＿＿号（代理人整理番号49986-0884）に関係する。これらの内容全部は参照によって、あたかも本稿に完全に記載されているかのように、あらゆる目的についてその全体において組み込まれる。
【０００２】
分野
実施形態は、概括的には、コンピュータ・ネットワークを通じて実施される電子会議に関する。考えられるグループ技術ユニット：2625；考えられる分類：358。
【背景技術】
【０００３】
このセクションで記述されるアプローチは、追求されることができたが必ずしも以前に着想または追求されたアプローチではない。したがって、特に断りのない限り、このセクションにおいて記述されるアプローチは本願の請求項に対する従来技術ではないことがあり、このセクションに含まれることによって従来技術であると認められるものではない。
【０００４】
対話的ホワイトボード（IWB:  interactive  whiteboard）機器はユーザーが文書およびファイルといった電子的な情報を共有することを許容し、リアルタイムで他のIWB、クライアント装置、モバイル・アプリケーションおよびサードパーティー解決策と協働する。IWBのいくつかの顕著な特徴は、注釈付け、ファイル共有および同期、OCRならびにローカルな機能を含む。たとえば、異なる地理的位置にいるユーザーがリアルタイムで電子文書を閲覧し、論じ、注釈付けすることができる。IWBはまた、リアルタイムの協働をさらに容易にすることに向けたサードパーティー・ビデオ会議解決策をもって構成されてもよい。サードパーティー・ビデオ会議解決策は典型的には、IWB上でいわゆる「浅い統合（shallow  integration）」を使って、すなわち、IWBのグラフィカル・ユーザー・インターフェース・メニューを介して立ち上げられるホワイトボードの上の別個のプロセスとして、実装される。
【０００５】
この型の「浅い統合」には、IWB機能をサードパーティーのビデオ会議解決策に統合する能力が限られることや多数のサードパーティーのビデオ会議解決策をサポートし管理することの難しさおよび追加的な複雑さを含め、いくつか望ましくない特性がある。たとえば、IWBは潜在的に多数のサードパーティーのビデオ会議解決策を管理しなければならず、そのことは必要とされる計算資源の量を増し、それぞれのサードパーティー・ビデオ会議解決策のためのコントロールでグラフィカル・ユーザー・インターフェースが混雑することもある。さらに、サードパーティー・ビデオ会議解決策のグラフィカル・ユーザー・インターフェースのルックアンドフィールは互いに異なり、IWBのネイティブなグラフィカル・ユーザー・インターフェースのルックアンドフィールとも異なる。また、「浅い統合」は、企業クライアント・アプリケーションをモバイル・アプリケーション上で管理するために使うことさえできない。企業クライアント・アプリケーションによって作り出される複雑さおよびユーザー・インターフェース（UI）混雑のためである。さらに、ユーザーたちは異なるビデオ会議解決策を介して互いと通信することはできず、それぞれのビデオ会議解決策によって別個にユーザー認証が実行されなければならない。
【発明の概要】
【課題を解決するための手段】
【０００６】
対話的ホワイトボード（IWB）機器が一つまたは複数のプロセッサおよび一つまたは複数のメモリ、ユーザー・インターフェース、注釈付けアプリケーションおよび協働アプリケーションを有する。注釈付けアプリケーションはIWB機器上で実行されて、IWB機器のユーザーが、IWB機器のユーザー・インターフェースに表示された電子コンテンツに注釈付けする（annotate）ことを許容するよう構成される。協働アプリケーションもIWB上で実行されて、管理サービスを介して、それぞれ相異なるアプリケーション・プログラム・インターフェース（API）をサポートする複数のサードパーティー協働サービスにアクセスするよう構成される。該管理サービスは、前記協働アプリケーションおよび前記複数のサードパーティー協働サービスの両方と別個であり、前記複数のサードパーティー協働サービスの前記相異なるAPIとは異なるAPIをサポートする。協働アプリケーションは管理サービスのAPIをサポートするが、前記複数のサードパーティー協働サービスの前記相異なるAPIをサポートしない。この手法は、一つまたは複数のプロセッサによって処理されるときに前記機能を実行させる命令を記憶している一つまたは複数の非一時的なコンピュータ可読媒体によって実装されてもよい。この手法は、一つまたは複数のコンピュータ実装される方法によって実装されてもよい。
【図面の簡単な説明】
【０００７】
付属の図面において、同様の参照符号は同様の要素を指す。
【図１】対話的ホワイトボード（IWB）機器上での協働を管理するための例示的な構成を描くブロック図である。
【図２Ａ】OneLaunchアプリケーションの呼び出しの際に表示される、本稿で「OneLaunchパネル」と称される初期画面を描く図である。
【図２Ｂ】ユーザーがOneLaunchパネルから「ログイン」オプションを選択するのに応答してOneLaunchアプリケーションによって表示されるログイン画面を描く図である。
【図２Ｃ】選択されたサードパーティー協働サービスのためのユーザーIDおよびパスワードの形のユーザー・クレデンシャルをユーザーが入力することを許容するユーザー・クレデンシャル画面を描く図である。
【図２Ｄ】現在ログインしているユーザーがOneLaunchパネルから「通話」オプションを選択することに応答してOneLaunchアプリケーションによって表示される例示的な電子会議画面を描く図である。
【図２Ｅ】ユーザーがOneLaunchパネルから「部屋」オプションを選択することに応答してOneLaunchアプリケーションによって表示される部屋画面を描く図である。
【図２Ｆ】ユーザーがOneLaunchパネルから「会議」オプションを選択することに応答してOneLaunchアプリケーションによって表示される例示的な会議管理画面を描く図である。
【図２Ｇ】ユーザーがOneLaunchパネルから「連絡先」オプションを選択することに応答してOneLaunchアプリケーションによって表示される例示的な連絡先画面を描く図である。
【図２Ｈ】ユーザーがOneLaunchパネルから「共有」オプションを選択することに応答してOneLaunchアプリケーションによって表示される例示的な共有画面を描く図である。
【図３】OneLaunch  APIによってサポートされる例示的なコマンドおよび対応する引数を指定するテーブルである。
【図４Ａ】OneLaunchマネージャのOneLaunch  APIおよびAPIマネージャがサードパーティー協働サービスのための統一されたAPI呼び出しを提供する構成を描く図である。
【図４Ｂ】OneLaunchマネージャのOneLaunch  APIおよびAPIマネージャがOneLaunch  APIによってサポートされる一つまたは複数のデータ・プロトコルおよびフォーマットと、サードパーティー協働サービスによって必要とされるデータ・プロトコルおよびフォーマットとの間のデータ変換サービスを提供する構成を描く図である。
【図４Ｃ】サードパーティー協働サービスが複数のバージョンのAPIをサポートし、APIマネージャがそれぞれのサードパーティー協働サービスについて使用されるべきAPIの適切なバージョンを決定する構成を描く図である。
【図４Ｄ】サービスBがAPIのバージョン1.0、2.0および3.0を含む三つのバージョンをサポートする構成を描く図である。
【図５】サードパーティー協働サービスのAPIの属性を指定する例示的なAPIデータを描くテーブルである。
【図６Ａ】サードパーティー協働サービス１０８のためのライセンス鍵を記憶するライセンス鍵テーブルを描く図である。
【図６Ｂ】サードパーティー協働サービスのためのユーザー加入データを記憶するユーザー加入テーブルを描く図である。
【図６Ｃ】種々のサードパーティー協働サービスに関わる機能／動作を許諾するために使われる認証トークンを記憶する認証トークン・テーブルを描く図である。
【図６Ｄ】異なるサードパーティー協働サービスを使うユーザーの間の協働をサポートするためにOneLaunchマネージャによって使用されるクロスライセンス認証トークンを記憶するクロスライセンス認証トークン・テーブルを描く図である。
【図６Ｅ】サードパーティー協働サービスについてのユーザー加入データを記憶するユーザー状態テーブルを描く図である。
【図６Ｆ】協働会議のための状態情報を記憶する会議状態テーブルを描く図である。
【図７Ａ】ユーザーが異なるサードパーティー協働サービスを使って電子的に協働することを許容するクロスライセンス協働の論理的な概観を描くブロック図である。
【図７Ｂ】クロスライセンス認証トークンを使うための手法を描く流れ図である。
【図８】ログイン手順の間のさまざまな要素の間の例示的な対話を描くメッセージ・シーケンス図である。
【図９】実施形態が実装されうるコンピュータ・システムのブロック図である。
【発明を実施するための形態】
【０００８】
以下の記述では、説明の目的のために、数多くの個別的詳細が、本発明の十全な理解を与えるために記述される。しかしながら、本発明がそうした個別的詳細なしでも実施されうることは当業者には明白であろう。他方、よく知られた構造および装置は、本発明を無用に埋没させるのを避けるために、ブロック図の形で示される。本発明のさまざまな側面が以下のセクションにおいて記述される。
Ｉ．概観
ＩＩ．アーキテクチャー
ＩＩＩ．OneLaunchユーザー・インターフェース
Ａ．ログイン
Ｂ．通話
Ｃ．部屋
Ｄ．送信
Ｅ．チャット
Ｆ．会議
Ｇ．連絡先
Ｈ．共有
ＩＶ．API管理
Ｖ．ライセンス鍵管理
ＶＩ．クロスライセンス協働
ＶＩＩ．動作例
ＶＩＩＩ．実装例
〈Ｉ．概観〉
IWB上での協働を管理するための手法により、異なるサードパーティー協働サービスのユーザーがIWB上での協働会議に参加できるようになる。本手法は、たとえユーザーが異なるサードパーティー協働サービスを使っていても、ユーザーが、注釈付けのようなIWBによって提供される協働機能を使い、互いと通信することを許容する。本手法は、「単一ラッパー」アプリケーション・プログラム・インターフェース（API）および協働会議の中央集中した管理を提供する協働マネージャを使う。該管理は、ライセンス鍵およびトークン管理、クロスライセンス協働、ユーザー管理および会議管理を含む。協働マネージャは、異なるサードパーティー協働サービスのAPIを扱う仲介層のはたらきをし、不均一な協働クライアントを使っている諸ユーザーが協働会議に参加できるようにする。
【０００９】
〈ＩＩ．アーキテクチャー〉
図１は、IWB上での協働を管理するための例示的な構成１００を描くブロック図である。図１に描いた例では、構成１００はIWB  １０２およびクライアント装置１０４の形のクライアント装置、OneLaunchマネージャ１０６およびサードパーティー協働サービス１０８を含む。これらの要素は、たとえばインターネットや一つまたは複数の直接有線接続もしくは無線接続を含む一つまたは複数の有線または無線ネットワーク接続を介して通信上結合されてもよい。実施形態は図１に描かれる具体的な例示的構成１００に限定されるものではなく、実施形態は具体的な実装に依存して追加的なまたはより少数の要素を含んでいてもよい。
【００１０】
IWB  １０２およびクライアント装置１０４はそれぞれ、OneLaunchマネージャ１０６を介してサードパーティー協働サービス１０８へのアクセスを提供するOneLaunchアプリケーション１１０をもって構成される。サードパーティー協働サービス１０８はいかなる型の協働サービスであってもよく、たとえばオーディオ／ビデオ会議サービス、メッセージ交換サービス、チャット・サービス、デスクトップ、アプリケーションおよびデータ共有サービスなどであってもよい。
【００１１】
IWB  １０２は一つまたは複数のプロセッサと、一つまたは複数のメモリと、ユーザー・インターフェースとを含む。ユーザー・インターフェースはコンテンツをユーザーに対して表示し、タッチスクリーンによって実装されてもよい。タッチスクリーンは、情報を表示するとともに、たとえばメニュー項目を選択したりIWB  １０２に表示されたコンテンツに注釈付けしたりなどするためにユーザー入力を受け入れる。IWB  １０２は、一つまたは複数の有線または無線ネットワークを介して他の装置と通信するための有線および無線インターフェースを含んでいてもよい。ある実施形態によれば、IWB  １０２はスタンドアローンの装置として実装される。クライアント装置１０４はいかなる型のクライアント装置によって実装されてもよい。クライアント装置１０４の例示的実装は、限定なしに、デスクトップ・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピューティング装置、携帯情報端末（PDA）、モバイル装置、スマートフォン、多機能周辺装置（MFP:  multifunctional  peripheral）、スキャン装置などを含む。
【００１２】
OneLaunchアプリケーション１１０、１１２はそれぞれ、OneLaunchマネージャ１０６によって提供される機能およびデータへのアクセスを提供するOneLaunchアプリケーション・プログラム・インターフェース（API）１２０を介してOneLaunchマネージャ１０６にアクセスするよう構成される。OneLaunchアプリケーション１１０、１１２は、APIのようなサードパーティー協働サービス１０８の詳細を実装する必要なしにOneLaunchマネージャ１０６のOneLaunch  API  １２０を介して任意の数のサードパーティー協働サービス１０８にアクセスするいわゆる「シンクライアント」として実装されてもよい。このように、OneLaunchアプリケーション１１０、１１２は、IWB  １０２およびクライアント装置１０４上に各サードパーティー協働サービス１０８について別個のクライアントをインストールする必要なしに、サードパーティー協働サービス１０８へのクライアント側アクセスを提供する。用語「アプリケーション」は本稿では説明目的のために使われているだけであり、OneLaunchアプリケーション１１０、１１２はスタンドアローンのアプリケーション自身に限定されない。OneLaunchアプリケーション１１０、１１２はそれぞれスタンドアローンのプロセス、プラグイン・モジュール、ウィジェット、ライブラリなどとして実装されてもよい。もう一つの例として、IWB  １０２上で、OneLaunchアプリケーション１１０はGUIウィンドウとして実装されてもよい。IWB  １０２およびクライアント装置１０４は、具体的な実装に依存して変わりうる他のアプリケーションおよびプロセスとともに構成されてもよい。ある実施形態によれば、IWB  １０２は、IWB  １０２の一または複数のユーザーが、IWB  １０２のユーザー・インターフェース上に表示される電子文書、スプレッドシート、電子メール、オーディオ／ビデオ・コンテンツなどといった電子コンテンツに注釈付けすることを許容する注釈付けアプリケーションをもって構成される。
【００１３】
本稿で「管理サービス」とも称されるOneLaunchマネージャ１０６は、IWB  １０２およびクライアント装置１０４に代わってサードパーティー協働サービス１０８を実装する一つまたは複数のプロセスである。このやり方では、OneLaunchマネージャ１０６は、OneLaunchアプリケーション１１０、１１２とサードパーティー協働サービス１０８との間の仲介層のはたらきをし、中央集中式にデータおよび通信を管理する。下記でより詳細に述べるように、ある実施形態によれば、OneLaunchマネージャ１０６は、サードパーティー協働サービス１０８のためのソフトウェア開発キット（SDK:  software  development  kits）、APIおよびライブラリを実装することによって、いわゆる「深い統合」を使う。深い統合は、ユーザー、フィーチャーおよび全体的なエンドツーエンドのユーザー経験を管理するためにサードパーティー協働サービス１０８の、より粒度の細かい制御を提供し、また、OneLaunchアプリケーション１１０、１１２上でのUIの混雑を軽減する。OneLaunchマネージャ１０６はクロスライセンス協働をも提供する。クロスライセンス協働は、サードパーティー協働サービスの雑多な集合を横断して諸ユーザーの雑多な大きな集合が接続されることを許容するための、ライセンス鍵の中央管理に関わる。
【００１４】
OneLaunchマネージャ１０６は、コンピュータ・ソフトウェア、コンピュータ・ハードウェアまたはコンピュータ・ソフトウェアおよびコンピュータ・ハードウェアの任意の組み合わせで実装されうる。OneLaunchマネージャ１０６は、IWB  １０２およびクライアント装置１０４によって呼び出されるスタンドアローンのプロセス、プラグイン、ライブラリなどとして実装されてもよい。いくつかの実施形態が本稿では説明の目的のために単一のプロセスとしてのOneLaunchマネージャ１０６のコンテキストで記述されるが、実施形態はこの例示的実装に限定されない。OneLaunchマネージャ１０６は、IWB  １０２およびクライアント装置１０４を含む一つまたは複数のコンピューティング装置またはネットワーク要素上で実行されてもよい。
【００１５】
図１に描かれるように、OneLaunchマネージャ１０６は、OneLaunchアプリケーション１１０、１１２によって使われるOneLaunch  API  １２０を含んでいる。OneLaunchマネージャ１０６は、OneLaunch  API  １２０に準拠する、OneLaunchアプリケーション１１０、１１２からの要求を受け取り、それらの要求を管理プロセス１３０にルーティングするサーバー１２２をも含んでいる。サーバー１２２は、データ１５０へのアクセス、データ変換の実行などといった他の機能をも実行してもよい。たとえば、サーバー１２２は、OneLaunch  API  １２０によってサポートされるデータ・フォーマットとサードパーティー協働サービス１０８によってサポートされるデータ・フォーマットとの間のデータ変換を実行してもよい。管理プロセス１３０は、APIマネージャ１３２、ユーザー・マネージャ１３４、認証情報マネージャ１３６、会議マネージャ１３８、ライセンス・マネージャ１４０および存在（Presence）マネージャ１４２を含む。これらの管理プロセスは図１では単に説明の目的のために別個のプロセスとして描かれており、これらのマネージャによって提供される機能は具体的な実装に依存して変わりうる任意の数のプロセスにおいて編成され、実装されてもよい。APIマネージャ１３２は、サードパーティー協働サービスのAPI要件を満たす要求を生成する。ユーザー・マネージャ１３４は、ユーザー・データ１５４に記憶されているユーザーに関するさまざまな型のデータを維持する。会議マネージャ１３８は、協働会議を管理し、会議データ１５８を維持する。ライセンス・マネージャ１４０は、サードパーティー協働サービスのためのライセンス鍵を管理する。存在マネージャ１４２は、ユーザー・データ１５４の一部として維持されうるユーザー状態データを管理する。
【００１６】
OneLaunchマネージャ１０６は、APIデータ１５２、ユーザー・データ１５４、認証（auth）データ１５６、会議データ１５８、ライセンス・データ１６０および存在データ１６２を含むさまざまな型のデータ１５０を管理するためのアドミニストレーター１４５をも含む。このデータの一つまたは複数の部分が、OneLaunchマネージャ１０６のユーザー、たとえばアドミニストレーターによって生成され、管理されてもよい。ユーザー・データ１５４は、複数のユーザーのそれぞれに対応する一つまたは複数のサードパーティー協働サービス１０８を指定してもよい。たとえば、ユーザー・データ１５４は、第一のユーザーが特定のベンダーによって提供されるサードパーティー協働サービス１０８のユーザーであることを指定してもよい。ユーザー・データ１５４は各ユーザーについての連絡先をも指定してもよい。
【００１７】
〈ＩＩＩ．OneLaunchユーザー・インターフェース〉
ある実施形態によれば、OneLaunchアプリケーション１１０、１１２は、OneLaunchマネージャ１０６を介してサードパーティー協働サービス１０８にアクセスするための共通のグラフィカル・ユーザー・インターフェースを実装する。共通のグラフィカル・ユーザー・インターフェースは、具体的な実装に依存して変わりうる幅広い多様な仕方で実装されうる。たとえば、共通のグラフィカル・ユーザー・インターフェースは、アプリケーション・ベースのユーザー・インターフェースとして、ウェブ・ベースのユーザー・インターフェースとして、または任意のアプリケーションもしくはシステムにつなぐことのできるプラガブル（pluggable）・アーキテクチャーとしてなどで実装されうる。これは、複数のサードパーティー協働サービスを横断して共通の「ルックアンドフィール」をもつ共通のグラフィカル・ユーザー・インターフェースを提供することによって、より好ましいユーザー経験を提供する。たとえば、使われているサードパーティー協働サービスに関わりなく、ウィンドウおよびコントロールの位置および配置ならびに色および他の視覚効果が同じになる。さらに、共通のグラフィカル・ユーザー・インターフェースの「ルックアンドフィール」は、具体的な実装のために、組織内の複数のクライアント装置を横断して特定の「ルックアンドフィール」を提供するよう、たとえばいわゆる「スキン」を使って調整されてもよい。図示され、以下で論じられるさまざまなグラフィカル・ユーザー・インターフェース画面の「ルックアンドフィール」および機能は、ログイン・プロセスの間にユーザーによって選択される特定のサードパーティー協働サービスに基づいて変更されてもよい。これについては図２Ｂに関して下記でより詳細に述べる。これはたとえば、異なるサードパーティー協働サービスのための論理に基づいて、異なるウィンドウ、コントロールなどを表示することを含んでいてもよい。
【００１８】
図２Ａは、OneLaunchアプリケーション１１０、１１２の呼び出しに際して表示される、本稿で「OneLaunchパネル」２００と称される初期画面を描いている。OneLaunchパネル２００は、サードパーティー協働サービス１０８によって提供されるさまざまな協働機能にアクセスするためのコントロールを提供する。ある実施形態によれば、これらのコントロールは、IWB機器１０２において使われている任意のサードパーティー協働サービスを横断して共通であり、よって、OneLaunch〔ワンローンチ〕パネル２００は、任意の協働サービスへの単一のインターフェース点のはたらきをする。図２Ａに描いた例では、コントロールは、OneLaunchサービスにログインするための「ログイン」コントロール、音声／ビデオ通話を開始するための「通話」コントロール、部屋にアクセスし管理するための「部屋」コントロール、他のユーザーまたは会議参加者に電子情報を送るための「送信」コントロール、チャット・セッションを開始するための「チャット」コントロール、進行中の会議を閲覧し、加わるための「会議」コントロール、連絡先にアクセスするための「連絡先」コントロールおよび会議の参加者と電子情報を共有するための「共有」コントロールを含む。これらの機能はIWB機器で普通に実装されているが、実施形態はこれらの例に限定されず、本稿に記載される手法は、IWB機器上で実装されうる任意の型の機能に適用可能である。これらの機能のそれぞれは、以下で、より詳細に記述する。OneLaunchパネル２００で提供されるおよび／または有効にされる具体的なオプションは、各サードパーティー協働サービス１０８によって提供されるサービスに依存して変わりうる。たとえば、「チャット」コントロールは、ユーザーがチャット・サービスを提供しない特定のサードパーティー協働サービス１０８にログインするときには無効にされてもよい。
【００１９】
〈Ａ．ログイン〉
ログイン機能はユーザーがOneLaunchサービスにログインすることを許容する。図２Ｂは、ユーザーがOneLaunchパネル２００から「ログイン」オプションを選択することに応答してOneLaunchアプリケーション１１０、１１２によって表示されるログイン画面２１０を描いている。ログイン画面２１０はユーザーが、該ユーザーが登録されている任意のサードパーティー協働サービスにログインすることを許容する。図２Ｃは、選択されたサードパーティー協働サービスのために、ユーザーIDおよびパスワードの形のユーザー・クレデンシャルをユーザーが入力することを許容するユーザー・クレデンシャル画面２２０を描いている。ユーザー・クレデンシャル画面２２０は一例として与えられており、具体的なサードパーティー協働サービスの要件に依存して、他のユーザー・クレデンシャルがユーザーに尋ねられてもよい。コントロール２２２は、ユーザーが入力されたユーザー・クレデンシャルを確認する、または取り消して図２ＡのOneLaunchパネル２００に戻ることを許容する。ある実施形態によれば、ユーザーがどのサードパーティー協働サービスのアカウントももたない場合には、ユーザーは、ソーシャル・ネットワーク・サービス、たとえばグーグル＋、フェイスブックなどといった認証情報プロバイダー（identity  provider）を使ってログインしてもよい。たとえば、コントロール２２２は、選択されるとユーザーが選択された認証情報プロバイダーのためのログイン・クレデンシャルを与えることによって認証情報プロバイダーにログインできるオプションを含んでいてもよい。
【００２０】
ひとたびユーザー・クレデンシャルが入力され確認されたら、OneLaunchアプリケーション１１０、１１２はそれらのユーザー・クレデンシャルを他の情報とともにOneLaunch  API  １２０を介してOneLaunchマネージャ１０６に渡す。該他の情報は、使用されるべき特定のサードパーティー協働サービスを特定するデータおよび任意的には機械パラメータのような他の情報である。するとOneLaunchマネージャ１０６はそれらのユーザー・クレデンシャルを、ユーザー認証のために、選択されたサードパーティー協働サービスのAPIを使って、選択されたサードパーティー協働サービスに提供する。ひとたびユーザーがサードパーティー協働サービスについて認証されたら、OneLaunchマネージャ１０６は認証データ１５６を更新する。ユーザーが以前に認証されていて、該以前の情報がまだ有効である状況もありうる。この状況では、ユーザーはサードパーティー協働サービスについて再認証される必要はなく、OneLaunchマネージャ１０６は認証データ１５６を使ってユーザーをサードパーティー協働サービスにログインさせることができる。あるいはまた、OneLaunchマネージャ１０６は、必要とされる認証データを要求するよう選択されたサードパーティー協働サービスに要求を送って、次いで、この情報がユーザーに尋ねられるよう、OneLaunchアプリケーション１１０、１１２に通知してもよい。ユーザー認証成功後、連絡先画面が表示されてもよい。これについてはのちにより詳細に述べる。あるいはまた、ユーザーはOneLaunchパネル２００に戻されてもよい。
【００２１】
〈Ｂ．通話〉
通話機能は、ユーザーが、一または複数の他のユーザーと音声／ビデオ通話（call）を開始することを許容する。図２Ｄは、現在ログインしているユーザーがOneLaunchパネル２００から「通話」オプションを選択することに応答してOneLaunchアプリケーション１１０、１１２によって表示される例示的な電子会議（meeting）画面２３０を描いている。ログインしていないユーザーが「通話」オプションを選択すると、ログイン画面２１０が表示される。
【００２２】
電子会議画面２３０は、電子文書、オーディオ／ビデオ情報、デスクトップおよび画面内容などといった電子情報およびコンテンツ２３４を表示し、共有するための表示／共有領域２３２を含む。電子会議画面２３０は、通話の参加者がそこから選択されうるまたはすでに選択されている、連絡先２３６の集合をも含んでいる。こうして、連絡先２３６は、通話のための候補参加者、現在の参加者または候補参加者と現在の参加者の両方を含んでいてもよく、通話中の任意の時点において参加者が追加されてもよい。ユーザーは、連絡先２３６から特定の連絡先を選択し、選択された連絡先を通話に加えるために「通話に追加」コントロールを選択してもよい。連絡先２３６のそれぞれの状態を示すために、たとえば視覚的指示の形の追加的な情報が提供されてもよい。当該現在ログインしているユーザーは、会議主催者またはまとめ役（organizer）として指定されてもよい。
【００２３】
電子会議画面２３０は、ビデオ・コンテンツおよび／またはビデオ会議ウィンドウを表示するためのビデオ領域２３８、電子チャット・セッションを実施するためのチャット領域２４０およびイベント履歴を表示するイベント・ログ２４２をも含む。「戻る」コントロール２４４は、ユーザーが図２ＡのOneLaunchパネル２００に戻ることを許容する。実施形態は、図２Ｄに描かれた例示的な電子会議画面２３０に限定されるものではなく、電子会議画面２３０の具体的な配置、序列および内容は具体的な実装に依存して変わりうる。
【００２４】
〈Ｃ．部屋〉
「部屋」コントロールは、ユーザーが部屋にアクセスし、部屋を管理することを許容する。本稿での用法では、用語「部屋」は、二人以上の参加者の間でのプライベートな会合を指す。部屋は、公衆には知られず、可視でなくてもよく、参加者に知られるだけであってもよい。部屋はユーザー認証を必要としてもよく、その一方で会議はユーザー認証を必要としなくてもよい。図２Ｅは、ユーザーがOneLaunchパネル２００から「部屋」オプションを選択することに応答してOneLaunchアプリケーション１１０、１１２によって表示される部屋画面２５０を描いている。部屋画面２５０は、現在の部屋の集合を表示する。ユーザーは、部屋画面２５０から部屋を選択してもよい。選択された部屋に加わるためである。ユーザーは、該ユーザーがその部屋に入室するために必要なクレデンシャルまたは認証をもつ場合に、選択された部屋に入室することが許容される。そうでない場合には、そのユーザーについての部屋に入室する要求が、選択された部屋のまとめ役に送信される。選択された部屋のまとめ役が要求を承認したら、ユーザーは選択された部屋へのアクセスを承認される。いくつかの実装では、部屋は特定のサードパーティー協働サービスに固有であってもよく、すべてのサードパーティー協働サービスについて有効にされなくてもよい。ある実施形態によれば、OneLaunchパネル２００における「部屋」オプションは、ユーザーが部屋サービスをサポートするサードパーティー協働サービスにログインしているときにのみ有効にされる。
【００２５】
部屋画面２５０は、今の例においてユーザーが部屋およびユーザーに関するさまざまな機能を実行することを許容するコントロール２５２を含む。これは、部屋に入室すること、新たな部屋を作成すること、既存の部屋を削除すること、既存の部屋からユーザーを削除すること、既存の部屋にユーザーを追加することまたは部屋情報をコピーすることを含む。たとえば、マウスなどのポインティング・デバイスなどを使って部屋画面２５０から特定の部屋を選択した後、ユーザーは、部屋に入室するために「部屋に入室」コントロール２５２を選択する、選択された部屋を削除するために「部屋を削除」コントロールを選択する、選択された部屋からユーザーを削除するために「部屋からユーザーを削除」コントロール２５２を選択する、選択された部屋にユーザーを追加するために「部屋にユーザーを追加」を選択する、あるいは選択された部屋から部屋情報をコピーするために「部屋情報をコピー」コントロール２５２を選択するなどしてもよい。「部屋からユーザーを削除」コントロール２５を選択することに応答して、ユーザーは、選択された部屋の現在ユーザーのリストを呈示され、ユーザーは、その部屋から削除されるべき現在のユーザーの一または複数を選択してもよい。「部屋にユーザーを追加」コントロール２５２を選択することに応答して、ユーザーは連絡先からのユーザーのリストを呈示され、ユーザーは、選択された部屋に追加されるべき一または複数のユーザーを選択してもよい。「新たな部屋を作成」コントロール２５２を選択することに応答して、ユーザーが名前、パーミッションなどの新たな部屋の属性を指定することを許容するダイアログボックスが表示される。部屋情報をコピーの機能は、部屋において共有されているコンテンツが別の部屋に、たとえばURLを介してコピーされることを許容する。「戻る」コントロール２５４はユーザーが図２ＡのOneLaunchパネル２００に戻ることを許容する。
【００２６】
〈Ｄ．送信〉
送信機能は、ユーザーが電子文書または他のコンテンツのような電子情報を一または複数の他のユーザーおよび／または会議参加者に送ることを許容する。ユーザーがOneLaunchパネル２００から「送信」オプションを選択することに応答して、ユーザーが送るべき電子情報を選択することを許容するナビゲーション・ウィンドウが表示されてもよい。ひとたび送るべき電子情報が選択されたら、ユーザーは連絡先および／または会議リストから一または複数の受取人を選択してもよい。電子情報を会議参加者に送るために、ユーザーはログインしていて、その会議に出ている必要がある。
【００２７】
〈Ｅ．チャット〉
チャット機能は、ユーザーが会議内の一または複数の他の参加者とチャットすることを許容する。たとえば、ログインして電子会議画面２３０を呈示された後、ユーザーは、チャット領域２４０を選択して、チャット・セッションに関するコントロールの集合にアクセスしてもよい。それらのコントロールは、ユーザーが既存のチャットに加わったり、あるいは会議内の一または複数の参加者との新たなチャットを生成したりすることを許容しうる。ユーザーは、会議内の選択されたユーザー、会議内の全ユーザーまたは特定のサードパーティー協働サービス１０８からのユーザーを含みうる。たとえば、ユーザーは、新たなチャットに含めるために、一または複数のIBM  Sametimeユーザーまたは特定の協働サービスからのユーザーを選択してもよい（Cisco  Jabberユーザーのみとのチャットを可能にするため）。
【００２８】
〈Ｆ．会議〉
会議機能は、ユーザーが現在および将来の会議にアクセスすることを許容する。図２Ｆは、ユーザーがOneLaunchパネル２００から「会議」オプションを選択することに応答してOneLaunchアプリケーション１１０、１１２によって表示される例示的な会議管理画面２６０を描いている。会議管理画面２６０は、実施されている現在の電子会議と、会議名、会議主催者、部屋および時間を含む各電子会議についての情報とを表示する。会議は公開でもプライベートでもよく、会議の公開またはプライベート状態は、会議管理画面２６０上で視覚的に示されてもよい。参加／招待要求（招待）コントロールは、ユーザーが電子会議に加わるまたは電子会議への招待を要求することを許容する。参加／招待要求コントロールを選択すると、すでに招待／許諾されているユーザーは電子会議に加わることができる。電子会議に加わると、選択された電子会議について、「通話」オプションに関して本稿で先に述べたように電子会議画面２３０（図２Ｄ）が表示されてもよい。まだ電子会議に加わるよう招待／許諾されていないユーザーについては、参加／招待要求コントロールを選択すると、会議のまとめ役または主催者に要求が送られる。会議まとめ役または主催者が要求を受け入れるかどうかを決定するとき、指示が提供されてもよい。
【００２９】
会議管理システム２６０はまた、将来の電子会議と、会議名、会議主催者、部屋および日時を含む各将来の電子会議についての情報とを表示する。招待要求（招待）コントロールが、ユーザーが将来の電子会議への招待を要求することを許容する。招待要求コントロールを選択すると、会議のまとめ役または主催者に要求が送られる。「戻る」コントロール２６２はユーザーが図２ＡのOneLaunchパネル２００に戻ることを許容する。
【００３０】
〈Ｇ．連絡先〉
連絡先機能は、ユーザーが連絡先およびその状態を見ることを許容する。図２Ｇは、ユーザーがOneLaunchパネル２００から「連絡先」オプションを選択することに応答してOneLaunchアプリケーション１１０、１１２によって表示される例示的な連絡先画面２７０を描いている。連絡先画面２７０は、連絡先のリストおよび各連絡先の現在の状態を示す。ある実施形態によれば、連絡先は、ユーザー・データ１５４の一部としてOneLaunchマネージャ１０６によって維持される。連絡先はユーザー・マネージャ１３４を介して生成され、管理されてもよい。これは、ユーザーが複数のサードパーティー協働サービス１０８を横断して連絡先を見ることを許容するという恩恵をもたらす。図２Ｇに描かれる例では、現在の状態は異なる記号によって視覚的に指示されているが、これはほんの一例であり、状態は具体的な実装に依存して変わりうる幅広い多様な仕方で視覚的に指示されうる。たとえば、現在の状態は、色、陰影、特殊視覚効果などを使って視覚的に示されてもよい。ある実施形態によれば、現在の状態は、オンラインであり手すき、オンラインであり会議中、オンラインであり離席中（away）、オンラインであり攪乱禁止（do  not  disturb）、オフラインであり手すきでない、ユーザーなどによって指定されうるカスタム状態を含みうる。実施形態はこれら具体的な状態に限定されるものではなく、他の状態が使われてもよい。ビュー・コントロール２７２は、ユーザーが利用可能なビューのリストからビューを選択することを許容する。ビューは、連絡先をフィルタリングする方法を提供する。これは、ユーザーが多数の連絡先をもっている状況において有用であることがある。例示的なビューは、限定なしに、オンラインの連絡先といった特定の状態をもつ連絡先、特定の会議にいる連絡先およびグーグル・ハングアウト、MSリンク、IBM  Sametimeなどといった特定のサードパーティー協働サービス１０８に登録している連絡先を含む。「戻る」コントロール２７４がユーザーが図２ＡのOneLaunchパネル２００に戻ることを許容する。
【００３１】
〈Ｈ．共有〉
共有機能は、ユーザーがアーチファクト（artifact）、文書、スクリーンまたは他の任意の電子情報を電子会議における他のユーザーと共有することを許容する。図２Ｈは、ユーザーがOneLaunchパネル２００から「共有」オプションを選択することに応答してOneLaunchアプリケーション１１０、１１２によって表示される例示的な共有画面２８０を描いている。共有画面２８０は、ユーザーが共有オプションを選択することを許容する。ここで、各共有オプションは共有される電子情報の型に対応する。図２Ｈで描かれている例では、オプションは、アプリケーション、ウィンドウおよびスクリーンを含む。実施形態はこの例に限定されるものではなく、他の型の電子情報の共有を許容してもよい。図２Ｈに描かれている例では、ユーザーはアプリケーションを会議における他のユーザーと共有することを選択しており、この選択に応答して、共有されうるアプリケーションのリストが表示される。ユーザーは、ウェブ・ブラウザーを共有することを選択しており、コントロール２８２はユーザーがこの選択を確認または取り消しすることを許容する。ひとたび共有のために項目が確認されたら、ユーザーは、選択された情報が共有される特定の電子会議を選択するオプションを与えられる。たとえば、現在の電子会議のリストが、特定の電子会議を選択するためのコントロールと一緒に表示されてもよい。共有を停止するためのコントロールも設けられてもよい。
【００３２】
〈ＩＶ．API管理〉
OneLaunchマネージャ１０６は、OneLaunchアプリケーション１１０、１１２がサードパーティー協働サービス１０８のAPIの詳細を認識または実装する必要なしにサードパーティー協働サービス１０８によって提供されるサービスにアクセスすることを許容する、単一のラッパーOneLaunch  API  １２０を提供するために「深い統合」を使う。ある実施形態によれば、APIマネージャ１３２が、サードパーティー協働サービス１０８にアクセスするための統一されたAPI呼び出し、データ変換およびバージョン管理を提供することによって、この機能を提供する。OneLaunchマネージャ１０６は、OneLaunch  API  １２０に準拠する要求を処理して、サードパーティー協働サービス１０８のAPIに準拠する要求をサードパーティー協働サービス１０８に与える。これは、具体的な実装に依存して変わりうる幅広い多様な処理を使って実装されうる。たとえば、APIマネージャ１３２は、OneLaunchアプリケーション１１０、１１２から受領された要求を、最小限の処理でまたは処理なしに、サードパーティー協働サービス１０８に転送してもよい。これはたとえば、OneLaunch  API  １２０に準拠する要求が最小限の処理でまたは処理なしでサードパーティー協働サービス１０８のAPIの要件を満たす状況において起こりうる。あるいはまた、APIマネージャ１３２はさまざまな型の処理を実行して、サードパーティー協働サービス１０８のAPIの要件を満たす要求を生成してもよい。たとえば、APIマネージャ１３２は、OneLaunch  API  １２０の要件を満たす要求から、コマンド、パラメータ、引数、値などといったデータを検査し、抽出し、次いでサードパーティー協働サービス１０８のためのAPIの要件を満たし、かつOneLaunch  API  １２０の要件を満たす要求から抽出されたデータの一部または全部を含む要求を生成してもよい。これは、OneLaunch  API  １２０の要件を満たす要求から抽出されたデータの一つまたは複数の部分を変換または翻訳することを含んでいてもよい。APIマネージャ１３２は、API鍵およびURLの管理のような他の機能を実行してもよい。サードパーティー協働サービス１０８のAPIの要件を満たす呼び出しの生成は、APIマネージャ１３２によって実装される論理によって達成されてもよい。
【００３３】
OneLaunch  API  １２０によってサポートされる具体的な機能は、具体的な実装に依存して変わってもよく、実施形態はいかなる特定の実装にも限定されない。図３は、OneLaunch  API  １２０によってサポートされる例示的なコマンドおよび対応する引数を指定するテーブル３００を描いている。図３に描かれるように、これらのコマンドは概括的には、電子会議、オーディオ／ビデオ通話およびコンテンツ共有に関するコンテンツ協働機能を実行することに関する。実施形態はこれらのコンテキストに限定されず、他のコンテキストに適用可能である。さらに、具体的な実装に依存して、より少数のまたは追加的なコマンドがサポートされてもよく、実施形態は図３に描かれる例示的なコマンドをサポートするOneLaunch  API  １２０に限定されない。テーブル３００の内容はたとえばAPIデータ１５２に、構造化されていないまたは構造化されたデータとして、任意のフォーマットにおいて記憶されてもよい。
【００３４】
図４Ａは、OneLaunchマネージャ１０６のOneLaunch  API  １２０およびAPIマネージャ１３２がサードパーティー協働サービス１０８のための統一されたAPI呼び出しを提供する構成４００を描いている。図４Ａに描いた例では、サードパーティー協働サービス１０８はサービスＡ、サービスＢおよびサービスＣを含む。OneLaunch  API  １２０は、前記コマンド、データ、パラメータ、引数およびサードパーティー協働サービス１０８のためのAPIの要件を満たす呼び出しを生成するためにAPIマネージャ１３２によって必要とされる他の任意の情報を定義する。
【００３５】
図４Ａに描いた例では、OneLaunchアプリケーション１１０が、OneLaunch  API  １２０のログインAPI  ４０２に準拠するログイン要求を生成する。このログイン要求は、アクセスされるべき特定のサードパーティー協働サービス１０８を、その特定のサードパーティー協働サービス１０８によって必要とされるユーザー・クレデンシャルと一緒に指定する。今の例では、この要求はWebexならびにユーザーID（「JackD」）およびパスワード（「doghouse」）の形のユーザー・クレデンシャルを指定すると想定される。たとえば、ログイン要求は「Login/service=webex&user=JackD&password=doghouse」の形を取ってもよい。ログイン要求はOneLaunchマネージャ１０６によって受領され、サーバー１２２によってAPIマネージャ１３２にルーティングされる。サーバー１２２は該要求に基づいて処理してもよく、たとえばデータ１５０にアクセスしてさまざまな論理および判断の実装を実行してもよい。図４Ａ〜図４Ｄでは特に描かれていないが、OneLaunchマネージャ１０６によって受領される要求は初期にサーバー１２２によって処理され、処理のために管理プロセス１３０の一つにルーティングされる。
【００３６】
今の例では、APIマネージャ１３２はログイン要求を受け取り、処理して、サービスＡのAPIに準拠する処理された要求または新たな要求を生成する。ある実施形態によれば、APIマネージャ１３２はAPIデータ１５２を使って、処理された要求または新たな要求を生成してもよい。APIデータ１５２は、各サードパーティー協働サービス１０８のAPIを記述する、すなわち各サードパーティー協働サービスのAPIの一つまたは複数の属性を定義するデータを含む。
【００３７】
図５は、サードパーティー協働サービス１０８のAPIの属性を指定する例示的なAPIデータを描くテーブル５００である。この例において、テーブル５００はサービス・プロバイダー、サービス、機能、APIを記述するデータ（これはAPIを記述するデータへのリンクの形であってもよい）、APIによってサポートされるプロトコルもしくはフォーマット、バージョン、状態、特定のバージョンがそのAPIのデフォルト・バージョンであるかどうかおよびたとえばある特定のバージョンが好ましいバージョンであるかどうかを示しうるコメントを指定する。たとえば、テーブル５００の第一行は、Ciscoによって提供される「Webex」サービスのための「ログイン」機能を実行するためのAPIデータを指定する。APIデータは、「ログイン」機能を実行するためのURLアドレスおよび引数を指定するデータを含む。第一行は、「REST」のようなフォーマット、「2.0」のようなAPIデータのバージョン、「アクティブ」のような状態、APIのその特定のバージョンがデフォルト・バージョンであるかどうかを指定しており、バージョン2.0が好ましいバージョンであることを示すコメントはない。先の例を参照するに、APIマネージャ１３２はサービス名、ユーザーIDおよびパスワードを受領された要求から抽出して、Cisco  Webex  APIの要件を満たす要求を生成する。たとえば、要求は「https://server.cisco.com/Login/user=JackD&password=doghouse」であってもよい。もう一つの例として、ユーザーが最近ログインしたのであって認証トークン（authentication  token）がのちにより詳細に述べる認証トークン・テーブル６２０において利用可能である場合には、要求は「https://server.cisco.com/Login/authentication=SomeAuthenticationToken」であってもよい。
【００３８】
ある実施形態によれば、要求が使うべきAPIのバージョンを指定していないときは、デフォルトまたは好ましいと指定されるAPIバージョンが使われる。「好ましい」としてまたはデフォルト・バージョンとして指示されていないAPIバージョンは、要求がサードパーティー協働サービス１０８の一つのためのAPIの特定のバージョンを指定する状況において使われてもよい。たとえば、プロバイダー「ABC」についてのAPIデータ１５２は「コンファレンス」サービスのための「ログイン」機能を実行するためのAPIの三つのバージョン（V1、V3、V4）を含み、バージョンV3およびV4のほうが新しいバージョンであるにもかかわらず、バージョンV1が「好ましい」バージョンとして指定されている。OneLaunchアプリケーション１１０、１１２から受領された「ABC‐コンファレンス」サービスについての「ログイン」要求は、APIの特定のバージョンを指定しないことがありうる。この状況では、APIマネージャ１３２は、APIデータ１５２に基づいて、バージョンV1が「ABC‐コンファレンス」サービスについてのAPIの好ましいバージョンであることを判別し、その要求を、その特定のサードパーティー協働サービスに提供される要求がAPIのバージョンV1の要件を満たすことを保証するような仕方で、処理する。あるいはまた、OneLaunchアプリケーション１１０、１１２から受領された要求は、「ABC‐コンファレンス」サービスについてのAPIのV3またはV4を指定していることがあり、APIマネージャ１３２は、その要求を、その特定のサードパーティー協働サービスに提供される要求が前記要求において指定されたその特定のサードパーティー協働サービスについての特定のAPIのバージョンの要件を満たすことを保証するような仕方で、処理する。このようにして、APIマネージャ１３２は、クライアントおよびサーバー側でエラーを最小にするようテーブル５００から適切なAPIを選択し、そのAPIを、なされた要求のためにシームレスに機能させる。
【００３９】
テーブル５００の内容は、サードパーティー協働サービス１０８によってサポートされるAPIの現在バージョンがテーブル５００において表わされることを保証するよう、アドミニストレーターのようなユーザーによって、生成され、維持されてもよい。こうして、APIマネージャ１３２は、APIデータ１５２を使って、処理された要求または新たな要求がサービスＡのためのAPIの現在のサポートされているバージョンに正しく準拠することを保証する。次いで、APIマネージャ１３２は処理されたログイン要求をサービスＡに転送する。ある実施形態によれば、APIが最新でなくなるのを避け、エラーを防ぐために、テーブル５００の内容は最新のAPIデータを用いて定期的にメンテナンスされる。
【００４０】
ひとたびOneLaunchマネージャ１０６から受領されたら、ログイン要求を指定されたサービスが処理し、指定されたサービスのAPIに準拠する応答をAPIマネージャ１３２に提供する。APIマネージャ１３２は該応答を処理し、OneLaunch  API  １２０に準拠する処理された応答を生成し、処理された応答を、もとの要求を送ったエンティティ（これは今の例ではOneLaunchアプリケーション１１０）に転送する。このようにして、OneLaunchマネージャ１０６はOneLaunchアプリケーション１１０、１１２のために統一された単一のラッパーAPIを提供し、OneLaunch１１０、１１２とサードパーティー協働サービス１０８との間で要求および応答の流れおよび処理を扱う。
【００４１】
ある実施形態によれば、APIマネージャ１３２は、種々のデータ・プロトコル、言語および／またはデータ・フォーマットを扱う機能を含む。これにより、OneLaunchアプリケーション１１０、１１２は、サードパーティー協働サービス１０８によって必要とされるデータ・プロトコルおよびフォーマットをサポートする必要なしに、OneLaunch  API  １２０によってサポートされるデータ・プロトコルおよびフォーマットのみをサポートすればよい。図４Ｂは、OneLaunchマネージャ１０６のOneLaunch  API  １２０およびAPIマネージャ１３２がOneLaunch  API  １２０によってサポートされる一つまたは複数のデータ・プロトコルおよびフォーマットと、サードパーティー協働サービス１０８によって必要とされるデータ・プロトコルおよびフォーマットとの間のデータ変換サービスを提供する構成４００を描いている。
【００４２】
図４Ｂに描いた例では、OneLaunchマネージャ１０６のOneLaunch  API  １２０はREST（Representational  State  Transfer［表現による状態転送］）をサポートし、一方、サービスＡは単純オブジェクト・アクセス・プロトコル（SOAP:  Simple  Object  Access  Protocol）をサポートし、サービスＢはRESTをサポートし、サービスＣは拡張可能マークアップ言語（XML:  Extensible  Markup  Language）をサポートする。APIマネージャ１３２は、目標となるサードパーティー協働サービス１０８に依存して、要求をRESTからSOAP、RESTまたはXMLに変換するよう構成される。APIマネージャ１３２は、応答をSOAP、RESTまたはXMLからRESTに変換するようにも構成される。このようにして、OneLaunchマネージャ１０６は、OneLaunchアプリケーション１１０、１１２のためにデータ・プロトコルおよびデータ・フォーマット変換サービスを提供し、それによりOneLaunchアプリケーション１１０、１１２はサードパーティー協働サービス１０８によって必要とされるデータ・プロトコルおよびデータ・フォーマットをサポートする必要はない。これは、多数の雑多なサードパーティー協働サービスが、それらがサポートするデータ・フォーマットやプロトコルに関わりなく、接続されることを許容する。
【００４３】
いくつかの状況では、サードパーティー協働サービス１０８はAPIの複数のバージョンをサポートする。ある実施形態によれば、APIマネージャ１３２は、サードパーティー協働サービス１０８についてのAPIの適切なバージョンを選択し、次いでAPIのそのバージョンと整合する変換サービスを実行する機能を含む。図４Ｃは、サードパーティー協働サービス１０８が複数のバージョンのAPIをサポートし、APIマネージャ１３２がそれぞれのサードパーティー協働サービス１０８について使用されるべきAPIの適切なバージョンを決定する構成４００を描いている。図４Ｃに描いた例では、APIマネージャ１３２は、APIのバージョン3.0がサービスＡのために使用されるべきであり、APIのバージョン2.0がサービスＢのために使用されるべきであり、APIのバージョン3.0がサービスＣのために使用されるべきであることを判別する。
【００４４】
図４Ｄは、サービスＢがAPIのバージョン1.0、2.0および3.0を含む三つのバージョンをサポートする構成４００を描いている。図４Ｄに示されるように、APIマネージャ１３２はバージョン2.0がサービスＢのために使われるべきAPIの適切なバージョンであることを判別している。サードパーティー協働サービス１０８についてのAPIの好ましいバージョンがAPIデータ１５２によって指定されてもよく、これはたとえばアドミニストレーターによって構成されてもよい。ある実施形態によれば、APIマネージャ１３２は、エラー・ハンドリング・サービスを提供するよう構成される。これはたとえば、目標となるサードパーティー協働サービス１０８について、APIサポートがないまたは最新でないAPIサポートがあることを判別することを含んでいてもよい。たとえば、OneLaunchマネージャ１０６は、サービスＡを使ってチャット・サービスを開始するようOneLaunchアプリケーション１１０から要求を受け取ってもよい。その要求の処理の間に、APIマネージャ１３２はサービスＡについてのAPIサポートがない、または不十分なAPIサポートがあることを判別する。この判別をするのに応答して、APIマネージャ１３２はサービスＡについてのAPIサポートがないまたは不十分なAPIサポートがあることを示す、OneLaunchアプリケーション１１０へのエラー・メッセージを生成して送信する。
【００４５】
〈Ｖ．ライセンス鍵管理〉
サードパーティー協働サービスがそのサービスを使うためにユーザーが許諾されることを求めることが珍しくない。許諾（authorization）は、具体的な実装に依存して変わりうる幅広い多様な機構によって提供されうる。一例として、サードパーティー協働サービスは、要求に対応するユーザーがそのサービスを使うことを許諾されていることを確かめるためにライセンス鍵の使用を必要としてもよい。たとえば、ユーザーは、特定のサードパーティー協働サービスを使うために有効なライセンス鍵のもとで許諾されていることが求められてもよい。ある実施形態によれば、OneLaunchマネージャ１０６は、ユーザーが現在ライセンスされていることを必要とするサードパーティー協働サービス１０８を介した協働をサポートするために、さまざまな型のライセンス・データ、ユーザー加入データ、ユーザー状態データおよび会議データを管理する。
【００４６】
図６Ａは、サードパーティー協働サービス１０８のためのライセンス鍵を記憶するライセンス鍵テーブル６００を描いている。ライセンス鍵テーブル６００の各行は、ビジネス組織のような組織に対して発行されたライセンス鍵に対応し、サービス・プロバイダー、サービス、組織の名前、ライセンス鍵、組織内でのライセンス鍵を使うことが許諾されているユーザーの数、ライセンス鍵の失効日、ライセンス鍵の状態およびライセンス鍵に関するコメントを指定する。図６Ａに描かれた例では、データのすべては組織「XYZ」および三つの異なるサービスについてであるが、実際上は、ライセンス鍵テーブル６００は任意の数の組織およびサービスについてのデータを含みうる。ライセンス鍵テーブル６００は、OneLaunchマネージャ１０６のアドミニストレーターのようなユーザーによって生成され、維持されてもよく、要求をサードパーティー協働サービス１０８に対して発する前に該要求が対応する有効なライセンス鍵を有するかどうかを判定することによって、ライセンス・マネージャ１４０によって使われてもよい。ライセンス鍵テーブル６００はライセンス・データ１６０の一部として維持されてもよい。
【００４７】
図６Ｂは、サードパーティー協働サービス１０８のためのユーザー加入データを記憶するユーザー加入テーブル６１０を描いている。ユーザー加入テーブル６１０の各行はユーザーに対応し、サービス・プロバイダー、サービス、組織の名前、そのユーザーのためのユーザーID、そのユーザーのための連絡先番号、現在の加入状態（「Sub  Status」）およびコメントを指定する。連絡先電話番号は説明目的のために使われるだけであり、具体的な実装に依存して他の型の連絡先情報が使われてもよい。図６Ｂに描かれた例では、データのすべては組織「XYZ」および三つの異なるサービスおよび三人のユーザーについてであるが、実際上は、ユーザー加入テーブル６１０は任意の数の組織、サービスおよびユーザーについてのデータを含みうる。ユーザー加入テーブル６１０は、OneLaunchマネージャ１０６のアドミニストレーターのようなユーザーによって生成され、維持されてもよく、ユーザーが特定のサードパーティー協働サービスに現在加入しているかどうかを判定するためにユーザー・マネージャ１３４によって使われてもよい。この情報は、多くの異なる目的のために、たとえばユーザーに対して特定のサードパーティー協働サービス１０８に現在ログインしている他のユーザーを示すために、使用されうる。ユーザー加入テーブル６１０はユーザー・データ１５４の一部として維持されてもよい。
【００４８】
図６Ｃは、種々のサードパーティー協働サービス１０８に関わる機能／動作を許諾するために使われる認証トークンを記憶する認証トークン・テーブル６２０を描いている。認証トークン・テーブル６２０の各行はユーザーに対応し、サービス・プロバイダー、サービス、組織の名前、ユーザーID、認証トークン、トークン状態、失効までの日数（「……で失効」）、ユーザーの存在または状態およびコメントを指定する。図６Ｃに描かれた例では、データのすべては組織「XYZ」および三つの異なるサービスおよび三人の異なるユーザーについてであるが、実際上は、認証トークン・テーブル６２０は任意の数の組織、サービスおよびユーザーについてのデータを含みうる。認証トークンは、ユーザーによって、たとえばOneLaunchマネージャ１０６のアドミニストレーターによって手動で指定されてもよい。これはたとえば、ユーザー・クレデンシャルがそれらの特定のサードパーティー協働サービス１０８に別個に登録される状況においてなされてもよい。これらの状況では、登録完了に際してサードパーティー協働サービス１０８によって発行される登録トークンが手動で認証データ１５６に入力されてもよい。あるいはまた、認証トークンは、ユーザーがOneLaunchマネージャ１０６を介してサードパーティー協働サービス１０８にログインした後にサードパーティー協働サービス１０８によってユーザー毎に発行されてもよい。たとえば、認証情報マネージャ１３６がサードパーティー協働サービス１０８から受領されたログイン応答から認証トークンを抽出してもよい。認証トークンは限られた寿命をもち、その特定のサードパーティー協働サービス１０８に基づいて（または管理ユーザーによって手動で指定されるところにより）最終的には失効し、置換されなければならない。認証トークン・テーブル６２０は、OneLaunchマネージャ１０６のアドミニストレーターのようなユーザーによって認証データ１５６において生成され、維持されてもよく、種々のサードパーティー協働サービス１０８に関わる機能／動作を管理するために認証情報マネージャ１３６によって使われる。特定のサードパーティー協働サービス１０８についての認証トークンの数は、その特定のサードパーティー協働サービス１０８についてライセンス鍵によって許諾されるユーザーの数に等しい。認証トークン・テーブル６２０は認証データ１５６の一部として認証情報マネージャ１３６によって維持されてもよい。
【００４９】
ある実施形態によれば、OneLaunchマネージャ１０６が要求、たとえば特定のユーザーがサードパーティー協働サービス１０８からの特定のサードパーティー協働サービスにアクセスするためのログイン要求を受け取るとき、ライセンス・マネージャ１４０がまず、ライセンス・データ１６０に基づいて、そのユーザーの組織が現在のライセンス鍵をもつかどうかを検証する。そうであれば、次いで、ライセンス・マネージャ１４０は、ユーザー・データ１５４に基づいて、その特定のユーザーがその特定のサードパーティー協働サービスに対するアクティブな加入をもつかどうかを検証する。そうであれば、次いで、ライセンス・マネージャ１４０は、認証トークン・テーブル６２０から、その特定のサードパーティー協働サービスに関するその特定のユーザーについての認証トークンを取り出す。取り出された認証トークンが、その特定のサードパーティー協働サービスのAPIにアクセスするためにAPIマネージャ１３２によって使われる。
【００５０】
〈ＶＩ．クロスライセンス協働〉
認証トークンは通常、特定のユーザーおよび特定のサードパーティー協働サービス両方に固有である。つまり、通常は、ユーザーは、ユーザーが使いたい一つ一つのサードパーティー協働サービスについて認証トークンをもつ必要がある。たとえば、特定のユーザーがサードパーティー協働サービスＡおよびＢの両方を使うためには、サービスＡに関してその特定のユーザーのために認証トークンが利用可能である必要があり、かつ、サービスＢに関してその特定のユーザーのために別個の認証トークンが利用可能である必要がある。さらに、ユーザーたちは同じサードパーティー協働サービスを使う必要がある。つまり、サードパーティー協働サービスＡのユーザーはサードパーティー協働サービスＢのユーザーと協働することはできない。これは発行され維持される必要のある認証トークンの数を大幅に増し、ライセンス鍵についての許諾されたユーザーの数をも増す。
【００５１】
これらの問題に対処するために、OneLaunchマネージャ１０６は、本稿で「クロスライセンス協働」と称されるものをサポートする。これは、ユーザーたちが異なるサードパーティー協働サービスを使って電子的に協働することを許容する。たとえば、サービスＡ、たとえばCisco  JabberのユーザーがサービスＢ、たとえばIBM  Sametimeのユーザーと協働できる。さらに、これは、一つ一つのサードパーティー協働サービスのためのユーザー固有の認証トークンを必要とすることなく達成される。ある実施形態によれば、OneLaunchマネージャ１０６は、特定のサードパーティー協働サービスに固有だが特定のユーザーに固有ではなく、よって複数のユーザーを横断して使用されうるクロスライセンス認証トークンを使う。これは、異なるサードパーティー協働サービスのユーザーが互いに協働することを許容する。
【００５２】
図６Ｄは、異なるサードパーティー協働サービス１０８を使うユーザーの間の協働をサポートするためにOneLaunchマネージャ１０６によって使用されるクロスライセンス認証トークンを記憶するクロスライセンス認証トークン・テーブル６３０を描いている。クロスライセンス認証トークン・テーブル６３０の各行は、ビジネス組織のような組織に対応し、サービス・プロバイダー、サービス、組織の名前、認証トークン、トークン状態、失効までの日数（「……で失効」）およびコメントを指定する。図６Ｄに描かれた例では、データのすべては組織「XYZ」および三つの異なるサービスについてであるが、実際上は、クロスライセンス認証トークン・テーブル６３０は任意の数の組織およびサービスについてのデータを含みうる。アドミニストレーターのようなユーザーが、ある組織または他の論理的なグループについて維持されるクロスライセンス認証トークンの数を確立してもよい。
【００５３】
クロスライセンス認証トークン・テーブル６３０における認証トークンは、たとえばOneLaunchマネージャ１０６の管理ユーザーによって、手動で指定されてもよい。認証トークンは、たとえば組織の管理ユーザーの汎用または一般的ユーザー・クレデンシャルを使って、サードパーティー協働サービス１０８から得られてもよい。次いで、認証トークン（単数または複数）がクロスライセンス認証トークン・テーブル６３０に手動で入力される。クロスライセンス認証トークン・テーブル６３０内の認証トークンは、組織での任意の数の論理的なエンティティについて取得されてもよい。たとえば、認証トークンは、事業部、部、プロジェクト、チームなどについて取得されてもよい。クロスライセンス認証トークン・テーブル６３０は、認証データ１５６の一部として認証情報マネージャ１３６によって維持されてもよい。ある実施形態によれば、クロスライセンス・トークンを同時に使用できるユーザー数はライセンス鍵制約によって制約される。
【００５４】
図６Ｅは、サードパーティー協働サービス１０８についてのユーザー加入データを記憶するユーザー状態テーブル６４０を描いている。テーブル６１０の各行はユーザーに対応し、サービス・プロバイダー、サービス、組織の名前、そのユーザーについてのユーザーID、そのユーザーについての連絡先番号、そのユーザーの現在状態、たとえば「オンライン」、「オフライン」、「ビジー」、「離席」などおよびコメントを指定する。上記のユーザー加入テーブル６１０と同様に、連絡先番号は説明目的のために使われるだけであり、具体的な実装に依存して他の型の連絡先情報が使われてもよい。図６Ｅに描かれた例では、データのすべては組織「XYZ」および三つの異なるサービスおよび三人のユーザーについてであるが、実際上は、ユーザー加入テーブル６１０は任意の数の組織、サービスおよびユーザーについてのデータを含みうる。ユーザー状態テーブル６４０は、OneLaunchマネージャ１０６のアドミニストレーターのようなユーザーによって生成され、維持されてもよい。ユーザー状態テーブル６４０は、特定のユーザーが使っているサービスを判別するためにAPIマネージャ１３２によって使用されてもよい。ユーザー状態テーブル６４０は、ユーザー・データ１５４の一部として維持されてもよい。
【００５５】
図６Ｆは、協働会議のための状態情報を記憶する会議状態テーブル６５０を描いている。会議状態テーブル６５０の各行は会議に対応し、会議ID、記述、サービス、組織の名前、会議まとめ役もしくは会議主催者についてのユーザーID、会議の現在状態、たとえば「これから」、「進行中」、「完了」などおよびコメントを指定する。図６Ｆに描かれた例では、会議のすべては組織「XYZ」および三つの異なるサービスおよび三人のユーザーについてであるが、実際上は、会議状態テーブル６５０は任意の数の組織およびサービスについてのデータを含みうる。会議状態テーブル６５０は、OneLaunchマネージャ１０６のアドミニストレーターのようなユーザーによって生成され、維持されてもよい。ユーザー状態テーブル６４０は、電子会議を管理するためにOneLaunchマネージャ１０６によって使用されてもよく、サードパーティー協働サービス１０８へのAPI呼び出しを生成するためにAPIマネージャ１３２によって使用されてもよい。会議状態テーブル６５０は、会議データ１５８の一部として会議マネージャ１３８によって維持されてもよい。
【００５６】
図７Ａは、ユーザーが異なるサードパーティー協働サービスを使って電子的に協働することを許容するクロスライセンス協働手法の論理的な概観を描くブロック図（７００）である。図７Ａに描いた例では、ユーザーＡがユーザーＢと電子的に協働する。ユーザーＡはサービスＡサーバー７２０によってホストされるサービスＡ  ７１０を使い、ユーザーＢはサービスＢサーバー７４０によってホストされるサービスＢ  ７３０を使う。この例において、サービスＡ  ７１０およびサービスＢ  ７３０は、オーディオ／ビデオ会議サービス、デスクトップ共有、アプリケーション共有またはデータ共有サービスなどのような協働サービスである。さらに、サービスＡ  ７１０およびサービスＢ  ７３０は異なるAPIをサポートする。
【００５７】
ある実施形態によれば、ユーザー間で協働、たとえばチャット・セッション、ビデオ会議セッション、デスクトップ、アプリケーションもしくはコンテンツ共有セッションなどが実行されるとき、APIマネージャ１３２が、二つ以上の型のサードパーティー協働サービスに関わるかどうかを判定する。APIマネージャ１３２は、たとえばユーザー状態テーブル６４０またはユーザー・データ１５４内の他のデータを参照することによってこの判定をしてもよい。協働に参加するユーザーが同じサードパーティー協働サービスを使っている場合には、APIマネージャ１３２は認証トークン・テーブル６２０からのユーザー固有の認証トークンを使う。たとえば、APIマネージャ１３２は、認証情報マネージャ１３６に、特定のサードパーティー協働サービス、組織およびユーザーについての認証トークンを要求してもよい。
【００５８】
二つ以上の型のサードパーティー協働サービスが協働のために使われる場合には、それらのサードパーティー協働サービスの諸APIにアクセスするためにユーザー固有の認証トークンを使う代わりに、APIマネージャ１３２は、特定のユーザーに固有ではないクロスライセンス認証トークン・テーブル６３０からの認証トークンを使う。より具体的には、APIマネージャ１３２は、特定のサードパーティー協働サービスのAPIにアクセスするときに該特定のサードパーティー協働サービスについてのクロスサービス認証トークンを含む。
【００５９】
図７Ａに描いた例を参照するに、サービスＡ  ７１０への呼び出しをするとき、APIマネージャ１３２は、サービスＡ  ７１０およびその組織に固有の認証トークンを使う。これは、APIマネージャ１３２が、サービスＡ  ７１０についてのAPIの要件を満たす要求を生成することを許容する。さらに、APIマネージャ１３２は、目標のサードパーティー協働サービス１０８（これは今の例ではサービスＡ  ７１０である）に対応する適切なAPIデータ１５２を使う。同様に、サービスＢ  ７３０への呼び出しをするとき、APIマネージャ１３２は、サービスＢ  ７３０およびその組織に固有の認証トークンを使う。さらに、APIマネージャ１３２は、サービスＢ  ７３０に対応する適切なAPIデータ１５２を使う。ある実施形態によれば、このようにしてユーザー固有の認証トークンの代わりにクロスサービス認証トークンを使うことは、協働に参加するユーザーが他のサードパーティー協働サービス１０８についての有効な個別の認証トークンをもつかどうかに関わりなく行なわれる。クロスサービス認証トークンが失効に近いときは、新たなクロスサービス認証トークンが得られるよう、管理者に通知が発されてもよい。
【００６０】
図７Ｂは、クロスライセンス認証トークンを使うための手法を描く流れ図７５０である。段階７５２では、OneLaunchマネージャ１０６は協働機能を実行するよう第一の要求を受領する。第一の要求はOneLaunchマネージャ１０６によって、OneLaunchアプリケーション１１０から受領されてもよく、第一の協働サービスの第一のユーザーおよび第二の協働サービスの第二のユーザーに関して協働機能が実行されることを要求するものである。協働機能は具体的な実装に依存して変わりうる幅広い多様な協働機能でありうる。今の例では、第一のユーザーはサービスＡ  ７１０のユーザーであり、第二のユーザーはサービスＢ  ７３０のユーザーであり、協働機能は第一のユーザーから第二のユーザーに、それぞれサービスＡ  ７１０およびサービスＢ  ７３０を介してメッセージを送信する要求であると想定される。
【００６１】
段階７５４では、OneLaunchマネージャ１０６および特にAPIマネージャ１３２が、それらのユーザーが同じ協働サービスを使っているかどうかを判定する。今の例では、APIマネージャ１３２は、第一のユーザーによって使われているサービスＡ  １７０が第二のユーザーによって使われているサービスＢ  ７３０と同じであるかどうかを判定する。この判定は、たとえばユーザー状態テーブル６４０またはユーザー・データ１５４内の他のデータを参照することによってなされてもよい。
【００６２】
段階７５４において、それらのユーザーが同じ協働サービスを使っているとの判定がなされたら、段階７５６において、OneLaunchマネージャ１０６は、第一のユーザーまたは第二のユーザーに固有な認証トークンを含む、前記協働機能を実行するための第二の要求を生成する。たとえば、APIマネージャ１３２は、サービスＢ  ７３０のAPIを定義する、APIデータ１５２からのデータと、第一のユーザーおよびサービスＢ  ７３０の両方に固有の認証トークンとを使って、第一のユーザーから第二のユーザーにメッセージを送信するための第二の要求を生成する。この第二の要求は、サービスＢ  ７３０のAPIを満たし、認証トークンは第一のユーザーに固有である。たとえば、サービスＢのための、認証トークン・テーブル６２０からの認証トークンが使われてもよい。
【００６３】
段階７５４において、それらのユーザーが異なる協働サービスを使っているとの判定がなされたら、段階７５８において、OneLaunchマネージャ１０６は、第一のユーザーまたは第二のユーザーに固有でない認証トークンを含む、前記協働機能を実行するための第二の要求を生成する。たとえば、APIマネージャ１３２は、サービスＢ  ７３０のAPIを定義する、APIデータ１５２からのデータと、サービスＢ  ７３０に固有だが第一のユーザーにも第二のユーザーにも固有でない認証トークンとを使って、第一のユーザーから第二のユーザーにメッセージを送信するための第二の要求を生成する。この第二の要求は、サービスＢ  ７３０のAPIを満たし、認証トークンはサービスＢのための、クロスライセンス認証トークン・テーブル６３０からのものでもよい。この例によって示されるように、OneLaunchマネージャ１０６は、OneLaunch  API  １２０の要件を満たす要求を受け取り、目標協働サービスのAPIの要件を満たす要求を生成する。OneLaunchマネージャ１０６は、OneLaunchアプリケーション１１０、１１２のためにライセンス鍵管理をも扱い、これは、ユーザーが異なる協働サービスを使う状況ではクロスライセンス認証トークンを使うことを含む。
【００６４】
認証トークンは、ユーザーによって、たとえばOneLaunchマネージャ１０６のアドミニストレーターによって手動で指定されてもよい。これはたとえば、ユーザー・クレデンシャルがそれらの特定のサードパーティー協働サービス１０８に別個に登録される状況においてなされてもよい。これらの状況では、登録完了に際してサードパーティー協働サービス１０８によって発行される登録トークンが手動で認証データ１５６に入力されてもよい。あるいはまた、認証トークンは、ユーザーがOneLaunchマネージャ１０６を介してサードパーティー協働サービス１０８にログインした後にサードパーティー協働サービス１０８によってユーザー毎に発行されてもよい。たとえば、認証情報マネージャ１３６がサードパーティー協働サービス１０８から受領されたログイン応答から認証トークンを抽出してもよい。認証トークンは限られた寿命をもち、その特定のサードパーティー協働サービス１０８に基づいて（または管理ユーザーによって手動で指定されるところにより）最終的には失効し、置換されなければならない。認証トークン・テーブル６２０は、OneLaunchマネージャ１０６のアドミニストレーターのようなユーザーによって認証データ１５６において生成され、維持されてもよく、種々のサードパーティー協働サービス１０８に関わる機能／動作を管理するために認証情報マネージャ１３６によって使われる。特定のサードパーティー協働サービス１０８についての認証トークンの数は、その特定のサードパーティー協働サービス１０８についてライセンス鍵によって許諾されるユーザーの数に等しい。
【００６５】
〈ＶＩＩ．動作例〉
図８は、ログイン手順の間の構成１００のさまざまな要素の間の例示的な相互作用を描くメッセージ・シーケンス図（８００）である。段階８０２において、ユーザーがOneLaunchアプリケーション１１０を介してログイン手順を開始する。たとえば、図２Ｂに関して本稿で先述したように、ユーザーは特定のサードパーティー協働サービスを選択し、図２Ｃにおいてユーザー・クレデンシャルを入力する。今の例では、「XYZ」という名前の組織に関連付けられた特定のユーザーであるユーザーAがサードパーティー協働サービスであるサービスAにアクセスすることを要求すると想定される。OneLaunchアプリケーション１１０はユーザーAについてのユーザー・クレデンシャルを他の情報と一緒に、OneLaunch  API  １２０を介してOneLaunchマネージャ１０６に渡す。他の情報とは、使用されるべき特定のサードパーティー協働サービス、すなわちサービスA、ユーザーに関連付けられた組織、すなわち「XYZ」を同定するデータおよび任意的には機械パラメータのような他の情報である。
【００６６】
段階８０４では、サーバー１２２は、OneLaunchアプリケーション１１０によって送信されたデータを受け取り、処理する。これは、段階８０４において、ライセンス検査を実行することを含む。ある実施形態によれば、これは、ライセンス・マネージャ１４０を介して、そのユーザーに関連付けられた組織について、有効なライセンス鍵が利用可能であるかどうかを判定することを含む。今の例では、ライセンス・マネージャ１４０は、ライセンス鍵テーブル６００がサードパーティー協働サービス、サービスAおよび組織「XYZ」についての有効なライセンス鍵を含むかどうかを判定する。ライセンス・マネージャ１４０は、検査の結果を示す、すなわちライセンス鍵テーブル６００がサードパーティー協働サービス、サービスAおよび組織「XYZ」についての有効なライセンス鍵を含むかどうかを示すサーバー１２２への応答を生成し、送信する。ライセンス・マネージャ１４０からの応答が、サードパーティー協働サービス、サービスAおよび組織「XYZ」についての有効なライセンス鍵が存在しないことを示す場合には、サーバー１２２はこの状態を示すメッセージを生成してOneLaunchアプリケーション１１０に送信する。
【００６７】
ライセンス・マネージャ１４０からの応答が、サードパーティー協働サービス、サービスAおよび組織「XYZ」についての有効なライセンス鍵が存在することを示す場合には、段階８０６において、サーバー１２２は加入検査を実行する。ある実施形態によれば、これは、ユーザー・マネージャ１３４を介して、ユーザーがそのサードパーティー協働サービスに現在加入しているかどうかを判定する。今の例では、ユーザー・マネージャ１３４は、ユーザー加入テーブル６１０がユーザーAがサービスAに現在加入していることを示すかどうかを判定する。ユーザー・マネージャ１３４は、検査の結果を示す、すなわちユーザー加入テーブル６１０がユーザーAがサービスAに現在加入していることを示すかどうかを示すサーバー１２２への応答を生成し、送信する。ユーザー・マネージャ１３４からの応答がユーザーAが現在サービスAに加入していないことを示す場合には、サーバー１２２はこの状態を示すメッセージを生成してOneLaunchアプリケーション１１０に送信する。
【００６８】
ユーザー・マネージャ１３４からの応答がユーザーAが現在サービスAに加入していることを示す場合には、段階８０８において、サーバー１２２はそのユーザーについての認証トークンを取得する。ある実施形態によれば、これはサーバー１２２が、認証情報マネージャ１３６に、サービスAおよび組織「XYZ」に関するユーザーAのための認証トークンを要求することを含む。認証情報マネージャ１３６は、認証トークン・テーブル６２０がサービスA、組織「XYZ」およびユーザーAに対応するエントリーを含むかどうかを判定する。認証情報マネージャ１３６は、検査の結果を示す、すなわち認証トークン・テーブル６２０がサービスA、組織「XYZ」およびユーザーAに対応するエントリーを含むことを示すサーバー１２２への応答を生成し、送信する。そのようなエントリーが存在する場合、応答はその認証トークンを含む。ユーザーAがサービスA以外の異なるサードパーティー協働サービスを使って他のユーザーと協働するであろうとわかっている状況では、認証情報マネージャ１３６は、本稿で先に述べたようにクロスライセンス認証トークン・テーブル６３０からのクロスライセンス認証トークンを提供してもよい。認証情報マネージャ１３６からの応答が、認証トークン・テーブル６２０がサービスA、組織「XYZ」およびユーザーAに対応するエントリーを含まないことを示す場合には、サーバー１２２は、この状態を示すメッセージを生成してOneLaunchアプリケーション１１０に送信する。
【００６９】
認証情報マネージャ１３６からの応答がサービスA、組織「XYZ」およびユーザーAについての認証トークンを含む場合には、段階８１０において、サーバー１２２は、そのサードパーティー協働サービスについてのAPI情報を取得する。APIマネージャ１３２が、そのサードパーティー協働サービスのAPIの要件を満たす要求を生成できるようにするためである。今の例では、サーバー１２２は、たとえばテーブル５００を介してサービスAについてのAPIを定義する情報を取得する。
【００７０】
段階８１２では、サーバー１２２は、ユーザーが現在ログインしていることを示すためにそのユーザーの状態を更新する。これはたとえば、認証情報マネージャ１３６が、ユーザーAが今サービスAにログインしていることを示す存在データ１６２を更新することを含んでいてもよい。
【００７１】
〈ＶＩＩＩ．実装例〉
本願の流れ図は特定の段階の集合を特定の順序で描いているが、他の実装は、図面に描かれているより少数またはより多数の段階を、同じまたは異なる順序で使ってもよい。
【００７２】
ある実施形態によれば、本稿に記載される技法は、一つまたは複数の特殊目的コンピューティング装置によって実装される。特殊目的コンピューティング装置は、本技法を実行するよう固定構成とされていてもよいし、あるいは本技法を実行するよう持続的にプログラムされた、一つまたは複数の特定用途向け集積回路（ASIC）またはフィールド・プログラマブル・ゲート・アレイ（FPGA）のようなデジタル電子デバイスを含んでいてもよいし、あるいはファームウェア、メモリ、他の記憶または組み合わせにおけるプログラム命令に従って本技法を実行するようプログラムされた一つまたは複数の汎用ハードウェア・プロセッサを含んでいてもよい。そのような特殊目的コンピューティング装置は、カスタムの固定構成論理、ASICまたはFPGAをカスタムのプログラミングと組み合わせて本技法を達成してもよい。特殊目的コンピューティング装置はデスクトップ・コンピュータ・システム、ポータブル・コンピュータ・システム、ハンドヘルド装置、ネットワーキング装置または本技法を実装するために固定構成および／またはプログラム論理を組み込んでいる他の任意の装置であってもよい。
【００７３】
図９は、実施形態が実装されうる例示的なコンピュータ・システム９００を描くブロック図である。コンピュータ・システム９００は、情報を通信するためのバス９０２または他の通信機構と、情報を処理するための、バス９０２に結合されたプロセッサ９０４とを含む。コンピュータ・システム９００は、ランダム・アクセス・メモリ（RAM）または他の動的記憶装置のような、情報およびプロセッサ９０４によって実行されるべき命令を記憶するための、バス９０２に結合されたメイン・メモリ９０６をも含む。メイン・メモリ９０６はまた、一時変数または他の中間的な情報を、プロセッサ９０４によって実行されるべき命令の実行の間、記憶しておくために使われてもよい。コンピュータ・システム９００はさらに、バス９０２に結合された、プロセッサ９０４のための静的な情報および命令を記憶するための読み出し専用メモリ（ROM）９０８または他の静的記憶装置を含む。磁気ディスクまたは光ディスクのような記憶装置９１０が提供され、情報および命令を記憶するためにバス９０２に結合される。
【００７４】
コンピュータ・システム９００は、コンピュータ・ユーザーに対して情報を表示するための、陰極線管（CRT）のようなディスプレイ９１２にバス９０２を介して結合されていてもよい。バス９０２は単一のバス９０２として示されているが、一つまたは複数のバスを含んでいてもよい。たとえば、バス９０２は、限定なしに、プロセッサ９０４がコンピュータ・システム９００内の他の装置を制御する制御バス、プロセッサ９０４が実行するための命令のメモリ位置を指定するためのアドレス・バスまたはコンピュータ・システム９００のコンポーネント間でデータまたは信号を伝達するための他の任意の型のバスを含んでいてもよい。
【００７５】
英数字その他のキーを含む入力装置９１４が、情報およびコマンド選択をプロセッサ９０４に伝えるためにバス９０２に結合される。もう一つの型のユーザー入力装置は、方向情報およびコマンド選択をプロセッサ９０４に伝えるとともにディスプレイ９１２上でのカーソル動きを制御するための、マウス、トラックボールまたはカーソル方向キーのようなカーソル・コントロール９１６である。この入力装置は典型的には、第一軸（たとえばx）および第二軸（たとえばy）の二つの軸方向において二つの自由度をもち、これにより該装置は平面内での位置を指定できる。
【００７６】
コンピュータ・システム９００は、本稿に記載される技法を実施するのに、カスタマイズされた固定構成論理、一つまたは複数のASICもしくはFPGA、コンピュータ・システムと組み合わさってコンピュータ・システム９００を特殊目的機械にするまたはプログラムするファームウェアおよび／またはプログラム論理またはコンピュータ・ソフトウェアを使ってもよい。ある実施形態によれば、それらの技法は、プロセッサ９０４がメイン・メモリ９０６に記憶されている命令を処理するのに応答して、コンピュータ・システム９００によって実行される。そのような命令は、記憶装置９１０のような別の非一時的なコンピュータ可読媒体からメイン・メモリ９０６に読み込まれてもよい。プロセッサ９０４によるメイン・メモリ９０６に含まれる命令の処理により、本稿に記載される機能が実行される。代替的な実施形態では、実施形態を実装するために、ソフトウェア命令の代わりにまたはソフトウェア命令と組み合わせて固定構成の回路が使用されてもよい。このように、実施形態は、ハードウェア回路とソフトウェアのいかなる個別の組み合わせにも限定されない。
【００７７】
本稿で用いられる用語「非一時的なコンピュータ可読媒体」は、コンピュータを特定の仕方で動作させるデータを提供することに参加する任意の非一時的な媒体を指す。コンピュータ・システム９００を使って実装されるある実施形態では、たとえば実行のためにプロセッサ９０４に命令を提供することにおいて、さまざまなコンピュータ可読媒体が関わる。そのような媒体は、不揮発性および揮発性の非一時的媒体を含むがそれに限られない多くの形を取りうる。不揮発性の非一時的媒体は、たとえば、記憶装置９１０のような光学式または磁気ディスクを含む。揮発性の非一時的媒体は、メイン・メモリ９０６のような動的メモリを含む。非一時的なコンピュータ可読媒体の一般的な形は、限定なしに、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープまたは他の任意の磁気媒体、CD-ROM、他の任意の光学式媒体、RAM、PROMおよびEPROM、フラッシュEPROM、NVRAM、他の任意のメモリ・チップ、メモリ・カートリッジまたはメモリ・スティックまたはそこからコンピュータが読み取りできる他の任意の媒体を含む。
【００７８】
さまざまな形の非一時的なコンピュータ可読媒体が、プロセッサ９０４による処理のための命令を記憶するのに関与しうる。たとえば、命令は最初、リモート・コンピュータの記憶媒体に記憶されていて、一つまたは複数の通信リンクを介してコンピュータ・システム９００に送信されてもよい。バス９０２がそのデータをメイン・メモリ９０６に搬送し、メイン・メモリ９０６から、プロセッサ９０４が命令を取り出し、処理する。メイン・メモリ９０６によって受信される命令は、任意的に、プロセッサ９０４による処理の前または後に記憶装置９１０上に記憶されてもよい。
【００７９】
コンピュータ・システム９００は、バス９０２に結合された通信インターフェース９１８をも含む。通信インターフェース９１８は、ローカル・ネットワーク９２２に接続されているネットワーク・リンク９２０への通信結合を提供する。たとえば、通信インターフェース９１８は、電話線へのデータ通信接続を提供するためのモデムであってもよい。もう一つの例として、通信インターフェース９１８は、互換LANへのデータ通信接続を提供するためのローカル・エリア・ネットワーク（LAN）カードであってもよい。無線リンクも実装されてもよい。そのようないかなる実装でも、通信インターフェース９１８は、さまざまな型の情報を表すデジタル・データ・ストリームを搬送する電気的、電磁的または光学的信号を送受信する。
【００８０】
ネットワーク・リンク９２０は典型的には、一つまたは複数のネットワークを通じた他のデータ装置へのデータ通信を提供する。たとえば、ネットワーク・リンク９２０は、ローカル・ネットワーク９２２を通じてホスト・コンピュータ９２４またはインターネット・サービス・プロバイダー（ISP）９２６によって運営されているデータ設備への接続を提供してもよい。ISP  ９２６は、現在一般に「インターネット」９２８と称される世界規模のパケット・データ通信網を通じたデータ通信サービスを提供する。ローカル・ネットワーク９２２およびインターネット９２８はいずれも、デジタル・データ・ストリームを担持する電気的、電磁的または光学的信号を使う。
【００８１】
コンピュータ・システム９００は、ネットワーク（単数または複数）、ネットワーク・リンク９２０および通信インターフェース９１８を通じて、メッセージを送り、プログラム・コードを含めデータを受信することができる。インターネットの例では、サーバー９３０は、インターネット９２８、ISP  ９２６、ローカル・ネットワーク９２２および通信インターフェース９１８を通じてアプリケーション・プログラムのための要求されたコードを送信してもよい。受信されたコードは、受信される際にプロセッサ９０４によって処理されても、および／または、のちの実行のために記憶装置９１０または他の不揮発性記憶に記憶されてもよい。
【００８２】
以上の明細書では、実施形態について、実装によって変わりうる数多くの個別的詳細に言及しつつ述べてきた。このように、何が本発明であるか、何が出願人によって本発明であると意図されているかの唯一にして排他的な指標は、この出願に対して付与される特許の請求項の、その後の訂正があればそれも含めてかかる請求項が特許された特定の形のものである。よって、請求項に明示的に記載されていない限定、要素、属性、特徴、利点もしくは特性は、いかなる仕方であれかかる請求項の範囲を限定すべきではない。よって、明細書および図面は制約する意味ではなく例示的な意味で見なされるべきものである。
【図１】
2018101417.tif 000003
【図２Ａ】
2018101417.tif 000004
【図２Ｂ】
2018101417.tif 000005
【図２Ｃ】
2018101417.tif 000006
【図２Ｄ】
2018101417.tif 000007
【図２Ｅ】
2018101417.tif 000008
【図２Ｆ】
2018101417.tif 000009
【図２Ｇ】
2018101417.tif 000010
【図２Ｈ】
2018101417.tif 000011
【図３】
2018101417.tif 000012
【図４Ａ】
2018101417.tif 000013
【図４Ｂ】
2018101417.tif 000014
【図４Ｃ】
2018101417.tif 000015
【図４Ｄ】
2018101417.tif 000016
【図５】
2018101417.tif 000017
【図６Ａ】
2018101417.tif 000018
【図６Ｂ】
2018101417.tif 000019
【図６Ｃ】
2018101417.tif 000020
【図６Ｄ】
2018101417.tif 000021
【図６Ｅ】
2018101417.tif 000022
【図６Ｆ】
2018101417.tif 000023
【図７Ａ】
2018101417.tif 000024
【図７Ｂ】
2018101417.tif 000025
【図８】
2018101417.tif 000026
【図９】
2018101417.tif 000027