情報処理システム、携帯端末及びプログラム
【課題】携帯端末で処理不能なファイルの処理を、ＰＣリモートを用いてサーバに処理させるシステムにおいて、使い勝手を向上させた情報処理システムを提供する。
【解決手段】サーバ２００と携帯端末１００とが通信可能に接続する情報処理システム１であって、携帯端末１００は、表示しようとするファイルが処理不能であるか否かを判定し、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報（ＵＲＩ）の少なくともいずれかをサーバ２００に送信する処理可否判定手段１０２を有し、サーバ２００は、受信した前記ファイル又は前記ファイルが存在するアドレスを示す情報に基づき取得したファイルを、処理実行する処理手段２０２と、処理手段２０２による処理実行の表示出力を、携帯端末１００に転送する画面転送手段２０３とを有することを特徴とする。
【解決手段】サーバ２００と携帯端末１００とが通信可能に接続する情報処理システム１であって、携帯端末１００は、表示しようとするファイルが処理不能であるか否かを判定し、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報（ＵＲＩ）の少なくともいずれかをサーバ２００に送信する処理可否判定手段１０２を有し、サーバ２００は、受信した前記ファイル又は前記ファイルが存在するアドレスを示す情報に基づき取得したファイルを、処理実行する処理手段２０２と、処理手段２０２による処理実行の表示出力を、携帯端末１００に転送する画面転送手段２０３とを有することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、携帯端末及びプログラムに関し、特に、シンクライアントシステムにおいてサーバのデスクトップ画面の送受信を行う技術の応用に関する。
【背景技術】
【０００２】
ハイパーテキストで記述されたページを閲覧するブラウザの特性の違いにより、ページの表示がページ制作者側の意図とは異なるものとなってしまうことがある。このことは、例えば、パーソナルコンピュータ（以下、「ＰＣ」と呼ぶ）向けのウェブサイトのページを、携帯電話や、シンクライアント端末におけるクライアント装置などの携帯端末に向けて設計されたブラウザで閲覧しようとした場合に起きる。
【０００３】
特許文献１には、上記のような課題に関連して、ＰＣ向けのウェブページを携帯端末で表示しようとする際に正しく表示されないことを解消するため、ウェブサーバと携帯端末の間にあるプロクシサーバ等で、ＰＣ向けのウェブページを携帯端末向けの書法で記述されたハイパーテキストに変換して中継する技術が開示されている。しかしながら、ページを変換しているため、ＰＣ向けのウェブページの表示とはならない。
【０００４】
他方で、サーバとクライアントからなるシンクライアントシステムにおいて、サーバのデスクトップ画面の送受信を行う技術が従来公知である。「デスクトップ画面の送受信」とは、サーバ上で走るオペレーティングシステム（以下、「ＯＳ」）のグラフィカルユーザインタフェースが提供するデスクトップ画面を、クライアントに送り、表示させる機能のことをいうものとする。送信するデスクトップ画面は、画面全体でもよいし一部でもよい。また、このような機能のことを、以下では、「ＰＣリモート」と呼ぶ場合がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００３−２７１５０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述のようなシンクライアントシステムのクライアント端末で例えばＰＣ向けのページを閲覧する際、ＰＣと同じ再現性が得られない場合があった。クライアント端末としては一例として携帯電話機やスマートフォン等の携帯端末が用いられ、これら携帯端末の性能の向上は近年著しい。ＰＣ向けのページの閲覧においても同じような再現性で閲覧できるようにはなってきたが、完全に互換性があるわけではないので、同じように見ることのできないウェブページも依然として存在する。携帯端末向けの技術同様、ＰＣ向けの技術も日々進化していることもあり、この性能のギャップは将来においても完全に埋まらず今後も全く同じ表現、再現性が実現するようにはならないと予想される。
【０００７】
そこで、すべてのページの閲覧をサーバで行い、そのページ表示を上記ＰＣリモートで携帯端末に送信することを考える。この場合、常に、携帯端末においてもＰＣと同じ再現性を実現することが可能なるとは予想される。しかしながら、この場合は、次の２点が問題となる。
【０００８】
第１点目は、例えば、携帯端末に届いたメールに記載されているリンクからウェブサイトを閲覧するといった、携帯端末の他のアプリケーションとの連携ができなくなるという点である。また、携帯端末に届いたメールに添付されたファイルや、携帯端末に接続した周辺機器（デジタルカメラやカムコーダなど）から取り込んだファイルなど、携帯端末側にしかないデータは、ＰＣリモートで閲覧することができない。
【０００９】
第２点目は、ＰＣリモートの接続、とりわけ、最初にリモートのサーバと接続する際に時間がかかるという点である。携帯端末からリモートのサーバと接続するためには、まず、サーバのネットワーク上の位置を特定してこれと接続を確立し、サーバの電源が落とされている状態であればその起動から始めなくてはならない。
【００１０】
本発明は、上記実情に鑑みてなされたものであって、携帯端末で処理不能なファイルの処理を、ＰＣリモートを用いてサーバに処理させるシステムにおいて、使い勝手を向上させた情報処理システム、携帯端末及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するために本発明は、第１の態様として、サーバと携帯端末とが通信可能に接続する情報処理システムであって、前記携帯端末は、表示しようとするファイルが処理不能であるか否かを判定し、処理不能である場合に、前記ファイルか前記ファイルの所在地情報の少なくともいずれかを前記サーバに送信する処理可否判定手段を有し、前記サーバは、受信した前記ファイル又は前記所在地情報に基づき取得したファイルを、処理実行する処理手段と、前記処理手段による処理実行の表示出力を、前記携帯端末に転送する画面転送手段とを有することを特徴とする、情報処理システムを提供するものである。
【００１２】
上記目的を達成するために本発明は、第２の態様として、サーバと通信可能に接続する携帯端末であって、表示しようとするファイルが処理可能であるか否かを判定し、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかを、前記サーバに送信し、前記サーバに、前記サーバが前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかに基づいて処理実行した表示出力を、携帯端末へ転送させることを特徴とする、携帯端末を提供するものである。
【００１３】
上記目的を達成するために本発明は、第３の態様として、サーバと通信可能に接続する携帯端末に、表示しようとするファイルが処理可能であるか否かを判定する処理と、前記判定する処理の結果、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかを前記サーバに送信する処理と、前記サーバに、前記サーバが前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかに基づいて処理実行した表示出力を、携帯端末へ転送させる処理と、を実行させることを特徴とする、プログラムを提供するものである。
【発明の効果】
【００１４】
本発明によれば、携帯端末で処理不能なファイルの処理を、ＰＣリモートを用いてサーバに処理させるシステムにおいて、使い勝手を向上させた情報処理システム、携帯端末及びプログラムを提供することが可能となる。
【図面の簡単な説明】
【００１５】
【図１】第１の実施形態のネットワーク全体の構成を示すブロック図である。
【図２】第１の実施形態の機能ブロック図である。
【図３】第１の実施形態の処理の手順を示すフローチャート図である。
【図４】第１の実施形態の変形実施形態の処理の手順を示すフローチャート図である。
【図５】第２の実施形態のネットワーク全体の構成を示すブロック図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施形態について図面を参照しながら説明する。
【００１７】
（第１の実施形態）
図１に、本実施形態のネットワーク全体の構成を示す。
図示のように、本実施形態の情報処理システム１は、通信ネットワーク３００を介して、携帯端末１００とサーバ２００が相互に通信可能に接続したシステムである。本実施形態では、通信ネットワーク３００をインターネットとするが、インターネットに限定しなくてもよい。
【００１８】
サーバ２００は、サーバ２００上で走るＯＳのデスクトップ画面を通信ネットワーク３００を介してクライアントである携帯端末１００に送信し、携帯端末１００では、受信したデスクトップ画面を表示する。この一連の処理又は同処理がもたらす機能を「ＰＣリモート」と呼ぶ。
【００１９】
また、携帯端末１００は、通信ネットワーク３００を介して外部のウェブサーバ６００に接続してハイパーテキストで記述されたページ等を取得して内部のブラウザで解釈して表示する。すなわち、ページを構成するファイルを取得し、内部で処理して、処理結果を出力する。なお、ファイルの取得の際には、プロクシサーバ４００に代理させてもよい。
【００２０】
同様に、携帯端末１００は、携帯端末１００に直接接続する周辺機器５００に接続し、静止画像ファイルや動画像ファイル等を取得し、内部で処理して、処理結果を出力する。周辺機器５００は、例えば、動画ファイルや静止画ファイルが格納されたデジタルカメラなどが該当する。
【００２１】
しかしながら、携帯端末１００の性能によっては、処理が不可能である場合や可能であっても処理が不十分である場合がある。処理が不可能である場合とは、編集しようとするファイルが、携帯端末が対応していないファイル形式であった場合などが該当する。処理が不十分な場合とは、例えば、ＰＣ向けのウェブページをブラウズしようとした結果、ウェブページの解釈処理が不十分で、再現性が劣る表示出力が得られた場合などが該当する。なお、以下では、「処理が不可能である場合や可能であっても処理が不十分である場合」をまとめて、「処理不能の場合」と呼ぶ。
【００２２】
そこで、本実施形態では、携帯端末１００で処理不能である否かを判定して不能である場合に、サーバ２００へその旨を伝え、ＰＣリモートによりサーバ２００での処理結果をサーバ２００に送信させる。
【００２３】
図２に、本実施形態の機能ブロック図を示す。
図示のように、携帯端末１００は、処理開始通知手段１０１、処理可否判定手段１０２、処理手段１０３を備える。他方、サーバ２００は、初期化手段２０１、処理手段２０２、画面転送手段２０３を備える。
【００２４】
処理開始通知手段１０１は、処理手段１０３を用いた処理が始められるタイミングで、処理が始められた旨をサーバ２００に通知する機能を備える。例えば、処理手段１０３による処理がウェブページの閲覧であった場合には、ブラウザアプリケーションが起動したタイミングで、ブラウジング処理が始められた旨をサーバ２００に通知する。動画再生処理であった場合には、動画再生アプリケーションが起動したタイミングで、その旨をサーバ２００に通知する。
【００２５】
処理可否判定手段１０２は、処理手段１０３が処理しようとしているファイルが処理不能であるか否か、判定する機能を備える。また、当該ファイルがサーバ２００によって取得可能であるか否かも判定する。
【００２６】
処理手段１０３は、ユーザによる操作等により、処理対象のファイルを処理する手段である。具体的には、ブラウザアプリケーションや、動画再生アプリケーションや、文書ファイルの表示アプリケーションなどがある。
【００２７】
初期化手段２０１は、例えば、ＷｏＬ（Ｗａｋｅ ｏｎ Ｌａｎ）などを用いてサーバ２００自体を起動し、携帯端末１００からリクエストがあったときにすぐにＰＣリモート機能を提供できるよう、サーバ２００を準備する機能を備える。
【００２８】
処理手段２０２は、携帯端末１００の処理手段１０３と同様であるが、通常は、処理手段１０３よりも処理可能なファイルの種類が多い。
【００２９】
画面転送手段２０３は、ＰＣリモートにより、処理手段２０２による表示出力を携帯端末１００に送信する。送信する表示出力は、全部であっても、一部をトリミングしたものであってもよい。
【００３０】
次に、本実施形態の動作を説明する。
図３に、本実施形態の処理の手順を示す。
【００３１】
携帯端末１００において、処理手段１０３による処理が始められた場合、処理開始通知手段１０１は、その旨をサーバ２００に通知し、この通知を受けて初期化手段２０１がＰＣリモートの初期化をする（ステップＳ１０１）。
【００３２】
ここでのＰＣリモートの初期化は、初期化手段２０１がサーバ２００を起動してＰＣリモートに備える処理の他、携帯端末１００がサーバ２００のネットワーク上の位置を特定し、サーバ２００と通信ネットワーク３００を通じて通信可能にする処理も含まれる。
【００３３】
次に、処理手段１０３は、ユーザ操作等にしたがって、順次ファイルを処理していくが、その都度、処理するファイルが処理手段１０３によって処理不能なものであるか否か、処理可否判定手段１０２によって判定される（ステップＳ１０２、Ｓ１０３）。
【００３４】
ここでのファイルが処理不能であるか否かの判定方法としては、ファイルがＨＴＭＬファイルであれば、ＨＴＭＬファイルのサイズが携帯端末のブラウザで想定しているサイズを超えていないかどうか、ウェブページで使用しているプラグインの種類が対応しているものであるかどうか、表示にかかる処理時間を監視して表示完了までにあらかじめ定めた閾値以上の処理時間がかかるかどうか、といった判定方法を用いる。
【００３５】
処理不能である場合、処理可否判定手段１０２は、続けて、処理不能であると判定したファイルがサーバ２００によってアクセス可能か、取得可能であるか否かを判定する（ステップＳ１０４）。なお、この判定は、サーバ２００に判定させ、判定結果を処理可否判定手段１０２が受信してもよい。取得できないと判定された場合、当該ファイルもサーバ２００に送信する（ステップＳ１０５）。
【００３６】
ここでのファイルが取得可能であるか否かの判定は、ファイルの所在によって判断する。通信ネットワーク３００に接続するウェブサーバ６００にファイルが存在すれば、取得可能であると判断する。他方、周辺機器５００内にファイルが存在すれば、取得不可能であると判断する。
【００３７】
次に、携帯端末１００の処理可否判定手段１０２は、サーバ２００にファイルの存在する位置を示すＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）を送信する（ステップＳ１０６）。このステップは、ファイルを送信している場合（ステップＳ１０５）は、省略可能である。
【００３８】
ファイルか、ファイルが存在するネットワーク上の位置を示すＵＲＩ（あるいはその両方）を受け取ったサーバ２００では、処理手段２０２が、当該ファイルを処理する（ステップＳ１０７）。ＰＣ向けのウェブページを処理する場合、携帯端末１００ではメモリ不足などで処理不能であったウェブページであっても、通常、サーバ２００側では問題なく処理できる。
【００３９】
次に、画面転送手段２０３は、ステップＳ１０７における処理結果をＰＣリモートにより携帯端末１００に送信する（ステップＳ１０８）。ステップＳ１０７がウェブページの閲覧であれば、ブラウザの表示出力を携帯端末１００に送信する。
【００４０】
なお、図３における各ステップの主体は、ステップＳ１０１がサーバ２００の初期化手段２０１、ステップＳ１０２とＳ１０３とＳ１０４とＳ１０５とＳ１０６が携帯端末１００の処理可否判定手段１０２、ステップＳ１０７がサーバ２００の処理手段２０２、ステップＳ１０８がサーバ２００の画面転送手段２０３である。
【００４１】
本実施形態は、以上のように構成され、また、動作するので、クライアントである携帯端末で処理不能なファイルであっても、携帯端末で処理結果を得ることができ、使い勝手が向上する。ウェブページの閲覧で、携帯端末で処理不能なページがあったとしても、そのページについてだけ、サーバ側にＵＲＩを送りブラウジング処理をさせ、表示出力を送信させるため、携帯端末では、サーバで処理した画面でページを見られることとなり、再現性の問題が解消する。
【００４２】
また、主な操作は携帯端末側に搭載されているアプリケーションで実施し、処理不能なファイルだけをサーバで処理するため、携帯端末のアプリケーションの操作性や、アプリケーション間の連携などの携帯端末の操作性は損なわれない。
【００４３】
また、処理が開始されるタイミングでサーバとの接続確立やサーバの起動を行うため、ＰＣリモートを用いても、ユーザが感じる処理の遅れを最小限にとどめることができる。例えば、ウェブブラウズを開始した際に、バックグラウンドでサーバとの接続確立やサーバの起動を行っておくため、表示できないウェブページに行き当たったときには、既に、接続確立がなされており、スムーズにＰＣリモートによる表示がなされる。
【００４４】
上記実施形態は、処理不能なファイルが、ウェブページに埋め込まれた特定形式の動画ファイル（例えば、Ａｄｏｂｅ（登録商標）のＦｌａｓｈ（登録商標）ファイル）であった場合は、埋め込まれた画面の該当部分のみをサーバから送信する形態でもよい。
【００４５】
この場合、ウェブページ中の埋め込みタグに、動画ファイルのＵＲＩがパラメータとして存在しているので、処理可否判定手段１０２がＵＲＩに含まれる動画ファイルの拡張子から、携帯端末１００では処理不能であると判定して、同ＵＲＩをサーバ２００に送信する。サーバ２００では、処理手段２０２が同ＵＲＩから動画ファイルを取得し、表示出力を画面転送手段２０３が、携帯端末１００に転送する。携帯端末１００では、処理手段１０３が、埋め込みタグやウェブページ全体から動画ファイルが表示されるべき位置を判断し、その位置に、転送されてきた表示出力を嵌め込む。
【００４６】
この場合は、アプリケーションのタッチ操作などの操作性や携帯端末側の固有の設定を利用できるため、携帯端末の操作性が損なわれない。
【００４７】
上記実施形態では、携帯端末１００が外部のウェブサーバ６００からウェブページを構成するファイルを取得する際に、プロクシサーバ４００に代理させて取得してもよい。この実施形態の場合、ウェブページのキャッシュがプロクシサーバ４００に残るので、携帯端末１００で所定のアドレスのウェブページを表示させようとしたが表示できないためサーバ２００が前記所定のアドレスのウェブページを構成するファイルを取得する際、プロクシサーバ４００に残っているキャッシュを利用できる。したがって、この実施形態によれば、表示が高速に行われ、使い勝手が向上する。
【００４８】
また、上記実施形態は、次のように変形実施してもよい。
本変形実施形態のブロック構成は、図１と図２に示したものと同じである。図４に、本変形実施形態の動作を示す。図４に示すように、図３のフローチャートと似ているが、異なる点としては、処理可否判定手段１０２が、「携帯端末１００が処理しようとするファイルは処理手段１０１による処理ができない」と判断する処理（ステップＳ２０２，Ｓ２０３）のあと、ＰＣリモートのサーバ２００がプロクシサーバ４００経由で処理しようとするファイルを取得する（ステップＳ２０５）点がある。
【００４９】
本変形実施形態において、端末１００は、所定のアドレスのＷｅｂページをプロクシサーバ４００を経由して表示させようとしたが不可能であると判断された場合、その旨の情報をＵＲＩとともにサーバ２００へ送信する（ステップＳ２０４）。次に、サーバ２００は、プロクシサーバ４００経由で表示しようとするファイルを取得する（ステップＳ２０５）。次に、処理手段２０２が取得したファイル（Ｗｅｂページを構成するファイル）を表示する処理を行う（ステップＳ２０６）。次に、画面転送手段２０３は、ステップＳ２０６における表示処理結果をＰＣリモートにより携帯端末１００に送信する（ステップＳ２０７）。
【００５０】
なお、図４における各ステップの主体は、ステップＳ２０１がサーバ２００の初期化手段２０１、ステップＳ２０２とＳ２０３とＳ２０４が携帯端末１００の処理可否判定手段１０２、ステップＳ２０５とＳ２０６がサーバ２００の処理手段２０２、ステップＳ２０７がサーバ２００の画面転送手段２０３である。
【００５１】
本変形実施形態によれば、サーバ２００による処理がプロクシサーバ４００を経由して行われるので、サーバ２００の処理手段２０２が表示処理等行う際に、プロクシサーバ４００に蓄積されているファイルを利用することができる。そのため、サーバ２００とウェブサーバ６００間の通信の効率化が実現し、携帯端末１００は高速に処理結果が得られる。なお、本変形実施形態においては、携帯端末１００とサーバ２００が同じプロクシサーバ４００を利用した場合にのみ、通信の効率化や処理の高速化が図れる。
【００５２】
（第２の実施形態）
図５に、本実施形態のネットワーク全体の構成を示す。
図示のように、ネットワーク全体の構成の点で第１の実施形態（図１）と異なるところは、サーバ２００が除かれ、ＰＣリモートサーバ２００ａが置かれるところである。
【００５３】
ＰＣリモートサーバ２００ａは、第１の実施形態におけるサーバ２００同様、ＰＣリモートサーバ２００ａ上で走るＯＳのデスクトップ画面を通信ネットワーク３００を介してクライアントである携帯端末１００に送信し、携帯端末１００では、受信したデスクトップ画面を表示する。
【００５４】
第１の実施形態においては、サーバ２００は、携帯端末１００のユーザが所有するＰＣリモート機能を持つサーバである。したがって、ユーザが普段使っているパーソナルコンピュータなので、上述したように、履歴やユーザＩＤ／パスワードの自動入力機能などの利用を含むアプリケーションのタッチ操作などの操作性や携帯端末側の固有の設定を利用できる。
【００５５】
これに対して、上記特徴を持つ第２の実施形態のネットワーク構成では、ＰＣリモートサーバ２００ａをＰＣリモート機能を持つサーバとして機能させ、サービス事業者がサービスとして不特定多数のユーザに提供する形態である。
【００５６】
本実施形態によれば、サービス事業者が提供するサーバであるＰＣリモートサーバ２００ａが、携帯端末１００で処理不能なファイルの処理を処理するため、ユーザがＰＣリモートサーバ２００ａの電源を入れる必要がない。代行処理が始まって始めてＰＣリモートサーバ２００ａの電源を入れる場合よりも時間が短縮される効果がある。また、携帯端末１００のユーザの自宅等にＰＣリモート機能を有するサーバ２００をおかなくてもよい。
【符号の説明】
【００５７】
１ 情報処理システム
１００ 携帯端末
１０１ 処理開始通知手段
１０２ 処理可否判定手段
１０３ 処理手段
２００ サーバ
２００ａ ＰＣリモートサーバ
２０１ 初期化手段
２０２ 処理手段
２０３ 画面転送手段
３００ 通信ネットワーク
４００ プロクシサーバ
５００ 周辺機器
６００ ウェブサーバ
【技術分野】
【０００１】
本発明は、情報処理システム、携帯端末及びプログラムに関し、特に、シンクライアントシステムにおいてサーバのデスクトップ画面の送受信を行う技術の応用に関する。
【背景技術】
【０００２】
ハイパーテキストで記述されたページを閲覧するブラウザの特性の違いにより、ページの表示がページ制作者側の意図とは異なるものとなってしまうことがある。このことは、例えば、パーソナルコンピュータ（以下、「ＰＣ」と呼ぶ）向けのウェブサイトのページを、携帯電話や、シンクライアント端末におけるクライアント装置などの携帯端末に向けて設計されたブラウザで閲覧しようとした場合に起きる。
【０００３】
特許文献１には、上記のような課題に関連して、ＰＣ向けのウェブページを携帯端末で表示しようとする際に正しく表示されないことを解消するため、ウェブサーバと携帯端末の間にあるプロクシサーバ等で、ＰＣ向けのウェブページを携帯端末向けの書法で記述されたハイパーテキストに変換して中継する技術が開示されている。しかしながら、ページを変換しているため、ＰＣ向けのウェブページの表示とはならない。
【０００４】
他方で、サーバとクライアントからなるシンクライアントシステムにおいて、サーバのデスクトップ画面の送受信を行う技術が従来公知である。「デスクトップ画面の送受信」とは、サーバ上で走るオペレーティングシステム（以下、「ＯＳ」）のグラフィカルユーザインタフェースが提供するデスクトップ画面を、クライアントに送り、表示させる機能のことをいうものとする。送信するデスクトップ画面は、画面全体でもよいし一部でもよい。また、このような機能のことを、以下では、「ＰＣリモート」と呼ぶ場合がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００３−２７１５０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述のようなシンクライアントシステムのクライアント端末で例えばＰＣ向けのページを閲覧する際、ＰＣと同じ再現性が得られない場合があった。クライアント端末としては一例として携帯電話機やスマートフォン等の携帯端末が用いられ、これら携帯端末の性能の向上は近年著しい。ＰＣ向けのページの閲覧においても同じような再現性で閲覧できるようにはなってきたが、完全に互換性があるわけではないので、同じように見ることのできないウェブページも依然として存在する。携帯端末向けの技術同様、ＰＣ向けの技術も日々進化していることもあり、この性能のギャップは将来においても完全に埋まらず今後も全く同じ表現、再現性が実現するようにはならないと予想される。
【０００７】
そこで、すべてのページの閲覧をサーバで行い、そのページ表示を上記ＰＣリモートで携帯端末に送信することを考える。この場合、常に、携帯端末においてもＰＣと同じ再現性を実現することが可能なるとは予想される。しかしながら、この場合は、次の２点が問題となる。
【０００８】
第１点目は、例えば、携帯端末に届いたメールに記載されているリンクからウェブサイトを閲覧するといった、携帯端末の他のアプリケーションとの連携ができなくなるという点である。また、携帯端末に届いたメールに添付されたファイルや、携帯端末に接続した周辺機器（デジタルカメラやカムコーダなど）から取り込んだファイルなど、携帯端末側にしかないデータは、ＰＣリモートで閲覧することができない。
【０００９】
第２点目は、ＰＣリモートの接続、とりわけ、最初にリモートのサーバと接続する際に時間がかかるという点である。携帯端末からリモートのサーバと接続するためには、まず、サーバのネットワーク上の位置を特定してこれと接続を確立し、サーバの電源が落とされている状態であればその起動から始めなくてはならない。
【００１０】
本発明は、上記実情に鑑みてなされたものであって、携帯端末で処理不能なファイルの処理を、ＰＣリモートを用いてサーバに処理させるシステムにおいて、使い勝手を向上させた情報処理システム、携帯端末及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するために本発明は、第１の態様として、サーバと携帯端末とが通信可能に接続する情報処理システムであって、前記携帯端末は、表示しようとするファイルが処理不能であるか否かを判定し、処理不能である場合に、前記ファイルか前記ファイルの所在地情報の少なくともいずれかを前記サーバに送信する処理可否判定手段を有し、前記サーバは、受信した前記ファイル又は前記所在地情報に基づき取得したファイルを、処理実行する処理手段と、前記処理手段による処理実行の表示出力を、前記携帯端末に転送する画面転送手段とを有することを特徴とする、情報処理システムを提供するものである。
【００１２】
上記目的を達成するために本発明は、第２の態様として、サーバと通信可能に接続する携帯端末であって、表示しようとするファイルが処理可能であるか否かを判定し、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかを、前記サーバに送信し、前記サーバに、前記サーバが前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかに基づいて処理実行した表示出力を、携帯端末へ転送させることを特徴とする、携帯端末を提供するものである。
【００１３】
上記目的を達成するために本発明は、第３の態様として、サーバと通信可能に接続する携帯端末に、表示しようとするファイルが処理可能であるか否かを判定する処理と、前記判定する処理の結果、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかを前記サーバに送信する処理と、前記サーバに、前記サーバが前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかに基づいて処理実行した表示出力を、携帯端末へ転送させる処理と、を実行させることを特徴とする、プログラムを提供するものである。
【発明の効果】
【００１４】
本発明によれば、携帯端末で処理不能なファイルの処理を、ＰＣリモートを用いてサーバに処理させるシステムにおいて、使い勝手を向上させた情報処理システム、携帯端末及びプログラムを提供することが可能となる。
【図面の簡単な説明】
【００１５】
【図１】第１の実施形態のネットワーク全体の構成を示すブロック図である。
【図２】第１の実施形態の機能ブロック図である。
【図３】第１の実施形態の処理の手順を示すフローチャート図である。
【図４】第１の実施形態の変形実施形態の処理の手順を示すフローチャート図である。
【図５】第２の実施形態のネットワーク全体の構成を示すブロック図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施形態について図面を参照しながら説明する。
【００１７】
（第１の実施形態）
図１に、本実施形態のネットワーク全体の構成を示す。
図示のように、本実施形態の情報処理システム１は、通信ネットワーク３００を介して、携帯端末１００とサーバ２００が相互に通信可能に接続したシステムである。本実施形態では、通信ネットワーク３００をインターネットとするが、インターネットに限定しなくてもよい。
【００１８】
サーバ２００は、サーバ２００上で走るＯＳのデスクトップ画面を通信ネットワーク３００を介してクライアントである携帯端末１００に送信し、携帯端末１００では、受信したデスクトップ画面を表示する。この一連の処理又は同処理がもたらす機能を「ＰＣリモート」と呼ぶ。
【００１９】
また、携帯端末１００は、通信ネットワーク３００を介して外部のウェブサーバ６００に接続してハイパーテキストで記述されたページ等を取得して内部のブラウザで解釈して表示する。すなわち、ページを構成するファイルを取得し、内部で処理して、処理結果を出力する。なお、ファイルの取得の際には、プロクシサーバ４００に代理させてもよい。
【００２０】
同様に、携帯端末１００は、携帯端末１００に直接接続する周辺機器５００に接続し、静止画像ファイルや動画像ファイル等を取得し、内部で処理して、処理結果を出力する。周辺機器５００は、例えば、動画ファイルや静止画ファイルが格納されたデジタルカメラなどが該当する。
【００２１】
しかしながら、携帯端末１００の性能によっては、処理が不可能である場合や可能であっても処理が不十分である場合がある。処理が不可能である場合とは、編集しようとするファイルが、携帯端末が対応していないファイル形式であった場合などが該当する。処理が不十分な場合とは、例えば、ＰＣ向けのウェブページをブラウズしようとした結果、ウェブページの解釈処理が不十分で、再現性が劣る表示出力が得られた場合などが該当する。なお、以下では、「処理が不可能である場合や可能であっても処理が不十分である場合」をまとめて、「処理不能の場合」と呼ぶ。
【００２２】
そこで、本実施形態では、携帯端末１００で処理不能である否かを判定して不能である場合に、サーバ２００へその旨を伝え、ＰＣリモートによりサーバ２００での処理結果をサーバ２００に送信させる。
【００２３】
図２に、本実施形態の機能ブロック図を示す。
図示のように、携帯端末１００は、処理開始通知手段１０１、処理可否判定手段１０２、処理手段１０３を備える。他方、サーバ２００は、初期化手段２０１、処理手段２０２、画面転送手段２０３を備える。
【００２４】
処理開始通知手段１０１は、処理手段１０３を用いた処理が始められるタイミングで、処理が始められた旨をサーバ２００に通知する機能を備える。例えば、処理手段１０３による処理がウェブページの閲覧であった場合には、ブラウザアプリケーションが起動したタイミングで、ブラウジング処理が始められた旨をサーバ２００に通知する。動画再生処理であった場合には、動画再生アプリケーションが起動したタイミングで、その旨をサーバ２００に通知する。
【００２５】
処理可否判定手段１０２は、処理手段１０３が処理しようとしているファイルが処理不能であるか否か、判定する機能を備える。また、当該ファイルがサーバ２００によって取得可能であるか否かも判定する。
【００２６】
処理手段１０３は、ユーザによる操作等により、処理対象のファイルを処理する手段である。具体的には、ブラウザアプリケーションや、動画再生アプリケーションや、文書ファイルの表示アプリケーションなどがある。
【００２７】
初期化手段２０１は、例えば、ＷｏＬ（Ｗａｋｅ ｏｎ Ｌａｎ）などを用いてサーバ２００自体を起動し、携帯端末１００からリクエストがあったときにすぐにＰＣリモート機能を提供できるよう、サーバ２００を準備する機能を備える。
【００２８】
処理手段２０２は、携帯端末１００の処理手段１０３と同様であるが、通常は、処理手段１０３よりも処理可能なファイルの種類が多い。
【００２９】
画面転送手段２０３は、ＰＣリモートにより、処理手段２０２による表示出力を携帯端末１００に送信する。送信する表示出力は、全部であっても、一部をトリミングしたものであってもよい。
【００３０】
次に、本実施形態の動作を説明する。
図３に、本実施形態の処理の手順を示す。
【００３１】
携帯端末１００において、処理手段１０３による処理が始められた場合、処理開始通知手段１０１は、その旨をサーバ２００に通知し、この通知を受けて初期化手段２０１がＰＣリモートの初期化をする（ステップＳ１０１）。
【００３２】
ここでのＰＣリモートの初期化は、初期化手段２０１がサーバ２００を起動してＰＣリモートに備える処理の他、携帯端末１００がサーバ２００のネットワーク上の位置を特定し、サーバ２００と通信ネットワーク３００を通じて通信可能にする処理も含まれる。
【００３３】
次に、処理手段１０３は、ユーザ操作等にしたがって、順次ファイルを処理していくが、その都度、処理するファイルが処理手段１０３によって処理不能なものであるか否か、処理可否判定手段１０２によって判定される（ステップＳ１０２、Ｓ１０３）。
【００３４】
ここでのファイルが処理不能であるか否かの判定方法としては、ファイルがＨＴＭＬファイルであれば、ＨＴＭＬファイルのサイズが携帯端末のブラウザで想定しているサイズを超えていないかどうか、ウェブページで使用しているプラグインの種類が対応しているものであるかどうか、表示にかかる処理時間を監視して表示完了までにあらかじめ定めた閾値以上の処理時間がかかるかどうか、といった判定方法を用いる。
【００３５】
処理不能である場合、処理可否判定手段１０２は、続けて、処理不能であると判定したファイルがサーバ２００によってアクセス可能か、取得可能であるか否かを判定する（ステップＳ１０４）。なお、この判定は、サーバ２００に判定させ、判定結果を処理可否判定手段１０２が受信してもよい。取得できないと判定された場合、当該ファイルもサーバ２００に送信する（ステップＳ１０５）。
【００３６】
ここでのファイルが取得可能であるか否かの判定は、ファイルの所在によって判断する。通信ネットワーク３００に接続するウェブサーバ６００にファイルが存在すれば、取得可能であると判断する。他方、周辺機器５００内にファイルが存在すれば、取得不可能であると判断する。
【００３７】
次に、携帯端末１００の処理可否判定手段１０２は、サーバ２００にファイルの存在する位置を示すＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）を送信する（ステップＳ１０６）。このステップは、ファイルを送信している場合（ステップＳ１０５）は、省略可能である。
【００３８】
ファイルか、ファイルが存在するネットワーク上の位置を示すＵＲＩ（あるいはその両方）を受け取ったサーバ２００では、処理手段２０２が、当該ファイルを処理する（ステップＳ１０７）。ＰＣ向けのウェブページを処理する場合、携帯端末１００ではメモリ不足などで処理不能であったウェブページであっても、通常、サーバ２００側では問題なく処理できる。
【００３９】
次に、画面転送手段２０３は、ステップＳ１０７における処理結果をＰＣリモートにより携帯端末１００に送信する（ステップＳ１０８）。ステップＳ１０７がウェブページの閲覧であれば、ブラウザの表示出力を携帯端末１００に送信する。
【００４０】
なお、図３における各ステップの主体は、ステップＳ１０１がサーバ２００の初期化手段２０１、ステップＳ１０２とＳ１０３とＳ１０４とＳ１０５とＳ１０６が携帯端末１００の処理可否判定手段１０２、ステップＳ１０７がサーバ２００の処理手段２０２、ステップＳ１０８がサーバ２００の画面転送手段２０３である。
【００４１】
本実施形態は、以上のように構成され、また、動作するので、クライアントである携帯端末で処理不能なファイルであっても、携帯端末で処理結果を得ることができ、使い勝手が向上する。ウェブページの閲覧で、携帯端末で処理不能なページがあったとしても、そのページについてだけ、サーバ側にＵＲＩを送りブラウジング処理をさせ、表示出力を送信させるため、携帯端末では、サーバで処理した画面でページを見られることとなり、再現性の問題が解消する。
【００４２】
また、主な操作は携帯端末側に搭載されているアプリケーションで実施し、処理不能なファイルだけをサーバで処理するため、携帯端末のアプリケーションの操作性や、アプリケーション間の連携などの携帯端末の操作性は損なわれない。
【００４３】
また、処理が開始されるタイミングでサーバとの接続確立やサーバの起動を行うため、ＰＣリモートを用いても、ユーザが感じる処理の遅れを最小限にとどめることができる。例えば、ウェブブラウズを開始した際に、バックグラウンドでサーバとの接続確立やサーバの起動を行っておくため、表示できないウェブページに行き当たったときには、既に、接続確立がなされており、スムーズにＰＣリモートによる表示がなされる。
【００４４】
上記実施形態は、処理不能なファイルが、ウェブページに埋め込まれた特定形式の動画ファイル（例えば、Ａｄｏｂｅ（登録商標）のＦｌａｓｈ（登録商標）ファイル）であった場合は、埋め込まれた画面の該当部分のみをサーバから送信する形態でもよい。
【００４５】
この場合、ウェブページ中の埋め込みタグに、動画ファイルのＵＲＩがパラメータとして存在しているので、処理可否判定手段１０２がＵＲＩに含まれる動画ファイルの拡張子から、携帯端末１００では処理不能であると判定して、同ＵＲＩをサーバ２００に送信する。サーバ２００では、処理手段２０２が同ＵＲＩから動画ファイルを取得し、表示出力を画面転送手段２０３が、携帯端末１００に転送する。携帯端末１００では、処理手段１０３が、埋め込みタグやウェブページ全体から動画ファイルが表示されるべき位置を判断し、その位置に、転送されてきた表示出力を嵌め込む。
【００４６】
この場合は、アプリケーションのタッチ操作などの操作性や携帯端末側の固有の設定を利用できるため、携帯端末の操作性が損なわれない。
【００４７】
上記実施形態では、携帯端末１００が外部のウェブサーバ６００からウェブページを構成するファイルを取得する際に、プロクシサーバ４００に代理させて取得してもよい。この実施形態の場合、ウェブページのキャッシュがプロクシサーバ４００に残るので、携帯端末１００で所定のアドレスのウェブページを表示させようとしたが表示できないためサーバ２００が前記所定のアドレスのウェブページを構成するファイルを取得する際、プロクシサーバ４００に残っているキャッシュを利用できる。したがって、この実施形態によれば、表示が高速に行われ、使い勝手が向上する。
【００４８】
また、上記実施形態は、次のように変形実施してもよい。
本変形実施形態のブロック構成は、図１と図２に示したものと同じである。図４に、本変形実施形態の動作を示す。図４に示すように、図３のフローチャートと似ているが、異なる点としては、処理可否判定手段１０２が、「携帯端末１００が処理しようとするファイルは処理手段１０１による処理ができない」と判断する処理（ステップＳ２０２，Ｓ２０３）のあと、ＰＣリモートのサーバ２００がプロクシサーバ４００経由で処理しようとするファイルを取得する（ステップＳ２０５）点がある。
【００４９】
本変形実施形態において、端末１００は、所定のアドレスのＷｅｂページをプロクシサーバ４００を経由して表示させようとしたが不可能であると判断された場合、その旨の情報をＵＲＩとともにサーバ２００へ送信する（ステップＳ２０４）。次に、サーバ２００は、プロクシサーバ４００経由で表示しようとするファイルを取得する（ステップＳ２０５）。次に、処理手段２０２が取得したファイル（Ｗｅｂページを構成するファイル）を表示する処理を行う（ステップＳ２０６）。次に、画面転送手段２０３は、ステップＳ２０６における表示処理結果をＰＣリモートにより携帯端末１００に送信する（ステップＳ２０７）。
【００５０】
なお、図４における各ステップの主体は、ステップＳ２０１がサーバ２００の初期化手段２０１、ステップＳ２０２とＳ２０３とＳ２０４が携帯端末１００の処理可否判定手段１０２、ステップＳ２０５とＳ２０６がサーバ２００の処理手段２０２、ステップＳ２０７がサーバ２００の画面転送手段２０３である。
【００５１】
本変形実施形態によれば、サーバ２００による処理がプロクシサーバ４００を経由して行われるので、サーバ２００の処理手段２０２が表示処理等行う際に、プロクシサーバ４００に蓄積されているファイルを利用することができる。そのため、サーバ２００とウェブサーバ６００間の通信の効率化が実現し、携帯端末１００は高速に処理結果が得られる。なお、本変形実施形態においては、携帯端末１００とサーバ２００が同じプロクシサーバ４００を利用した場合にのみ、通信の効率化や処理の高速化が図れる。
【００５２】
（第２の実施形態）
図５に、本実施形態のネットワーク全体の構成を示す。
図示のように、ネットワーク全体の構成の点で第１の実施形態（図１）と異なるところは、サーバ２００が除かれ、ＰＣリモートサーバ２００ａが置かれるところである。
【００５３】
ＰＣリモートサーバ２００ａは、第１の実施形態におけるサーバ２００同様、ＰＣリモートサーバ２００ａ上で走るＯＳのデスクトップ画面を通信ネットワーク３００を介してクライアントである携帯端末１００に送信し、携帯端末１００では、受信したデスクトップ画面を表示する。
【００５４】
第１の実施形態においては、サーバ２００は、携帯端末１００のユーザが所有するＰＣリモート機能を持つサーバである。したがって、ユーザが普段使っているパーソナルコンピュータなので、上述したように、履歴やユーザＩＤ／パスワードの自動入力機能などの利用を含むアプリケーションのタッチ操作などの操作性や携帯端末側の固有の設定を利用できる。
【００５５】
これに対して、上記特徴を持つ第２の実施形態のネットワーク構成では、ＰＣリモートサーバ２００ａをＰＣリモート機能を持つサーバとして機能させ、サービス事業者がサービスとして不特定多数のユーザに提供する形態である。
【００５６】
本実施形態によれば、サービス事業者が提供するサーバであるＰＣリモートサーバ２００ａが、携帯端末１００で処理不能なファイルの処理を処理するため、ユーザがＰＣリモートサーバ２００ａの電源を入れる必要がない。代行処理が始まって始めてＰＣリモートサーバ２００ａの電源を入れる場合よりも時間が短縮される効果がある。また、携帯端末１００のユーザの自宅等にＰＣリモート機能を有するサーバ２００をおかなくてもよい。
【符号の説明】
【００５７】
１ 情報処理システム
１００ 携帯端末
１０１ 処理開始通知手段
１０２ 処理可否判定手段
１０３ 処理手段
２００ サーバ
２００ａ ＰＣリモートサーバ
２０１ 初期化手段
２０２ 処理手段
２０３ 画面転送手段
３００ 通信ネットワーク
４００ プロクシサーバ
５００ 周辺機器
６００ ウェブサーバ
【特許請求の範囲】
【請求項１】
サーバと携帯端末とが通信可能に接続する情報処理システムであって、
前記携帯端末は、
表示しようとするファイルが処理不能であるか否かを判定し、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかを前記サーバに送信する処理可否判定手段を有し、
前記サーバは、
受信した前記ファイル又は前記ファイルが存在するアドレスを示す情報に基づき取得したファイルを、処理実行する処理手段と、
前記処理手段による処理実行の表示出力を、前記携帯端末に転送する画面転送手段とを有する
ことを特徴とする、情報処理システム。
【請求項２】
前記携帯端末は、前記処理可否判定手段による処理不能であるか否かの判定の前に、前記サーバの起動か前記サーバとの接続の少なくともいずれかを実行する処理開始通知手段を有することを特徴とする、請求項１記載の情報処理システム。
【請求項３】
前記処理可否判定手段は、ファイルが処理不能であるか否かの判定方法として、ファイルサイズが所定の大きさを超えているか否か、前記ファイルのファイル形式が対応している形式であるか否か、又は、表示にかかる時間が所定の閾値を超えるか否かを判定する方法を用いることを特徴とする、請求項１又は２記載の情報処理システム。
【請求項４】
サーバと通信可能に接続する携帯端末であって、
表示しようとするファイルが処理可能であるか否かを判定し、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかを、前記サーバに送信し、
前記サーバに、前記サーバが前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかに基づいて処理実行した表示出力を、携帯端末へ転送させる
ことを特徴とする、携帯端末。
【請求項５】
サーバと通信可能に接続する携帯端末に、
表示しようとするファイルが処理可能であるか否かを判定する処理と、
前記判定する処理の結果、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかを前記サーバに送信する処理と、
前記サーバに、前記サーバが前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかに基づいて処理実行した表示出力を、携帯端末へ転送させる処理と、
を実行させる
ことを特徴とする、プログラム。
【請求項１】
サーバと携帯端末とが通信可能に接続する情報処理システムであって、
前記携帯端末は、
表示しようとするファイルが処理不能であるか否かを判定し、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかを前記サーバに送信する処理可否判定手段を有し、
前記サーバは、
受信した前記ファイル又は前記ファイルが存在するアドレスを示す情報に基づき取得したファイルを、処理実行する処理手段と、
前記処理手段による処理実行の表示出力を、前記携帯端末に転送する画面転送手段とを有する
ことを特徴とする、情報処理システム。
【請求項２】
前記携帯端末は、前記処理可否判定手段による処理不能であるか否かの判定の前に、前記サーバの起動か前記サーバとの接続の少なくともいずれかを実行する処理開始通知手段を有することを特徴とする、請求項１記載の情報処理システム。
【請求項３】
前記処理可否判定手段は、ファイルが処理不能であるか否かの判定方法として、ファイルサイズが所定の大きさを超えているか否か、前記ファイルのファイル形式が対応している形式であるか否か、又は、表示にかかる時間が所定の閾値を超えるか否かを判定する方法を用いることを特徴とする、請求項１又は２記載の情報処理システム。
【請求項４】
サーバと通信可能に接続する携帯端末であって、
表示しようとするファイルが処理可能であるか否かを判定し、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかを、前記サーバに送信し、
前記サーバに、前記サーバが前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかに基づいて処理実行した表示出力を、携帯端末へ転送させる
ことを特徴とする、携帯端末。
【請求項５】
サーバと通信可能に接続する携帯端末に、
表示しようとするファイルが処理可能であるか否かを判定する処理と、
前記判定する処理の結果、処理不能である場合に、前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかを前記サーバに送信する処理と、
前記サーバに、前記サーバが前記ファイルか前記ファイルが存在するアドレスを示す情報の少なくともいずれかに基づいて処理実行した表示出力を、携帯端末へ転送させる処理と、
を実行させる
ことを特徴とする、プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１２−１８５６１７（Ｐ２０１２−１８５６１７Ａ）
【公開日】平成２４年９月２７日（２０１２．９．２７）
【国際特許分類】
【出願番号】特願２０１１−４７５２１（Ｐ２０１１−４７５２１）
【出願日】平成２３年３月４日（２０１１．３．４）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２４年９月２７日（２０１２．９．２７）
【国際特許分類】
【出願日】平成２３年３月４日（２０１１．３．４）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]