(57)【要約】【課題】アプリが未知であっても一覧より選択可能であり、セキュリティを確保したうえで、一般ユーザが利用する携帯端末にて構成することも可能な、ウェブサービス提供サーバを提供する。【解決手段】アプリ管理部11は、各アプリをパスとポート番号と対応付けて管理する。インデックス応答部13は、クライアント20からのリクエストに従って上記管理されたアプリのインデックスを応答する。アプリ起動部14は、クライアント20がインデックス内から選択したアプリを、対応するポート番号において起動する。リダイレクト部15は、選択されたアプリに対応するパスとポート番号をクライアント20に通知して、アプリによるウェブサービスの提供を開始する。ここで、クライアント20はドメイン名及びポート番号ごとに区別して記憶領域を確保する。【選択図】図１
2014191805.tif 000002
【特許請求の範囲】
【請求項１】
ウェブサービスの提供を受ける際にドメイン名及びポート番号ごとに区別して記憶領域を確保するクライアントに対して、ウェブサービスを提供するサーバであって、
ウェブサービスを提供するために前記サーバが実行する各アプリを、前記サーバのドメイン内におけるアプリのパスと、アプリ毎に一意に付与されたポート番号と、に対応付けて管理するアプリ管理部と、
クライアントからのリクエストを受け付けるリクエスト受付部と、
前記リクエストに応答して、前記アプリ管理部に管理されたアプリのインデックスを前記クライアントに応答するインデックス応答部と、
前記インデックスより選択されたアプリを、前記クライアントより受け付け、前記サーバにおいて当該選択されたアプリを前記一意に付与されたポート番号において起動するアプリ起動部と、
前記アプリ管理部で管理されたパス及びポート番号のうち前記選択されたアプリに対応するものを前記クライアントに返信することで、前記クライアントに対して前記選択されたアプリによるウェブサービスの提供を、当該返信したパス及びポート番号によって開始するリダイレクト部と、を備えることを特徴とするサーバ。
【請求項２】
前記リクエスト受付部は、第一ポート番号にて、前記リクエストを受け付け、
前記アプリ管理部は、各アプリを、前記パスと、アプリ毎に一意に付与された前記第一ポート番号以外のポート番号と、に対応付けて管理し、
前記インデックス応答部は、前記第一ポート番号にて、前記インデックスを応答し、
前記アプリ起動部は、前記第一ポート番号にて、前記選択されたアプリを受け付け、
前記リダイレクト部は、前記第一ポート番号にて、前記返信することを特徴とする請求項１に記載のサーバ。
【請求項３】
前記第一ポート番号がHTTP通信用であることを特徴とする請求項２に記載のサーバ。
【請求項４】
前記アプリ管理部は、前記サーバの管理者からのアプリのインストール又はアンインストールの指示に従って、管理するアプリを更新し、
インストールの指示を受けた際には、インストールされるアプリに対して、所定のパスと、当該指示された時点においていずれのアプリにも対応付けられていないポート番号と、を対応付けることを特徴とする請求項１ないし３のいずれかに記載のサーバ。
【請求項５】
前前記クライアントからのリクエストを受け付け、前記選択されたアプリによるウェブサービスの提供をしている場合以外は、前記サーバの管理者が所望のアプリのみを実行可能なように構成されていることを特徴とする請求項１ないし４のいずれかに記載のサーバ。
【請求項６】
前記リクエスト受付部では、予め設定されたクライアントのみからリクエストを受け付けることを特徴とする請求項１ないし５のいずれかに記載のサーバ。
【請求項７】
ウェブサービスを受ける際にドメイン名及びポート番号ごとに区別して記憶領域を確保するクライアントに対して、サーバがウェブサービスを提供する方法であって、
ウェブサービスを提供するために前記サーバが実行する各アプリを、前記サーバのドメイン内におけるアプリのパスと、アプリ毎に一意に付与されたポート番号と、に対応付けて管理するアプリ管理段階と、
クライアントからのリクエストを受け付けるリクエスト受付段階と、
前記リクエストに応答して、前記アプリ管理段階にて管理されたアプリのインデックスを前記クライアントに応答するインデックス応答段階と、
前記インデックスより選択されたアプリを、前記クライアントより受け付け、前記サーバにおいて当該選択されたアプリを前記一意に付与されたポート番号において起動するアプリ起動段階と、
前記アプリ管理段階で管理されたパス及びポート番号のうち前記選択されたアプリに対応するものを前記クライアントに返信することで、前記クライアント対して前記選択されたアプリによるウェブサービスの提供を、当該返信したパス及びポート番号によって開始するリダイレクト段階と、を備えることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバにあるウェブサービス提供のためのアプリを、クライアント側からリクエストして実行する際に、各アプリ及びそのポート番号がわからなくとも、サーバ側のアプリ一覧を取得し、動作させたいアプリを選択でき、かつセキュリティを担保した上で、実行することが可能な、ウェブサービスを提供するサーバに関する。
【背景技術】
【０００２】
クライアントよりサービスの提供要求等を受け、対応するアプリケーション（「アプリ」と略称する）を実行するサーバにおけるアプリ管理に関して、以下の特許文献１及び２のような従来技術が存在する。
【０００３】
特許文献1では、メモリやCPU、ストレージに制限が多い組み込み機器を主なターゲットとし、事前に用意した各アプリの設定情報に基づき、ユーザからHTTPサーバに対してHTTPリクエストがあった際に、より安全なSSL (Secure Socket Layer) を利用したHTTPSサーバへのHTTPSリクエストに自動的に切り替えることが可能である。すなわち、ユーザ側は、HTTP通信か、HTTPS通信かを意識することなく、サーバに対してリクエストを送信することができる。
【０００４】
また、特許文献2では、例えば、HTTPリクエストを受け取った際に、HTTPSに限らず、指定したポート番号での通信に切り替えることが可能である。事前に、各アプリに対して、待ち受けのポート番号と、転送先のポート番号を設定しておくことで、待ち受けポートで受信したリクエストを、転送先のポート番号に切り替えて、アプリを実行することができる。
【０００５】
当該事前設定は例えば、80番ポートで待ち受けていて、それを443番ポートに自動切り替える場合は、アプリに対して、待ち受けポートが80番(HTTP)で、転送先ポートが443番(HTTPS)という情報を、リストとして保持しておくことを意味する。この際に、443番ではなく、例えば、1024番などのユーザが定義するポート番号を利用できる仕組みを提供しているのが、特許文献1との違いである。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2006-277246号公報
【特許文献２】特開2012-68874号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記特許文献1及び2に開示の従来技術では、以下のような課題がある。
【０００８】
第一に、従来技術においては、ユーザ側からリクエストされたポートから自動的に転送先ポートへ切り替えることはできるが、サーバ上にどんなアプリがあるかといった情報をユーザ側に提供することはできない。すなわち、ユーザ側は、ドメイン名とポート番号だけでなく、アプリのパスを事前に知っていなければ、アプリを実行できない。
【０００９】
また第二に、リクエストのポートを自動的に切り替えたとしても、そのポートで、各アプリがリクエストを待ち受けていなければ、アプリを実行できないが、従来技術においては、事前に起動すべきアプリを順序も含めてリストに記述しておくことにより、アプリを起動する。そのため、機器の電源投入のタイミングなどで、リストに記述されたアプリは、全て起動されることが前提となる。
【００１０】
こうした事項が課題となるのは、サーバをスマートフォンなどの携帯端末によって実現しようとする場合である。
【００１１】
すなわち、従来技術にて想定している組み込み機器などにおいては、一般に、予めインストールされたアプリ群があり、それらは、一括で起動される。これらの各アプリは、ユーザによって頻繁に起動・終了されることは少ないと考えられる。
【００１２】
一方で、携帯端末（スマートフォン）においては、端末管理者（端末の保持者であり、一般ユーザである）がアプリを頻繁にインストールやアンインストールすると共に、アプリの起動・終了も頻繁に行うこととなる。
【００１３】
このような制約下にある携帯端末自身がサーバとして機能し、クライアントに対して、そのアプリを提供することを考えた場合、端末内にあるアプリの情報を自動的に管理し、クライアントに通知できることが望ましい。従って、上記第一の課題が生ずる
【００１４】
また、携帯端末内のアプリは、端末の処理能力などの制約もあり、端末管理者により、起動および終了が頻繁に行われる。一般の組み込み機器のように、常時全アプリが起動していることは、端末においては現実的ではない。そのため、クライアントからのリクエストがあったときに、アプリを起動できることが望ましい。従って、上記第二の課題が生ずる。
【００１５】
さらに、第三の課題として、上記第一及び第二の課題に対処した後、当該リクエストに基づいてアプリを起動した場合に、クライアント側で実行するアプリが、当該クライアントのアプリ実行環境の制約のもとで安全かつ安定的に動作することも、強く望まれる。
【００１６】
上記課題に鑑みて、本発明は、クライアント側に利用可能なアプリを通知可能であり、クライアントからのリクエストに応じてアプリの起動が可能であり、さらに、当該起動されたアプリがクライアントにおいて安全且つ安定的に機能することが可能な、ウェブサービスを提供するサーバ及び方法を提供することを目的とする。
【課題を解決するための手段】
【００１７】
上記目的を達成するため、本発明は、ウェブサービスの提供を受ける際にドメイン名及びポート番号ごとに区別して記憶領域を確保するクライアントに対して、ウェブサービスを提供するサーバであって、ウェブサービスを提供するために前記サーバが実行する各アプリを、前記サーバのドメイン内におけるアプリのパスと、アプリ毎に一意に付与されたポート番号と、に対応付けて管理するアプリ管理部と、クライアントからのリクエストを受け付けるリクエスト受付部と、前記リクエストに応答して、前記アプリ管理部に管理されたアプリのインデックスを前記クライアントに応答するインデックス応答部と、前記インデックスより選択されたアプリを、前記クライアントより受け付け、前記サーバにおいて当該選択されたアプリを前記一意に付与されたポート番号において起動するアプリ起動部と、前記アプリ管理部で管理されたパス及びポート番号のうち前記選択されたアプリに対応するものを前記クライアントに返信することで、前記クライアントに対して前記選択されたアプリによるウェブサービスの提供を、当該返信したパス及びポート番号によって開始するリダイレクト部と、を備えることを特徴とする。
【００１８】
ウェブサービスを受ける際にドメイン名及びポート番号ごとに区別して記憶領域を確保するクライアントに対して、サーバがウェブサービスを提供する方法であって、ウェブサービスを提供するために前記サーバが実行する各アプリを、前記サーバのドメイン内におけるアプリのパスと、アプリ毎に一意に付与されたポート番号と、に対応付けて管理するアプリ管理段階と、クライアントからのリクエストを受け付けるリクエスト受付段階と、前記リクエストに応答して、前記アプリ管理段階にて管理されたアプリのインデックスを前記クライアントに応答するインデックス応答段階と、前記インデックスより選択されたアプリを、前記クライアントより受け付け、前記サーバにおいて当該選択されたアプリを前記一意に付与されたポート番号において起動するアプリ起動段階と、前記アプリ管理段階で管理されたパス及びポート番号のうち前記選択されたアプリに対応するものを前記クライアントに返信することで、前記クライアント対して前記選択されたアプリによるウェブサービスの提供を、当該返信したパス及びポート番号によって開始するリダイレクト段階と、を備えることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、アプリ管理部（アプリ管理段階）で管理されているインデックスをクライアントに対してインデックス応答部が応答するので、利用可能なアプリの通知が可能となる。
【００２０】
また、アプリ起動部（アプリ起動段階）により、クライアント側にてインデックスから選択されたアプリを、サーバにおいて自動起動することが可能となる。
【００２１】
さらに、アプリ起動部（アプリ起動段階）による起動の際はアプリ管理部（アプリ管理段階）で管理された一意なポート番号において起動され、リダイレクト部（リダイレクト段階）は当該ポート番号とアプリのパスをクライアント側に通知する。従って、ドメイン名及びポート番号ごとに区別して記憶領域を確保するクライアントにおいては、当該サーバのアプリ毎に記憶領域を確保するので、安全且つ安定的にアプリが機能して、ウェブサービスの提供を受けることが可能となる。
【図面の簡単な説明】
【００２２】
【図１】一実施形態に係るアプリ連携システムの機能ブロック図である。
【図２】ユーザによるアプリ管理部へのアプリ登録を模式的に説明するための図である。
【図３】クライアント側のブラウザからサーバ側のアプリを利用する際の、アプリ連携のフローチャートである。
【図４】本発明によるゲートウェイを利用しない場合の、ブラウザに確保されるデータ領域の例を示す図である。
【図５】本発明によるゲートウェイを利用する場合の、ブラウザに確保されるデータ領域の例を示す図である。
【図６】ウェブストレージに格納する値が、別途のアプリから参照・更新されることで、本発明によるゲートウェイを利用しない場合に問題が発生する一連の流れの例である。
【発明を実施するための形態】
【００２３】
図１は、一実施形態に係るアプリ連携システムの機能ブロック図である。アプリ連携システム1は、サーバ10及びクライアント20を備える。サーバ10及びクライアント20はスマートフォンなどの携帯端末であってもよく、それぞれ複数存在していてもよい。クライアント20はサーバ10に対してウェブサービスの提供を要求し、サーバ10は当該要求に応じてクライアント20に対してウェブサービスを提供する。なお、当該ウェブサービスの提供を受けるための各種のやりとりを行う際に、クライアント20では自身が実行するブラウザを利用することができる。
【００２４】
サーバ10は、アプリ管理部11、リクエスト受付部12、インデックス応答部13、アプリ起動部14、リダイレクト部15及びアプリ機能部16を備える。当該各部は、コンピュータであるサーバ10にてプログラムを読み込んで実行（以下、クライアント20の処理への言及の場合を含め適宜、読み込みが行われる旨を省略して、「実行」あるいは「起動」と略記する）することによって実現される。
【００２５】
ここで特に、アプリ起動部14は、OS(オペレーティングシステム)やブラウザエンジンといったプラットフォーム、すなわち一連の基本プログラムの実行で実現することができる。
【００２６】
アプリ起動部14以外の各部は、(プラットフォームが実行されている前提のもと)プラットフォームとは別に、ゲートウェイアプリの実行で実現することができる。ゲートウェイアプリは、バックグラウンドで起動している、すなわち、読み込まれて実行され、具体的な処理の命令を待機している状態となっていることを前提とする。
【００２７】
アプリ管理部11は、ウェブサービスを提供するための各アプリを、当該サーバ10におけるアプリのパスと、アプリ毎に一意に付与されたポート番号と対応づけて管理し、その情報を保持する。アプリ管理部11はまた、ウェブサービス提供用以外の、サーバ10にて実行する各アプリも管理する。当該管理される各アプリは、ユーザによって指定され、登録されたものである。
【００２８】
図2は、ユーザによるアプリ管理部11へのアプリ登録を模式的に説明するための図である。欄C1の(1-1)に示す登録アプリテーブルは、アプリ名、アプリパス名およびそれに対応するポート番号の組み合わせを記載したテーブルであり、アプリ管理部11が管理している。当該(1-1)にはある時点における当該テーブルの内容が示されており、「Memo（メモ）」アプリ及び「Gallery（画像閲覧）」アプリの2つに関して登録されている。
【００２９】
なお、(1-2)のアプリ起動通知テーブルは、当該テーブル(1-1)に対応するものであって当該テーブル(1-1)と共に登録される。すなわち、OSやブラウザエンジンといった各プラットフォームがサポートするアプリ呼び出し機能を利用するための所定様式の指示を、当該アプリ起動通知テーブルとして、呼び出し対象のアプリ毎に記録しておく。なお、図2では起動対象のアプリ名とアプリパス名のみを示し、所定様式の指示の詳細は示していない。
【００３０】
当該テーブル(1-1),(1-2)の状態に対して、欄C3に例を示すような登録画面によってユーザが新たなアプリ（「Movie（動画）」アプリ）を登録した後の状態が、欄C2のテーブル(2-1),(2-2)として示されている。アプリ登録の際は、サーバ10はネットワーク上で登録可能アプリを保持しているアプリサーバ30にアクセスして、ユーザが所望のアプリを選択し、サーバ10にダウンロード及びインストールする。この際、アプリ管理部11が以下のように各項目を自動設定し、登録アプリテーブルを更新する。
【００３１】
アプリ名に関しては、アプリサーバ30に登録されているものを登録アプリテーブルに記載する。あるいは、ユーザがアプリ名をマニュアル入力した場合は、当該入力された名称を記載してもよい。
【００３２】
また、アプリパス名に関しては、アプリサーバ30にて設定しておき、あるいは、上記のように定めたアプリ名から所定規則を用いて自動生成し、当該パス名を登録アプリテーブルに記載する。なお、サーバ10にて当該記載されたパスの箇所でアプリが実行されるように、アプリ管理部11はインストール処理を行う。
【００３３】
さらに、ポート番号に関して、現時点における登録アプリテーブルで割り振っていない番号を、アプリ管理部11が自動で割り振ることで、登録アプリテーブルを更新する。割り振る番号は、登録ポート番号：1024-49151またはプライベートポート番号：49152-65535の範囲内より、現時点の登録アプリテーブルに使用されていないものを自動選択すればよい。
【００３４】
アプリ管理部11はまた、このアプリ登録の際に同時に、OSやブラウザエンジンといった各プラットフォームが提供する所定様式に従って、アプリ起動通知テーブルも自動で更新する。
【００３５】
こうして、欄C3に示すように、ユーザ選択によって新規に「Movie（動画）」アプリがインストールされると、登録アプリテーブルは更新されて欄C2の(2-1)のようになる。すなわち、アプリ名が「Movie」である新規アプリが、当該アプリ名と、そのパス名「Movieapp.html」と、未使用であった番号から自動割り振りされたポート番号「3003」と、対応付けて登録され、更新される。この際同様に、アプリ起動通知テーブルも更新されて(2-2)のようになる。
【００３６】
なお、ユーザはアプリサーバ30から新規アプリを登録する際に、登録アプリテーブルに登録しない旨も選択可能である。この場合、別途に欄C4に示すように、非登録アプリリストとしてアプリ管理部11に管理される。当該アプリをクライアント20に対してサービス提供するのには用いず、自身のみが利用するような場合は特に、このようにして非登録アプリリスト側に登録すればよい。
【００３７】
なおまた、アプリ管理部11は、ユーザが何らかのアプリをサーバ10にインストールしようとする際に、自動的に起動され、登録アプリテーブルに登録するか否かをユーザに入力させるようにすることができる。ユーザ自身が起動してもよいが、そのような操作がなかった場合には、インストール作業の検知によってアプリ管理部11は自動的に起動される。
【００３８】
逆に、ユーザがアプリを削除（アンインストール）した場合は、アプリ管理部11は当該操作を自動検知して、当該削除対象となったアプリを、登録アプリテーブル（及びアプリ起動通知テーブル）または非登録アプリリストより削除する。当該アプリが登録アプリテーブルに登録されたものであった場合、割り当てられていたポート番号は、今後、何らかのアプリを登録アプリテーブルに登録する際に利用可能となる。
【００３９】
リクエスト受付部12は、クライアント20より受信したリクエストを解析して、適切な処理を行う。このため例えば、「http://172.0.0.1/」というリクエスト（172.0.0.1はサーバ10のIPアドレスの例）に対して、インデックス応答部13に指示して登録アプリテーブルのアプリ一覧を表すインデックス（index.htmlなど）を応答するといった設定を行っておく。当該設定によって、リクエスト受付部12がリクエストを検知し解析した結果が上記の設定と一致すれば、インデックス応答部13にそれを通知し、上記アプリ一覧の応答を行うようにさせる。そうでない場合は、エラーコードなどをクライアント20に返答する。
【００４０】
インデックス応答部13は、リクエスト受付部12からの指示を受け、アプリ管理部11の管理している登録アプリテーブルにあるアプリの一覧を含んだ事前に作成されたインデックスをウェブページとして、クライアント20に応答する。当該ウェブページ内には、サーバ10のドメイン名と登録されているアプリ名とがセットとなったリンクとして、各アプリの情報が記載されている。なお、受信リクエスト結果によっては、上記のようにエラーコードなどを返答し、本発明によるサービス提供は開始されない。
【００４１】
なお、当該応答するためのウェブページも、ユーザがアプリ管理部11においてアプリを追加登録又は削除した際に、ウェブページとしての所定様式を整えたうえで、登録アプリテーブル及びアプリ起動通知テーブルと共に自動作成することができる。従って、アプリ管理部11では当該ウェブページも管理する。
【００４２】
クライアント20側では、インデックス応答部13から受け取ったインデックス中のアプリ一覧のウェブページから、サービス提供を受けるための所望のアプリケーションのリンクを選択してサーバ10側(アプリ起動部14)へ送信する。リンクには、前述のようにドメイン名とアプリ名がセットとなったアプリ情報が書かれている。このリンクへの接続リクエストは、httpのサービスに利用される80番ポートへのリクエストとなる。
【００４３】
アプリ起動部14は、上記受信したクライアント20指定のアプリ名でアプリ管理部11のアプリ管理テーブルを参照してそのポート番号を取得し、当該ポート番号においてクライアント20が指定したアプリを起動する。アプリ機能部16は、当該起動されたアプリの機能を担い、当該取得されたポート番号においてクライアント20と通信して、当該アプリによるウェブサービスの提供を担う。
【００４４】
なお、当該起動の際、各プラットフォームのアプリ起動部14が提供するアプリ起動通知機能を使って、アプリ起動通知テーブル内に記載の所定処理を行うことで、取得したポート番号でアプリが起動する。
【００４５】
一方で、リダイレクト部15では、アプリ起動部14によるアプリ起動の完了を確認してから、クライアント20側に対して、取得したポート番号（アプリ起動部14にて起動された際のポート番号）付きのアプリのURI(Uniform Resource Identifier)にリダイレクトするメッセージを返答する。クライアント20側はそのメッセージを解釈して、自動的にアプリへリダイレクトされ、上記のように当該ポート番号においてアプリ機能部16と通信して、ウェブサービスの提供を受ける。当該ウェブサービス提供の際に利用するポート番号は、取得したポート番号（例えば、1024番や3001番など）となる。
【００４６】
図3は、クライアント20側のブラウザから、サーバ10側のアプリを利用する際のアプリ連携のフローチャートである。なお、当該フローの開始に先立って、アプリ管理部11におけるユーザによる登録により、登録アプリテーブル等が構築されている。
【００４７】
なお、図1の各機能部などは、対応するコンピュータにて対応するプログラムを読み込んで実行して実現されるが、図2では当該プログラムのサービス提供の際の位置づけによって、動作主体を分類している。図1の各機能部などとの対応関係として、ブラウザB1はクライアント20に、ゲートウェイG1はアプリ管理部11、リクエスト受付部12、インデックス応答部13及びリダイレクト部15に、プラットフォームP1はアプリ起動部14に、アプリA1はアプリ機能部16に、相当する。
【００４８】
最初に、ステップS0として、サーバ10側では、ゲートウェイG1が常時起動していて、httpサービスに割り当てられている80番ポートを監視（listen）している。
【００４９】
ステップS1にて、クライアント20のブラウザB1からアプリを持つサーバ10のURIにhttpアクセスをする。このhttpリクエストを行う際に、特にポート番号の指定がない場合には、デフォルトで80番ポートへのアクセスとなる。ゲートウェイG1では、80番ポートを監視しているため、リクエスト受付部12によりブラウザB1からの当該リクエストを検知すると共に、その内容の解析が行われる。
【００５０】
当該解析によりリクエストが所定様式に即したものであった場合、ステップS2にてその応答として、インデックス応答部13がアプリ一覧であるインデックス(例えば、index.html)をブラウザB1側へと返す。
【００５１】
ブラウザB1側には、アプリ一覧が書かれたインデックスページが表示される。表示されたアプリのリンクの中から利用したいアプリをブラウザB1のユーザが選択し、ステップS3にて、ゲートウェイG1に対して、再度httpリクエストを出す。例えば、「Memo(メモ)」アプリを選択した場合、そのリンク「http://172.0.0.1/Memo」をhttpリクエストとして送信する。このリンクへの接続リクエストは、httpのサービスに利用される80番ポートへのリクエストとなる。
【００５２】
アプリ選択のhttpリクエストを受け取ったゲートウェイG1は、URI中に含まれるアプリ名を抽出し、そのアプリ名をキーにして、アプリ管理部11内のアプリ登録テーブルを参照し、対応するポート番号を取得する。
【００５３】
こうして、ステップS4及びS5として示すように、アプリ起動部14によって、プラットフォームが提供するアプリ起動通知機能を介して、このアプリ名とポート番号に対応するアプリA1が起動され、アプリ機能部16が稼働状態となる。アプリが起動すると、そのアプリ内では、このポート番号に対するリクエストの監視を開始する。なお、ステップS3のリクエストが複数ある場合は、複数のアプリが起動される。
【００５４】
また、ステップS6及びS7として示すように、プラットフォーム側P1では、アプリA1の起動に成功したというイベントが発生し、それをゲートウェイG1で検知する。この検知後、ステップS8として示すように、リダイレクト部15がhttpリダイレクトコード（301または302）とリダイレクト先のURIを、ブラウザB1側に返す。
【００５５】
リダイレクトのメッセージを受け取ったブラウザB1は、このコードを認識し、ステップS9に示すように、自動でリダイレクト先のURIに対して、httpリクエストを出す。この際に、URIには、起動したアプリに対応するポート番号が含まれる。このような機能は、通常のブラウザB1に備わるものである。
【００５６】
例えば、「Memo(メモ)」アプリの選択に対して応答されたリダイレクトメッセージにより、対応するリダイレクト先「http://172.0.0.1/Memoapp.html」に対して、指示されたポート番号「3001」によるhttpリクエスト「http://172.0.0.1:3001/Memoapp.html」を出す。
【００５７】
なお、ステップS8のリダイレクトメッセージを受信した時点で、ゲートウェイG1とブラウザB1との間での80番ポートを利用した通信は終わる。ステップS9以降では、各アプリA1とブラウザB1との間での通信が、80番ポートとは別に当該指定されたポート番号を利用して開始される。
【００５８】
当該ステップS9以降の処理、例えばステップS10として示すアプリレスポンス等に関しては、各アプリに記述された処理に従ってなされ、ウェブサービスが提供される。アプリを終了する際は、ステップS11に示すようにブラウザB1よりアプリA1へと終了リクエストを送信してもよい。
【００５９】
以下、本発明によるゲートウェイG1による第一の効果として、ブラウザB1におけるセキュリティや安全性が向上することを説明する。図4は、ゲートウェイG1を利用しない場合に、ブラウザB1(クライアント20)において確保されるデータ領域の例R80を示している。図5は、ゲートウェイG1を利用する場合に、ブラウザB1において確保されるデータ領域の例R3001及びR3002を示している。
【００６０】
ブラウザB1は、ウェブストレージ（Web Storage）やクッキー（Cookie）などのデータ領域を、オリジン毎に確保する。ウェブストレージは、ローカルストレージ（Local Storage）とセッションストレージ（Session Storage）に大別されるが、クッキーも含めて、役割としては、アプリ毎のデータの保持である。オリジンとは、ドメイン名とポート番号の組み合わせで構成される識別子である。ウェブストレージやクッキーは、このオリジン毎に管理される。
【００６１】
従って、ドメイン名（ここでは、IPアドレスとして表記）が例えば「172.0.0.1」であるサーバ10に対して、ゲートウェイG1を利用しない図4では、どのようなアプリを利用する場合であっても、単純なサーバ機能によってデフォルト設定のポート番号80（又は特定の単独ポート番号のみ）でアクセスする。従って図4の例では、例えばポート番号80でアクセスするのであれば、サーバ10ではどのようなアプリであっても、オリジン「172.0.0.1:80」の領域R80のみしか確保されない。
【００６２】
一方、ゲートウェイG1を利用する図5では、サーバ10に対して図2に例示したような「Memo(メモ)」アプリ専用に構築されたオリジン「172.0.0.1:3001」の領域R3001と、「Gallery(画像閲覧)」アプリ専用に構築されたオリジン「172.0.0.1:3002」の領域R3002と、…といったようにアプリ毎に記憶領域が用意される。
【００６３】
ここで、図4のようにポート番号による区別を設けないとすると、同一ドメイン以下に置かれているアプリケーションは、ドメイン上でのパスが異なっていても、同一オリジンとなる。従って、例えば、あるアプリでウェブストレージの値を書き換えた後に、別のアプリでウェブストレージの値に依存した処理を実行した際に、図4の場合、当該値が上書きされるなどして、意図しない動作となるケースがありうる。しかしながら、図5の場合、そのような問題は生じない。
【００６４】
図6は、ウェブストレージ「A」に格納する値が、別途のアプリから参照・更新される一連の流れの例であり、ゲートウェイG1を利用しない場合に問題が発生する例となっている。
【００６５】
ステップS101では、ユーザが起動した「Gallery(画像閲覧)」アプリによりウェブストレージ「A」が空である場合、「"image.com/"」を格納してから、当該「A」を用いた処理がなされる。ステップS102では、その後別途ユーザが起動した「Memo(メモ)」アプリによって、「A」に「"memo.com/"」を格納してから、当該「A」を用いた処理がなされる。ステップS103はステップS101と同様であり、再度ユーザは「Gallery(画像閲覧)」アプリによる処理を行う。
【００６６】
図4の領域R80においては、ステップS102にて意図されず「image.com/」から「memo.com/」へと上書きされた「A」によって、ステップS103が実施されてしまうが、図5の例では領域R3001及びR3002に区別されることで、このような問題は生じない。
【００６７】
すなわち、ゲートウェイG1によってアプリA1毎にポート番号を切り替えた上で、ブラウザB1側にサービスを提供するため、異なるオリジンとしてブラウザB1側で認識され、ウェブストレージやクッキーといったストレージがアプリ毎に分離した状態でアプリを実行することができる。このことにより、あるアプリの操作が、別のアプリの操作に影響することを防止することができ、セキュリティや安定性を高めることができる。
【００６８】
また、本発明による効果は、サーバ10及びクライアント20の各ユーザの観点からは、以下の通りである。当該各ユーザは、ネットワーク管理の専門家等ではなく、一般ユーザであってよい。
クライアント20側のユーザ視点では、ブラウザからアクセスする際には、特にポート番号を意識せずに、サーバ10のURIにアクセスすることで、サーバ側にあるアプリ一覧を知ることができる。また、上記第一の効果として説明したように、実行する各アプリが異なるオリジンと認識されるため、セキュリティが担保されかつ安定的な動作するアプリを利用できる。
【００６９】
サーバ10側のユーザ視点では、以下に第二の効果として説明するように、アプリをインターネット上からインストールした際に、クライアント20側に公開するアプリか否かを簡単に登録することができ、かつポート番号を自分で割り振らなくて済む。アプリ提供者としても、セキュリティを担保して安定的な動作するアプリを配布できると言える。
【００７０】
すなわち、ゲートウェイG1を利用しない場合、プラットフォームP1側でアプリのインストールが行われた際に、一般の単純なサーバ機能を持つアプリでは、プラットフォームとの連動は考慮されないため、アプリがインストールされたことを検知しない。そのため、アプリが登録される度に、登録アプリテーブルをサーバ端末の所持者が手動で更新する必要がある。
【００７１】
従来型のサーバの利用の仕方であれば、サーバの所持者は、一般に開発者であり、インストール自体（ウェブ文書（ウェブアプリ）の追加）の頻度も多くはないという前提のため、手動で更新する場合であっても、ウェブ文書の編集であるため、手間を除けば、問題は大きくない。
【００７２】
しかしながら、本発明にて想定しているサーバの利用の仕方においては、サーバ10の所持者のほとんどが一般ユーザであり、かつ頻繁にインストール・アンインストールが行われるため、ウェブ文書の編集という更新作業自体が煩雑かつ手間が大きいことは、利便性の観点で問題である。
【００７３】
この点に関して本発明によれば、アプリ管理部11で図2の例のようにして、ユーザは所定項目を選択するだけで、その他の必要設定が自動で構築され、インデックス応答部13の応答するウェブ文章なども自動更新されるので、容易に登録を行うことができる。
【００７４】
すなわち、ゲートウェイG1では、インストール時にプラットフォームP1側で発生したイベントを検知し、それに応じて、アプリ管理部11が起動されることで、アプリ登録をユーザ側に促す。なお、ユーザが明示的にアプリ管理部11を起動してインストールを行うようにしてもよい。
【００７５】
ユーザの選択によって、アプリ登録（登録アプリテーブルへの記載）を行うか否かは、決定されるが、登録する場合は、図2で説明したように、所定メニューなどから選択する等の簡単な作業のみで、自動的に登録することができる。これにより、インストールが頻繁に起こった際にも、ウェブ文章等をその都度マニュアル修正する必要なく、手間なく簡単にアプリを登録することができ、利便性を高めることができる。
【００７６】
さらに、第三の効果として、アプリ起動部14の働きによって、クライアント20からのリクエストを処理するのに必要なアプリが自動起動される。従って、サーバ10が携帯端末等であってアプリの起動・終了が頻繁に行われる状況であっても、確実にウェブサービスを提供することが可能となる。
【００７７】
また、当該第三の効果により、サーバ10は、クライアント20からのリクエストを受信してウェブサービスの提供を実施している場合以外は、当該サーバ10の保有者(携帯端末などとしてのサーバ10の保有者)が所望のアプリのみを実行することが可能となる。
【００７８】
なお、本発明における補足事項として以下がある。
【００７９】
リクエスト受付部12では、クライアント20として、予め設定されたクライアントからのみ、リクエストを受け付けるようにしてもよい。このため、許可したクライアントのID等を予め登録しておき、IDが一致したクライアントからのリクエストに対してのみ、インデックス応答部13以降の処理を実施して、サーバ10によるウェブサービスの提供を実施する。設定されていないクライアントからリクエストがあった場合は、インデックス応答部13のインデックス応答を行わず、サーバ10によるウェブサービスの提供を行わない。
【符号の説明】
【００８０】
1…アプリ連携システム、10…サーバ、20…クライアント、11…アプリ管理部、12…リクエスト受付部、13…インデックス応答部、14…アプリ起動部、15…リダイレクト部、16…アプリ機能部
【図１】
2014191805.tif 000003
【図２】
2014191805.tif 000004
【図３】
2014191805.tif 000005
【図４】
2014191805.tif 000006
【図５】
2014191805.tif 000007
【図６】
2014191805.tif 000008