JP5499524B2 - 中継プログラムおよび中継装置 - Google Patents

Description

本発明は、ネットワークを介して提供されるアプリケーションプログラム（以下、単に「アプリケーション」という）における情報管理に関する。

従来、一般的にはアプリケーションの利用にあたって、利用者は、アプリケーションを記憶した記憶媒体またはアプリケーションの使用権を購入し、コンピュータのローカルディスクにアプリケーションをインストールしていた。そして、コンピュータが、ローカルディスクにインストールされたアプリケーションを実行していた。

しかし、近年では、このような事前の購入およびインストールを必要としないプログラムの提供形態が注目を集めている。
例えば、ブラウザベースのウェブアプリケーションを利用するためには、利用者は、クライアント上で稼働するウェブブラウザ（以下では単に「ブラウザ」という）によりウェブアプリケーション提供者のウェブサイトにアクセスする。すると、利用者は、クライアントにアプリケーションプログラムを事前にインストールする必要なしに、ウェブアプリケーションを利用することができる。もちろん、利用者は、もしサービスが有料であれば使用料を支払う必要がある。しかし、ネイティブアプリケーションとは異なり、ブラウザベースのウェブアプリケーションの利用においては、インストールの手間が不要である。

上記のようにアプリケーションをサービスとして提供する提供者は、「ＡＳＰ（Application Service Provider）」と呼ばれる。また、アプリケーションなどのソフトウェアをサービスとして提供するというモデルは「ＳａａＳ（Software as a Service）」と呼ばれる。ネットワークを介してサービスとして提供されるアプリケーション自体が「ＳａａＳアプリケーション」と呼ばれることもある。

ＳａａＳアプリケーションの多くは、事前にアプリケーションをクライアントにインストールすることが不要な、ブラウザベースのウェブアプリケーションである。また、無料のＳａａＳアプリケーションもあるし、「サービスの利用料として対価を得る」というビジネスモデルに基づく有料のＳａａＳアプリケーションもある。

ところで、ＳａａＳアプリケーションの特徴の１つは、利用者のデータがサーバ側に保存されることである。例えば、スケジューラ機能を提供するＳａａＳアプリケーションの場合、利用者が入力したスケジュールデータは、アプリケーション提供者のサーバに格納される。そのため、利用者はデータの保存場所を気にする必要がない。つまり、利用者は、どのコンピュータを使ってサーバにアクセスしたとしても、同じスケジュールデータを参照することができる。

上記のように利用者のデータがサーバ側に保存されるという特徴は、利用者に利便性の向上をもたらす反面、企業がＳａａＳアプリケーションの導入を躊躇する理由にもなっている。なぜなら、企業における業務活動のために従業員がＳａａＳアプリケーションを利用することにより、企業内の重要な情報が社外のサーバに格納されることになるからである。

もちろん、ＳａａＳアプリケーションの提供者は、「自分たちはサーバから情報が漏洩しないように万全の対策をとっており、サーバはセキュアである」と主張するであろう。しかしながら、企業にとって重要な情報が企業自身の管理下にない第三者によって管理されることに対する抵抗感を持つ企業も多い。

そこで、ネットワークを介したサービスの提供に関して、例えば次のような技術も開示されている。
例えば、あるサービス提供システムは、セキュリティ上重要な情報をサービスサーバに供給することなく、サービスサーバからサービスの提供を受けることができるようにすることを目的としている。

具体的には、ＣＥ（Consumer Electronics）機器が、機器ＩＤなどの認証に必要な情報を認証代行サーバに送信して、所定のサービスの提供を要求する。すると、認証代行サーバは、認証情報に基づいてＣＥ機器を認証するとともに、その認証結果をサービスサーバに送信する。サービスサーバは、認証代行サーバからの結果に基づいて、要求されたサービスをＣＥ機器に提供する。ＣＥ機器は、サービスサーバから提供されたサービスを利用する。

また、あるウェブサービスシステムは、サービスの利用者側および提供者側に改修の必要なしに、サービスの利用者が提供者側に送信すべき情報を秘匿した状態で通常通りにサービスを利用可能とすることができるようにすることを目的としている。

具体的には、情報秘匿プロキシ装置が、ウェブサービス提供側ネットワークシステム外、かつウェブサービスを提供するサーバとウェブサービスを利用するクライアントとの間に備えられる。情報秘匿プロキシ装置は、クライアントからの第１の情報を受信し、第１の情報に含まれる特定の情報を変換後の情報に変換して更新し、更新した第１の情報をサーバに送信する。また、情報秘匿プロキシ装置は、サーバからの第２の情報を受信し、第２の情報に含まれる上記変換後の情報を検出し、上記変換後の情報を上記特定の情報に置換して更新し、更新した第２の情報をクライアントへ送信する。

特開２００３−３３７８６８号公報 特開２００８−１７７８２１号公報

しかしながら、一般にアプリケーションで使用される情報は、例えば機器ＩＤなどの認証に必要な情報だけには限られない。また、アプリケーションで使用される情報のデータ形式は様々である。そのため、例えば単純な文字列置換操作によって特定の文字列を置換することで特定の文字列を秘匿しようとする方法は、データ形式によっては、秘匿対象の特定の文字列の検出に失敗し、ひいてはデータの秘匿に失敗する可能性がある。

そこで本発明の目的は、利用者が入力した情報を、情報の種類やデータ形式によらず確実にサービス提供者から秘匿しつつ、利用者がサービス提供者からサービスを受けることを可能とするためのプログラムおよび装置を提供することである。

一態様によれば、クライアントを有する第１のネットワーク内の中継装置に、以下の要求受信ステップと検索ステップと判定ステップと置換ステップと要求送信ステップと発行ステップを実行させる中継プログラムが提供される。

前記要求受信ステップは、前記クライアントから、第２のネットワーク内のサーバに対する、該サーバ上の対象外部リソースに関する第１の要求を受信するステップである。
前記検索ステップは、前記サーバ上の外部リソースを判別する外部リソース判別情報と、前記第１のネットワーク内の内部リソースを判別する内部リソース判別情報とを対応付ける第１の対応付け情報を参照することにより、前記対象外部リソースに対応する対象内部リソースを判別する対象内部リソース判別情報を検索するステップである。

前記判定ステップは、前記第１の要求が、要求ペイロード情報を含み、前記対象外部リソースの内容を前記要求ペイロード情報により示される内容に更新することを要求する更新要求であるか否かを判定するステップである。

前記置換ステップは、前記判定ステップにおいて、前記第１の要求が前記更新要求であると判定された場合に、外部リソース判別情報と第１のネットワーク内のダミー情報保持部に保持されたダミー情報とを対応付ける第２の対応付け情報を参照し、前記対象外部リソースを判別する対象外部リソース判別情報に対応するダミー情報を特定し、前記要求ペイロード情報を、特定された前記ダミー情報により置換するステップである。

前記要求送信ステップは、前記置換ステップにおいて前記置換が行われた後、置換後の前記第１の要求を、前記サーバに送信するステップである。
前記発行ステップは、前記要求送信ステップにおいて、置換後の前記第１の要求を前記サーバに送信する場合に、前記対象内部リソースの内容を置換前の前記要求ペイロード情報により示される前記内容に更新するよう要求する第２の要求を発行するステップである。

上記の中継プログラムによれば、対象外部リソース判別情報と対応する対象内部リソース判別情報が特定されれば、要求ペイロード情報は、情報の種類や形式に依存することなく、ダミー情報に置換される。よって、上記の中継プログラムによれば、第１のネットワーク内の内部リソースの内容を第２のネットワーク内のサーバから確実に秘匿することができる。

第１実施形態のシステム構成図である。 第１実施形態が適用される環境の一例を説明する図である。 第１実施形態による動作の説明図である。 第１比較例による動作の説明図である。 第２比較例による動作の説明図である。 第３比較例による動作の説明図である。 第４比較例による動作の説明図である。 ＲＥＳＴについて説明する図である。 第１実施形態によるページ内容送信処理のフローチャートである。 第１実施形態による書き換えＵＲＩ管理表の例を示す図である。 第１実施形態によるＧＥＴ処理のフローチャートである。 第１実施形態においてダミーデータ保持部が保持するデータの例を説明する図である。 第１実施形態において社内システムサーバに格納されるデータの例を説明する図である。 第１実施形態によるＧＥＴ処理の動作シーケンス図である。 第１実施形態によるＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理のフローチャートである。 第１実施形態によるＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理の動作シーケンス図である。 第２実施形態による書き換えＵＲＩ管理表の例を示す図である。 第３実施形態による書き換えＵＲＩ管理表の例を示す図である。 第４実施形態による書き換えＵＲＩ管理表の例を示す図である。 第４実施形態で使われるデータ形式の一例を示す図である。 第４実施形態における変換プログラムの例を説明する図である。 第４実施形態における逆変換プログラムの例を説明する図である。 コンピュータの構成図である。

以下、実施形態について、図面を参照しながら詳細に説明する。
図１は、第１実施形態のシステム構成図である。
第１実施形態のシステム１００には、２つのネットワーク、すなわち利用者の社内ネットワーク１１０とアプリケーション提供元サイト１７０が構築された社外のネットワークが含まれる。利用者の社内ネットワーク１１０は、例えば企業や学校などの組織のイントラネットであり、ＬＡＮ（Local Area Network）またはＷＡＮ（Wide Area Network）でもよい。アプリケーション提供元サイト１７０は、例えばアプリケーション提供者（アプリケーションベンダとも言われる）が運営するサイトであり、ウェブアプリケーションを提供するＳａａＳアプリケーションサーバ１８０を含む。

利用者の社内ネットワーク１１０とアプリケーション提供元サイト１７０は、例えばインターネットを介して接続されている。また、例えば不図示のファイヤウォールにより、利用者の社内ネットワーク１１０と外部との間の通信は制御されている。

以下では、利用者の社内ネットワーク１１０内のリソースを「内部リソース」ともいい、ＳａａＳアプリケーションサーバ１８０上のリソースを「外部リソース」ともいう。内部リソースの中には、利用者の社内ネットワーク１１０内に秘匿しておきたい（すなわちファイヤウォールの外には出したくない）情報を含むものもある。

なお、本願において、リソースとは、文字データ、画像データ、音声データ、実行可能なプログラムのデータ等の各種形式のデータをいう。
利用者の社内ネットワーク１１０には、利用者のブラウザ１２０と中継サーバ１３０と社内システムサーバ１６０が含まれる。

利用者のブラウザ１２０は、例えば、ＰＣ（Personal Computer）などのコンピュータ上で動作する一般的なウェブブラウザである。
なお、広義のウェブアプリケーションには、ＳａａＳアプリケーションサーバ１８０から必要に応じて機能モジュールがクライアントにダウンロード可能なように設計された、ネイティブアプリケーションも含まれる。しかし、第１実施形態においてＳａａＳアプリケーションサーバ１８０が提供するウェブアプリケーションは、利用者のブラウザ１２０を介して実行される、ブラウザベースのものであるとする。

中継サーバ１３０は、例えば利用者の社内ネットワーク１１０内に設けられたプロキシサーバであってもよい。ＣＧＩ（Common Gateway Interface）プロキシが中継サーバ１３０として機能することもできる。社内システムサーバ１６０は、利用者の社内ネットワーク１１０外に出したくない情報を管理するサーバである。

また、中継サーバ１３０は、認証機能部１４０と中継機能部１５０を備える。
認証機能部１４０は、アプリケーションの利用開始に先立って利用者を識別し、利用者の認証を行う機能を提供する。認証機能部１４０は、認証部１４１、セッション管理表１４２および利用者認証情報１４３を備える。

中継機能部１５０は、利用者のブラウザ１２０とＳａａＳアプリケーションサーバ１８０の間の通信を中継する機能、すなわちプロキシ機能を提供する。また、中継機能部１５０は、リクエスト受付部１５１、リクエスト先変換部１５２、書き換えＵＲＩ（Uniform Resource Identifier）管理表１５３、ページ内容送受信部１５４、ページ内容送信部１５５およびダミーデータ保持部１５６を備える。

認証部１４１は、例えば、利用者のブラウザ１２０に表示される入力画面を介して入力された利用者ＩＤ（identifier）とパスワードなどを用いて利用者のブラウザ１２０を認証する。認証部１４１は、入力された情報を利用者認証情報１４３と照合することで利用者を認証する。

利用者認証情報１４３は、例えば利用者ＩＤとパスワードの組を含み、中継サーバ１３０が備えるＨＤＤ（Hard Disk Drive）などの記憶装置に格納される。利用者認証情報１４３は、暗号化されていてもよい。

また、認証部１４１は、利用者が使用している端末（つまり利用者のブラウザ１２０が実行されているＰＣなどのコンピュータ）または利用者のブラウザ１２０の情報を、セッション管理表１４２に登録する。例えば、利用者のブラウザ１２０が実行されているコンピュータのネットワークアドレスやホストＩＤ、利用者のブラウザ１２０の種類などの情報が、利用者ＩＤと対応付けられてセッション管理表１４２に登録されてもよい。

セッション管理表１４２は、ＳａａＳアプリケーションサーバ１８０と利用者のブラウザ１２０との間のセッションを管理するための表である。もちろん、表形式以外のデータ形式が採用されてもよい。セッション管理表１４２は、中継サーバ１３０が備えるＲＡＭ（Random Access Memory）またはＨＤＤなどの記憶装置に格納される。

認証部１４１は、利用者ＩＤと対応付けて、ＳａａＳアプリケーションサーバ１８０のアドレスとセッションを識別するセッション情報との組をさらにセッション管理表１４２に登録してもよい。セッション情報は、セッションの状態などを示す情報を含んでいてもよい。

セッション管理表１４２への情報の登録により、認証部１４１は、利用者のブラウザ１２０からＳａａＳアプリケーションサーバ１８０への後のアクセスに関して、セッションの特定をすることが可能となる。

中継機能部１５０のリクエスト受付部１５１は、利用者のブラウザ１２０からＳａａＳアプリケーションサーバ１８０への、外部リソースの参照、作成、更新、削除などを要求するリクエストを受信する。そして、リクエスト受付部１５１は、受信したリクエストをリクエスト先変換部１５２に出力する。すると、リクエスト先変換部１５２は、リクエストの送信元である利用者のブラウザ１２０の情報を求めてセッション管理表１４２を検索する。

検索の結果、利用者に関する情報が得られなかった場合は、リクエスト先変換部１５２は、ページ内容送信部１５５を介して、エラーメッセージを含むリプライを利用者のブラウザ１２０に返す。エラーメッセージの内容は、例えば、利用者ＩＤとパスワードを入力しなおすように利用者に促す文章でもよい。

以下では、検索の結果、利用者に関する情報が得られた場合について説明する。この場合、リクエスト先変換部１５２は、次に、リクエストの対象である外部リソースのＵＲＩと、利用者ＩＤとを検索キーにして、書き換えＵＲＩ管理表１５３を検索する。なお、以下ではリクエストの対象である外部リソースを「対象外部リソース」ともいう。

書き換えＵＲＩ管理表１５３は、詳しくは図１０とともに後述するように、利用者ＩＤと書き換え対象ＵＲＩと書き換え先ＵＲＩを対応付ける表である。もちろん、表形式以外のデータ形式が採用されてもよい。

書き換えＵＲＩ管理表１５３に登録されている各エントリは、利用者の社内ネットワーク１１０内に秘匿しておきたい各リソースに対応する。以下では、利用者の社内ネットワーク１１０内に秘匿しておきたいリソースに関しては適切に書き換えＵＲＩ管理表１５３にエントリが登録されていると仮定して説明する。

なお、以下の説明において、「書き換え対象ＵＲＩ」とは、外部リソースのＵＲＩ、または外部リソースのＵＲＩの少なくとも一部を含む、パターンマッチング用の文字列パターンである。また、「書き換え先ＵＲＩ」とは、内部リソースのＵＲＩ、内部リソースの社内システムサーバ１６０上でのローカルパス、または、内部リソースのＵＲＩもしくはローカルパスの少なくとも一部を含む、パターンマッチング用の文字列パターンである。

リクエストが、秘匿したい情報に関するものではない場合、検索の結果、リクエストの対象である外部リソースのＵＲＩと利用者ＩＤの組に対応する書き換え先ＵＲＩが、書き換えＵＲＩ管理表１５３に登録されていないと判明する。つまり、対象外部リソースのＵＲＩが書き換えの対象ではないことが判明する。

そこで、リクエスト先変換部１５２は、リクエスト受付部１５１から出力されたリクエストを、そのままページ内容送受信部１５４に出力する。すると、ページ内容送受信部１５４は、リクエスト受付部１５１が受信したリクエストのペイロードデータを変えずに元のままに保って、リクエストの本来の送信先であるＳａａＳアプリケーションサーバ１８０に、リクエストを送信する。

逆に、リクエストが、秘匿したい情報に関するものである場合、リクエスト先変換部１５２による書き換えＵＲＩ管理表１５３の検索の結果、書き換え先ＵＲＩが特定される。つまり、対象外部リソースのＵＲＩが書き換えの対象であることが判明し、対象外部リソースのＵＲＩに対応する書き換え先ＵＲＩが一意に特定される。なお、以下では、特定された書き換え先ＵＲＩにより識別される内部リソースを、「対象内部リソース」ともいう。

書き換え先ＵＲＩが特定されると、リクエスト先変換部１５２は、元のリクエストに含まれている対象外部リソースのＵＲＩと、特定された対象内部リソースを示す書き換え先ＵＲＩをページ内容送受信部１５４に通知する。また、リクエスト先変換部１５２は、リクエストをページ内容送受信部１５４に出力する。

すると、ページ内容送受信部１５４は、リクエストが要求する操作の種類に応じて、適宜リクエストの内容の書き換えなどを行いつつ、リクエストをＳａａＳアプリケーションサーバ１８０と社内システムサーバ１６０に送信する。リクエストが要求する操作の種類には、例えば、参照、作成、更新、削除などがある。ページ内容送受信部１５４の動作は、詳しくは後述するが、概説すると次のとおりである。

すなわち、ページ内容送受信部１５４は、ペイロードデータをダミーデータに置換したリクエストをＳａａＳアプリケーションサーバ１８０に送信する。その結果、「秘匿したい対象内部リソースの内容が利用者の社内ネットワーク１１０の外部に送信される」という事態が回避される。なお、ダミーデータを含むリクエストの送信は、秘密保持の効果だけでなく、リソースに対する操作が行われたことをＳａａＳアプリケーションサーバ１８０に認識させる効果もある。

また、ページ内容送受信部１５４は、本来の宛先とは異なる宛先である社内システムサーバ１６０にリクエストを送信する。その結果、秘匿したい対象内部リソースに対して、ＳａａＳアプリケーションサーバ１８０から提供されるアプリケーションを介して、参照、作成、更新、削除などの操作を行うことが可能となる。つまり、外部のＳａａＳアプリケーションサーバ１８０から提供されるサービスを利用者が享受するとともに、当該サービスでの操作対象である情報をＳａａＳアプリケーションサーバ１８０から秘匿することが可能となる。

ダミーデータ保持部１５６は上記のダミーデータを保持する。ダミーデータ保持部１５６の詳細は図１２とともに後述する。
また、ページ内容送受信部１５４は、ＳａａＳアプリケーションサーバ１８０と社内システムサーバ１６０からそれぞれリプライを受信する。そして、ページ内容送受信部１５４は、受信したリプライに基づいて、利用者のブラウザ１２０に送信するリプライを生成し、ページ内容送信部１５５に出力する。

ページ内容送信部１５５は、ページ内容送受信部１５４から出力されたリプライを利用者のブラウザ１２０に送信する。
社内システムサーバ１６０は、リクエスト受付部１６１とページ内容送信部１６２を備え、さらに、アプリケーションデータ１６３を記憶するＨＤＤなどの記憶装置を備えている。

リクエスト受付部１６１は、ページ内容送受信部１５４からのリクエストを受信し、受信したリクエストに応じてアプリケーションデータ１６３の作成、参照、更新、削除などの各種処理を行う。ページ内容送信部１６２は、処理の結果をページ内容送受信部１５４に送信する。なお、アプリケーションデータ１６３は、種々の内部リソースのデータである。

ＳａａＳアプリケーションサーバ１８０は、リクエスト受付部１８１とページ内容送信部１８２を備え、さらに、アプリケーションデータ１８３を記憶するＨＤＤなどの記憶装置を備えている。

リクエスト受付部１８１は、ページ内容送受信部１５４からのリクエストを受信し、受け付けたリクエストに応じてアプリケーションデータ１８３の作成、参照、更新、削除などの各種処理を行う。ページ内容送信部１８２は、処理の結果をページ内容送受信部１５４に送信する。アプリケーションデータ１８３は、種々の外部リソースのデータである。秘匿の必要がない情報に関しては、実データがアプリケーションデータ１８３としてＳａａＳアプリケーションサーバ１８０に記憶されるが、秘匿したい情報に関しては、実データではなくダミーデータがアプリケーションデータ１８３として記憶される。

上記のような図１のシステム１００は、例えば図２のような環境内に構築されてもよい。図２は、第１実施形態が適用される環境の一例を説明する図である。
図２のシステム２００では、ユーザ企業Ａの社内ネットワーク２１０とユーザ企業Ｂの社内ネットワーク２２０とアプリケーション提供元サイト２４０がネットワーク２５０を介して接続されている。

ユーザ企業Ａの社内ネットワーク２１０は、例えばＬＡＮやＷＡＮでもよい。ユーザ企業Ａの社内ネットワーク２１０にはファイヤウォール２１１が設けられており、ファイヤウォール２１１は、ユーザ企業Ａの社内ネットワーク２１０とネットワーク２５０の間の通信を制御する。また、ユーザ企業Ａの社内ネットワーク２１０内にはブラウザ２１２が稼働するＰＣなどが含まれる。

同様に、ユーザ企業Ｂの社内ネットワーク２２０は、例えばＬＡＮやＷＡＮでもよい。ユーザ企業Ｂの社内ネットワーク２２０にもファイヤウォール２２１が設けられており、ファイヤウォール２２１は、ユーザ企業Ｂの社内ネットワーク２２０とネットワーク２５０の間の通信を制御する。また、ユーザ企業Ｂの社内ネットワーク２２０内にはブラウザ２２２が稼働するＰＣなどが含まれる。

アプリケーション提供元サイト２４０ではＳａａＳアプリケーションサーバ２４１が稼働している。ＳａａＳアプリケーションサーバ２４１は、企業Ａのデータと企業Ｂのデータの双方を含むアプリケーションデータ２４２を格納する記憶装置を備えている。ＳａａＳアプリケーションサーバ２４１は、アプリケーションデータ２４２を用いて、例えば、顧客管理機能２４３、サプライチェーン管理機能２４４、またはグループウェア機能２４５などを企業Ａと企業Ｂにそれぞれ提供する。すなわち、ＳａａＳアプリケーションサーバ２４１は、これらの機能を実現するウェブアプリケーションをサービスとして提供する。

具体的には、ブラウザ２１２はネットワーク２５０を介してＳａａＳアプリケーションサーバ２４１にアクセスし、少なくとも画面表示のコード２１３を取得する。画面表示のコード２１３は、具体的には、例えばＨＴＭＬ（HyperText Markup Language）文書である。ブラウザ２１２は、画面表示のコード２１３にしたがって画面を表示し、画面を介してユーザからの入力を受け付けることで、ＳａａＳアプリケーションサーバ１８０により提供されるアプリケーションのフロントエンドとして機能する。

同様に、ブラウザ２２２も、ネットワーク２５０を介してＳａａＳアプリケーションサーバ２４１にアクセスし、少なくとも画面表示のコード２２３を取得する。そして、ブラウザ２２２も、画面表示のコード２２３にしたがって画面を表示し、画面を介してユーザからの入力を受け付けることで、ＳａａＳアプリケーションサーバ１８０により提供されるアプリケーションのフロントエンドとして機能する。

したがって、アプリケーション提供元サイト２４０に蓄積されるアプリケーションデータ２４２は、上記のように、異なる複数の企業のユーザのデータを含む。
以上のような図２の環境において、例えばユーザ企業Ａの社内ネットワーク２１０に図１の中継サーバ１３０と社内システムサーバ１６０が追加されてもよい。このように、既存のアプリケーション提供元サイト２４０に影響を与えることなく、第１実施形態をユーザ企業Ａの社内ネットワーク２１０に適用することができる。

上記のように図１のシステム１００が図２の環境で用いられる場合、図１の利用者のブラウザ１２０は、例えば図２のブラウザ２１２に相当する。また、図１のアプリケーション提供元サイト１７０が図２のアプリケーション提供元サイト２４０に相当し、図１のＳａａＳアプリケーションサーバ１８０が図２のＳａａＳアプリケーションサーバ２４１に相当する。また、図１のアプリケーションデータ１８３は図のアプリケーションデータ２４２に相当する。

ところで、アプリケーションによっては、画面表示のコード２１３だけではなく、JavaScript（登録商標）などのスクリプト言語で記述されたクライアント側プログラムも、ＳａａＳアプリケーションサーバ１８０からブラウザ２１２に読み込まれる。ブラウザ２１２がクライアント側プログラムを実行することで、ウェブページのリロードを伴わずに、利用者の操作に応じて即時かつ動的にブラウザ２１２の画面の内容を変更することが可能となる。

近年では、クライアントの性能向上とともに上記のようなクライアント側プログラムを利用したウェブアプリケーションが広まりつつある。例えば、文書作成や表計算など、従来は専用プログラムを用いて行われていた処理を行うことができるウェブアプリケーションも登場している。

したがって、企業内の活動で利用されるアプリケーションの多くも、ＳａａＳアプリケーションとして安価に提供されるようになりつつある。つまり、企業内の個々のコンピュータのそれぞれに専用プログラムをインストールしなくても、企業内の活動のためのアプリケーションをサービスとして利用することが可能になりつつある。

ところが、図２のシステム２００のような環境では、従来、企業ユーザがアプリケーション提供元サイト２４０の利用をためらうことがあった。なぜなら、例えば、企業Ａのデータが、インターネットなどのネットワーク２５０を経由してアプリケーション提供元サイト２４０に送信されるからである。そして、企業Ａのデータが、企業Ａの管轄下にあるユーザ企業Ａの社内ネットワーク２２０ではなく、企業Ａの管轄下にないアプリケーション提供元サイト２４０に、アプリケーションデータ２４２として蓄積されるからである。

アプリケーション提供元サイト２４０の運営者は、アプリケーション提供元サイト２４０がセキュアであることを主張するかもしれない。しかし、企業にとって情報漏洩は重大な問題であり、企業活動に関係するデータは可能な限り社外に出さないことが望ましい。

そのため、企業Ａは、データがアプリケーション提供元サイト２４０から漏洩することを心配して、ＳａａＳアプリケーションサーバ２４１の利用をためらうことがある。企業Ａは、例えば、顧客管理機能２４３により管理される顧客情報がアプリケーション提供元サイト２４０から漏洩することを心配するかもしれない。

そのため、現状では、たとえ優れたＳａａＳアプリケーションが提供されているとしても、企業のポリシーとして、ＳａａＳアプリケーション利用を手控える企業も多い。
しかし、本発明の各実施形態を適用することにより、図２のような環境においても、外部に出したくない情報を内部ネットワークに秘匿したまま、外部のアプリケーション提供元サイト２４０などからサービスを受けることが可能となる。例えば、企業Ａは、企業Ａにとって重要な情報である顧客情報をユーザ企業Ａの社内ネットワーク２１０内に秘匿したまま、ＳａａＳアプリケーションサーバ２４１から、顧客管理機能２４３のサービスを享受することができるようになる。また、各実施形態によれば、情報の種類やデータ形式によらず、任意の情報を内部ネットワークに秘匿しておくことも可能である。

以下、上記のような利点を有する各実施形態について詳しく説明する。
図３は、第１実施形態による動作の説明図である。図３には、図１と同様に、利用者の社内ネットワーク１１０とアプリケーション提供元サイト１７０を含むシステム１００が示されている。また、図３には図１の一部の要素のみが抜粋されて示されているとともに、図１には不図示の要素が示されている。

すなわち、利用者の社内ネットワーク１１０には図１と同様に、利用者のブラウザ１２０、中継サーバ１３０および社内システムサーバ１６０が含まれる。また、利用者の社内ネットワーク１１０と外部との通信はファイヤウォール１１１により制御されている。図３では、中継サーバ１３０の構成要素のうち書き換えＵＲＩ管理表１５３とダミーデータ保持部１５６のみが抜粋されて示されており、社内システムサーバ１６０の構成要素のうちアプリケーションデータ１６３のみが抜粋されて示されている。

また、アプリケーション提供元サイト１７０には図１と同様のＳａａＳアプリケーションサーバ１８０がある。図３では図示の都合上、アプリケーションデータ１８３がＳａａＳアプリケーションサーバ１８０の外側に示してある。アプリケーションデータ１８３は、ＳａａＳアプリケーションサーバ１８０に記憶されていてもよく、アプリケーション提供元サイト１７０内の不図示の他のデータベースサーバなどに記憶されていてもよい。

ところで、従来の一般的なウェブアプリケーションでは、サーバ側で実行されるプログラムによりアプリケーションのロジックが実装され、ＨＴＭＬページのリロードにより画面が遷移していた。しかし、クライアント用のコンピュータの性能の向上につれて近年では、上記のようにクライアント側プログラムを利用するウェブアプリケーションも増えてきている。一例として、現在、リッチクライアントを実現するＡｊａｘ（登録商標）（Asynchronous JavaScript + XML）技術が注目を集めている。

Ａｊａｘアプローチを採用したウェブアプリケーションでは、クライアント側で実行されるJavaScriptプログラムにより、アプリケーションのロジックの一部（ときには大部分）が実装される。そして、JavaScriptの組み込みオブジェクトであるXMLHttpRequestを用いて、クライアントはサーバとＨＴＴＰ（HyperText Transfer Protocol）通信を行う。

XMLHttpRequestオブジェクトによる通信は、典型的には非同期通信だが、同期通信でもよい。クライアントは、JavaScriptプログラムにしたがって、通信結果を用いて動的にページを書き換えることで、ウェブページ全体のリロードを行うことなく表示内容を変化させることができる。

以下、第１実施形態においてＳａａＳアプリケーションサーバ１８０が提供するアプリケーションでは、XMLHttpRequestによる非同期通信が行われ、ＸＭＬ（eXtensible Markup Language）データが送受信されるものとする。

図３において、ＳａａＳアプリケーションサーバ１８０には、画面表示および処理ロジックのコード１８４が記憶されている。画面表示および処理ロジックのコード１８４は、例えば、以下の（ａ）と（ｂ）を含んでもよいし、（ｃ）を含んでもよいし、その他の（ａ）〜（ｃ）の適宜の組み合わせであってもよい。

（ａ）画面表示用のＨＴＭＬソースコードを生成するための、スクリプト言語などで書かれたコード。
（ｂ）生成されたＨＴＭＬソースコードからリンクされ、利用者のブラウザ１２０に読み込まれるJavaScriptソースコード。

（ｃ）ＨＴＭＬソースコードと、ＨＴＭＬソースコードに埋め込まれるJavaScriptソースコードの双方を生成するための、スクリプト言語などで書かれたコード。
例えば、画面表示および処理ロジックのコード１８４は少なくともＨＴＭＬソースコードを生成するための何らかのプログラムコードを含むとする。この場合、まず、利用者のブラウザ１２０が中継サーバ１３０を介してＳａａＳアプリケーションサーバ１８０にアクセスすると、画面表示および処理ロジックのコード１８４をＳａａＳアプリケーションサーバ１８０が実行する。そして、その結果生成されたＨＴＭＬソースコードが中継サーバ１３０を介して利用者のブラウザ１２０に送信される。

また、利用者のブラウザ１２０に送信されたＨＴＭＬソースコードには、JavaScriptソースファイルへのリンクまたはJavaScriptソースコードそのものが埋め込まれている。リンクされたJavaScriptソースファイルもＳａａＳアプリケーションサーバ１８０から利用者のブラウザ１２０へと読み出される。したがって、JavaScriptコードがＨＴＭＬソースコード内に埋め込まれているか否かとは関係なく、利用者のブラウザ１２０には、画面表示および処理ロジックのコード１２１が読み出される。

したがって、利用者のブラウザ１２０は、ＨＴＭＬソースコードに基づいてウェブページを表示するとともに、読み出したJavaScriptプログラムを実行する。JavaScriptプログラムには、例えば利用者からの入力などのイベントを契機として、XMLHttpRequestオブジェクトを用いてＳａａＳアプリケーションサーバ１８０と通信を行う処理のコードが含まれる。

XMLHttpRequestオブジェクトを利用してＨＴＴＰリクエストを発行することで、利用者のブラウザ１２０は、ウェブページのリロードを伴わずに、ＸＭＬデータの参照や更新などを行うことができる。そして、動的に参照または更新されるＸＭＬデータに基づいて、利用者のブラウザ１２０は、動的に画面の表示内容を変化させることができる。

発行されたＨＴＴＰリクエストによって要求される参照や更新などの操作の対象は、アプリケーションを提供するＳａａＳアプリケーションサーバ１８０上の外部リソースである。また、図１に関して説明したように、中継サーバ１３０内の書き換えＵＲＩ管理表１５３には、利用者ＩＤと書き換え対象ＵＲＩと書き換え先ＵＲＩが対応付けられて記憶されている。

そして、中継サーバ１３０では、利用者のブラウザ１２０から発行されたＨＴＴＰリクエストの対象である対象外部リソースのＵＲＩに対応する書き換えＵＲＩを求めて書き換えＵＲＩ管理表１５３が検索される。対象内部リソースに対応する書き換え先ＵＲＩが特定された場合、中継サーバ１３０は、XMLHttpRequestオブジェクトによるデータの参照リクエストや変更リクエストなどを、送信先を社内システムサーバ１６０に変更して転送する。また、中継サーバ１３０からは、ペイロードデータがダミーデータに書き換えられたリクエストがＳａａＳアプリケーションサーバ１８０に送信される。

なお、以上の説明から明らかなように、第１実施形態では、ＳａａＳアプリケーションサーバ１８０だけでなく社内システムサーバ１６０も、ＨＴＴＰリクエストを受け付けて応答する機能を有する。例えば、社内システムサーバ１６０には、ウェブサーバソフトウェアがインストールされていてもよい。

具体的には、社内システムサーバ１６０は、リソースの参照、作成、更新および削除を要求するＨＴＴＰリクエストを、少なくとも中継サーバ１３０からは受け入れるよう、設定されている。また、社内システムサーバ１６０は、中継サーバ１３０内のページ内容送受信部１５４以外からのＨＴＴＰリクエストに対しては、「Forbidden」や「Not Found」などのステータスを通知することができる。あるいは、社内システムサーバ１６０は、元のＨＴＴＰリクエストを発した利用者のブラウザ１２０での利用者ＩＤに基づく認証を行ってもよい。

続いて、図３を参照して説明した上記の動作の長所の理解を助けるため、図４〜図７を参照して４つの比較例について説明する。
図４は、第１比較例による動作の説明図である。第１比較例は、サーバ側で各種処理が行われるウェブアプリケーションの例である。

図４のシステム３００は、利用者の社内ネットワーク３１０とアプリケーション提供元サイト３２０を含む。利用者の社内ネットワーク３１０と外部との通信はファイヤウォール３１１により制御されている。利用者は、利用者の社内ネットワーク３１０内のブラウザ３１２、ファイヤウォール３１１およびネットワークを介して、アプリケーション提供元サイト３２０内のＳａａＳアプリケーションサーバ３２１から提供されるサービスを受けることができる。

すなわち、ＳａａＳアプリケーションサーバ３２１には、アプリケーションデータ３２２と、アプリケーションの処理ロジックのコード３２３と、画面表示のコード３２４が格納されている。処理ロジックのコード３２３は、例えばスクリプト言語で書かれており、ＳａａＳアプリケーションサーバ３２１により実行される。また、画面表示のコード３２４は静的なＨＴＭＬソースコードでもよいし、ＨＴＭＬソースコードを生成するためのコードであってもよいし、両者が使われてもよい。

例えば、図４に示すように、ブラウザ３１２は、まずアプリケーションの初期画面をＳａａＳアプリケーションサーバ３２１に要求する。すると、ＳａａＳアプリケーションサーバ３２１からは画面表示内容がブラウザ３１２に送信される。つまり、画面表示のコード３２４として記憶されている静的なＨＴＭＬソースコード、あるいはスクリプト言語などで記述された画面表示のコード３２４に基づいて生成されたＨＴＭＬソースコードがブラウザ３１２に送信される。

ブラウザ３１２は、ＳａａＳアプリケーションサーバ３２１から送信された画面表示のコード３１３（すなわちＨＴＭＬソースコード）にしたがい、画面を表示する。表示される画面には、入力フィールドやボタンなどが含まれる。利用者がブラウザ３１２の画面内の入力フィールドにデータを入力し、次画面をロードするための、例えばボタン押下などの動作をすると、ブラウザ３１２は、ボタンが押下されたというイベントを検出する。そして、ブラウザ３１２は、利用者の指示にしたがって次画面をＳａａＳアプリケーションサーバ３２１に要求するとともに、入力されたデータをＳａａＳアプリケーションサーバ３２１に送信する。

ＳａａＳアプリケーションサーバ３２１は、ブラウザ３１２から受け取ったデータを入力として使用して処理ロジックのコード３２３を実行する。例えば、処理ロジックのコード３２３の実行により、次画面を表すＨＴＭＬソースコードが生成されてもよい。また、ブラウザ３１２から送信されたデータは、処理ロジックのコード３２３の実行の結果として、必要に応じて加工され、アプリケーションデータ３２２として格納されてもよい。

そして、次画面の表示内容がＳａａＳアプリケーションサーバ３２１からブラウザ３１２に送信され、ブラウザ３１２は次画面を表示する。システム３００では、以上のようにして、ウェブページのリロードにより画面表示の更新（すなわち画面遷移）が実現される。

ところが、上記の説明から明らかなように、システム３００においては、ＳａａＳアプリケーションサーバ３２１が提供するアプリケーションにより扱われるアプリケーションデータ３２２は、アプリケーション提供元サイト３２０内に格納される。

よって、アプリケーションデータ３２２の内容が、利用者の社内ネットワーク３１０の外部に保存したくない内容である場合、利用者はＳａａＳアプリケーションサーバ３２１が提供するアプリケーションを使用しないことに決めるかもしれない。例えば、ＳａａＳアプリケーションサーバ３２１が優れた顧客管理アプリケーションを提供していても、顧客データを自社外に保存したくない企業は、ＳａａＳアプリケーションサーバ３２１を使用しないかもしれない。

このように、第１比較例では、アプリケーション提供元サイト３２０の運営者は、潜在的な利用者を失ってしまい、利用者は、優れたＳａａＳアプリケーションを使用することによる様々な利益を得られない、ということが考えられる。それに対し、図１と図３に示した第１実施形態では、利用者は、秘匿したい情報は利用者の社内ネットワーク１１０内に秘匿しつつ、ＳａａＳアプリケーションサーバ１８０が提供するアプリケーションの機能を利用することができる。したがって、第１実施形態は、第１比較例と比べると、アプリケーションの提供者にとっても利用者にとっても利点が大きい。

また、アプリケーションデータを社内ネットワーク内に保存するように第１比較例を変形した第２比較例も考えられる。図５は、第２比較例による動作の説明図である。
図５のシステム４００は、利用者の社内ネットワーク４１０とアプリケーション提供元サイト４２０を含む。利用者の社内ネットワーク４１０と外部との通信はファイヤウォール４１１により制御されている。利用者は、利用者の社内ネットワーク４１０内のブラウザ４１２、ファイヤウォール４１１およびネットワークを介して、アプリケーション提供元サイト４２０内のＳａａＳアプリケーションサーバ４２１から提供されるサービスを受けることができる。

ＳａａＳアプリケーションサーバ４２１には、処理ロジックのコード４２２と、不図示の画面表示のコードが格納されている。ブラウザ４１２は、図４のブラウザ３１２と同様にしてＳａａＳアプリケーションサーバ４２１に画面表示を要求し、ＨＴＭＬソースコードを取得して、画面を表示することができる。

また、第１比較例とは異なり、第２比較例では、利用者の社内ネットワーク４１０内に社内システムサーバ４１３が設けられ、社内システムサーバ４１３にアプリケーションデータ４１４が格納される。しかし、このような第２比較例では、ＳａａＳアプリケーションサーバ４２１が提供するアプリケーションによりデータを作成して保存したり、保存されたデータを参照または更新したりすることができない。

なぜなら、第２比較例でも第１比較例と同様に、アプリケーションの処理ロジックのコード４２２はＳａａＳアプリケーションサーバ４２１にあり、サーバ側で処理が行われるからである。したがって、第２変形例においてアプリケーションの処理内でアプリケーションデータ４１４を操作するには、ＳａａＳアプリケーションサーバ４２１が、ファイヤウォール４１１を越えて社内システムサーバ４１３にアクセスする必要がある。

よって、一時的であろうとアプリケーションデータ４１４が利用者の社内ネットワーク４１０の外部に送信されることを避けたいと利用者が望むならば、第２比較例のアプローチは採用することができない。

また、「アプリケーションデータ４１４が、必要に応じてその都度ＳａａＳアプリケーションサーバ４２１によりアクセスされるだけで、利用者の社内ネットワーク４１０の外部に不揮発的に蓄積されることがなければ容認可能である」という立場もありうる。しかし、利用者がそのような立場をとっている場合でも、第２比較例では、ＳａａＳアプリケーションサーバ４２１が提供するアプリケーションによりデータを作成して保存したり、保存されたデータを参照または更新したりすることができない。

なぜなら、企業などの組織では、情報漏洩を防ぐため、一般にイントラネットへの外部からのアクセスを拒絶するようにファイヤウォールが設定されているからである。また、ＳａａＳアプリケーションサーバ４２１から社内システムサーバ４１３へのアクセスのみ例外的に認めるようにファイヤウォールの設定を変えることは、セキュリティホールの原因となりかねないので、好ましくない。

したがって、結局、第２比較例では、外部のＳａａＳアプリケーションサーバ４２１からの、利用者の社内ネットワーク４１０内の社内システムサーバ４１３へのアクセスは、ファイヤウォール４１１により拒絶される。

以上から、第２比較例では、ＳａａＳアプリケーションサーバ４２１が処理ロジックのコード４２２にしたがってアプリケーションデータ４１４を処理することさえできない。よって第２比較例では利用者はアプリケーションの恩恵を受けることができないので、第２比較例と比べた第１実施形態の利点は明らかである。

図６は、第３比較例による動作の説明図である。Ａｊａｘ技術への注目が高まるにつれて、アプリケーションのロジックの一部（ときには大部分）が、クライアント側でのプログラム実行により実現されるタイプのアプリケーションも増えてきた。第３比較例においても、アプリケーションのロジックを実現するためのプログラムがクライアント側で実行される。

具体的には、システム５００は、利用者の社内ネットワーク５１０とアプリケーション提供元サイト５２０を含む。利用者の社内ネットワーク５１０と外部との通信はファイヤウォール５１１により制御されている。また、アプリケーション提供元サイト５２０内のＳａａＳアプリケーションサーバ５２１は、アプリケーションデータ５２２と、画面表示および処理ロジックのコード５２３を記憶している。画面表示および処理ロジックのコード５２３は、例えば、画面表示のためのＨＴＭＬソースコードを生成するとともに、クライアント側で実行されるJavaScriptプログラムのソースコードを生成するコードであってもよい。

利用者の社内ネットワーク５１０内のブラウザ５１２は、ファイヤウォール５１１とネットワークを介して、アプリケーション提供元サイト５２０内のＳａａＳアプリケーションサーバ５２１にアクセスし、アプリケーションの初期画面を要求する。すると、ＳａａＳアプリケーションサーバ５２１は画面表示および処理ロジックのコード５２３に基づいて、画面表示のためのＨＴＭＬソースコードとJavaScriptソースコードをブラウザ５１２に送信する。

ブラウザ５１２は、送信された画面表示および処理ロジックのコード５１３（具体的にはＨＴＭＬソースコードとJavaScriptプログラムのソースコード）にしたがって、画面を表示するとともに、JavaScriptプログラムを実行する。ブラウザ５１２が取得したJavaScriptプログラムのソースコードには、XMLHttpRequestオブジェクトを使ってＨＴＴＰ通信によりＸＭＬデータを参照するなどしてブラウザ５１２が動的にページを書き換えるためのソースコードが含まれる。

ところが、JavaScriptプログラムの実行によりブラウザ５１２がＨＴＴＰ通信によりＸＭＬデータにアクセスするためには、ＸＭＬデータはＳａａＳアプリケーションサーバ５２１になくてはならない。つまり、図６に示すように、処理は利用者の社内ネットワーク５１０内のブラウザ５１２で行われるにもかかわらず、アプリケーションデータ５２２はアプリケーション提供元サイト５２０になくてはならない。

その理由は、ＳＯＰ（Same Origin Policy）と呼ばれるセキュリティ上の制約をブラウザ５１２が持っているからである。ＳＯＰによれば、XMLHttpRequestオブジェクトによりブラウザ５１２がデータを送信することができるのは、ＳａａＳアプリケーションサーバ５２１に限定される。よって、アプリケーションデータ５２２はＳａａＳアプリケーションサーバ５２１に記憶される必要がある。

このように、第３比較例では、アプリケーションデータ５２２が利用者の社内ネットワーク５１０の外部で管理される。したがって、第１比較例と同様に、第３比較例においても、アプリケーションデータ５２２の内容が、利用者の社内ネットワーク５１０の外部に保存したくない内容である場合、利用者はＳａａＳアプリケーションサーバ５２１の利用をあきらめるかもしれない。よって、利用者が、秘匿したい情報は利用者の社内ネットワーク１１０内に秘匿しつつ、ＳａａＳアプリケーションサーバ１８０が提供するアプリケーションの機能を利用することが可能な第１実施形態は、第３比較例と比べても優れている。

図７は、第４比較例による動作の説明図である。
第３比較例と同様に、図７のシステム６００は、利用者の社内ネットワーク６１０とアプリケーション提供元サイト６２０を含み、ファイヤウォール６１１が利用者の社内ネットワーク６１０と外部との通信を制御している。また、利用者の社内ネットワーク６１０内のブラウザ６１２はアプリケーション提供元サイト６２０内のＳａａＳアプリケーションサーバ６２１にアクセスする。その結果、ブラウザ６１２は、画面表示および処理ロジックのコード６２２に基づいてＳａａＳアプリケーションサーバ６２１から送信される画面表示および処理ロジックのコード６１５を取得する。

第３比較例と異なる点は、第４比較例では利用者の社内ネットワーク６１０内に社内システムサーバ６１３が設けられ、アプリケーションデータ６１４が社内システムサーバ６１３に格納される点である。したがって、第４比較例ではアプリケーションデータ６１４が利用者の社内ネットワーク６１０の外部には送信されない。

しかし、システム６００においてはそもそもアプリケーションが機能しない。なぜなら、第３比較例について説明したように、ブラウザ６１２がXMLHttpRequestオブジェクトを用いてアプリケーションデータ６１４を参照しようとすると、ＳＯＰにより参照リクエストは拒絶されるからである。

以上説明した４つの比較例のいずれにおいても、外部のサーバから提供されるアプリケーションを、アプリケーションで使用する情報を外部から秘匿したままで利用することはできない。それに対し、図１および図３に示した第１実施形態のシステム１００では、外部のサーバから提供されるアプリケーションを、アプリケーションで使用する情報を外部に送信することなく、利用することができる。以下ではこのような利点を有する第１実施形態について、さらに詳しく説明する。

なお、第１実施形態は、近年注目を集めるようになってきているＲＥＳＴ（Representational State Transfer）スタイルに準じるウェブアプリケーションに適用されることを前提としているので、ここでＲＥＳＴについて簡単に説明する。ＲＥＳＴはインターネット上のデータを扱うスタイルの１つである。

ＲＥＳＴの基本的な考え方は、データなどのリソースに一意なＵＲＩを対応させ、ＨＴＴＰだけでそのデータの参照、作成、更新および削除を表現するという考え方である。ＲＥＳＴスタイルに準じることでインターネット経由でのデータの利用が容易になることから、今後、ＲＥＳＴスタイルに準じるアプリケーションが増えることが予想されている。

図８は、ＲＥＳＴについて説明する図である。図８において、システム７００は企業Ａの社内ネットワーク７１０とアプリケーション提供元サイト７２０を含む。
企業Ａの社内ネットワーク７１０内のブラウザ７１１は、アプリケーション提供元サイト７２０内の、「example.com」というホスト名のＳａａＳアプリケーションサーバ７２１が提供するアプリケーションを利用する。ＳａａＳアプリケーションサーバ７２１において、企業Ａは、「acompany」という利用者ＩＤで管理されているとする。

ＳａａＳアプリケーションサーバ７２１はアプリケーションデータ７２２を管理している。なお、ＳａａＳアプリケーションサーバ７２１は不図示の企業Ｂにもアプリケーションをサービスとして提供している。そのため、アプリケーションデータ７２２には、企業Ａのデータ７２３だけでなく、企業Ｂのデータ７２４も含まれる。企業Ａのデータ７２３は、「data200812181234」という識別子により識別されるデータ７２５と、「data200901100954」という識別子により識別されるデータ７２６を含む。また、企業Ｂのデータ７２４は、「data200812241430」という識別子により識別されるデータ７２７を含む。

例えば、データ７２５というリソースは、「http://example.com/data/acompany/data200812181234」というＵＲＩにより識別される。また、データ７２６というリソースは、「http://example.com/data/acompany/data200901100954」というＵＲＩにより識別される。そして、企業ＢがＳａａＳアプリケーションサーバ７２１において「bcompany」という利用者ＩＤで管理されていれば、データ７２７は、「http://example.com/data/bcompany/data200812241430」というＵＲＩにより識別される。

このように、ＲＥＳＴスタイルに準じるアプリケーションにおいて使用される個々のリソースは、それぞれ一意なＵＲＩに対応している。
また、上記のように、ＲＥＳＴスタイルでは、リソースに対する参照、作成、更新および削除の各操作がＨＴＴＰのみで表現される。具体的には、リソースの参照、作成、更新および削除は、それぞれＨＴＴＰのＧＥＴメソッド、ＰＯＳＴメソッド、ＰＵＴメソッドおよびＤＥＬＥＴＥメソッドにより表現される。

例えば、ブラウザ７１１は、既存のデータ７２５の参照を要求するとき、リクエストラインにＧＥＴメソッドとデータ７２５のＵＲＩを指定したＨＴＴＰリクエストを、ＳａａＳアプリケーションサーバ７２１に送信する。すると、ＳａａＳアプリケーションサーバ７２１は、ＨＴＴＰリクエストに対する処理結果を表すステータス（例えば「ＯＫ」など）とともに、データ７２５の内容を、ブラウザ７１１に送信する。

また、ブラウザ７１１は、既存のデータ７２５の更新を要求するとき、リクエストラインにＰＵＴメソッドとデータ７２５のＵＲＩを指定し、更新したい内容をメッセージボディに含めたＨＴＴＰリクエストを、ＳａａＳアプリケーションサーバ７２１に送信する。すると、ＳａａＳアプリケーションサーバ７２１は、データ７２５の内容を、メッセージボディに指定された内容に更新し、ＨＴＴＰリクエストに対する処理結果を表すステータス（例えば「ＯＫ」など）をブラウザ７１１に送信する。

さらに、ブラウザ７１１は、既存のデータ７２５の削除を要求するとき、リクエストラインにＤＥＬＥＴＥメソッドとデータ７２５のＵＲＩを指定したＨＴＴＰリクエストを、ＳａａＳアプリケーションサーバ７２１に送信する。すると、ＳａａＳアプリケーションサーバ７２１は、データ７２５を削除し、ＨＴＴＰリクエストに対する処理結果を表すステータス（例えば「ＯＫ」など）をブラウザ７１１に送信する。

また、図８には示していないが、新規リソースの作成は次のように行われる。
ＳａａＳアプリケーションサーバ７２１上には、新規リソースを作成してアプリケーションデータ７２２として保存するための特別なプログラムのデータが存在する。その特別なプログラムはＳａａＳアプリケーションサーバ７２１により実行される。上記のとおり、一般的にプログラムのデータもリソースの１種であるから、上記特別なプログラムのデータも、ＵＲＩにより識別される。以下では上記の特別なプログラムのデータを「特別なリソース」ともいう。

ブラウザ７１１は、新規のデータの作成を要求するとき、ＨＴＴＰリクエストのリクエストラインにＰＯＳＴメソッドと上記の特別なリソースを識別するＵＲＩを指定し、メッセージボディに、作成したいリソースの内容を含める。そして、ブラウザ７１１は、ＨＴＴＰリクエストをＳａａＳアプリケーションサーバ７２１に送信する。

すると、ＳａａＳアプリケーションサーバ７２１は、新たなリソースを識別するための新たなＵＲＩを生成し、ＳａａＳアプリケーションサーバ７２１上の、上記の新たなＵＲＩに対応する場所に、上記の特別なリソースを使って新規のリソースを作成する。作成されたリソースの内容はＨＴＴＰリクエストで指定された内容である。

そして、ＳａａＳアプリケーションサーバ７２１は、ＨＴＴＰレスポンスをブラウザ７１１に送信する。そのＨＴＴＰレスポンスのレスポンスラインには、ＨＴＴＰリクエストに対する処理結果を表すステータス（例えば「Created」など）が含まれ、「Location」レスポンスヘッダフィールドには上記の新たなＵＲＩが含まれる。したがって、ブラウザ７１１は、新規に作成されたデータのＵＲＩを認識することができる。

第１実施形態では、以上説明したようなＲＥＳＴスタイルに準じることを前提として、図１のＳａａＳアプリケーションサーバ１８０がアプリケーションを提供している。以下、図９〜図１７を参照して、図１の中継機能部１５０の動作を詳細に説明する。

図９は、第１実施形態によるページ内容送信処理のフローチャートである。図９の処理の契機は、利用者のブラウザ１２０からのＨＴＴＰリクエスト（以下、「ＨＴＴＰリクエスト」を単に「リクエスト」ということがある）の受信である。

すなわち、リクエスト受付部１５１は、利用者のブラウザ１２０からXMLHttpRequestオブジェクトによるリクエストを受信し、受信したリクエストをリクエスト先変換部１５２に出力する。すると、リクエスト先変換部１５２は利用者のブラウザ１２０の情報を求めてセッション管理表１４２を検索する。検索の結果、利用者ＩＤなど利用者に関する情報が得られると、図９の処理が開始される。

ステップＳ１０１でリクエスト先変換部１５２は、セッション管理表１４２から得た利用者ＩＤと、リクエスト受付部１５１から受け取ったリクエストが要求している対象外部リソースのＵＲＩを検索キーにして、書き換えＵＲＩ管理表１５３を検索する。そして、リクエスト先変換部１５２は、書き換えＵＲＩ管理表１５３から、書き換え先のＵＲＩのパターンを得る。

図１０は、第１実施形態による書き換えＵＲＩ管理表の例を示す図である。書き換えＵＲＩ管理表１５３は、ＳａａＳアプリケーションの利用に先立って、利用者などにより適宜設定されている。

第１実施形態における書き換えＵＲＩ管理表１５３は、利用者ＩＤを示す「利用者」列と、外部リソースを判別する外部リソース判別情報を示す「書き換え対象ＵＲＩ」列と、内部リソースを判別する内部リソース判別情報を示す「書き換え先ＵＲＩ」列を有する。

ここで、「書き換え対象ＵＲＩ」列の内容は、外部リソースを一意に識別するＵＲＩそのものでもよいし、外部リソースのＵＲＩの少なくとも一部を含む文字列パターンでもよい。文字列パターンは、例えば、ワイルドカード、正規表現、変数などを含んでいてもよい。なお、文字列パターンは、リソースを一意に識別することができるとは限らないが、リソースを絞り込むことはできるので、上記では「外部リソース判別情報」のように「判別」という語を用いた。

また、「書き換え対象ＵＲＩ」列の内容は、内部リソースを一意に識別するＵＲＩそのものでもよいし、内部リソースがアプリケーションデータ１６３として記憶される社内システムサーバ１６０の記憶装置における内部リソースの保存場所を示すローカルパスでもよい。あるいは、「書き換え対象ＵＲＩ」列の内容は、内部リソースのＵＲＩまたはローカルパスの少なくとも一部を含む文字列パターンでもよい。文字列パターンは、例えば、ワイルドカード、正規表現、変数などを含んでいてもよい。

具体的には、例えば、図１のＳａａＳアプリケーションサーバ１８０のＵＲＩが「http://www.app1.com/」であるとする。また、ＳａａＳアプリケーションサーバ１８０の社内システムサーバ１６０のＵＲＩが「http://data.mycompany.com/」であるとする。

この場合、例えば図１０に示すようなデータ８０１が書き換えＵＲＩ管理表１５３に含まれる。データ８０１は、外部リソース判別情報と内部リソース判別情報とを対応付ける対応付け情報の具体例である。

すなわち、図１０の１行目に示すエントリは「yamada」という利用者ＩＤと「http://www.app1.com/data*」という文字列パターンと「http://data.mycompany.com/yamada/app1/data」という文字列パターンを対応付けるエントリである。なお、以下の説明で「*」という文字はパターンマッチングにおけるワイルドカードを示す。

図１０のデータ８０１はさらに２つのエントリも例示している。２行目のエントリは、「tanaka」という利用者ＩＤと「http://www.app1.com/data*」という文字列パターンと「http://data.mycompany.com/tanaka/app1/data」という文字列パターンを対応付けるエントリである。また、３行目のエントリは、「tanaka」という利用者ＩＤと「http://www.app2.com/schedule*」という文字列パターンと「http://data.mycompany.com/tanaka/app2/data」という文字列パターンを対応付けるエントリである。

なお、１行目と２行目のエントリを比較すると分かるように、「書き換え対象ＵＲＩ」列の同じ「http://www.app1.com/data*」という文字列パターンに対して、利用者ごとに異なる書き換え先ＵＲＩが対応付けられていてもよい。

例えば、社内システムサーバ１６０は、利用者ＩＤごとに別のディレクトリに分けてアプリケーションデータ１６３を格納するという方針にしたがって運用されているかもしれない。それに対し、ＳａａＳアプリケーションサーバ１８０では、利用者ＩＤごとに別のディレクトリに分けることはしていないかもしれない。例えばそのような場合に、１行目と２行目のエントリのように、同じ書き換え対象ＵＲＩに対して、利用者ごとに異なる書き換え先ＵＲＩが対応付けられることがある。

また、実施形態によっては、複数台の社内システムサーバにアプリケーションデータが分散され、格納されてもよい。その場合、例えば利用者に応じて、どの社内システムサーバにデータが格納されるかが異なるかもしれない。そのような場合にも、「利用者」列があれば、利用者ごとに適切に書き換え対象ＵＲＩと書き換え先ＵＲＩの組を設定することができる。

ここで図９の説明に戻る。例えば、「yamada」という利用者ＩＤの利用者が利用者のブラウザ１２０を利用しており、利用者のブラウザ１２０から、「http://www.app1.com/data/companya/data200812241430」というＵＲＩを操作対象とするリクエストが送信されるとする。すると、ステップＳ１０１においてリクエスト先変換部１５２は、「yamada」という利用者ＩＤと「http://www.app1.com/data/companya/data200812241430」というＵＲＩを検索キーにして、データ８０１を含む書き換えＵＲＩ管理表１５３を検索する。

検索の結果、「http://www.app1.com/data/companya/data200812241430」というＵＲＩが、１行目のエントリの「http://www.app1.com/data*」という「書き換え対象ＵＲＩ」列の文字列パターンとマッチすることが判明する。よって、ステップＳ１０１でリクエスト先変換部１５２は、書き換え先のＵＲＩのパターンとして、１行目の「http://data.mycompany.com/yamada/app1/data」というパターンを得る。

なお、第１実施形態では、前方一致検索が行われる。しかし、実施形態によっては、前方一致検索の代わりに後方一致検索、最長一致検索または最短一致検索などの方針にしたがってリクエスト先変換部１５２が検索を実行してもよい。

以上のように、ステップＳ１０１は、第１のネットワーク（すなわち利用者の社内ネットワーク１１０）内のコンピュータ（具体的には中継サーバ１３０）が図１０のデータ８０１のような対応付け情報を参照するステップを含む。

また、中継サーバ１３０は、ステップＳ１０１の契機となる受信ステップも実行する。すなわち、中継サーバ１３０は、第１のネットワークとは別の第２のネットワーク内のサーバ（具体的にはＳａａＳアプリケーションサーバ１８０）に対する第１の要求を、第１のネットワーク内のクライアント（つまり利用者のブラウザ１２０）から受信する。

ステップＳ１０１はさらに、対応付け情報に基づき、第１の要求の対象である対象外部リソースを一意に識別する対象外部リソース判別情報と対応する対象内部リソース判別情報を検索するステップを含む。

続いてステップＳ１０２でリクエスト先変換部１５２は、書き換えＵＲＩ管理表１５３に、対象外部リソースに該当するエントリがあるか否かを、ステップＳ１０１の検索の結果から判断する。対象外部リソースに該当するエントリが書き換えＵＲＩ管理表１５３になければ処理はステップＳ１０３に移行し、対象外部リソースに該当するエントリが書き換えＵＲＩ管理表１５３にあれば処理はステップＳ１０４に移行する。

ステップＳ１０３が実行されるのは、ステップＳ１０１の検索の結果、対象内部リソース判別情報が一意に特定されなかった場合である。上記のように、第１実施形態では、秘匿したい情報を含むリソースに関しては適宜書き換えＵＲＩ管理表１５３にエントリが登録済みであると仮定されている。よって、換言すれば、ステップＳ１０３が実行されるのは、利用者の社内ネットワーク１１０の外部のＳａａＳアプリケーションサーバ１８０に送信しても問題ない情報しか含まないリソースに関して、利用者のブラウザ１２０がリクエストを発行した場合である。

したがって、ステップＳ１０３でリクエスト先変換部１５２は、社内システムサーバ１６０との連携が不要であると判断し、リクエスト受付部１５１から受け取ったリクエストをページ内容送受信部１５４に出力する。ページ内容送受信部１５４は、リクエスト先変換部１５２の判断にしたがい、リクエスト先変換部１５２から受け取ったリクエストをそのまま、本来の送信先であるＳａａＳアプリケーションサーバ１８０に送信する。

ページ内容送受信部１５４から送信されたリクエストは、ＳａａＳアプリケーションサーバ１８０のリクエスト受付部１８１で受信される。ＳａａＳアプリケーションサーバ１８０は、リクエストの内容に応じて、例えばアプリケーションデータ１８３の更新などの処理を行い、処理結果を含むリプライ（すなわちＨＴＴＰレスポンス）をページ内容送信部１８２から中継サーバ１３０へと送信する。

なお、ページ内容送受信部１５４は、ステップＳ１０３でＳａａＳアプリケーションサーバ１８０からのリプライの受信を待っている。ページ内容送受信部１５４は、ＳａａＳアプリケーションサーバ１８０からリプライを受信すると、受信したリプライをそのまま、ページ内容送信部１５５を介して利用者のブラウザ１２０に返す。そして、図９の処理は終了する。

このように、ステップＳ１０３は、利用者のブラウザ１２０からの第１の要求を、ＳａａＳアプリケーションサーバ１８０に送信するステップを含む。また、ステップＳ１０３は、第１の要求に対して得られるＳａａＳアプリケーションサーバ１８０の応答を、クライアントである利用者のブラウザ１２０に送信するステップを含む。

他方、ステップＳ１０１の検索の結果、対象内部リソース判別情報が特定された場合は、ステップＳ１０４が実行される。換言すれば、利用者のブラウザ１２０からのリクエストが、秘匿したい情報を含むリソースに関する場合は、ステップＳ１０４が実行される。ステップＳ１０４でリクエスト先変換部１５２は、書き換え先のＵＲＩパターンを展開し、書き換え先のＵＲＩを得る。

すなわち、図１０を再び参照して具体例を説明すると、ステップＳ１０４の詳細は下記のごとくである。
例えば上記の例のように、ステップＳ１０１で図１０の１行目に示したエントリが得られたとする。すると、ステップＳ１０４でリクエスト先変換部１５２は、「http://www.app1.com/data/companya/data200812241430」という元のＵＲＩのうち、書き換え対象ＵＲＩの文字列パターンとマッチした「http://www.app1.com/data/」という部分を置換する。つまり、リクエスト先変換部１５２は、元のＵＲＩのうちの「http://www.app1.com/data/」という部分を、対応する書き換え先ＵＲＩの文字列パターンである「http://data.mycompany.com/yamada/app1/data」に置換する。

その結果、リクエスト先変換部１５２は、対象内部リソースを一意に識別するＵＲＩを「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」と特定する。このように、リクエスト先変換部１５２は、書き換えＵＲＩ管理表１５３のデータ８０１を検索して文字列パターンマッチング処理を行うことで、対象外部リソースに対応する対象内部リソースのＵＲＩを一意に特定することができる。

また、リクエスト先変換部１５２は、特定した対象内部リソースのＵＲＩを、ステップＳ１０１の検索に用いた利用者ＩＤおよび対象外部リソースのＵＲＩとともにページ内容送受信部１５４に通知する。通知された２つのＵＲＩは、後述の図１１または図１５の処理で利用される。

なお、図１０の例には「利用者」列が含まれるが、実施形態によっては「利用者」列はなくてもよい。例えば、利用者ＩＤを示す変数「$USER」を用いて、書き換え先ＵＲＩが「http://data.mycompany.com/$USER/app1/data」のような文字列パターンで表されていてもよい。

この場合、リクエストを送信した利用者のブラウザ１２０が「yamada」という利用者ＩＤの利用者により使われていることがセッション管理表１４２から判明したとする。すると、ステップＳ１０４ではリクエスト先変換部１５２が変数「$USER」に「yamada」という値を代入する。よって、例えば、対象外部リソースが「http://www.app1.com/data/companya/data200812241430」というＵＲＩで識別される場合、ステップＳ１０４においてリクエスト先変換部１５２は、上記の例と同様に、対象内部リソースを一意に識別するＵＲＩを特定する。すなわち、「利用者」列がない実施形態においても、ステップＳ１０４でリクエスト先変換部１５２は、対象内部リソースのＵＲＩとして「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」を取得することができる。

このように、ステップＳ１０４の文字列のパターンマッチングと置換の詳細は、実施形態に応じて適宜様々な方法を採用することができ、必要に応じて正規表現や変数が使われてもよい。

上記のようにしてステップＳ１０４が実行された後、次のステップＳ１０５でリクエスト先変換部１５２は、リクエストの種別（すなわちリクエストラインで指定されるメソッドの種別）を判定する。

本実施形態では、判定された種別がＧＥＴであれば、ステップＳ１０５に続いてステップＳ１０６のＧＥＴ処理が実行されて図９の処理が終了する。ＧＥＴ処理の詳細は図１１〜図１４とともに後述する。

また、判定された種別がＧＥＴ以外であれば、ステップＳ１０５に続いてステップＳ１０７のＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理が実行されて図９の処理が終了する。ＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理の詳細は図１５〜図１６とともに後述する。

図１１は、第１実施形態によるＧＥＴ処理のフローチャートである。ＧＥＴ処理は、利用者のブラウザ１２０から送信されたリクエストにおいて、リソースを参照するためのＧＥＴメソッドが指定されている場合に実行される。よって、当然ながらリクエストのメッセージボディにはリソースの内容は含まれていない
ステップＳ２０１でリクエスト先変換部１５２は、リクエスト受付部１５１から受け取ったリクエストをページ内容送受信部１５４に出力する。そして、ページ内容送受信部１５４は、書き換える前のＵＲＩすなわち対象外部リソースを識別する元のＵＲＩに対して、リクエスト先変換部１５２から受け取ったリクエストを送信する。つまり、ステップＳ２０１は、利用者のブラウザ１２０からの第１の要求が、対象外部リソースの内容を指示する要求ペイロード情報を含まないときに、第１の要求をＳａａＳアプリケーションサーバ１８０に送信するステップの具体例である。

送信されたリクエストはＳａａＳアプリケーションサーバ１８０のリクエスト受付部１８１で受信される。そして、アプリケーションデータ１８３のうち要求された対象外部リソースのデータが読み出される。ページ内容送信部１８２は、読み出されたデータと、「ＯＫ」などの処理結果などを含むリプライ（すなわちＨＴＴＰレスポンス）を中継サーバ１３０に送信する。

ページ内容送受信部１５４はステップＳ２０１でＳａａＳアプリケーションサーバ１８０からのリプライの受信を待っており、ページ内容送受信部１５４がリプライを得ると処理はステップＳ２０２に移行する。

ステップＳ２０２でページ内容送受信部１５４は、リクエストが成功したか否かを判断する。すなわち、ページ内容送受信部１５４は、ステップＳ２０１で受信したＨＴＴＰレスポンスのレスポンスラインに含まれるステータスコードから、ステップＳ２０１で送信したリクエストが成功して正常に処理されたか否かを判断する。リクエストが成功した場合、処理はステップＳ２０３に移行し、リクエストが失敗した場合、処理はステップＳ２０６に移行する。

ステップＳ２０３で、ページ内容送受信部１５４は、利用者ＩＤ、書き換え前のＵＲＩおよびリプライの内容を互いに対応付けてダミーデータ保持部１５６に格納する。ここで、利用者のブラウザ１２０からの第１の要求に対するＳａａＳアプリケーションサーバ１８０からの応答に含まれており、対象外部リソースの内容を示す情報を、「外部応答ペイロード情報」ということにする。ステップＳ２０３は、外部応答ペイロード情報を、対象外部リソース判別情報に対応するダミー情報として記憶するステップの具体例である。

なお、ここで「利用者ＩＤ」と「書き換え前のＵＲＩ」とは、ページ内容送受信部１５４がＳ２０１で受信したリプライに対応する元のリクエストに関して、図９のステップＳ１０１でリクエスト先変換部１５２が検索キーとして用いたものを指す。また、「リプライの内容」とは、リプライのペイロードであり、換言すれば、ＨＴＴＰレスポンスのメッセージボディに指定された、対象外部リソースの内容である。

ここで、図１２を参照して、ステップＳ２０３の具体例について説明する。図１２は、第１実施形態においてダミーデータ保持部が保持するデータの例を説明する図である。
第１実施形態におけるダミーデータ保持部１５６には、図１２に示すような表形式でデータ８０２が格納されている。図１２の表には、利用者ＩＤを示す「利用者」列と、利用者のブラウザ１２０から送信される元のリクエストで指定される対象外部リソースを一意に識別するＵＲＩを示す「書き換え元ＵＲＩ」列と、ダミーデータを示す「内容」列がある。

例えば、１行目のエントリでは、「yamada」という利用者ＩＤと、「http://www.app1.com/data/companya/data200812241430」というＵＲＩと、ＸＭＬ形式のダミーデータが対応付けられている。このダミーデータはルート要素として「userdata」という要素を持ち、「userdata」要素は、２つの子要素、すなわち「name」要素と「address」要素を持つ。「name」要素の内容は「名前を入力してください」というテキストであり、「address」要素の内容は「住所を入力してください」というテキストである。

また、２行目のエントリでは、「tanaka」という利用者ＩＤと、「http://www.app2.com/schedule/tanaka/20090110」というＵＲＩと、ＸＭＬ形式のダミーデータが対応付けられている。このダミーデータは「schedule」という要素をルート要素として持ち、「schedule」要素の内容は空テキストである。

例えば１行目のエントリは、次のようにして作られる。
まず、「yamada」という利用者ＩＤを持つ利用者の操作にしたがって、利用者のブラウザ１２０から、「http://www.app1.com/data/companya/data200812241430」というＵＲＩで識別される外部リソースを参照するリクエストが送信されたとする。そして、図９のステップＳ１０１、Ｓ１０２、Ｓ１０４およびＳ１０５が実行され、図１１のステップＳ２０１でリプライが得られたとする。得られたリプライのメッセージボディには、図１２に示すような、「userdata」要素をルート要素として持つＸＭＬデータが含まれる。したがって、ステップＳ２０３においてページ内容送受信部１５４は、１行目のエントリを作成してダミーデータ保持部１５６内に格納する。

なお、後に再び「yamada」という利用者ＩＤを持つ利用者の操作にしたがって、利用者のブラウザ１２０が、「http://www.app1.com/data/companya/data200812241430」というＵＲＩで識別される外部リソースを参照するリクエストを送信するかもしれない。その場合、ステップＳ２０３でページ内容送受信部１５４は、ダミーデータ保持部１５６に新たなエントリを作成する代わりに、１行目のエントリのうち「内容」列のみを更新する。

ここで図１１の説明に戻ると、ステップＳ２０３の実行後、ステップＳ２０４でページ内容送受信部１５４は、書き換え後のＵＲＩ（すなわち図９のステップＳ１０４でリクエスト先変換部１５２から通知されたＵＲＩ）に対してリクエストを送信する。ステップＳ２０４は、対象内部リソース判別情報により識別される対象内部リソースの参照を要求する参照要求を発行するステップの一例である。

例えば、利用者のブラウザ１２０からの元のリクエストが参照を要求している対象外部リソースのＵＲＩが「http://www.app1.com/data/companya/data200812241430」であるとする。この場合、図９のステップＳ１０４に関して図１０を参照して説明したように、書き換え後のＵＲＩは「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」であり、社内システムサーバ１６０上の内部リソースを識別するＵＲＩである。したがって、この場合、ページ内容送受信部１５４はステップＳ２０４において、「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」の参照を要求するリクエストを社内システムサーバ１６０に送信する。

送信されたリクエストは、社内システムサーバ１６０のリクエスト受付部１６１で受信される。そして、アプリケーションデータ１６３のうち要求された対象内部リソースのデータが読み出される。ページ内容送信部１６２は、読み出されたデータと、「ＯＫ」などの処理結果などを含むリプライ（すなわちＨＴＴＰレスポンス）を中継サーバ１３０に送信する。

上記のステップＳ２０４の動作について、図１３を参照してさらに具体的に説明する。図１３は、第１実施形態において社内システムサーバに格納されるデータの例を説明する図である。

図１に関して説明したように、秘匿したい内部リソースであるアプリケーションデータ１６３は、例えば社内システムサーバ１６０が備えるＨＤＤなどの記憶装置に格納される。

具体的には、図１３に示すように、データ８０３は、社内システムサーバ１６０内の「yamada/app1/data/companya/data200812241430」というローカルパスで示される場所に格納されている。また、データ８０４は、社内システムサーバ１６０内の「tanaka/app2/data/tanaka/20090110」というローカルパスで示される場所に格納されている。より正確には、図１３に示したローカルパスは、ＨＴＴＰサーバとして機能する社内システムサーバ１６０におけるドキュメントルートよりも下層のパスである。

また、社内システムサーバ１６０は、例えば公知のファイルシステムなどを利用して、個々のリソースの所有者を管理してもよい。具体的には、社内システムサーバ１６０は、データ８０３に「yamada」という利用者ＩＤを対応付けるとともに、データ８０４に「tanaka」という利用者ＩＤを対応付け、リソースの所有者に応じたアクセス制御を行ってもよい。

続いて、図１３と図１０および図１２の関係について説明する。
「http://www.app1.com/data/companya/data200812241430」というＵＲＩに対応して図１０のデータ８０１から図９のステップＳ１０４で得られるＵＲＩは、上記のとおり「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」である。同様に、「http://www.app2.com/schedule/tanaka/20090110」というＵＲＩに対応してステップＳ１０４で得られるＵＲＩは、図１０より、「http://data.mycompany.com/tanaka/app2/data/tanaka/20090110」である。

そして図１２によれば、上記の「http://www.app1.com/data/companya/data200812241430」というＵＲＩに対応するダミーデータは、「userdata」要素をルート要素とするＸＭＬデータであり、図１３のデータ８０３と文書の木構造が等しい。同様に、図１２によれば、上記の「http://www.app2.com/schedule/tanaka/20090110」というＵＲＩに対応するダミーデータは、「schedule」要素をルート要素とするＸＭＬデータであり、図１３のデータ８０４と文書の木構造が等しい。

図１３のデータ８０３では、「name」要素の内容が「山田太郎」というテキストであり、「address」要素の内容が「川崎市中原区」というテキストである。よって、データ８０３と図１２の１行目のエントリに含まれるダミーデータとは、異なる内容を含んでいるが、文書の木構造は同じである。また、図１３のデータ８０４では、「schedule」要素の内容が「10:30 新プロジェクト打ち合わせ」というテキストである。よって、データ８０４と図１２の２行目のエントリに含まれるダミーデータとは、異なる内容を含んでいるが、文書の木構造は同じである。

なお、上記のように内部リソースのデータとダミーデータとが同じ文書構造を持つ場合の前提については、ＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理について説明した後に述べる。
ここで図１１の説明に戻る。ページ内容送受信部１５４はステップＳ２０４で社内システムサーバ１６０からのリプライの受信を待っており、ページ内容送受信部１５４がリプライを得ると処理はステップＳ２０５に移行する。

ステップＳ２０５でページ内容送受信部１５４は、対象内部リソースのデータが見つかったか否かを判断する。例えば、「ＯＫ」を示すステータスコード「２００」が、ステップＳ２０４で得たリプライに含まれていれば、ページ内容送受信部１５４は「対象内部リソースのデータが見つかった」と判断し、処理はステップＳ２０６に移行する。逆に、ページ内容送受信部１５４が「対象内部リソースのデータが見つからなかった」と判断した場合は、処理はステップＳ２０７に移行する。

ステップＳ２０６は、ステップＳ２０２で「失敗した」と判断された後またはステップＳ２０５で「対象内部リソースのデータが見つかった」と判断された後に実行される。ステップＳ２０６では、ページ内容送受信部１５４が、直前に返されたリプライをそのまま、ページ内容送信部１５５を介して、クライアントである利用者のブラウザ１２０に返す。

すなわち、ステップＳ２０２に続いてステップＳ２０６が実行される場合、ページ内容送受信部１５４は、ステップＳ２０１でＳａａＳアプリケーションサーバ１８０から得たリプライを、ページ内容送信部１５５を介して利用者のブラウザ１２０に転送する。つまり、ページ内容送信部１５５は、ページ内容送受信部１５４からの出力にしたがい、対象外部リソースの参照に失敗したことを示すＨＴＴＰレスポンスを利用者のブラウザ１２０に送信する。

また、ステップＳ２０５に続いてステップＳ２０６が実行される場合、ページ内容送受信部１５４は、ステップＳ２０４で社内システムサーバ１６０から得たリプライを、ページ内容送信部１５５を介して利用者のブラウザ１２０に転送する。つまり、ページ内容送信部１５５は、ページ内容送受信部１５４からの出力にしたがい、対象内部リソースの内容（例えば図１３のデータ８０３）をメッセージボディに含むＨＴＴＰレスポンスを利用者のブラウザ１２０に送信する。この場合、ステップＳ２０６は、ステップＳ２０４で発行した参照要求に対して得られる内部応答を受信し、対象内部リソースの内容を示す情報として内部応答に含まれる内部応答ペイロード情報を、クライアントである利用者のブラウザ１２０に送信するステップの例である。

ステップＳ２０６の処理の実行後、図１１の処理も終了する。
また、ステップＳ２０７では、ページ内容送受信部１５４が、ダミーデータ保持部１５６から現在の利用者ＩＤと書き換え前のＵＲＩを検索キーにして、対応するダミーデータを検索する。そして、ページ内容送受信部１５４は、検索の結果として得られたダミーデータを内容として含めたリプライを、ページ内容送信部１５５を介して、クライアントである利用者のブラウザ１２０に返す。

なお、ここで「現在の利用者ＩＤ」と「書き換え前のＵＲＩ」とは、ページ内容送受信部１５４がＳ２０１で受信したリプライに対応する元のリクエストに関して、図９のステップＳ１０１でリクエスト先変換部１５２が検索キーとして用いたものを指す。

例えば、現在の利用者ＩＤと書き換え前のＵＲＩがそれぞれ「yamada」と「http://www.app1.com/data/companya/data200812241430」であるとする。この場合、ステップＳ２０７では、図１２の１行目に示した「userdata」要素をルート要素として持つＸＭＬ形式のダミーデータが、検索の結果として得られる。よって、ページ内容送受信部１５４は、得られたダミーデータをメッセージボディに含むＨＴＴＰレスポンスを、ページ内容送信部１５５を介して利用者のブラウザ１２０に送信する。以上により、図１１の処理が終了する。

なお、通常はステップＳ２０５で「対象内部リソースのデータが見つかった」と判断され、ステップＳ２０６が実行される。ステップＳ２０７が実行されるのは、ＳａａＳアプリケーションサーバ１８０が、例えば次のように設計されているような例外的な場合である。

ある種のＳａａＳアプリケーションサーバ１８０は、存在しないＵＲＩに対する参照が要求されたとき、当該ＵＲＩがＳａａＳアプリケーションサーバ１８０内でのＵＲＩ空間の管理方針に合致していれば、次のように動作するよう設計されているかもしれない。つまり、ＳａａＳアプリケーションサーバ１８０は、デフォルトで決められた内容のリソースを新たに作成し、要求されたＵＲＩが表す場所に格納し、新たに作成したリソースがあたかも既に存在していたかのようにふるまってもよい。その場合、ＳａａＳアプリケーションサーバ１８０は、新たに作成したリソースの内容（すなわちデフォルトで決められた内容）をメッセージボディに含めてＨＴＴＰレスポンスを中継サーバ１３０に返す。

仮にＳａａＳアプリケーションサーバ１８０が上記のように設計されている場合、新規にＳａａＳアプリケーションサーバ１８０上に作成された外部リソースに対応する内部リソースは、当然、社内システムサーバ１６０上には存在しない。すると、ステップＳ２０２では「リクエストが成功した」と判断される一方で、ステップＳ２０５では「対象内部リソースのデータが見つからなかった」と判断されるので、ステップＳ２０７が実行される。

続いて、図９と図１１の処理についてさらに図１４を参照して説明する。図１４は、第１実施形態によるＧＥＴ処理の動作シーケンス図である。すなわち、図１４には図１の利用者のブラウザ１２０、中継機能部１５０、ダミーデータ保持部１５６、社内システムサーバ１６０およびＳａａＳアプリケーションサーバ１８０の列がある。なお、図１４では図示の便宜上、中継機能部１５０内のダミーデータ保持部１５６を中継機能部１５０とは分けて示してある。

（１）に示すように、利用者のブラウザ１２０からXMLHttpRequestオブジェクトによりＳａａＳアプリケーションサーバ１８０上の外部リソースの参照が要求され、中継機能部１５０でＨＴＴＰリクエストが受信される。

すると、図９の処理が開始される。そして、対象外部リソースのＵＲＩが書き換えＵＲＩ管理表１５３に登録されていれば、図９のステップＳ１０２からステップＳ１０４へと処理が進む。リソースの参照を要求するＨＴＴＰリクエストで指定されるメソッドは、図８に関して説明したようにＧＥＴメソッドである。そこで、図９のステップＳ１０６すなわち図１１のＧＥＴ処理が実行される。

具体的には、図１４の（２）に示すように、図１１のステップＳ２０１で、中継機能部１５０からＳａａＳアプリケーションサーバ１８０に対して、ＨＴＴＰでデータ（つまり対象外部リソースのデータ）の参照が要求される。

そして、ステップＳ２０１において、さらに（３）に示すように、アプリケーション提供元であるＳａａＳアプリケーションサーバ１８０から、要求されたデータが中継機能部１５０に送信される。なお、図１４では、（３）で送信されるデータが「初期状態データ」と表現されているが、その理由は後述する。初期状態データは、図１２に示したようなダミーデータと同じ内容である。

すると、上記（３）で正常なリプライが得られたので、処理はステップＳ２０２からステップＳ２０３へと進む。すなわち、（４）に示すように、中継機能部１５０は、書き換え前のＵＲＩ（つまり対象外部リソースのＵＲＩ）と初期状態データをダミーデータ保持部１５６に格納する。

続いてステップＳ２０４が実行され、（５）に示すように、中継機能部１５０がＨＴＴＰで書き換え先ＵＲＩを指定してデータの参照を要求する。すなわち、中継機能部１５０は、社内システムサーバ１６０上の対象内部リソースの参照を要求する。

すると、ステップＳ２０４において、さらに（６）に示すように、社内システムサーバ１６０は、社内システムサーバ１６０内に保存してあるデータを中継機能部１５０に送信する。

そして、上記（６）で正常に対象内部リソースのデータが得られると、処理はステップＳ２０６に進む。すると、（７）に示すように、中継機能部１５０は、社内システムサーバ１６０に保存されていたデータを利用者のブラウザ１２０に送信する。

あるいは、上記（６）で社内システムサーバ１６０上に対象内部リソースが存在しなかった場合、すなわちデータがない場合は、処理はステップＳ２０７に進む。すると、（７）では、中継機能部１５０がダミーデータ保持部１５６からダミーデータを読み出し、ダミーデータが利用者のブラウザ１２０に送信される。

以上から、利用者のブラウザ１２０は、単に「（１）の要求に対して（７）のリプライが得られた」と認識する。つまり、利用者のブラウザ１２０は、得られたリプライのペイロードデータ（具体的にはＨＴＴＰレスポンスのメッセージボディ）が外部リソースのデータであるか内部リソースのデータであるかの違いを認識せずに、（７）以降の処理を続行することができる。そして、利用者のブラウザ１２０が（１）で発行するＨＴＴＰリクエストでは、ＳａａＳアプリケーションサーバ１８０上のＵＲＩが指定されているので、ＳＯＰも守られている。

また、ＳａａＳアプリケーションサーバ１８０は、（２）の要求を受け付け、（３）でリプライを送信するので、「対象外部リソースに対して参照が要求された」という事実および「要求は成功裡に処理された」という事実を認識することができる。したがって、認識した結果に基づいてＳａａＳアプリケーションサーバ１８０は適切なデータ管理を行うことが可能である。

例えば、ＳａａＳアプリケーションサーバ１８０は、「アプリケーションデータ１８３のうちで一定期間以上アクセスされていないデータにマークをつける」などのデータ管理を行うよう設計されているかもしれない。その場合も、第１実施形態によれば、ＳａａＳアプリケーションサーバ１８０は適切にデータ管理を行うことができ、不整合は生じない。

続いて、図９のステップＳ１０７で実行されるＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理の詳細について説明する。
図１５は、第１実施形態によるＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理のフローチャートである。

なお、ＨＴＴＰリクエストで指定されるメソッドのうち、ＰＵＴ、ＰＯＳＴおよびＤＥＬＥＴＥは副作用を持つという点で共通しているので、図１５には「ＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理」としてまとめて図示した。もちろん、これら３種のメソッドの違いに応じて図１５の各ステップの詳細は一部異なるので、以下ではまず各ステップの概要を説明し、メソッドごとの具体的な相違点については後から説明する。

ステップＳ３０１でページ内容送受信部１５４は、ダミーデータ保持部１５６内で現在の利用者ＩＤおよび書き換え前のＵＲＩに対応するダミーデータを検索する。図１１のステップＳ２０３に関して説明したように、ダミーデータは、リソースの参照を要求するため過去に送信されたリクエストに対するリプライに含まれていたデータである。

なお、ステップＳ３０１における「現在の利用者ＩＤ」および「書き換え前のＵＲＩ」は、図１１のステップＳ２０７と同様の意味であり、図９のステップＳ１０４で既にリクエスト先変換部１５２から通知されている。

次に、ステップＳ３０２でページ内容送受信部１５４は、検索条件に合致するダミーデータがダミーデータ保持部１５６にあったか否かを判断する。検索条件に合致するダミーデータがダミーデータ保持部１５６にあれば処理はステップＳ３０３に移行し、なければ処理はステップＳ３０４に移行する。

ステップＳ３０３でページ内容送受信部１５４は、検索の結果得られたダミーデータを内容として書き換え前のＵＲＩにリクエストを送信し、ＳａａＳアプリケーションサーバ１８０からのリプライの受信を待つ。リプライの受信後、処理はステップＳ３０５に移行する。ただし、ＤＥＬＥＴＥメソッドが指定されたリクエストに関して図１５の処理が行われる場合は、メッセージボディは不要なので、ページ内容送受信部１５４はダミーデータをリクエストに含める必要はない。

また、ステップＳ３０４でページ内容送受信部１５４は、「空のデータ」を内容として書き換え前のＵＲＩにリクエストを送信し、ＳａａＳアプリケーションサーバ１８０からのリプライの受信を待つ。リプライの受信後、処理はステップＳ３０５に移行する。ただし、ＤＥＬＥＴＥメソッドが指定されたリクエストに関して図１５の処理が行われる場合は、ステップＳ３０３と同様にメッセージボディは不要である。

なお、ここで「空のデータ」とは、「実質的な内容が空（ブランク）であるデータ」という意味である。例えば、利用者のブラウザ１２０からの元のリクエストのメッセージボディで指定されているデータがＸＭＬデータであれば、「空のデータ」は、元のＸＭＬデータのタグのみ残して、属性と各要素の内容が削除されたデータでもよい。また、利用者のブラウザ１２０からの元のリクエストのメッセージボディで指定されているデータがプレインテキストデータであれば、「空のデータ」は、空白文字のみを含むデータでもよい。

ページ内容送受信部１５４は、ステップＳ３０４において例えば上記のような「空のデータ」を生成して、書き換え前のＵＲＩに対するリクエストのメッセージボディに含めることができる。

なお、ステップＳ３０３とＳ３０４は、対象内部リソース判別情報により識別される対象内部リソースに対して、利用者のブラウザ１２０からの第１の要求により要求される操作と同じ種類の操作を要求する第２の要求を発行するステップの具体例である。

ステップＳ３０５では、ページ内容送受信部１５４は、書き換え後のＵＲＩに対して、利用者のブラウザ１２０からの元のリクエストに含まれている元のデータを内容としてリクエストを送信する。そして、ページ内容送受信部１５４は、社内システムサーバ１６０からのリプライの受信を待つ。ただし、ＤＥＬＥＴＥメソッドが指定されたリクエストに関して図１５の処理が行われる場合は、ステップＳ３０３やＳ３０４と同様にメッセージボディは不要である。リプライの受信後、処理はステップＳ３０６に移行する。

ステップＳ３０６でページ内容送受信部１５４は、ステップＳ３０３またはＳ３０４で得たリプライを、ページ内容送信部１５５を介して、クライアントである利用者のブラウザ１２０に返す。つまり、ステップＳ３０６は、クライアントである利用者のブラウザ１２０からの第１の要求が対象外部リソースに副作用を与える要求であるときの、第１の要求に対するサーバからの応答の内容をクライアントに送信するステップの例である。ステップＳ３０６の実行後、図１５の処理が終了する。

以上、ＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理の概要について説明したので、続いて、メソッドごとの相違点を中心にＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理の詳細を説明する。
（Ａ）ＰＵＴメソッドの場合
例えば、「yamada」という利用者ＩＤの利用者の操作にしたがって、利用者のブラウザ１２０が「http://www.app1.com/data/companya/data200812241430」というＵＲＩに対してＰＵＴメソッドを指定したリクエストを送信したとする。すると、利用者のブラウザ１２０からのリクエストの送信を契機として図９の処理が開始され、図９のステップＳ１０７で図１５の処理が呼び出される。

この場合、図１５のステップＳ３０１の検索の結果として、図１２の１行目に示した、「userdata」要素をルート要素として持つＸＭＬ形式のダミーデータが得られる。したがって、ステップＳ３０３でページ内容送受信部１５４は、次のようなＨＴＴＰリクエストをＳａａＳアプリケーションサーバ１８０に送信する。

・リクエストラインには、ＰＵＴメソッドと「http://www.app1.com/data/companya/data200812241430」という書き換え前のＵＲＩが指定されている。なお、ここでは説明の便宜上、絶対ＵＲＩを示したが、当該ＵＲＩに対応する相対パスなどでもよいことは当然であり、本明細書中の他の箇所においても同様である。

・メッセージボディには、ステップＳ３０１で得られたダミーデータが含まれる。
このように、（Ａ）の場合、利用者のブラウザ１２０からの第１の要求は、対象外部リソースの内容を指示するペイロード情報を含む。よって、（Ａ）の場合、ステップＳ３０２は、外部リソース判別情報とダミー情報とを対応付ける対応付け情報（具体的には例えば図１２のデータ８０２）を参照し、対象外部リソース判別情報に対応するダミー情報を特定するステップの一例である。また、（Ａ）の場合、ステップＳ３０３は、第１の要求に含まれるペイロード情報を対象外部リソース判別情報に対応するダミー情報により置換して、置換後の第１の要求をサーバに送信するステップの例となっている。

また、何らかの理由でステップＳ３０１においてダミーデータが見つからなかった場合は、ステップＳ３０４でページ内容送受信部１５４は、次のようなＨＴＴＰリクエストをＳａａＳアプリケーションサーバ１８０に送信する。

・リクエストラインには、ＰＵＴメソッドと、「http://www.app1.com/data/companya/data200812241430」という書き換え前のＵＲＩが指定されている。
・メッセージボディには、空のデータが含まれる。

また、既に図９のステップＳ１０４で書き換え後の「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」というＵＲＩがリクエスト先変換部１５２から通知されている。したがって、ステップＳ３０５でページ内容送受信部１５４は、次のようなＨＴＴＰリクエストを社内システムサーバ１６０に送信する。

・リクエストラインには、ＰＵＴメソッドと、「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」というＵＲＩが指定されている。
・メッセージボディには、図９の処理の契機となった利用者のブラウザ１２０からの元のリクエストのメッセージボディと同じ内容が含まれる。

そして、ステップＳ３０６でページ内容送受信部１５４は、ステップＳ３０３またはＳ３０４でＳａａＳアプリケーションサーバ１８０から得られたリプライを、ページ内容送信部１５５を介して利用者のブラウザ１２０に返す。リプライには、例えば、ＳａａＳアプリケーションサーバ１８０において更新が成功したことを示す「ＯＫ」などのステータスが含まれる。

（Ｂ）ＤＥＬＥＴＥメソッドの場合
例えば、「yamada」という利用者ＩＤの利用者の操作にしたがって、利用者のブラウザ１２０が「http://www.app1.com/data/companya/data200812241430」というＵＲＩに対してＤＥＬＥＴＥメソッドを指定したリクエストを送信したとする。すると、利用者のブラウザ１２０からのリクエストの送信を契機として図９の処理が開始され、図９のステップＳ１０７で図１５の処理が呼び出される。

この場合も、通常は上記（Ａ）と同様にダミーデータが見つかるが、エラーなど何らかの理由で、ダミーデータが見つからないこともありうる。いずれにせよ、（Ｂ）の場合、ステップＳ３０３またはＳ３０４でページ内容送受信部１５４は、次のようなＨＴＴＰリクエストをＳａａＳアプリケーションサーバ１８０に送信する。

・リクエストラインには、ＤＥＬＥＴＥメソッドと、「http://www.app1.com/data/companya/data200812241430」という書き換え前のＵＲＩが指定されている。
つまり、（Ｂ）の場合、利用者のブラウザ１２０からの第１の要求は、対象外部リソースの内容を指示する要求ペイロード情報を含まない。したがって、（Ｂ）の場合は、ステップＳ３０３とＳ３０４も、第１の要求をサーバに送信するステップの具体例となっている。

また、（Ａ）と同様に既に図９のステップＳ１０４で書き換え後のＵＲＩは通知されているので、ステップＳ３０５でページ内容送受信部１５４は、次のようなＨＴＴＰリクエストを社内システムサーバ１６０に送信する。

・リクエストラインには、ＤＥＬＥＴＥメソッドと、「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」というＵＲＩが指定されている。
そして、ステップＳ３０６でページ内容送受信部１５４は、ステップＳ３０３またはＳ３０４でＳａａＳアプリケーションサーバ１８０から得られたリプライを、ページ内容送信部１５５を介して利用者のブラウザ１２０に返す。リプライには、例えば、ＳａａＳアプリケーションサーバ１８０において削除が成功したことを示す「ＯＫ」などのステータスが含まれる。

なお、上記のように、（Ｂ）の場合は、ステップＳ３０２の判断結果によらず同じリクエストがＳａａＳアプリケーションサーバ１８０に送信される。よって、ステップＳ３０１とＳ３０２とＳ３０４が省略されて、ステップＳ３０３とＳ３０５とＳ３０６のみが実行されてもよい。しかし、例えば、ダミーデータの有無に応じて中継機能部１５０がエラー処理などを適宜行うことができるようにするため、（Ｂ）の場合にも図１５の各ステップが省略されずに行われてもよい。

（Ｃ）ＰＯＳＴメソッドの場合
利用者のブラウザ１２０は、ＳａａＳアプリケーションサーバ１８０上に新規に外部リソースを作成することを要求するとき、ＰＯＳＴメソッドを指定したリクエストを送信する。図８に関して説明したように、ＰＯＳＴメソッドを指定したリクエストにおけるリクエストＵＲＩは、リソースを作成するための特別なリソースのＵＲＩである。

例えば、ＳａａＳアプリケーションサーバ１８０における上記の特別なリソースのＵＲＩが「http://www.app1.com/data/post」であるとする。すると、利用者のブラウザ１２０が送信するリクエストは下記のようなものである。

・リクエストラインには、ＰＯＳＴメソッドと、「http://www.app1.com/data/post」というＵＲＩが指定されている。
・メッセージボディには、利用者の操作にしたがって利用者のブラウザ１２０を介して内容が編集されたデータ（例えばＸＭＬデータやプレインテキストデータ）が含まれる。

また、本発明の各実施形態において、社内システムサーバ１６０も、ＰＯＳＴメソッドが指定されたリクエストに応じて新規リソースを社内システムサーバ１６０上に作成する機能を提供する。例えば、社内システムサーバ１６０において、新規リソースを作成するための特別なリソースのＵＲＩが「http://data.mycompany.com/post」であるとする。

また、書き換えＵＲＩ管理表１５３には、図１０のデータ８０１に加えて、さらに、各利用者ＩＤについてそれぞれ次のようなエントリが含まれている。
・書き換え対象ＵＲＩとして「http://www.app1.com/data/post」が指定されている。

・書き換え先ＵＲＩとして「http://data.mycompany.com/post」が指定されている。
よって、利用者のブラウザ１２０がＰＯＳＴメソッドを指定したリクエストを送信すると、図９のステップＳ１０７から図１５の処理が呼び出される。すると、ページ内容送受信部１５４はステップＳ３０１の検索を実行する。

ところが、第１実施形態においては、ダミーデータ保持部１５６にエントリが追加されるのは、図１１のステップＳ２０３においてである。つまり、第１実施形態では、既存の外部リソースに対する参照が要求されることにより、ダミーデータ保持部１５６にエントリが追加される。また、リソースを作成するための特別なリソースに対しては、通常、ＧＥＴメソッドが指定されることはない。

したがって、ステップＳ３０１の検索の結果、ダミーデータは得られず、処理はステップＳ３０４に移行する。ステップＳ３０４でページ内容送受信部１５４は、ＳａａＳアプリケーションサーバ１８０に対して、下記のようなリクエストを送信する。

・リクエストラインには、ＰＯＳＴメソッドと、「http://www.app1.com/data/post」という書き換え前のＵＲＩが指定されている。
・メッセージボディには、「空のデータ」が含まれる。

ＳａａＳアプリケーションサーバ１８０がこのリクエストを処理すると、ＳａａＳアプリケーションサーバ１８０上に新規にリソースが作成され、例えば「http://www.app1.com/data/companya/data200812241430」のようなＵＲＩが割り当てられる。ＳａａＳアプリケーションサーバ１８０からのＨＴＴＰレスポンスは、上記の処理により割り当てられた新たなＵＲＩの通知を含む。

そして、次のステップＳ３０５でページ内容送受信部１５４は、社内システムサーバ１６０に対して、下記のようなリクエストを送信する。
・リクエストラインには、ＰＯＳＴメソッドと、「http://data.mycompany.com/post」という書き換え後のＵＲＩが指定されている。

・メッセージボディには、利用者のブラウザ１２０からの元のリクエストのメッセージボディの内容が含まれる。
社内システムサーバ１６０がこのリクエストを処理すると、社内システムサーバ１６０上に新規にリソースが作成され、例えば「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」のようなＵＲＩが割り当てられる。社内システムサーバ１６０からのＨＴＴＰレスポンスは、上記の処理により割り当てられた新たなＵＲＩの通知を含む。

なお、ページ内容送受信部１５４は、ステップＳ３０４とＳ３０５でそれぞれ通知される新たなＵＲＩに基づいて、書き換えＵＲＩ管理表１５３にエントリを追加してもよい。
そして、ステップＳ３０６でページ内容送受信部１５４は、ステップＳ３０４で通知されたＳａａＳアプリケーションサーバ１８０上の新たなＵＲＩを含むＨＴＴＰレスポンスを、ページ内容送信部１５５を介して、利用者のブラウザ１２０に送信する。

以上、（Ａ）〜（Ｃ）の場合に分けて、図１５の処理の具体例について説明した。続いて、再度メソッドによらない共通点に注目して、ＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理について図１６を参照して説明する。

図１６は、第１実施形態によるＰＵＴ／ＰＯＳＴ／ＤＥＬＥＴＥ処理の動作シーケンス図である。図１６の形式は図１４と同じである。
（１）に示すように、利用者のブラウザ１２０からXMLHttpRequestオブジェクトによりＳａａＳアプリケーションサーバ１８０に対して、リソースの作成、更新または削除が要求される。すると、図９の処理が開始される。

利用者のブラウザ１２０からのリクエストに指定されているＵＲＩが書き換えＵＲＩ管理表１５３に登録されていれば、図９のステップＳ１０２からステップＳ１０４へと処理が進む。また、リソースの作成、更新または削除が要求される場合は、処理はステップＳ１０５からＳ１０７へと進み、図１５の処理が呼び出される。

すると、図１６の（２）に示すように、図１５のステップＳ３０１で、指定された書き換え前のＵＲＩに対応するダミーデータが検索される。ダミーデータが見つかれば、中継機能部１５０はダミーデータを取得することができる。

そして、（３）に示すように、ステップＳ３０３またはＳ３０４において、中継機能部１５０はＨＴＴＰによりＳａａＳアプリケーションサーバ１８０に対して、リソースの作成、更新または削除を要求する。また、上記のように、ＰＵＴメソッドまたはＰＯＳＴメソッドが指定される場合は、ダミーデータあるいは「空のデータ」がここで使われる。

ステップＳ３０３またはＳ３０４においては、さらに（４）に示すように、ＳａａＳアプリケーションサーバ１８０から（３）の要求に対するリプライが中継機能部１５０に送信される。

すると、ステップＳ３０５で、（５）に示すように、中継機能部１５０から社内システムサーバ１６０に対して、リソースの作成、更新または削除が要求される。また、ステップＳ３０５ではさらに、（６）に示すように、社内システムサーバ１６０から中継機能部１５０に対してリプライが送信される。

そして、ステップＳ３０６で、（７）に示すように、中継機能部１５０から利用者のブラウザ１２０に、中継機能部１５０が（４）で受信したリプライが転送される。
以上から、利用者のブラウザ１２０は、単に「（１）の要求に対して（７）のリプライが得られた」と認識する。例えば、利用者のブラウザ１２０は、（１）においてリソースの作成を要求すると、ＳａａＳアプリケーションサーバ１８０上の外部リソースの新規ＵＲＩを（７）で認識することができる。あるいは、利用者のブラウザ１２０は、（１）においてリソースの更新または削除を要求すると、要求した操作がＳａａＳアプリケーションサーバ１８０において成功したか否かという結果を（７）で認識することができる。

そして、利用者のブラウザ１２０が（１）で発行するＨＴＴＰリクエストでは、ＳａａＳアプリケーションサーバ１８０上のＵＲＩが指定されているので、ＳＯＰも守られている。

また、ＳａａＳアプリケーションサーバ１８０は、（３）で要求を受け付け（４）でリプライを送信するので、「リソースの作成、更新または削除が要求された」という事実および「要求は成功裡に処理された」という事実を認識することができる。

したがって、認識した結果に基づいてＳａａＳアプリケーションサーバ１８０は適切なデータ管理を行うことが可能である。例えば、ＳａａＳアプリケーションサーバ１８０は、上記の認識に基づいて、作成されたリソースの一覧情報を管理することもできるし、リソースの最終更新日時などの編集状態を管理することができる。

また、リソースの作成が要求された場合、ＳａａＳアプリケーションサーバ１８０は新規ＵＲＩを生成し、作成した新規リソースに新規ＵＲＩを割り当て、新規ＵＲＩは（７）で利用者のブラウザ１２０に通知される。それにより、新規に作成されたリソースに対する利用者のブラウザ１２０からの今後のアクセスが可能となる。

このように、ダミーデータを用いてＳａａＳアプリケーションサーバ１８０とも通信を行うことによって、個々のリソースのメタ情報のＳａａＳアプリケーションサーバ１８０内での管理と、リソース自体の内容（つまりペイロード）の秘匿が両立可能となる。

ところで、図１３に関して説明したように、第１実施形態では、内部リソースのデータとダミーデータとが同じ文書構造を持っている。その理由を、具体例を挙げて以下に説明する。

例えば、ＳａａＳアプリケーションサーバ１８０には、利用者登録のための１つ以上のリソース（以下便宜的に「利用者登録リソース」という）が存在することがある。
利用者登録リソースの１つは、例えば、利用者のブラウザ１２０を介して新規に登録をしようとする利用者が、所望の利用者ＩＤとパスワードを入力するための入力画面を表すＨＴＭＬソースコードでもよい。また、上記の１つ以上の利用者登録リソースのＵＲＩは、どれも書き換えＵＲＩ管理表１５３には登録されていないとする。

すると、入力された利用者ＩＤとパスワードは中継機能部１５０を介してＳａａＳアプリケーションサーバ１８０へと中継される。
また、もう１つの利用者登録リソースは、例えば、ＳａａＳアプリケーションサーバ１８０により実行されるプログラム（以下便宜的に「利用者登録プログラム」という）のコードを含んでいる。利用者登録プログラムは、例えばスクリプト言語で書かれていてもよい。

そして、利用者登録プログラムは、具体的には、ＳａａＳアプリケーションサーバ１８０が受信した新規の利用者ＩＤとパスワードに基づいて、アプリケーションの新規アカウントを作成するためのプログラムである。例えば、ＳａａＳアプリケーションサーバ１８０は利用者登録プログラムを実行することにより、アカウント管理用のデータベースに新規アカウント用のエントリを追加する。

さらに、ＳａａＳアプリケーションサーバ１８０は、利用者登録プログラムを実行することにより、利用者プロフィールを示すための新規リソース（以下便宜的に「プロフィールデータ」という）を作成してもよい。

例えば、新たに「yamada」という利用者ＩＤのアカウント作成が利用者のブラウザ１２０により要求されたとする。すると、ＳａａＳアプリケーションサーバ１８０は、利用者登録プログラムを実行することにより「http://www.app1.com/data/companya/data200812241430」という新たなＵＲＩに新たなプロフィールデータを作成する。

ここで作成されるプロフィールデータは、利用者登録プログラムがデフォルトとして規定した内容を持つ。例えば、作成されるプロフィールデータは、ルート要素が「userdata」要素で、「userdata」要素が「name」要素と「address」要素という２つの子要素を持つＸＭＬデータである。そして、「name」要素の内容は、「名前を入力してください」というテキストであり、「address」要素の内容は「住所を入力してください」というテキストである。すなわち、図１２の１行目に示したダミーデータと同じ内容のプロフィールデータが、例えばアカウントの作成時に作成される。

こうして作成されたプロフィールデータは、もちろん、アプリケーションデータ１８３の一部である。そして、ＳａａＳアプリケーションサーバ１８０が提供するアプリケーションには、例えばプロフィールデータを更新するためのメニュー（以下便宜的に「更新メニュー」という）が含まれている。

更新メニューは、例えば下記のコードを含むウェブページを利用者のブラウザ１２０に送信する、ＳａａＳアプリケーションサーバ１８０上のリソースにより実現される。
・XMLHttpRequestオブジェクトを利用して、現状のプロフィールデータを参照し、現状のプロフィールデータの内容を利用者のブラウザ１２０の画面に表示するためのJavaScriptソースコード。

・ＸＭＬ形式のプロフィールデータの内容を、利用者のブラウザ１２０の画面を介してローカルに編集するためのユーザインタフェイスを提供するためのJavaScriptソースコード。

・特定のボタン（以下便宜的に「更新ボタン」という）を利用者のブラウザ１２０に表示させるためのＨＴＭＬソースコード。
・ローカルに編集されたプロフィールデータを、更新ボタンの押下を契機として、XMLHttpRequestオブジェクトを利用し、ＳａａＳアプリケーションサーバ１８０に送信するためのJavaScriptソースコード。具体的には、ＰＵＴメソッドと、読み出したプロフィールデータのＵＲＩとが、送信時には指定される。

したがって、「yamada」という利用者ＩＤの利用者の操作にしたがって利用者のブラウザ１２０が更新メニューにアクセスすると、まず、図９の処理が行われ、図９のステップＳ１０６から図１１の処理が呼び出される。その結果、アカウント作成時に作成されたプロフィールデータが利用者のブラウザ１２０に取得され、図１２の１行目のエントリがダミーデータ保持部１５６に作成される。

利用者のブラウザ１２０は、JavaScriptで書かれたプログラムを実行することで、利用者の操作にしたがって、「name」要素と「address」要素の内容をローカルに編集する。そして、更新ボタンが押下されると、再び図９の処理が行われ、今度は図９のステップＳ１０７から図１５の処理が呼び出される。その結果、ＳａａＳアプリケーションサーバ１８０には、アカウント作成時と同じプロフィールデータ（すなわちダミーデータとして記憶されたのと同じ内容のデータ）が格納される一方で、社内システムサーバ１６０には、図１３のデータ８０３が格納される。

上記のようないくつかの処理の結果、第１実施形態では、ダミーデータと内部リソースのデータが同じ形式なのである。
また、上記の処理の流れによれば、ＳａａＳアプリケーションサーバ１８０に送信されるデータは、最初にＳａａＳアプリケーションサーバ１８０から読み出された、実際の氏名や住所が未入力の状態（つまり初期状態）のプロフィールデータである。図１４において「初期状態データ」という用語を用いたのも、そのためである。以上の説明からも、ダミーデータ保持部１５６が保持するダミーデータが、利用者の社内ネットワーク１１０の外部に対して秘密にする必要のないデータであることは明らかである。

続いて、第２実施形態について説明する。第１実施形態と第２実施形態の違いは、図１の書き換えＵＲＩ管理表１５３に格納される内容のみである。
第１実施形態では、ＳａａＳアプリケーションサーバ１８０の提供するアプリケーションがＲＥＳＴスタイルに則っていると仮定している。つまり、同じリソースに対して参照、更新および削除のように異なる操作が行われる場合にも、各ＨＴＴＰリクエストにおいて同じＵＲＩが指定される、と第１実施形態では仮定している。

しかし、アプリケーションの中には、ＲＥＳＴスタイルにほぼ準じてはいるものの、完全にＲＥＳＴスタイルに従っているわけではないものがある。具体的には、同じリソースに対して、操作の種類によって異なるＵＲＩを用いるアプリケーションが存在する。

すなわち、第２実施形態においてＳａａＳアプリケーションサーバ１８０が提供するアプリケーションは、１つのＵＲＩにより識別される１つのリソースが、操作の種類によって異なるＵＲＩを介してアクセスされるよう設計されている。例えば、ＳａａＳアプリケーションサーバ１８０が提供するアプリケーションは、次のように設計されているかもしれない。

・ある外部リソースを参照するためのＵＲＩは「http://www.app1.com/data/load/companya/data200812241430」である。
・同じ外部リソースに対して、更新を要求するためのＵＲＩは「http://www.app1.com/data/save/companya/data200812241430」である。

このように設計されたアプリケーションに関しても、第２実施形態によれば、データの内容を外部のＳａａＳアプリケーションサーバ１８０には秘匿しつつ、アプリケーションが提供する機能を利用者のブラウザ１２０が享受することが可能である。具体的には、第２実施形態では、書き換えＵＲＩ管理表１５３が例えば図１７のように設定されるが、それ以外の点では第２実施形態は第１実施形態と同様である。

図１７は、第２実施形態による書き換えＵＲＩ管理表の例を示す図である。例えば、図１７の書き換えＵＲＩ管理表８０５は、「yamada」という利用者ＩＤに対応する２つのエントリを含む。この２つのエントリは同じリソースに対応する。

図１７のデータ８０５は、「http://data.mycompany.com/yamada/app1/data」という書き換え先ＵＲＩに対して、「http://www.app1.com/data/load*」という書き換え対象ＵＲＩを対応させるエントリを含む。データ８０５はさらに、上記と同じ「http://data.mycompany.com/yamada/app1/data」という書き換え先ＵＲＩに対して、別の「http://www.app1.com/data/save*」という書き換え対象ＵＲＩを対応させるエントリを含む。なお、第２実施形態においても、第１実施形態と同様に、「書き換え対象ＵＲＩ」と「書き換え先ＵＲＩ」は、例えば、ＵＲＩの一部を含む文字列パターンである。

例えば、利用者のブラウザ１２０が、外部リソースの参照のために、「http://www.app1.com/data/load/companya/data200812241430」というＵＲＩとＧＥＴメソッドを指定したＨＴＴＰリクエストを送信したとする。すると、図１７のデータ８０５に基づいて、図９のステップＳ１０４では第１実施形態と同様に「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」というＵＲＩが得られる。そして、第１実施形態と同様に図１１の処理が行われる。

また、利用者のブラウザ１２０が、外部リソースの更新のために、「http://www.app1.com/data/save/companya/data200812241430」というＵＲＩとＰＵＴメソッドを指定したＨＴＴＰリクエストを送信したとする。すると、図１７のデータ８０５に基づいて、図９のステップＳ１０４では第１実施形態と同様に「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」というＵＲＩが得られる。そして、第１実施形態と同様に図１５の処理が行われる。

よって、操作の種類により異なるＵＲＩを介してアクセスを受け付けるよう設計されたアプリケーションをＳａａＳアプリケーションサーバ１８０が提供する場合も、適切に書き換えＵＲＩ管理表１５３が設定されていれば、第１実施形態と同様の効果が得られる。

続いて、「デフォルトダミーデータ」が導入される第３実施形態について説明する。
図１８は、第３実施形態による書き換えＵＲＩ管理表の例を示す図である。第１実施形態では図１０のような３列の書き換えＵＲＩ管理表１５３が利用されるが、第３実施形態では、図１８のように「ダミーデータ初期値」列が追加された４列の書き換えＵＲＩ管理表１５３が利用される。

図１８に示した書き換えＵＲＩ管理表１５３のデータ８０６の１行目のエントリにおいて、「利用者」列、「書き換え対象ＵＲＩ」列および「書き換え先ＵＲＩ」列の内容は、図１０の１行目のエントリと同じである。よって説明は省略する。また、「ダミーデータ初期値」列には、ルート要素が「userdata」要素で、「userdata」要素が「name」要素と「address」要素という２つの子要素を持つＸＭＬデータが格納されている。なお、図１８において「name」要素の内容は、「名前を入力してください」というテキストであり、「address」要素の内容は「住所を入力してください」というテキストである。

そして、データ８０６の２行目のエントリにおいて、「利用者」列、「書き換え対象ＵＲＩ」列および「書き換え先ＵＲＩ」列の内容は、図１０の３行目のエントリと同じである。よって説明は省略する。また、「ダミーデータ初期値」列には、ルート要素が「schedule」要素で、「schedule」要素は子要素を持たず、「schedule」要素の内容が空テキストであるＸＭＬデータが格納されている。

第３実施形態は、「ある種のアプリケーションでは、処理対象のリソースの種類が、リソースのＵＲＩから決定可能である」という点に着目した実施形態である。具体的には、例えば以下のように、ＳａａＳアプリケーションサーバ１８０上の外部リソースのＵＲＩから、外部リソースの形式が判明しているとする。

・「http://www.app1.com/data*」というパターンにマッチするＵＲＩで識別されるリソースは、ルート要素が「userdata」要素で、「userdata」要素が「name」要素と「address」要素という２つの子要素を持つＸＭＬデータである。

・「http://www.app2.com/schedule*」というパターンにマッチするＵＲＩで識別されるリソースは、ルート要素が「schedule」要素で、「schedule」要素は子要素を持たないＸＭＬデータである。

つまり、第３実施形態では、書き換え対象ＵＲＩに応じて上記のように予め判明しているデータ形式を持ったデータが、デフォルトダミーデータとして「ダミーデータ初期値」列に予め格納される。なお、デフォルトダミーデータは、利用者の社内ネットワーク１１０の外部に送信されても問題のない内容のみを含むように作成されるものとする。

こうして予めデータの種類に応じて用意され、書き換えＵＲＩ管理表１５３に予め格納されたデフォルトダミーデータは、図１５のステップＳ３０４で使われる。つまり、ステップＳ３０４でページ内容送受信部１５４は、「空のデータ」を生成する代わりに、書き換えＵＲＩ管理表１５３を参照してデフォルトダミーデータを取得する。

したがって、第３実施形態では、リソースの作成または更新のたびに「空のデータ」をページ内容送受信部１５４が生成する必要がない。また、第３実施形態においても、第１実施形態と同様に、ＳａａＳアプリケーションサーバ１８０には情報の内容を秘匿しつつ、アプリケーションの機能を享受することが可能である。

続いて、第４実施形態について説明する。
ウェブアプリケーションを利用する組織（例えば企業）とアプリケーションの提供者の関係は、図２ではｎ対１の例を示したが、一般にはｎ対ｎである。よって、例えば、企業Ａは、第１の提供者が提供する第１のウェブアプリケーションを利用するとともに、第２の提供者が提供する第２のウェブアプリケーションも利用するかもしれない。つまり、企業Ａ内の利用者は、第１と第２のアプリケーションの双方を利用することがありうる。

そして、場合によっては、複数のアプリケーションが共通の機能を提供していることがある。例えば、利用者の氏名と住所を管理する機能や、スケジューラ機能（カレンダ機能とも呼ばれる）は多くのアプリケーションでサポートされている。

したがって、もし複数のアプリケーション間で一部のデータを共有することができれば、下記の２つの観点から好ましい。
第１に、利用者は複数のアプリケーションのそれぞれについて、同じ内容のデータの入力作業を繰り返す必要がない。つまり利用者の負担が軽くなる。

第２に、利用者の負担を抑制しつつ複数のアプリケーションの機能を有効活用することが可能となる。
例えば、第１と第２のアプリケーションの双方がスケジューラ機能を提供している場合、利用者の負担を軽減するという観点からは、利用者は、一方のアプリケーションでのみ、スケジューラ機能を使ってもよい。しかし、第１のアプリケーションは、スケジューラ機能とメーラ機能を連携させることで、より良いサービスを提供するかもしれない。同様に、第２のアプリケーションは、スケジューラ機能とグループウェア機能を連携させることで、より良いサービスを提供するかもしれない。

この場合、もし利用者が一方のアプリケーションでのみスケジューラ機能を利用すると、利用者は、第１と第２のアプリケーションの双方の機能を有効に利用しきれない可能性がある。それに対し、もし利用者が同じ入力を繰り返さずに同じデータを第１と第２のアプリケーションで共有することができるのであれば、利用者は、第１と第２のアプリケーションの双方の機能を有効に利用することが可能となる。

以上の２つの観点から、第４実施形態では、複数のアプリケーション間でデータを共有するための付加的な仕組みを、中継機能部１５０がさらに備えている。具体的には、第４実施形態では、書き換えＵＲＩ管理表１５３に列が追加され、図１１のステップＳ２０６でデータの変換が行われ、図１５のステップＳ３０５でデータの逆変換が行われる。

なお、以下の説明において「変換」とは、社内システムサーバ１６０でのデータ形式（以下では「内部形式」という）から、ＳａａＳアプリケーションサーバ１８０でのデータ形式（以下では「外部形式」という）への変換を示す。また、「逆変換」とは、外部形式から内部形式への変換を示す。

続いて、図１９〜図２２を参照して、書き換えＵＲＩ管理表１５３と変換と逆変換の具体例を説明し、その後で、第４実施形態における処理の流れを説明する。
図１９は、第４実施形態による書き換えＵＲＩ管理表の例を示す図である。第４実施形態の書き換えＵＲＩ管理表１５３は、図１０に示した第１実施形態と同様の「利用者」列、「書き換え対象ＵＲＩ」列および「書き換え先ＵＲＩ」列を含み、さらに、「変換プログラム」列と「逆変換プログラム」列を含む。

図１９のデータ８０７の１行目のエントリは、「yamada」という利用者ＩＤと、「http://www.app1.com/data*」という文字列パターンと、「http://data.mycompany.com/yamada/app1/data」という文字列パターンを含む。

また、第４実施形態では、「http://www.app1.com/」というＵＲＩで識別される第１のＳａａＳアプリケーションサーバ（不図示）で使われる第１の外部形式が、内部形式として採用されている。そのため、１行目のエントリにおいて、変換プログラムと逆変換プログラムは「なし」と指定されている。

２行目のエントリは、「yamada」という利用者ＩＤと、「http://www.app2.com/data*」という文字列パターンと、「http://data.mycompany.com/yamada/app1/data」という文字列パターンを含む。つまり、「http://www.app2.com/」というＵＲＩで識別される第２のＳａａＳアプリケーションサーバ（不図示）に関しても、１行目と同じ「http://data.mycompany.com/yamada/app1/data」という文字列パターンが指定されている。

また、第２のＳａａＳアプリケーションサーバで使われる第２の外部形式は、内部形式としても使われている第１の外部形式とは異なる。そこで、２行目のエントリでは、内部形式のデータを第２の外部形式に変換する変換プログラムと、第２の外部形式のデータを内部形式に逆変換する逆変換プログラムが指定されている。

具体的には、第４実施形態では、ＸＳＬＴ（eXtensible Stylesheet Language Transformations）文書とＸＳＬＴプロセッサによりデータの変換と逆変換が行われる。例えば、公知のソフトウェアとして実現されるＸＳＬＴプロセッサが、第４実施形態ではページ内容送受信部１５４に組み込まれている。

そこで、変換プログラムを記憶するための中継サーバ１３０内の所定のディレクトリに記憶されている「adrsconv-app2-internal.xsl」というファイル名のＸＳＬＴ文書が２行目のエントリでは指定されている。同様に、逆変換プログラムを記憶するための中継サーバ１３０内の所定のディレクトリに記憶されている「adrsconv-internal-app2.xsl」というファイル名のＸＳＬＴ文書が２行目のエントリでは指定されている。

図２０は、第４実施形態で使われるデータ形式の一例を示す図である。以下では、上記の内部形式を兼ねる第１の外部形式が、第１実施形態に関して図１３に示したデータ８０３の形式であるとし、上記の第２の外部形式が、図２０に示す形式であるとする。

図２０のデータ８０８は、利用者の氏名と住所を管理するためのデータの一例である。データ８０８は、子要素を持たない「entry」要素をルート要素とするＸＭＬ形式のデータである。具体的には、「entry」要素は、「user」という属性値が指定された「type」属性と、「山田太郎」という氏名が属性値として指定された「name」属性と、「川崎市中原区」という住所が属性値として指定された「address」属性を有する。

内部形式でもある第１の外部形式による図１３のデータ８０３と、第２の外部形式による図２０のデータ８０８を比較すると、両者は、氏名と住所を管理するという目的は同じだが、データ形式において異なっている。

図２１は、第４実施形態における変換プログラムの例を説明する図である。すなわち、上記の所定のディレクトリに記憶されている「adrsconv-app2-internal.xsl」というファイル名のＸＳＬＴ文書の具体例を、図２１は示している。

図２１には、変換プログラム８０９（つまりＸＳＬＴ文書）と、入力データ８１０と、出力データ８１１が示されている。
入力データ８１０は、図１３のデータ８０３と同じＸＭＬデータである。出力データ８１１は図２１のデータ８０８と同じＸＭＬデータである。変換プログラム８０９は、入力データ８１０を出力データ８１１に変換する方法を記載したＸＳＬＴ文書である。

具体的には、変換プログラム８０９は、入力データ８１０の「userdata」要素を見つけて次の処理を行うようＸＳＬＴプロセッサに指示している。
・「type」属性と「name」属性と「address」属性を持つ「entry」要素を出力する。

・「type」属性の属性値には「user」と設定する。
・「name」属性の属性値には、入力データ８１０で見つけた「userdata」要素の子要素である「name」要素の内容を設定する。

・「address」属性の属性値には、入力データ８１０で見つけた「userdata」要素の子要素である「address」要素の内容を設定する。
以上のような変換プログラム８０９の指示にしたがって、ＸＳＬＴプロセッサは入力データ８１０から出力データ８１１を生成する。

図２２は、第４実施形態における逆変換プログラムの例を説明する図である。すなわち、上記の所定のディレクトリに記憶されている「adrsconv-internal-app2.xsl」というファイル名のＸＳＬＴ文書の具体例を、図２２は示している。

図２２の入力データ８１３は、図２１の出力データ８１１と同じＸＭＬデータであり、図２２の出力データ８１４は、図２１の入力データ８１０と同じＸＭＬデータである。図２２の逆変換プログラム８１２は、入力データ８１３を出力データ８１４に変換する方法を記載したＸＳＬＴ文書である。

具体的には、逆変換プログラム８１２は、入力データ８１３の「entry」要素を見つけて次の処理を行うようＸＳＬＴプロセッサに指示している。
・「name」要素と「address」要素を子要素に持つ「userdata」要素を出力する。

・「name」要素の内容として、入力データ８１３で見つけた「entry」要素の「name」属性の属性値を設定する。
・「address」要素の内容として、入力データ８１３で見つけた「entry」要素の「address」属性の属性値を設定する。

以上のような逆変換プログラム８１２の指示にしたがって、ＸＳＬＴプロセッサは入力データ８１３から出力データ８１４を生成する。
以上、図１９〜図２２を参照して第４実施形態における書き換えＵＲＩ管理表１５３のデータ８０７の例と、変換と逆変換の例について詳細に説明した。続いて、変換と逆変換を含む処理の流れについて説明する。

例えば、利用者のブラウザ１２０が第２のＳａａＳアプリケーションサーバに対して「http://www.app2.com/data/companya/data200812241430」というＵＲＩのリソースの参照を要求したとする。すると、第１実施形態と同様に図９の処理が行われる。具体的には、図１９のデータ８０７に基づき、図９のステップＳ１０４で「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」というＵＲＩが得られ、ステップＳ１０６から図１１の処理が呼び出される。

第１実施形態と異なる処理が行われるのは、図１１の処理がステップＳ２０１、Ｓ２０２、Ｓ２０３、Ｓ２０４、Ｓ２０５、Ｓ２０６の順で行われる場合である。この場合、ステップＳ２０４において、ページ内容送受信部１５４は、上記の「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」という書き換え後のＵＲＩに対して対象内部リソースの参照を要求するリクエストを送信する。したがって、ステップＳ２０４で得られるリプライには、内部形式で表されたデータが含まれる。

例えば、ステップＳ２０４では図２１の入力データ８１０が得られる。しかしながら、元のリクエストを送信した利用者のブラウザ１２０が現在利用しているのは、内部形式とは異なる第２の外部形式を採用した第２のＳａａＳアプリケーションサーバから提供されるアプリケーションである。そこで、ステップＳ２０４の後にステップＳ２０６が実行される場合は、ステップＳ２０６において、ページ内容送受信部１５４は図２１の変換プログラム８０９による変換処理を行う。

例えば、ページ内容送受信部１５４は、ステップＳ２０４で得られた、内部形式で表された入力データ８１０を変換して、第２の外部形式で表された出力データ８１１を得る。そして、ページ内容送受信部１５４は、ページ内容送信部１５５を介して、第２の外部形式で表された出力データ８１１を利用者のブラウザ１２０に送信する。

また、利用者のブラウザ１２０が第２のＳａａＳアプリケーションサーバに対して「http://www.app2.com/data/companya/data200812241430」というＵＲＩのリソースの更新を要求したとする。すると、第１実施形態と同様に図９の処理が行われる。具体的には、図１９のデータ８０７に基づき、図９のステップＳ１０４で「http://data.mycompany.com/yamada/app1/data/companya/data200812241430」というＵＲＩが得られ、ステップＳ１０７から図１５の処理が呼び出される。

第１実施形態と異なる処理が行われるのはステップＳ３０５である。すなわち、利用者のブラウザ１２０からの元のリクエストに含まれているのは第２の外部形式で表されたデータである。他方、ステップＳ３０５でのリクエストの送信先である社内システムサーバ１６０では、内部形式が使われている。そこで、ステップＳ３０５においてページ内容送受信部１５４は、図２２の逆変換プログラムによる逆変換処理を行う。

例えば、ページ内容送受信部１５４は、第２の外部形式で表された入力データ８１３を逆変換して、内部形式で表された出力データ８１４を得る。そして、ページ内容送受信部１５４は、社内システムサーバ１６０に対し、出力データ８１４を含みＰＵＴメソッドを指定したリクエストを送信する。

また、利用者のブラウザ１２０が第２のＳａａＳアプリケーションサーバに対してリソースの作成を要求した場合も、同様に、ステップＳ３０５においてページ内容送受信部１５４は逆変換処理を行う。なお、利用者のブラウザ１２０が第２のＳａａＳアプリケーションサーバに対してリソースの削除を要求した場合の処理は、第１実施形態と同様である。

なお、上記の説明では、２つのアプリケーション間で氏名と住所のデータを共有する例を示したが、複数のアプリケーション間で共有されるデータ項目が完全に一致していない場合にも、第４実施形態は適用可能である。つまり、第４実施形態によれば、複数のアプリケーションでのデータ項目の和集合を含むデータを社内システムサーバ１６０が保持することで、何らかの共通点がある複数のアプリケーション間でのデータ共有が可能となる。

例えば、第１のＳａａＳアプリケーションサーバが提供する第１のアプリケーションでは利用者の氏名が管理されるが住所は管理されず、第２のＳａａＳアプリケーションサーバが提供する第２のアプリケーションでは利用者の氏名と住所の双方が管理される場合がある。この場合、氏名と住所の双方を含む、第２のアプリケーションでのデータ形式（すなわち第２の外部形式）が、内部形式として利用されてもよい。

そして、ページ内容送受信部１５４は、第１のアプリケーションの利用時には、必要に応じた形式の変換に加えてさらに、「内部形式のデータから住所を削除する」という変換を行ってもよい。

ページ内容送受信部１５４は、第１のアプリケーションの利用時の逆変換として、例えば次のような２つの処理を含む逆変換処理を行ってもよい。
・現状の内部形式のデータに含まれる住所のデータを読み込んで、読み込んだ住所のデータをそのまま出力する。

・第１のアプリケーションを介して編集された可能性のある氏名を、利用者のブラウザ１２０からの入力データから得て、必要に応じて形式を変換したうえで、出力する。
また、第１のアプリケーションでは利用者の氏名と住所が管理され、第２のアプリケーションでは利用者の氏名と電話番号が管理される場合がある。この場合、社内システムサーバ１６０は、氏名と住所と電話番号を含むデータを内部データとして保持してもよい。

そして、ページ内容送受信部１５４は、第１のアプリケーションの利用時には、必要に応じた形式の変換に加えてさらに、「内部形式のデータから電話番号を削除する」という変換を行ってもよい。また、ページ内容送受信部１５４は、第２のアプリケーションの利用時には、必要に応じた形式の変換に加えてさらに、「内部形式のデータから住所を削除する」という変換を行ってもよい。

なお、逆変換のためには、上記の例と同様に、必要に応じてページ内容送受信部１５４は、現状の内部形式のデータに含まれる住所または電話番号のデータを読み込んで、そのまま出力の一部に加える処理を行えばよい。

以上のように第４実施形態によれば、第１〜第３実施形態と同様の効果に加えてさらに、複数のＳａａＳアプリケーションで同じデータを共有することで、柔軟にアプリケーション間の連携を実現することも可能となる。なぜなら、複数のＳａａＳアプリケーションで共通して利用されるデータは、第４実施形態によれば、個々のＳａａＳアプリケーションの提供元に分散してばらばらに格納され管理されるのではなく、社内システムサーバ１６０で一元管理されるからである。

ところで、以上説明した第１〜第４実施形態における中継サーバ１３０は、例えば、図２３に示すコンピュータ９００により実現することができる。
図２３は、コンピュータの構成図である。コンピュータ９００は、ＣＰＵ（Central Processing Unit）９０１、ＲＯＭ（Read Only Memory）９０２などの不揮発性メモリ、ワークエリア用のＲＡＭ９０３を備える。また、コンピュータ９００は、利用者のブラウザ１２０が稼働しているＰＣ、社内システムサーバ１６０およびＳａａＳアプリケーションサーバ１８０などの他のコンピュータとネットワークを介して通信を行うための、通信インタフェイス９０４を備える。

コンピュータ９００はさらに、キーボードやポインティングデバイスなどの入力装置９０５、ディスプレイやスピーカなどの出力装置９０６、ＨＤＤなどの記憶装置９０７、および可搬型記憶媒体９１０の駆動装置９０８を備える。また、コンピュータ９００が備える上記各部は、バス９０９で互いに接続されている。

以下、図９、図１１、および図１５の処理をコンピュータ９００に行わせることでコンピュータ９００を中継機能部１５０として機能させるプログラム、コンピュータ９００を中継サーバ１３０として機能させるプログラムをまとめて「中継プログラム」という。

中継プログラムは、例えば記憶装置９０７に格納され、ＲＡＭ９０３に読み込まれ、ＣＰＵ９０１によって実行されてもよい。あるいは、中継プログラムは、可搬型記憶媒体９１０に格納され、駆動装置９０８を介して読み取られ、ＲＡＭ９０３に展開され、ＣＰＵ９０１により実行されてもよい。可搬型記憶媒体９１０の例は、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Compact Disc Recordable）、ＤＶＤ（Digital Versatile Disc）、光磁気ディスク、磁気ディスク、半導体メモリカード等である。また、中継プログラムは、ネットワークと通信インタフェイス９０４を介して他のコンピュータからコンピュータ９００にダウンロードされてもよい。

図１の認証部１４１、リクエスト受付部１５１、ページ内容送受信部１５４およびページ内容送信部１５５は、例えば、ＣＰＵ９０１が通信インタフェイス９０４と協働しながら中継プログラムを実行することで実現される。リクエスト先変換部１５２は、ＣＰＵ９０１が中継プログラムを実行することで実現される。

また、図１のセッション管理表１４２は、例えばＲＡＭ９０３に記憶される。また、利用者認証情報１４３と書き換えＵＲＩ管理表１５３とダミーデータ保持部１５６は、例えば記憶装置９０７に記憶され、必要に応じてＲＡＭ９０３に読み出されてもよい。

なお、例えば第１実施形態の説明において、便宜上、利用者のブラウザ１２０から受け付けたリクエストがリクエスト受付部１５１からリクエスト先変換部１５２、ページ内容送受信部１５４へと順に出力されるように説明した。しかし、利用者のブラウザ１２０から受信したリクエストを、リクエスト受付部１５１としての通信インタフェイス９０４が、受信バッファとしてのＲＡＭ９０３に格納してもよい。そして、リクエスト先変換部１５２とページ内容送受信部１５４としてのＣＰＵ９０１が、適宜受信バッファを参照するのでもよい。

以上を換言すれば、ＣＰＵ９０１と通信インタフェイス９０４は、コンピュータ９００が接続される第１のネットワーク内のクライアントからの、第２のネットワーク内のサーバに対する第１の要求を受信する受信手段の一例であり、受信した第１の要求をサーバに中継することができる。また、受信手段としてのＣＰＵ９０１と通信インタフェイス９０４は、サーバからの、第１の要求に対する外部応答をクライアントに中継することもできる。

そして、記憶装置９０７またはＲＡＭ９０３は、サーバ上の外部リソースを判別する外部リソース判別情報と、第１のネットワーク内の内部リソースを判別する内部リソース判別情報とを対応付ける第１の対応付け情報を保持する第１の対応付け情報保持手段として機能する。また、記憶装置９０７またはＲＡＭ９０３は、外部リソースに書き込むダミー情報を保持するダミー情報保持手段、および外部リソース判別情報とダミー情報とを対応付ける第２の対応付け情報を保持する第２の対応付け情報保持手段としても機能する。第１と第２の対応付け情報の例は、それぞれ、図１０のデータ８０１と図１２のデータ８０２である。

また、ＣＰＵ９０１は、下記の検索手段、判定手段、置換手段として機能することもでき、ＣＰＵ９０１と通信インタフェイス９０４は協働して、下記の要求送信手段および発行手段として機能することもできる。

すなわち、ＣＰＵ９０１は、第１の対応付け情報を参照することにより、第１の要求の対象である対象外部リソースに対応する対象内部リソースを判別する対象内部リソース判別情報を検索する検索手段として機能する。

また、第１の要求が、要求ペイロード情報により示される内容に対象外部リソースの内容を更新することを要求しており要求ペイロード情報を含む更新要求であるか否かを判定する判定手段としても、ＣＰＵ９０１は機能する。

また、判定手段としてのＣＰＵ９０１が「第１の要求は更新要求である」と判定した場合に、ＣＰＵ９０１は、さらに置換手段として次のように動作する。すなわち、ＣＰＵ９０１は、第２の対応付け情報を参照し、対象外部リソース判別情報に対応するダミー情報を特定する。そして、ＣＰＵ９０１は、要求ペイロード情報を、対象外部リソース判別情報に対応して記憶装置９０７またはＲＡＭ９０３に記憶されており上記のようにして特定されたダミー情報に置換する。

そして、ＣＰＵ９０１と通信インタフェイス９０４は、置換が行われた第１の要求をサーバに送信することで、協働して要求送信手段として機能する。
また、ＣＰＵ９０１は、「第１の要求は更新要求である」と判定した場合に、対象内部リソースの内容を置換前の要求ペイロード情報により示される内容に更新するよう要求する第２の要求を発行する発行手段としても機能する。さらに通信インタフェイス９０４が発行手段の一部としてＣＰＵ９０１と協働してもよい。

例えば、上記実施形態では、内部リソースは中継サーバ１３０とは別の社内システムサーバ１６０に格納されているので、ＣＰＵ９０１と通信インタフェイス９０４が協働して、ＨＴＴＰリクエストの形式で第２の要求を発行し、協働して発行手段として機能する。

しかし、中継サーバ１３０と社内システムサーバ１６０が物理的に同じコンピュータ９００であってもよい。その場合、図１のアプリケーションデータ１６３は記憶装置９０７に格納されるので、図１のリクエスト受付部１６１とページ内容送信部１６２は省略可能である。また、第２の要求は、例えばコンピュータ９００内部の入出力要求として、発行手段としてのＣＰＵ９０１により発行される。

また、第１の要求が、対象外部リソースの参照を要求する参照要求であると判定したとき、ＣＰＵ９０１は、次の処理も行う。すなわち、ＣＰＵ９０１は、第１の要求に対するサーバからの外部応答に含まれており対象外部リソースの内容を示す外部応答ペイロード情報を、対象外部リソース判別情報に対応するダミー情報として記憶装置９０７に記憶させる制御を行う。さらに、ＣＰＵ９０１は、対象内部リソースの参照を要求する第３の要求を発行する。

このように第１の要求が参照要求であるとき、ＣＰＵ９０１は、必要に応じて通信インタフェイス９０４と協働しながら、第３の要求に対する応答（すなわち第１のネットワーク内で完結する通信に関する応答）をクライアントに送信するための制御を行う。第２の要求がＨＴＴＰリクエストであれば、応答はＨＴＴＰレスポンスであり、第２の要求がコンピュータ９００内部の入出力要求であれば、応答は入出力応答である。

なお、本発明は上記の実施形態に限られるものではなく、様々に変形可能である。例えば、２つ以上の上記の実施形態を適宜組み合わせることもできる。
また、ＳａａＳアプリケーションサーバ１８０が提供するアプリケーションは、ブラウザベースのウェブアプリケーションでなくてもよい。例えば、上記の各実施形態は、次のような広義のリッチクライアントアプリケーションにも適用することができる。

・利用者のＰＣなどのクライアントは、ＳａａＳアプリケーションサーバ１８０から読み出したコードにしたがって処理を行う。
・クライアントは、ＳａａＳアプリケーションサーバ１８０との間でのＨＴＴＰ通信を行う。

・上記ＨＴＴＰ通信は、第１実施形態のようにＲＥＳＴスタイルに準じているか、または第２実施形態のようにＲＥＳＴスタイルに比較的近いスタイルに則っている。
以上説明した様々な実施形態のいずれにおいても、従来は情報漏洩が心配されるために利用がためらわれた業務に関しても、利用者が入力したデータが利用者の社内ネットワーク１１０の外に出ることを防ぐことが可能となる。したがって、上記の実施形態によれば、企業ユーザ等が、外部サイトからの情報漏洩の心配なしにＳａａＳアプリケーションを利用することが可能となる。

また、上記の各実施形態によれば、利用者の社内ネットワーク１１０の外部のＳａａＳアプリケーションサーバ１８０に送信されるデータそのものが検索対象となるのではなく、ＵＲＩが検索キーとして利用される。よって、利用者のブラウザ１２０から送信されるデータが、例えばプレインテキスト形式ではなくバイナリ形式や暗号化形式などであっても、書き換えＵＲＩ管理表１５３さえ適切に管理されていれば、データが秘匿対象か否かが確実かつ適切に判断される。また、上記の各実施形態によれば、「データ形式が原因で、秘匿対象のデータか否かの判断に失敗する」あるいは「検索の結果、秘匿対象と判断されたデータの一部を機械的に置換することで、データ全体が不正な形式になってしまう」といったことが防げる。

さらに、上記各実施形態によれば、アプリケーション提供元サイト１７０の運営者にとっても利点がある。なぜなら、各利用者が自身の都合に応じて書き換えＵＲＩ管理表１５３を適宜設定しておくだけで、利用者ごとの希望に応じた情報の秘匿が可能になるので、ＳａａＳアプリケーションサーバ１８０が提供するアプリケーションには変更の必要がないからである。

また、アプリケーションデータ１８３としてＳａａＳアプリケーションサーバ１８０に格納されるダミーデータは、一般に実データよりもデータサイズが小さい。よって、上記各実施形態には、ＳａａＳアプリケーションサーバ１８０における記憶領域の節約という、ＳａａＳアプリケーションサーバ１８０にとっての利点もある。

したがって、上記各実施形態は、広範囲のＳａａＳアプリケーションについて、情報の秘匿とアプリケーションの機能の享受を両立させることが可能なので、ＳａａＳアプリケーションの普及促進に役立つ。

最後に、さらに下記の付記を開示する。
（付記１）
クライアントを有する第１のネットワーク内の中継装置において実行される中継プログラムであって、
前記中継装置に、
前記クライアントから、第２のネットワーク内のサーバに対する、該サーバ上の対象外部リソースに関する第１の要求を受信する要求受信ステップと、
前記サーバ上の外部リソースを判別する外部リソース判別情報と、前記第１のネットワーク内の内部リソースを判別する内部リソース判別情報とを対応付ける第１の対応付け情報を参照することにより、前記対象外部リソースに対応する対象内部リソースを判別する対象内部リソース判別情報を検索する検索ステップと、
前記第１の要求が、要求ペイロード情報を含み、前記対象外部リソースの内容を前記要求ペイロード情報により示される内容に更新することを要求する更新要求であるか否かを判定する判定ステップと、
前記判定ステップにおいて、前記第１の要求が前記更新要求であると判定された場合に、外部リソース判別情報と第１のネットワーク内のダミー情報保持部に保持されたダミー情報とを対応付ける第２の対応付け情報を参照し、前記対象外部リソースを判別する対象外部リソース判別情報に対応するダミー情報を特定し、前記要求ペイロード情報を、特定された前記ダミー情報により置換する第１の置換ステップと、
前記置換ステップにおいて前記置換が行われた後、置換後の前記第１の要求を、前記サーバに送信する第１の要求送信ステップと、
前記第１の要求送信ステップにおいて、置換後の前記第１の要求を前記サーバに送信する場合に、前記対象内部リソースの内容を置換前の前記要求ペイロード情報により示される前記内容に更新するよう要求する第２の要求を発行する第１の発行ステップと、
を実行させることを特徴とする中継プログラム。
（付記２）
前記検索ステップの結果、前記対象内部リソースを判別する前記内部リソース判別情報が見つからなかった場合は、前記中継装置に、さらに、
前記第１の要求を前記サーバに送信する第２の要求送信ステップと、
前記第１の要求に対して前記サーバから得られる外部応答の内容を前記クライアントに送信する第１の応答送信ステップと、
を実行させることを特徴とする付記１に記載の中継プログラム。
（付記３）
前記第１の置換ステップにおいて、前記対象外部リソース判別情報に対応する前記ダミー情報が見つからなかった場合に、前記対象外部リソース判別情報に対応に対応付けられて予め記憶されているデフォルトダミー情報を取得し、前記要求ペイロード情報を前記デフォルトダミー情報に置換する第２の置換ステップを、
さらに前記中継装置に実行させることを特徴とする付記１または２に記載の中継プログラム。
（付記４）
前記第１の発行ステップは、前記対象外部リソース判別情報に対応付けられている逆変換プログラムにしたがって前記要求ペイロード情報の形式を逆変換する逆変換ステップを含み、前記第１の発行ステップでは、逆変換された前記要求ペイロード情報を含む前記第２の要求が発行されることを特徴とする付記１から３のいずれか１項に記載の中継プログラム。
（付記５）
前記対象外部リソースおよび前記対象内部リソースはＸＭＬ文書であり、
前記逆変換プログラムはＸＳＬＴ文書である、
ことを特徴とする付記４に記載の中継プログラム。
（付記６）
前記判定ステップにおいて、前記第１の要求が前記対象外部リソースの参照を要求する参照要求であると判定された場合に、前記第１の要求をそのまま前記サーバに送信する第２の要求送信ステップと、
前記第２の要求送信ステップにおいて、前記第１の要求をそのまま前記サーバに送信した場合に、前記第１の要求に対する前記サーバからの外部応答に含まれており前記対象外部リソースの前記内容を示す外部応答ペイロード情報を、前記対象外部リソース判別情報に対応するダミー情報として前記ダミー情報保持部に保持させ、かつ、前記対象内部リソースの参照を要求する第３の要求を発行する第２の発行ステップと、
をさらに前記中継装置に実行させることを特徴とする付記１から５のいずれか１項に記載の中継プログラム。
（付記７）
前記第１の要求が前記対象外部リソースの参照を要求する前記参照要求であるとき、前記対象内部リソースがもし存在しなければ、
前記対象外部リソース判別情報に対応付けられた前記ダミー情報を取得し、取得した前記ダミー情報を含むように加工したダミー応答を前記クライアントに送信する第２の応答送信ステップを、
前記中継装置に実行させることを特徴とする付記６に記載の中継プログラム。
（付記８）
前記第３の要求に対する内部応答を受信し、前記対象内部リソースの内容を示す情報として前記内部応答に含まれている内部応答ペイロード情報の形式を、前記対象外部リソース判別情報に対応付けられている変換プログラムにしたがって変換し、変換された前記内部応答ペイロード情報を含む応答を前記クライアントに送信する第３の応答送信ステップ
をさらに前記中継装置に実行させることを特徴とする付記６に記載の中継プログラム。
（付記９）
前記対象外部リソースおよび前記対象内部リソースはＸＭＬ文書であり、
前記変換プログラムはＸＳＬＴ文書である、
ことを特徴とする付記８に記載の中継プログラム。
（付記１０）
前記第１の要求はＨＴＴＰリクエストであり、前記サーバは前記第１の要求に対してＨＴＴＰレスポンスを返すことを特徴とする付記１から９のいずれか１項に記載の中継プログラム。
（付記１１）
前記第２の要求は、前記対象内部リソースを記憶する記憶装置を備える前記第１のネットワーク内の内部サーバに対するＨＴＴＰリクエストであり、
前記内部サーバは前記第２の要求に対してＨＴＴＰレスポンスを返す、
ことを特徴とする付記１０に記載の中継プログラム。
（付記１２）
前記中継装置が、前記対象内部リソースを記憶する記憶装置を備えており、
前記第２の要求は、前記記憶装置に対する入出力要求であり、
前記記憶装置は、前記入出力要求に対する入出力応答を返す、
ことを特徴とする付記１０に記載の中継プログラム。
（付記１３）
前記対象外部リソース判別情報は、前記対象外部リソースを識別する第１のＵＲＩまたは前記第１のＵＲＩの少なくとも一部を含む文字列パターンであり、
前記対象内部リソース判別情報は、前記対象内部リソースを識別する第２のＵＲＩ、前記対象内部リソースが記憶される記憶装置における前記対象内部リソースのローカルパス、または、前記第２のＵＲＩもしくは前記ローカルパスの少なくとも一部を含む文字列パターンである、
ことを特徴とする付記１から１２のいずれか１項に記載の中継プログラム。
（付記１４）
前記クライアントは、前記サーバから読み込んだクライアント側プログラムにしたがって前記第１の要求を発行するウェブブラウザであることを特徴とする付記１から１３のいずれか１項に記載の中継プログラム。
（付記１５）
クライアントを有する第１のネットワーク内の中継装置であって、
前記クライアントから、第２のネットワーク内のサーバに対する、該サーバ上の対象外部リソースに関する第１の要求を受信する受信手段と、
前記サーバ上の外部リソースを判別する外部リソース判別情報と、前記第１のネットワーク内の内部リソースを判別する内部リソース判別情報とを対応付ける第１の対応付け情報を保持する第１の対応付け情報保持手段と、
ダミー情報を保持するダミー情報保持手段と、
前記外部リソース判別情報と前記ダミー情報とを対応付ける第２の対応付け情報を保持する第２の対応付け情報保持手段と、
前記第１の対応付け情報を参照することにより、前記対象外部リソースに対応する対象内部リソースを判別する対象内部リソース判別情報を検索する検索手段と、
前記第１の要求が、要求ペイロード情報を含み、前記対象外部リソースの内容を前記要求ペイロード情報により示される内容に更新することを要求する更新要求であるか否かを判定する判定手段と、
前記第１の要求が前記更新要求であると前記判定手段が判定した場合に、前記第２の対応付け情報を参照し、前記対象外部リソースを判別する対象外部リソース判別情報に対応するダミー情報を特定し、前記要求ペイロード情報を、特定された前記ダミー情報により置換する置換手段と、
前記置換手段による置換が行われた前記第１の要求を、前記サーバに送信する要求送信手段と、
前記第１の要求が前記更新要求であると前記判定手段が判定した場合に、前記対象内部リソースの内容を置換前の前記要求ペイロード情報により示される前記内容に更新するよう要求する第２の要求を発行する発行手段と、
を備えることを特徴とする中継装置。

１００、２００、３００、４００、５００、６００、７００ システム
１１０、２１０、２２０、３１０、４１０、５１０、６１０、７１０ 利用者（例えばユーザ企業Ａまたはユーザ企業Ｂ）の社内ネットワーク
１１１、２１１、２２１、３１１、４１１、５１１、６１１ ファイヤウォール
１２０、２１２、２２２、３１２、４１２、５１２、６１２、７１１ （利用者の）ブラウザ
１２１、１８４、５１３、５２３、６１５、６２２ 画面表示および処理ロジックのコード
１３０ 中継サーバ
１４０ 認証機能部
１４１ 認証部
１４２ セッション管理表
１４３ 利用者認証情報
１５０ 中継機能部
１５１、１６１、１８１ リクエスト受付部
１５２ リクエスト先変換部
１５３ 書き換えＵＲＩ管理表
１５４ ページ内容送受信部
１５５、１６２、１８２ ページ内容送信部
１５６ ダミーデータ保持部
１６０、４１３、６１３ 社内システムサーバ
１６３、１８３、２４２、３２２、４１４、５２２、６１４、７２２ アプリケーションデータ
１７０、２４０、３２０、４２０、５２０、６２０、７２０ アプリケーション提供元サイト
１８０、２４１、３２１、４２１、５２１、６２１、７２１ ＳａａＳアプリケーションサーバ
２１３、２２３、３１３、３２４ 画面表示のコード
２４３ 顧客管理機能
２４４ サプライチェーン管理機能
２４５ グループウェア機能
２５０ ネットワーク
３２３、４２２ 処理ロジックのコード
７２３ 企業Ａのデータ
７２４ 企業Ｂのデータ
７２５〜７２７、８０１〜８０８ データ
８０９ 変換プログラム
８１０、８１３ 入力データ
８１１、８１４ 出力データ
８１２ 逆変換プログラム
９００ コンピュータ
９０１ ＣＰＵ
９０２ ＲＯＭ
９０３ ＲＡＭ
９０４ 通信インタフェイス
９０５ 入力装置
９０６ 出力装置
９０７ 記憶装置
９０８ 駆動装置
９０９ バス
９１０ 可搬型記憶媒体

Claims (5)

1. クライアントを有する第１のネットワーク内の中継装置において実行される中継プログラムであって、前記中継装置に、
   前記クライアントから、第２のネットワーク内のサーバに対する、該サーバ上の対象外部リソースに関する第１の要求を受信し、
   前記サーバ上の外部リソースを判別する外部リソース判別情報と、前記第１のネットワーク内の内部リソースを判別する内部リソース判別情報とを対応付ける第１の対応付け情報を参照することにより、前記対象外部リソースに対応する対象内部リソースを判別する対象内部リソース判別情報を検索し、
   検索の結果、前記対象内部リソース判別情報が特定され、かつ、前記第１の要求が、要求ペイロード情報を含み、前記対象外部リソースの内容を前記要求ペイロード情報により示される内容に更新することを要求する更新要求である場合に、
   前記外部リソース判別情報と第１のネットワーク内のダミー情報保持部に保持されたダミー情報とを対応付ける第２の対応付け情報を参照し、
   前記対象外部リソースを判別する対象外部リソース判別情報に対応するダミー情報を特定し、
   前記要求ペイロード情報を、特定された前記ダミー情報により置換し、
   前記要求ペイロード情報を前記ダミー情報に置換した後の前記第１の要求を、前記サーバに送信し、
   前記対象内部リソースの内容を置換前の前記要求ペイロード情報により示される前記内容に更新するよう要求する第２の要求を、前記第１のネットワーク内において前記対象内部リソースを記憶している記憶手段に対して発行する
   ことを含む処理を実行させることを特徴とする中継プログラム。
2. 前記検索の結果、前記対象内部リソース判別情報が特定され、かつ、前記第１の要求が前記更新要求である場合に、さらに、
   前記要求ペイロード情報を前記ダミー情報に置換した後の前記第１の要求に対する第１の応答を前記サーバから受信し、
   前記第２の要求に対する第２の応答を前記記憶手段から取得し、
   前記第１の応答の内容を前記クライアントに送信する
   処理を前記中継装置に実行させることを特徴とする請求項１に記載の中継プログラム。
3. 前記ダミー情報は前記外部リソースと同じ形式であることを特徴とする請求項１または２記載の中継プログラム。
4. 前記外部リソース判別情報と前記内部リソース判別情報が、いずれも文字列パターンにより表されることを特徴とする請求項１から３のいずれか１項記載の中継プログラム。
5. クライアントを有する第１のネットワーク内の中継装置であって、
   前記クライアントから、第２のネットワーク内のサーバに対する、該サーバ上の対象外部リソースに関する第１の要求を受信する受信手段と、
   前記サーバ上の外部リソースを判別する外部リソース判別情報と、前記第１のネットワーク内の内部リソースを判別する内部リソース判別情報とを対応付ける第１の対応付け情報を保持する第１の対応付け情報保持手段と、
   ダミー情報を保持するダミー情報保持手段と、
   前記外部リソース判別情報と前記ダミー情報とを対応付ける第２の対応付け情報を保持する第２の対応付け情報保持手段と、
   前記第１の対応付け情報を参照することにより、前記対象外部リソースに対応する対象内部リソースを判別する対象内部リソース判別情報を検索する検索手段と、
   前記検索手段による検索の結果、前記対象内部リソース判別情報が特定され、かつ、前記第１の要求が、要求ペイロード情報を含み、前記対象外部リソースの内容を前記要求ペイロード情報により示される内容に更新することを要求する更新要求である場合に、前記第２の対応付け情報を参照し、前記対象外部リソースを判別する対象外部リソース判別情報に対応するダミー情報を特定し、前記要求ペイロード情報を、特定された前記ダミー情報により置換する置換手段と、
   前記検索手段による前記検索の結果、前記対象内部リソース判別情報が特定され、かつ、前記第１の要求が前記更新要求である場合に、前記置換手段による置換が行われた前記第１の要求を、前記サーバに送信する要求送信手段と、
   前記検索手段による前記検索の結果、前記対象内部リソース判別情報が特定され、かつ、前記第１の要求が前記更新要求である場合に、前記対象内部リソースの内容を置換前の前記要求ペイロード情報により示される前記内容に更新するよう要求する第２の要求を、前記第１のネットワーク内において前記対象内部リソースを記憶している記憶手段に対して発行する発行手段と、
   を備えることを特徴とする中継装置。

Images