JP2020522768A - カテゴリ指向パーサを用いたデータ損失防止 - Google Patents

Abstract

【解決手段】開示技術は、サービス固有のパーサが利用可能でないクラウドベースのサービスにデータ損失防止（ＤＬＰ）を適用するシステムを含む。システムは、既知のクラウドベースのサービスが、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアクセスされ、アクセスされているＡＰＩに対してサービス固有のパーサが利用可能でないことを判定する。システムは、アクセスされているＡＰＩに対してカテゴリ指向パーサを適用する。カテゴリ指向パーサは、或るカテゴリのサービスを実施する、多くの既知のプロバイダによって使用される複数のシンタックスから導出される複数のカテゴリ指向マッチルールを含む。カテゴリ指向パーサは、ＡＰＩを介して伝達されるコンテンツからメタデータを収集し、収集されたメタデータを変数に割り当てる。システムは、ＤＬＰプロセッサを起動し、収集されたメタデータを、ＡＰＩを介して伝達されるコンテンツの分析に集中するためのＤＬＰプロセッサに送信する。【選択図】 図１

Description

優先権主張

本出願は、２０１８年５月２２日出願の「カテゴリ指向パーサを用いたデータ損失防止」と題する米国特許出願第１５／９８６，７３２号（代理人事件整理番号：ＮＳＫＯ １０１１−１）の利益を主張する。

合体資料

以下の資料は、ここに完全に記載されているかの如く、参照により組み込まれる。

２０１４年３月５日出願の「ネットワーク配信サービス用セキュリティ」と題する米国特許出願第１４／１９８，４９９号（代理人事件整理番号：ＮＳＫＯ １０００−２）（現在は２０１６年７月１９日発行の米国特許第９，３９８，１０２号）。

２０１５年８月２５日出願の「クラウドコンピューティングサービス（ＣＣＳ）に格納された企業情報を監視及び制御するシステム及び方法」と題する米国特許出願第１４／８３５，６４０号（代理人事件整理番号：ＮＳＫＯ １００１−２）（現在は２０１８年３月２７日発行の米国特許第９，９２８，３７７号）。

２０１６年１２月２日出願の「クラウド・コンピューティング・サービスのデータ欠損トランザクションにおいてマルチパート・ポリシーを実施するシステム及び方法」と題する米国特許出願第１５／３６８，２４０号（代理人事件整理番号：ＮＳＫＯ １００３−２）。

２０１８年５月２２日出願の「カテゴリ指向パーサを用いたデータ損失防止」と題する米国特許出願第１５／９８６，７３２号（代理人事件整理番号：ＮＳＫＯ １０１１−１）。

開示される技術は、サービス固有のパーサが利用可能でないクラウドベースのサービスにデータ損失防止を適用することに関する。

本セクションで議論される主題は、本セクションにおけるその言及の結果、単に従来技術であると仮定すべきではない。同様に、本セクションで述べた問題または背景技術として提供された主題に関連する問題は、従来技術内で既に認識されたものと仮定すべきではない。本セクションの主題は単に様々なアプローチを示しているに過ぎず、また、それ自体または自発的に、請求項に記載の技術の実施に対応し得る。

現在、多くの企業機能のためにクラウドベースのサービスを使用することが一般的である。従って、顧客関係管理（ＣＲＭ）ソフトウェア製品を実行するために企業ネットワーク内にサーバをインストールする代わりに、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍの提供物等のソフトウェア・アズ・ア・サービス（ＳａａＳ）ソリューションを使用することができる。古典的なソリューションへのアクセスを記録し、保護することができる情報技術（ＩＴ）及びネットワーク・アーキテクチャのアプローチは、制限された制御を提供する。

データは、多くの場合、あらゆるビジネスの源泉であり、それが効果的に管理され、保護され、コンプライアンスの必要性を満たすことが重要である。過去のデータの保護は、主にオンプレミス・シナリオに焦点を当てていたが、現在、クラウドベースのサービスの採用が増加するにつれて、全てのサイズの企業は、現在、データの作成、編集、及び格納をクラウドに依存している。これは、新しい課題を提示する。クラウドは、その利点にも拘わらず、企業の機密データが容易に失われる。一つの理由として、複数のデバイスからクラウドサービスにより容易にアクセスできる点がある。他の理由として、クラウドサービスは、組織外の人々を含めて、データ共有が容易に行える点がある。これらの理由から、データが組織の制御から容易に逸脱し得る。

また、クラウドベースのサービスの数が指数関数的に増加するにつれて、数百の方法でデータが漏洩する可能性がある。異なるクラウドベースのサービスは、異なるサービスをユーザに提供する。例えば、ＣＲＭクラウドベースのサービスを使用して、従業員は、アカウントを管理し、機会を見て、レポートを生成することができる。適切な資格認定を用いて、従業員は、生成されたレポートをダウンロードし、クラウドベースのストレージ・サービスに格納することができる。従業員は、ダウンロードされたレポート及び他の企業文書を、組織外の人々と共有することができる。従業員は、メール送信中に間違ったファイルを添付したり、送信ボタンの押下が早過ぎたり、締め切りに急いでいる時に注意を払わなかったり、または、組織外の人々とデータを共有したり協力したりする可能性がある。

例えば、知的財産、非公開の財務情報、戦略的計画、顧客リスト、顧客または従業員に属する個人を特定可能な情報等の機密情報を保護するために、企業ネットワークを含む、複数の装置、ネットワークサービス、及びネットワークに亘って同じポリシーを実施する等、一貫した集中管理された制御を提供する機会が生じる。

図面において、同様の参照符号は一般的に異なる図を通して同様の部品を指す。また、図面は必ずしも一定の縮尺ではなく、代わりに、開示された技術の原理を図解することに一般的に重点が置かれている。以下の説明では、開示された技術の様々な実施態様が、以下の図面を参照して説明される。

インライン・プロキシが、企業ネットワークのユーザとクラウドベースのサービスとの間のネットワーク・トラフィックをモニタ及び解析して、データ損失を防止する、システムのアーキテクチャ・レベルの概略図を示す。

図１のインライン・プロキシのサブシステム・コンポーネントのブロック図である。

企業ユーザによってアクセスされているクラウドベースのサービスを決定するための高レベルのプロセス・ステップと、適切なパーサの選択とを示す。

サービス固有のパーサが利用可能である既知のクラウドベースのサービスがアクセスされている第１のシナリオを示す。

サービス固有のパーサが利用可能でない既知のクラウドベースのサービスがアクセスされている第２のシナリオを示す。

未知のクラウドベースのサービスがアクセスされている第３のシナリオを示す。

「個人ページ及びブログ」カテゴリにおいてクラウドベースのサービスの提供者にコメントを投稿するための、ヘッダ及びコンテンツ部分を含む例示的なメッセージデータを提示する。

カテゴリ・データベースに問い合わせることによってクラウドベースのサービスのカテゴリを識別するインライン・プロキシを示す。

図５Ａのクラウドベースのサービスに伝達されるコンテンツからメタデータを収集するための選択されたカテゴリ指向パーサを示す。

図４のメッセージデータ内のヘッダ・メタデータを収集するための例示的なカテゴリ指向パーサからのコンピュータ・プログラム・コードの一部分を示す。

図４の例示的なメッセージデータにおいて伝達されているコンテンツを識別するための、例示的なカテゴリ指向パーサからのコンピュータ・プログラム・コードの第２の一部分を示す。

図６Ｂで識別されたコンテンツをシステム変数に格納するための例示的なカテゴリ指向パーサからのコンピュータ・プログラム・コードの第３の一部分を示す。

開示された技術を実施するために使用することができるコンピュータ・システムの簡略化されたブロック図である。

以下の説明は、当業者が開示された技術を製作し使用することを可能にするために提示され、特定の用途及びその要件に即して提供される。開示された実施態様に対する様々な修正は、当業者には容易に明らかであり、本明細書で定義される一般原則は、開示される技術の精神及び範囲から逸脱することなく、他の実施態様及び用途に適用され得る。従って、開示された技術は、示された実施態様に限定されることを意図するものではなく、本明細書に開示された原理及び特徴と一致する最も広い範囲が与えられるべきである。
［序論］

企業ユーザは、複数のクラウドベースのサービスにアクセスして、製品及びサービスに関連する様々なアクティビティを実行する。例えば、ユーザは、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ（商標）等のクラウドベースの顧客関係管理（ＣＲＭ）システムＡＰＩにアクセスして、オープンな販売機会のレポートを生成することができる。ユーザは、コンピュータまたはモバイルデバイス等のエンドポイントにレポートをダウンロードすることができる。これに続いて、ユーザは、Ｂｏｘ（商標）等のクラウドベースのストレージ・サービスにアップロードすることによって、他のユーザとレポートを共有することができる。これらのインタラクションの監視は、データ損失防止プログラムの一部である。クラウドベースのサービスの普及は、各新しいクラウドベースのサービスのシンタックスを監視するためにカスタマイズされたサービス固有のパーサを開発することを困難にしている。

クラウドベースのサービスとのユーザのトランザクションは、企業のエンドポイントとクラウドベースのサービスのサーバとの間で生じる。エンドポイントとクラウドベースのサービスとの間に配置されたプロキシは、トランザクションを監視する。プロキシは、エンドポイントとサーバとの間のメッセージを傍受し、構文解析する。プロキシは、どのクラウドベースのサービスのアプリケーション・プログラミング・インターフェース（ＡＰＩ）がアクセスされているかを決定し、メタデータを収集するためにパーサ（コネクタとしても知られる）を適用する。

開示された技術を適用して、既知のクラウドベースのサービスは、「個人ページ及びブログ」、「ニュース・ウェブサイト」、「クラウドベースのストレージ・サービス」、及び「ソーシャル・メディア・サービス」等のサービスのカテゴリに整理される。カテゴリは、ユーザが同様のアクティビティを実行することを可能にするクラウドベースのサービスのプロバイダのユニフォーム・リソース・ロケータ（ＵＲＬ）のリストを含む。例えば、サービスの「個人ページ及びブログ」カテゴリのプロバイダは、ユーザが投稿を作成し、投稿についてコメントし、写真及びマルチメディアをアップロードまたは埋め込み、加減し、ＲＳＳ（リッチ・サイト・サマリ）フィードを公開すること等を可能にする。Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ（商標）及びＢｏｘ（商標）等の広く使用されるプロバイダの場合、メタデータを収集するサービス固有のパーサが提供される。しかしながら、既知のクラウドベースのサービスの多数のプロバイダのために、サービス固有のパーサが利用可能でない多くの既知のプロバイダが存在する。

カテゴリ内の様々なプロバイダは、カテゴリ内のサービスを実施するために異なるシンタックスを使用する。開示された技術を適用すると、カテゴリ指向パーサは、カテゴリ内のプロバイダのサンプルのインタラクション・シンタックス・パターンを合成する。カテゴリ指向パーサは、カテゴリ内のサンプル・プロバイダによって使用されるシンタックスから合成された複数のカテゴリ指向マッチルールを使用して、既知のクラウドベースのサービスからメタデータを収集する。カテゴリ指向パーサによって収集されたメタデータは、ＤＬＰプロセッサが、ＡＰＩを介して伝達されているコンテンツの分析に集中することを可能にする。本出願において、「コンテンツ」は、ユーザのコンテンツにおいては、ＡＰＩまたはコンテンツ記憶装置によって伝達されるコンテンツは、ヘッダデータ及びボディデータの両方を指す。場合によっては、「コンテンツ」は、メッセージのペイロードまたはボディを指すために、より狭い意味で使用される。これらの用語の違いは、使用法から明らかである。

カテゴリベースのパーサでさえ、サービスの全領域に及ぶわけではない。ユーザは、特定のパーサまたはカテゴリ指向パーサが利用可能でないＡＰＩを介して、未知のクラウドベースのサービスにアクセスすることができる。未知のクラウドベースのサービスがアクセスされていること、カテゴリが割り当てられていないこと、またはカテゴリ固有のパーサが利用可能でないことをプロキシが決定すると、汎用パーサが選択されて、ＡＰＩを介して伝達されているコンテンツからメタデータが収集される。汎用パーサは、デフォルト・マッチルールを使用して、ＡＰＩを介して伝達されるコンテンツからメタデータを収集する。プロキシが、コンテンツからメタデータを収集するために汎用パーサを使用する場合、ＤＬＰプロセッサは、メタデータが汎用パーサによって収集されることを通知される。これは、精度とリコールとの間のトレードオフを導く。
［システム概要］

クラウドベースのコンテンツのストレージ及びホスティング・サービス（集合的に「クラウドベースのサービス」）にデータ損失防止（ＤＬＰ）を適用するためのシステム及び種々の実施態様を説明する。図１は、本実施態様によるシステムのアーキテクチャ・レベルの概略図を示す。図１はアーキテクチャ図であるので、説明の明確さを改善するために、特定の詳細は意図的に省略される。図１の説明は、以下のように編成される。最初に、図の要素を説明し、続いてそれらの相互接続を説明する。次に、システムにおける要素の使用について、より詳細に説明する。

図１は、システム１００を含む。システム１００は、ユーザ・エンドポイント１１１と、クラウドベースのホスティング・サービス１３６と、ウェブ・サービス１３７と、クラウドベースのストレージ・サービス１５９と、メタデータ蓄積ストア１９９と、カテゴリ・データベース１９５と、インライン・プロキシ１６１と、ネットワーク１６５とを含む。クラウドベースのホスティング・サービス１３６、ウェブ・サービス１３７、及びクラウドベースのストレージ・サービス１５９は、集合的にクラウドベースのサービス１１７と呼ばれる。

コンピュータ１２１ａ〜ｎ、タブレット１３１ａ〜ｎ、及び携帯電話１４１ａ〜ｎ等のユーザ・エンドポイント１１１は、クラウドベースのサービス１１７に格納されたデータにアクセスし、インタラクションする。このアクセス及びインタラクションは、ユーザ・エンドポイントとクラウドベースのサービス１１７との間に介在するインライン・プロキシ１６１によって調節される。インライン・プロキシ１６１は、トラフィック・モニタ１７１及びＡＰＩ（アプリケーション・プログラミング・インターフェース）パーサ１８１を使用して、ユーザ・エンドポイント１１１とクラウドベースのサービス１１７との間のトラフィックをモニタする。インライン・プロキシ１６１は、クラウドベースのプロキシであってもよいし、構内に配置されてもよい。

「管理デバイス」実施態様では、ユーザ・エンドポイント１１１は、ユーザ・エンドポイント１１１から発信されるクラウドベースのサービス１１７に対するリクエスト及びリクエストに対するレスポンスが、ポリシー実施のためにインライン・プロキシ１６１を介してルーティングされることを確実にするルーティング・エージェント（図示せず）を用いて構成される。ユーザ・エンドポイント１１１がルーティング・エージェントと共に構成されると、それらは、それらの位置（構内または構外）に拘わらず、インライン・プロキシ１６１の領域または範囲下にある。

「非管理デバイス」実施態様では、ルーティング・エージェントで構成されていない特定のユーザ・エンドポイントは、インライン・プロキシ１６１によってモニタされるオンプレミス・ネットワーク内で動作しているとき、依然として、インライン・プロキシ１６１の範囲下にあり得る。

次に、システム１００の要素の相互接続について説明する。ネットワーク１６５は、コンピュータ１２１ａ〜ｎ、タブレット１３１ａ〜ｎ、携帯電話１４１ａ〜ｎ、クラウドベースのサービス１１７、メタデータ・ストア１９９、カテゴリ・データベース１９５、及び、インライン・プロキシ１６１の全てを、相互に通信可能に結合する（両矢印実線で示す）。実際の通信経路は、公衆及び／またはプライベート・ネットワーク上のポイント・ツー・ポイントであり得る。通信の全ては、様々なネットワーク、例えば、プライベート・ネットワーク、ＶＰＮ、ＭＰＬＳ回路、またはインターネットを介して行うことができ、適切なアプリケーション・プログラミング・インターフェース（ＡＰＩ）及びデータ交換フォーマット、例えば、リプレゼンテーショナル・ステート・トランスファ（ＲＥＳＴ）、ＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記（ＪＳＯＮ）、拡張マークアップ言語（ＸＭＬ）、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）、Ｊａｖａ（登録商標）メッセージ・サービス（ＪＭＳ）、及び／または、Ｊａｖａプラットフォーム・モジュール・システムを使用することができる。全ての通信を暗号化することができる。通信は、通常、ＬＡＮ（ローカル・エリア・ネットワーク）、ＷＡＮ（ワイド・エリア・ネットワーク）、電話ネットワーク（公衆交換電話ネットワーク（ＰＳＴＮ））、セッション開始プロトコル（ＳＩＰ）、無線ネットワーク、ポイント・ツー・ポイント・ネットワーク、星型ネットワーク、トークンリング型ネットワーク、ハブ型ネットワーク、ＥＤＧＥ、３Ｇ、４ＧＬＴＥ、Ｗｉ−Ｆｉ、及びＷｉＭＡＸ等のプロトコルを介するモバイルインターネットを含むインターネット等のネットワークを通して行われる。図１のエンジンまたはシステム・コンポーネントは、様々なタイプのコンピューティング・デバイス上で実行されるソフトウェアによって実施される。デバイスの実施例は、ワークステーション、サーバ、コンピューティング・クラスタ、ブレード・サーバ、及び、サーバ・ファームである。更に、ユーザ名／パスワード、オープン認証（ＯＡｕｔｈ）、Ｋｅｒｂｅｒｏｓ、ＳｅｃｕｒｅＩＤ、ディジタル証明書等の様々な承認及び認証技術を使用して、通信を保護することができる。

クラウドベースのサービス１１７は、ユーザに、クラウド内またはインターネット上で実施される機能を提供する。クラウドベースのサービス１１７は、ニュース・ウェブサイト、ブログ、ビデオ・ストリーミング・ウェブサイト、ソーシャル・メディア・ウェブサイト、ホスティッド・サービス、クラウド・アプリケーション、クラウド・ストア、クラウド・コラボレーション、及びメッセージングプラットフォーム等のインターネット・ホスティッド・サービス、及び／またはクラウド顧客関係管理（ＣＲＭ）プラットフォームを含むことができる。クラウドベースのサービス１１７は、ブラウザ（例えば、ＵＲＬを介して）またはネイティブ・アプリケーション（例えば、同期クライアント）を使用してアクセスすることができる。クラウドベースのサービスのカテゴリには、ソフトウェア・アズ・ア・サービス（ＳａａＳ）の提供、プラットフォーム・アズ・ア・サービス（ＰａａＳ）の提供、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）の提供が含まれる。ＵＲＬ／ＡＰＩを介して公開される企業アプリケーションは、カテゴリ指向パーサによってサポートされるサービスのカテゴリに適合することができ、または、カテゴリ指向パーサは、サービスの企業アプリケーション・カテゴリに対して書くことができる。今日の一般的なウェブ・サービスの例には、ＹｏｕＴｕｂｅ（登録商標）、Ｆａｃｅｂｏｏｋ（商標）、Ｔｗｉｔｔｅｒ（商標）、Ｇｏｏｇｌｅ（商標）、ＬｉｎｋｅｄＩｎ（商標）、 Ｗｉｋｉｐｅｄｉａ（商標）、Ｙａｈｏｏ（商標）、Ｂａｉｄｕ（商標）、Ａｍａｚｏｎ（商標）、ＭＳＮ（商標）、Ｐｉｎｔｅｒｅｓｔ（商標）、Ｔａｏｂａｏ（商標）、Ｉｎｓｔａｇｒａｍ（商標）、Ｔｕｍｂｌｒ（商標）、ｅＢａｙ（商標）、Ｈｏｔｍａｉｌ（商標）、Ｒｅｄｄｉｔ（商標）、ＩＭＤｂ（商標）、Ｎｅｔｆｌｉｘ（商標）、ＰａｙＰａｌ（商標）、Ｉｍｇｕｒ（商標）、Ｓｎａｐｃｈａｔ（商標）、Ｙａｍｍｅｒ（商標）、Ｓｋｙｐｅ（商標）、Ｓｌａｃｋ（商標）、ＨｉｐＣｈａｔ（商標）、Ｃｏｎｆｌｕｅｎｃｅ（商標）、ＴｅａｍＤｒｉｖｅ（商標）、Ｔａｓｋｗｏｒｌｄ（商標）、Ｃｈａｔｔｅｒ（商標）、Ｚｏｈｏ（商標）、ＰｒｏｓｐｅｒＷｏｒｋｓ（商標）、ＧｏｏｇｌｅのＧｍａｉｌ（商標）、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ（商標）、Ｂｏｘ（商標）、Ｄｒｏｐｂｏｘ（商標）、Ｇｏｏｇｌｅ Ａｐｐｓ（商標）、Ａｍａｚｏｎ ＡＷＳ（商標）、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ ３６５（商標）、Ｗｏｒｋｄａｙ（商標）、Ｏｒａｃｌｅ ｏｎ Ｄｅｍａｎｄ（商標）、Ｔａｌｅｏ（商標）、Ｊｉｖｅ（商標）、及び、Ｃｏｎｃｕｒ（商標）が含まれる。

組織に属するユーザは、クラウドベースのサービスの数百のプロバイダにアクセスして、組織の内部または外部の他のユーザとデータを生成し、格納し、協働し、共有する。既知のクラウドベースのサービスは、サービスの別個のカテゴリを提供するカテゴリ内において整理される。例えば、サービスの「個人ページ及びブログ」カテゴリに属するプロバイダは、ユーザが、自分の個人ページ上に投稿を作成し、投稿に関するコメントを作成し、写真及びマルチメディアをアップロードまたは埋め込み、ユーザからのコメントを加減し、ＲＳＳフィードを公開すること等を可能にする。「個人ページ及びブログ」カテゴリにおけるクラウドベースのサービスのプロバイダの幾つかの例には、Ｇｏｏｇｌｅ Ｐｌｕｓ（商標）、Ｂｌｏｇｇｅｒ（商標）、Ｓｑｕａｒｅｓｐａｃｅ（商標）、Ｗｉｘ（商標）、及びＷｏｒｄｐｒｅｓｓ（商標）が含まれる。サービスのカテゴリは、サービスのカテゴリの人気に応じて、数十から数千、またはそれ以上に及び得る多数の既知のプロバイダを含む。一実施態様では、それぞれがそのカテゴリのサービスを実施する少なくとも２５の既知のプロバイダがある。２５は、カテゴリ内のプロバイダの最小数の概算の推定値である。「ブログ及び個人ページ」カテゴリにおける５０のプロバイダの例示的なリストは、「ｈｔｔｐｓ：／／ｗｗｗ．ｓｐａｒｒｉｎｇｍｉｎｄ．ｃｏｍ／ｓｕｃｃｅｓｓｆｕｌ−ｂｌｏｇｓ／」で利用可能である。既知のクラウドベースのサービスの別個のカテゴリの他の例には、「ニュース・ウェブサイト」、「クラウドベースのストレージ・サービス」、「ソーシャル・メディア・サービス」、及び「ウェブメール」が含まれる。既知のクラウドベースのサービスの５０以上の別個のカテゴリのサービスが確認されている。例としては、技術、教育、健康及び栄養、旅行、家及び庭、自動車、専門家のネットワーク、オークション及び市場、科学、及びファッションが挙げられる。当業者であれば、開示された技術の精神及び範囲から逸脱することなく、追加のカテゴリのサービスを、他の現在または将来開発されるクラウドベースのサービスに適用することができることを理解するであろう。

サービスのカテゴリ及びカテゴリ毎のクラウドベースのサービスのプロバイダは、カテゴリ・データベース１９５に格納される。上に列挙した５つの例示的なサービスのカテゴリのクラウドベースのサービスは、サービスの特定のカテゴリを対処する１つのカテゴリ指向パーサを有する少なくとも５つのカテゴリ指向パーサによって供給される。

クラウドベースのサービス１１７は、セキュリティ・ポリシーを実施している組織のユーザに機能を提供する。ユーザが、エンドポイント１２１ａを介してクラウドベースのサービスにリクエストを送信すると、インライン・プロキシ１６１は、リクエスト・メッセージを傍受する。インライン・プロキシ１６１は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアクセスされているクラウドベースのサービスを識別するために、カテゴリ・データベース１９５に問い合わせる。一実施態様において、インライン・プロキシ１６１は、アクセスされるクラウドベースのサービスを識別するためにＡＰＩにアクセスするために使用されるユニフォーム・リソース・ロケータ内のドメイン名を使用する。アクセスされているＡＰＩに対してサービス固有のパーサが利用可能でない場合、インライン・プロキシ１６１は、アクセスされているＡＰＩにカテゴリ指向パーサを適用する。ＡＰＩを介して伝達されているコンテンツから収集されたメタデータは、カテゴリ指向パーサによって収集される。メタデータは、ＡＰＩを介して伝達されているコンテンツの分析に集中するためのデータ損失防止（ＤＬＰ）プロセッサに転送される。インライン・プロキシは、ユーザからメタデータ蓄積ストア１９９へのリクエスト・メッセージ内にメタデータを蓄積する。メタデータの蓄積は、クラウドベースのサービスとのユーザのインタラクションに関するより大きなコンテキストを構築するのに役立ち、これは、ＤＬＰプロセッサがその分析に集中するのに役立つ。

図２は、インライン・プロキシ１６１のサブシステム・コンポーネントを示すブロック図２００である。インライン・プロキシ１６１は、トラフィック・モニタ１７１及びＡＰＩパーサ１８１を含む。インライン・プロキシは、クラウドベースのサービス１１７にアクセスするために、コンピュータ１２１ａ、タブレット１３１ａ、または携帯電話１４１ａ等のエンドポイント上で作動するクライアントを介して、ユーザからリクエスト・メッセージを受信する。一実施態様では、クライアントとクラウドベースのサービスのサーバとの間の通信は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用する。リクエストを受信した後、インライン・プロキシ１６１は、リクエストしているクライアントに代わってサーバへの接続を確立する。これに続いて、クライアントからサーバへの全てのリクエスト・メッセージ及びサーバからクライアントへのレスポンス・メッセージが、プロキシ１６１によって検査され、ＤＬＰプロセッサに転送されて、データ損失防止のためのポリシーが実施される。インライン・プロキシ１６１を実行するデバイスは、ＨＴＴＰリクエストが発信された同じデバイス上で実行されるエンドポイント・ルーティング・クライアントがＨＴＴＰリクエストをルーティングするクラウドベースのサーバとすることができる。別の実施態様では、インライン・プロキシ１６１を実行するデバイスは、ユーザ・エンドポイント１１１からのＨＴＴＰリクエストを能動的に処理するように配置されたオンプレミス・ルーティング・アプライアンスである。

例えば、ユーザがブログ投稿にコメントを投稿しているとすると、リクエストＵＲＬは「ｈｔｔｐｓ：／／ｔｅｓｔ９５１３４２０５６．ｗｏｒｄｐｒｅｓｓ．ｃｏｍ／ｗｐ−ｃｏｍｍｅｎｔｓ−ｐｏｓｔ．ｐｈｐ」であり、従って、ドメインネーム（ホストネームとも呼ばれる）は「ｗｏｒｄｐｒｅｓｓ．ｃｏｍ」である。ドメイン名を使用して、カテゴリ識別子コンポーネント２３５は、カテゴリ・データベース１９５に照会し、「個人ページ及びブログ」カテゴリに属する既知のクラウドベースのサービス「Ｗｏｒｄｐｒｅｓｓ（商標）」がＡＰＩを介してアクセスされていることを判定する。これに続いて、パーサ・セレクタ２４５は、サービス固有パーサ２７５がアクセスされているＡＰＩに対して利用可能であるかどうかを判定する。アクセスされているＡＰＩに対してサービス固有のパーサが利用可能でない場合、パーサ・セレクタ２４５は、トラフィック・パーサ・コンポーネント２５５からサービスの「個人ページ及びブログ」カテゴリ内のクラウドベースのサービスにサービスを提供するカテゴリ指向パーサを選択する。

ユーザが未知のクラウドベースのサービスにアクセスしようと試みるとき、インライン・プロキシは、アクセスされているＡＰＩからメタデータを収集するために、汎用パーサ２８５を使用する。クラウドベースのサービスは、そのＡＰＩを介して伝達されているコンテンツからメタデータを収集するために利用可能なサービス固有のパーサがない場合、未知のクラウドベースのサービスと呼ばれる。更に、未知のクラウドベースのサービスはサービスの何れのカテゴリにも属さないので、ＡＰＩを介して伝達されるコンテンツからメタデータを収集するためにカテゴリ指向パーサは利用可能ではない。従って、汎用パーサ２８５は、未知のクラウドベースのサービスのＡＰＩを介して伝達されているコンテンツからメタデータを収集する。
［カテゴリ指向パーサ及び汎用パーサの選択］

インライン・プロキシ１６１は、エンドポイント上で作動するクライアントを介して企業ユーザからリクエストを受信し、クライアントに代わってリクエストされたクラウドベースのサービスへの接続を確立する。接続の確立に続いて、インライン・プロキシは、既知のクラウドベースのサービスがＡＰＩを介してアクセスされているかどうかを判定する。図３Ａ〜３Ｄは、既知及び未知のクラウドベースのサービスが、それぞれのＡＰＩを介してアクセスされる場合の、パーサ（コネクタとも呼ばれる）の選択及び識別の３つの実施例を示す。

図３Ａは、ブロック３５１で（エンドポイント上のクライアントを介して）インライン・プロキシ１６１が企業ユーザＡから、クラウドベースのサービスにアクセスするリクエストを受信するプロセスの概観３００Ａを提示する。インライン・プロキシ１６１は、既知のまたは未知のクラウドベースのサービスがアクセスされているかどうか、及び既知のクラウドベースのサービスによって実施されるサービスのカテゴリを判定する（ブロック３５３）。インライン・プロキシによるこの判定に続いて、３つの異なるタイプのパーサの選択に繋がる３つの経路が可能である。以下の実施例では、クラウドベースのサービスのクライアントとサーバの間の通信は、ＨＴＴＰプロトコルを使用する。

図３Ｂは、クライアントからのリクエスト・メッセージにおいてインライン・プロキシによって受信されたＵＲＬが「ｈｔｔｐｓ：／／ａｐｉ．ｂｏｘｃｌｏｕｄ．ｎｅｔ／．．．．」（３６１）である実施例３００Ｂを示す。リクエストＵＲＬは、説明のために部分的に示されている。ドメイン名「ｂｏｘｃｌｏｕｄ．ｎｅｔ」３５４及びクラウドベースのサービス「Ｂｏｘ（商標）」３５７は、リクエストＵＲＬ ３６１からインライン・プロキシによって決定される。インライン・プロキシは、カテゴリ・データベース１９５に照会し、アクセスされているＡＰＩに対してサービス固有のパーサが利用可能であることを判定する（ブロック３３５）。一実施態様では、カテゴリ・データベース１９５は、既知のクラウドベースのサービスのプロバイダのドメインネームのエントリリストを維持する。エントリリストは、プロバイダに利用可能なサービス固有のパーサを識別する。これに続いて、インライン・プロキシは、Ｂｏｘ（商標）ＡＰＩのためのサービス固有のパーサを選択し、それをリクエスト・メッセージに適用して、ＡＰＩを介して伝達されているコンテンツからメタデータを収集する（ブロック３３７）。収集されたメタデータは、ＤＬＰに転送され、ＡＰＩを介して伝達されるコンテンツの分析に集中するのに使用される。

図３Ｃの実施例３００Ｃでは、リクエスト・メッセージのＵＲＬは“ｈｔｔｐｓ：／／ｗｗｗ．ｗｅｃｈａｔ．ｃｏｍ／．．．．”（３６２）である。インライン・プロキシは、ドメイン名を「ｗｅｃｈａｔ．ｃｏｍ」（３５５）と、リクエストされたクラウドベースのサービスによって実施されるサービスのカテゴリを「個人ページ及びブログ」カテゴリ３５８と、判定する。プロバイダに利用可能なサービス固有のパーサは存在しない。インライン・プロキシは、「個人ページ及びブログ」カテゴリ指向パーサを選択し、適用して（ブロック３５７）、ＡＰＩを介して伝達されているコンテンツからメタデータを収集する。収集されたメタデータは、ＤＬＰプロセッサに送られ、ＡＰＩを介して伝達されるコンテンツの分析に集中するのに使用される。図３Ｂ及び３Ｃに示されるクラウドベースのサービスの実施例は、サービス固有パーサまたはカテゴリ指向パーサが利用可能な既知のクラウドベースのサービスである。別の実施態様では、カテゴリ指向パーサを選択するために、ホスト内のリソースを識別する経路が使用される。例えば、リクエスト・メッセージ内のＵＲＬ「ｈｔｔｐｓ：／／ｍｙｓｉｔｅ．ｃｏｍ／ｆｏｒｕｍｓ」を考える。ＵＲＬ「／ｆｏｒｕｍｓ」のリソース部分は、リクエストされたクラウドベースのサービスによって実施されるサービスのカテゴリが「個人ページ及びブログ」カテゴリに属することを判定するために使用される。これは、ｍｙｓｉｔｅ．ｃｏｍが２つの異なるカテゴリ指向パーサで処理されるサービスを提供する場合に最も役立つ。カテゴリの識別に続いて、上述のように、カテゴリ指向パーサが選択される。

図３Ｄに示す実施例３００Ｄでは、リクエスト・メッセージのＵＲＬ３６３は「ｈｔｔｐｓ：／／ｗｗｗ．ｇｌｕｕ．ｏｒｇ／．．．．」である。インライン・プロキシは、アクセスされるクラウドベースのサービスのドメイン名が「ｇｌｕｕ．ｏｒｇ」であると判定する（３５６）。しかし、インライン・プロキシは、アクセスされているＡＰＩからメタデータを収集するために利用可能なサービス固有パーサまたはカテゴリ指向パーサがないので、これが未知のクラウドベースのサービスであると判定する（３５９）。クラウドベースのサービスの新しいプロバイダ、またはクラウドベースのサービスのまれにアクセスされるプロバイダは、クラウドベースのサービスのこのカテゴリに入る可能性が高い（ブロック３７５）。インライン・プロキシ１６１は、未知のクラウドベースのサービスのＡＰＩに汎用パーサを適用する（ブロック３７７）。
［クライアントからクラウドベースのサービスのサーバへのリクエスト・メッセージ］

図４は、クライアントからクラウドベースのサービス１１７のサーバへの例示的なＨＴＴＰリクエスト・メッセージ４００を示す。リクエスト・メッセージは、４つの主要部分、すなわち、一般ヘッダ４１１、レスポンス・ヘッダ４３１、リクエスト・ヘッダ４６１、及びフォーム・データ４８１を含む。最初の３つの部分は、送信者、受信者、及びメッセージ内容に関する情報を提供するヘッダ・フィールドを含む。一般ヘッダ４１１は、ＨＴＴＰリクエスト・メッセージとＨＴＴＰレスポンス・メッセージの両方に適用される。この部分は、アクセスされているクラウドベースのサービスのドメイン名４１５を更に含むリクエストＵＲＬ４１８を含む。リクエスト・ヘッダ４６１は、アクセスされるクライアントまたはリソースに関する更なる情報を含む。リクエスト方法は、ラベル４５３によって示されるように「ＰＯＳＴ」である。ＨＴＴＰ・ＰＯＳＴリクエスト方法は、ウェブ・サーバが、それを格納するためのリクエスト・メッセージの本文に含まれるデータを受け入れることをリクエストする。ＰＯＳＴ方法は、完成したウェブフォームをサブミットするとき、またはクラウドベースのストレージ・サービスにファイルをアップロードするときに使用される。リクエスト・ヘッダ４６１内のコンテンツ・タイプ・フィールド４６６は、リクエスト・メッセージ内の値がキー値タプルにおいて符号化されることを識別する。レスポンス・ヘッダ４３１は、サーバの位置及び名前等のレスポンスに関する追加情報を含む。メッセージの最後の部分は、リクエスト・メッセージ内のコンテンツまたはペイロードを含むフォーム・データ４８１である。例示的なリクエスト・メッセージ４００では、ユーザは、コメント４７４「あなたの投稿は非常に有益です。ありがとうございます。」をブログに投稿している。

例示的なリクエスト・メッセージ４００の構造を説明したので、次に、リクエスト・メッセージ４００内の情報を使用して、インライン・プロキシ１６１によるカテゴリ指向パーサの選択を説明する。図５Ａ及び５Ｂは、インライン・プロキシ１６１の一実施態様を示す。インライン・プロキシ１６１によって実行される分析は、例えば、情報を受信または検索し、情報を処理し、結果を格納し、結果を送信するように構成された１または複数のプロセッサによって、コンピュータまたは他のデータプロセッシングシステムを用いて少なくとも部分的に実施することができる。他の実施態様は、異なる順序で、及び／または図示されたものとは異なる、より少ない、または追加のアクションで、結果を実行することができる。

インライン・プロキシ１６１は、ユーザ・エンドポイント１１１とクラウドベースのサービス１１７（クラウドベースのホスティング・サービス１３６及びストレージ・サービス１５９を含む）との間に挿入される。インライン・プロキシ１６１は、ユーザのエンドポイント（コンピュータ１２１ａ〜ｎ、タブレット１３１ａ〜ｎ、及び携帯電話１４１ａ〜ｎ等）からのウェブブラウザ・トラフィックを監視する。ユーザのエンドポイントからリクエストを受信すると、インライン・プロキシ１６１は、リクエストしたクライアントに代わってサーバへの接続を確立する。従って、インライン・プロキシ１６１は、クラウドベースのサービスからダウンロードされ、クラウドベースのサービスにアップロードされた任意のドキュメントを含むリクエスト及びレスポンス・メッセージをリアルタイムで監視する。一実施態様では、インライン・プロキシ１６１はＨＴＴＰ（ハイパーテキスト転送プロトコル）プロキシであり、ＨＴＴＰトランザクションにおけるリクエスト及びレスポンス・メッセージを検査する。

図５Ａは、企業ユーザＡが、ブログ投稿にコメントを投稿するために、クラウドベースのサービス１１７に（コンピュータ１２１ａを介して）リクエスト・メッセージ４００を送信する実施例５００Ａを示す。インライン・プロキシ１６１は、ドメイン名「ｗｏｒｄｐｒｅｓｓ．ｃｏｍ」４１５を識別するために、リクエスト・メッセージ４００内のリクエストＵＲＬ４１８を構文解析する。インライン・プロキシ１６１は、リクエストされたクラウドベースのサービス「ｗｏｒｄｐｒｅｓｓ．ｃｏｍ」がサービス３５８の「個人ページ及びブログ」カテゴリに属することを判定するために、カテゴリ・データベース１９５に問い合わせる。インライン・プロキシ１６１は更に、アクセスされているクラウドベースのサービス「ｗｏｒｄｐｒｅｓｓ．ｃｏｍ」のＡＰＩのためのサービス固有のパーサが存在しないことを識別する。図５Ｂは、リクエストされたクラウドベースのサービスのカテゴリを対処するカテゴリ指向パーサの選択を示す。インライン・プロキシ１６１は、トラフィック・パーサ・コンポーネント２５５内の利用可能なカテゴリ指向パーサから、「個人ページ及びブログ」カテゴリのサービスに属するクラウドベースのサービスのプロバイダにサービスを提供する「個人ページ及びブログ」カテゴリ指向パーサを選択する。
［カテゴリ指向パーサ］

カテゴリ指向パーサの選択を説明した後、ここで、リクエスト・メッセージ４００に対するカテゴリ指向パーサの適用を紹介する。カテゴリ指向パーサ（コネクタとも呼ばれる）は、リクエスト及びレスポンス・メッセージを構文解析し、実行されているアクティビティ、例えば、「ログイン」、「ファイル・アップロード」、「ファイル・ダウンロード」を識別しようと試みる。ユーザは、クラウドベースのサービスによって提供されるサービスに関連する多くのアクティビティを実行することができる。アクティビティの特定に続いて、カテゴリ指向パーサは、アクティビティに関連するメタデータを収集し、ＡＰＩを介して伝達されているコンテンツの分析に集中するのに使用するためにＤＬＰプロセッサに送信する。

固有パーサは、既知のクラウドベースのサービスのＡＰＩを使用して実行することができる全てのアクティビティを識別するためのロジックを含む。しかし、企業ユーザによってアクセスされる既知のクラウドベースのサービスの多数のプロバイダのために、全てのプロバイダのＡＰＩのための固有パーサを構築することは実現可能ではない。或るカテゴリのサービスを実施するクラウドベースのサービスは、ユーザが同様のアクティビティを実行することを可能にし、例えば、「個人ページ及びブログ」カテゴリのサービスを実施するクラウドベースのサービスは、ユーザが、投稿の作成、投稿に関するコメント、写真及びマルチメディアのアップロードまたは埋め込み、加減し、ＲＳＳ（リッチ・サイト・サマリ）フィードの公開すること等のアクティビティを実行することを可能にする。カテゴリ指向パーサは、カテゴリ指向マッチルールを使用して、リクエスト・メッセージ及びレスポンス・メッセージから関連するメタデータを収集する。図６Ａ、６Ｂ、及び６Ｃは、「個人ページ及びブログ」カテゴリ指向パーサによるメッセージ４００の段階的構文解析を示す。「個人ページ及びブログ」カテゴリ指向パーサの構文解析ロジックは、擬似ステートメントを使用して示される。
［“コメントを投稿する”アクティビティ］

図６Ａは、リクエスト・メッセージ４００の部分と、実行されたアクティビティを識別するための「個人ページ及びブログ」カテゴリ指向パーサ内の対応するロジックとを識別する図６００Ａである。一実施態様では、カテゴリ指向パーサ内の構文解析ロジックは、アクティビティに応じて整理される。例えば、「個人ページ及びブログ」カテゴリ指向パーサの場合、アクティビティは、「コメントを投稿する」、「ファイルをアップロードする」等を含む。メッセージ（リクエストまたはレスポンス）の構文解析を実行する前に、メッセージ内のヘッダは、アクティビティを決定するために識別ルールにマッチングされる。図６Ａは、「個人ページ及びブログ」カテゴリ指向パーサの一部６０１を示す。＜ヘッダ・マッチ・セグメント＞タグ６５０及び＜エンド・オブ・マッチ・セグメント＞タグ６９０は、それぞれ、カテゴリ指向マッチルールを使用する前に、ＵＲＬリクエスト内のパラメータを識別ルールにマッチさせるマッチ・ステートメント６６２及び６８２を含む。識別ルールは、メッセージ中のコンテンツがキー値ペアの形式であり、ＨＴＴＰ・ＰＯＳＴ方法を使用してサーバに送信されることをリクエストする。ブール論理ステートメント６７２は、両方のステートメント６６２及び６８２が、カテゴリ指向マッチルールの適用のために真である必要があることを示す。図４に示す「コメントを投稿する」メッセージに基づいた実施例を以下に示す。

一対の例示的なマッチ・ステートメント６６２及び６８２において、マッチ・ステートメント内の値は、ラベル４５３及び４６６によって示される、リクエスト・メッセージ４００のリクエスト・ヘッダ部分４６１に含まれるリクエスト・パラメータに対してマッチングされる。これらのパラメータは、マッチ・ステートメントに対してテストされる。マッチルールは、左辺が右辺にマッチする論理式を形成する。マッチ・ステートメントの「フィールド名」部分（マッチ・ステートメント６６２内のラベル６６３によって識別されるような）は、「マッチする値」ステートメント６６７内の「リテラル」がマッチするリクエスト・ヘッダ内のリクエスト・パラメータのラベルを識別する。一実施態様では、最初の一致ステートメント６６２において、フィールド名６６３は、リクエスト・ヘッダ４６１のラベル４６６によって識別されるリクエスト・パラメータにマップする「コンテンツ・タイプ」フィールドである。「コンテンツ・タイプ」リクエスト・パラメータ４６６は、メッセージのコンテンツ（図６Ｂに示される）がキー値ペアの形式であることを示す値「ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｗｗｗ−ｆｏｒｍ−ｕｒｌｅｎｃｏｄｅｄ」を有する。この値は、ステートメント６６７内の「リテラル」値に対してテストされる。ＨＴＴＰ・ＰＯＳＴメッセージ内の「コンテンツ・タイプ」フィールド値の他の実施例は、ＪａｖａＳｃｒｉｐｔオブジェクト表記（ＪＳＯＮ）データ交換フォーマットを示す「アプリケーション／ｊｓｏｎ」と、多目的インターネットメール拡張（ＭＩＭＥ）符号化を示す「マルチパート／フォーム・データ」を含む。「マッチタイプ」ステートメント６６５は、実行されたマッチのタイプ、例えば、文字列マッチを示す。第２のマッチ・ステートメント６８２は、リクエスト・メッセージ内のリクエスト・パラメータ「方法」４５３の値を比較して、その方法がＨＴＴＰ・ＰＯＳＴ方法であることを判定する。一実施態様では、リクエスト・メッセージ内の「方法」リクエスト・パラメータの値が、マッチングを判定するために、ステートメント６８６に示されるように、許可された方法値のリストに対してテストされる。

マッチ・ステートメント６６２及び６８２の両方の結果が真である場合、「個人ページ及びブログ」カテゴリ指向パーサは、図６Ｂ（６００Ｂ）のボックス６０２に示すように、カテゴリ指向マッチルール６１３を適用して、リクエスト・メッセージ４００内にデータ４８１を形成する。フォーム・データ（ＨＴＴＰ・ＰＯＳＴデータまたはＰＯＳＴボディとも呼ばれる）は、キー値ペアの形式でメッセージ４００のコンテンツを含む。カテゴリ指向マッチルールは、上記で識別された「コンテンツ・タイプ」に従って形成される。コンテンツが（例示４００の場合のように）キー値ペアとして編成される場合には、各々のカテゴリ指向マッチルールは、メッセージ中の「キー」リテラルを識別するための「キー・ツー・マッチ」ステートメントを含む。カテゴリ指向マッチルール６１３は、それぞれ、＜ボディ・マッチ・セグメント＞タグ６４１及び＜エンド・オブ・マッチ・セグメント＞タグ６９１内に囲まれたアクションのリストである。カテゴリ指向マッチルールのマッチングに関連する他のタイプのアクションには、システム変数にメタデータを割り当てること、及びＤＬＰプロセッサにメタデータを送信することが含まれる。

カテゴリ指向マッチルール６１３は、「個人ページ及びブログ」カテゴリ指向パーサによって対処される「個人ページ及びブログ」カテゴリのサービスを実施するために、及び、例えば、サービスの「コメントを投稿する」アクティビティを実施するために、多数の既知のプロバイダによって使用される複数のシンタックスから導出される。一実施態様では、複数のカテゴリ指向マッチルールは、少なくとも１０のマッチルールを含み、これは、幾つかのサービスで利用可能なアクティビティの複雑さのおおよその下限を反映している。１０は、経験に基づく、特定のカテゴリに対するマッチルールの実際的な下限である。最大値は決定されていないが、実際には、１０００のマッチルールは厄介であり、更なるカテゴリへのカテゴリの細分化を招く。これらのマッチルールは、カテゴリ指向パーサによって対処されるカテゴリのサービスを実施するために、多数の既知のプロバイダによって使用される複数のシンタックスから導出される。一実施態様において、複数のカテゴリ指向マッチルールは、それぞれがカテゴリ指向パーサによって対処されるカテゴリのサービスを実施する少なくとも２５の既知のプロバイダによって使用されるシンタックスから導出される。２５は、カテゴリ内のプロバイダの最小数のおおよその推定値である。先に提示したように、「個人ページ及びブログ」カテゴリの５０のプロバイダの例示的なリストは、「ｈｔｔｐｓ：／／ｗｗｗ．ｓｐａｒｒｉｎｇｍｉｎｄ．ｃｏｍ／ｓｕｃｃｅｓｓｆｕｌ−ｂｌｏｇｓ／」で利用可能である。サービスの「個人ページ及びブログ」カテゴリに属するクラウドベースのサービスの異なるプロバイダは、フォーム・データ内のコンテンツを記述するために、キー値ペア内の異なる「キー」を使用する。例示的なメッセージ４００では、ユーザのコメントは、キーが「コメント」であり、値が、ブログ投稿上のユーザのコメントである「あなたの投稿は非常に有益です。ありがとうございます。」であるキー値ペア４７４として含まれる。ステートメント６８５（カテゴリ指向マッチルール６８８）がリテラル「コメント」の値を有すると仮定する。これは、キー値ペア４７４内のリクエスト・パラメータ・キー「コメント」に対してテストされた場合に肯定的なマッチをもたらす。

しかし、カテゴリ指向マッチルール６１３は、他の既知のクラウドベースのプロバイダからのメッセージからメタデータを捕捉しようと試みる複数のマッチルール６５８、６６８、６７８、６８８等を含むことが分かる。例えば、第２のプロバイダは、「メッセージ」等の異なるキーを使用して同じコメントを含むことができる。そのような実施例では、リテラル「メッセージ」にマッチするキーを有する別のマッチルールが、マッチルール６８８の代わりに適用される。マッチルール６１３は、キー値ペアの形式であるフォーム・データ（または投稿データ）を構文解析するためのロジックを含む。異なるマッチ・ロジックを有する異なるセットのマッチルールが、上述したようなＪＳＯＮ及びＭＩＭＥのような他のフォーマットのデータを含むリクエスト及びレスポンス・メッセージを構文解析するために適用される。マッチルール６８８は、ステートメント６８３「フィールド名：リテラル」を含む。リクエスト・メッセージ４００の実施例では、フィールド名は、「投稿データ」または「フォーム・データ」である。従って、このマッチルールでは、ステートメント６８５で識別されたキー「コメント」を、キー値ペアを含むフォーム・データ（または投稿データ）４８１にマッチさせて、キー「コメント」がフォーム・データに存在するか否かを判定する。カテゴリ指向マッチルール６１３の完全なリストは、図６Ｂのボックス６０２には提示されていない。実施例の目的は、ＡＰＩを介して伝達されているコンテンツからメタデータを収集するためのカテゴリ指向マッチルールの適用を例示することである。

図６Ｃは、アサイン・ステートメント６１４（ボックス６０３に示される）が、リクエスト・メッセージ４００内のキー値ペアからのキーの値をシステム変数に割り当てる実施例６００Ｃを提示する。上記で説明したように、カテゴリ指向マッチルール６１３は、カテゴリ指向パーサによって対処されるカテゴリのサービスを実施するためにクラウドベースのサービスの多数の既知のプロバイダによって使用される複数のシンタックスから導出される。カテゴリ指向パーサは、６８０等のアサイン・ステートメントを使用することによって、成功裏に解決されたマッチルールの結果を保持する。成功裏に解決されたマッチルールに相関名を持つアサイン・ステートメントを使用すると、保持されている値がシステム変数に割り当てられる。一実施態様では、アサイン・ステートメント６８０は、ステートメント６８９内のシステム変数に値を割り当てるコンテンツ・タイプを識別するステートメント６８４「アサインメント・タイプ：列挙」から構成される。上述したように、コンテンツ・タイプの一例は、キー値ペアである。そのような場合、ステートメント６８４は、カテゴリ指向パーサに、リクエスト・メッセージ４００内のキーの値をシステム変数に割り当てるように命令する。キーは、ステートメント６８７「キー・ツー・マッチ：リテラル」で識別され、システム変数は、ステートメント６８９で識別される。これに続いて、カテゴリ指向パーサは、収集されたメタデータ及びコンテンツを、検査のためにＤＬＰプロセッサに送信する。

或るカテゴリのサービスを実施するクラウドベースのサービスにアクセスするユーザは、サービスのカテゴリに関連する様々なアクティビティを実行する。カテゴリ指向パーサは、実行されたアクティビティに関連するメタデータを収集し、それをメタデータとしてＤＬＰプロセッサに送信する。一実施態様では、アクティビティ・データ（メタデータ及びコンテンツを含む）をＤＬＰプロセッサに送信するトリガが呼び出される。メタデータは、ＤＬＰプロセッサがコンテンツを検査し、セキュリティ・ポリシーを適用するのに役立つデータを含む。例えば、トリガは、データがリクエスト・メッセージ（ＨＴＴＰ・ＰＯＳＴ）またはレスポンス・メッセージ（ＨＴＴＰ・ＧＥＴ）から収集されたことをＤＬＰプロセッサに通知する。実行されるアクティビティに応じて、カテゴリ指向パーサは、ＤＬＰプロセッサが検査するための「オブジェクト」を識別する。例えば、アクティビティが「ログイン」である場合、オブジェクトは「ユーザ名」であり、アクティビティがアップロードまたはダウンロードである場合、オブジェクトは「ファイル」である。
［“ファイルのアップロード”するアクティビティ］

「個人ページ及びブログ」カテゴリ指向パーサを続けて、ここで、企業ユーザが、ＷｏｒｄＰｒｅｓｓ（商標）ＡＰＩを使用して、サービスの「個人ページ及びブログ」カテゴリに属するプロバイダ「ＷｏｒｄＰｒｅｓｓ．ｃｏｍ」にファイルをアップロードしようと試みることを考える。インライン・プロキシ１６１は、リクエスト・メッセージ（ＨＴＴＰ・ＰＯＳＴ）を受信し、プロキシは、図５Ａ及び５Ｂで上述したのと同じプロセスに従い、リクエストＵＲＬからサービスのカテゴリを識別し、カテゴリ指向パーサを選択する。「個人ページ及びブログ」カテゴリ指向パーサが選択され、（図６Ａで説明したように）リクエスト・メッセージ・ヘッダを構文解析して、実行されたアクティビティを決定することを考える。この目的のために、（図６Ａに示されるような）ヘッダ・マッチ・セグメント内の１対のマッチ・ステートメント（識別ルールとも呼ばれる）が適用される。マッチ・ステートメント内の値は、リクエスト・メッセージのリクエスト・ヘッダ部分に含まれるリクエスト・パラメータに対してテストされる。

第１のマッチ・ステートメントは、図６Ａのマッチ・ステートメント６８２と同様であり、リクエスト・メッセージがＨＴＴＰ・ＰＯＳＴ方法を使用して送信されていることを識別する。第２のマッチ・ステートメントは、リクエスト・メッセージが「マルチパート／フォーム・データ」の形式の添付ファイルを含むことを識別する。アクティビティを識別するためにヘッダ・マッチ・セグメントに識別ルールを適用した後、カテゴリ指向マッチルールを適用して、アクティビティのオブジェクトに関連するメタデータを収集する。一実施態様では、添付ファイルはＭＩＭＥエンコードされる。カテゴリ指向マッチルールは、オブジェクトのタイプ（この実施例では「ファイル」）及びオブジェクトのサイズ（この実施例ではファイルのサイズ）を含む関連するメタデータを収集する。メッセージのメタデータ及びコンテンツは、その分析に集中するために、ＤＬＰプロセッサに転送される。カテゴリ指向パーサは、サービスのカテゴリに属する既知のクラウドベースのサービスのアクティビティに対応するアクティビティ識別マッチルール及びカテゴリ指向マッチルールを含む。
［汎用パーサ］

図３Ｄに関連して上述したように、インライン・プロキシが、未知のクラウドベースのサービスが、サービス固有のパーサもカテゴリ指向パーサも利用可能でないＡＰＩを介してアクセスされていると判定した場合、インライン・プロキシは、アクセスされているＡＰＩに対して汎用パーサ（ユニバーサルコネクタとも呼ばれる）を選択し、適用する。ユーザが、クラウドベースのサービスｇｌｕｕ．ｏｒｇにリクエスト・メッセージ「ｈｔｔｐｓ：／／ｓｕｐｐｏｒｔ．ｇｌｕｕ．ｏｒｇ／ｉｎｓｔａｌｌａｔｉｏｎ／７１３９／ｓｅｒｖｉｃｅ−ｉｓｓｕｅｓ／」を送信しようとする場合を考える。図３Ｄで上述したように、インライン・プロキシは、ユーザが未知のクラウドベースのサービス「ｇｌｕｕ．ｏｒｇ」にアクセスしていることを判定する。インライン・プロキシ１６１は、未知のクラウドベースのサービスのＡＰＩに汎用パーサを適用する。汎用パーサは、未知のクラウドベースのサービスのＡＰＩを使用して実行されるアクティビティを知らないので、汎用パーサは、ユーザによって実行されるアクティビティに従って編成されたマッチルールを含まない。

汎用パーサは、カテゴリ指向パーサによって対処される少なくとも２つのカテゴリのサービスを実施するために、少なくとも１つのデフォルト・マッチルールを含む。例えば、汎用パーサは、ＨＴＴＰ・ＰＯＳＴリクエスト・メッセージでサーバにデータを送信する全てのアクティビティに適用されるデフォルト・マッチルール「ファイルのアップロード」を含む。既知のクラウドベースのサービスの場合、これらのアクティビティは、少なくとも２つのカテゴリのサービスにおいてクラウドベースのサービスによって提供される。例えば、サービスの「ウェブメール」カテゴリからの「ｅメールを送信する」アクティビティと、「個人ページ及びブログ」カテゴリからの「コメントを投稿する」アクティビティとの両方は、リクエストが汎用パーサによって処理されるとき、「ファイルのアップロード」アクティビティと見なされる。従って、汎用パーサは、カテゴリ指向パーサと比較して、より少ないメタデータを収集する。複数のタイプのアクティビティが、デフォルト・マッチルールを使用して汎用パーサによって処理されるので、汎用パーサは、メタデータが汎用パーサによって収集されるというラベルを含む追加の変数をＤＬＰプロセッサに送信する。この追加のメタデータは、ＤＬＰプロセッサに、その許容範囲を緩和するために随意的に使用できる情報をＤＬＰプロセッサに与えることによって、ＤＬＰプロセッサが誤検知を回避するのを助ける。アップロードに対して行動をとるための許容範囲の緩和は、許容範囲が緩和されたサイトを調査するための報告を伴うことができる。例えば、ブログ・ポストにコメントを投稿しているが、ファイルのアップロードのアクティビティとしてＤＬＰプロセッサに送信されるリクエスト・メッセージは、セキュリティ・ポリシーが、ファイルのアップロードが許可されないと提示している場合、ＤＬＰプロセッサによってブロックすることができる。しかし、これは、誤検知であり、リクエスト・メッセージが汎用パーサによって構文解析されることをＤＬＰプロセッサに通知するための追加のメタデータを含むことは、ポリシーを実施するときに、ＤＬＰプロセッサがこの情報を含むのを助けることができる。
［コンピュータ・システム］

図７は、サービス固有のパーサが利用可能でないクラウドベースのコンテンツ・ストレージやホスティング・サービス（集合的に「クラウドベースのサービス」）に、データ損失防止（ＤＬＰ）を適用するための図１のインライン・プロキシ１６１を実施するために使用できるコンピュータ・システム７００の簡略ブロック図である。コンピュータ・システム７００は、バス・サブシステム７５５を介して幾つかの周辺装置と通信する少なくとも１つの中央演算処理装置（ＣＰＵ）７７２を含む。これらの周辺装置は、例えば、メモリ装置及びファイル・ストレージ・サブシステム７３６を含むストレージ・サブシステム７１０、ユーザ・インターフェイス入力装置７３８、ユーザ・インターフェイス出力装置７７６、及びネットワーク・インターフェイス・サブシステム７７４を含むことができる。入力及び出力装置は、コンピュータ・システム７００とのユーザ・インタラクションを可能にする。ネットワーク・インターフェイス・サブシステム７７４は、他のコンピュータ・システム内の対応するインターフェイス装置へのインターフェイスを含む、外部ネットワークへのインターフェイスを提供する。

一実施態様では、図１のインライン・プロキシ１６１は、ストレージ・サブシステム７１０及びユーザ・インターフェイス入力装置７３８に通信可能にリンクされる。

ユーザ・インターフェイス入力装置７３８は、キーボード、マウス，トラックボール，タッチパッド，またはグラフィックス・タブレット等のポインティングデバイス、スキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム及びマイクロフォン等のオーディオ入力装置、並びに他のタイプの入力装置を含むことができる。一般に、「入力装置」という用語の使用は、コンピュータ・システム７００に情報を入力するための全ての可能なタイプの装置及び方法を含むことが意図される。

ユーザ・インターフェイス出力装置７７６は、ディスプレイ・サブシステム、プリンタ、ファックスマシン、またはオーディオ出力装置等の非視覚ディスプレイを含むことができる。ディスプレイ・サブシステムは、ＬＥＤディスプレイ、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）等のフラットパネル装置、投影装置、または可視画像を生成するための他の何らかのメカニズムを含むことができる。ディスプレイ・サブシステムはまた、オーディオ出力装置等の非視覚ディスプレイを提供することができる。一般に、「出力装置」という用語の使用は、コンピュータ・システム７００からユーザに、または別の機械もしくはコンピュータ・システムに情報を出力するための全ての可能なタイプの装置及び方法を含むことが意図される。

ストレージ・サブシステム７１０は、本明細書で説明するモジュール及び方法の一部または全部の機能を提供するプログラミング及びデータ構造を記憶する。サブシステム７７８は、グラフィックス処理装置（ＧＰＵ）またはプログラマブル・ゲートアレイ（ＦＰＧＡ）とすることができる。

ストレージ・サブシステム７１０で使用されるメモリ・サブシステム７２２は、プログラム実行中に命令及びデータを格納するためのメイン・ランダムアクセス・メモリ（ＲＡＭ）７３２と、固定命令が格納される読み出し専用メモリ（ＲＯＭ）７３４とを含む、幾つかのメモリを含むことができる。ファイル・ストレージ・サブシステム７３６は、プログラム及びデータファイルのための永続的ストレージを提供することができ、ハードディスク・ドライブ、関連するリムーバブル・メディアと共にフロッピー（商標）ディスク・ドライブ、ＣＤ−ＲＯＭドライブ、光ドライブ、またはリムーバブル・メディア・カートリッジを含むことができる。特定の実施態様の機能を実施するモジュールは、ストレージ・サブシステム７１０内のファイル・ストレージ・サブシステム７３６によって、またはプロセッサによってアクセス可能な他のマシン内に格納することができる。

バス・サブシステム７５５は、コンピュータ・システム７００の様々なコンポーネント及びサブシステムに、意図されたように互いに通信させるためのメカニズムを提供する。バス・サブシステム７５５は、単一のバスとして概略的に示されているが、バス・サブシステムの他に採り得る実施態様は、多数のバスを使用することができる。

コンピュータ・システム７００は、パーソナル・コンピュータ、ポータブル・コンピュータ、ワークステーション、コンピュータ端末、ネットワーク・コンピュータ、テレビ、サーバ、メインフレーム、広範囲に分散した一連の疎結合コンピュータ、または任意の他のデータ処理システムもしくはユーザ・デバイスを含む様々なタイプのものとすることができる。コンピュータ及びネットワークの絶えず変化する性質のために、図７に示されるコンピュータ・システム７００の説明は、本発明の好ましい実施形態を例示する目的のための特定の実施例としてのみ意図される。コンピュータ・システム７００の多くの他の構成は、図７に示されたコンピュータ・システムよりも多いまたは少ないコンポーネントを有することが可能である。
［特定の実施態様］

本発明は、サービス固有のパーサが利用できないクラウドベースのコンテンツ・サービスにデータ損失防止（ＤＬＰと略記）を適用することに関する。

開示される技術は、システム、方法、デバイス、製品、コンピュータ可読媒体、または製品として実施することができる。実施態様の１以上の特徴は、基本実施態様と組み合わせることができる。相互に排他的でない実施態様は、組み合わせ可能であると教示される。実施態様の１以上の特徴は、他の実施態様と組み合わせることができる。本開示は、これらのオプションをユーザに定期的に想起させる。これらのオプションを繰り返す記述の幾つかの実施態様からの省略は、これまでのセクションで教示された組み合わせを限定するものとして解釈されるべきではない。これらの記載は、以下の実施態様のそれぞれに参考として援用される。

開示された技術の第１のシステムの実施態様は、メモリに接続された１以上のプロセッサを含む。メモリには、データ損失防止（ＤＬＰと略記）をクラウドベースのコンテンツ・サービスに適用するためのコンピュータ命令がロードされている。システムは、既知のクラウドベースのサービスが、アプリケーション・プログラミング・インターフェース（ＡＰＩと略記）を介してアクセスされていることを判定する。システムは、アクセスされているＡＰＩに対してサービス固有のパーサが利用可能でないことを判定する。システムは、アクセスされているＡＰＩに対してサービスのカテゴリを判定する。システムは、判定されたカテゴリに基づいてカテゴリ指向パーサを選択する。カテゴリ指向パーサは、そのカテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される複数のカテゴリ指向マッチルールを含む。システムは、カテゴリ指向パーサを使用して、ＡＰＩを介して伝達されるコンテンツを構文解析して、メタデータを収集し、カテゴリ指向マッチルールを使用して、収集されたメタデータを変数に割り当てる。システムは、変数に割り当てられた収集されたメタデータを、ＡＰＩを介して伝達されているコンテンツにデータ損失防止を適用するためのＤＬＰプロセッサに送信する。

このシステムの実施態様及び開示された他のシステムは、以下の特徴の１以上を任意に含む。システムはまた、開示された方法に関連して説明された特徴を含むことができる。簡潔にするために、システムの特徴の代替的な組み合わせは、個々に列挙されない。システム、方法、及び製品に適用可能な特徴は、基本特徴の法定クラスセット毎に繰り返されない。読者は、このセクションで識別された特徴が、他の法定クラスの基本特徴とどのように容易に組み合わせることができるかを理解するであろう。

システムは、選択アクションにおいてアクセスされているＡＰＩのために選択すべきカテゴリ指向パーサが利用可能でないかを判定し、次いで、汎用パーサを選択する。汎用パーサは、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される少なくとも１つのデフォルト・マッチルールを含む。デフォルト・マッチルールは、複数のカテゴリのサービスに関連付けられる。システムは、選択された汎用パーサのマッチルールを使用して、ＡＰＩを介して伝達されるコンテンツを構文解析し、収集されたメタデータを変数に割り当てる。

システムは、ＡＰＩにアクセスするために使用されるユニフォーム・リソース・ロケータ（ＵＲＬと略記）内のドメイン名に基づいて、カテゴリ指向パーサを使用することを決定する。

複数のマッチルールは、カテゴリ指向パーサによって対処されるカテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される少なくとも１０のマッチルールを含む。複数のマッチルールは、それぞれがカテゴリ指向パーサによって対処されたカテゴリのサービスを実施するクラウドベースのコンテンツ・サービスの少なくとも２５のプロバイダによって使用されるシンタックスから導出される。

クラウドベースのサービスは、サービスの別個のカテゴリにおける少なくとも５つのカテゴリ指向パーサによって供給される。サービスの少なくとも５つのカテゴリによって供給されるサービスの別個のカテゴリは、サービス固有のパーサを有さない個人ページ及びブログを含む。サービスの少なくとも５つのカテゴリにおけるサービスの他のカテゴリは、サービス固有のパーサを有さないニュース・ウェブサイト、サービス固有のパーサを有さないクラウドベースのストレージ・サービス、サービス固有のパーサを有さないソーシャル・メディア・サービス、及びサービス固有のパーサを有さないウェブメール・サービスを含む。

ＡＰＩを介して伝達されるコンテンツからメタデータを収集することは、クライアントから、既知のクラウドベースのサービスをホストするサーバへのリクエスト・メッセージを処理することを更に含む。リクエスト・メッセージに続いて、クライアントからＤＬＰ検査の対象となるサーバへのコンテンツのアップロードが行われる。ＡＰＩを介して伝達されるコンテンツからメタデータを収集することは、リクエスト・メッセージにレスポンスする既知のクラウドベースのサービスをホストするサーバからのレスポンスを処理することを更に含む。レスポンス・メッセージに続いて、ＤＬＰ検査の対象となるサーバから、コンテンツがダウンロードされる。

ＡＰＩを介して伝達されるコンテンツからのメタデータの収集は、クライアントから既知のクラウドベースのサービスをホストするサーバへの複数のリクエスト・メッセージの処理からのメタデータの蓄積を更に含む。

アクセスされるＡＰＩへのカテゴリ指向パーサの適用は、以下を含む。システムは、ＡＰＩにアクセスするために使用されるユニフォーム・リソース・ロケータ（ＵＲＬ）を構文解析することによって、既知のクラウドベースのサービスのドメイン名を識別する。これに続いて、システムは、ドメイン名を、利用可能なサービス固有のパーサのドメイン名のエントリリストと照合することによって、アクセスされているＡＰＩに利用可能なサービス固有のパーサがないと判定する。システムは、カテゴリ指向パーサのドメイン名のエントリリスト内のドメイン名のマッチを見つける。

一実施態様において、システムは、構文解析されたＵＲＬリクエストから識別されたリソース記述を使用することによって、カテゴリ指向パーサの一部を起動することを含む。システムは、カテゴリ指向マッチルールを使用して、ＡＰＩを介して伝達されるコンテンツからメタデータを収集する前に、ＵＲＬ内のパラメータを識別ルールにマッチさせる。これに続いて、システムは、カテゴリ指向マッチルールを使用して、収集されたメタデータを変数に割り当てる。

複数のカテゴリ指向マッチルールにおけるマッチルールは、コンテンツ・ラベル（鍵とも呼ばれる）を識別する左側指定子と、複数のシンタックスからの特定のシンタックスにおけるコンテンツ・ラベルにマッチするための目標ラベルの右側指定子とを含む。或るカテゴリのサービスを実施する、既知のクラウドベースのサービスの多数の既知のプロバイダによって使用される複数のシンタックス。システムは、アサイン・ステートメントを使用することによって、成功裏に解決されたマッチルールの結果を保持する。成功裏に解決されたマッチルールに相関名を持つアサイン・ステートメントを使用すると、保持されている値がシステム変数に割り当てられる。

他の実施態様は、上述のシステムの機能を実行するためにプロセッサによって実行可能な命令を格納する非一時的なコンピュータ可読記憶媒体を含むことができる。更に別の実施態様は、上述したシステムの機能を実行する方法を含むことができる。

開示された技術の第１の方法の実施態様は、データ損失防止（ＤＬＰと略記）をクラウドベースのコンテンツ・サービスに適用することを含む。方法は、既知のクラウドベースのサービスが、アプリケーション・プログラミング・インターフェース（ＡＰＩと略記）を介してアクセスされていることを判定することを含む。方法は、アクセスされているＡＰＩに対してサービス固有のパーサが利用可能でないことを判定することを含む。方法は、アクセスされているＡＰＩに対してサービスのカテゴリを判定することを含む。方法は、判定されたカテゴリに基づいてカテゴリ指向パーサを選択することを含む。カテゴリ指向パーサは、そのカテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される複数のカテゴリ指向マッチルールを含む。方法は、カテゴリ指向パーサを使用して、ＡＰＩを介して伝達されるコンテンツを構文解析して、メタデータを収集し、カテゴリ指向マッチルールを使用して、収集されたメタデータを変数に割り当てることを含む。最後に、方法は、変数に割り当てられた収集されたメタデータを、ＡＰＩを介して伝達されているコンテンツにデータ損失防止を適用するためのＤＬＰプロセッサに送信することを含む。

第１のシステムの実施態様について、この特定の実施態様のセクションで議論された特徴のそれぞれは、この方法の実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

他の実施態様は、上述の第１の方法を実行するために、プロセッサによって実行される命令を格納する非一時的なコンピュータ可読記憶媒体を含むことができる。更に別の実施態様は、上述の第１の方法を実行するために、メモリと、そのメモリ内に格納された命令を実行するように動作可能な１以上のプロセッサを含むシステムを含むことができる。

開示された技術のコンピュータ可読媒体（ＣＲＭ）の実施態様は、プロセッサ上で実行されることで上述した方法を実施するコンピュータ・プログラム命令を記憶した非一時的なコンピュータ可読記憶媒体を含む。

第１のシステムの実施態様について、この特定の実施態様のセクションで議論された特徴のそれぞれは、このＣＲＭの実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

開示された技術の第２のシステムの実施態様は、メモリに接続された１以上のプロセッサを含む。メモリには、データ損失防止（ＤＬＰと略記）をクラウドベースのコンテンツ・サービスに適用するためのコンピュータ命令がロードされている。システムは、未知のクラウドベースのサービスが、サービス固有のパーサ及びカテゴリ指向パーサが利用可能でないアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアクセスされていることを判定する。システムは、未知のクラウドベースのサービスがアクセスされていることの判定に基づいて、汎用パーサを選択する。汎用パーサは、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される、少なくとも１つのデフォルト・マッチルールを含む。デフォルト・マッチルールは、カテゴリ指向パーサによって対処される少なくとも２つのカテゴリのサービスに関連付けられる。システムは、選択された汎用パーサを使用して、ＡＰＩを介して伝達されている前記コンテンツを構文解析し、メタデータを収集する。システムは、収集されたメタデータを変数に割り当てる。システムは、変数に割り当てられたメタデータと、メタデータが汎用パーサによって収集されたことを示すデータをＤＬＰプロセッサに送信する。ＤＬＰプロセッサは、ＡＰＩを介して伝達されているコンテンツにデータ損失防止を適用する。

第２のシステムの実施態様と開示された他のシステムは、上述の第１のシステムの実施態様と関連して議論された特徴の内の１つ以上を任意に含み得る。システムはまた、開示された方法に関連する特徴を含み得る。説明の簡潔のために、本出願で開示される特徴の別の組み合わせは個別に列挙されない。システム、方法、そして製品に適用可能な特徴は、基本特徴の各法定クラスセットに対して繰り返されない。読者は、本セクションで特定された特徴が、他の法定クラスにおける基本特徴とどのように容易に組み合わせることができるかを理解するであろう。

開示された技術の第２の方法の実施態様は、データ損失防止（ＤＬＰと略記）をクラウドベースのコンテンツ・サービスに適用することを含む。方法は、未知のクラウドベースのサービスが、サービス固有のパーサ及びカテゴリ指向パーサが利用可能でないアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアクセスされていることを判定することを含む。方法は、未知のクラウドベースのサービスがアクセスされていることの判定に基づいて、汎用パーサを選択することを含む。汎用パーサは、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される、少なくとも１つのデフォルト・マッチルールを含む。デフォルト・マッチルールは、カテゴリ指向パーサによって対処される少なくとも２つのカテゴリのサービスに関連付けられる。方法は、選択された汎用パーサを使用して、ＡＰＩを介して伝達されている前記コンテンツを構文解析し、メタデータを収集することを含む。方法は、収集されたメタデータを変数に割り当てることを含む。最後に、方法は、変数に割り当てられたメタデータと、メタデータが汎用パーサによって収集されたことを示すデータをＤＬＰプロセッサに送信することを含む。ＤＬＰプロセッサは、ＡＰＩを介して伝達されているコンテンツにデータ損失防止を適用する。

第２のシステムの実施態様について、この特定の実施態様のセクションで議論された特徴のそれぞれは、この方法の実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

他の実施態様は、上述の第２の方法を実行するために、プロセッサによって実行される命令を格納する非一時的なコンピュータ可読記憶媒体を含むことができる。更に別の実施態様は、上述の第２の方法を実行するために、メモリと、そのメモリ内に格納された命令を実行するように動作可能な１以上のプロセッサを含むシステムを含むことができる。

開示された技術のコンピュータ可読媒体（ＣＲＭ）の実施態様は、プロセッサ上で実行されることで上述した方法を実施するコンピュータ・プログラム命令を記憶した非一時的なコンピュータ可読記憶媒体を含む。

第２のシステムの実施態様について、この特定の実施態様のセクションで議論された特徴のそれぞれは、このＣＲＭの実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

開示された技術の第３のシステムの実施態様は、メモリに接続された１以上のプロセッサを含む。メモリには、データ損失防止（ＤＬＰと略記）をクラウドベースのコンテンツ・サービスに適用するためのコンピュータ命令がロードされている。システムは、クラウドベースのサービスにアクセスするアプリケーション・プログラミング・インターフェース（ＡＰＩ）を識別するデータを受信する。システムは、ＡＰＩを識別する前記データに基づいて、アクセスされているＡＰＩに対してサービス固有のパーサが利用可能でないことを判定する。

アクセスされているＡＰＩに対してカテゴリ指向パーサが利用可能であると判定された場合、システムは、以下を実行する。システムは、アクセスされているＡＰＩに対してサービスのカテゴリを判定し、システムは、判定されたカテゴリに基づいてカテゴリ指向パーサを選択する。カテゴリ指向パーサは、或るカテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される複数のカテゴリ指向マッチルールを含む。

アクセスされているＡＰＩに対してカテゴリ指向パーサが利用可能でないと判定された場合、システムは汎用パーサを選択する。汎用パーサは、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される、少なくとも１つのデフォルト・マッチルールを含む。デフォルト・マッチルールは、複数のカテゴリのサービスに関連付けられる。

システムは、選択されたカテゴリ指向パーサまたは選択された汎用パーサのマッチルールを使用して、ＡＰＩを介して伝達されているコンテンツを構文解析して、メタデータを収集する。システムは、カテゴリ指向マッチルールを使用して、選択されたカテゴリ指向パーサを介して収集されたメタデータを変数に割り当てる。システムは、デフォルト・マッチルールを使用して、選択された汎用パーサを介して収集されたメタデータを変数に割り当てる。最後に、システムは、変数に割り当てられた収集されたメタデータを、ＡＰＩを介して伝達されているコンテンツにデータ損失防止を適用するためのＤＬＰプロセッサに送信する。

このシステムの実施態様及び開示された他のシステムは、以下の特徴の１以上を任意に含む。システムはまた、開示された方法に関連して説明された特徴を含むことができる。簡潔にするために、システムの特徴の代替的な組み合わせは、個々に列挙されない。システム、方法、及び製品に適用可能な特徴は、基本特徴の法定クラスセット毎に繰り返されない。読者は、このセクションで識別された特徴が、他の法定クラスの基本特徴とどのように容易に組み合わせることができるかを理解するであろう。

システムは、アクセスされているＡＰＩに対してサービス固有のパーサが利用可能でないと判定した場合、メタデータが汎用パーサによって収集されたことを示すデータを送信することを更に含み、収集されたメタデータを送信する。

システムは、アクセスされているＡＰＩに対してカテゴリ指向パーサが利用可能かを判定する。

システムは、アクセスされているＡＰＩに対してカテゴリ指向パーサが利用可能かを、ＡＰＩにアクセスするために使用されるユニフォーム・リソース・ロケータ（ＵＲＬと略記）内のドメイン名に基づいて判定する。

複数のカテゴリ指向マッチルールは、カテゴリ指向パーサによって対処されるカテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される少なくとも１０のマッチルールを含む。複数のカテゴリ指向マッチルールは、それぞれがカテゴリ指向パーサによって対処されるカテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスの少なくとも２５のプロバイダによって使用されるシンタックスから導出される。

クラウドベースのサービスは、サービスの別個のカテゴリにおける少なくとも５つのカテゴリ指向パーサによって供給される。サービスの少なくとも５つのカテゴリによって供給されるサービスの別個のカテゴリは、サービス固有のパーサを有さない個人ページ及びブログを含む。サービスの少なくとも５つのカテゴリにおけるサービスの他のカテゴリは、サービス固有のパーサを有さないニュース・ウェブサイト、サービス固有のパーサを有さないクラウドベースのストレージ・サービス、サービス固有のパーサを有さないソーシャル・メディア・サービス、及びサービス固有のパーサを有さないウェブメール・サービスを含む。

ＡＰＩを介して伝達されるコンテンツからメタデータを収集することは、クライアントから、既知のクラウドベースのサービスをホストするサーバへのリクエスト・メッセージを処理することを更に含む。リクエスト・メッセージに続いて、クライアントからＤＬＰ検査の対象となるサーバへのコンテンツのアップロードが行われる。ＡＰＩを介して伝達されるコンテンツからメタデータを収集することは、リクエスト・メッセージにレスポンスする既知のクラウドベースのサービスをホストするサーバからのレスポンスを処理することを更に含む。レスポンス・メッセージに続いて、ＤＬＰ検査の対象となるサーバから、コンテンツがダウンロードされる。

第３のシステムの実施態様と開示された他のシステムは、上述の第１のシステムの実施態様と関連して議論された特徴の内の１つ以上を任意に含み得る。システムはまた、開示された方法に関連する特徴を含み得る。説明の簡潔のために、本出願で開示される特徴の別の組み合わせは個別に列挙されない。システム、方法、そして製品に適用可能な特徴は、基本特徴の各法定クラスセットに対して繰り返されない。読者は、本セクションで特定された特徴が、他の法定クラスにおける基本特徴とどのように容易に組み合わせることができるかを理解するであろう。

開示された技術の第３の方法の実施態様は、データ損失防止（ＤＬＰと略記）をクラウドベースのコンテンツ・サービスに適用することを含む。方法は、クラウドベースのサービスにアクセスするアプリケーション・プログラミング・インターフェース（ＡＰＩ）を識別するデータを受信することを含む。方法は、ＡＰＩを識別するデータに基づいて、アクセスされているＡＰＩに対してサービス固有のパーサが利用可能でないことを判定することを含む。

アクセスされているＡＰＩに対してカテゴリ指向パーサが利用可能であると判定された場合、方法は、以下を実行することを含む。アクセスされているＡＰＩに対してサービスのカテゴリを判定し、判定されたカテゴリに基づいてカテゴリ指向パーサを選択すること。カテゴリ指向パーサは、或るカテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される複数のカテゴリ指向マッチルールを含む。

アクセスされているＡＰＩに対してカテゴリ指向パーサが利用可能でないと判定された場合、方法は汎用パーサを選択することを含む。汎用パーサは、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される、少なくとも１つのデフォルト・マッチルールを含む。デフォルト・マッチルールは、複数のカテゴリのサービスに関連付けられる。

方法は、選択されたカテゴリ指向パーサまたは選択された汎用パーサのマッチルールを使用して、ＡＰＩを介して伝達されているコンテンツを構文解析して、メタデータを収集することを含む。方法は、カテゴリ指向マッチルールを使用して、選択されたカテゴリ指向パーサを介して収集されたメタデータを変数に割り当てることを含む。方法は、デフォルト・マッチルールを使用して、選択された汎用パーサを介して収集されたメタデータを変数に割り当てることを含む。最後に、方法は、変数に割り当てられた収集されたメタデータを、ＡＰＩを介して伝達されているコンテンツにデータ損失防止を適用するためのＤＬＰプロセッサに送信することを含む。

第３のシステムの実施態様について、この特定の実施態様のセクションで議論された特徴のそれぞれは、この方法の実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

他の実施態様は、上述の第３の方法を実行するために、プロセッサによって実行される命令を格納する非一時的なコンピュータ可読記憶媒体を含むことができる。更に別の実施態様は、上述の第３の方法を実行するために、メモリと、そのメモリ内に格納された命令を実行するように動作可能な１以上のプロセッサを含むシステムを含むことができる。

開示された技術のコンピュータ可読媒体（ＣＲＭ）の実施態様は、プロセッサ上で実行されることで上述した方法を実施するコンピュータ・プログラム命令を記憶した非一時的なコンピュータ可読記憶媒体を含む。

第３のシステムの実施態様について、この特定の実施態様のセクションで議論された特徴のそれぞれは、このＣＲＭの実施態様に対して等しく適用される。上述したように、全てのシステムの特徴は、ここでは繰り返されず、参照により繰り返されると見なされるべきである。

Claims (41)

1. データ損失防止（ＤＬＰ）をクラウドベースのコンテンツ・サービスに適用するためのコンピュータ命令がロードされているメモリに接続された１以上のプロセッサを含むシステムであって、
   前記命令は、前記プロセッサ上で実行されると、
   既知のクラウドベースのサービスが、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアクセスされていることを判定すること、
   アクセスされている前記ＡＰＩに対してサービス固有のパーサが利用可能でないことを判定すること、
   アクセスされている前記ＡＰＩに対してサービスのカテゴリを判定すること、
   判定された前記カテゴリに基づいてカテゴリ指向パーサを選択すること、
   前記カテゴリ指向パーサは、前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される複数のカテゴリ指向マッチルールを含み、
   前記カテゴリ指向パーサを使用して、前記ＡＰＩを介して伝達されるコンテンツを構文解析して、メタデータを収集し、前記カテゴリ指向マッチルールを使用して、収集されたメタデータを変数に割り当てること、及び、
   前記変数に割り当てられた前記収集されたメタデータを、前記ＡＰＩを介して伝達されている前記コンテンツにデータ損失防止を適用するためのＤＬＰプロセッサに送信すること、を含むアクションを実施するシステム。
2. 前記選択するアクションにおいて、アクセスされている前記ＡＰＩのために選択すべきカテゴリ指向パーサが利用可能でない場合、
   汎用パーサを選択すること、
   前記汎用パーサは、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される、少なくとも１つのデフォルト・マッチルールを含み、前記デフォルト・マッチルールは、複数のカテゴリのサービスに関連付けられ、
   前記選択された汎用パーサの前記マッチルールを使用して、前記ＡＰＩを介して伝達されている前記コンテンツを構文解析し、前記収集されたメタデータを変数に割り当てること、を含むアクションを更に実施する請求項１に記載のシステム。
3. 前記カテゴリ指向パーサを使用することの決定が、前記ＡＰＩにアクセスするために使用されるユニフォーム・リソース・ロケータ（ＵＲＬと略記）内のドメイン名に基づいて行われる請求項１または２に記載のシステム。
4. 前記複数のマッチルールは、前記カテゴリ指向パーサによって対処される前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスの前記プロバイダによって使用される前記複数のシンタックスから導出される少なくとも１０のマッチルールを含む請求項１〜３の何れか１項に記載のシステム。
5. 前記複数のマッチルールは、それぞれが前記カテゴリ指向パーサによって対処される前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスの少なくとも２５のプロバイダによって使用されるシンタックスから導出される請求項１〜４の何れか１項に記載のシステム。
6. 前記クラウドベースのサービスは、サービスの別個のカテゴリにおける少なくとも５つのカテゴリ指向パーサによって供給される請求項１〜５の何れか１項に記載のシステム。
7. 前記少なくとも５つのカテゴリ指向パーサによって供給される前記サービスの別個のカテゴリは、少なくとも、個人ページ及びブログ、ニュース・ウェブサイト、クラウドベースのストレージ・サービス、ウェブメール、及び、ソーシャル・メディア・サービスを含む請求項６に記載のシステム。
8. 前記ＡＰＩを介して伝達されるコンテンツからメタデータを収集することは、クライアントから、前記既知のクラウドベースのサービスをホストするサーバへのリクエスト・メッセージを処理することを更に含む請求項１〜７の何れか１項に記載のシステム。
9. 前記リクエスト・メッセージに続いて、前記クライアントからＤＬＰ検査の対象となる前記サーバへの前記コンテンツの前記ＡＰＩを介したアップロードが行われる請求項８に記載のシステム。
10. データ損失防止（ＤＬＰ）をクラウドベースのコンテンツ・サービスに適用するためのコンピュータ命令がロードされているメモリに接続された１以上のプロセッサを含むシステムであって、
    前記命令は、前記プロセッサ上で実行されると、
    未知のクラウドベースのサービスが、サービス固有のパーサ及びカテゴリ指向パーサが利用可能でないアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアクセスされていることを判定すること、
    未知のクラウドベースのサービスがアクセスされていることの判定に基づいて、汎用パーサを選択すること、
    前記汎用パーサは、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される、少なくとも１つのデフォルト・マッチルールを含み、前記デフォルト・マッチルールは、カテゴリ指向パーサによって対処される少なくとも２つのカテゴリのサービスに関連付けられ、
    前記選択された汎用パーサを使用して、前記ＡＰＩを介して伝達されている前記コンテンツを構文解析し、メタデータを収集し、前記収集されたメタデータを変数に割り当てること、及び、
    前記変数に割り当てられ、前記メタデータが前記汎用パーサによって収集されたことを示すデータを伴う前記収集されたメタデータを、前記ＡＰＩを介して伝達されている前記コンテンツにデータ損失防止を適用するためのＤＬＰプロセッサに送信すること、を含むアクションを実施するシステム。
11. データ損失防止（ＤＬＰ）をクラウドベースのコンテンツ・サービスに適用する方法であって、
    既知のクラウドベースのサービスが、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアクセスされていることを判定すること、
    アクセスされている前記ＡＰＩに対してサービス固有のパーサが利用可能でないことを判定すること、
    アクセスされている前記ＡＰＩに対してサービスのカテゴリを判定すること、
    判定された前記カテゴリに基づいてカテゴリ指向パーサを選択すること、
    前記カテゴリ指向パーサは、前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される複数のカテゴリ指向マッチルールを含み、
    前記カテゴリ指向パーサを使用して、前記ＡＰＩを介して伝達されるコンテンツを構文解析して、メタデータを収集し、前記カテゴリ指向マッチルールを使用して、収集されたメタデータを変数に割り当てること、及び、
    前記変数に割り当てられた前記収集されたメタデータを、前記ＡＰＩを介して伝達されている前記コンテンツにデータ損失防止を適用するためのＤＬＰプロセッサに送信すること、を含む方法。
12. 前記カテゴリ指向パーサを使用することの決定が、前記ＡＰＩにアクセスするために使用されるユニフォーム・リソース・ロケータ（ＵＲＬと略記）内のドメイン名に基づいて行われる請求項１１に記載の方法。
13. 前記複数のマッチルールは、前記カテゴリ指向パーサによって対処される前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスの前記プロバイダによって使用される前記複数のシンタックスから導出される少なくとも１０のマッチルールを含む請求項１１または１２に記載の方法。
14. 前記複数のマッチルールは、それぞれが前記カテゴリ指向パーサによって対処される前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスの少なくとも２５のプロバイダによって使用されるシンタックスから導出される請求項１１〜１３の何れか１項に記載の方法。
15. 前記クラウドベースのサービスは、サービスの別個のカテゴリにおける少なくとも５つのカテゴリ指向パーサによって供給される請求項１１〜１４の何れか１項に記載の方法。
16. 前記少なくとも５つのカテゴリ指向パーサによって供給される前記サービスの別個のカテゴリは、少なくとも、個人ページ及びブログ、ニュース・ウェブサイト、クラウドベースのストレージ・サービス、ウェブメール、及び、ソーシャル・メディア・サービスを含む請求項１５に記載の方法。
17. 前記ＡＰＩを介して伝達されるコンテンツからメタデータを収集することは、クライアントから、前記既知のクラウドベースのサービスをホストするサーバへのリクエスト・メッセージを処理することを更に含む請求項１１〜１６の何れか１項に記載の方法。
18. 前記リクエスト・メッセージに続いて、前記クライアントからＤＬＰ検査の対象となる前記サーバへの前記コンテンツの前記ＡＰＩを介したアップロードが行われる請求項１７に記載の方法。
19. データ損失防止（ＤＬＰ）をクラウドベースのコンテンツ・サービスに適用する方法であって、
    クラウドベースのサービスにアクセスするアプリケーション・プログラミング・インターフェース（ＡＰＩ）を識別するデータを受信すること、
    前記ＡＰＩを識別する前記データに基づいて、アクセスされている前記ＡＰＩに対してサービス固有のパーサが利用可能でないことを判定すること、
    （１）アクセスされている前記ＡＰＩに対してカテゴリ指向パーサが利用可能であると判定された場合、
    アクセスされている前記ＡＰＩに対してサービスのカテゴリを判定すること、及び、
    判定された前記カテゴリに基づいてカテゴリ指向パーサを選択すること、
    前記カテゴリ指向パーサは、前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される複数のカテゴリ指向マッチルールを含み、
    （２）アクセスされている前記ＡＰＩに対してカテゴリ指向パーサが利用可能でないと判定された場合、
    汎用パーサを選択すること、
    前記汎用パーサは、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される、少なくとも１つのデフォルト・マッチルールを含み、前記デフォルト・マッチルールは、複数のカテゴリのサービスに関連付けられ、
    前記選択されたカテゴリ指向パーサまたは選択された汎用パーサの前記マッチルールを使用して、前記ＡＰＩを介して伝達されている前記コンテンツを構文解析して、メタデータを収集し、前記カテゴリ指向マッチルールを使用して、前記収集されたメタデータを変数に割り当てること、及び、
    前記変数に割り当てられた前記収集されたメタデータを、前記ＡＰＩを介して伝達されている前記コンテンツにデータ損失防止を適用するためのＤＬＰプロセッサに送信すること、を含む方法。
20. アクセスされている前記ＡＰＩに対してサービス固有のパーサが利用可能でないと判定された場合、
    前記収集されたメタデータを送信することは、前記メタデータが前記汎用パーサによって収集されたことを示すデータを送信することを、更に含む請求項１９に記載の方法。
21. アクセスされている前記ＡＰＩに対してカテゴリ指向パーサが利用可能かを判定することを更に含む請求項１９または２０に記載の方法。
22. アクセスされている前記ＡＰＩに対してカテゴリ指向パーサが利用可能かの判定が、前記ＡＰＩにアクセスするために使用されるユニフォーム・リソース・ロケータ（ＵＲＬと略記）内のドメイン名に基づいて行われる請求項２１に記載の方法。
23. 前記複数のカテゴリ指向マッチルールは、前記カテゴリ指向パーサによって対処される前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスの前記プロバイダによって使用される前記複数のシンタックスから導出される少なくとも１０のマッチルールを含む請求項１９〜２２の何れか１項に記載の方法。
24. 前記複数のカテゴリ指向マッチルールは、それぞれが前記カテゴリ指向パーサによって対処される前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスの少なくとも２５のプロバイダによって使用されるシンタックスから導出される請求項１９〜２３の何れか１項に記載の方法。
25. 前記クラウドベースのサービスは、サービスの別個のカテゴリにおける少なくとも５つのカテゴリ指向パーサによって供給される請求項１９〜２４の何れか１項に記載の方法。
26. 前記少なくとも５つのカテゴリ指向パーサによって供給される前記サービスの別個のカテゴリは、少なくとも、個人ページ及びブログ、ニュース・ウェブサイト、クラウドベースのストレージ・サービス、ウェブメール、及び、ソーシャル・メディア・サービスを含む請求項２５に記載の方法。
27. 前記ＡＰＩを介して伝達されるコンテンツからメタデータを収集することは、クライアントから、前記クラウドベースのサービスをホストするサーバへのリクエスト・メッセージを処理することを更に含む請求項１９〜２６の何れか１項に記載の方法。
28. 前記リクエスト・メッセージに続いて、前記クライアントからＤＬＰ検査の対象となる前記サーバへの前記コンテンツの前記ＡＰＩを介したアップロードが行われる請求項２７に記載の方法。
29. メモリと１以上のプロセッサを備えたコンピュータ・システムであって、
    前記１以上のプロセッサによって実行された場合、前記コンピュータに請求項１９〜２８の何れか１項に記載の方法を実行させるコンピュータ可読命令を格納しているコンピュータ・システム
30. 請求項１９〜２８の何れか１項に記載の方法を、１以上のプロセッサに実行させるように構成されたコンピュータ可読命令を搭載するコンピュータ可読媒体。
31. データ損失防止（ＤＬＰ）をクラウドベースのコンテンツ・サービスに適用する方法であって、
    未知のクラウドベースのサービスが、サービス固有のパーサ及びカテゴリ指向パーサが利用可能でないアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアクセスされていることを判定すること、
    未知のクラウドベースのサービスがアクセスされていることの判定に基づいて、汎用パーサを選択すること、
    前記汎用パーサは、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される、少なくとも１つのデフォルト・マッチルールを含み、前記デフォルト・マッチルールは、前記カテゴリ指向パーサによって対処される少なくとも２つのカテゴリのサービスに関連付けられ、
    前記選択された汎用パーサを使用して、前記ＡＰＩを介して伝達されている前記コンテンツを構文解析し、メタデータを収集し、前記収集されたメタデータを変数に割り当てること、及び、
    前記変数に割り当てられ、前記メタデータが前記汎用パーサによって収集されたことを示すデータを伴う前記収集されたメタデータを、前記ＡＰＩを介して伝達されている前記コンテンツにデータ損失防止を適用するためのＤＬＰプロセッサに送信すること、を含む方法。
32. データ損失防止（ＤＬＰ）をクラウドベースのコンテンツ・サービスに適用するためのコンピュータ・プログラム命令を記憶した非一時的なコンピュータ可読記憶媒体であって、
    前記命令は、プロセッサ上で実行されると、
    既知のクラウドベースのサービスが、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアクセスされていることを判定すること、
    アクセスされている前記ＡＰＩに対してサービス固有のパーサが利用可能でないことを判定すること、
    アクセスされている前記ＡＰＩに対してサービスのカテゴリを判定すること、
    判定された前記カテゴリに基づいてカテゴリ指向パーサを選択すること、
    前記カテゴリ指向パーサは、前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される複数のカテゴリ指向マッチルールを含み、
    前記カテゴリ指向パーサを使用して、前記ＡＰＩを介して伝達されるコンテンツを構文解析して、メタデータを収集し、前記カテゴリ指向マッチルールを使用して、収集されたメタデータを変数に割り当てること、及び、
    前記変数に割り当てられた前記収集されたメタデータを、前記ＡＰＩを介して伝達されている前記コンテンツにデータ損失防止を適用するためのＤＬＰプロセッサに送信すること、を含む方法を実施する非一時的なコンピュータ可読記憶媒体。
33. 前記選択するアクションにおいて、アクセスされている前記ＡＰＩのために選択すべきカテゴリ指向パーサが利用可能でない場合、
    汎用パーサを選択すること、
    前記汎用パーサは、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される、少なくとも１つのデフォルト・マッチルールを含み、前記デフォルト・マッチルールは、複数のカテゴリのサービスに関連付けられ、及び、
    前記選択された汎用パーサの前記マッチルールを使用して、前記ＡＰＩを介して伝達されている前記コンテンツを構文解析し、前記収集されたメタデータを変数に割り当てること、を更に含む前記方法を実施する請求項３２に記載の非一時的なコンピュータ可読記憶媒体。
34. 前記カテゴリ指向パーサを使用することの決定が、前記ＡＰＩにアクセスするために使用されるユニフォーム・リソース・ロケータ（ＵＲＬと略記）内のドメイン名に基づいて行われる請求項３２または３３に記載の非一時的なコンピュータ可読記憶媒体。
35. 前記複数のマッチルールは、前記カテゴリ指向パーサによって対処される前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスの前記プロバイダによって使用される前記複数のシンタックスから導出される少なくとも１０のマッチルールを含む請求項３２〜３４の何れか１項に記載の非一時的なコンピュータ可読記憶媒体。
36. 前記複数のマッチルールは、それぞれが前記カテゴリ指向パーサによって対処される前記カテゴリのサービスを実施する、クラウドベースのコンテンツ・サービスの少なくとも２５のプロバイダによって使用されるシンタックスから導出される請求項３２〜３５の何れか１項に記載の非一時的なコンピュータ可読記憶媒体。
37. 前記クラウドベースのサービスは、サービスの別個のカテゴリにおける少なくとも５つのカテゴリ指向パーサによって供給される請求項３２〜３６の何れか１項に記載の非一時的なコンピュータ可読記憶媒体。
38. 前記少なくとも５つのカテゴリ指向パーサによって供給される前記サービスの別個のカテゴリは、少なくとも、個人ページ及びブログ、ニュース・ウェブサイト、クラウドベースのストレージ・サービス、ウェブメール、及び、ソーシャル・メディア・サービスを含む請求項３７に記載の非一時的なコンピュータ可読記憶媒体。
39. 前記ＡＰＩを介して伝達されるコンテンツからメタデータを収集することは、クライアントから、前記既知のクラウドベースのサービスをホストするサーバへのリクエスト・メッセージを処理することを更に含む請求項３２〜３８の何れか１項に記載の非一時的なコンピュータ可読記憶媒体。
40. 前記リクエスト・メッセージに続いて、前記クライアントからＤＬＰ検査の対象となる前記サーバへの前記コンテンツの前記ＡＰＩを介したアップロードが行われる請求項３９に記載の非一時的なコンピュータ可読記憶媒体。
41. データ損失防止（ＤＬＰ）をクラウドベースのコンテンツ・サービスに適用するためのコンピュータ・プログラム命令を記憶した非一時的なコンピュータ可読記憶媒体であって、
    前記命令は、プロセッサ上で実行されると、
    未知のクラウドベースのサービスが、サービス固有のパーサ及びカテゴリ指向パーサが利用可能でないアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してアクセスされていることを判定すること、
    未知のクラウドベースのサービスがアクセスされていることの判定に基づいて、汎用パーサを選択すること、
    前記汎用パーサは、クラウドベースのコンテンツ・サービスのプロバイダによって使用される複数のシンタックスから導出される、少なくとも１つのデフォルト・マッチルールを含み、前記デフォルト・マッチルールは、前記カテゴリ指向パーサによって対処される少なくとも２つのカテゴリのサービスに関連付けられ、
    前記選択された汎用パーサを使用して、前記ＡＰＩを介して伝達されている前記コンテンツを構文解析し、メタデータを収集し、前記収集されたメタデータを変数に割り当てること、及び、
    前記変数に割り当てられ、前記メタデータが前記汎用パーサによって収集されたことを示すデータを伴う前記収集されたメタデータを、前記ＡＰＩを介して伝達されている前記コンテンツにデータ損失防止を適用するためのＤＬＰプロセッサに送信すること、を含む方法を実施する非一時的なコンピュータ可読記憶媒体。

Images