(57)【要約】【課題】画面の一部を簡単に取り込むことができる情報処理装置を提供すること。【解決手段】画面における複数のアプリケーションの表示を制御する情報処理装置１０であって、前記画面に表示された第一のアプリケーションの表示範囲を少なくとも含む第一の画像データを取得する画像データ取得手段３２と、前記第一のアプリケーションの表示範囲に関する情報を取得する表示範囲取得手段３４と、前記表示範囲取得手段が取得した前記第一のアプリケーションの表示範囲に基づいて、少なくとも前記第一の画像データの一部を含む第二の画像データを生成する生成手段３５と、を有する。【選択図】図１
2019133283.tif 000002
【特許請求の範囲】
【請求項１】
画面における複数のアプリケーションの表示を制御する情報処理装置であって、
前記画面に表示された第一のアプリケーションの表示範囲を少なくとも含む第一の画像データを取得する画像データ取得手段と、
前記第一のアプリケーションの表示範囲に関する情報を取得する表示範囲取得手段と、
前記表示範囲取得手段が取得した前記第一のアプリケーションの表示範囲に基づいて、少なくとも前記第一の画像データの一部を含む第二の画像データを生成する生成手段と、
を有する情報処理装置。
【請求項２】
前記生成手段が生成した前記第二の画像データを第二のアプリケーションの画面に表示する画像データ表示手段を有することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記画像データ取得手段、前記表示範囲取得手段、及び、前記生成手段は、第三のアプリケーションが提供する機能であり、
前記第一のアプリケーション、前記第二のアプリケーション、及び、前記第三のアプリケーションはＯＳ（Operating System）上で動作しており、
前記第二のアプリケーションは前記ＯＳを介して前記第三のアプリケーションに対し、前記第一のアプリケーションの画面の画像データの取得を要求することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記第二のアプリケーションは、
前記ＯＳが提供するカスタムＵＲＩスキームを使って、前記第三のアプリケーションの起動と前記第一のアプリケーションの画面の画像データの取得とを、前記第三のアプリケーションに対し要求することを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記第二のアプリケーションは、前記第一のアプリケーションの画面の前記第一の画像データの取得を要求する際、前記第二の画像データの保存場所を指定する保存場所指定情報を、前記ＯＳを介して前記第三のアプリケーションに通知し、
前記第三のアプリケーションは、前記第二の画像データを前記保存場所指定情報で指定された保存場所に記憶させ、
前記第二のアプリケーションは前記保存場所から前記第二の画像データを取得して、前記画像データ表示手段が前記画像データを第二のアプリケーションの画面に表示することを特徴とする請求項３又は４に記載の情報処理装置。
【請求項６】
前記表示範囲取得手段は、前記ＯＳから前記第一のアプリケーションの画面と前記第二のアプリケーションの画面の表示範囲に関する情報を取得し、
予め既知の前記第二のアプリケーションの識別情報を有さないアプリケーションを前記第一のアプリケーションとして判断して、前記第一のアプリケーションの画面の表示範囲に関する情報を取得することを特徴とする請求項３〜５のいずれか１項に記載の情報処理装置。
【請求項７】
前記表示範囲取得手段は、前記第一のアプリケーションの画面の表示範囲を少なくとも含むスクリーンを前記第一のアプリケーションの画面に重畳して表示して、ユーザにより指定される切取領域を受け付け、
前記生成手段は、前記表示範囲取得手段が取得した前記切取領域を前記第一の画像データから切り取ることを特徴とする請求項３〜５のいずれか１項に記載の情報処理装置。
【請求項８】
前記表示範囲取得手段は、前記第一のアプリケーションが前記画面に表示しきれない非表示範囲を含む前記第一のアプリケーションの表示範囲に関する情報を取得し、
前記画像データ取得手段は、前記第一のアプリケーションが前記画面に表示しきれない非表示範囲を含む前記第一のアプリケーションの画面の前記第一の画像データを取得し、
前記画像データ表示手段は、前記画像データ取得手段が取得した前記第一の画像データから生成された前記第二の画像データを第二のアプリケーションの画面に表示することを特徴とする請求項３〜５のいずれか１項に記載の情報処理装置。
【請求項９】
ネットワークを介して第二の情報処理装置と通信する通信手段を有し、
前記通信手段は、前記生成手段が生成した前記第二の画像データを前記第二の情報処理装置に送信し、
前記画像データ表示手段は、前記通信手段が前記第二の情報処理装置から受信した前記第二の画像データを前記第二のアプリケーションの画面に表示することを特徴とする請求項２〜８のいずれか１項に記載の情報処理装置。
【請求項１０】
前記第二の情報処理装置はＷｅｂサーバであり、
前記第二のアプリケーションはブラウザの機能を有し、
前記第二の情報処理装置により生成された前記第二の画像データを表示させる処理がＨＴＭＬ及びスクリプトで記述された画面情報に基づいて、
前記画像データ表示手段は、前記第二の画像データを前記第二のアプリケーションの画面に表示することを特徴とする請求項９に記載の情報処理装置。
【請求項１１】
前記通信手段は、前記生成手段が生成した前記第二の画像データを前記第二の情報処理装置に送信する際、前記第二のアプリケーションの画面における前記第一の画像データの表示位置を前記第二の情報処理装置に送信し、
前記第二の情報処理装置により生成された前記第二の画像データを前記表示位置に表示させる処理がＨＴＭＬ及びスクリプトで記述された画面情報に基づいて、
前記画像データ表示手段は、前記第二の画像データを前記第二のアプリケーションの画面の前記表示位置に表示することを特徴とする請求項１０に記載の情報処理装置。
【請求項１２】
前記通信手段は、前記第二のアプリケーションの表示範囲に含まれる座標を前記第二の画像データの表示位置として前記第二の情報処理装置に送信することを特徴とする請求項１１に記載の情報処理装置。
【請求項１３】
画面における複数のアプリケーションの表示を制御する情報処理装置を、
前記画面に表示された第一のアプリケーションの表示範囲を少なくとも含む第一の画像データを取得する画像データ取得手段と、
前記第一のアプリケーションの表示範囲に関する情報を取得する表示範囲取得手段と、
前記表示範囲取得手段が取得した前記第一のアプリケーションの表示範囲に基づいて、少なくとも前記第一の画像データの一部を含む第二の画像データを生成する生成手段、
として機能させるためのプログラム。
【請求項１４】
画面における複数のアプリケーションの表示を制御する情報処理装置と、前記情報処理装置とネットワークを介して通信する第二の情報処理装置とを有する通信システムであって、
前記情報処理装置は、
前記画面に表示された第一のアプリケーションの表示範囲を少なくとも含む第一の画像データを取得する画像データ取得手段と、
前記第一のアプリケーションの表示範囲に関する情報を取得する表示範囲取得手段と、
前記表示範囲取得手段が取得した前記第一のアプリケーションの表示範囲に基づいて、少なくとも前記第一の画像データの一部を含む第二の画像データを生成する生成手段と、
前記生成手段が生成した前記第一のアプリケーションの画面の第二の画像データを、前記第二の情報処理装置に送信する通信手段と、を有し、
前記第二の情報処理装置は、
前記第二の画像データを受信する第二の通信手段と、
前記第二の画像データを表示させる処理がＨＴＭＬ及びスクリプトで記述された画面情報を生成する画面情報生成手段と、を有し、
前記第二の通信手段は前記画面情報を前記情報処理装置に送信する、通信システム。
【請求項１５】
画面における複数のアプリケーションの表示を制御する情報処理装置が行う画像処理方法であって、
画像データ取得手段が、前記画面に表示された第一のアプリケーションの表示範囲を少なくとも含む第一の画像データを取得するステップと、
表示範囲取得手段が、前記第一のアプリケーションの表示範囲に関する情報を取得するステップと、
生成手段が、前記表示範囲取得手段が取得した前記第一のアプリケーションの表示範囲に基づいて、前記第一の画像データの一部を含む第二の画像データを生成するステップと、
を有する画像処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、プログラム、通信システム、及び、画像処理方法に関する。
【背景技術】
【０００２】
マルチタスクに対応しているＯＳ（Operating System）を有する情報処理装置では、複数のアプリを並行に実行することができ、表示装置に複数のアプリケーション（以下、アプリという）の画面を同時に表示することができる。ユーザからは複数のアプリが同時に実行されているように見え、ユーザは所望のアプリの画面を選択して各アプリを操作できる（例えば、特許文献１参照。）。特許文献１には、メールを作成するアプリの画面と、音楽データを再生するアプリの画面とを表示装置に同時に表示する携帯端末について開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
しかしながら、従来の技術では画面の一部を簡単に取り込むことができないという問題があった。例えば、アプリＡとアプリＢの画面が表示装置に同時に表示されている状態で、ユーザがアプリＡ又はアプリＢの画面だけを取り込みたい場合がある。アプリＢが資料表示アプリである場合に、資料表示アプリが表示する情報をユーザが活用するような場合である。ユーザは資料表示アプリの画面の画像データをアプリＡで表示したり、外部に送信したりすることができる。
【０００４】
従来、このような要望に対しては、ＯＳが提供する表示装置の全体画面の取り込み機能をユーザが利用して、全体画面の画像データからアプリＢの画面の部分だけをマウスなどで指定してトリミングする要があった。アプリＡがアプリＢの画面の画像データを活用するためには、更に、ユーザがアプリＡに画像データを読み取らせる操作を行う。このようにユーザとしては多くの操作を行う必要があり手間がかかってしまう。
【０００５】
本発明は、上記課題に鑑み、画面の一部を簡単に取り込むことができる情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題に鑑み、本発明は、画面における複数のアプリケーションの表示を制御する情報処理装置であって、前記画面に表示された第一のアプリケーションの表示範囲を少なくとも含む第一の画像データを取得する画像データ取得手段と、前記第一のアプリケーションの表示範囲に関する情報を取得する表示範囲取得手段と、前記表示範囲取得手段が取得した前記第一のアプリケーションの表示範囲に基づいて、少なくとも前記第一の画像データの一部を含む第二の画像データを生成する生成手段と、を有する。
【発明の効果】
【０００７】
画面の一部を簡単に取り込むことができる情報処理装置を提供することができる。
【図面の簡単な説明】
【０００８】
【図１】情報処理装置で動作する２つのアプリの画面のうち一方の画面の取り込み方法を説明する図である。
【図２】本実施形態の通信システムの概略構成図の一例である。
【図３】情報端末のハードウェア構成図の一例である。
【図４】サーバの概略的なハードウェア構成図の一例である。
【図５】情報処理装置で動作するソフトウェア構成の一例を示す図である。
【図６】情報処理装置及びサーバが有する機能をブロック状に示す機能ブロック図の一例である。
【図７】カスタムＵＲＩスキームを説明する図の一例である。
【図８】ホワイトボードアプリと補助アプリが資料表示アプリの画面の画像データを取り込む手順を示すシーケンス図の一例である。
【図９】トリミング領域について補足する図の一例である。
【図１０】ホワイトボードアプリが表示するメニューの一例を示す図である。
【図１１】資料表示アプリの画面の画像データの表示方法を説明する図の一例である。
【図１２】ホワイトボードアプリが表示する画像データの表示例を示す図である。
【図１３】資料表示アプリの画面の一部の画像データを取得する方法を説明する図の一例である。
【図１４】資料表示アプリの非表示画面の取得方法を説明する図の一例である。
【発明を実施するための形態】
【０００９】
以下、本発明を実施するための形態の一例として、情報処理装置１０，及び、情報処理装置１０が行う画像処理方法について図面を参照しながら説明する。
【００１０】
＜複数のアプリの画面の表示例とアプリの画面の取り込み＞
まず、図１を用いて複数のアプリケーション（以下、単にアプリという）の画面の表示例について説明する。図１は情報処理装置１０で動作する２つのアプリの画面のうち一方の画面の取り込み方法を説明する図である。図１では資料表示アプリ（第一のアプリケーションの一例）とホワイトボードアプリ（第二のアプリケーションの一例）とが動作しており、資料表示アプリの画面４１とホワイトボードアプリの画面４２が表示されている。ホワイトボードアプリはホワイトボードのように使用されるアプリであり、ユーザは文字等を手書きできる他、画像データを貼り付けることができる。図１からは明らかでないがホワイトボードアプリはサーバと通信して、他の拠点のホワイトボードアプリと画面を表有している。拠点とは、活動のよりどころとなる所である。情報処理装置の設置場所又はユーザの所在が拠点である。
【００１１】
資料表示アプリは例えば会議で共有される資料を表示しており、ユーザがこの資料をホワイトボードアプリに貼り付け、他の拠点の会議参加者と共有したり、貼り付けた画像に対してホワイトボードアプリを使ってメモ等の書き込みしたりしたいと考える場合がある。従来の技術では、ユーザが表示装置の全体画面４３を取り込む操作を情報処理装置１０に入力し、その後、全体画面４３の画像データから資料表示アプリの画面４１のみをトリミングする必要があった。
【００１２】
この操作をホワイトボードアプリが自動で行えばよいが、ホワイトボードアプリは後述するようにＷｅｂアプリであるため、ホワイトボードアプリの画面４２の取り込みは可能でも、全体画面４３（又は資料表示アプリの画面４１のみ）の取り込みはセキュリティ上好ましくない。これは、全体画面４３の取り込みが可能であると、Ｗｅｂアプリを取得する情報処理装置の画面、つまり、Ｗｅｂアプリを取得するためのＵＲＬに接続した情報処理装置であればどの情報処理装置の画面であっても、Ｗｅｂアプリが取得し、Ｗｅｂアプリが指定する外部装置へ送信できてしまうこととなり、セキュリティ上好ましくないＷｅｂアプリとなってしまうおそれがあるためである。
【００１３】
そこで、本実施形態では、全体画面４３の取り込みが可能な補助アプリ１３（第三のアプリケーションの一例）が用意される。補助アプリ１３は情報処理装置１０で動作するネイティブアプリ（Ｗｅｂアプリでない）であるので全体画面４３を取り込むことができる。補助アプリ１３はＯＳ１４（Operating System）に全体画面４３の取り込みを要求して、ホワイトボードアプリから通知されたファイルパス（保存場所指定情報の一例）に画像データを保存することができる。
【００１４】
しかしながら、補助アプリ１３を利用しても次のような不都合がある。すなわち、一般に、ＯＳ１４上の異なるアプリは互いに通信することができない。したがって、ホワイトボードアプリと補助アプリ１３は通信できず、ホワイトボードアプリはファイルパス（を補助アプリ１３に通知することもできない。なお、ファイルパスは論理的なファイルの位置を示すものであればよく、情報処理装置内の特定のファイルの位置を示してもよいし、補助アプリ１３をサーバとして機能させ、ファイルをサーバ上におき、サーバ上のファイルの位置を示すＵＲＬを指定するものでもよい。
【００１５】
ＯＳ１４によってはプロセス間通信なども可能であるが、動作が不安定になるなどのデメリットの方が大きいため、汎用的な情報処理装置１０で動作するＯＳ１４ではアプリ同士の任意の通信は困難である。
【００１６】
そこで、本実施形態では、ＯＳ１４が提供するカスタムＵＲＩスキームという仕組みを使用して、ホワイトボードアプリがファイルパスを補助アプリ１３に通知する。カスタムＵＲＩスキームについては後述する。
【００１７】
以上の構成による情報処理装置１０の動作の概略を説明する。
（１）ユーザが資料表示アプリの画面４１を取り込む場合、取り込みボタン４０７を押下する。
（２）ホワイトボードアプリはカスタムＵＲＩスキームを使用して、補助アプリ１３を起動すると共にファイルパスを通知する。
（３）補助アプリ１３は全体画面４３の取り込みをＯＳ１４に要求する。ＯＳ１４は全体画面４３を取り込んで画像データ（第一の画像データの一例）を補助アプリ１３に返す。補助アプリ１３はＯＳ１４から取得した資料表示アプリの表示範囲を取得してトリミングを行い資料表示アプリの画面４１の画像データ（第二の画像データの一例）を作成する。
（４）補助アプリ１３はファイルパスで指示された画像保存場所３６に資料表示アプリの画面４１の画像データを保存する。
（５）ホワイトボードアプリは画像保存場所３６から資料表示アプリの画面４１の画像データを取得してサーバに送信する。これにより、サーバは資料表示アプリの画面４１の画像データを含む画面情報を生成してホワイトボードアプリに送信するので、各拠点のホワイトボードアプリが、資料表示アプリの画面４１の画像データを共有することができる。
【００１８】
このように、本実施形態の情報処理装置１０は、補助アプリ１３及びカスタムＵＲＩスキームを使用すること等により、ホワイトボードアプリと共に表示装置に表示されている資料表示アプリの画面４１を取り込んで表示することができる。なお、ホワイトボードアプリの画面４２は表示装置に表示されていなくても、資料表示アプリの画面４１の画像データの共有は可能である。
【００１９】
＜用語について＞
表示装置とは画像を表示する装置である。ディスプレイと呼ばれる場合がある。また、表示装置はプロジェクタでもよい。
【００２０】
表示範囲に関する情報とは、表示装置においてアプリの画面が占める範囲を特定、指定、識別、又は、推定する情報である。本実施形態ではウィンドウ情報という用語で説明される。
【００２１】
画像データを切り取るとは、画像データを分割したり一部を切り抜いたりして画像の一部を取ることをいう。トリミングと称する場合がある。
【００２２】
ホワイトボードアプリはプログラムであり、ホワイトボードはホワイトボードアプリにより実現される機能又はホワイトボードアプリが表示する画面である。ただし、ホワイトボードアプリとホワイトボードはほぼ一体でありこれらを明確に区別しない場合がある。
【００２３】
＜システム構成例＞
図２は、本実施形態の通信システム１００の概略構成図の一例である。通信システム１００は、ネットワークＮを介して通信可能な情報端末１０Ａ、情報端末１０Ｂ、及び、サーバ５０を有する。情報端末１０Ａと情報端末１０Ｂは図１で説明した情報処理装置１０の一例である。したがって、図２では、２台の情報処理装置１０が図示されているが、情報処理装置１０は１台以上あればよい。また、情報処理装置１０は３台以上あっても支障がない。
【００２４】
情報端末１０Ａと情報端末１０Ｂはタッチパネルを備える。情報端末１０Ａのタッチパネルは比較的、大画面であり、情報端末１０Ｂのタッチパネルは比較的小さいが、どちらも指、ペンなどでユーザが手書きできるという点では同じである。情報端末１０Ａと情報端末１０Ｂのタッチパネルのサイズは同じでもよく、図２は一例に過ぎない。また、大画面では大画面に適した方式のタッチパネルが搭載されてよく、タッチパネルはどのような方式を採用してもよい。
【００２５】
情報端末１０Ａ、１０Ｂは、汎用的な情報処理装置でよく、例えば、タブレット端末、スマートフォン、ノートＰＣ（Personal Computer）、ＰＤＡ（Personal Digital Assistant）、などであるが、これらには限られない。また、情報処理装置１０の１つ以上が電子ボード、情報ボード、又は電子ホワイトボード等でもよい。
【００２６】
本実施形態の情報処理装置１０はこのようにタッチパネルを有することで、ユーザが指やペンで手書きできるため利便性が向上するが、一般的な情報処理装置１０では、ユーザはマウスで手書きすることもできるため、タッチパネルは必ずしも必須ではない。以下では、指、ペン、又はマウスを区別しない場合にポインティングデバイスという場合がある。
【００２７】
サーバ５０は、各情報処理装置１０に画面情報を送信するＷｅｂサーバ（又はＨＴＴＰサーバ）としての機能を有する１つ以上の情報処理装置である。更に、サーバ５０は情報処理装置１０が実行するＷｅｂアプリを提供する。Ｗｅｂアプリとは、Ｗｅｂブラウザ上で動作するスクリプト言語（たとえばJavaScript（登録商標））によるプログラムとＷｅｂサーバ側のプログラムが協調することによって動作し、ブラウザ上で使用されるソフトウェア又はその仕組みを言う。
【００２８】
サーバ５０は、一方の情報処理装置１０が送信する手書き情報により画面情報を生成し、この画面情報を各情報処理装置１０に送信する。これにより、ユーザは情報処理装置１０でホワイトボードアプリを動作させれば、他の拠点の情報処理装置１０と手書き情報を共有できる。ホワイトボードアプリはＷｅｂアプリであるため、Ｗｅｂブラウザが動作する情報処理装置１０であれば情報の共有が可能になる。
【００２９】
なお、サーバ５０はクラウドコンピューティングに対応していてよい。クラウドコンピューティングとは、特定ハードウェア資源が意識されずにネットワーク上のリソースが利用される利用形態をいう。
【００３０】
ネットワークＮは、ファイヤウォールの内側にある１つ以上のＬＡＮでもよいし、ＬＡＮに加えてファイヤウォールの外側にあるインターネットを含んでもよい。この他、ＶＰＮ（Virtual Private Network）や広域イーサネット（登録商標）が含まれていてもよい。ネットワークＮは有線又は無線のどちらで構築されてもよく、また、有線と無線が組み合わされていてもよい。また、３Ｇ、ＬＴＥ（Long Term Evolution）、４Ｇなどの携帯電話網により接続される場合、ＬＡＮはなくてもよい。
【００３１】
＜ハードウェア構成例＞
＜＜情報端末＞＞
図３を用いて、本実施形態の情報端末１０Ａ、１０Ｂのハードウェア構成を説明する。図３は、情報端末１０Ａ、１０Ｂのハードウェア構成図である。
【００３２】
図３に示されているように、情報端末１０Ａ、１０Ｂは、情報端末１０Ａ、１０Ｂの全体の動作を制御するＣＰＵ１０１、ＩＰＬ等のＣＰＵ１０１の駆動に用いられるプログラムを記憶したＲＯＭ１０２、ＣＰＵ１０１のワークエリアとして使用されるＲＡＭ１０３、情報端末１０Ａ、１０Ｂ用のプログラム等の各種データを記憶するＳＳＤ１０４、ネットワークＮとの通信を制御するネットワークコントローラ１０５、及び、ＵＳＢメモリ５との通信を制御する外部記憶コントローラ１０６を備えている。
【００３３】
また、情報端末１０Ａ、１０Ｂは、グラフィクスを専門に扱うＧＰＵ(Graphics Processing Unit)１１２、及び、ＧＰＵからの出力画像をディスプレイ３に出力するために画面表示の制御及び管理を行うディスプレイコントローラ１１３を備えている。
【００３４】
更に、情報端末１０Ａ、１０Ｂは、接触センサ１１５の処理を制御するセンサコントローラ１１４、ディスプレイ３上に電子ペン４やユーザの手Ｈ等が接触したことを検知する接触センサ１１５を備えている。この接触センサ１１５は例えば静電容量の変化でユーザが触れた座標の検出を行う（タッチパネルを実現する）。接触センサ１１５としては、静電容量の変化を検知する方法に限られず、対向する２の抵抗膜の電圧変化によって接触位置を特定する抵抗膜方式のタッチパネル、接触物体が表示部に接触することによって生じる電磁誘導を検知して接触位置を特定する電磁誘導方式のタッチパネルなどの種々の検出手段を用いてもよい。
【００３５】
更に、情報端末１０Ａ、１０Ｂは、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、ＳＳＤ１０４、ネットワークコントローラ１０５、外部記憶コントローラ１０６、キャプチャデバイス１１１、ＧＰＵ１１２、センサコントローラ１１４、及び電子ペンコントローラ１１６を、電気的に接続するためのアドレスバスやデータバス等のバスライン１２０を備えている。
【００３６】
なお、情報端末１０Ａ、１０Ｂ用のプログラムは、ＣＤ−ＲＯＭ等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよいし、プログラム配信用のサーバから配信されてもよい。
【００３７】
＜＜サーバ＞＞
図４は、サーバ５０の概略的なハードウェア構成図の一例である。サーバ５０は、ＣＰＵ２０１と、ＣＰＵ２０１が使用するデータの高速アクセスを可能とするメモリ２０２とを備える。ＣＰＵ２０１及びメモリ２０２は、システム・バス２０３を介して、サーバ５０の他のハードウェア要素、例えば、グラフィックス・ドライバ２０４及びネットワーク・ドライバ（ＮＩＣ）２０５へと接続されている。
【００３８】
グラフィックス・ドライバ２０４は、バスを介してＬＣＤ２０６に接続されて、ＣＰＵ２０１による処理結果をモニタする。また、ネットワーク・ドライバ２０５は、トランスポート層レベル及び物理層レベルでサーバ５０をネットワークＮへと接続して、情報処理装置１０とのセッションを確立させている。
【００３９】
システム・バス２０３には、更にＩ／Ｏバス・ブリッジ２０７が接続されている。Ｉ／Ｏバス・ブリッジ２０７の下流側には、ＰＣＩなどのＩ／Ｏバス２０８を介して、ＩＤＥ、ＡＴＡ、ＡＴＡＰＩ、シリアルＡＴＡ、ＳＣＳＩ、ＵＳＢなどにより、ＨＤＤ（ハードディスクドライブ）２０９などの記憶装置が接続されている。ＨＤＤ２０９はサーバ５０の全体を制御するプログラム２０９ｐを記憶している。ＨＤＤ２０９はＳＳＤ（Solid State Drive）でもよい。
【００４０】
また、Ｉ／Ｏバス２０８には、ＵＳＢなどのバスを介して、キーボード及びマウス（ポインティング・デバイスと呼ばれる）などの入力装置２１０が接続され、システム管理者などのオペレータによる入力及び指令を受け付けている。
【００４１】
なお、図示したサーバ５０のハードウェア構成は、１つの筐体に収納されていたりひとまとまりの装置として備えられていたりする必要はなく、サーバ５０が備えていることが好ましいハード的な要素を示す。また、クラウドコンピューティングに対応するため、本実施例のサーバ５０の物理的な構成は固定的でなくてもよく、負荷に応じてハード的なリソースが動的に接続・切断されることで構成されてよい。
【００４２】
＜ソフトウェア構成例＞
続いて、図５を用いて情報処理装置１０のソフトウェア構成について説明する。図５は、情報処理装置１０で動作するソフトウェア構成の一例である。情報処理装置１０ではＯＳ１４が動作し、ＯＳ１４上で資料表示アプリ１１、ホワイトボードアプリ１２、及び、補助アプリ１３が動作している。
【００４３】
ＯＳ１４は、例えば、Ａｎｄｒｏｉｄ（登録商標）、ｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）、ｍａｃＯＳ（登録商標）等である。ただし、これらには限られない。また、情報処理装置１０の機種によって異なってよい。
【００４４】
資料表示アプリ１１は、例えば会議の資料を表示するアプリである。資料表示アプリ１１は会議に参加している複数の情報処理装置１０のうち１台以上で動作していればよい。資料表示アプリ１１の資料は共有されるためである。何を資料とするかはユーザの属性や状況によって様々であるため、資料表示アプリ１１はＯＳ１４上で動作して何らかの画面を表示するアプリであればよい。例えば、会議では、プレゼンテーションアプリが資料表示アプリ１１となりうる。また、インターネット上の情報を表示できるＷｅｂブラウザ、文書を編集又は表示するワープロアプリ、表計算アプリなども資料表示アプリ１１となりうる。更に、写真を表示する写真アプリ、ローカルゲームやオンラインゲームなどのゲームアプリ、ユーザが絵を描くためのペイントアプリ、及び、ファイル管理アプリなども資料表示アプリ１１となりうる。なお、これらの資料表示アプリ１１は一例であってこれらには限られない。
【００４５】
Ｗｅｂブラウザ１５がこのＷｅｂブラウザ１５で動作するスクリプトを実行するとことでホワイトボードアプリ１２が実現される。ホワイトボードアプリ１２はホワイトボードの機能をユーザに提供するＷｅｂアプリである。上記のように、資料表示アプリ１１の画面の画像データを表示する機能を有する。なお、資料表示アプリ１１の画面の画像データを表示する機能を有すれば、ホワイトボードアプリ１２がホワイトボードの機能を有していなくてもよい。つまり、ホワイトボードアプリ１２は情報処理装置１０で動作するＷｅｂアプリであればよい。
【００４６】
補助アプリ１３は、ホワイトボードアプリ１２が資料表示アプリ１１の画面の画像データを表示するための補助的な機能を提供する。主にＷｅｂアプリであるホワイトボードアプリでは困難な処理を行う。例えば、ＯＳ１４のＡＰＩ（Application Interface）を呼び出すような機能又は処理である。なお、資料表示アプリ１１が任意のアプリでよいのに対し、補助アプリ１３はホワイトボードアプリ１２と同じ又は関連がある開発メーカにより開発されることが想定される。よって、補助アプリ１３とホワイトボードアプリ１２とが連携することが可能になる。
【００４７】
ホワイトボードアプリ１２はＷｅｂブラウザ１５をベースに動作するため情報処理装置１０の機種への依存性が少ないのに対し、補助アプリ１３はＯＳ１４と連携して資料表示アプリ１１の画面の画像データを取得するため、機種への依存が強い機能を受け持つ。したがって、補助アプリ１３はネイティブアプリである。ネイティブアプリはＷｅｂアプリに対比して使用される用語であるが、情報処理装置１０にインストールされて実行されるアプリであって、ＯＳ１４の機能を利用し、また、ハードウェア制御が可能なアプリをいう。
【００４８】
これに対し、ホワイトボードアプリ１２はＷｅｂアプリであり、サーバ５０から送信されスクリプトの実行により動作するのでインストールが不要である。一方、ＷｅｂアプリはＯＳ１４の機能を利用したりハードウェアを制御したりすることは困難な場合が多い。
【００４９】
本実施形態の補助アプリ１３は、内部で動作すればよいため原則的に画面を表示しない。通常は画面を表示しないことで、情報処理装置１０の表示装置（ディスプレイ３又はＬＣＤ２０６）の広さを有効に活用できる。また、ユーザが補助アプリ１３を意識する必要がない。ユーザが補助アプリ１３の動作の設定を行う際には例外的に補助アプリ１３が何らかの画面を提供してもよい。
【００５０】
＜機能について＞
続いて、図６を用いて、ホワイトボードアプリ１２、補助アプリ１３、及び、サーバ５０が有する機能について説明する。図６は、情報処理装置１０及びサーバ５０が有する機能をブロック状に示す機能ブロック図の一例である。
【００５１】
図６では、サーバ５０、ホワイトボードアプリ１２、ＯＳ１４、及び、補助アプリ１３の機能を示す。資料表示アプリ１１は画面を表示する機能を有すればよいため、その機能は必要に応じて説明する。
【００５２】
＜＜ホワイトボードアプリ＞＞
ホワイトボードアプリ１２は、表示制御部２１、通信部２２、ストローク生成部２３、操作受付部２４、画像取得部２５、及び、取込指示部２６を有する。情報処理装置１０が有するこれら各部は、図３に示されている各構成要素のいずれかが、ＳＳＤ１０４からＲＡＭ１０３上に展開されたプログラム及びサーバ５０から送信されたスクリプトに従ったＣＰＵ１０１からの命令によって動作することで実現される機能又は手段である。
【００５３】
通信部２２は、サーバ５０と各種の情報を送受信する。例えば、ＨＴＭＬ、ＣＳＳ（Cascade Style Sheet）、及び、JavaScript（登録商標）で記述された画面情報をサーバ５０から受信する。また、ユーザが手書きして入力した手書き情報をサーバ５０に送信する。
【００５４】
操作受付部２４は、ホワイトボードアプリ１２に対するユーザの各種の操作を受け付ける。例えば、メニューに表示されるボタンの押下、又は、タッチパネルに対する手書き情報を受け付ける。
【００５５】
取込指示部２６は、操作受付部２４からの通知により、ユーザが資料表示アプリ１１の画面の取り込みボタン４０７を押下したことを検出し、ＯＳ１４を介して補助アプリ１３に画像の取り込みを指示する。指示にはカスタムＵＲＩスキームが利用される。また、この時、取込指示部２６は画像保存場所３６を指し示すファイルパスを補助アプリ１３に通知する。ＯＳ１４は補助アプリ１３を起動させ、ファイルパスを補助アプリ１３に通知する。起動した補助アプリ１３はＯＳ１４と連携して資料表示アプリ１１の画面の取り込みを行う。
【００５６】
ストローク生成部２３は、操作受付部２４が受け付けたタッチパネルに対する手書き情報に基づいてストロークを生成する。操作受付部２４が受け付ける手書き情報は、点の座標のリストなので、このまま表示しても複数の点が表示されるに過ぎない。このため、ストローク生成部２３は、ユーザが指定した色、太さ、線種などで点を連結してストロークを生成する。
【００５７】
表示制御部２１は、通信部２２が受信した画面情報を解析して表示装置（ディスプレイ３又はＬＣＤ２０６）に表示する。また、ストローク生成部２３が生成したストロークを表示装置に表示する。
【００５８】
画像取得部２５は、ファイルパスで指定された画像保存場所３６から資料表示アプリ１１の画面の画像データを取得する。補助アプリ１３が画像データを画像保存場所３６に保存したことはホワイトボードアプリ１２に通知されないので、画像取得部２５は画像保存場所３６に対しポーリングすることで資料表示アプリ１１の画面の画像データを取得する。
【００５９】
画像保存場所３６は、情報処理装置１０が有する記憶手段である。例えば、図３のＲＡＭ１０３、ＳＳＤ１０４等である。ＵＳＢメモリ、ＳＤメモリなどの可搬型の記憶手段でもよい。また、画像保存場所３６はネットワーク上のストレージでもよい。
【００６０】
＜＜補助アプリ＞＞
補助アプリ１３は、画像保存部３１、画面取込部３２、取込指示受付部３３、トリミング領域判断部３４、及び、トリミング部３５を有する。情報処理装置１０が有するこれら各部は、図３に示されている各構成要素のいずれかが、ＳＳＤ１０４からＲＡＭ１０３上に展開されたプログラムに従ったＣＰＵ１０１からの命令によって動作することで実現される機能又は手段である。
【００６１】
取込指示受付部３３は、ホワイトボードアプリ１２の取込指示部２６からＯＳ１４を介して通知される取り込み指示を受け付ける。取り込み指示にはファイルパスが含まれるが、上記のように取り込み指示にはカスタムＵＲＩスキームが利用される。取込指示受付部３３は画面取込部３２に全体画面４３の取り込みを要求し、トリミング領域判断部３４にトリミング領域の判断を要求する。
【００６２】
画面取込部３２は、ＯＳ１４に対し表示装置（ディスプレイ３又はＬＣＤ２０６）の全体画面４３の取り込みを要求する。これにより、ＯＳ１４がホワイトボードアプリ１２の画面４２と資料表示アプリ１１の画面４１の両方の画面を含む画像データを画面取込部３２に返す。
【００６３】
トリミング領域判断部３４は、表示装置（ディスプレイ３又はＬＣＤ２０６）に表示されている各アプリの表示位置とサイズをＯＳ１４から取得する。ＯＳ１４はアプリの名称又はＩＤに対応付けてアプリの表示位置とサイズをトリミング領域判断部３４に出力する。トリミング領域判断部３４にとってホワイトボードアプリ１２の名称又はＩＤは既知であるので、ホワイトボードアプリ１２以外のアプリの表示位置とサイズにより、トリミング領域（切取領域）を判断する（決定する）。トリミング領域判断部３４はトリミング領域をトリミング部３５に送出する。なお、資料表示アプリが予め特定されていれば、資料表示アプリの表示領域を取得し、切り取ってもよい。
【００６４】
トリミング部３５は、画面取込部３２が取り込んだ全体画面４３の画像データから、トリミング領域判断部３４が通知したトリミング領域をトリミングする。これにより、全体画面４３の画像データから資料表示アプリ１１の画面４１だけをトリミングすることができる。なお、トリミングとは、画像の一部を切り取ること、又は取得することをいう。
【００６５】
画像保存部３１は、資料表示アプリ１１の画面の画像データをファイルパスで指定される画像保存場所３６に保存する。
【００６６】
＜＜サーバ＞＞
サーバ５０は通信部５１、ホワイトボード管理部５２、ホワイトボードデータ部５３、及び、オブジェクト合成部５４を有する。サーバ５０が有するこれら各部は、図４に示されている各構成要素のいずれかが、ＨＤＤ２０９からメモリ２０２に展開されたプログラムに従ったＣＰＵ２０１からの命令によって動作することで実現される機能又は手段である。
【００６７】
通信部５１は、情報処理装置１０と各種の情報を送受信する。例えば、ＨＴＭＬ、ＣＳＳ、及び、JavaScript（登録商標）で記述された画面情報を情報処理装置１０に送信する。また、ユーザが手書きして入力した手書き情報を情報処理装置１０から受信する。
【００６８】
ホワイトボード管理部５２は、ホワイトボードに関する管理を行う。まず、ホワイトボード管理部５２は、ホワイトボードの生成、及び、消滅を行う。例えば、情報処理装置１０から新しいホワイトボードを生成する要求があると、ホワイトボードを生成する。説明を容易にするため、１つのＵＲＬが１つのホワイトボードに対応するものとすると、新たなＵＲＬを会議に割り当て、ホワイトボードのための画面情報を生成することでホワイトボードを生成する。
【００６９】
また、ホワイトボード管理部５２は、例えば上記ＵＲＬへのアクセスを受け付けた際に接続元のＩＰアドレスを記憶しておいたり、サーバ５０へのログイン時等に接続元のＩＰアドレスを記憶しておいたりする。そして、これら各情報処理装置１０のＩＰアドレスを、ホワイトボードのＵＲＬに対応付けて保持しておく。１つの会議には少なくとも１つのホワイトボードが生成され、ホワイトボードのＵＲＬに接続した情報処理装置１０に同じホワイトボードが表示される。サーバ５０の通信部５１は、ホワイトボードのＵＲＬに対応付けられているＩＰアドレスの情報処理装置１０に対し同じ画面情報（手書き情報を含む）を送信する。
【００７０】
また、情報処理装置１０からホワイトボードを削除する要求があると、ホワイトボード管理部５２はホワイトボードを削除する。
【００７１】
なお、ホワイトボード管理部５２は、ホワイトボードのＵＲＬと情報処理装置１０のＩＰアドレスに加え、情報処理装置１０のユーザを特定するユーザＩＤを対応付けて管理してもよい。例えば、会議毎にホワイトボードを用意するような場面では、会議毎に当該ホワイトボードにアクセスするためのＵＲＬがサーバ５０にて生成される。ここで、会議とユーザＩＤを紐付けておくと、ユーザＩＤを受け付けた場合に、ユーザＩＤに対応する会議のＵＲＬを提示し、会議に応じたホワイトボードにアクセス可能となる。ユーザＩＤはユーザを識別又は特定するための識別情報である。ＩＤはIdentificationの略であり識別子や識別情報という意味である。ＩＤは複数の対象から、ある特定の対象を一意的に区別するために用いられる名称、符号、文字列、数値又はこれらのうち１つ以上の組み合わせをいう。以下のＩＤについても同様である。あるいは、通信元を識別するという意味で通信ＩＤを対応付けて管理してもよい。
【００７２】
ホワイトボードデータ部５３は、１つのホワイトボードごとにデータを管理する。データはホワイトボードに表示されるデータであるため、例えば、手書き情報、テキストメモ、及び、画像データ等である。これらの内容と表示位置がホワイトボードごとに管理されている。
【００７３】
オブジェクト合成部５４は、ホワイトボードデータ部５３が管理するデータを用いて画面情報を生成する。例えば、複数のストロークが重なっている場合、複数のストロークを１つのオブジェクトに合成する。こうすることで、拡大、縮小、回転などに対し画像の品質がよくなる。
【００７４】
ホワイトボードに好適なＨＴＭＬ要素としてＣａｎｖａｓ要素がある。Ｃａｎｖａｓ要素は、JavaScript（登録商標）によるスクリプティングによって図形などを描画するために使用される。オブジェクト合成部５４は、ホワイトボードデータ部５３のデータを監視して、追加されるごとに画面情報を生成する。通信部５１は新しい画面情報が生成されると会議に参加している各情報処理装置１０に送信するので、ほぼリアルタイムにホワイトボードアプリ１２で表示されるデータを共有できる。
【００７５】
＜カスタムＵＲＩスキーム＞
続いて、カスタムＵＲＩスキームについて説明する。カスタムＵＲＩスキームはＵＲＩスキームをカスタム化したものである。ＵＲＩスキームは、インターネット上の資源の所在を表すＵＲＩ(又はＵＲＬでもよい)の先頭部分で、資源に到達するための手段を表す表記法である。通常は、ＵＲＩとしてhttp、file、mailtoなどの予約語が指定される。これに対し、カスタムＵＲＩスキームは、任意のＵＲＩで資源を表すことができる。
【００７６】
図７は、本実施形態のカスタムＵＲＩスキームを説明する図の一例である。図７では一例としてＯＳ１４がAndroid（登録商標）の場合を説明する。まず、図７（ａ）は補助アプリ１３のマニフェストの一例である。マニフェストとは、そのアプリの名前、アイコン、及び機能等について様々な情報が記載されたファイルである。マニフェストはＸＭＬで記述されている。ＸＭＬで記載された<intent−filter>タグの１〜３行までは記載形式が決まっている定型文である。４行目の記述がカスタムＵＲＩスキームによりＯＳ１４が補助アプリ１３を起動するための記述である。
【００７７】
<data android:scheme="subapp" android:host="filepath" />
という記載のうち「subapp」が補助アプリ１３を指定し（補助アプリ１３の識別情報）、「filepath」が補助アプリ１３に通知される情報の名前を示す。
【００７８】
図７（ｂ）はカスタムＵＲＩスキームの一例を示す。
subapp://filepath?id=/foo/bar/001/001.jpg
先頭の「subapp」が補助アプリ１３を指定し、「filepath」に続く「id=/foo/bar/001/001.jpg」が、補助アプリ１３に通知される情報が「filepath」という変数に含まれ、変数の値は「/foo/bar/001/001.jpg」であることを指定する。
【００７９】
カスタムＵＲＩスキームを用いてホワイトボードアプリ１２が補助アプリ１３を起動してファイルパスを通知する手順は以下のようになる。
（１）ホワイトボードアプリ１２の取込指示部２６は図７（ｂ）のカスタムＵＲＩスキームをＯＳ１４に通知する。
（２）ＯＳ１４はカスタムＵＲＩスキームの「subapp」で指定されるアプリを各アプリのマニフェストから検索し補助アプリ１３を特定する。
（３）補助アプリ１３を特定できるとＯＳ１４は補助アプリ１３の実行ファイルを実行することで補助アプリ１３を起動する。
（４）補助アプリ１３の取込指示受付部３３は起動時にＯＳ１４からカスタムＵＲＩスキームを取得する処理を行う。
（５）取込指示受付部３３は引き続き、カスタムＵＲＩスキームの「id」以下のファイルパスを取得する。
【００８０】
このようにしてホワイトボードアプリ１２はＯＳ１４を介して補助アプリ１３を起動させ、補助アプリ１３はファイルパスを取得できる。なお、補助アプリ１３は起動すると明示的な取り込み指示がなくても（自動的に）全体画面４３の取り込みを開始する。したがって、カスタムＵＲＩスキームが取り込み指示に相当する。あるいは、ホワイトボードアプリ１２がＯＳ１４を介して明示的な取り込み指示を補助アプリ１３に通知してもよい。
【００８１】
＜動作手順＞
続いて、図８を用いて通信システム１００の全体的な動作手順を説明する。図８は、ホワイトボードアプリ１２と補助アプリ１３が資料表示アプリ１１の画面の画像データを取り込む手順を示すシーケンス図の一例である。図８の処理は、ユーザが会議を行う際に開始される。
【００８２】
会議に先立って、まず、ユーザはホワイトボードアプリ１２を起動する操作を情報処理装置１０に対して行う。情報処理装置１０を操作するユーザはサーバ５０へのログイン操作を行ってもよい。
【００８３】
なお、本実施形態の説明においては情報処理装置１０が宛先の情報処理装置１０と通信することは必要でない。情報処理装置１０がサーバ５０と通信できれば、情報処理装置１０は資料表示アプリ１１の画面を取り込んで自機のホワイトボードアプリ１２で表示できる。
【００８４】
S1：ユーザがサーバ５０にログインすると、ホワイトボードアプリ１２を操作してホワイトボードを新規に作成する操作を行う。つまり、例えば会議で使用されるホワイトボードを作成する。ただし、１つの会議で複数のホワイトボードを作成することも可能である。
【００８５】
S2.1：ホワイトボードアプリ１２の通信部２２はホワイトボードの作成をサーバ５０に要求するためのＵＲＬにアクセスする。例えば、ＨＴＴＰでサーバ５０の所定のリソースにアクセスすることでホワイトボード作成要求を送信する。サーバ５０に要求するためのＵＲＬの一例を以下に示す。
http://server/kaigi/createKaigi
なお、ホワイトボードの作成要求は会議の作成依頼というような形でもよい。
【００８６】
S2.1.1：サーバ５０の通信部５１はホワイトボード作成要求を受信して、ホワイトボード管理部５２がホワイトボードを新規に作成する。ホワイトボード管理部５２は例えば会議で使用されるホワイトボードを作成する。作成されるのは、言うまでもなく物理的に存在するホワイトボードでなはく、サーバ５０上に作成される仮想的なホワイトボードである。例えば、Ｃａｎｖａｓ要素とJavaScript（登録商標）等によって、ユーザが手書き情報を書き込んだり、画像を表示したりする機能のＷｅｂアプリがホワイトボードに相当する。
【００８７】
ホワイトボードは１つ以上の情報処理装置１０がアクセスできるように所定のＵＲＬに作成される。ホワイトボードのＵＲＬの一例を以下に示す。このＵＲＬの「k001」は会議ＩＤである。
http://server/kaigi/k001
ホワイトボード管理部５２は会議に参加している情報処理装置１０のＩＰアドレスとホワイトボードのＵＲＬを対応付けて管理する。サーバ５０の通信部５１はホワイトボードのＵＲＬをホワイトボードアプリ１２に送信する。なお、サーバ５０の通信部５１はホワイトボードのＵＲＬを同じ会議に参加している他の情報処理装置１０にも送信する。
【００８８】
S3：ホワイトボードアプリ１２の通信部２２はホワイトボードのＵＲＬを受信すると、ホワイトボードのＵＲＬに対し通信を開始する。これにより、ホワイトボードアプリ１２はこのＵＲＬからＣａｎｖａｓ要素とJavaScript（登録商標）を含む画面情報を取得する。すなわち、Ｃａｎｖａｓ要素とJavaScript（登録商標）を含む画面情報を取得することでホワイトボードアプリ１２（Ｗｅｂアプリ）としての機能を実装する。新規に作成されたホワイトボードは、真っ白な画面と取り込みボタン４０７等を有するメニューを有する。このメニューの一例を図１０に示す。メニューは、Ａｎｄｒｏｉｄ（登録商標）のシステムレイヤ上に描画される。通常のＡｎｄｒｏｉｄアプリ（ネイティブアプリやＷｅｂブラウザ）よりも高いレイヤで表示される。
【００８９】
なお、図８の説明では、ユーザが新規にホワイトボードを作成する手順を説明したが、ユーザは既存のホワイトボードを再利用することもできる。このような使い方をするためには、ホワイトボードが情報処理装置１０のＩＰアドレスだけでなくユーザＩＤ（又は通信ＩＤ）と対応付けられていることが好ましい。ホワイトボード管理部５２はログインしたユーザのユーザＩＤ（又は通信ＩＤ）が対応付けられているホワイトボードのＵＲＬのリストを、情報処理装置１０に提供するので、ユーザは自分が再開したいホワイトボードのＵＲＬ（ユーザから見ると会議に相当する）を選択できる。ユーザが選択したホワイトボードのＵＲＬは、同じ会議に参加している他の情報処理装置１０にも送信されるので、会議に参加している各ユーザは同じホワイトボードを共有することで会議を再開することができる。
【００９０】
S4：会議の間、ユーザは資料表示アプリ１１で資料を表示し、この資料を共有したい又はホワイトボードに貼り付けておきたいと考えたものとする。ユーザはホワイトボードアプリ１２が表示する取り込みボタン４０７を押下する。ホワイトボードアプリ１２の操作受付部２４は取り込みボタン４０７の押下を受け付ける。以降は、図７で説明した手順が実行される。まず、表示装置（ディスプレイ３又はＬＣＤ２０６）の全体画面４３の画像データが取り込まれる。
【００９１】
S4.1：ホワイトボードアプリ１２の取込指示部２６はカスタムＵＲＩスキームをＯＳ１４に通知することで補助アプリ１３を起動させると共に、ファイルパスを補助アプリ１３に通知する。なお、図８では、ホワイトボードアプリ１２、補助アプリ１３、及びＯＳ１４が通信する処理については省略されている。
【００９２】
S4.1.1：補助アプリ１３の取込指示受付部３３は画面取込部３２に画面の取り込みを要求する。これにより画面取込部３２はＯＳ１４のＡＰＩを呼び出して、全体画面４３の取り込みを要求する。例えば、Ａｎｄｒｏｉｄ（登録商標）では、MediaProjectionAPIというＡＰＩにより、全体画面４３を取り込むことができる。画面取込部３２はＯＳ１４から全体画面４３の画像データを取得する。
【００９３】
S4.1.2：ＯＳ１４から取得した画像データにはホワイトボードアプリ１２の画面も含まれるため、補助アプリ１３の取込指示受付部３３はトリミング領域判断部３４に資料表示アプリ１１の画面４１だけをトリミングするためのトリミング領域の判断を要求する。トリミング領域判断部３４はＯＳ１４に対しアプリのウィンドウ情報を要求する。アプリのウィンドウ情報とは、ＯＳ１４上で動作しているアプリのウィンドウの表示位置とサイズの情報である。アプリのウィンドウ情報の一例を図９に示す。これにより、トリミング領域判断部３４はアプリのウィンドウ情報を取得する。
【００９４】
S4.1.3：トリミング領域判断部３４はトリミング領域をトリミング部３５に送出するので、トリミング部３５は画面取込部３２が取り込んだ全体画面４３の画像データから、トリミング領域をトリミングする。これにより、資料表示アプリ１１の画面４１のみが含まれる画像データが得られる。
【００９５】
なお、画像データのファイルフォーマットのデフォルトがＢＭＰ（ビットマップ）のように容量が大きい場合、情報処理装置１０とサーバ５０間の送信負荷を考慮して、画像保存部３１は資料表示アプリ１１の画面の画像データをＪＰＥＧにエンコード（圧縮）してもよい。
【００９６】
S4.1.5：画像保存部３１は、取込指示受付部３３が受け付けたファイルパスにしたがって画像保存場所３６に資料表示アプリ１１の画面４１の画像データを保存する。
【００９７】
S4.2 S4.3：ホワイトボードアプリ１２の画像取得部２５は画像保存場所３６に対し繰り返し、画像データの取得を試みる。これは、画像取得部２５は、どのタイミングで画像データが画像保存場所３６に保存されるかを知ることが困難なためである。画像取得部２５には取込指示部２６からファイルパスが通知されるので、画像取得部２５は画像保存場所３６のファイルパスにファイル（画像データ）が保存されるまでポーリングする。例えば、ステップS4.2では画像データの読み込みに失敗し、ステップS4.3では成功している。なお、ファイルパスには画像データのファイル名が含まれるため、画像取得部２５は一意に画像データのファイルを特定できる。
【００９８】
S4.4：画像取得部２５が画像データを取得すると、ホワイトボードアプリ１２の通信部２２はステップS2.1.1で通知されたホワイトボードのＵＲＬ（会議のＵＲＬ）に対し、画像データを送信する。ここで、通信部２２は画像データのホワイトボードにおける表示位置を画像データと共に送信することが好ましい。ホワイトボードは縦横にスクロールできるため、画像データが貼り付けられた位置によっては、表示装置（ディスプレイ３又はＬＣＤ２０６）の表示範囲外に表示されるおそれがあるためである。例えば、現在、情報処理装置１０が表示装置（ディスプレイ３又はＬＣＤ２０６）に表示しているホワイトボードの表示範囲の左上コーナーを画像データの表示位置とする。あるいは、ホワイトボードの表示範囲に含まれる座標を画像データの表示位置とする。これらにより、サーバ５０が画面情報を情報処理装置１０に送信した際に、資料表示アプリ１１の画像データがホワイトボードアプリの画面４２に表示される。
【００９９】
なお、資料表示アプリ１１の画面を取り込んでいない他の拠点の情報処理装置１０は（画像データを受信するだけの情報処理装置１０）、表示装置（ディスプレイ３又はＬＣＤ２０６）に表示しているホワイトボードの表示範囲が、資料表示アプリ１１の画面を取り込んだ情報処理装置１０と同じとは限らないため、資料表示アプリ１１の画面の画像データが表示されるとは限らない。この場合、他方の情報処理装置１０のユーザはホワイトボードをスクロールすることで資料表示アプリ１１の画面４１の画像データを表示させることができる。
【０１００】
なお、画像データがホワイトボードアプリの画面４２に表示された後でも、Ｃａｎｖａｓ要素では、画像データの表示位置を任意のユーザがホワイトボードアプリ１２上で変更できる。この場合、最後に変更された表示位置がサーバ５０に送信され、各情報処理装置１０に反映される。
【０１０１】
また、画像データの表示位置をユーザが変更できるため、サーバ５０が表示位置を任意に決定してもよい。この場合、ホワイトボードアプリ１２は表示位置をサーバ５０に送信しなくてよい。
【０１０２】
また、資料表示アプリ１１の画面４１の画像データを複数の情報処理装置１０で共有しないのであれば、情報処理装置１０は画像データをサーバに送信しなくてもよい。ホワイトボードアプリ１２は画像保存場所３６に保存されたローカルファイルを読み込んで、表示装置（ディスプレイ３又はＬＣＤ２０６）に表示することができる。
【０１０３】
また、ホワイトボードアプリ１２の通信部２２は送信に成功したら（例えば、ＨＴＴＰのステイタスの２００を受信したら）、画像取得部２５にその旨を通知し、画像取得部２５は画像保存場所３６の画像データ（ＢＭＰ、ＪＰＥＧの両方）を削除する。これにより、メモリ領域を解放することができる。
【０１０４】
S4.4.1：サーバ５０の通信部５１は画像データを受信する。ホワイトボードデータ部５３は、ホワイトボードのＵＲＬごとに画像データと表示位置を保存する。オブジェクト合成部５４は、ホワイトボードデータ部５３が新たなデータを保存したので、画面情報を生成する。例えば、表示位置を指定してＣａｎｖａｓに画像データを貼り付ける。
【０１０５】
S5：サーバ５０の通信部５１は画面情報の更新（ホワイトボードに画像を通知する例えばCanvasの変化通知）を送信する。通常のＨＴＴＰ通信はクライアントから通信を行うが、リアルタイムにホワイトボードを更新するため、サーバ５０からデータの送信を開始するWebSocket、ＡＪＡＸ（Asynchronous JavaScript + XML）、又は、ＣＯＭＥＴなどの通信方式が利用される。
【０１０６】
S5.1：ホワイトボードアプリ１２の通信部２２は更新された画面情報を受信し、表示制御部２１が画面情報に含まれる画像データをホワイトボードに表示する。
【０１０７】
以上のような処理で、資料表示アプリ１１の画面のみの画像データをホワイトボードアプリ１２が表示できる。ユーザは１回のボタン操作で資料表示アプリ１１の画面４１の画像データを他のユーザと共有できる。
【０１０８】
＜トリミング領域について＞
図９を用いてトリミング領域について補足する。図９（ａ）は、情報処理装置１０の表示装置（ディスプレイ３又はＬＣＤ２０６）に表示される画面の一例を示す。図９（ａ）では、資料表示アプリ１１の画面４１が左側に、ホワイトボードアプリ１２の画面４２が右側にそれぞれ表示されている。このような各アプリ１つ１つの画面をウィンドウという場合がある。
【０１０９】
ＯＳ１４は各ウィンドウの表示位置とサイズをウィンドウ情報としてリアルタイムに管理している。図９（ｂ）は各アプリのウィンドウ情報の一例を示す。資料表示アプリ１１の左上コーナーの座標は（０，２０）、ウィンドウ幅は５００ピクセル、ウィンドウ高さは５００ピクセルである。ホワイトボードアプリ１２の左上コーナーの座標は（５００，２０）、ウィンドウ幅は２００ピクセル、ウィンドウ高さは５００ピクセルである。
【０１１０】
トリミング領域判断部３４はこのようなウィンドウ情報に基づいてトリミング領域を判断する。トリミング領域判断部３４にはホワイトボードアプリ１２のアプリ名が設定されているので（補助アプリ１３にとってホワイトボードアプリ１２のアプリ名は既知）、ホワイトボードアプリ１２以外のアプリを特定する。図９（ｂ）では資料表示アプリ１１が特定される。トリミング領域判断部３４は資料表示アプリ１１のウィンドウ情報（表示位置、サイズ）をそのままトリミング領域に決定する。なお、ウィンドウ情報よりも少し小さめに又は大きめに決定してもよい。トリミングしたあと、ツールバーと思われる部分をきりとってもよい。また、右半分のウィンドウと左半分のウィンドウの間に境界線が表示されるような場合には、境界線部分を自動できりとるようにしてもよい。更に、Ｗｅｂブラウザ１５の表示領域に加えて、ＯＳが表示するツールバー等の表示領域もＯＳから取得し、このツールバーの表示領域を含まないように切り取ってもよい。
【０１１１】
資料表示アプリ１１の画面の表示位置が予め決まっている場合、補助アプリ１３はウィンドウ情報をＯＳ１４から取得しなくてもよい。例えば、表示装置（ディスプレイ３又はＬＣＤ２０６）の左半分に資料表示アプリ１１が表示され、残りの右半分にホワイトボードアプリ１２が表示されるような場合である。この場合、補助アプリ１３のトリミング部３５は全体画面４３の左半分を切り取ればよい。任意の表示位置が予め決まっている場合もトリミング部３５は容易に切り取ることができる。領域を指定するためのＵＩをユーザに提示し、ユーザから入力を受け付けて、トリミング領域を決定してもよい。
【０１１２】
図示するように、ウィンドウ情報は表示装置（ディスプレイ３又はＬＣＤ２０６）に表示されている範囲の表示位置とサイズであるが、ホワイトボードアプリ１２又は資料表示アプリ１１は表示装置の範囲外にも広がっている場合がある。つまり、表示されていない範囲（非表示範囲）がありうる。なお、ホワイトボードアプリ１２の広さは例えばＣａｎｖａｓにより設定されるため、事実上、無限とみなせる広さを有することも可能である。
【０１１３】
＜メニューについて＞
続いて、図１０を用いてホワイトボードアプリ１２が有するメニューについて補足する。図１０はホワイトボードアプリ１２が表示するメニュー４０１の一例を示す図である。メニュー４０１は、ペンボタン４０２、消しゴムボタン４０３、画面移動ボタン４０４、戻るボタン４０５、進むボタン４０６、取り込みボタン４０７、文字メモボタン４０８、業務アプリ連携ボタン４０９、及び、設定ボタン４１０を有する。
ペンボタン…手書き情報（ストローク）を描画するためのボタン
消しゴムボタン…手書き情報を消去するためのボタン
画面移動ボタン…ディスプレイ３に表示しきれていない範囲（ホワイトボードアプリ１２は理論的に無限の広さを持つことができる）をディスプレイ３に表示するためのボタン
戻るボタン…操作内容を破棄して操作前の状態に戻すためのボタン
進むボタン…操作内容を復活させて操作後の状態に戻すためのボタン
取り込みボタン…資料表示アプリ１１の画面４１のみの画像データを取り込むためのボタン
文字メモボタン…ソフトキーボードを表示させテキストを入力するためのボタン
業務アプリ連携ボタン…クラウドサービス（本実施形態のサーバ５０以外のクラウドサービス）や電子メールに会議のＵＲＬを送信するためのボタン
設定ボタン…各種の設定を受け付けるためのボタン
上記のように、ユーザはメニューの取り込みボタン４０７を押下して、資料表示アプリ１１の画面のみの画像データを取り込むことができる。
【０１１４】
＜画像データの表示方法＞
図１１を用いて資料表示アプリ１１の画面の画像データの表示方法を説明する。図１１の説明では、ＨＴＭＬ５のＣａｎｖａｓ要素を例にして説明する。まず、図１１（ａ）はＣａｎｖａｓノードを定義する記述である。「id="c1"」はＣａｎｖａｓの識別情報であり、「width="300"」はＣａｎｖａｓの横幅、「height="300"」はＣａｎｖａｓの高さである。横幅と高さは任意なので、例えばシステム管理者がＣａｎｖａｓの広さ、すなわちホワイトボードの広さを設定できる。
【０１１５】
図１１（ｂ）はJavaScript（登録商標）によりＣａｎｖａｓへ画像を表示する記述の一例である。１行目は、描画の対象となる図１１（ａ）のcanvasノードを取得する処理である。２行目は、getContextメソッドで２Ｄコンテキストをｃｔｘというオブジェクトに格納する処理である。この２Ｄコンテキスト（ｃｔｘ）で様々なJavaScriptのメソッドを使用し、Ｃａｎｖａｓに画像データを貼り付けるだけでなく、ユーザが線、図形等を描画できる。
【０１１６】
図１１（ｃ）は、JavaScript（登録商標）でＣａｎｖａｓに画像データを貼り付ける記述の一例である。ctxがＣａｎｖａｓを示しており、drawImageが画像データである「img」を座標（x, y）に表示するメソッドである。なお、「img」には、情報処理装置１０が送信した資料表示アプリ１１の画面の画像データが格納されている。
【０１１７】
座標（x, y）はＣａｎｖａｓの左上コーナーを基準とする、資料表示アプリ１１の画面４１の画像データの表示位置であり、本実施形態では情報処理装置１０から送信されている。仮に、情報処理装置１０から表示位置が送信されていない場合、サーバ５０は画像データが重複しないように表示位置を決定してもよいし、送信された画像データが何個目であるかに応じて自動的に決定してもよい（例えば、画像サイズ分だけ座標を下にずらす）。
【０１１８】
オブジェクト合成部５４は図１１のような記述を使ってホワイトボードに画像データを表示させる。
【０１１９】
なお、Ｃａｎｖａｓでは画像データの拡大や縮小とも可能である。
ctx.drawImage(img, dx, dy, dw, dh)
このdw, dhは画像データ（img）の幅と高さを指定する引数なので、サーバ５０のオブジェクト合成部５４は画像データを拡大又は縮小することができる。
【０１２０】
また、Ｃａｎｖａｓでは画像データのトリミングが可能である。
ctx.drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh)
sx,syはトリミングするため左上コーナーの座標であり、sw,shは幅とサイズである。したがって、トリミングは補助アプリ１３でなくサーバ５０が行うことができる。この場合、ホワイトボードアプリ１２は、画像保存場所３６を共有メモリにして補助アプリ１３から資料表示アプリ１１のウィンドウ情報を取得し、画像データと共にsx, sy, sw, shをサーバ５０に送信する。
【０１２１】
＜資料表示アプリの画面の表示例＞
図１２はホワイトボードアプリ１２が表示する画像データの表示例を示す図である。図１２（ａ）は資料表示アプリ１１の画面４１の取り込み時の表示例を示し、図１２（ｂ）は補助アプリ１３により取り込まれホワイトボードアプリ１２により表示された画像データの一例を示す。図１２（ａ）と図１２（ｂ）を比較すると、資料表示アプリ１１の画面の画像データ６９をホワイトボードアプリ１２が表示していることを確認できる。
【０１２２】
＜資料表示アプリの画面の一部の取得＞
ユーザが資料表示アプリ１１の画面の全体でなく、資料表示アプリ１１の画面の一部のみをホワイトボードに表示したい場合がある。このような要望に対しては補助アプリ１３が座標の指定を受け付けることができる。
【０１２３】
図１３は、資料表示アプリ１１の画面の一部の画像データを取得する方法を説明する図の一例である。図１３（ａ）は取り込みボタン４０７が押下された際に表示されるポップアップメニュー４２１の一例を示す。ユーザが取り込みボタン４０７を押下すると、操作受付部２４がこれを受け付け、表示制御部２１がポップアップメニュー４２１を表示する。ポップアップメニュー４２１には全体取得ボタン４２２と一部取得ボタン４２３が含まれる。全体取得ボタン４２２が押下された場合には、これまでの説明と同様に資料表示アプリ１１の画面４１の全体が取り込まれる。ボタンが取得された場合以外に、ジェスチャ（ドラッグアンドドロップや、Ｚ字のジェスチャ）を受け付けたときに資料表示アプリ１１の画面を取り込んでもよい。例えば資料表示アプリ１１と、Ｗｅｂブラウザ１５の境界線をまたぐように画面をなぞるジェスチャを受け付けた場合に、資料表示アプリ１１の画面を取り込む。
【０１２４】
一部取得ボタン４２３が押下された場合、補助アプリ１３のトリミング領域判断部３４がユーザによる範囲指定を受け付けるための透明スクリーン６１を表示装置（ディスプレイ３又はＬＣＤ２０６）に表示する。図１３（ｂ）は資料表示アプリ１１に重畳して表示された透明スクリーン６１の一例を示す。透明スクリーン６１は少なくとも資料表示アプリ１１の画面の全体をカバーしていればよい。上記のように、資料表示アプリ１１のウィンドウ情報はＯＳ１４から取得できる。
【０１２５】
また、補助アプリ１３のトリミング領域判断部３４は「取り込む範囲を指定して下さい」などのメッセージ６３を表示装置（ディスプレイ３又はＬＣＤ２０６）に表示する。これより、ユーザは透明スクリーン６１にタッチして取り込み範囲を指定できることを把握する。ユーザは、例えば、取り込み範囲６２の左上コーナーと右下コーナーを指定してもよいし、円を描いた場合の円の外接矩形を取り込み範囲６２としてもよい。
【０１２６】
補助アプリ１３のトリミング領域判断部３４は透明スクリーン６１で取得した取り込み範囲６２をトリミング領域に決定する。したがって、ホワイトボードアプリ１２はユーザが指定した範囲の画像データを表示できる。
【０１２７】
なお、トリミング領域判断部３４は指定された取り込み範囲６２を半透明にしたり、輝度を変更したり、点線で囲むなどして強調してもよい。また、透明スクリーン６１は完全な透明でなく半透明でもよい。こうすることで、ユーザは取り込み範囲６２を指定できる範囲を把握できる。
【０１２８】
＜資料表示アプリの非表示画面の取得＞
図１３では資料表示アプリ１１の画面の一部の取得方法を説明したが、資料表示アプリ１１が表示装置（ディスプレイ３又はＬＣＤ２０６）に表示しきれていない非表示画面をユーザが取り込みたいと考える場合もある。
【０１２９】
図１４は資料表示アプリ１１の非表示画面の取得方法を説明する図の一例である。図１４では資料表示アプリ１１が画面を表示しているが、表示装置（ディスプレイ３又はＬＣＤ２０６）に表示しきれない非表示範囲６４が下方に続いている。このような状況は資料表示アプリ１１が例えばＷｅｂブラウザ１５の場合に生じやすい。ユーザとしては、非表示範囲６４を含め資料表示アプリ１１が表示する全ての画面をホワイトボードアプリ１２に取り込みたい場合がある。
【０１３０】
非表示範囲６４を含め資料表示アプリ１１が表示する全ての画面を取り込む方法として、補助アプリ１３がＯＳ１４から資料表示アプリ１１の全体サイズを取得する方法がある。この方法では、ＯＳ１４から資料表示アプリ１１の画面のみの表示位置とサイズを取得することができ、画面取込部３２が資料表示アプリ１１の画面の画像データのみを取り込めばよい。
【０１３１】
ＯＳ１４が資料表示アプリ１１の全体サイズを把握していない場合、資料表示アプリ１１がアクセスしているＵＲＬをＯＳ１４が取得することを利用する。資料表示アプリ１１がＨＴＴＰ通信する際は、サーバ５０とＴＣＰ通信を行うためＷｅｂサーバとソケットを接続する。このソケットにはＷｅｂサーバのＩＰアドレスが書き込まれる。したがって、ＯＳ１４は資料表示アプリ１１がアクセスしているＵＲＬを検出できる。補助アプリ１３はＯＳ１４からＷｅｂサーバのＵＲＬを取得して、画像保存場所３６に保存する。これにより、ホワイトボードアプリ１２は資料表示アプリ１１が資料として表示しているＷｅｂページのＵＲＬを取得できるため、ホワイトボードに非表示範囲６４を含め資料表示アプリ１１が表示する全ての画面を取り込むことができる。Ｗｅｂページであるホワイトボードの中に別のＷｅｂページを表示するタグとしてiframe（インラインフレーム）が知られている。
【０１３２】
このように、ホワイトボードアプリ１２は、非表示範囲６４を含め資料表示アプリ１１が表示する全ての画面を取り込むことができる。
【０１３３】
＜まとめ＞
以上説明したように、本実施形態の情報処理装置１０は、補助アプリ１３を利用してＯＳ１４に近い処理を行わせることで、汎用的なアプリであるＷｅｂブラウザ１５による資料表示アプリ１１の画面の共有を実現できる。
【０１３４】
＜その他の適用例＞
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【０１３５】
例えば、本実施形態ではホワイトボードアプリ１２が資料表示アプリ１１の画面の画像データをサーバ５０に送ったが、補助アプリ１３が資料表示アプリ１１の画面の画像データをサーバ５０に送ってもよい。
【０１３６】
また、本実施形態では補助アプリ１３が資料表示アプリ１１の画面の画像データを取り込んだが、Ｗｅｂブラウザ１５によるこのような処理が可能であれば、ホワイトボードアプリ１２が資料表示アプリ１１の画面の画像データを取り込んでもよい。
【０１３７】
また、本実施形態では、ホワイトボードアプリ１２と資料表示アプリ１１という２つのアプリが画面を表示装置（ディスプレイ３又はＬＣＤ２０６）に表示しているが、３つアプリが画面を表示してもよい。この場合、補助アプリ１３は、ウィンドウ情報に基づいてホワイトボードアプリ以外の２つのアプリの画面を取り込み、ウィンドウ情報に基づいて切り取りを行う。アプリが４つ以上の場合も同様である。
【０１３８】
また、本実施形態では、ホワイトボードアプリ１２の画面が表示されている間に資料表示アプリ１１の画面を取り込む例を説明したが、ホワイトボードアプリ１２の画面は表示装置（ディスプレイ３又はＬＣＤ２０６）に表示されていなくてもよい。ホワイトボードアプリ１２の画面が表示されていなくても、資料表示アプリ１１の画面の画像データを取り込むことができる。
【０１３９】
また、本実施形態ではＨＴＭＬ５のＣａｎｖａｓ要素を使用して説明したが、ＷｅｂＧＬ、ＳＶＧ（Scalable Vector Graphics）、ＦＬＡＳＨ（登録商標）等をしようしてもよい。
【０１４０】
また、補助アプリ１３は、全体画面４３の画像データを取り込んでからトリミングするのでなく、直接、資料表示アプリ１１の画面だけを取り込んでもよい。この時、補助アプリ１３はアクティブなウィンドウの画面を取り込む機能を利用してもよい。
【０１４１】
また、図６などの構成例は、情報処理装置１０及びサーバ５０による処理の理解を容易にするために、主な機能に応じて分割したものである。処理単位の分割の仕方や名称によって本願発明が制限されることはない。情報処理装置１０及びサーバ５０の処理は、処理内容に応じて更に多くの処理単位に分割することもできる。また、１つの処理単位が更に多くの処理を含むように分割することもできる。
【０１４２】
なお、画面取込部３２は画像データ取得手段の一例であり、トリミング領域判断部３４は表示範囲取得手段の一例であり、トリミング部３５は画像切取手段の一例であり、表示制御部２１は画像データ表示手段の一例であり、通信部２２は通信手段の一例である。サーバ５０は第二の情報処理装置の一例であり、通信部５１は第二の通信手段の一例であり、オブジェクト合成部５４は画面情報生成手段の一例である。
【符号の説明】
【０１４３】
１０      情報処理装置
１０Ａ、１０Ｂ    情報端末
１１      資料表示アプリ
１２      ホワイトボードアプリ
１３      補助アプリ
４３      全体画面
５０      サーバ
１００    通信システム
【先行技術文献】
【特許文献】
【０１４４】
【特許文献１】特開２０１３‐０５９１１８号公報
【図１】
2019133283.tif 000003
【図２】
2019133283.tif 000004
【図３】
2019133283.tif 000005
【図４】
2019133283.tif 000006
【図５】
2019133283.tif 000007
【図６】
2019133283.tif 000008
【図７】
2019133283.tif 000009
【図８】
2019133283.tif 000010
【図９】
2019133283.tif 000011
【図１０】
2019133283.tif 000012
【図１１】
2019133283.tif 000013
【図１２】
2019133283.tif 000014
【図１３】
2019133283.tif 000015
【図１４】
2019133283.tif 000016