(57)【要約】【課題】あるＷｅｂアプリから他のＷｅｂアプリへの操作の可否を、Ｗｅｂアプリ単位で制御する。【解決手段】  情報処理装置は、第１〜３の実行部を備える。第１の実行部は、第１のブラウジングコンテキスト（ＢＣ）で第１のＷｅｂアプリを実行する。第２の実行部は、第２のＢＣで第２のＷｅｂアプリを実行する。第３の実行部は、第３のＢＣで第３のＷｅｂアプリを実行する。第１の実行部は、第２のＷｅｂアプリに対する操作を行うことを求める第１の要求を第３の実行部に送る。ここで、第１のＷｅｂアプリから第２のＷｅｂアプリに対する前記操作が許可されているか否かを示す情報を、制御情報という。制御情報が、前記操作が許可されていることを示す場合、第３の実行部は、第１の要求を第１の実行部から受け取ると、第２のＷｅｂアプリに対して前記操作を行うための第２の要求を、第２の実行部に送る。【選択図】図１
2016095704.tif 000002
【特許請求の範囲】
【請求項１】
第１のブラウジングコンテキストで第１のＷｅｂアプリケーションを実行する第１の実行部と、
第２のブラウジングコンテキストで第２のＷｅｂアプリケーションを実行する第２の実行部と、
第３のブラウジングコンテキストで第３のＷｅｂアプリケーションを実行する第３の実行部と、を備え、
前記第１の実行部は、前記第２のＷｅｂアプリケーションに対する操作を行うことを求める第１の要求を前記第３の実行部に送り、
前記第１のＷｅｂアプリケーションから前記第２のＷｅｂアプリケーションに対する前記操作が許可されているか否かを示す制御情報が、前記操作が許可されていることを示す場合、前記第３の実行部は、前記第１の要求を前記第１の実行部から受け取ると、前記第２のＷｅｂアプリケーションに対して前記操作を行うための第２の要求を、前記第２の実行部に送る
ことを特徴とする情報処理装置。
【請求項２】
前記第３のブラウジングコンテキストは、前記第１と前記第２のブラウジングコンテキストの上位ブラウジングコンテキストである
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記第３のＷｅｂアプリケーションから、前記第１及び前記第２のブラウジングコンテキストがサンドボックス化され、
前記第３のブラウジングコンテキストはサンドボックス化されない
ことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記第３の実行部が、前記第１の実行部に予め認証情報を渡しており、
前記第１の実行部は、前記第１の要求に前記認証情報を含めて、前記第１の要求を前記第３の実行部に送り、
前記第３の実行部は、前記認証情報を用いて、前記第１のＷｅｂアプリケーションを認証する
ことを特徴とする請求項２又は３に記載の情報処理装置。
【請求項５】
情報処理装置上のブラウジングコンテキストにおいて前記情報処理装置に操作制御処理を実行させるプログラムであって、前記操作制御処理が、
前記操作制御処理が実行される前記ブラウジングコンテキストとは異なる、前記情報処理装置上の第１のブラウジングコンテキストで実行される第１のＷｅｂアプリケーションから、前記操作制御処理が実行される前記ブラウジングコンテキストとは異なる、前記情報処理装置上の第２のブラウジングコンテキストで実行される第２のＷｅｂアプリケーションに対する操作を行うことを求める第１の要求を受け取り、
前記第１のＷｅｂアプリケーションから前記第２のＷｅｂアプリケーションに対する前記操作が許可されているか否かを示す制御情報が、前記操作が許可されていることを示す場合、前記第２のＷｅｂアプリケーションに対して前記操作を行うための第２の要求を、前記第２のＷｅｂアプリケーションに送る
ことを含むことを特徴とするプログラム。
【請求項６】
前記操作制御処理は、前記操作制御処理が実行される前記ブラウジングコンテキストから２つの下位ブラウジングコンテキストを作ることを含み、
前記２つの下位ブラウンジグコンテキストが、前記第１のブラウジングコンテキスト及び前記第２のブラウジングコンテキストである
ことを特徴とする請求項５に記載のプログラム。
【請求項７】
前記第１及び前記第２のブラウジングコンテキストをサンドボックス化する
ことを前記操作制御処理が含む
ことを特徴とする請求項６に記載のプログラム。
【請求項８】
前記第１のＷｅｂアプリケーションに予め認証情報を渡し、
前記第１のＷｅｂアプリケーションから受け取った前記第１の要求に前記認証情報が含まれていれば、前記認証情報に基づいて、前記第１のＷｅｂアプリケーションを認証する
ことを前記操作制御処理が含むことを特徴とする請求項６又は７に記載のプログラム。
【請求項９】
情報処理装置が、
第１のブラウジングコンテキストで第１のＷｅｂアプリケーションを実行し、
第２のブラウジングコンテキストで第２のＷｅｂアプリケーションを実行し、
第３のブラウジングコンテキストで第３のＷｅｂアプリケーションを実行し、
前記第１のＷｅｂアプリケーションから前記第２のＷｅｂアプリケーションに対する操作を行うことを求める第１の要求を、前記第３のＷｅｂアプリケーションに送り、
前記第１のＷｅｂアプリケーションから前記第２のＷｅｂアプリケーションに対する前記操作が許可されているか否かを示す制御情報が、前記操作が許可されていることを示す場合、前記第２のＷｅｂアプリケーションに対して前記操作を行うための第２の要求を、前記第１の要求に応じて、前記第３のＷｅｂアプリケーションから前記第２のＷｅｂアプリケーションに送る
ことを特徴とする情報処理方法。
【請求項１０】
前記情報処理装置が、
前記第１のブラウジングコンテキストと前記第２のブラウジングコンテキストを、前記第３のブラウジングコンテキストの下位ブラウジングコンテキストとして作る
ことを特徴とする請求項９に記載の情報処理方法。
【請求項１１】
前記情報処理装置が、
前記第３のブラウジングコンテキストをサンドボックス化せず、
前記第３のＷｅｂアプリケーションに、前記第１及び前記第２のブラウジングコンテキストをサンドボックス化させる
ことを特徴とする請求項１０に記載の情報処理方法。
【請求項１２】
前記情報処理装置が、
前記第３のＷｅｂアプリケーションから前記第１のＷｅｂアプリケーションに予め認証情報を渡し、
前記第１のＷｅｂアプリケーションに従って、前記第１の要求に前記認証情報を含め、
前記第１の要求に含まれる前記認証情報に基づいて、前記第１のＷｅｂアプリケーションを前記第３のＷｅｂアプリケーションにおいて認証する
ことを特徴とする請求項１０又は１１に記載の情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に関する。
【背景技術】
【０００２】
Ｗｅｂアプリケーション（以下、Ｗｅｂアプリとも言う）は、インターネットなどのネットワークを介して使用するアプリケーションソフトウェアである。Ｗｅｂアプリは、Ｗｅｂブラウザ上で動作するプログラムである。Ｗｅｂアプリは、例えばＪａｖａＳｃｒｉｐｔなどのプログラミング言語とＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＨＴＭＬ）で記述されており、Ｗｅｂサーバ側のプログラムと協調して動作する。
【０００３】
Ｗｅｂアプリは、クライアントにインストールされて利用されるＷｅｂブラウザ上のブラウジングコンテキスト（以下、ＢＣ）で実行される。ＢＣとは、ＨＴＭＬ５の仕様によれば、文書が表示されるウィンドウやタブなどの環境を示す。また、ＨＴＭＬ５のインラインフレームなども、ＢＣと呼ばれる。
【０００４】
Ｗｅｂアプリは、オリジンと呼ばれるグループに属している。同一生成源ポリシー（Ｓａｍｅ  Ｏｒｉｇｉｎ  Ｐｏｌｉｃｙ：ＳＯＰ）によれば、Ｗｅｂアプリは、同じオリジンに属している別のＷｅｂアプリに対する操作が許可されている。そのため、Ｗｅｂアプリは、同じオリジンに属している別のＷｅｂアプリに対して、例えば、Ｄｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ（以下、ＤＯＭ）操作や、Ｗｅｂアプリ間のメッセージの送受信などを行うことが許可されている。
【０００５】
一方、ＳＯＰによれば、Ｗｅｂアプリは、異なるオリジンに属している別のＷｅｂアプリに対する操作を行うことが許可されていない。そのため、Ｗｅｂアプリは、異なるオリジンに属している別のＷｅｂアプリに対して、例えば、ＤＯＭ操作や、Ｗｅｂアプリ間のメッセージの送受信を行うことが許可されていない。これにより、異なるオリジンへのデータの漏洩などを避けることができる。このように、Ｗｅｂアプリは、オリジンに基づいて操作を制限される。
【０００６】
プログラムの危険度に応じて、サンドボックスと仮想空間を多段化することを可能とするための情報処理装置も提案されている（例えば、特許文献１を参照）。当該情報処理装置は、子プロセスの起動時に、プロセス起動ポリシーデータを参照する。また、当該情報処理装置は、プロセス起動ポリシーデータの設定情報に従って、子プロセス用に仮想空間とサンドボックスを新たに作るか、又は、親プロセスと同じ仮想空間とサンドボックスを用いるか、を決定する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１０−２０５１８６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＳＯＰのもとでは、あるＷｅｂアプリケーションから他のＷｅｂアプリケーションへの操作の可否は、オリジン単位で制御される。オリジンは、Ｗｅｂアプリケーションの配布者により決定される。その配布者であっても、複数のＷｅｂアプリケーション間の関連性を考慮したオリジンの設計は困難である。
【０００９】
１つの側面において、本発明は、あるＷｅｂアプリケーションから他のＷｅｂアプリケーションへの操作の可否を、Ｗｅｂアプリケーション単位で制御することを目的とする。
【課題を解決するための手段】
【００１０】
一態様による情報処理装置は、第１の実行部、第２の実行部、第３の実行部を備える。前記第１の実行部は、第１のブラウジングコンテキストで第１のＷｅｂアプリケーションを実行する。前記第２の実行部は、第２のブラウジングコンテキストで第２のＷｅｂアプリケーションを実行する。前記第３の実行部は、第３のブラウジングコンテキストで第３のＷｅｂアプリケーションを実行する。前記第１の実行部は、前記第２のＷｅｂアプリケーションに対する操作を行うことを求める第１の要求を前記第３の実行部に送る。ここで、前記第１のＷｅｂアプリケーションから前記第２のＷｅｂアプリケーションに対する前記操作が許可されているか否かを示す情報を、制御情報という。前記制御情報が、前記操作が許可されていることを示す場合、前記第３の実行部は、前記第１の要求を前記第１の実行部から受け取ると、前記第２のＷｅｂアプリケーションに対して前記操作を行うための第２の要求を、前記第２の実行部に送る。
【発明の効果】
【００１１】
あるＷｅｂアプリケーションから他のＷｅｂアプリケーションへの操作の可否を、Ｗｅｂアプリケーション単位で制御することができる。
【図面の簡単な説明】
【００１２】
【図１】本実施形態に係るＷｅｂアプリの実行環境の例を説明する図である。
【図２】情報処理装置とサーバの機能的構成の例を説明する図である。
【図３】情報処理装置及びサーバのハードウェア構成の例を説明する図である。
【図４】制御情報の例（その１）を説明する図である。
【図５】Ｗｅｂアプリ管理情報の例を説明する図である。
【図６Ａ】本実施形態に係る情報処理装置の処理の例を説明するシーケンス図である。
【図６Ｂ】本実施形態に係る情報処理装置の処理の例を説明するシーケンス図である。
【図７】制御情報の例（その２）を説明する図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照しながら、実施形態を詳細に説明する。
図１は、本実施形態に係るＷｅｂアプリの実行環境の例を説明する図である。情報処理装置２００には、ブラウザ１００がインストールされている。ブラウザ１００は、複数のＢＣ（例えば、ウィンドウ、タブ、インラインフレームなど）を提供することができる。各ＢＣでは、Ｗｅｂアプリが実行される。複数のＢＣは階層化（nested）されていてもよい。情報処理装置１００は、複数のＢＣに対応する複数の実行部を含む。
【００１４】
階層化された複数のＢＣは、例えば、トップレベルＢＣ１１０、子ＢＣ１２０、子ＢＣ１３０、孫ＢＣ１４０である。実行部１１１は、オリジンＸに属するＷｅｂアプリ１１２をトップレベルＢＣ１１０で実行する。トップレベルＢＣ１１０は、子ＢＣ１２０と子ＢＣ１３０の親である。そのため、Ｗｅｂアプリ１１２は、子ＢＣ１２０と子ＢＣ１３０をサンドボックス化する（sandbox）ことができる。例えば、トップレベルＢＣ１１０はトップレベルのウィンドウであってもよく、子ＢＣ１２０と子ＢＣ１３０は、トップレベルＢＣ１１０内のインラインフレームであってもよい。
【００１５】
実行部１２１は、オリジンＲに属するＷｅｂアプリ１２２を子ＢＣ１２０で実行する。オリジンＲは、オリジンＸと異なるオリジンである。実行部１３１は、オリジンＳに属するＷｅｂアプリ１３２を子ＢＣ１３０で実行する。オリジンＳは、オリジンＸとオリジンＲとは、別のオリジンである。子ＢＣ１２０は、孫ＢＣ１４０の親である。実行部１４１は、オリジンＲに属するＷｅｂアプリ１４２を孫ＢＣ１４０で実行する。
【００１６】
本実施形態におけるブラウザ１００におけるＷｅｂアプリ１１２は、例えば、オリジンＳに属するＷｅｂアプリ１３２が、オリジンＳと異なるオリジンＲに属するＷｅｂアプリ１４２に対する操作を行うことを可能とする。以下に、異なるオリジンに属するＷｅｂアプリ間の操作を可能とする処理の手順を示す。
【００１７】
まず、Ｗｅｂアプリ１３２からＷｅｂアプリ１４２に対して操作を行おうとする場合、Ｗｅｂアプリ１３２を実行する実行部１３１が、Ｗｅｂアプリ１４２に対して操作を行うことを求める第１の要求を、トップレベルＢＣ１１０の実行部１１１に送る。実行部１１１は、Ｗｅｂアプリ１４２に対して操作を行うことを求める第１の要求を受け取る。実行部１１１は、Ｗｅｂアプリ１３２からＷｅｂアプリ１４２に対する操作が許可されているか否かを示す制御情報が、第１の要求により求められた操作が許可されていることを示すか否かを確認する。
【００１８】
ここで、制御情報は、Ｗｅｂアプリ１１２から利用可能な記憶部に保持されていてもよい。該記憶部は、具体的には、ブラウザ１００を実行する情報処理装置２００内の記憶装置（例えば、主記憶装置、Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ（ＨＤＤ）、またはその組み合わせ）である。また、制御情報を、第１の情報処理装置２００とは異なる、Ｗｅｂアプリ１１２を送信する第２の情報処理装置（サーバ）が保持していてもよい。第２の情報処理装置が制御情報を保持している場合、実行部１１１は、適宜、第２の情報処理装置に対して制御情報についての問い合わせをすればよい。
【００１９】
Ｗｅｂアプリ１３２からＷｅｂアプリ１４２への操作が許可されていることを制御情報が示す場合、実行部１１１は、第１の要求を受け取ると、Ｗｅｂアプリ１４２に対して操作を行うための第２の要求を、実行部１４１に送る。第２の要求を受け取った実行部１４１は、受け取った第２の要求に基づいた操作を、Ｗｅｂアプリ１４２に対して行う。
【００２０】
このように、Ｗｅｂアプリ１１２が、操作を許可するか否かを制御情報に基づいて制御することで、オリジン単位での制御だけでなく、Ｗｅｂアプリ単位での制御が可能となる。そのため、オリジンＳに属するＷｅｂアプリ１３２から、オリジンＳと異なるオリジンＲに属するＷｅｂアプリ１４２に対する操作を行うことが可能となる。また、Ｗｅｂアプリ単位での制御をすることで、同じオリジンＲに属するＷｅｂアプリ１２２とＷｅｂアプリ１４２間での操作を禁止することも可能となる。
【００２１】
なお、本実施形態に係るトップレベルＢＣ１１０のＷｅｂアプリ１２１は、ＢＣが階層化されていなくとも、Ｗｅｂアプリ間の操作を許可するか否かをＷｅｂアプリ単位で制御することが可能である。また、図１に示すブラウザ１００内の各ＢＣの階層や、図１におけるＢＣの数は、単なる例示である。ＢＣの数、ＢＣ同士が階層化されているか否か、ＢＣ同士が階層化されている場合のＢＣ間の親子関係などは、図１に例示されたものに制限されない。
【００２２】
以下において、子ＢＣや孫ＢＣで実行されるＷｅｂアプリを「Ｗｅｂアプリ」と言い、トップレベルＢＣ１１０で実行されるＷｅｂアプリ１１２を「管理アプリ」と区別して称する。
【００２３】
図２は、情報処理装置とサーバの機能的構成の例を説明する図である。サーバ２１０は、少なくとも記憶部２１１と送信部２１２を備える。記憶部２１１は、管理アプリ１５０を記憶している。送信部２１２は、情報処理装置２００からの要求に応じて情報処理装置２００に管理アプリ１５０を送信する。図１に関して説明した制御情報が、記憶部２１１に記憶されていてもよい。なお、情報処理装置２００とサーバ２１０は、ネットワークを介して接続されている。
【００２４】
サーバ２２０Ｒは、オリジンＲに属するＷｅｂアプリ１２２とＷｅｂアプリ１４２を配布する。サーバ２２０Ｓは、オリジンＳに属するＷｅｂアプリ１３２を配布する。サーバ２２０Ｒとサーバ２２０Ｓは、配布するＷｅｂアプリが異なるものの、Ｗｅｂアプリを配布するサーバである。そのため、以下、サーバ２２０Ｒとサーバ２２０Ｓとを纏めてサーバ２２０と称する。情報処理装置２００は、ネットワークを介して、サーバ２２０Ｒとサーバ２２０Ｓに接続されている。
【００２５】
サーバ２２０は、少なくとも記憶部２２１と送信部２２２を備える。サーバ２２０Ｓの記憶部２２１は、オリジンＳに属するＷｅｂアプリ１３２を記憶している。サーバ２２０Ｒの記憶部２２１は、オリジンＲに属するＷｅｂアプリ１２２とＷｅｂアプリ１４２を記憶している。送信部２２２は、情報処理装置２００からの要求に応じて、情報処理装置２００に、要求されたＷｅｂアプリを送信する。
【００２６】
情報処理装置２００は、インストールされているブラウザ１００を動作させる。実行部１１１は、サーバ２１０から管理アプリ１５０をダウンロードし、ダウンロードした管理アプリ１５０をブラウザ１００上で（より具体的にはトップレベルＢＣ１１０上で）実行する。管理アプリ１５０は、メッセージ受信部１５１、操作制御部１５２、処理部１５３、及びメッセージ送信部１５５を実現するためのコードを含む。よって、実行部１１１が管理アプリ１５０を実行することにより、メッセージ受信部１５１、操作制御部１５２、処理部１５３、及びメッセージ送信部１５５が実現される。その結果として、実行部１１１は、メッセージ受信部１５１、操作制御部１５２、処理部１５３、及びメッセージ送信部１５５を含む。また、管理アプリ１５０の実行中に実行部１１１がアクセスすることが可能なローカルな記憶装置（例えば、主記憶装置、ＨＤＤ、またはその組み合わせ）が、記憶部１５４として使われる。
【００２７】
メッセージ受信部１５１は、実行部１２１、実行部１３１、実行部１４１などから、該実行部が実行するＷｅｂアプリとは別のＷｅｂアプリに対して操作を行うことを求める要求を受信する。要求の送受信のために、具体的には、「ＨＴＭＬ５  Ｗｅｂ  ｍｅｓｓａｇｉｎｇ」と呼ばれるＡｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）が利用される。要求の送受信は、情報処理装置２００内で行われる一種のメッセージパッシングである。
【００２８】
記憶部１５４は、Ｗｅｂアプリ間の操作が許可されているかを示す制御情報を記憶する。上記のとおり、記憶部１５４は、情報処理装置２００内の記憶装置（例えば、主記憶装置、ＨＤＤ、またはその組み合わせ）である。また、記憶部１５４は、Ｗｅｂアプリ管理情報を記憶している。Ｗｅｂアプリ管理情報は、管理アプリ１５０を実行する実行部１１１が、ブラウザ１００上で実行されている他のＷｅｂアプリを管理するために用いられる。
【００２９】
操作制御部１５２は、メッセージ受信部１５１が受信した要求により求められている操作が許可されているかを判定する。記憶部１５４に制御情報が記憶されている場合、操作制御部１５２は、記憶部１５４に記憶されている制御情報に基づいて、Ｗｅｂアプリ間の操作が許可されているかを判定する。制御情報をサーバ２１０の記憶部２１１が記憶している場合、操作制御部１５２は、Ｗｅｂアプリ間の操作が許可されているかをサーバ２１０に問い合わせることにより、Ｗｅｂアプリ間の操作が許可されているかを判定する。
【００３０】
処理部１５３は、ブラウザ１００からＷｅｂアプリの実行要求を受け取ると、該Ｗｅｂアプリを、サーバ２２０からダウンロードする。オリジンＳに属するＷｅｂアプリをダウンロードする場合、処理部１５３は、サーバ２２０ＳからＷｅｂアプリをダウンロードする。オリジンＲに属するＷｅｂアプリをダウンロードする場合、処理部１５３は、サーバ２２０ＲからＷｅｂアプリをダウンロードする。
【００３１】
処理部１５３は、ダウンロードしたＷｅｂアプリを、管理アプリ１５０が実行されるＢＣの子ＢＣや孫ＢＣで実行させる。なお、Ｗｅｂアプリの実行要求は、例えば、情報処理装置２００を使用する利用者が、ブラウザ１００上のＷｅｂアプリへのリンクボタンを押下するなどのイベントをトリガとして、発生する。また、処理部１５３は、子ＢＣや孫ＢＣをサンドボックス化する。
【００３２】
なお、Ｗｅｂアプリを子ＢＣや孫ＢＣで実行させる場合、処理部１５３は、Ｗｅｂアプリの情報と、そのＷｅｂアプリが実行されるＢＣの情報とを対応づけた情報を、記憶部１５４のＷｅｂアプリ管理情報に追加する。処理部１５３は、子ＢＣや孫ＢＣで実行されているＷｅｂアプリを認証するかを判断するための認証情報を生成する。そして、処理部１５３は、メッセージ受信部１５１が受信した要求の要求元であるＷｅｂアプリを認証するか否かを、認証情報を用いて判断する。
【００３３】
メッセージ受信部１５１が受信した要求により求められている操作が許可されている場合、メッセージ送信部１５５は、Ｗｅｂアプリに対して操作を行うための要求を、操作対象のＷｅｂアプリを実行する実行部１２１、１３１、又は１４１に送信する。
【００３４】
Ｗｅｂアプリ（例えば、Ｗｅｂアプリ１２２、１３２、及び１４２の各々）は、メッセージ受信部３０１、処理部３０２、メッセージ送信部３０３を実現するためのコードを含む。例えば、実行部１２１がＷｅｂアプリ１２２を実行することにより、実行部１２１内のメッセージ受信部３０１、処理部３０２、及びメッセージ送信部３０３が実現される。以下では便宜上、実行部１２１に含まれるメッセージ受信部３０１、処理部３０２、及びメッセージ送信部３０３について主に説明する。
【００３５】
実行部１２１のメッセージ受信部３０１は、管理アプリ１５０のメッセージ送信部１５５から、Ｗｅｂアプリ１２２に対する操作を行うことを求める要求を受信する。メッセージ送信部３０３は、処理部３０２が行う処理に応じて、他のＷｅｂアプリに対して操作を行うことを求める要求を、管理アプリ１５０のメッセージ受信部１５１へ送信する。
【００３６】
実行部１２１の処理部３０２は、メッセージ受信部３０１が受信した要求に従って、処理（例えば、Ｗｅｂアプリ１２２に対するＤＯＭ操作、Ｗｅｂアプリ１２２に対するメッセージ通知、など）を実行する。実行部１２１の処理部３０２は、自Ｗｅｂアプリ（すなわちＷｅｂアプリ１２２）がどのＢＣ上で実行されているかを判定する。自ＷｅｂアプリがトップレベルＢＣで実行されている場合、処理部３０２は、管理アプリ１５０をトップレベルＢＣ上で実行させ、自Ｗｅｂアプリを一旦終了させる。すると、管理アプリ１５０の処理部１５３は、その終了されたＷｅｂアプリをサーバ２２０（オリジンＳのＷｅｂアプリの場合はサーバ２２０Ｓ、オリジンＲのＷｅｂアプリの場合はサーバ２２０Ｒ）からダウンロードし、子ＢＣや孫ＢＣで実行させる。
【００３７】
図３は、情報処理装置及びサーバのハードウェア構成の例を説明する図である。情報処理装置２００、サーバ２１０、サーバ２２０の各々は、プロセッサ１１、メモリ１２、バス１５、外部記憶装置１６、ネットワーク接続装置１９を備える。さらにオプションとして、情報処理装置２００、サーバ２１０、サーバ２２０の各々は、入力装置１３、出力装置１４、媒体駆動装置１７を備えても良い。情報処理装置２００、サーバ２１０、サーバ２２０の各々は、例えば、コンピュータである。
【００３８】
プロセッサ１１は、任意の処理回路であってよく、例えば、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）であってもよい。プロセッサ１１は、情報処理装置２００において、実行部１１１、実行部１２１、実行部１３１、実行部１４１として動作する。より詳しくは、プロセッサ１１は、処理部１５３、操作制御部１５２、メッセージ受信部１５１、メッセージ送信部１５５として動作する。更に、プロセッサ１１は、メッセージ受信部３０１、処理部３０２、メッセージ送信部３０３として動作する。なお、プロセッサ１１は、例えば、メモリ１２又は外部記憶装置１６に記憶されたプログラムを実行することができる。プロセッサ１１が実行するプログラムの例は、管理アプリ１５０（つまりＷｅｂアプリ１１２）、Ｗｅｂアプリ１２２、Ｗｅｂアプリ１３２、Ｗｅｂアプリ１４２などである。
【００３９】
メモリ１２は、情報処理装置２００において、記憶部１５４として使われる。場合によっては、外部記憶装置１６が記憶部１５４として使われてもよい。サーバ２１０においては、外部記憶装置１６が記憶部２１１として使われるが、メモリ１２が記憶部２１１として使われてもよい。サーバ２２０Ｒ及びサーバ２２０Ｓにおいては、外部記憶装置１６が記憶部２２１として使われるが、メモリ１２が記憶部２２１として使われてもよい。さらに、メモリ１２は、プロセッサ１１の動作により得られたデータや、プロセッサ１１が実行する処理に用いられるデータも、適宜、記憶する。
【００４０】
ネットワーク接続装置１９は、他の装置との通信に使用される。ネットワーク接続装置１９は、例えば、ネットワークアダプタなどのネットワークインタフェイス回路である。ネットワーク接続装置１９は、サーバ２１０においては、送信部２１２として動作する。ネットワーク接続装置１９は、サーバ２２０Ｒ及びサーバ２２０Ｓにおいては、送信部２２２として動作する。情報処理装置２００は、ネットワーク接続装置１９とネットワークを介して、管理アプリ１５０やＷｅｂアプリ１２２、１３２、１４２などをダウンロードする。また、制御情報がサーバ２１０に記憶されている場合、情報処理装置２００のネットワーク接続装置１９は、サーバ２１０に問い合わせを送信し、問い合わせに対する返答を受信するための、送受信装置として動作する。
【００４１】
入力装置１３は、例えば、ボタン、キーボード、マウス等であってもよい。出力装置１４は、ディスプレイなどであってもよい。バス１５は、プロセッサ１１、メモリ１２、入力装置１３、出力装置１４、外部記憶装置１６、媒体駆動装置１７、ネットワーク接続装置１９の間を、相互にデータの受け渡しが行えるように接続する。外部記憶装置１６には、プログラムやデータなどが格納される。外部記憶装置１６は、例えば、ＨＤＤでもよく、Ｓｏｌｉｄ‐Ｓｔａｔｅ  Ｄｒｉｖｅ（ＳＳＤ）でもよい。外部記憶装置１６に格納されている情報は、適宜、プロセッサ１１などに提供される。媒体駆動装置１７は、メモリ１２や外部記憶装置１６に記憶されているデータを可搬記憶媒体１８に出力することができ、また、可搬記憶媒体１８からプログラムやデータ等を読み出すことができる。ここで、可搬記憶媒体１８は、フロッピイディスク、Ｍａｇｎｅｔｏ-Ｏｐｔｉｃａｌ（ＭＯ）ディスク、Ｃｏｍｐａｃｔ  Ｄｉｓｃ  Ｒｅｃｏｒｄａｂｌｅ（ＣＤ−Ｒ）やＤｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ  Ｒｅｃｏｒｄａｂｌｅ（ＤＶＤ−Ｒ）などの、持ち運びが可能な任意の記憶媒体であってよい。可搬型記録媒体１８は、フラッシュメモリなどの半導体メモリカードであってもよく、媒体駆動装置１７はメモリカード用のリーダ及びライタであってもよい。
【００４２】
なお、メモリ１２、外部記憶装置１６、及び可搬型記録媒体１８は、いずれも、有形の（tangible）記憶媒体の例である。これらの有形の記憶媒体は、信号搬送波のような一時的な（transitory）媒体ではない。
【００４３】
図４は、制御情報の例（その１）を説明する図である。制御情報は、Ｗｅｂアプリ間での操作が許可されているかを示す情報である。制御情報は、許可操作情報、操作元情報、操作対象情報、ユーザ情報を対応付けた情報である。
【００４４】
制御情報においては、操作元情報と操作対象情報により示されるＷｅｂアプリのペアと、ユーザ情報により示されるユーザとの組み合わせに対して許可されている操作が、許可操作情報により示される。
【００４５】
上記のとおり、本実施形態では、Ｗｅｂアプリから他のＷｅｂアプリに対する操作を求める要求が送信される。許可操作情報は、他のＷｅｂアプリに対する操作を求める要求の操作元と操作対象の間で許可されている操作の種類を示す。許可操作情報には、例えば、ＤＯＭ操作、メッセージ送受信、全操作（Ｗｅｂアプリ間で要求され得る操作全てを含む）などを示す情報が設定される。
【００４６】
操作元情報は、他のＷｅｂアプリに対する操作を求める要求の操作元のＷｅｂアプリを示す情報である。操作元情報は、例えば、「http://originS.com/webApp132.html」のように、Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）方式により示される。操作元情報中の「http://originS.com」の部分が、オリジンを示す情報であり、この場合は、オリジンＳである。オリジンは、スキームとホストとポートの組み合わせにより識別される。「http://originS.com/webApp132.html」の内、オリジンを示す情報の後に付随している「webApp132.html」の部分は、オリジンに属するＷｅｂアプリを示す情報である。従って、「http://originS.com/webApp132.html」で示される操作元情報は、オリジンＳに属するＷｅｂアプリ１３２を示している。
【００４７】
操作対象情報は、他のＷｅｂアプリに対する操作を求める要求において操作対象として指定されるＷｅｂアプリを示す情報である。操作対象情報は、例えば、「http://originR.com/webApp122.html」のように、ＵＲＬにより示される。「http://originR.com/webApp122.html」は、要求された操作の対象が、オリジンＲに属するＷｅｂアプリ１２２であることを示す。
【００４８】
ユーザ情報は、操作元のＷｅｂアプリから操作対象のＷｅｂアプリに対する操作が、どのユーザに対して許可されているのかを示す。例えば、Ｗｅｂアプリの実行時に、ユーザは、ブラウザ１００の表示画面からユーザ情報を入力するように求められる。
従って、図４の制御情報の一行目には、ユーザＰがブラウザ１００を操作している場合に、Ｗｅｂアプリ１３２からＷｅｂアプリ１２２へのＤＯＭ操作が許可されていることが示されている。図４の制御情報の二行目には、ユーザＰ又はユーザＱがブラウザ１００を操作している場合に、Ｗｅｂアプリ１３２からＷｅｂアプリ１４２へのＤＯＭ操作が許可されていることが示されている。図４の制御情報の三行目には、ユーザＲがブラウザ１００を操作している場合に、Ｗｅｂアプリ１２２からＷｅｂアプリ１４２へのＤＯＭ操作が許可されていることが示されている。図４の制御情報の四行目には、ブラウザ１００を操作しているユーザに関わらず、Ｗｅｂアプリ１３２からＷｅｂアプリ１４２へのメッセージ送受信の操作が許可されていることが示されている。図４の制御情報の五行目には、ユーザＱがブラウザ１００を操作している場合に、Ｗｅｂアプリ１２２からＷｅｂアプリ１３２への全操作（ＤＯＭ操作、メッセージ送受信を含む）が許可されていることが示されている。
【００４９】
なお、図４に例示した制御情報は、許可の内容を限定するものではない。また、操作元情報及び操作対象情報は、図４に例示されているようにＵＲＬを用いてＷｅｂアプリを特定する情報であってもよいが、Ｗｅｂアプリを識別できる情報であれば別の形式の情報でもよい。また、ＵＲＬは、「ｈｔｔｐ」ではなく「ｈｔｔｐｓ」でもよい。「https」は、Ｗｅｂ上のデータ転送に用いられるプロトコルであるＨＴＴＰが、Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ（ＳＳＬ）やＴｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ（ＴＬＳ）で暗号化されている状態を示すものである。ＨＴＴＰは、ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌの略である。なお、管理アプリ１５０は、他のＷｅｂアプリに対するどの操作も許可されているものとする。
【００５０】
管理アプリ１５０が、あるＷｅｂアプリから他のＷｅｂアプリに対する操作を許可するか否かを制御情報に基づいて制御することで、オリジン単位での制御だけでなく、Ｗｅｂアプリ単位での制御が可能となる。また、図４のように、制御情報がユーザ情報を含むことで、ユーザ単位での制御も可能となる。実施形態によっては、ユーザ情報およびユーザ単位での制御が省略されてもよい。
【００５１】
図５は、Ｗｅｂアプリ管理情報の例を説明する図である。Ｗｅｂアプリ管理情報は、管理アプリ１５０が、他のＷｅｂアプリを管理するために用いる情報である。Ｗｅｂアプリ管理情報は、ＢＣ情報、Ｗｅｂアプリ情報、認証情報を対応付けた情報である。図５のＷｅｂアプリ管理情報は、図１の階層化されたＢＣ及びＷｅｂアプリの関係性を説明する図である。
【００５２】
一例として、Ｗｅｂアプリ管理情報の一行目には、ＢＣ情報として「ＢＣ１２０」、Ｗｅｂアプリ情報として「http://originR.com/webApp122.html」、認証情報として「３２４１」が対応づけられている。
【００５３】
Ｗｅｂアプリ情報は、Ｗｅｂアプリと、該Ｗｅｂアプリが属するオリジンとを示す情報である。図５の例では、Ｗｅｂアプリ情報は、具体的にはＵＲＬにより示される。ＢＣ情報は、ＵＲＬにより示されるＷｅｂアプリが実行されているＢＣを識別する情報である。処理部１５３は、ブラウザ１００上の各ＢＣを識別する識別情報を取得することができ、取得した識別情報をＢＣ情報として利用することができる。図５では、理解の助けとするために、実際の識別情報の代わりに「ＢＣ１２０」などの文字列によりＢＣ情報が表現されている（図１を参照）。認証情報は、管理アプリ１５０がＷｅｂアプリの認証に用いる鍵情報である。実施形態によっては、認証情報が省略されてもよい。
【００５４】
つまり、Ｗｅｂアプリ管理情報の一行目の例は、Ｗｅｂアプリ１２２がＢＣ１２０で実行されていることを示す。更に、Ｗｅｂアプリ１２２は、オリジンＲに属しており、管理アプリ１５０によるＷｅｂアプリ１２２の認証では、認証情報「３２４１」が鍵として用いられる。Ｗｅｂアプリ管理情報の二行目の例は、Ｗｅｂアプリ１３２がＢＣ１３０で実行されていることを示す。更に、Ｗｅｂアプリ１３２は、オリジンＳに属しており、管理アプリ１５０によるＷｅｂアプリ１３２の認証では、認証情報「３２ｋｌ」が鍵として用いられる。Ｗｅｂアプリ管理情報の三行目の例は、Ｗｅｂアプリ１４２がＢＣ１４０で実行されていることを示す。更に、Ｗｅｂアプリ１４２は、オリジンＲに属しており、管理アプリ１５０によるＷｅｂアプリ１４２の認証では、認証情報「ｃｖ７５」が鍵として用いられる。
【００５５】
なお、Ｗｅｂアプリ管理情報のＷｅｂアプリ情報は、図５に例示されているようにＵＲＬを用いてＷｅｂアプリを特定する情報であってもよいが、Ｗｅｂアプリを識別できる情報であれば別の形式の情報であってもよい。また、ＢＣ情報も、ＢＣを特定できる情報であれば、どのような形式の情報でもよい。また、認証情報も、認証に用いられる情報であれば、どのような形式の情報でもよい。
【００５６】
図６Ａと図６Ｂは、本実施形態に係る情報処理装置の処理の例を説明するシーケンス図である。図６Ａと図６Ｂのシーケンス図は、ユーザ、ブラウザ１００、ブラウザ１００で実行されるＷｅｂアプリ１３２と管理アプリ１５０とＷｅｂアプリ１２２、サーバ２１０、サーバ２２０の間で行われる処理の例を示している。
【００５７】
ユーザが、情報処理装置２００にブラウザ１００を実行させるための操作（例えばアイコンをダブルクリックする操作）をする（ステップＳ１０１）。その後、ブラウザ１００の画面に表示されている、Ｗｅｂアプリ１３２へのリンクを示すリンクボタンが、ユーザにより押下される（ステップＳ１０２）。
【００５８】
ブラウザ１００は、Ｗｅｂアプリ１３２のダウンロード要求を、サーバ２２０Ｓに送信する（ステップＳ１０３）。サーバ２２０Ｓの送信部２２２は、ステップＳ１０３で要求されたＷｅｂアプリ１３２を、記憶部２２１から読み出し、情報処理装置２００に送信する（ステップＳ１０４）。ブラウザ１００は、あるＢＣ（例えば、リンクを示すアンカータグの属性値により決まるＢＣ）において、Ｗｅｂアプリ１３２の実行を開始する（ステップＳ１０５）。
【００５９】
Ｗｅｂアプリ１３２の処理部３０２は、自Ｗｅｂアプリ１３２が実行されているＢＣがトップレベルＢＣ１１０であるかを判定する（ステップＳ１０６）。Ｗｅｂアプリ１３２が実行されているＢＣがトップレベルＢＣ１１０でない場合（ステップＳ１０６でＮＯ）、Ｗｅｂアプリ１３２の処理部３０２は、ステップＳ１１８の処理を実行する。なお、Ｗｅｂアプリ１３２がトップレベルＢＣ１１０で実行されていない場合とは、既にトップレベルＢＣ１１０で管理アプリ１５０が実行されている場合である。
【００６０】
Ｗｅｂアプリ１３２が実行されているＢＣがトップレベルＢＣ１１０である場合（ステップＳ１０６でＹＥＳ）、Ｗｅｂアプリ１３２の処理部３０２は、トップレベルＢＣ１１０で管理アプリ１５０を実行するための要求をブラウザ１００に送る（ステップＳ１０７）。Ｗｅｂアプリ１３２の処理部３０２は、一旦、トップレベルＢＣ１１０でのＷｅｂアプリ１３２の実行を終了する（ステップＳ１０８）。
【００６１】
ブラウザ１００は、管理アプリ１５０のダウンロード要求を、サーバ２１０に送信する（ステップＳ１０９）。サーバ２１０の送信部２１２は、ステップＳ１０９で要求された管理アプリ１５０を、記憶部２１１から読み出し、情報処理装置２００に送信する（ステップＳ１１０）。なお、サーバ２１０は、管理アプリ１５０のコードの中に、制御情報の少なくとも一部（例えば、図４の制御情報のうち、操作元情報がＷｅｂアプリ１３２を示している行）を含めてもよい。ブラウザ１００は、トップレベルＢＣ１１０において、管理アプリ１５０の実行を開始する（ステップＳ１１１）。制御情報が管理アプリ１５０のコードの中に含まれる場合、管理アプリ１５０の処理部１５３は、制御情報を記憶部１５４に記憶する。
【００６２】
管理アプリ１５０の処理部１５３は、Ｗｅｂアプリ１３２を認証するために用いる認証情報を生成する（ステップＳ１１２）。管理アプリ１５０の処理部１５３は、Ｗｅｂアプリ１３２を示すＷｅｂアプリ情報と、Ｗｅｂアプリ１３２を実行するＢＣを示すＢＣ情報と、Ｗｅｂアプリ１３２の認証情報とを対応付けて、記憶部１５４のＷｅｂアプリ管理情報に追加する（ステップＳ１１３）。管理アプリ１５０の処理部１５３は、Ｗｅｂアプリ１３２を実行するための要求をブラウザ１００に送る（ステップＳ１１４）。なお、ステップＳ１１４では、処理部１５３は、Ｗｅｂアプリ１３２を実行するＢＣを、例えば、子ＢＣ１３０と指定する。それにより、子ＢＣ１３０が作られる。
【００６３】
ブラウザ１００は、Ｗｅｂアプリ１３２のダウンロード要求を、サーバ２２０Ｓに送信する（ステップＳ１１５）。サーバ２２０Ｓの送信部２２２は、ステップＳ１１５で要求されたＷｅｂアプリ１３２を、記憶部２２１から読み出し、情報処理装置２００に送信する（ステップＳ１１６）。ブラウザ１００は、子ＢＣ１３０において、Ｗｅｂアプリ１３２の実行を開始する（ステップＳ１１７）。
【００６４】
Ｗｅｂアプリ１３２の処理部３０２は、自Ｗｅｂアプリ１３２が実行されているＢＣがトップレベルＢＣ１１０であるかを判定する（ステップＳ１１８）。Ｗｅｂアプリ１３２が実行されているＢＣがトップレベルＢＣ１１０である場合（ステップＳ１１８でＹＥＳ）、Ｗｅｂアプリ１３２の処理部３０２は、ステップＳ１０７から処理を繰り返す。Ｗｅｂアプリ１３２が実行されているＢＣがトップレベルＢＣ１１０でない場合（ステップＳ１１８でＮＯ）、Ｗｅｂアプリ１３２の処理部３０２は、管理アプリ１５０に対して認証情報の取得要求を送る（ステップＳ１１９）。管理アプリ１５０の処理部１５３は、Ｗｅｂアプリ１３２に対応した認証情報をＷｅｂアプリ１３２に送る（ステップＳ１２０）。Ｗｅｂアプリ１３２の処理部３０２は、受け取った認証情報を含む問い合わせを管理アプリ１５０に送ることにより、Ｗｅｂアプリ１３２を認証するよう管理アプリ１５０に要求する（ステップＳ１２１）。なお、Ｗｅｂアプリ１３２の処理部３０２は、不図示のローカルな記憶装置（例えば、主記憶装置、ＨＤＤ、またはその組み合わせ）に、取得した認証情報を記憶する。
【００６５】
管理アプリ１５０の処理部１５３は、Ｗｅｂアプリ１３２から送られた認証情報を用いて、Ｗｅｂアプリ１３２を認証するか否か判断する（ステップＳ１２２）。具体的には、ステップＳ１２２において、処理部１５３は、記憶部１５４のＷｅｂアプリ管理情報に含まれる認証情報と、Ｗｅｂアプリ１３２から送られた認証情報とを比較する。Ｗｅｂアプリ１３２からの認証情報が不正な場合（ステップＳ１２２でＮＯ）、管理アプリ１５０の処理部１５３は、Ｗｅｂアプリ１３２を終了させ、ステップＳ１１２から再度処理を実行する。Ｗｅｂアプリ１３２からの認証情報に問題がない場合（ステップＳ１２２でＹＥＳ）、管理アプリ１５０の処理部１５３は、Ｗｅｂアプリ１３２を認証したことを示す情報を、Ｗｅｂアプリ１３２に送る（ステップＳ１２３）。
【００６６】
Ｗｅｂアプリ１３２の処理部３０２は、ステップＳ１２０で取得した認証情報を、不図示の記憶装置から読み出す（ステップＳ１２４）。Ｗｅｂアプリ１３２の処理部３０２は、ステップＳ１２４を含む、Ｗｅｂアプリ１２２に対する操作を行うことを求める要求を生成する（ステップＳ１２５）。Ｗｅｂアプリ１３２のメッセージ送信部３０３は、Ｗｅｂアプリ１２２に対する操作を行うことを求める要求を管理アプリ１５０に送る（ステップＳ１２６）。
【００６７】
管理アプリ１５０のメッセージ受信部１５１は、Ｗｅｂアプリ１３２のメッセージ送信部３０３から送られた要求（つまり、Ｗｅｂアプリ１２２に対する操作を行うことを求める要求）を受け取る（ステップＳ１２７）。管理アプリ１５０の処理部１５３は、Ｗｅｂアプリ１３２からの要求に認証情報が含まれているか否かを確認する（ステップＳ１２８）。Ｗｅｂアプリ１３２からの要求に正しい認証情報が含まれていない場合（ステップＳ１２８でＮＯ）、ステップＳ１２５から再度処理を繰り返す。Ｗｅｂアプリ１３２からの要求に正しい認証情報が含まれている場合（ステップＳ１２８でＹＥＳ）、管理アプリ１５０の操作制御部１５２は、要求された操作が許可されているかを判定する（ステップＳ１２９）。具体的には、操作制御部１５２は、記憶部１５４に記憶されている制御情報に基づいて、Ｗｅｂアプリ１３２からＷｅｂアプリ１２２への操作が許可されているかを判定する。
【００６８】
Ｗｅｂアプリ１３２からＷｅｂアプリ１２２への操作が許可されていない場合（ステップＳ１２９でＮＯ）、管理アプリ１５０及びＷｅｂアプリ１３２は処理を終了する。Ｗｅｂアプリ１３２からＷｅｂアプリ１２２への操作が許可されている場合（ステップＳ１２９でＹＥＳ）、管理アプリ１５０の処理部１５３は、操作対象であるＷｅｂアプリ１２２の認証を行う（ステップＳ１３０）。なお、Ｗｅｂアプリ１２２は、Ｗｅｂアプリ１３２の実行が開始される前に、予め子ＢＣ１２０で実行されていてもよい。または、Ｗｅｂアプリ１２２の実行は、任意のタイミング（例えばステップＳ１１２〜Ｓ１３０の間）で開始されてもよい。いずれにせよ、Ｗｅｂアプリ１２２の実行は、ステップＳ１０２〜Ｓ１１７と同様の処理により開始される。つまり、管理アプリ１５０の処理部１５３は、ステップＳ１１２と同様の処理により、Ｗｅｂアプリ１２２に対応する認証情報を既に生成している。よって、ステップＳ１３０で処理部１５３は、Ｗｅｂアプリ１２２に対応する認証情報を記憶部１５４から読み出し、読み出した認証情報を用いてＷｅｂアプリ１２２の認証を行う。
【００６９】
Ｗｅｂアプリ１２２の認証に問題がある場合（ステップＳ１３０でＮＯ）、管理アプリ１５０の処理部１５３は、管理アプリ１５０とＷｅｂアプリ１２２の処理を終了する。認証に問題がある場合とは、例えば、既にＷｅｂアプリ１２２が終了しており、Ｗｅｂアプリ１２２に対応する情報がＷｅｂアプリ管理情報から削除されている場合である。Ｗｅｂアプリ１２２の認証に問題がない場合（ステップＳ１３０でＹＥＳ）、管理アプリ１５０のメッセージ送信部１５５は、Ｗｅｂアプリ１２２に対して操作を行うための要求を、Ｗｅｂアプリ１２２に送る（ステップＳ１３１）。
【００７０】
Ｗｅｂアプリ１２２の処理部３０２は、ステップＳ１３１で管理アプリ１５０から受け取った要求に基づいた処理（例えば、ＤＯＭ操作など）を実行する（ステップＳ１３２）。
【００７１】
ユーザは、任意のタイミングでＷｅｂアプリ１３２を終了するための操作をする（ステップＳ１３３）。ブラウザ１００は、Ｗｅｂアプリ１３２を終了するよう求める要求をＷｅｂアプリ１３２に送る（ステップＳ１３４）。Ｗｅｂアプリ１３２の処理部３０２は、管理アプリ１５０に、Ｗｅｂアプリ１３２が終了することを示す情報を送り、Ｗｅｂアプリ１３２自体を終了させる（ステップＳ１３５）。管理アプリ１５０の処理部１５３は、Ｗｅｂアプリ１３２に対応する情報を、Ｗｅｂアプリ管理情報から削除する（ステップＳ１３６）。
【００７２】
なお、ユーザがＷｅｂアプリ１３２のリンクボタンを押下する時点（ステップＳ１０２の時点）で、Ｗｅｂアプリ１３２を使用するためのユーザ認証が既に行われていてもよい。または、Ｗｅｂアプリ１３２の実行開始後の任意のタイミングで、Ｗｅｂアプリ１３２が、ユーザに、ユーザ認証のための情報の入力を要求してもよい。よって、Ｗｅｂアプリ１３２は、ステップＳ１２６で送る要求にユーザ情報を含めることができる。そのため、管理アプリ１５０の処理部１５３は、ステップＳ１３０で、要求に含まれるユーザ情報と制御情報に含まれるユーザ情報とを比較することができる。
【００７３】
管理アプリ１５０は、例えば、下に示すＨＴＭＬコードで実現されてもよい。
<!DOCTYPE html>
<html>
<body>
<iframe id="iframe0" sandbox="allow-popups allow-top-navigation allow-forms allow-pointer-lock allow-scripts"></iframe>
<script>(略)</script>
</body>
</html>
Ｗｅｂアプリ１３２は、例えば、下に記載するコードを含んでいてもよい。それにより、ステップＳ１０６〜Ｓ１０９の処理が実現される。
if(window == top) {    
var href="https://originX.com/webApp112.html";
href += "title=" + document.title; 
href += "url" + location.href;
location.href=href;
}
【００７４】
ステップＳ１１２とステップＳ１１４の処理は、例えば、下に示すコードで実現されてもよい。
var appKey = String(Math.floor(1000000000*Math.random()));
function GetQueryString(key) {
var regex = new RegExp("[\\?&]" + key + "=([^&#]*)";
var result = regex.exec(window.location.href);
return result[1];
}
var newURL = GetQueryString("url") + "&appKey=" + appKey;  
document.getElementById("iframe0").src = 
decodeURIComponent(GetQueryString("url"));
【００７５】
また、管理部１５０は、ステップＳ１１４の処理に、下に示すコードを含めてもよい。
iframe0.location.href=url;
これは、管理アプリ１５０のインラインフレーム・オブジェクトである「iframe0」のソースを示す「href」属性に、実行したいＷｅｂアプリ（つまりＷｅｂアプリ１３２）のＵＲＬを示す変数「url」の値を代入する処理である。
【００７６】
また、ステップＳ１１４の処理は、Ｗｅｂアプリ１３２を再起動することを示すコードを含めてもよい。下にＷｅｂアプリ１３２を再起動することを示すコードを示す。
windowObject.location.href=url;
なお、「windowObject」は、管理アプリ１５０に操作の要求を送ったＢＣ１３０を示すウィンドウオブジェクトであり、「url」はＢＣ１３０内のＷｅｂアプリ１３２のＵＲＬである。
【００７７】
ステップＳ１３５の処理は、例えば、下に示すコードで実現されてもよい。
window.addEventListener('beforeunload', function () {
var message = "FINALIZE";
top.postMessage(message, "http://originX.com");
});
【００７８】
ステップＳ１０７の処理は、例えば、下に示すコードで実現されてもよい。
var message = "INITIALIZE" + location.href; 
top.postMessage(message, "https://originX.com/webApp122.html");
【００７９】
以上、説明したように、実施形態にかかる方法では、Ｗｅｂアプリ１１２（すなわち管理アプリ１５０）が、操作を許可するか否かを制御情報に基づいて制御することで、オリジン単位での制御だけでなく、Ｗｅｂアプリ単位での制御が可能となる。そのため、オリジンＳに属するＷｅｂアプリ１３２から、オリジンＳと異なるオリジンＲに属するＷｅｂアプリ１４２に対する操作を行うことが可能となる。また、Ｗｅｂアプリ単位での制御をすることで、同じオリジンＲに属するＷｅｂアプリ１２２とＷｅｂアプリ１４２間での操作を禁止することも可能となる。
【００８０】
＜その他＞
図７は、制御情報の例（その２）を説明する図である。図７は、Ｗｅｂアプリをグループ化して操作制御をする場合の制御情報の例を示す。図７の制御情報は、グループ情報、Ｗｅｂアプリ情報、ユーザ情報を含む。
【００８１】
グループ情報は、少なくとも２つのＷｅｂアプリを含むグループを識別するための情報である。Ｗｅｂアプリ情報は、グループに属しているＷｅｂアプリの（ＵＲＬ）情報である。ユーザ情報は、そのグループに属しているＷｅｂアプリ間での全操作が許可されているユーザを示す情報である。
【００８２】
図７の制御情報の例では、「グループＡ」に属するＷｅｂアプリは、「http://originR.com/webApp122.html」で表されるＷｅｂアプリ１２２と、「http://originS.com/webApp132.html」で表されるＷｅｂアプリ１３２である。そして、グループＡのＷｅｂアプリ１２２とＷｅｂアプリ１３２の間の全操作が許可されているユーザは、ユーザ情報に示されるユーザＰ及びユーザＱである。ユーザＰ又はユーザＱが、Ｗｅｂアプリ１２２又はＷｅｂアプリ１３２を実行している場合、Ｗｅｂアプリ１２２とＷｅｂアプリ１３２の間の任意の操作が許可される。「グループＢ」に属するＷｅｂアプリは、「http://originR.com/webApp142.html」で表されるＷｅｂアプリ１４２と「http://originS.com/webApp132.html」で表されるＷｅｂアプリ１３２である。そして、グループＢのＷｅｂアプリ１４２とＷｅｂアプリ１３２の間の全操作が許可されているユーザは、ユーザ情報に示されるユーザＰ及びユーザＲである。ユーザＰ又はユーザＲが、Ｗｅｂアプリ１４２又はＷｅｂアプリ１３２を実行している場合、Ｗｅｂアプリ１４２とＷｅｂアプリ１３２の間の任意の操作が許可される。
【００８３】
言い換えると、グループＡとグループＢの情報によると、ユーザＰは、Ｗｅｂアプリ１２２とＷｅｂアプリ１３２の間の全操作と、Ｗｅｂアプリ１４２とＷｅｂアプリ１３２の間の全操作を実行することが許可されている。ユーザＱは，Ｗｅｂアプリ１２２とＷｅｂアプリ１３２の間の全操作を実行することが許可されている。ユーザＲは、Ｗｅｂアプリ１４２とＷｅｂアプリ１３２の間の全操作を実行することが許可されている。管理アプリ１５０の操作制御部１５２は、例えば図６ＢのステップＳ１２９において、図４の制御情報の代わりに図７の制御情報を用いて判断を行ってもよい。
【００８４】
本実施形態におけるＷｅｂアプリ１１２は、子ＢＣ１２０、子ＢＣ１３０、孫ＢＣ１４０などをサンドボックス化することができる。サンドボックス化されたＢＣで実行されるＷｅｂアプリのオリジンはnullとなる。なお、オリジンnullに属している２つのＷｅｂアプリは、同じオリジンに属していることにはならない。
【００８５】
サンドボックス化されたＢＣで実行されるオリジンnullのＷｅｂアプリに対して、オリジンを指定した操作はできない。また、サンドボックス化されたＢＣで実行されるオリジンnullのＷｅｂアプリから、オリジンの情報を取得することはできない。ブラウザ１００で複数のＢＣをサンドボックス化して使用する環境では、本実施形態のように、管理アプリ１５０が、オリジン単位でなくＷｅｂアプリ単位で操作制御をすることが望ましい。
【００８６】
また、ＢＣがサンドボックス化されることで、Ｗｅｂアプリ１３２、Ｗｅｂアプリ１２２、Ｗｅｂアプリ１４２は、管理アプリ１５０経由で送られたメッセージ以外は受信しないようにすることで、セキュリティを保証できる。
【００８７】
本実施形態では、管理アプリ１５０をサンドボックス化されていないＢＣ上で実行することが望ましい。ＷｅｂアプリがトップレベルＢＣ１１０で実行されると、管理アプリ１５０が実行されるため、Ｗｅｂアプリ使用時に管理アプリ１５０が実行されていることが保証される。管理アプリ１５０は、図６ＡのステップＳ１１４のように、管理アプリ１５０がＷｅｂアプリの実行を開始するため、ＷｅｂアプリがどのＢＣで実行されているのかを把握可能である。管理アプリ１５０が子ＢＣでＷｅｂアプリを実行することで、Ｗｅｂアプリをサンドボックス化されたＢＣ環境で実行させることができる。
【００８８】
子ＢＣがサンドボックス化されている場合、管理アプリ１５０は、操作元のＷｅｂアプリのオリジンを取得できない。そのため、管理アプリ１５０は、操作元のＷｅｂアプリと、図６ＡのステップＳ１２１と図６ＢのステップＳ１２６のように、操作元のＷｅｂアプリを認証できることが望ましい。同様に、管理アプリ１５０は、オリジンが取得できない操作対象のＷｅｂアプリを、図６ＢのステップＳ１３１のように、操作対象のＷｅｂアプリを認証できることが望ましい。
【符号の説明】
【００８９】
１００  ブラウザ
１１０  トップレベルＢＣ
１１１、１２１、１３１、１４１  実行部
１１２、１２２、１３２、１４２  Ｗｅｂアプリ
１２０、１３０  子ＢＣ
１４０  孫ＢＣ
１５０  管理アプリ
２００  情報処理装置
２１０、２２０、２２０Ｓ、２２０Ｒ  サーバ
１５４、２１１、２２１  記憶部
２１２、２２２  送信部
１５１、３０１  メッセージ受信部
１５２  操作制御部
１５３、３０２  処理部
１５５、３０３  メッセージ送信部
【図１】
2016095704.tif 000003
【図２】
2016095704.tif 000004
【図３】
2016095704.tif 000005
【図４】
2016095704.tif 000006
【図５】
2016095704.tif 000007
【図６Ａ】
2016095704.tif 000008
【図６Ｂ】
2016095704.tif 000009
【図７】
2016095704.tif 000010