JP2016530814A - 大量のｖｐｎ接続を遮断するためのゲートウェイデバイス - Google Patents

Abstract

【課題】【解決手段】ＶＰＮゲートウェイデバイスは、大規模なｐｅｒ−ａｐｐモバイル環境を可能にすることができる。モバイルデバイスのユーザが、モバイルデバイス上のアプリを開くときに、ＶＰＮゲートウェイは、そのアプリに、固有ＩＰアドレスを伝送する。ゲートウェイは、また、そのアプリに、アプリ連合クッキーも伝送する。アプリは、アプリ連合クッキーを第２のアプリと共有する。ＶＰＮゲートウェイは、次いで、第２のアプリに、同じ固有ＩＰアドレスを割り当てる。ゲートウェイは、次いで、第１のアプリに、ポート範囲を伝送する。アプリは、ポート範囲内のポートを、デバイスからＶＰＮゲートウェイへのデータ伝送のために使用する。ゲートウェイは、ＶＰＮを通じて第１のアプリからのデータ伝送を受信し、そのデータ伝送が第１のアプリから発していることを、ソースポートに基づいて決定する。【選択図】図９

Description

［関連出願の相互参照］
本出願は、米国特許法第１１９（ｅ）条の定めにより、２０１３年８月１５日に出願され発明の名称を「ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＲＥＰＯＲＴＩＮＧ Ａ ＪＡＩＬＢＲＯＫＥＮ／ＲＯＯＴＥＤ ＤＥＶＩＣＥ ＡＮＤ ＴＥＲＭＩＮＡＴＩＮＧ ＭＵＬＴＩＰＬＥ ＳＥＣＵＲＥ ＴＵＮＮＥＬ ＣＯＮＮＥＣＴＩＯＮＳ ＡＴ Ａ ＧＡＴＥＷＡＹ ＣＯＭＰＯＮＥＮＴ（ゲートウェイコンポーネントにおいて、ジェイルブレーク／ルート化されたデバイスを報告するための及び複数のセキュアトンネル接続を遮断するための、方法並びにシステム）」とする、Ｃｈａｍｐａｇｎｅ ｅｔ ａｌ．による米国仮出願第６１／８６６，３２０号の優先権を主張する。該出願は、参照によってその全体を本明細書に組み込まれる。

本発明は、ソフトウェア、コンピュータネットワーク通信、及びＶＰＮゲートウェイコンポーネントに関する。特に、本発明は、モバイルデバイス上のアプリと、ＶＰＮゲートウェイとの間に仮想プライベートネットワーク（ＶＰＮ）接続を作成することに関する。

ユーザが仕事のために又は企業体ファイアウォールの背後にあるサービスにアクセスするためにモバイルデバイス及びモバイルアプリを用いる企業体において、モバイルセキュリティの必要性が高まっている。モバイルデバイスからＶＰＮゲートウェイへのＶＰＮを提供する従来のソフトウェアがあるが、このようなソフトウェアは、セキュリティレベルが不十分であることが多く、また、企業体に対し、企業体対応アプリの使用に関する情報をほとんど提供しない。この従来のシナリオでは、１つのＶＰＮが、全ての企業体アプリからＶＰＮゲートウェイに来る全てのデータに使用される。別の言い方をすると、ＶＰＮは、デバイスレベルにある。個人のモバイルデバイス上において仕事関連のアプリを実行し、セキュアトンネルを通じて仕事関連又は企業体関連のサービスに接続する必要があるユーザの数が、増加を続けていることを踏まえると、モバイルデバイスと企業体ＶＰＮゲートウェイとの間で行き来する全てのデータに１本のＶＰＮパイプを使用するのでは、ハッカー及びその他の悪者が、データを盗用及び操作すること又は最終的に企業体に危害を加えるかもしれないマルウェアをモバイルデバイスに植え付けることを阻止するために必要とされるレベルのセキュリティを、提供することができない。

より高いレベルのセキュリティは、（デバイス全体は言うまでもなく）複数のアプリに１つのＶＰＮを共有させないこと、即ちデバイスレベルのセキュアＶＰＮトンネルを使用させないことを伴う。より優れたレベルのセキュリティとは、各アプリに、自身専用の対ゲートウェイＶＰＮを与えること、即ちセキュアで尚且つそのアプリのためのデータのみを運ぶ又は少なくともそのアプリ連合のためのデータのみを送るＶＰＮを与えることである。或るシナリオでは、個人のモバイルデバイス上の各企業体アプリが、（ユーザの雇用主、顧客、供給元などによって運営されている）企業体ゲートウェイへの自身専用のＶＰＮ接続を有する。更に、各ＶＰＮ接続が、プライベートな固有ＩＰアドレスを必要とするだろうことを念頭に置くと、企業体ＶＰＮゲートウェイは、大量のＶＰＮ接続（例えば、幾百又は幾千ものＶＰＮ）を管理及び作成することができる必要がある。企業体ＶＰＮゲートウェイは、また、この大量のＶＰＮ接続を遮断すること、並びに企業体の内部サーバとの間で行き来するトラフィックを管理することもできる必要がある。

本発明の一態様において、デバイス上のアプリと、ＶＰＮゲートウェイとの間でＶＰＮトンネルを通してデータを通信又は伝送する方法が説明される。モバイルデバイスユーザが、モバイルデバイス上のアプリを開くと、ＶＰＮゲートウェイは、そのアプリに、固有ＩＰアドレスを伝送する。ゲートウェイは、また、そのアプリに、アプリ連合クッキーも伝送する。アプリ（「第１のアプリ」）は、第２のアプリとアプリ連合クッキーを共有しており、第１及び第２のアプリは、モバイルデバイス上の或るアプリ連合内のアプリである。ＶＰＮゲートウェイは、次いで、第１のアプリに割り当てられたのと同じ固有ＩＰアドレスを第２のアプリに割り当てる。ゲートウェイは、次いで、第１のアプリに、（モバイルデバイスの）ポート範囲を伝送する。アプリは、そのアプリ範囲内のポートを、デバイスからＶＰＮゲートウェイへのデータ伝送のためのソースポートとして使用する。ゲートウェイは、第１のアプリからのデータ伝送を、ＶＰＮトンネルを通じて受信し、そのデータ伝送が第１のアプリから発していることを、ソースポートに基づいて決定する。

別の一実施形態では、ＶＰＮゲートウェイは、第２のアプリに、第２のポート範囲を伝送する。第２のアプリは、このポート範囲内のポートを、デバイスからゲートウェイへデータを伝送するためのソースポートとして使用する。ゲートウェイは、そのデータ伝送が第２のアプリから発していることを、ソースポートに基づいて決定する。別の一実施形態では、固有ＩＰアドレスは、同じ連合内の全てのアプリによって使用され、このようにすれば、連合内の各アプリは、自身の固有ＩＰアドレスは持たないが、依然として、ゲートウェイとの間に自身のプライベートＶＰＮを有する。別の一実施形態では、第１及び第２のアプリは、それらがラッピングされるときに、ＶＰＮゲートウェイＩＰアドレス及びＶＰＮゲートウェイドメイン名を伴うように設定され、それによって、各アプリは、その最初の実行時にゲートウェイに連絡することを可能にされる。アプリは、また、自身が受信した連合クッキーを連合内のその他のアプリと共有するように指示され、また、連合クッキーを要求されるかもしれないこと、又は、その実行時に連合クッキーを提供しなければならないかもしれないことを認識する。

説明の一部を構成し、例として本発明の具体的な実施形態が示された、添付の図面が参照される。

本発明のアプリ制御プロセスの概要を示したブロック図である。

本発明のアプリ制御プロセスの代替の一実施形態を示したブロック図である。

本発明の一実施形態にしたがったアプリセキュリティプログラムのコンポーネントを示したブロック図である。

本発明の一実施形態にしたがった、アプリをデバイスへのそのダウンロード前にセキュアにするプロセスを示したフローチャートである。

一実施形態にしたがった、ポリシーマネージャで実施される方法を示したフローチャートである。

一実施形態にしたがった、携帯端末又はモバイルデバイス上でセキュリティラップアプリが実行されるプロセスを示したフローチャートである。

一実施形態にしたがった、アプリセキュリティ制御システムのシステムアーキテクチャ図である。

一実施形態にしたがった、ｐｅｒ−ａｐｐ ＶＰＮを実装するために必要とされるモバイルデバイス内のコンポーネント及びモジュールを示したブロック図である。

本発明の一実施形態にしたがった、アプリＶＰＮを実装するプロセスを示したフローチャートである。

ネットワークのコンポーネントを示したブロック図であり、本発明の様々な概念が例示されている。

一実施形態にしたがった、企業体サーバから特定のアプリへどのようにデータをルーティングして戻すかを決定するためにゲートウェイデバイスによって実行されるプロセスを示したフローチャートである。 一実施形態にしたがった、ＶＰＮゲートウェイアクティブセッションモニタ画面を示したディスプレイのスクリーンショットである。 本発明の様々な実施形態を実現するのに適したコンピューティングシステムのブロック図である。 本発明の様々な実施形態を実現するのに適したコンピューティングシステムのブロック図である。

アプリケーションセキュリティプロセス及びアプリケーションセキュリティシステムの代表的な実施形態が説明される。これらの例及び実施形態は、単に、背景を追加するために及び本発明の理解を助けるために提供されるものである。したがって、当業者にならば、本発明が、本明細書で説明される具体的詳細の一部又は全部を伴わずとも実施されえることが明らかである。また、本発明を不必要に不明瞭にしないために、周知の概念の詳細な説明は省略されている。その他の用途及び例が可能であり、したがって、以下の例、説明、及び背景は、その範囲においてであれ設定においてであれ、決定的なもの又は限定的なものと捉えられるべきではない。これらの実施形態は、当業者が本発明を実施することを可能にするのに十分な詳しさで説明されているが、これらの例、説明、及び概念は、限定的なものではなく、本発明の趣旨及び範囲から逸脱することなくその他の実施形態が使用されること及び変更がなされることが可能である。

様々な図面において、デバイスソフトウェアアプリケーションがデバイスを、より具体的にはモバイルデバイスを、感染させること又はそれ以外の形で損なうことを防ぐための、方法及びシステムが説明されている。これらのタイプのアプリケーションは、スマートフォン、タブレット型コンピュータ、ゲーム機、及びポータブルコンピューティングデバイスなどの、多岐にわたるモバイルデバイスで使用されることが多く、「アプリ」と呼ばれるのが一般的である。これらのアプリは、テレビ、コンピュータ、自動車、及びその他の最先端高性能デバイスなどの、非モバイルデバイスにもダウンロード可能である。説明される方法及びシステムは、モバイルデバイス上での動作に限定されることを意図していない。これらのデバイスプログラム又はアプリは、増加の一途を辿り、今や非常に普及している。現在では、アプリは、Ｊａｖａ（登録商標、以下同じ）又はＣで記述されるのが通例である。本明細書で説明される方法及びシステムは、その他の言語で記述されたアプリ又は異なるプラットフォーム用に記述されたアプリにも適用可能である。全てではないにせよ、大半のアプリは、その意図する機能を実施するために必要な特定のサービスを得るために、モバイルデバイスのオペレーティングシステムと通信する必要があり、このようなサービスは、通常は、オペレーティングシステムからのみ入手可能である。使用されるこのようなサービスの一般的な例は、アプリが必要とするだろうデバイスの場所を得るためのＧＰＳである。しかしながら、この露出ゆえに、アプリは、デバイスにとっての脆弱性であり、セキュリティ及びプライバシーの危険をユーザにもたらす。会社は、そのデータ及びソフトウェアへのアクセスを制御する及びセキュアにするために、中央集権的なポリシーを強制できることを望む。これは、エンドユーザ（即ち、個人やホームユーザなど）にも当てはまる。このようなポリシーの強制は、企業体のＩＴ部門が企業データの統一性を維持することを可能にする。以下で説明される方法は、モバイルデバイスにダウンロードされるアプリがセキュリティ脅威を及ぼさないようにそれらのアプリのセキュリティを中央集権的に制御するための方法を提供する。ここで言うモバイルデバイスは、従業員の個人使用の電話又は雇用主の電話のいずれかである。本発明の様々な実施形態は、親及び個人が（即ち、家庭又は非仕事環境において）、その個人使用のモバイルデバイスがマルウェアから安全であることを確認するために使用されてもよく、また、使用などに対して制御を加えるために使用されてもよい。本発明のアプリ制御ソフトウェアの実施形態は、また、モバイルデバイスデータの保護及びバックアップに、並びにアプリケーションレベルのテレメトリングに使用されてもよい。

図１Ａは、本発明のアプリ制御プロセスの概要を示したブロック図である。これは、１つのプロセスの一般的な説明であり、特定の設定又は環境に縛られることはない。アプリプロバイダ１００によって、アプリ１０２が提供される。アプリプロバイダは、任意のタイプのエンティティ（個人、ソフトウェア開発者、雇用主など）であってよい。アプリは、通常は保護されておらず、それを包み込む唯一のセキュリティは、オペレーティングシステムによって提供される。しかしながら、オペレーティングシステムによって提供されるのは、デバイスに取り込まれたときにそこでどのように実行されるかに関してなされる保護及び照合のみである。

本発明は、デバイスのオペレーティングシステムによって提供されるのではない更なるアプリセキュリティを可能にする。アプリ１０２に、セキュリティアプリケーションプログラム１０４が適用される。或いは、アプリ１０２は、第三者のアプリセキュリティプロバイダによって供給されるだろうプログラム１０４に入力される。一実施形態では、セキュリティアプリケーションプログラム１０４は、ポリシーマネージャ及びポリシーラッパーを有し、これらは、それぞれ異なる場所にあってよい。これらは、図２で更に詳しく説明される。セキュリティプログラム１０４がアプリ１０２に適用されると、アプリはセキュリティ層によってラッピングされ、したがって、デバイスは保護される。これは、セキュアアプリ１０６として示されている。一実施形態では、セキュアアプリ１０６は、次いで、スマートフォン又はタブレット型コンピュータなどのモバイルデバイス１０８にダウンロードされ、そこで、デバイス１０８を損なう危険を伴うことなく安全に実行される。もう１つの利点は、セキュアアプリ１０６が、従業員にアプリを提供している雇用主などの、ユーザにアプリを提供している会社又はその他のエンティティによって管理されてもよいことである。例えば、もし、ユーザが会社から出ると、会社は、アプリ及び関連のあらゆるデータをデバイスから自動的に削除することができる。別の例では、親が、別の人物（例えば子供）によって使用されるアプリを制限する、又は例えば１日に１０分などの時間制限を加える、又はアプリによってアクセス可能なウェブサイトを制限することができる。或いは、親は、子供の居場所が見知らぬ第三者に漏出することを懸念する。その他に、多くの例が挙げられる。上記のように、図１は、アプリをセキュアにする及びデバイスにダウンロードする一般的なプロセスを示すことを意図している。ここで留意すべきは、この実施形態では、アプリ１０２が、デバイスにダウンロードされた後ではなくデバイスにダウンロードされる前に、デバイスに危害を加えないようにセキュアにされることである。別の一実施形態では、アプリは、デバイスにダウンロードされた後に、ただし、オペレーティングシステムとやり取りできる前に、セキュアにされる。

図１Ｂは、代替の一実施形態を示したブロック図である。モバイルデバイス１１２に、非セキュアアプリ１１０（やはりアプリプロバイダによって供給される）がダウンロードされる。この実施形態では、しかしながら、デバイス１１２上には、非セキュアアプリ１１０の実際のインストールをブロックする特殊設計のアプリがあってよい。この特殊アプリ（不図示）は、非セキュアアプリ１１０をアプリセキュリティプログラム１１４へリダイレクトする。非セキュアアプリ１１０は、セキュリティポリシーにラッピングされ、その結果得られたアプリが、セキュアアプリ１１６として示されている。セキュアアプリ１１６は、次いで、ダウンロードされ、デバイス１１２へのインストールを特殊アプリによって許可される。このようにすれば、例えば、アプリによって及ぼされるセキュリティ脅威から自身の電話を保護したいと考える個人又はホームユーザは、自身の電話にアプリがダウンロードされる前に、それらのアプリを、２つだけ例を挙げるとすると第三者サービス又は自身の携帯電話キャリアによって、セキュアにする（ラッピングする）ことができる。ここで留意すべきは、このセキュリティラッピングが、ユーザがどこからアプリをダウンロードするかに関係なく行えることである。また、図１Ａ及び図１Ｂでは、コンポーネントとソフトウェアとの間のネットワーク及び接続が、一般的に示されていることも留意されるべきである。伝送は、主に、インターネット（不図示）上であるが、プライベートネットワーク内であっても又はインターネット上及びプライベートネットワーク内の両方であってもよい。

図２は、本発明の一実施形態にしたがった、アプリケーションセキュリティプログラムのコンポーネントを示したブロック図である。一実施形態では、セキュリティプログラムは、２つの主要コンポーネント、即ちポリシーマネージャ及びポリシーラッパーを有する。ポリシーマネージャ２０２は、管理者からの、又はモバイルデバイスのためのセキュリティを設定する責任を担っているその他の個人からの、入力を受け付ける。その人物は、１つ以上のモバイルデバイスのセキュリティを統一しているゆえに、統治者と呼ぶことができる。セキュリティポリシーは、様々なユーザインターフェース画面を使用して設定されてよい。ポリシーの例は、多数あり、ジオフェンシング（例えば、アプリはビル内でのみ使用することができる）などが挙げられる。サービスプロバイダ、即ちアプリケーションプログラムを提供しているエンティティは、また、ホームユーザにとって有用だろうデフォルトポリシー及びセキュリティ設定も提供することができる。ポリシー設定の例が、以下で説明される。ポリシーマネージャ２０２に、ポリシー入力２０４が入力される。ポリシーマネージャ２０２は、統治者からの入力／設定を受けて、ポリシー又はメタデータ２０６を作成する。メタデータ２０６のフォーマット、即ち形式は、様々であってよい。これらは、原則的に、統治者からのポリシー設定を反映している。

メタデータ（ポリシー）２０６は、ポリシーラッパー２０８への入力として使用されてよい。一実施形態では、このプログラムコンポーネントは、ポリシーを受けて、それらのポリシーを、アプリ２１０をラッピングによってセキュアにするために使用する。ラッパー２０８は、ハンドヘルドデバイス２１２からアプリ２１０を受信する。一実施形態では、ラッパー２０８は、電話２１２にダウンロードされた元のアプリ２１４の代わりに、アプリのコピー２１０を受信する（上記の図１Ｂを参照）。ここでは、ハンドヘルドデバイス２１２ユーザは、アプリプロバイダ２１８から、非セキュアアプリ２１６をダウンロードしようとする。図１Ａで説明されたシナリオでは、ラッパーは、コピーではなくアプリ自体に働きかけるだろう。これは、マーケットプレース又はアプリストアが、非セキュアヴァージョンとともにセキュアヴァージョンのアプリを顧客に提供する（又はセキュアヴァージョンのみを提供する）場合に該当する。ポリシーラッパー２０８からデバイス２１２には、セキュアヴァージョン２２０（セキュリティラップヴァージョン）が返される。

メタデータ２０６は、ローカルポリシーファイル（デバイス上に既にある既存のポリシー）をアップデートするためにも使用されてよい。ローカルポリシーファイルは、デバイス２１２上にあるポリシーパラメータをアップデートするために使用される。例えば、「ジオフェンシング」（即ち、アプリの使用を特定の物理的領域に制限する）の場合は、統治者によって制御されるＧＰＳロケーションが、時間とともに変化する可能性が高い。このような変化が生じたときは、２つの異なる方式で新しいポリシーを適用することができる。１つは、新しいポリシーを生成し、それを元のアプリに適用する（即ち、新しいポリシーでアプリをラッピングする）方式である。もう１つは、ポリシーの「可変」部分が暗号化／署名されて内部にあるローカルポリシーデータファイルに基づいて、動的設定を可能にする方式である。例えば、ＩＴ担当者は、診断目的で、デバイス上にあるＩＴアプリを通じてデバイス上の設定を直接的にオーバーライドできることを望むだろう。

一実施形態では、ポリシーは、２つのコンポーネント、即ち固定部分と可変部分とを有する。固定部分は、ポリシーファイルに記述されたコンテンツである（例えば、「１日のうちの特定の時間帯にＧＰＳを保護する」）。可変部分は、通常、コンソールを通じて統治者によって提供される（例えば、「どの時間帯にＧＰＳが保護されるべきか？」）。可変部分は、新しいポリシーの適用なしに変わることができる。

ポリシーの設計者は、ポリシーの可変コンポーネントを放棄することを選択し、基本的に全てのデータ又はコンテンツをポリシーファイルに静的に「埋め込む」ことができる。この場合は、コンソールによってポリシーをカスタマイズすることはできない。

もし、ポリシーの設計者が、何らかの可変コンポーネントをポリシーに含めることを選択した場合は、（コンソール上で）可変データに変更がなされたときに、新しいデータファイルがデバイスに送信され、その最新の変更を反映させることができる。このようなファイルは、（悪質なアプリがポリシーを迂回することがないように）暗号化／署名され、デバイスにダウンロードされ、新しいデータを適切なポリシーに適用するためにデバイス上のアプリセキュリティコードによって使用される。

このような変更及びアップデートは、ローカルポリシーアップデートコンポーネント２２２のランタイムで行われてよい。このコンポーネントは、デバイス２１２上に、アップデートされたポリシーパラメータを作成する。その後、ラップアプリ２２０は、このアップデートされたポリシーパラメータを使用することになる。

一実施形態では、ポリシーマネージャ２０２及びポリシーラッパー２０８は、同じアプリセキュリティプログラム内のコンポーネントであり、同じコンピュータ上で動作することができる。その他の実施形態では、マネージャコンポーネント及びラッパーコンポーネントは、別々のコンピュータ上にあってよい。例えば、ポリシーマネージャ２０２は、或る場所のサーバ上にあってよく、ポリシーラッパー２０８は、別の場所のコンピュータ上にあって、異なるエンティティ又は同じエンティティによって管理されていてよい。まとめると、マネージャ及びラッパーは、アプリセキュリティプログラムを形成し、一実施形態では、セキュリティサービスプロバイダによって運営される。また、会社、雇用主、共同経営者などの企業体によって、又は携帯電話キャリアによって提供されてもよい。

図３は、本発明の一実施形態にしたがった、アプリをデバイスへのそのダウンロード前にセキュアにするプロセスを示したフローチャートである。ステップ３０２では、セキュアにされるべきアプリのコピー又はクローンが、デバイス上に作成される。一実施形態では、これは、モバイルデバイス自体でなされてよい、又はデバイスから離れた例えばインターネット上の、クラウド内の、企業体のサーバ上の、若しくはキャリアサーバ上のコンポーネントでなされてよい。ユーザは、個人、会社の従業員、又はその他のエンティティであってよい。当該分野で知られるように、アプリは、幾つかの方式で取得可能であり、最も一般的なのは、アプリストア若しくはアプリマーケットからであり、又はアプリ開発者若しくはアプリプロバイダから直接に、又はその他の任意の適切な方式で取得可能である。コピーを作成することによって、元のアプリが保存され、セキュアヴァージョン又は非セキュアヴァージョンのいずれを使用するかの選択肢がユーザに与えられ、また、アプリ制御プロセスに何らかの問題があったときにアプリを使用することができるようにユーザが保護される。ここで留意すべきは、一実施形態では、アプリが、まだ電話にダウンロードされていないことである。一実施形態では、後述される方法は、別のコンピューティングデバイス上で実施される。別の一実施形態では、プロセスは、モバイルデバイス上で実施されてよいが、アプリは、プロセスが完了してアプリがセキュアにされた後に初めてデバイス上で実行される。

ステップ３０４において、アプリは、逆カプセル化される。アプリは、全てではなくてもその大半が、著者／開発者によって署名されたデジタル署名を有する。ステップ３０４では、逆カプセル化の一環として、アプリからデジタル署名が取り除かれる。これは、当該分野で知られた技術を使用してなされてよい。このステップでは、アプリの復号化も実施されてよい。これらの及びその他のステップは、アプリのコアオブジェクトコードを提供し、これらのコードは、これ以降、アプリ制御プログラムによって作動可能になる。この動作の性質及び詳細は、モバイルデバイスのオペレーティングシステムに依存することができる。

スマートフォンのためのオペレーティングシステムには、ｉＯＳ（ｉＰｈｏｎｅ（登録商標）用）、Ａｎｄｒｏｉｄ（様々なメーカからの携帯端末に使用されている）、Ｗｉｎｄｏｗｓ（登録商標） Ｍｏｂｉｌｅ ７、Ｗｅｂ Ｏ／Ｓ、Ｐａｌｍなどの、幾つかの例がある。ステップ３０６において、コアオブジェクトコードは、実行可能なオブジェクトコードを得るために、逆アセンブル又は逆コンパイルのいずれかを経ることができる。例えば、コードは、「ネイティブコード」（ＣＰＵ命令）又はバイトコード（Ｊａｖａ若しくは．Ｎｅｔなどの仮想マシン命令）のいずれかであってよい。一実施形態では、これは、逆アセンブリが特定のリンク及び用語を発見して置換するプロセスに近いものであるｉＯＳをデバイスが搭載している場合は、より修正プロセスに近いものになるだろう。しかしながら、通常は、逆アセンブラを使用するなどの、当該分野で知られた技術を使用して、逆カプセル後にアプリのオブジェクトコードを得るための逆アセンブリプロセスがなされてよい。

ステップ３０８において、アプリオブジェクトコードは、アプリセキュリティプログラムからのオブジェクトコードで補強される。例えば、このオブジェクトコードは、セキュリティプログラムからのクラスファイルで置き換えられるクラスファイルを含んでいてよい。オブジェクトコードは、通常、モバイルデバイスオペレーティングシステムへのインターフェースを提供する。アプリ制御セキュリティプログラムオブジェクトコードは、一部には、上述されたポリシー／メタデータから導き出される。ｉＯＳの場合は、オブジェクトコードの置き換えではなくむしろ「発見及び置換」プロセスが生じるという意味で、動作が異なる。これは、ｉＯＳが使用する割り込みアプローチを考慮に入れたものである。通常、アプリセキュリティプログラムは、アセンブリ言語コードを調べていく。発見される具体的なアイテムは、オブジェクトコード内のソフトウェア割り込み（ＳＷＩ）であり、アプリ制御セキュリティプログラム層へのブランチで置き換えられ、このプログラム層は、次いで、後述されるように、リクエストの発行や結果の強化などの、とられるべき更なる措置を決定することができる。

オブジェクトコードの置換（即ち、ＳＷＩの置換）がなされた後、ステップ３１０において、アプリセキュリティプログラムは、モバイルデバイス上での実行に備えてセキュリティラップアプリの準備を整える。セキュリティプログラムによる置換によってアプリに入れられたオブジェクトコードは、通常、アプリとモバイルデバイスオペレーティングシステムとの間にブリッジ又は接続を提供する。セキュリティプログラムクラスファイルは、オペレーティングシステムクラスファイルを包み込むものとして説明することができる。アプリセキュリティプログラムクラスファイルは、（統治者からの入力によって）前に作成されたポリシーに基づいて生成される。アプリは、原則的に、携帯端末上で実行されるために、リワイヤ（変更）される。即ち、アプリは、モバイルデバイスオペレーティングシステム層によって提供されるセキュリティに加えてアプリセキュリティプログラム層を使用するために、リワイヤされる。別の言い方をすると、セキュアアプリは、依然として、オペレーティングシステムによるセキュリティの提供を受けることができる。一実施形態では、アプリがセキュアにされたことを反映するためにアプリのアイコンを変えるなどの、何らかの見た目の変更をアプリに施すこともできる。こうすれば、ユーザは、アプリアイコンが携帯端末の画面に現れたときに、そのアプリのセキュアヴァージョンが実行されることを確信することができる。アプリは、この時点で、セキュリティプログラムによって、原則的にリファクタリング又は再プログラミングされている。

ステップ３１２において、アプリは、例えば、サービスプロバイダの鍵又はセキュアアプリを提供している企業体の鍵などの、新しい鍵で署名される。リファクタリングを経たセキュアヴァージョンのアプリが、携帯端末デバイスに返される。別の一実施形態では、アプリは、電話上でセキュリティ層によってラッピングされる。ステップ３１４において、一実施形態では、セキュアでない元のアプリコピーが携帯端末デバイスから削除される。これは、セキュアヴァージョンのアプリによって、それが携帯端末にダウンロードされた時点で行われてよい。その他の実施形態では、これは行われず、両ヴァージョンがモバイルデバイス上に残る。この段階で、プロセスは完了する。

図４は、一実施形態にしたがった、ポリシーマネージャ２０２で実施される方法のフローチャートである。ステップ４０２において、統治者又はその他のセキュリティポリシー個人は、セキュリティポリシーを定義し、生成し、作成することを可能にされる。これは、企業体のネットワーク管理者が、幾百の又は幾千のモバイルデバイスにダウンロードされるだろう多数の（仕事用に特化された）企業体アプリを使用している幾百の従業員のために、無数のモバイルデバイスセキュリティポリシーを決定することであってよい。その対極として、これは、親が、子供が新しいモバイルデバイスにダウンロードする３つ又は４つのアプリについてのセキュリティポリシーを設定することであってよい。その他の例として、なかでも特に、ゲームアプリがＧＰＳを使用することを阻止する若しくは封じる、会話を記録若しくは盗聴するためにアプリがデバイス上のマイクを使用することを阻止するなどが挙げられる。いずれの場合も、統治者は、アプリのカテゴリ、アプリのタイプ及び性質、著者、年相応性、並びにその他の数々の要因を考慮に入れることができる。例えば、同じ著者が、マルウェアとして分類された又はデバイスにセキュリティ脅威を及ぼした可能性がある他のアプリを書いたことがあるかどうかが挙げられる。この場合は、同じ著者による他のアプリがあるかどうかが決定されてよい。各アプリにどのルールを適用するかを統治者が判断するのは、この段階においてである。一実施形態では、これは、統治者によって、オフラインでなされる。即ち、これは、管理者によって使用されているホームコンピュータ上又は企業体ネットワークコンピュータ上のユーザインターフェースを使用して行われてよく、そこでは、セキュリティプログラムサービスプロバイダによって提供されるセキュリティテンプレート（原則的にデフォルトテンプレートである）が使用されてよい、又はそれらのテンプレートを使用して非常に特殊なルールが設定されてよい。

ステップ４０４では、実際のポリシーを作成するために、ステップ４０２で入力されたセキュリティデータ入力が、アプリ制御セキュリティプログラムによって使用される。ステップ４０６では、ステップ４０４で作成されたセキュリティポリシーに関する統治者からの入力に基づいて、アプリ制御セキュリティプログラムオブジェクトコードが生成される。統治者又はサービスプロバイダは、必要に応じ、既存のセキュリティポリシーをアップデートすることもできる。上述のように、オブジェクトコードは、逆アセンブルされたアプリから得られた元のオブジェクトコードを強化するために使用されてよい。強化コードは、企業体及びエンドユーザを保護するために、アプリのためのセキュリティ及びプライバシーの設定を調整するために挿入される。元のアプリの行動が変更され、これは、アプリがどのように行動するかを統治者が制御することを可能にする。例えば、もし、或るアプリが極秘アカウント情報をプレーンテキストで（即ち、暗号化されていない状態で）保存している場合は、そのアプリが作成する全ての情報が暗号化形式で保存されるように行動が変更されてよく、暗号化されたこのような情報は、もし、保存されている永続的データに対する鍵がアプリに固有であれば、そのアプリによってのみアクセス可能である。多くの場合、強化コードは、特定の使用のシナリオに合わせて最適化されるゆえに、アプリのパフォーマンスを向上させることができる。

図５は、一実施形態にしたがった、携帯端末上又はモバイルデバイス上でセキュリティラップアプリが実行されるプロセスを示したフローチャートである。ステップ５０２では、アプリがデバイス上で実行されるときの又はアプリがデバイス上で実行される直前の、アプリの行動が変更される、即ち修正される。例えば、行動修正は、例えばスマートカード／ＣＡＣカード又はパスワードの要求などの、アプリ初期化時における認証を含んでいてよい。アプリによっては、最初に設計された状態ではセキュリティのためのパスワードを要求しないものがあるが、修正を経たセキュアヴァージョンのアプリは、パスワードの入力をユーザに要求することができる。ステップ５０４において、セキュアアプリは、ユーザがそれをアクティブにする（例えば、もしデバイスがタッチ画面を有する場合はアイコンをタップする）ことによって、モバイルデバイス上で実行される。アプリの実行に際し、一実施形態では、制御が４つの選択肢のうちの１つを採ることができる。当該分野で知られるように、アプリは、その実行時に、その機能を遂行するためにデバイスのオペレーティングシステムに対して呼び出し又はリクエストを行う。多くの場合、これらの呼び出しは、電話又はデバイスに対して無害である、即ち大きなセキュリティ脅威を及ぼさないと考えられる。もしそうであれば、呼び出しは、ステップ５０６に示されるように、オペレーティングシステムへの引き渡しを許可されるだろう。この場合、呼び出しは、デバイスオペレーティングシステムに対してなされ、アプリは、通常の方式で実行される。

もし、アプリを包むセキュリティ層、即ちラッパーが、デバイスにセキュリティ脅威を及ぼすかもしれないリクエストをアプリが出したことを検出した場合は、アプリセキュリティ層は、リクエストを、それがオペレーティングシステムに又は電話内のその他のソフトウェアコンポーネント若しくはハードウェアコンポーネントに引き渡される前に、強化又は修正することができる。これは、ステップ５０８に示されている。一実施形態では、統治者は、１つ以上のポリシーを検討することによって、どの呼び出しが許容可能であるかを決定する。例えば、統治者は、全てのデータが、暗号化形式で保存されるべきであると決定するかもしれない。別の例では、統治者は、選択された信頼できるアプリグループのみが、兵士のＧＰＳ座標に関するデータを有するべきであると判断するかもしれない。一実施形態では、何が安全であるか、何が脅威になりえるか、又は何が実際の脅威であるかを決定するためのランタイムロジックはなく、原則的に、上記ステップ４０４で作成されたポリシーのなかで、統治者によって事前に宣言されている。別の一実施形態では、何らかのランタイムロジックがあってよい。例えば、或るアプリが、高価なＳＭＳテキストメッセージを送出しようとしているかもしれない。アプリ制御プログラムは、そう判断すると、一定の数を超えるテキストメッセージを送信しないようにアプリをブロックしてよく、例えば、メッセージの送信を１つのみに制限することができる。この強化は、パスワード要求などの何らかの新しい追加であってよい。別の例として、もし、呼び出しが、モバイルデバイスメモリ上にデータを保存することである場合、セキュアアプリは、実際は、クラウド内の又はインターネット上の（即ちデバイス外の）記憶領域にデータをバックアップすることができる。別の例では、呼び出しに関連したデータを暗号化することができる。

ステップ５１０では、セキュアアプリは、呼び出しが実際の脅威であって、ステップ５０８よりも厳しい方式で扱われるべきであると決定するだろう。例えば、もし、保安区域である建物（例えば米国国防総省）にいるときにデバイスのカメラがアクセスされた場合、アプリは、そのアプリのためのポリシーに基づいて、直ちに終了されるべきであると判断されるだろう。この場合は、単にリクエストを強化するだけでは不十分だと考えられる。ステップ５１０では、リクエストは、オペレーティングシステム又はデバイスのその他のコンポーネントに進むことを許可されない。しかしながら、一実施形態では、アプリに応答が返される。ただし、その応答は、意図的に不正確にされている、即ち間違ったものであり、原則的に難読化されている。例えば、それは、デバイスの実際の物理座標ではないＧＰＳ座標であるかもしれない（例えば、デバイスはカリフォルニア州にあるが、アプリに返されるＧＰＳ座標はネブラスカ州内の座標である）。これは、子供がアプリを使用している場合に望ましいだろう。その他の例としては、もし、規制環境（例えば保安区域であるオフィス）内でのみ作動するべきであるアプリが、その環境外（例えば自宅）で作動していると決定された場合に、不良データ、即ち文字化けしたデータの結果を返すことが挙げられる。この例では、アプリは、機密扱いでないデータにのみアクセスすることができるように、部分的に機能を損なわれ、機密扱いの情報は、無効にされる。別の例では、ユーザが、機密扱いのアプリから機密扱いでないアプリへ極秘データをペースト又はコピーしようとしているときに、アプリ制御プログラムは、ペーストされようとしているデータのコピーを変更して文字化けさせる、即ち原則的に無意味にすることができる。ステップ５０６、５０８、又は５１０のいずれかが完了した後、ステップ５１４において、セキュリティラップアプリは、モバイルデバイス上での実行を継続する。

ステップ５１２では、アプリを包み込むセキュリティ層は、アプリによってなされた呼び出し又はアプリ実行の行動が、全体として、モバイルデバイスに対して余りに高いレベルのセキュリティ脅威を及ぼすことを決定した。この極端な事例では、セキュリティ層は、アプリの実行を終了させる及び／又はアプリを削除すると判断する。例えば、アプリは、帯域幅などの電話上のリソースを多く使用しすぎているかもしれない、又はオペレーティングシステムに対して高リスクの呼び出しを多く行いすぎて、それゆえにモバイルデバイスを露出過多にしているかもしれない。この場合、アプリは、電話から単純に削除される、又は終了される。ユーザは、そのアプリを再実行する又は再インストールすることができなくなる。例えば、或るアプリは、会社の極秘データを露出させていたので、従業員は、そのアプリを会社の電話に再びインストールすることができなくなる。或いは、或るアプリが、データを秘密裏に電話に収集している又はマルウェアをインストールしていると決定されるかもしれない。

図６は、一実施形態にしたがった、アプリセキュリティ制御システムのシステムアーキテクチャ図である。トリガマネージャコンポーネント６０２は、２つのイベントを取り扱っており、その１つは新しいポリシーを生成するためのイベント６０４であり、もう１つはポリシーパラメータをアップデートするためのイベント６０６である。このようなイベントは、様々なシステムによってトリガすることができる。例えば、コンソールの管理者又は統治者が、新しいポリシーを全てのデバイスに適用するかもしれない（手動動作）。或いは、アプリケーションを監視しているネットワークが、デバイス（又はアプリ）から発している不審なトラフィックを検出した後に、ユーザ／デバイス／アプリがネットワークリソースにアクセスすることを防ぐ新しいポリシーをプッシュするかもしれない（自動動作の一例）。ポリシーを変更する／アップデートする権限を有する様々なシステム又はエンティティが、トリガマネージャ２０２を通じてそれを行う。

新しいポリシーの入力６０４は、ポリシー定義ファイル６０８に入力される。このポリシー定義ファイル６０８は、ランタイムで生成されてよく、例えば、アプリ制御サービスプロバイダに特有の、又はポリシーが適用されるアプリ／ユーザ／デバイスに特有の、様々なタイプのコード及び拡張子を含んでいてよい。ポリシー定義ファイル６０８は、２つの出力を有するポリシーコンパイラ６１０に入力される。出力の１つは、ラッパー定義ファイル６１２である。このファイルは、アプリラッパーコンポーネント６１４に入力される。アプリラッパーファイル６１４は、例えばアプリストアから直接的にダウンロードされたアプリにカスタムバイナリコード（ネイティブ又はバイトコード）を投入することによってセキュアアプリを生成する役割を担う。或いは、アプリは、ユーザが自身のデバイスにダウンロードし次いで「アプリ制御」サーバにアップロードしたアプリであるかもしれない。

アプリラッパーコンポーネント６１４は、１つ以上のアプリストア６１６からのアプリ、ＩＤ管理コンポーネント６１８からの証明書鍵管理データ、及びハード化コンポーネント６２０の、３つの入力を有していてよい。鍵管理データは、ユーザ、デバイス、及びアプリのＩＤを関連付けて、ポリシー制御を受けるあらゆる動作が特定のユーザ／デバイス／アプリに結び付けられることを保証するために使用される。これは、悪質なアプリがポリシー及びハード化コンポーネント６２０（例えば「デバイスセキュリティフレームワーク」））を迂回することを防ぐために、ラップアプリケーションが特定のデバイス上でのみ動作できることも保証する。アプリラッパー６１４からの出力は、デバイスのコントローラ６２６を通じてモバイルデバイス６２４にダウンロード又はインストールされるラップアプリ６２２である。デバイスコントローラ６２６の役割は、アプリラッパーからアプリをダウンロードすること、デバイス上で動作するアプリが適切にラッピングされたアプリである（例えば、ユーザ１用にラッピングされたアプリがユーザ２のデバイスに／でインストール／作動するべきでない）ことを保証すること、インストールされたアプリケーションのリスト／ヴァージョンを報告し、管理コンソールが各デバイス／ユーザ／アプリケーションのためにポリシーを制御することを可能にすること、並びにポリシーパラメータを適時にダウンロードすることを含む。ラップアプリ６２２は、ポリシーパラメータ６２８に結び付けられた状態でデバイス６２４上にある。

ポリシーコンパイラ６１０に戻り、もう一方の出力は、ランタイムポリシー定義ファイル６３０である。このファイルは、ランタイムポリシーコンパイラ６３２に入力される。ランタイムポリシーコンパイラ６３２は、（管理コンソール又はその他のサブシステムによって指定された）入力ポリシーパラメータ６０６も受け付ける。コンパイラ６３２からの出力は、デバイスランタイムポリシーファイル６３４である。このファイル６３４は、ポリシーパラメータ６２８として示されるものとしてデバイス６２４にダウンロードされ、ラップアプリ６２２に適用されるポリシーをカスタマイズするために使用される。

以下で説明されるのは、本発明のアプリ制御セキュリティプログラムの様々な使用例及び性能である。使用例の１つは、携帯電話上で仕事と私生活とを分けることを伴う。アプリには、ユーザの私用のためのアプリと、ユーザの雇用主（又は雇用主の共同経営者）が提供しただろうアプリとがあり、これらのアプリは、多くはユーザの個人用の電話である同じ電話上で動作する。ユーザの電話上の、セキュアにされる必要があるアプリのセキュリティを決定する統治者は、（ｅ−ｍａｉｌアプリなどの）アプリ間におけるコピー／ペースト動作をブロックすることができる。統治者は、アプリ及び関連ファイルの選択的消去を実施する、仕事関連アプリのためのポリシーを設定することができる。ユーザの場所に基づくポリシーは、特定のアプリがどこで実行されてよいかを制御することもできる。マルウェアに起因する保護レベルの例として、連絡先へのアクセスを拒否する、同意を経ていないＳＭＳの送信を拒否するなどがある。

もう１つの使用例は、アプリ制御である。本発明を使用して、アプリのホワイトリスト及びブラックリストを作成することはもちろん、統治者によって設定されたポリシーにしたがってアプリを完全に削除することもできる。アプリは、デバイスのその他のアプリ、ソフトウェア、及びハードウェアを保護するために、「サンドボックス化（安全な箱に閉じ込めてその中で動作させる）」することができる。その他の性能として、アプリ又はサービスのＩＤベースの制御、及びアプリ行動に対する高粒度の制御が挙げられる。トロイの木馬の識別は、アプリセキュリティ制御によって実現することができる別の使用例である。例えば、各アプリ及びコンテンツは、不正なアプリが電話上の機密データにアクセスして盗用することがないように、暗号化することができる。セキュリティプログラムは、公開されている意図から外れて動作する悪質なトロイの木馬アプリを識別するために、アプリによる異常なシステム呼び出し行動を識別可能であってもよい。

別の使用例は、アプリデータのバックアップ及びリカバリであり、この場合、ＩＴセキュリティ管理者及び統治者は、データ修正制御を有し、バックアップ及び回復動作を通じてアプリ及びデバイスコンテンツの移行を実現することができる。別の使用例は、ネットワークトラフィックの監視である。モバイルデバイス上のアプリは、アプリ通信の検査及び制御を可能にするために、既存の企業体ＩＤＳ／ＩＰＳ／Ｗｅｂフィルタリングインフラストラクチャから見えるようにされてよい。アプリセキュリティプログラムは、また、マルウェアを識別するために、ＳｙｍａｎｔｅｃのＤＮＳサービスなどの第三者ＤＮＳサービスと一体化することもできる。携帯電話サービスプロバイダにおける通信を含む全てのアプリ通信が、暗号化されてよい。その他の使用例として、セッション持続性、消費者プライバシー（例えば、ＧＰＳの難読化や安全なＤＮＳの実装）、及びモバイルデバイスからの（即ち、モバイルコマースストリームの真ん中で動作している）支払い／取引メッセージの傍受が挙げられる。

一実施形態では、アプリセキュリティサービスは、例えば、アプリをエンドユーザ又は個人（即ち、雇用主又は企業体に関係していないユーザ）によって使用されるようにするために、第三者サービスプロバイダによって提供される。例えば、親は、Ｆａｃｅｂｏｏｋなどのソーシャルネットワークサイトが子供の居場所を知ることを望まないゆえに、子供の電話のＧＰＳを難読化し、ＧＰＳを原則的に無効にしたいと考えるだろう。別の一実施形態では、無線電話キャリア（例えばＶｅｒｉｚｏｎやＡＴ＆Ｔ）によって運営されているアップルストアが、追加料金又は割増料金でセキュアアプリを提供するだろう。キャリアの顧客は、追加代金を支払うことによって、非セキュアヴァージョンの代わりにセキュアアプリをマーケットプレース又はオンラインストアからダウンロードすることができる。別の一実施形態では、企業体が、その従業員や共同経営者らのための専用のアプリストアを有していてよく、そこでは、ユーザは、セキュアヴァージョンのアプリ（「ハード」アプリと呼ぶことができる）のみをダウンロードすることができる。これらのアプリは、ｅ−ｍａｉｌ又は企業データのコピー＆ペーストをブロックする、ユーザが会社から出たらユーザの電話からアプリを抹消するなどの、企業体の統治者（セキュリティ管理者）によって定義された上述のセキュリティ特徴を多く有することができる。携帯電話キャリアのＤＮＳは、通常はあらゆるサイトにアクセスすることができるが、アプリセキュリティプログラムは、安全なＤＮＳ（例えばＳｙｍａｎｔｅｃのＤＮＳ）にのみアクセスできるように、モバイルデバイスのブラウザをブロックすることができ、その安全なＤＮＳからは、安全なＷｅｂサイトのみがアクセス可能である。別の一実施形態では、アプリセキュリティプログラムプロバイダは、アプリセキュリティプログラム又は機能をデバイスのハードウェア及びソフトウェア動作に組み込むために、モバイルデバイスメーカと連携することができる。後述されるこの実施形態では、ユーザは、非セキュアアプリをダウンロードし、それを、実行前に電話又はデバイス自体においてセキュアにすることができ、したがって、アプリをセキュアにするために第三者サービスにアクセスする又はアプリがデバイスにダウンロードされる前にそれがセキュアであることを確認する必要がない。

上述された様々な実施形態からわかるように、モバイルデバイスのセキュリティは、デバイス自体を超えて、デバイスにダウンロードされるアプリに直接的に適用される。会社及びその他のエンティティは、会社の企業体ＩＴシステムのデータ漏出又はマルウェア感染などのセキュリティリスクに関して心配することなく、より自由にアプリを活用することができる。会社らは、その企業データの統治を維持することができる。

本発明の別の一態様では、デバイス上の個々のアプリによってＶＰＮが作成され利用される。即ち、アプリは、例えば企業ＶＰＮゲートウェイと通信するためのＶＰＮトンネルを有する。このＶＰＮトンネルは、デバイス上の１つのアプリと、ＶＰＮゲートウェイとの間でのみ使用される。一実施形態では、各セキュリティラップアプリは、それ自身のＩＰスタック、又はより一般的にはＶＰＮスタックを有する。デバイス上の特定のラップアプリのためのＶＰＮトンネルを作成するための方法及びシステムが、図７及び図８で説明される。

上記のように、従来は、（クライアント側／デバイス側において）システムのＵＤＰ又はＴＣＰモジュールの上にＶＰＮトンネルが構築され、このトンネルがＶＰＮゲートウェイと通信する。説明の実施形態では、デバイスは、スマートフォン、タブレット、又はその他のモバイルデバイスであってよい。その他の実施形態では、デバイスは、ＰＣ又はノートパソコンであってよい。また、デバイスは、腕時計やゴーグルなどの身に着けられる機器、又はその他のノマディックインターネット対応のコンピューティングデバイスであってもよい。更に他の実施形態では、デバイスは、インターネット対応のあらゆる器具又はシステムであってよい。例として、インターネットアクセスを有する自動車、家電製品（冷蔵庫や洗濯機など）、ＨＶＡＣ、即ち住宅暖房／エアコンシステム、又はセキュリティシステムが挙げられる。上記のように、説明の実施形態は、ユーザがアプリをダウンロードするモバイルデバイスを使用する。しかしながら、本発明は、その他の実施形態及び状況に使用されてもよい。

通常、スマートフォン、タブレット、ＰＣ、又はその他のインターネット対応機器などのデバイス上には、それがゲートウェイデバイスへのＶＰＮ接続を行うことを可能にするソフトウェアがある。しかしながら、説明の実施形態は、更にセキュアなＶＰＮトンネルをデバイス上に作成して利用する、よりコンパートメント化された方式を提供する。一実施形態では、各ラップアプリが、それ自身のＶＰＮトンネルを有する。別の一実施形態では、デバイス上のアプリ連合内の一部又は全部のアプリが、１本のＶＰＮトンネルを共有する選択肢を有する。「連合」アプリの場合は、プロセス間における通信のために、セキュア形式のＩＰＣが用いられてよい。以下で更に詳しく説明されるように、各ラップアプリのために、ＩＰｓｅｃパケットを構築することができる（各ラップアプリは、自身のサンドボックス内で、即ちデバイスのオペレーティングシステムの外で動作する）。ＩＰパケットは、プロキシ又は仮想データリンク層（アプリＶＰＮスタックの一部）を通じてオペレーティングシステム内のネイティブＵＤＰモジュールに伝送される。そこから、ＩＰパケットは、ＶＰＮゲートウェイに伝送される。上記のように、デバイスは、ＰＣであってもよい。例えば、ラッピングされたヴァージョンのＭｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋを動作させているＰＣは、そこからゲートウェイへの自身のＶＰＮトンネルを有していてよい。

ＶＰＮトンネルを確立するためには、最初のステップは、代表的なオペレーティングシステムがアプリケーションに提供することができるパケットタイプのみを作成することである。例えば、ＩＰベースのＶＰＮに接続するためには、アプリケーションは、ＴＣＰ又はＵＤＰパケットを使用することができる。説明の実施形態では、ａｐｐ ＩＰスタックは、ＵＤＰスタックを使用する。通常、「未加工」ＩＰパケットは、オペレーティングシステム用であり、特権的なアプリケーションのみがそれらを送受信可能であるので、使用されるべきではないのが一般的である。本発明の様々な実施形態で説明されるように、ｐｅｒ−ａｐｐ ＶＰＮは、デバイス上における特権的なプロセスである必要はない。ＩＰｓｅｃパケットのＮＡＴトラバーサルは、（ＲＦＣ３９４７及びＲＦＣ３９８４に記述されるように、）未加工ＩＰパケットではなくＵＤＰプロトコルを使用して可能にされる。

或るアプリが、ＶＰＮトンネルを通してゲートウェイにデータを送信するためには、そのアプリは、ＩＰパケットを構築可能でなければならず、このようなＩＰパケットは、次いで、デバイス上においてＶＰＮソフトウェアを使用してカプセル化される。ＩＰパケットは、ＩＰスタックを使用して構築される。このソフトウェアは、通常は、デバイスのオペレーティングシステム内にある。したがって、ｐｅｒ−ａｐｐ ＶＰＮを動作させるために、一実施形態では、アプリは、その１つのアプリとゲートウェイとの間でのみ使用されるトンネルを構築するために使用されるＩＰ又はＶＰＮスタックを活用する。要するに、一実施形態では、このスタックが、その他のアプリによって使用されることはない。このスタックは、ｐｅｒ−ａｐｐ ＩＰスタックとも呼ばれてよく、アプリサンドボックス内にある。その目標は、オペレーティングシステム機能をサンドボックス内に全体的に複製することである。

ＩＰスタックが、外部ネットワークにアクセスするためには、そのＩＰスタックは、データリンクインターフェースと呼ばれるソフトウェア（ＴＣＰ／ＩＰ及びＯＳＩネットワーキングモデルで言うところのレイヤ２としても知られる）を使用する。本発明の一実施形態では、図７に示されるように、このデータリンクインターフェースは、下位のオペレーティングシステムの（ネイティブ）ＩＰスタックへのプロキシ（又は仮想）データリンクインターフェースとして実装される。一実施形態において、もし、ＵＤＰパケットのみが送受信されるならば、このプロキシデータリンクインターフェースは、ネイティブオペレーティングシステムのＩＰ／ＶＰＮスタック及びｐｅｒ−ａｐｐ ＩＰ／ＶＰＮスタックを通じてＵＤＰトラフィックを送受信することをサポートする。ＩＰｓｅｃモジュールが、仮想データリンク層から来るインバウンドトラフィックを復号化し、ｐｅｒ−ａｐｐ ＩＰスタックからのアウトバウンドトラフィックを暗号化する。

ＩＰｓｅｃは、通常は、「［ＩＰ］スタック内の突出」として実装され、オペレーティングシステムのＩＰスタックに組み込まれる。一実施形態では、ＩＰｓｅｃは、代わりにｐｅｒ−ａｐｐ ＩＰスタック内に実装される。上記のように、ｐｅｒ−ａｐｐ ＩＰスタック内に、プロキシ又は仮想データリンクインターフェースが定義される。ＩＰｓｅｃは、ｐｅｒ−ａｐｐ ＩＰスタックを通して構築されたトラフィック（ＩＰスタック）をカプセル化し、そのトラフィックを、一実施形態ではプロキシデータリンクインターフェースを通じてネイティブオペレーティングシステムスペース内のＵＤＰモジュールへルーティングする。

図７は、一実施形態にしたがった、ｐｅｒ−ａｐｐ ＶＰＮを実装するために必要とされるモバイルデバイス内のコンポーネント及びモジュールを示したブロック図である。図に示されているのは、モジュールデバイス７０２上の２つの関連メモリスペース、即ち、ラップアプリ、システムコンポーネント、及びＩＰ／ＶＰＮスタックの各コンポーネントを含むサンドボックス領域７０４、並びにデバイスオペレーティングシステムスペース７０６である。また、モバイルデバイス７０２の外に、ＶＰＮゲートウェイコンポーネント７０８も示されている。上記のように、本発明の実施形態は、サンドボックス領域７０４内にセキュリティラップアプリのためのＩＰスタックを作成及び実装することを伴う。

ＩＰスタック７１０は、ネットワーク層及びトランスポート層などの、ＴＣＰ／ＩＰスタックの従来の層を幾つか有する。ＩＰスタック７１０の上は、ＨＴＴＰプロキシ又はソケット層７１２である。ａｐｐ ＩＰスタック７１０内の２つのコンポーネントは、ＩＰｓｅｃ７１４及びプロキシデータリンク層７１６である。仮想データリンク層７１６は、仮想ＩＰＳｓｅｃ７１４とネイティブＵＤＰモジュール７２２との間のＩＰインターフェースとして機能する。仮想ＩＰｓｅｃ７１４、仮想データリンク層７１６、及びＩＰスタック７１０の組み合わせは、「ｐｅｒ−ａｐｐ ＶＰＮ」スタックと呼ぶこともできる。本発明のｐｅｒ−ａｐｐ ＶＰＮスタックの主な目標は、ネイティブオペレーティングシステム７０６内で起きる動作及び機能を複製することである。１つのアプリのためのコンポーネント、及び任意のシステムコンポーネントが、サンドボックス領域７０４内にある。しかしながら、例示のために、図には、１つのアプリコンポーネント７０８、及び１つのシステムコンポーネント７２０のみが示されている。

ネイティブオペレーティングシステム７０６は、システムレベル又はネイティブＩＰスタック（不図示）などの、幾つかのコンポーネントを含む。本発明で必要とされる、オペレーティングシステム７０６内のモジュールの１つは、ＵＤＰモジュール７２２である。上記のように、ＩＰｓｅｃパケットは、ＵＤＰを使用してモバイルデバイス７０２からＶＰＮゲートウェイ７０８に伝送される。その他の実施形態では、ＴＣＰが使用されてよい。セキュリティラップアプリのためのデータパケットも、ＶＰＮゲートウェイデバイス７０８からＵＤＰモジュール７２２で受信され、プロキシデータリンク層７１６へ中継される。

図８は、本発明の一実施形態にしたがった、ａｐｐ ＶＰＮを実装するプロセスのフローチャートである。サンドボックス７０４内のセキュリティラップアプリが、通常の方式で実行され、その過程において、デバイスオペレーティングシステムへの呼び出しを行う。呼び出しには、ＶＰＮ通信を必要とするものがある。これは、ステップ８０２において生じる。一実施形態では、これらの呼び出しは、ステップ８０４において、ａｐｐ ＩＰスタックへリダイレクトされる。一実施形態では、ＨＴＴＰプロキシ層ボックス７１２を通じてアプリケーション（アプリボックス７１８及びシステムコンポーネントボックス７２０）に面しているインターフェースは、オペレーティングシステム７０６によって提供される対応するインターフェースを忠実に反映している。

ステップ８０６において、ａｐｐ ＩＰスタックは、従来の方式でＩＰｓｅｃスタックを構築する。これは、普通は、サンドボックス内のアプリ又はシステムコンポーネントがオペレーティングシステムへの呼び出しを行う結果としてシステム／ネイティブＩＰスタックによってなされえる。ＩＰパケットは、次いで、ａｐｐ ＶＰＮスタック内のＩＰｓｅｃを使用してカプセル化される。ステップ８０８では、やはりａｐｐ ＶＰＮスタックの一部であるプロキシデータリンク層が、システム／ネイティブＩＰスタック内のＵＤＰモジュールにパケットを伝送する。ＳＳＬ ＶＰＮが実装されるその他の実施形態では、パケットは、ＴＣＰモジュールに伝送されてよい。上記のように、プロキシ（仮想）データリンク層は、ａｐｐ ＩＰスタックと、具体的にはＵＤＰモジュールであるシステムネイティブスタックとの間のインターフェースとして機能する。ＩＰｓｅｃモジュールは、仮想ＩＰｓｅｃインターフェースとして説明することができる。このインターフェースは、仮想データリンクインターフェースとともに、ａｐｐ ＶＰＮスタックを通して降りてくるＩＰパケットを取得して、ネイティブＵＤＰモジュールからＶＰＮゲートウェイへ出す働きをする。

着目すべきは、これが、ネットワークアドレス変換（ＮＡＴ）の使用によって可能であることである。当該分野で知られるように、この技術は、ＩＰアドレスに対応付けられる「プライベート」ＩＰアドレスをエンティティが割り当てることを可能にする。プライベートＩＰアドレスは、公に見られることはない。従来のＮＡＴ手法は、ＩＰパケットをリライトし、次いで、それを異なるプライベートアドレスに送信することができる。

上記のように、特定のアプリケーションを、自身のＶＰＮトンネルを有するように設定することによって、アプリセキュリティラッピングサーバを、ネットワークリソースへのアクセスを制限し、アプリをそれが必要とする特定のリソースのみにアクセス可能にするように、構成することが可能だろう。もし、ＨＴＴＰプロキシ７１２が、オペレーティングシステム７０６によって提供されるＴＣＰポートで聴いている場合、そのＴＣＰポートには、その他のアプリケーションが接続する可能性がある。一実施形態では、ＨＴＴＰプロキシ層７１２は、デバイス上のその他のアプリケーションがＨＴＴＰプロキシにアクセスすることを防ぐための技術を実装している。一実施形態では、システムは、例えば、現行プロセス（即ち、ラッピングを経たホストアプリ）における全てのファイル記述子を調べ、ＨＴＴＰプロキシ層７１２への接続を行ったファイル記述子があるかどうかを決定するためにカーネルに問い合わせることによって、ＨＴＴＰプロキシ層７１２への接続が現行プロセスから来たものであるかどうかを決定する。もし、或るアプリグループ又はアプリ連合の信頼性が認められ、これらのアプリ間において通信が確立可能であるならば、一実施形態において、その連合のアプリは、１本のＶＰＮトンネルを共有することができる。こうすれば、デバイスに必要とされる並列ＶＰＮトンネルの本数は減らされるだろう。しかしながら、その一方では、ネットワークリソースへのアクセスを制限し、アプリをそれが必要とする特定のリソースのみにアクセス可能にするように、サーバを構成するなどの、上述された幾つかの利点が損なわれる恐れがある。

このように、一実施形態では、特定のセキュリティラップアプリのみが、そのアプリのＶＰＮスタックによって作成されたＶＰＮトンネルに接続することができる。これは、デバイス上の別の悪質なアプリ又はその他の任意のマルウェアが、別のアプリのためのＨＴＴＰプロキシをその悪質なアプリのためのプロキシでもあると宣言することを阻止し、そうして、悪質なアプリによる、ラップアプリのＶＰＮの使用を防ぐものである。別の一実施形態では、セキュリティラップアプリによって作成されたＶＰＮトンネルは、ＶＰＮを作成したアプリと同じ連合又はグループ内のその他のラップアプリと共有されてよい。

別の一実施形態では、デバイスユーザは、いかなるアクセス又は接続を得るためにも先ずＶＰＮを必要とする（例えば、ユーザは、インターネットアクセスに制約のある国外で仕事をしている）かもしれず、この場合、ユーザは、デバイスレベルのＶＰＮにアクセスして最初の完全なインターネットアクセスを得て、次いで、ｐｅｒ−ａｐｐ ＶＰＮを使用して社内アクセスを得ることができる。

１つのアプリケーションを１本のＶＰＮトンネルに結び付けることによる別の利点は、ＶＰＮゲートウェイにおいて、アプリケーションごとに異なる「設定プロフィール」（即ちＶＰＮグループ）を使用することによって、アプリケーションがアクセスを有するネットワークリソースを制限する能力である。

次に、本発明の別の一態様では、ゲートウェイ所有者の観点からネットワークセキュリティが強化される（ゲートウェイは、デバイス上のアプリとゲートウェイ７０８との間のＶＰＮを示した図７で最初に説明されている）。即ち、ゲートウェイの背後にある企業ネットワーク又は組織ネットワークなどのコンポーネントのセキュリティが、より良く保護される。後述のように、一実施形態では、セキュリティは、ジェイルブレーク又はルート化されたデバイスを報告する能力によって強化される。報告は、ゲートウェイへのプライベートトンネルを通じてなされてよく、ゲートウェイは、更に、適切なネットワークコンポーネントへの報告を行うことができる。本発明の更に別の一態様では、ゲートウェイは、モバイルデバイス上のアプリとの間のＶＰＮ又はＩＰＳＥＣ接続などの多数のプライベートトンネルを管理するために拡張することができる。

説明されたように、カリフォルニア州サンフランシスコのＭｏｃａｎａ Ｃｏｒｐｏｒａｔｉｏｎなどのアプリセキュリティプロバイダが、デバイス上の選択されたデフォルトポリシーにしたがってアプリをラッピングするために必要とされるソフトウェアを供給している。このアプリセキュリティプロバイダは、デバイス上のラップアプリが、例えば、ユーザの雇用主など会社の制御下にあるだろうゲートウェイとアプリとの間にＶＰＮ又はＩＰＳＥＣ接続などのプライベートトンネルを作成することを可能にする、ソフトウェアも提供することができる。アプリセキュリティプロバイダは、また、会社へのゲートウェイを含むソフトウェア及びハードウェアも提供することができる。代表的なシナリオでは、デバイスのユーザは、会社の従業員である。デバイスは、多くの場合、ユーザによって所有されている（会社によって所有されていて、仕事で使用するためにユーザに与えられていることもある）。デバイスは、会社によって従業員／ユーザに提供された又は雇用主のためになされる従業員の仕事に何らかの形で関係付けられた例えばｅ−ｍａｉｌクライアントなどの１つ以上のアプリを動作させる。アプリは、アプリセキュリティプロバイダから購入されたセキュリティラッピングソフトウェアを使用して、雇用主（例えばＩＴ部門）によってラッピングされる。アプリは、ラッピングされると、従業員（本明細書では「ユーザ」と称される）によって使用される前に、ユーザに与えられる。

一実施形態では、各ユーザは、１つの（又は２つ以上の）デバイスを有し、各デバイスは、仕事関連の複数のセキュリティラップアプリを有していてよい。雇用主は、仕事関連の１つ以上のラップアプリを有する自分用のデバイスをそれぞれ使用している幾百又は幾千のユーザを有するだろう。これらの各アプリは、動作するときに、雇用主のゲートウェイ（上記のゲートウェイ７０８）との間に自身専用のプライベートトンネルを有し、これは、従来の設定では、雇用主が非常に多数の固有ＩＰアドレスを管理しなければならないだろうことを意味する。これらの固有ＩＰアドレスは、１０ネットアドレスである可能性が高い。ＩＰアドレスを指定する作業、及びゲートウェイからアプリへトラフィックをルーティングして戻さなければならないことは、雇用主にとって、ほぼ間違いなく乗り越えられない、又は少なくとも重大な、技術面及びロジスティック面での課題である。

企業体などのエンティティが割り当て及び管理をしなければならないだろう固有ＩＰアドレスの数を減らし、それと同時に、ラップアプリの数、及びそれらのラップアプリとゲートウェイとの間のプライベート接続の数を増やすことができる、手段及び方法を提供することが望ましいだろう。即ち、ｐｅｒ−ａｐｐ ＶＰＮ実施形態の利点を維持しつつ、それらの実施形態を実装する管理面及び技術面の欠点及び障害を減らす、手段及び方法を提供することが望ましいだろう。

また、ゲートウェイに接続することができるユーザデバイスの数の増加ゆえに、内部企業体ネットワークのセキュリティを維持するためには、ジェイルブレーク又はルート化されたデバイスのゲートウェイについて通知できることも望ましいだろう。

上記のように、ゲートウェイを使用している企業体を懸念させている問題は、ジェイルブレーク又はルート化されたデバイスから（ゲートウェイの背後の）企業体ネットワークのセキュリティが破られる可能性である。上記のように、モバイルデバイスは、大抵の場合、（益々増えつつある「個人使用機器の持ち込み」ＢＹＯＤ環境を反映して）従業員に属しており、雇用主は、ジェイルブレーク又はルート化されたデバイスをユーザが使用することを防ぐこと、又はそのような使用についての警告を受けることを望む。或いは、雇用主は、最低でも、そのようなデバイスがゲートウェイに接続するためにいつ使用されているかを知ることを望む。幾千ものユーザを擁し、それゆえに幾千もの異なるデバイスがゲートウェイに接続している大規模な雇用主の場合は、実際は脱獄している又はルート化されているデバイスが、不明な数で存在する可能性がある。雇用主は、このようなデバイスがいつゲートウェイに接続するかを知ることを望む。

このような状況では、ラップアプリを、自身が脱獄デバイス上で動作しているかどうかをそのプライベートトンネルを通じて報告できるようにすることが、望ましいだろう。なお、ここでは、デバイスがジェイルブレークされたものであるかどうかの実際の検出が、アプリのラッピングを実施するデバイス上で動作しているアプリセキュリティソフトウェアによって実施されることが、留意されるとよい。この脱獄の検出は、本発明に関わる機能とは別個の動作であり、要するに、デバイスがジェイルブレークされたものであるかどうかをゲートウェイ（即ち、雇用主又は企業体）に報告する動作である。

モバイルデバイス上のアプリと、ゲートウェイとの間に接続を確立する２つのフェーズを説明する前に、ゲートウェイの観点から見て信頼に足る地点として特徴付けられるモバイルデバイス上のラップアプリと連携するゲートウェイの性能の概要を提供することが有用である。後述のように、本発明の機能及び性能は、ゲートウェイ及びラップアプリの両方を企業体が所有していることに端を発しており、これらのゲートウェイ及びラップアプリは、ともに、アプリセキュリティソフトウェアを用いる。上記のように、セキュリティプロバイダは、アプリをラッピングするためのソフトウェアと、ゲートウェイのためのソフトウェアとを提供する（また、ゲートウェイ自体も提供することができる）。

ゲートウェイの性能の中心にあるのは、多数のプライベート接続を遮断する能力である。これらの接続は、ＶＰＮ／ＳＳＬ、ＩＫＥ／ＩＰＳＥＣ、又はその他のプロトコル若しくは標準を使用することができる。例示を目的として、説明の実施形態では、ゲートウェイは、ラップアプリを起点とするＩＫＥ／ＩＰＳＥＣセッションを遮断する。ゲートウェイのもう１つの中心性能は、ラップアプリとゲートウェイとの間に、より高いレベルの認証又はセキュリティを強制する能力である。上記のように、これの特徴の１つは、ジェイルブレーク又はルート化されたデバイスについてラップアプリが報告する能力である。ゲートウェイのもう１つの性能は、ラップアプリとの間を行き来するデータパケットに関連する詳細なトラフィックデータを得ることである。ゲートウェイは、その他の性能も有し、その一部は、アプリ特有のデータベースを使用する。

モバイルデバイス上のアプリと、ゲートウェイとの間における傍受又は改ざんを防ぐために、セキュアなトンネル又は接続を確立するプロセスは、２つのフェーズで説明することができる。一実施形態では、Ｐｈａｓｅ １は、２要素認証を伴うＸＡＵＴＨプロトコルの拡張機能したものとして特徴付けられる。各ラップアプリ（以下では「クライアント」とも呼ばれる）は、ゲートウェイ（以下では「ヘッドエンド」とも呼ばれる）との間でＩＫＥ／Ｐｈａｓｅ １を経る。アプリは、ラッピングされるときに、ゲートウェイのための固有なパブリックＩＰアドレス及び／又は完全修飾ドメイン名を提供される、即ちそれを伴うように事前に設定される。要するに、アプリは、「ホームを呼び出す」能力を与えられる。アプリは、先ず、そのＩＤをゲートウェイに証明する必要がある。このプロセスは、アプリがデバイス上のユーザによって起動されて、ゲートウェイとの間にセキュアなプライベート接続を行おうとするときに開始する。ユーザは、ユーザのアプリケーション及びデバイスに固有な再接続トークンを提供することもできる。

当該分野で知られるように、これは、２要素認証プロセスの第１の要素である。クライアントは、ゲートウェイのパブリックＩＰアドレスを使用してデバイス証明書をゲートウェイに伝送するために、セキュアなトンネルを使用する。ゲートウェイは、従来の手段を使用して証明書の調査及び検証を行う。もし、加入証明書が有効であり、ヘッドエンドがユーザのＩＤに関して満足した場合は、第２の要素についてのプロセスが開始する。

ＸＡＵＴＨ拡張機能の２要素認証プロセスの第２の要素に関しては、クライアントは、クライアントとヘッドエンド（即ち、ＶＰＮゲートウェイ）との間で伝送されるデータについて、セキュリティアソシエーションを取り決める。クライアントは、ＸＡＵＴＨによる認証に進み、そこで、そのユーザ名、パスワード、ＭＡＣアドレス、及びプロトコルを証明する。アプリは、また、クライアントが動作しているモバイルデバイスがジェイルブレークされているかどうか、及びクライアント上で動作しているアプリの名前などのその他の情報を報告する。これは、全て、セキュアなＩＫＥトンネルを通じてなされる。クライアントは、これを、ＸＡＵＴＨプロトコルの拡張機能を使用して行う。この拡張機能は、ＰＥＲＰと呼ばれるポリシー強制及び報告プロトコルとして特徴付けることができる。ゲートウェイは、データベースをチェックすることによってこのデータをローカルで認証することができる、又はゲートウェイは、ＡＡＡサーバ若しくはアクティブディレクトリなどの外部コンポーネントを使用することができる。

ゲートウェイがこのデータを認証し、ＰＥＲＰ応答が許容可であると、ＸＡＵＴＨフェーズの第２の要素が完了する。ＰＥＲＰによって拡張されたＸＡＵＴＨ Ｐｈａｓｅ １段階によって、ラップアプリは、ジェイルブレークされたデバイスをゲートウェイに報告することができ、ゲートウェイは、すると、雇用主のネットワーク内のコンポーネント（例えば、セキュリティ管理者のコンソール）に通知することができる。別の言い方をすると、ゲートウェイは、アプリ、ユーザ、デバイス、ＩＰアドレス、及びＭＡＣアドレスに関する具体的な情報を学習するために、ＰＥＲＰを使用する。したがって、任意のＩＫＥ／ＩＰＳＥＣセッションを通じてゲートウェイで受信されたいかなるデータに関しても、雇用主は、ＰＥＲＰによって、確信を持って、どのユーザがデータを送信したか、どのラップアプリからであるか、及びどのデバイスからであるかを学習することができる。ここで留意すべきは、ＰＥＲＰが、任意のセキュアプロトコルを通じて２点間で使用可能であること、即ち説明の実施形態のようにＩＫＥに結び付けられているのではないことである。ＰＥＲＰは、ＶＰＮ／ＳＳＬなどの任意の適切なセキュアプロトコルを通じて運ぶことができる。企業体は、この高粒度データを、推定、即ち確実とは言えない結果（即ち、誰であるか、何であるか、及びどこであるかに関する知的推測）に終わるのが一般的である経験則、パケット解析、又はその他の手段に依存する必要なく得ることができる。一実施形態では、これは、ヘッドエンド（ゲートウェイ）が、データの発信元である信頼に足るクライアントとの間に関係を有するゆえに可能である。ＰＥＲＰ、及びそれが既存のラップアプリのためのシームレスユーザ認証にどのように使用可能であるかに関する更なる詳細が、以下で提供される。

セキュリティアソシエーションが取り決められたら、クライアントは、ゲートウェイとの間で設定を開始する。一実施形態では、これは、ＩＫＥ ＭＯＤＥ−ＣＯＮＦＩＧを使用してなされる。この段階で、アプリは、固有（内部）ＩＰアドレスをゲートウェイに要求する。アプリは、また、サブネット及びＤＮＳ名も要求してよい。

ＸＡＵＴＨ／ＰＥＲＰに関しては、一実施形態では、ゲートウェイは、クライアント／アプリに、それが、デバイス上のラップアプリ連合に入っているかどうか、即ち、アプリが、企業体からの、アプリ連合と呼ばれるアプリグループの一員であるかどうかを照会することができる。もし、クライアントがそうだと答えた場合、ゲートウェイは、連合クッキーをクライアントに伝送することによって応答する。別の一実施形態では、ゲートウェイは、ラップアプリに、連合に関する照会は行わない。その代わり、ゲートウェイは、単純に連合クッキーをアプリに送信する。もし、アプリが連合の一員でない場合、即ち、もし、アプリがデバイス上において企業体からの唯一のアプリ（即ち、１つのアプリからなる連合）である場合、クッキーは、その後に続いて使用されても又は使用されなくてもよい。以下のステップで説明されるように、この連合クッキーは、連合内のその他のアプリによって使用される。

ラップアプリがゲートウェイとの間でそれ自身の設定を行ったら、ＩＫＥ Ｐｈａｓｅ １は完了し、アプリとゲートウェイとの間にセキュアなトンネルが確立される。このポリシー強制は、ＰＥＲＰを使用してＰｈａｓｅ １の最中に実行される、及びＩＰｓｅｃセッション内にトラフィックを監視することによって後ほど実行される可能性が、最も高い。ゲートウェイは、こうして、雇用主／企業体に代わり、ユーザのデバイス上でポリシー（例えば、ジオフェンシング、コピー／ペーストなど）を強制することができる。例えば、ゲートウェイは、特定のラップアプリを使用している従業員にポリシーを強制し、その従業員がそのアプリを一日の内の特定の時間帯にのみ及び特定の地理的領域にいるとき（例えば、その従業員の店舗にいるとき）のみ使用するように、指示することができる。ゲートウェイがこれを行うことができるのは、ゲートウェイがユーザ、アプリ、及びデバイスに関して正確で且つ具体的なデータを有しており、それに相応して１つ以上ポリシーを適用できるからである。後述のように、ゲートウェイは、アプリ、及びポリシー強制に使用されるその他のデータを含む、データベースを有していてよい。

ゲートウェイは、例えば、ＩＫＥメインモード又はアグレッシブモード、ＸＡＵＴＨ対応又はＸＡＵＴＨ非対応などの、特定のモードに事前に設定される。上記のように、ラップアプリが起動し、もし、そのアプリがゲートウェイの固有なパブリックＩＰアドレスとドメイン名とを有するように事前に設定されていれば、そのアプリは、ゲートウェイに接続することができる。メインモードセッションでは、６パケットの交換があり、その終わりには、ゲートウェイとラップアプリとが原則的に互いを信用しあうようになる。これが、１要素認証の終了であり、その後、後述のようにＸＡＵＴＨ／ＰＥＲＰ交換が起きる。

Ｐｈａｓｅ ２では、Ｐｈａｓｅ １トンネルを通じて新しいセキュリティセッションが取り決められ、アプリとゲートウェイとの間に、１本は伝送用の、もう１本は受信用の、２本の単方向Ｐｈａｓｅ ２トンネルが作成される。ＩＰＳＥＣの分野で知られるように、ゲートウェイ及びラップアプリは、新しいトンネルを通してデータを伝送するために各自によって使用される対称鍵を作成する。この時点で、Ｐｈａｓｅ ２は、実際のアプリデータをアプリとゲートウェイとの間で伝送するために使用される。Ｐｈａｓｅ ２の終わりまでに、説明の実施形態は、１）本明細書でＰＥＲＰと呼ばれる、ポリシー強制のためのプロトコルを利用し、２）後述の理由により、アプリに連合クッキーを送信する。

上記のように、ＩＰＳＥＣトンネルモードにおいて、ゲートウェイは、固有なプライベートＩＰアドレスをデバイス上のラップアプリに与える。多くの場合、デバイスは、２つ以上のラップアプリを有し、各アプリは、アプリごとに設定モードを経るので、アプリごとに固有なプライベートＩＰアドレスを得る。原則的に、ラップアプリは、アプリごとにゲートウェイへの登録を行う（或るアプリが「デバイスＡ上のアプリ１です。プライベートＩＰアドレスが必要です」というメッセージを送信することから始まり、デバイス上の別のアプリが「デバイスＡ上のアプリ２です。プライベートＩＰアドレスが必要です」というメッセージを送信し、以下同様に続く）。このようなラップアプリは、３つ、４つ、又は５つ以上あるかもしれず、たとえ同じ連合内にあろうとも、それぞれが独立に動作するアプリであるので、ゲートウェイとの間でそれぞれＰｈａｓｅ １を経る必要がある。このようなアプリは、同じ連合に属しているかもしれないが、実際は、そのことを除いて互いに関して何も知らない。

言及されたように、企業体又は任意のエンティティにとって、大量の固有な外部ＩＰアドレス（例えば「１０ネット」アドレス）を管理することは、技術面及びロジスティック面での困難な課題だと考えられる。一般的に、各デバイス上の各ラップアプリに固有ＩＰアドレスを発行することは、実現不可能だと考えられる。同時にまた、セキュリティの観点からすると、図７及び図８に関連して説明されたように、各ラップアプリとゲートウェイとの間にプライベートＶＰＮ又はトンネルを実装することが望ましいとされる。ゲートウェイのハードウェア及びソフトウェアは、大量のＩＫＥ／ＩＰＳＥＣセッションを遮断することができるように、拡張することができる。別の一実施形態では、ゲートウェイのハードウェア及びソフトウェアは、大量のＳＳＬ／ＶＰＮ接続を遮断することができる。したがって、ＩＰアドレスを集約させることが必要とされる。

一実施形態では、この集約は、１つのデバイス上の１つのアプリ連合に属するアプリのＩＰアドレスをまとめる、即ち集約させることを伴う。例えば、もし、ユーザのモバイルデバイス上の１つの連合内に８つのラップアプリがある場合は、ＶＰＮゲートウェイは、各クライアント（アプリ）がゲートウェイへのプライベートＶＰＮを有するように、そのデバイスのために８つの固有ＩＰアドレスを割り当てなければならない代わりに、デバイス上の１つの連合内の全てのラップアプリのために、１つの固有ＩＰアドレスを割り当てることができる。一実施形態では、ラップアプリは、１つの連合に属する。企業体の従業員は、従業員が仕事のために使用するいずれもラッピングされた全ての企業体アプリを、１つの連合内に維持する傾向がある。

ＩＰアドレスのこの集約の結果、説明の実施形態では、ゲートウェイは、ラッピングされたいずれかの連合アプリのためであろう戻ってきたトラフィックがデバイスによって受信されるときに、そのトラフィックをデバイス上のどの連合ラップアプリが受信するべきであるかを決定する方法を有する。即ち、その連合内のいずれかのアプリのために入ってきた全てのトラフィックを受信するものとして、どのアプリが指定されるべきであるかが決定され、そのトラフィックは、ひとたび連合内に入ると、適切な連合アプリへルーティングされる。連合内の各モバイルアプリケーションは、ゲートウェイとの間に同じＰｈａｓｅ ２セキュリティアソシエーション集合を有するので、１つのＩＰアドレスは、モバイルデバイス及びアプリ連合を決定するには十分であるが、特定のモバイルアプリを決定するには十分ではない。したがって、連合内の特定のモバイルアプリのための、発信用の正しいセキュリティアソシエーションをゲートウェイが選択することを可能にするために、ＩＰアドレスと併せて使用されるのは、ポート範囲である。ＩＰアドレスは、特定のアプリ連合のためのものであり、したがって、トラフィックは、少なくとも、正しい連合には到達する。ここで留意すべき重要な点は、ラップアプリとゲートウェイとの間のプライベート接続及びトラフィックが、依然として、Ｐｈａｓｅ ２セキュリティアソシエーションを用いていることであり、これは、ＩＰアドレスとポート範囲とによって実現される。したがって、データトラフィックは、やはり、上述のように、特定のラップアプリとゲートウェイとの間に確立された対称鍵を使用して暗号化される。

ＩＰアドレスを集約させ、それによって、ゲートウェイにおける多数のＶＰＮトンネルの遮断を可能にする方法を説明することを目的として、デバイス上にｎ個のラップアプリからなる連合があると想定し、それらのアプリは、全て、ユーザの雇用主（又はその他の関連のエンティティ／企業体）に関係し、したがって、そのアプリ連合は、雇用主の制御下でゲートウェイに結び付けられているとする。デバイス上に、仕事関連のラップアプリが１つしかないこともあり、この場合は、ここで説明される方法は不要だろう。この場合に必要とされるのは、いずれにしてもアプリが有するだろう固有ＩＰアドレスのみである。しかしながら、別の一実施形態では、もし、そうすることによる大きな欠点がなければ、この単独のアプリは、一貫性のために、１つのアプリからなる１つのアプリ連合として扱われ、やはり、後述されるプロセスを経ることができる。ユーザが連合内のアプリを起動すると、そのアプリは、ｐｅｒ−ａｐｐ ＶＰＮ実施形態に関連して上述された方法を使用して、ゲートウェイに接続する。アプリは、それ自身をゲートウェイに明かし、Ｐｈａｓｅ １を経る。ゲートウェイは、アプリに固有ＩＰアドレスを割り当て、一実施形態では、アプリが連合の一員であるかどうかを照会する。アプリは、（この例示では）そうであると応答し、すると、ゲートウェイは、連合クッキーを伝送する。ゲートウェイは、アプリに、その他のアプリと連合クッキーを共有するように指示する。

一実施形態では、アプリは、ラッピングされるときに、もしそれがゲートウェイから連合クッキーを受信したら（アプリは、連合クッキーを見たときにそれをどのように認識するかがわかる）、そのクッキーを同じ連合内のその他のアプリに使用可能にするべきであることがわかるように、設定される。ゲートウェイへの登録を試みる連合内のその他のアプリは、この連合クッキーを要求することになる。もし、このクッキーを、引き続き起動される別のアプリが有するならば、ゲートウェイは、後述される特定の方式によるＩＰアドレス及びその他のデータの操作に進んでよいことがわかる。

アプリは、ゲートウェイによって連合クッキーを要求されることになるので、ラッピングされるときに、連合クッキーを与えられるだろうこと又は連合クッキーを（同じ連合内の別のアプリから）得なければならないだろうことを認識するように、設定される。原則的に、連合アプリは、ラッピングされるときに、ゲートウェイとの通信時に連合クッキーを用いなければならないかもしれないことを認識するように、設定することができる。

一実施形態では、ゲートウェイは、モバイルデバイス上で最初に起動された連合アプリに連合クッキーを与えるときに、固有ＩＰアドレス、即ちそのモバイルデバイスに固有なＩＰアドレスもアプリに与える。これら２つのアイテム、即ちクッキー及びＩＰアドレスに加えて、一実施形態では、ゲートウェイは、モバイルデバイス上におけるポート範囲もアプリに与える。このポート範囲は、ソースＩＰ（モバイルデバイス）から宛先ＩＰ（ゲートウェイ）への及びその逆方向へのデータトラフィックを通信するために使用される。

アプリは、デバイス上の特定の連合アプリからデータを送信するときに（モバイルデバイス上の）どのソースポートを使用するかを制限するために、この範囲を使用する。説明すると、ゲートウェイは、１００〜１９９のポート範囲をアプリに送信することができる。これは、アプリに、トラフィックを生成してそれをプライベートＶＰＮ接続に載せて送信するときに１００〜１９９の範囲内のポートを使用しなければならないことを言っている。このようにすれば、ゲートウェイは、デバイスからトラフィックを受信し、トラフィックの発信元であるソースポート（モバイルデバイス上のポート）が１００〜１９９の範囲内であることを見れば、たとえＩＰアドレスがデバイスに固有であるだけであっても、トラフィックが特定の連合アプリから来ていることがわかる。デバイス上において、アプリが使用するポート番号は、デバイスのオペレーティングシステムによってアプリに割り当てられ、そのポート番号は、そのアプリに固有なものである。

ゲートウェイの企業体側では、ゲートウェイは、企業体サーバ（例えば、雇用主の内部ネットワーク）からトラフィックを受信した場合に、このポート範囲を、（ゲートウェイ上において、）デバイス上のアプリに対応付けられる宛先ポート範囲のテストとして使用することができる。主な制約は、（モバイルデバイス上の）ソースポート番号が、ゲートウェイによって割り当てられた範囲内であること、及びデバイス上のどの他のアプリも、ＶＰＮを通じて通信するときにそのポート番号を使用しないことである。上記のように、１つのアプリからなる連合も、たとえ固有ＩＰアドレスを使用すれば十分であってもポート範囲を割り当てられてよい。

この段階では、連合内の第１のアプリが動作しており、ゲートウェイとの間にセキュアなＶＰＮを有し、固有ＩＰアドレスを有し、ゲートウェイによって支持されたとおりのポート範囲内のポートからデータを伝送している。次は、連合内の第２のアプリが開かれる。この第２のアプリは、ゲートウェイによって連合クッキーを要求される。第２のアプリによってゲートウェイにクッキーが提示されると、この第２のアプリは、第１のアプリに与えられたのと同じＩＰアドレスを与えられる。ゲートウェイは、第２の連合アプリのためだけに第２の固有ＩＰアドレスを生成する必要はない。ただし、ゲートウェイは、例えば２００〜２９９のように、異なるポート範囲を第２のアプリに与える。第２のアプリが、自身のプライベートＶＰＮトンネルを通して２００〜２９９のポート範囲内のポートからデータを送信し始めると、ゲートウェイは、２００〜２９９のポート範囲内の任意のソースポートから受信されるデータが、特定の連合内の第２のアプリからであることがわかる。上記のように、ゲートウェイは、自身が、特定のソースポートを発信元とする受信トラフィックが特定のアプリ（即ち、第２のアプリ）から来ることを確信することができるように、第２のアプリに、それが使用するポートを確実にそのアプリに固有なものにするように、指示する。そのアプリのみが、その範囲内のポートを使用する。アプリが閉じられ、ポートの使用を終えたら、そのポートは閉じられ、オペレーティングシステムは、そのポート番号を再利用することができる。ゲートウェイは、それ以降は、そのアプリのみが２００〜２９９のポート範囲内のソースポートを使用することを予期しない。

図９は、ネットワークのコンポーネントを示したブロック図であり、本発明の様々な概念を例示している。図に示されているのは、モバイルデバイス９０２、ゲートウェイ９０４、及び企業体（プライベート）サーバ９０６である。デバイス９０２上の２つのアプリ９１２、９１４と、ゲートウェイ９０４との間には、２本のセキュアなトンネル、即ちＰＶＮ９０８及び９１０がある。

モバイルデバイス９０２は、ソースＩＰ（「ＳＲＣ ＩＰ」）と呼ばれるパブリックＩＰアドレス（パブリックキャリアによって割り当てられる）を有する。各アプリ９１２、９１４は、ともにゲートウェイ９０４によって割り当てられた、内部ＩＰアドレスとポート範囲とを有する。ゲートウェイ９０４は、パブリックキャリアによって割り当てられたパブリックＩＰアドレス（「ＤＥＳＴ ＩＰ」）、内部ＩＰアドレスプール、及びポート範囲データストアを有する。

２本のＶＰＮ，即ちセキュアなトンネル９０８、９１０がある。ＶＰＮ９０８は、モバイルデバイス９０２上のポートｘ９１６（ポートｘは、アプリ９１２専用である）を通してアプリ９１２をゲートウェイ９０４に接続する。セキュアトンネル９０８は、ＳＲＣ ＩＰアドレス及びＤＥＳＴ ＩＰアドレスを使用して確立される、即ち作成される。同様に、セキュアなトンネル９１０は、ＳＣＲ ＩＰアドレス及びＤＥＳＴ ＩＰアドレスを使用して作成され、ポートｍ９１８を通じてアプリ９１４をゲートウェイ９０４に接続する。しかしながら、セキュアトンネル内で移動するデータは、「トンネル内部」ＩＰアドレスとして特徴付けられる内部ＩＰアドレスと企業体サーバＩＰアドレスとからなるアドレスを有する。後述されるように、セキュアトンネル内を移動するデータは、通常、サーバ９０６などのプライベート企業体サーバと、特定のアプリとの間である。したがって、セキュアトンネルを通ってゲートウェイ９０４を通じて伝送されるデータは、デバイス９０２のパブリックＩＰアドレスではなく、アプリの内部ＩＰアドレスを使用する。

図１０は、一実施形態にしたがった、企業体サーバから特定のアプリへどのようにデータをルーティングして戻すかを決定するためにゲートウェイデバイスによって実行されるプロセスを示したフローチャートである。ステップ１００２において、デバイス及びゲートウェイは、ＡＴ＆Ｔ又はＣｏｍｃａｓｔなどの企業体のインターネットサービスプロバイダから、パブリックＩＰアドレスを割り当てられる（又は既に割り当てられている）。モバイルデバイスのためのパブリックＩＰアドレスは、ソースＩＰアドレス（ＳＲＣ ＩＰ）であり、ゲートウェイのためのパブリックＩＰアドレスは、宛先ＩＰアドレス（ＤＥＳＴ ＩＰ）である。

ステップ１００４では、ユーザが、モバイルデバイス上の第１のアプリを開く。ゲートウェイは、自身のＩＰアドレスプールから内部ＩＰアドレスを第１のアプリに割り当てる。ゲートウェイは、また、ポート範囲（本明細書では「第１のポート範囲」とも呼ばれる）もアプリに割り当てる。ゲートウェイは、これらのデータ、具体的には第１のアプリに割り当てられる内部ＩＰアドレス及びポート範囲を、データストアに格納している。ステップ１００６において、ユーザは、モバイルデバイス上の第２のアプリを開く。ゲートウェイは、同じ内部ＩＰアドレスを第２のアプリに割り当て、したがって、ゲートウェイが有する限られた内部アドレスプールから、別の内部ＩＰアドレスを用いる必要がない。第１及び第２のアプリは、同じゲートウェイ内部ＩＰアドレスを有する。ゲートウェイは、また、第１のアプリに割り当てられたポート範囲とは異なる第２のポート範囲を第２のアプリに割り当てる。これらのデータも、ゲートウェイに格納されている。後述されるように、データは、（ゲートウェイによって同じ内部ＩＰアドレスを与えられた全てのアプリのなかから）どのデータがデータを受信するべきであるかを調べるための逆引きを原則的に実施するために、ゲートウェイによって使用される。

ユーザは、第１のアプリを実行し、該アプリは、ステップ１００８において、プライベート企業体ネットワーク内でゲートウェイの背後で動作している（アプリに関係した）企業体サーバに向けて、ゲートウェイへデータを伝送し始める。ステップ１０１において、ユーザは、同じことを第２のアプリでも実施し、ここでも、ゲートウェイの背後の企業体サーバ（第１のアプリの場合と同じであっても又は異なっていてもよい）にデータが伝送される。この例では、２つのアプリは、同じ企業体サーバにデータを送信する。

ステップ１０１２において、企業体サーバは、ゲートウェイにデータを送り返す。このデータは、第１のアプリからの又は第２のアプリからのリクエストへの応答であってよい。プライベート企業体サーバ自体は、データが送信されるべき先がどのデバイス上のどのアプリであるかを知らない。したがって、企業体サーバは、探索も、いかなるタイプのアドレス変換も実施せず、単純に、内部ＩＰアドレスに伴われたデータをゲートウェイに送り返す。企業体サーバからゲートウェイへのデータは、内部ＤＥＳＴ ＩＰアドレスと、該ＩＰアドレスに埋め込まれた（即ち、トラフィックを発信したモバイルアプリの）ＤＥＳＴ ＰＯＲＴとを有する。

ステップ１０１４において、ゲートウェイは、サーバからデータを受信し、データが送信されるべき先の内部ＩＰアドレスと宛先ポートとを調べる。ゲートウェイは、企業体サーバからのデータとともに取得した内部ＩＰアドレスがデバイス上の特定のアプリ連合に対応することを決定するために、内部の又はそれ以外の形でアクセス可能なデータストア内で検索を実施し、デバイス上のそのアプリ連合内のどの特定のアプリがデータを受信するべきかを探索するために、宛先ポートを使用する。一実施形態では、ゲートウェイは、具体的にどのアプリがデータを受信するべきであるか及びデータを送信するためにどのセキュリティアソシエーションが使用されるべきであるかを決定するために、内部ＩＰアドレス及びポート番号の両アイテムを必要とする。ステップ１０１６において、ゲートウェイは、決定された特定のアプリに割り当てられた、モバイルデバイス上のポートを使用し、その特定のアプリに、そのアプリとゲートウェイとの間の専用のセキュアトンネルを通してデータを送信する。

図１１は、一実施形態にしたがった、ＶＰＮゲートウェイアクティブセッションモニタ画面を示したディスプレイのスクリーンショットである。ユーザディスプレイ１１０２は、ゲートウェイに接続されたユーザ、デバイス、及びアプリに関連する様々なデータ及び情報を示している。図１１に示されるようなアクティブセッションクエリの代表的なユーザは、企業体のモバイルセキュリティ責任者又はネットワークセキュリティ管理者であってよく、いずれも、その企業体におけるモバイルアプリ及びデータの利用に関して具体的で且つ正確な情報を学習することに関心がある。

画面１１０２には、選択されたユーザのセッションデータ１１０４、デバイスデータ１１０６、及びアプリデータ１１０８の、３つのカテゴリのデータがある。この情報は、ボックス１１１０に示された選択されたユーザについてのものである。セッションデータ１１０４は、ユーザ名、グループ、ログイン日時、現行セッションの長さ、及び認証プロバイダなどの情報を示している。この事例では、ユーザ認証は、再接続トークンを使用して提供される。

アクティブセッションデータのもう１つのカテゴリは、ボックス１１０６に示された「使用されるデバイス」である。ここに示されるのは、デバイス識別子（例えば、ＭＡＣアドレスの場合もある）、デバイスのハードウェアタイプ（スマートフォン、タブレット、ノートパソコン、又はその他のポータブルコンピューティングデバイスであってよい）、デバイス上のオペレーティングシステムのタイプ及びヴァージョン、並びにもし該当するならば、接続を提供しているキャリア名である。キャリアは、モバイルデバイス及びゲートウェイのパブリックＩＰアドレスを提供することができる。

第３のカテゴリは、選択されたユーザによって使用されているアプリケーションを記述するデータ１１０８である。このデータは、デバイス情報（ボックス１１０６に示されたデバイスデータと同じ）、アプリケーション名（この事例では、或るブラウザアプリと、「ＮＳＬｏｏｋｕｐ」と呼ばれる別のアプリである）、及び関連のアプリ情報を含む。関連のアプリ情報は、パッケージＩＤ、ＵＵＩＤ、及びセッションＩＤを含んでいてよい。なお、ＶＰＮゲートウェイを使用して監視されるアプリは、図１〜６において上述されたプロセスを使用してセキュリティラッピングされていることを思い起こすとよい。したがって、ボックス１１０８に挙げられたアプリをラッピングするために使用されるアプリセキュリティソフトウェアのヴァージョン情報も提供される。この情報は、いずれも、企業体における実際のアプリ利用に基づく徹底した詳細、即ち、どの（及びどの状態の）デバイス上にあるどの（及びどのヴァージョンの）アプリをどれくらいの長さにわたって誰が使用しているかを提供する。

図１２Ａ及び図１２Ｂは、本発明の実施形態を実現するのに適したコンピューティングシステムを示している。図１２Ａは、コンピューティングシステムとして考えられる１つの物理的形態を示している。もちろん、コンピューティングシステムは、集積回路、プリント回路基板、小型のハンドヘルドデバイス（携帯電話、携帯端末、若しくはＰＤＡなど）、パソコン、又はスーパーコンピュータなどの、多くの物理的形態をとりえる。コンピューティングシステム１２００は、モニタ１２０２、ディスプレイ１２０４、ケース１２０６、ディスクドライブ１２０８、キーボード１２１０、及びマウス１２１２を含む。ディスク１２１４は、コンピュータシステム１２００との間でデータをやり取りするために使用されるコンピュータ読み取り可能なメディアである。

図１２Ｂは、コンピューティングシステム１２００のブロック図の一例である。システムバス１２２０に取り付けられているのは、多岐にわたるサブシステムである。メモリ１２２４を含むストレージデバイスに、（１つ又は複数の）プロセッサ１２２２（中央演算処理装置、即ちＣＰＵとも呼ばれる）が接続されている。メモリ１２２４は、ランダムアクセスメモリ（ＲＡＭ）及び読み出し専用メモリ（ＲＯＭ）を含む。当該分野で知られるように、ＲＯＭは、データ及び命令をＣＰＵに単方向に送る働きをし、ＲＡＭは、通常、データ及び命令を双方向に送るために使用される。これらのメモリは、いずれのタイプも、後述されるコンピュータ読み取り可能メディアのうちの任意の適切なものを含んでいてよい。ＣＰＵ１２２２には、固定ディスク１２２６も双方向に接続され、追加のデータストレージ容量を提供しており、やはり、後述されるコンピュータ読み取り可能メディアのうちの任意を含んでいてよい。固定ディスク１２２６は、プログラムやデータなどを格納するために使用されてよく、通常は、一次ストレージよりも低速な二次ストレージメディア（ハードディスクなど）である。固定ディスク１２２６内に保持される情報は、もし適切であれば、仮想メモリとして標準形式でメモリ１２２４に組み込まれてよいことがわかる。着脱式ディスク１２１４は、後述されるコンピュータ読み取り可能メディアのうちの任意の形態をとりえる。

ＣＰＵ１２２２は、ディスプレイ１２０４、キーボード１２１０、マウス１２１２、及びスピーカ１２３０などの、様々な入出力デバイスにも接続されている。一般に、入出力デバイスは、ビデオディスプレイ、トラックボール、マウス、キーボード、マイク、タッチ画面、トランスデューサカードリーダ、磁気若しくは紙テープリーダ、タブレット、スタイラスペン、音声若しくは手書き文字認識装置、生体認証リーダ、又はその他のコンピュータの、任意であってよい。ＣＰＵ１２２２は、随意として、ネットワークインターフェース１２４０を使用して別のコンピュータ又は電気通信ネットワークに接続されていてよい。このようなネットワークインターフェースによって、ＣＰＵは、上述された方法のステップを実施する過程において、ネットワークから情報を受信可能である又はネットワークに情報を出力可能であると考えられる。更に、本発明の方法実施形態は、ＣＰＵ１２２２上のみで実行されてよい、又は処理の一部を共有するリモートＣＰＵと連携してインターネットなどのネットワーク上で実行されてよい。

本明細書では、例示としての実施形態及び本発明の用途が図示及び説明されてきたが、数多くのヴァリエーション及び変更形態が、本発明の概念、範囲、及び趣旨の範囲内である。これらのヴァリエーションは、当業者にならば、本出願を熟読した後に明らかになるだろう。したがって、説明された実施形態は、例示的であって非制限的であるとみなされ、本発明は、本明細書で与えられる詳細に限定されず、添付の特許請求の範囲の範囲及び均等物の範囲内で変更されえる。

Claims (20)

1. デバイス上の第１のアプリと、ＶＰＮゲートウェイとの間で、ＶＰＮトンネルを通して通信する方法であって、
   前記ＶＰＮゲートウェイから前記第１のアプリに、内部的に固有なＩＰアドレスを伝送することと、
   前記ＶＰＮゲートウェイから前記第１のアプリに、アプリ連合クッキーを伝送することと、
   前記アプリ連合クッキーを、アプリ連合内の第２のアプリと共有することと、
   前記第２のアプリに、前記内部的に固有なＩＰアドレスと同じＩＰアドレスを割り当てることと、
   前記第１のアプリに、第１のポート範囲を伝送し、前記第１のアプリは、前記第１のポート範囲内のポートを、前記第１のアプリから前記ＶＰＮゲートウェイへのデータ伝送のためのソースポートとして使用することと、
   前記ＶＰＮゲートウェイにおいて、前記第１のアプリからのデータ伝送を受信することと、
   前記ＶＰＮゲートウェイにおいて、前記データ伝送が前記第１のアプリから発していることを、前記ソースポートに基づいて決定することと、
   を備える方法。
2. 請求項１に記載の方法であって、更に、
   前記ＶＰＮゲートウェイから前記第２のアプリに、第２のポート範囲を伝送し、前記第２のアプリは、前記第２のポート範囲内のポートを、前記第２のアプリから前記ＶＰＮゲートウェイへのデータ伝送のためのソースポートとして使用することと、
   前記ＶＰＮゲートウェイにおいて、前記第２のアプリからのデータ伝送を受信することと、
   前記ＶＰＮゲートウェイにおいて、前記データ伝送が前記第２のアプリから発していることを、前記ソースポートに基づいて決定することと、
   を備える方法。
3. 請求項１又は２に記載の方法であって、更に、
   前記固有なＩＰアドレスは、前記アプリ連合によって使用され、前記アプリ連合内の個々のアプリは、個別の固有なＩＰアドレスを割り当てられない、方法。
4. 請求項１〜３のいずれか一項に記載の方法であって、更に、
   前記第１のアプリを、ＶＰＮゲートウェイＩＰアドレス及びＶＰＮゲートウェイドメイン名を伴うように設定し、それによって、前記第１のアプリを、その実行時に前記ＶＰＮゲートウェイに連絡することを可能にすることを備える方法。
5. 請求項１〜４のいずれか一項に記載の方法であって、更に、
   前記第１のアプリに、前記連合クッキーを前記第２のアプリと共有するように指示することを備える方法。
6. 請求項５に記載の方法であって、更に、
   前記第２のアプリの実行時に、前記第２のアプリに前記連合クッキーを要求することを備える方法。
7. 請求項１〜６のいずれか一項に記載の方法であって、更に、
   前記第１のアプリをラッピングするときに、前記第１のアプリを、連合クッキーを与えられるかもしれないこと又は前記連合内の別のアプリから連合クッキーを検索しなければならないかもしれないことを認識するように設定することと、
   前記第２のアプリをラッピングするときに、前記第２のアプリを、連合クッキーを与えられるかもしれないこと又は前記連合内の別のアプリから連合クッキーを検索しなければならないかもしれないことを認識するように設定することと、
   を備える方法。
8. 請求項１〜７のいずれか一項に記載の方法であって、更に、
   前記第２のアプリから前記連合クッキーを受信することを備える方法。
9. デバイス上の第１のアプリと、仮想プライベートネットワーク（ＶＰＮ）ゲートウェイとの間で、ＶＰＮトンネルを通して通信する方法であって、
   ＶＰＮゲートウェイから前記デバイス上の前記第１のアプリに、内部的に固有なＩＰアドレス及びアプリ連合クッキーを伝送し、前記アプリ連合クッキーは、アプリ連合内の第２のアプリと共有され、前記第２のアプリは、前記内部的に固有なＩＰアドレスと同じＩＰアドレスを割り当てられることと、
   前記ＶＰＮゲートウェイから前記第１のアプリに、第１のポート範囲を伝送し、前記第１のアプリは、前記第１のポート範囲内のポートを、前記第１のアプリから前記ＶＰＮゲートウェイへのデータ伝送のためのソースポートとして使用することと、
   前記ＶＰＮゲートウェイにおいて、前記第１のアプリからのデータ伝送を受信することと、
   前記ＶＰＮゲートウェイにおいて、前記データ伝送が前記第１のアプリから発していることを、前記ソースポートに基づいて決定することと、
   を備える方法。
10. 請求項９に記載の方法であって、更に、
    前記ＶＰＮゲートウェイから前記第２のアプリに、第２のポート範囲を伝送し、前記第２のアプリは、前記第２のポート範囲内のポートを、前記第２のアプリから前記ＶＰＮゲートウェイへのデータ伝送のためのソースポートとして使用することと、
    前記ＶＰＮゲートウェイにおいて、前記第２のアプリからのデータ伝送を受信することと、
    前記ＶＰＮゲートウェイにおいて、前記データ伝送が前記第２のアプリから発していることを、前記ソースポートに基づいて決定することと、
    を備える方法。
11. 請求項９又は１０に記載の方法であって、
    前記固有なＩＰアドレスは、前記アプリ連合によって使用され、前記アプリ連合内の個々のアプリは、個別の固有なＩＰアドレスを割り当てられない、方法。
12. 請求項９〜１１のいずれか一項に記載の方法であって、更に、
    前記第１のアプリを、ＶＰＮゲートウェイＩＰアドレス及びＶＰＮゲートウェイドメイン名を伴うように設定し、それによって、前記第１のアプリを、その実行時に前記ＶＰＮゲートウェイに連絡することを可能にすることを備える方法。
13. 請求項９〜１２のいずれか一項に記載の方法であって、更に、
    前記第１のアプリに、前記連合クッキーを前記第２のアプリと共有するように指示することを備える方法。
14. 請求項１３に記載の方法であって、更に、
    前記第２のアプリの実行時に、前記第２のアプリに前記連合クッキーを要求することを備える方法。
15. 請求項９〜１４のいずれか一項に記載の方法であって、更に、
    前記第１のアプリをラッピングするときに、前記第１のアプリを、連合クッキーを与えられるかもしれないこと又は前記連合内の別のアプリから連合クッキーを検索しなければならないかもしれないことを認識するように設定することと、
    前記第２のアプリをラッピングするときに、前記第２のアプリを、連合クッキーを与えられるかもしれないこと又は前記連合内の別のアプリから連合クッキーを検索しなければならないかもしれないことを認識するように設定することと、
    を備える方法。
16. 請求項９〜１５のいずれか一項に記載の方法であって、更に、
    前記第２のアプリから前記連合クッキーを受信することを備える方法。
17. 仮想プライベートネットワーク（ＶＰＮ）ゲートウェイであって、
    前記仮想プライベートネットワーク（ＶＰＮ）ゲートウェイからデバイス上の第１のアプリに、内部的に固有なＩＰアドレス及びアプリ連合クッキーを伝送するように構成された出力インターフェースであって、前記アプリ連合クッキーは、アプリ連合内の第２のアプリと共有され、前記第２のアプリは、前記内部的に固有なＩＰアドレスと同じＩＰアドレスを割り当てられ、前記出力インターフェースは、更に、前記ＶＰＮゲートウェイから前記第１のアプリに、第１のポート範囲を伝送するように構成され、前記第１のアプリは、前記第１のポート範囲内のポートを、前記第１のアプリから前記ＶＰＮゲートウェイへのデータ伝送のためのソースポートとして使用する、出力インターフェースと、
    前記第１のアプリからのデータ伝送を受信するように構成された、前記ＶＰＮゲートウェイにおける入力インターフェースと、
    前記第１のポート範囲を前記第１のアプリに関係付けるように構成されたマッピングメカニズムと、
    前記データ伝送が前記第１のアプリから発していることを、前記ソースポートに基づいて決定するように構成されたＶＰＮゲートウェイプロセッサと、
    を備えるＶＰＮゲートウェイ。
18. 請求項１７に記載のＶＰＮゲートウェイであって、
    前記出力インターフェースは、更に、前記ＶＰＮゲートウェイから前記第２のアプリに、第２のポート範囲を伝送するように構成され、前記第２のアプリは、前記第２のポート範囲内のポートを、前記第２のアプリから前記ＶＰＮゲートウェイへのデータ伝送のためのソースポートとして使用する、ＶＰＮゲートウェイ。
19. 請求項１７又は１８に記載のＶＰＮゲートウェイであって、
    前記マッピングメカニズムは、更に、前記第２のポート範囲を前記第２のアプリに関係付けるように構成される、ＶＰＮゲートウェイ。
20. 請求項１７〜１９のいずれか一項に記載のＶＰＮゲートウェイであって、
    前記ＶＰＮゲートウェイプロセッサは、更に、前記データ伝送が前記第２のアプリから発していることを、前記ソースポートに基づいて決定するように構成される、ＶＰＮゲートウェイ。

Images