(57)【要約】      （修正有）【課題】モバイル端末上で動作するモバイル・アプリケーションが、別のアプリケーション中のURIで示される、イントラネット内のリソースにアクセスできるようにする技法を提供する。【解決手段】モバイル端末が、特定のイントラネット向けURIでグローバルDNSサーバにアクセスし、グローバルDNSサーバが名前解決によりイントラネット・ドメイン・アクセス・リゾルバのIPアドレスを返すと、IPアドレス先のイントラネット・ドメイン・アクセス・リゾルバにHTTP接続を行い、特定のイントラネット向けURIの一部を送る。イントラネット・ドメイン・アクセス・リゾルバは、イントラネット向けURIをエンコードし、303(See other)とともに、新しいURIを返す。モバイル端末は、返されたURIをパースし、デコードして得られた情報を元に、ゲートウェイを介してイントラネットにアクセスを試みる。【選択図】図７
2014139708.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータの処理によって実装されるシステムであって、
特定のイントラネット・ドメインのサーバへ所定のプロトコルでアクセス可能なURIに対応付けられたリソースをもつ、イントラネット・システムと、
前記イントラネット・システムの外と内の境界にあり、前記イントラネット・ドメインのURIに含まれている情報を用いて、前記イントラネット・ドメインのURIに対応する、前記イントラネット・システム内のリソースにアクセス可能な、ゲートウェイ・サーバと、
前記イントラネット・システムの外にある端末装置上にあり、特定のURIスキームに対応付けられて起動し、起動した際のURI中に与えられた、前記URIを示す情報をデコードし、前記ゲートウェイ・サーバと通信して、前記リソースにアクセスするクライアント・アプリケーションと、
前記端末装置から、前記イントラネット・ドメインのURIでアクセスされたことに応答して、前記イントラネット・ドメインのURIを、前記クライアント・アプリケーションを起動するように対応付けられたスキームに、前記イントラネット・ドメインのURIをエンコードしたURIを付加して生成されたURIを返す、イントラネット・ドメイン・アクセス・リゾルバを有し、
以って前記端末装置上のウェブブラウザなどの別のアプリケーションから、前記イントラネット・ドメインのURIにアクセスした際に、前記クライアント・アプリケーションを起動して前記ゲートウェイ・サーバ経由で、前記生成したURIを用いて、前記リソースにアクセスすることを可能ならしめる、
システム。
【請求項２】
前記所定のプロトコルがHTTPまたはHTTPSプロトコルである、請求項１に記載のシステム。
【請求項３】
前記前記イントラネット・ドメインのURIによる問い合わせに応答して、前記イントラネット・ドメイン・アクセス・リゾルバのIPアドレスを返す、グローバルDNSサーバをさらに有する、請求項２に記載のシステム。
【請求項４】
前記イントラネット・ドメイン・アクセス・リゾルバが、前記生成したURIを、HTTP 303レスポンスとともに返す、請求項２に記載のシステム。
【請求項５】
前記クライアント・アプリケーションが、
前記変換されたURIに対して、URIスキームと':'をスキップする手段と、
URIの残りの部分をデコードする手段と、
デコードされたURIをパースする手段と、
パス及びパラメータを抽出する手段を含む、
請求項２に記載のシステム。
【請求項６】
前記端末装置が、スマート・フォンである、請求項１に記載のシステム。
【請求項７】
前記クライアント・アプリケーションが、
前記ゲートウェイの要求する認証情報を、前記端末装置のユーザに要求する手段と、
得られた前記認証情報を一時的に記憶する手段とを有し、
前記記憶された認証情報を以って、その後の前記クライアント・アプリケーション経由の前記リソースへのアクセスにはユーザに認証情報を求めないようにする、
請求項１に記載のシステム。
【請求項８】
特定のイントラネット・ドメインのサーバへ所定のプロトコルでアクセス可能なURIに対応付けられたリソースをもつ、イントラネット・システムと、
前記イントラネット・システムの外と内の境界にあり、前記イントラネット・ドメインのURIに含まれている情報を用いて、前記イントラネット・ドメインのURIに対応する、前記イントラネット・システム内のリソースにアクセス可能な、ゲートウェイ・サーバと、
前記イントラネット・システムの外にある端末装置上にあり、特定のURIスキームに対応付けられて起動し、起動した際のURI中に与えられた、前記URIを示す情報をデコードし、前記ゲートウェイ・サーバと通信して、前記リソースにアクセスするクライアント・アプリケーションとをもつシステムにおいて、コンピュータの処理によって実装される方法であって、
イントラネット・ドメイン・アクセス・リゾルバを更に有し、
該イントラネット・ドメイン・アクセス・リゾルバが、前記端末装置から、前記イントラネット・ドメインのURIに含まれる情報でアクセスされたことに応答して、前記クライアント・アプリケーションを起動するように対応付けられたURIスキームに、前記URIをエンコードしたURIを付加して生成されたURIを返すステップと、
前記モバイル端末が、前記イントラネット・ドメインのURIにアクセスした際に、前記クライアント・アプリケーションを起動して前記ゲートウェイ・サーバ経由で、前記イントラネット・ドメイン・アクセス・リゾルバから返された前記URIに基づき、前記リソースにアクセスするステップを有する、
方法。
【請求項９】
前記所定のプロトコルがHTTPまたはHTTPSプロトコルである、請求項８に記載の方法。
【請求項１０】
グローバルDNSサーバをさらに有し、該グローバルDNSサーバが、前記前記イントラネット・ドメインのURIによる問い合わせに応答して、前記イントラネット・ドメイン・アクセス・リゾルバのIPアドレスを返すステップをさらに有する、請求項９に記載の方法。
【請求項１１】
前記イントラネット・ドメイン・アクセス・リゾルバが、前記生成したURIを、HTTP 303レスポンスとともに返す、請求項９に記載の方法。
【請求項１２】
前記クライアント・アプリケーションが、
前記変換されたURIに対して、URIスキームと':'をスキップするステップと、
URIの残りの部分をデコードするステップと、
デコードされたURIをパースするステップと、
パス及びパラメータを抽出するステップを実行する、
請求項９に記載の方法。
【請求項１３】
前記端末装置が、スマート・フォンである、請求項８に記載の方法。
【請求項１４】
前記クライアント・アプリケーションが、
前記ゲートウェイの要求する認証情報を、前記端末装置のユーザに要求する手段と、
得られた前記認証情報を一時的に記憶する手段とを有し、
前記記憶された認証情報を以って、その後の前記クライアント・アプリケーション経由の前記リソースへのアクセスにはユーザに認証情報を求めないようにする、
請求項８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、モバイル端末などから、ウェブサーバ上の情報あるいはアプリケーションにアクセスする技法に関する。
【背景技術】
【０００２】
最近になって、業務の利便性を高めるために、ビジネスマンが外出時にスマート・フォンなどのモバイル端末を携行する傾向にある。しかし、主としてセキュリティ的な理由により、モバイル端末は一般的に、企業のイントラネットへのアクセスを許されていない。すなわち、限られたモバイル・アプリケーションだけがイントラネット・リソースにアクセス可能であり、イントラネットURIは、イントラネットの外からはアクセス可能ではない。
【０００３】
例えば、モバイル端末において、eメールやチャット・メッセージ中に埋め込まれたイントラネット・ウェブSNS文書に対するURIリンクは、使用することができない。
【０００４】
特開２００２−１８３５９６号公報は、情報の伝達、流通を迅速に行うためにｉモードサービス、ｗｗｗサーバ、非公開認証サーバ、認証エージェントサーバを使用目的に応じて構成する。機密性の高い処理には実アドレスをマスクした仮想ＵＲＬを発行し、所定時間内にクライアントはメールを返信して決済するウェブビジネスにおける電子商取引のサーバシステムを開示する。
【０００５】
しかし、ここで提案される仮想ＵＲＬは、取引の認証のため認証サーバによって発行されるものであり、イントラネット内のリソースにアクセスする目的では使用できない。
【０００６】
イントラネット内のリソースにアクセスすることを許容するために、モバイル端末に、従来知られているVPN/プロキシ技法を使用することは、通常のセキュリティ・ポリシー上許容されない。これは、モバイル端末上の信頼性の低いその他のアプリケーションにもイントラネット・リソースにアクセス可能にしてしまうためである。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００２−１８３５９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
この発明の目的は、モバイル端末上で動作するモバイル・アプリケーションが、別のアプリケーション中で与えられたURIによって指し示される、イントラネット内のリソースにアクセスできるようにする技法を提供することにある。
【課題を解決するための手段】
【０００９】
この発明によれば、イントラネット・ドメイン・アクセス・リゾルバというサーバが設けられ、グローバルDNSサーバが、モバイル端末のメールなどに含まれる特定のイントラネット向けURIに対して、イントラネット・ドメイン・アクセス・リゾルバのIPアドレスが返されるように設定される。
【００１０】
すると、モバイル端末が、そのような特定のイントラネット向けURIでグローバルDNSサーバにアクセスし、グローバルDNSサーバが名前解決によりイントラネット・ドメイン・アクセス・リゾルバのIPアドレスを返すと、モバイル端末は、IPアドレス先のイントラネット・ドメイン・アクセス・リゾルバにHTTP接続を行い、特定のイントラネット向けURIに相当する情報を送る。実際にはURI中のスキーム部とオーソリティ部（ユーザ名、ドメイン、ポート）の情報は送られず、パスとそれに続く部分（パス、クエリ、フラグメント）の情報のみ送られるが、スキーム部とオーソリティ部はイントラネット・ドメイン・アクセス・リゾルバの構成上与えられている情報であるため、パス情報から元のURIを再構築できる。
【００１１】
イントラネット・ドメイン・アクセス・リゾルバは、このようにしてモバイル端末から送られたイントラネット向けURIをエンコードし、303 (See other)とともに、モバイル端末内の専用アプリケーションに対応付けられたスキームにエンコードしたイントラネット向けURIを付加して作られる新しいURIを返す。
【００１２】
モバイル端末は、303 (See other)と共に返された新しいURIを、モバイル端末内の専用アプリケーション(クライアント・アプリケーションとも称する)に提供し、これにより、専用アプリケーションは、図６のフローチャートに示す処理により、パースされた新しいURI中の元のURIをデコード、パースして得られる情報を用いて、ゲートウェイを介してイントラネット上のリソースにアクセスを試みる。その際、ゲートウェイは、モバイル端末に対して、ユーザーIDとパスワードで、認証を行う。
【発明の効果】
【００１３】
この発明によれば、モバイル端末から、イントラネット・ドメイン・アクセス・リゾルバを経て専用アプリケーションに適切にリダイレクトされることにより、イントラネット上のリソースにアクセスが図られるという効果が得られる。
【図面の簡単な説明】
【００１４】
【図１】本発明を実施するためのハードウェア構成の概要を示す図である。
【図２】ハードウェア構成におけるサーバの内部構成のブロック図である。
【図３】イントラネット・ドメイン・アクセス・レゾルバの機能構成を示す図である。
【図４】サービス・セットアップの処理のフローチャートを示す図である。
【図５】専用アプリケーションの開始または再開のフローチャートを示す図である。
【図６】専用アプリケーションにおける、URIをパースする処理のフローチャートを示す図である。
【図７】本発明の処理の概要を示す図である。
【図８】スマート・フォンと、イントラネット・ドメイン・アクセス・レゾルバの間のセッションを示す図である。
【発明を実施するための形態】
【００１５】
以下、図面に従って、本発明の実施例を説明する。これらの実施例は、本発明の好適な態様を説明するためのものであり、発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断わらない限り、同一符号は、同一の対象を指すものとする。
【００１６】
図１は、本発明のハードウェアの全体の概要構成を示す図である。図１において、グローバルDNSサーバ１０２が、インターネット１０４に接続され、さまざまなサーバなどからアクセス可能である。グローバルDNSサーバ１０２は、URI中のドメイン名を受け取り、名前解決して、そのURIに対するIPアドレスを返す機能をもつ。
【００１７】
インターネット１０４には更に、イントラネット１０６に入るためのゲートウェイ・サーバ１０８、１１０及び１１２が接続されている。ゲートウェイ・サーバ１０８、１１０及び１１２は各々、HTTP、FTP、SMTPなどの異なるプロトコルに対応する。
【００１８】
イントラネット１０６は例えば、特定の企業のファイアーウォール内のシステムであって、イントラネットDNSサーバ１１４、１１６、１１８、クライアント・コンピュータ１２０ａ、１２０ｂ、・・・、１２０ｎなどが接続されている。
【００１９】
なお、図１の構成は実際は適宜、ルータやスイッチを含むが、周知の構成要素なので、図示を省略していることを理解されたい。
【００２０】
スマート・フォン１２４ａ、・・・１２４ｋは、パケット通信網１２２を介して、インターネット１０４に接続され、その結果、スマート・フォン１２４ａ、・・・１２４ｋは、インターネット１０４上のさまざまなシステムにアクセス可能である。尚、スマート・フォン１２４ａ、・・・１２４ｋは、WiFiなどの無線LAN基地局(図示しない)を介してインターネット１０４に接続されてもよい。
【００２１】
インターネット１０４には更に、本発明に特徴的な機能を提供するサーバである、イントラネット・ドメイン・アクセス・リゾルバ１２６が接続されている。
【００２２】
グローバルDNSサーバ１０２は、特定のイントラネット向けURIによる問い合わせに対して、イントラネット・ドメイン・アクセス・リゾルバ１２６のIPアドレスを返すように設定されている。
【００２３】
イントラネット・ドメイン・アクセス・リゾルバ１２６は、URIをエンコードするためのURIマッピング・パターン３０８（図３）をもち、特定のイントラネット内リソース向けURIであるpathを以ってGET pathによりアクセスされたとき、そのpathをマッピング・パターン３０８とマッチングし、URIマッピング・パターンと対応付けられたスキーム（特定のモバイル・アプリケーションに対応付けられる）に再構成しエンコードしたURI情報を付加し、303 (See other)のリターン・コードを返す機能をもつ。
【００２４】
スマート・フォン１２４ａ、・・・１２４ｋには、イントラネット・ドメイン・アクセス・リゾルバ１２６からの303 (See other)に応答して、イントラネット・ドメイン・アクセス・リゾルバ１２６から送られたURIをデコードする機能をもつ専用アプリケーション１２４ａ−１、・・・、１２４ｋ−１(後述)が、導入されている。
【００２５】
図２は、グローバルDNSサーバ１０２、ゲートウェイ・サーバ１０８、１１０及び１１２、サーバ１１４、１１６及び１１８、イントラネット・ドメイン・アクセス・リゾルバ１２６の共通の構成を示す。ここでは単にサーバ２００と総称する。
【００２６】
サーバ２００の通信インターフェース２０２は、ネットワークに接続される。通信インターフェース２０２はさらに、バス２０４に接続され、バス２０４には、ＣＰＵ２０６、主記憶（ＲＡＭ）２０８、及びハードディスク・ドライブ（ＨＤＤ）２１０が接続されている。
【００２７】
図示しないが、サーバ２００にはさらに、キーボード、マウス、及びディスプレイが接続され、これらによって、保守担当者が、サーバ２００全体の管理やメンテナンス作業を行うようにしてもよい。
【００２８】
サーバ２００のハードディスク・ドライブ２１０には、オペレーティング・システムが保存されている。ハードディスク・ドライブ２１０には好適には、Ｊａｖａ（Ｒ）仮想環境を実現するＪａｖａ（Ｒ）  ＥＥが導入されている。
【００２９】
サーバ２００のハードディスク・ドライブ2１０には、好適には、IBM(R) WebSphere(商標) Application Server(WAS)が導入されている。
【００３０】
尚、上記サーバ２００として、これには限定されないが、インターナョナル・ビジネス・マシーンズ・コーポレーションから購入可能な、IBM(R) System X、System i、System pなどの機種のサーバを使うことができる。その際、使用可能なオペレーティング・システムは、AIX（商標）、UNIX(の商標)、Linux(商標)、Windows(商標)2003 Serverなどがある。
【００３１】
図３は、イントラネット・ドメイン・アクセス・リゾルバ１２６の本発明に関連する機能の機能ブロックを示す図である。図３において、メイン・プログラム３０２は、全体の動作を制御する機能をもつ。
【００３２】
通信モジュール３０４は、インターネット１０４に接続されているサーバ、その他の機器から、イントラネット・ドメイン・アクセス・リゾルバ１２６として設定されているIPアドレスを使用して送られてきたデータを受信し、あるいは、データを送ってきたサーバまたは機器に応答を返す機能をもつ。この実施例では、スマート・フォン１２４ａ、・・・、１２４ｋがパケット通信網１２２及びインターネット１０４を介して通信モジュール３０４にアクセスしてくる。
【００３３】
URIエンコーダ３０６は、通信モジュール３０４が受信したURIを、URIマッピング・パターン３０８の情報に基づいてスキームを選択し、変換されたURIを与える機能をもつ。
【００３４】
URIマッピング・パターン３０８の情報は、事前に設定可能であり、URIをパースして、モバイル・アプリケーション・スキームに変換するために使用される。そのため、モバイル・アプリケーション・スキームがapplnconnsであるとすると、URIマッピング・パターン３０８は、{https,".*"}=>applnconnsや、{http,".*"}=>applnconnsのような情報を含む。モバイル・アプリケーション・スキームに対応付けられるモバイル・アプリケーションの例として、インターナショナル・ビジネス・マシーンズ・コーポレーションから提供される、Lotus(R) Connectionsがある。
【００３５】
メイン・プログラム３０２は、URIエンコーダ３０６が、所定のURIをエンゴードし、エンコードされたURIを出力したとき、通信モジュール３０４を介して、URIを送ってきたサーバまたは機器に、303 (See other)の応答とともに、エンコードされたURIを返す。
【００３６】
次に、図４以下のフローチャートを参照して、本発明の処理について説明する。図４は、サービス・セットアップの処理を示す図である。図４に示す処理は、好適には、イントラネット１０６内にあるクライアント・コンピュータをオペレータが操作することによってセットアップ・プログラムが実行される。
【００３７】
ステップ４０２では、セットアップ・プログラムが、スマート・フォン１２４ａがアクセスするイントラネット内のサービスを開始し、そのサービスをイントラネットDNSサーバ１１４に登録する。
【００３８】
ステップ４０４では、セットアップ・プログラムが、ゲートウェイ・サーバ１０８、１１０及び１１２を開始する。
【００３９】
ステップ４０６では、イントラネット・ドメイン・アクセス・レゾルバ１２６を開始し、それをグローバルDNSサーバ１０２に登録する。これにより、所定のイントラネットURIに応答して、グローバルDNSサーバ１０２がイントラネット・ドメイン・アクセス・レゾルバ１２６のIPアドレスを返す。
【００４０】
ステップ４０８では、セットアップ・プログラムが、イントラネット・ドメイン・アクセス・レゾルバ１２６中に、URIマッピングを登録する。
【００４１】
次に、図５のフローチャートを参照して、スマート・フォン１２４ａにおける、専用アプリケーションの開始または再開の処理について説明する。
【００４２】
図５のステップ５０２では、スマート・フォン１２４ａは、URIが開かれたかどうか、すなわち、スマート・フォン１２４ａのユーザがメールに書かれているURIをクリックしたかどうか判断する。
【００４３】
ステップ５０２で、ユーザがメールに書かれているURIをクリックしたなら、スマート・フォン１２４ａは、好適にはSafari(商標)などのブラウザを立ち上げ、そのURI中のドメイン名をグローバルDNSサーバ１０２に送る。メールに書かれているURIが、イントラネットではない普通のURIであるなら、グローバルDNSサーバ１０２は対応するウェブサーバのIPアドレスを返すので、スマート・フォン１２４ａのブラウザがそのIPアドレスのサイトを表示することになる。
【００４４】
メールに書かれているURIが、所定のイントラネットURIであるなら、グローバルDNSサーバ１０２はイントラネット・ドメイン・アクセス・レゾルバ１２６のIPアドレスを返すので、スマート・フォン１２４ａは、そのIPアドレスでイントラネット・ドメイン・アクセス・レゾルバ１２６にHTTP接続し、URIのスキームとドメイン名などのオーソリティ部を除いたpath部分でGET pathを試みる。
【００４５】
すると、イントラネット・ドメイン・アクセス・レゾルバ１２６がURIをエンコードし、エンコードされた結果を特定のスキームのターゲット・リソースとしてセットし、その新しいURIを、303 (See other)というリターンコードとともに、スマート・フォン１２４ａに返す。
【００４６】
スマート・フォン１２４ａは303 (See other)と新しいURIのスキームに応答してエンコードされた元のURIを、専用アプリケーション１２４ａ−１に与えて起動し、専用アプリケーション１２４ａ−１は、与えられたターゲット・リソースをステップ５０４でパース(デコード)して、ステップ５０６でパースされた結果からターゲット・リソースをセットし、ゲートウェイ１０８、１１０及び１１２を介してイントラネット１２６に入り、イントラネットDNSサーバ１２６に問い合わせて目的のリソースにたどりつき、ステップ５０８で、それを表示する。なお、ゲートウェイ１０８、１１０及び１１２に対して、専用アプリケーション１２４ａ−１は、一般的には、ユーザーIDとパスワードで認証を行う。このあと、ステップ５１２で、専用アプリケーション１２４ａ−１は、ユーザの操作を待ち、ステップ５１４で操作が終了または中止でないと判断した場合、ステップ５０８で目的のリソースを表示する。
【００４７】
ステップ５０２でURIが開かれていない場合は、専用アプリケーション１２４ａ−１は、ステップ５１０で必要に応じてユーザーIDとパスワードで認証を行ってナビゲーションUIを表示し、ステップ５１２でユーザの操作を待ち、ステップ５１４で操作が終了または中止でないと判断した場合、ステップ５０８で目的のリソースを表示する。この場合も、一般的には、ユーザーIDとパスワードで認証を行う。
【００４８】
ステップ５１４で操作が終了または中断であると判断した場合、処理は終了または中断する。
【００４９】
次に図６のフローチャートを参照して、スマート・フォン１２４ａの専用アプリケーション１２４ａ−１が、URIをパースするステップ５０４について説明する。ここで、スマート・フォンが、applnconns:https%3A%2F%2Fw3-connections.company.com%2FcommunityView%3F%0BcommunityUuid%3D9f0b495%26file%3Da1988063を、スマート・フォン１２４ａから渡されるものとする。スキームapplnconns:は、専用アプリケーション向けであることを示すプリフィックスであり、具体的なアプリケーションに応じて、様々なプリフィックスが使用される。
【００５０】
図６のステップ６０２では、専用アプリケーション１２４ａ−１のURIパーサは、URIスキーム、すなわちapplnconns:及び、':'をスキップする。すなわち、applnconns:https%3A%2F%2Fw3-connections.company.com%2FcommunityView%3F%0BcommunityUuid%3D9f0b495%26file%3Da1988063の applnconns:をスキップする。
【００５１】
ステップ６０４では、専用アプリケーションのURIパーサは、URIの残りの部分をデコードする。デコードされた結果は、https://w3-connections.company.com/communityView?communityUuid=9f0b495&file=a1988063となる。
【００５２】
ステップ６０６では、専用アプリケーションのURIパーサは、デコードされたHTTP/HTTPS URI、https://w3-connections.company.com/communityView?communityUuid=9f0b495&file=a1988063をパースする。
【００５３】
ステップ６０８では、専用アプリケーションのURIは、デコードされたURIスキーム、ホスト及びポートをスキップまたは検証する。すなわちhttps://w3-connections.company.com/communityView?communityUuid=9f0b495&file=a1988063のhttps://w3-connections.company.comをスキップまたはそうであることを確認する。
【００５４】
ステップ６１０では、専用アプリケーションのURIは、パス及びパラメータ、すなわち、communityUuid=9f0b495と、file=a1988063を抽出する。
【００５５】
次に、図７と図８を参照して、本発明による具体的な処理を図式的に説明する。
【００５６】
図７において、スマート・フォン１２４ａのユーザが、メール中のイントラネットURIであるhttps://w3-connections.company.com/communityView?communityUuid=9f0b495&file=a1988063をクリックすると、スマート・フォン１２４ａは、グローバルＤＮＳサーバ１０２に、このURIのIPアドレスを問い合わせする。通常であれば、グローバルＤＮＳサーバ１０２は、イントラネットURIの名前解決をすることができないので、404 (Not found)を返すか、ソリー・サーバに案内するだけであるが、この発明によれば、イントラネットURIに対してグローバルＤＮＳサーバ１０２は、イントラネット・ドメイン・アクセス・レゾルバ１２６のIPアドレスを返すように設定されているので、この返されたIPアドレスで以て、スマート・フォン１２４ａは、GET /communityView?communityUuid=9f0b495&file=a1988063 HTTP/1.1で、イントラネット・ドメイン・アクセス・レゾルバ１２６にリクエストする。
【００５７】
すると、イントラネット・ドメイン・アクセス・レゾルバ１２６が、https://w3-connections.company.com/communityView?communityUuid=9f0b495&file=a1988063に基づき、URIマッピング・パターンを参照してエンコードすることにより、applnconns:https%3A%2F%2Fw3-connections.company.com%2FcommunityView%3F%0BcommunityUuid%3D9f0b495%26file%3Da1988063を生成し、303 (See other)というHTTP応答とともにスマート・フォン１２４ａに返す。
【００５８】
すると、図８に示すように、スマート・フォン１２４ａは、返された、転送先のURIである、applnconns:https%3A%2F%2Fw3-connections.company.com%2FcommunityView%3F%0BcommunityUuid%3D9f0b495%26file%3Da1988063の先頭のapplnconns:をみて、専用アプリケーションにこのURIを渡す。
【００５９】
専用アプリケーションは、applnconns:https%3A%2F%2Fw3-connections.company.com%2FcommunityView%3F%0BcommunityUuid%3D9f0b495%26file%3Da1988063を分解（先頭applnconns:のスキップ）し、https%3A%2F%2Fw3-connections.company.com%2FcommunityView%3F%0BcommunityUuid%3D9f0b495%26file%3Da1988063をデコードし、得られたhttps://w3-connections.company.com/communityView?communityUuid=9f0b495&file=a1988063をパースし、得られたパラメータ情報communityUuid=9f0b495、file=a1988063を以ってゲートウェイ・サーバ１０８、１１０及び１１２にアクセスする。その際、ゲートウェイ・サーバは、専用アプリケーションに、ユーザIDとパスワードを求めて、それにより認証する。この際、一度認証されたら、認証されたという結果を専用アプリケーション側で保持しておき、一定期間、それを再使用するようにしてもよい。
【００６０】
こうして、スマート・フォン１２４ａの専用アプリケーションは、認証されると、ゲートウェイ・サーバを介してイントラネット１０６に入ることができる。ゲートウェイ・サーバへのアクセスの仕方や、アクセスに応じたゲートウェイ・サーバによるイントラネット・リソースへのアクセスの仕方はゲートウェイ・サーバの構成によって様々変わり得るが、例えば、イントラネット内のウェブブラウザなどのクライアント用のHTTPプロトコルによってイントラネット・リソースにアクセスするとすれば、イントラネット１０６に入ると、イントラネットDNSサーバ１１４に問い合わせて名前解決し、イントラネットURI https://w3-connections.company.com/communityView?communityUuid=9f0b495&file=a1988063へのHTTP接続により、目的のイントラネット・リソースにアクセスする。
【００６１】
以上、この発明を、Java(R)など特定のハードウェア及びソフトウェアを用いた実施例として説明してきたが、この発明は特定のハードウェア、ソフトウェア及びプラットフォームに限定されるものでなく、任意のプラットフォームに適用可能であることを理解されたい。
【００６２】
また、イントラネットURIへのアクセスを試みるのは、スマート・フォンに限定されず、より一般のモバイル端末でよく、あるいは通常のモバイルPCのような機器であってもよい。
【符号の説明】
【００６３】
１０２・・・グローバルDNS
１０４・・・インターネット
１０６・・・イントラネット
１０８・・・ゲートウェイ
１１０・・・ゲートウェイ
１１２・・・ゲートウェイ
１１４・・・イントラネットDNS
１２０・・・クライアント・コンピュータ
１２４ａ、・・・１２４ｋ・・・スマート・フォン
１２４ａ−１、・・・１２４ｋ−１・・・スマート・フォンの専用アプリケーション
１２６・・・イントラネット・ドメイン・アクセス・レゾルバ
【図１】
2014139708.tif 000003
【図２】
2014139708.tif 000004
【図３】
2014139708.tif 000005
【図４】
2014139708.tif 000006
【図５】
2014139708.tif 000007
【図６】
2014139708.tif 000008
【図７】
2014139708.tif 000009
【図８】
2014139708.tif 000010