(57)【要約】【課題】Ｗｅｂアプリケーションの提供者に直接データを受け渡すことなくＷｅｂアプリケーションを利用可能とする。【解決手段】ユーザインタフェース機能を提供するアプリケーションプロバイダ３０は、Ｗｅｂブラウザ１０上で動作するユーザインタフェース機能を提供するためのアプリケーションスクリプト３２を、ユーザが操作するＷｅｂブラウザ１０に送信する。接続情報を用いてアプリケーションプロバイダ３０と連携し、データ操作に関する機能を提供するデータプロバイダ２０は、Ｗｅｂブラウザ１０上でのユーザの操作に伴ってデータ操作処理が必要になった場合、データの追加・修正・削除・参照などの要求に応じて保持するデータを操作し、その結果の情報のみを要求元のＷｅｂブラウザ１０に返信する。【選択図】図１
2009015816.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂブラウザを利用するユーザからの要求に基づき、Ｗｅｂ上でアプリケーションのサービスを提供するＷｅｂアプリケーション構成方法であって、
前記Ｗｅｂブラウザに対し、ユーザインタフェース機能を提供するユーザインタフェースサーバと、データを保持し、当該データの操作に関するデータ操作機能を提供するデータ操作サーバとを用い、前記Ｗｅｂブラウザは、前記ユーザインタフェースサーバの前記ユーザインタフェース機能に基づき画面表示を行い、
前記データ操作サーバは、前記画面表示された前記Ｗｅｂブラウザから入力される要求に応じて、前記データ操作機能を実行し、操作結果を前記Ｗｅｂブラウザに送信する
Ｗｅｂアプリケーション構成方法。
【請求項２】
請求項１記載のＷｅｂアプリケーション構成方法であって、
前記データ操作サーバは、前記データ操作サーバに接続するために必要な接続情報を保持し、当該接続情報に従って前記ユーザインタフェースサーバとの接続方法を設定し、前記データ操作機能と前記ユーザインタフェース機能とを連携して動作させる
Ｗｅｂアプリケーション構成方法。
【請求項３】
請求項２記載のＷｅｂアプリケーション構成方法において、
前記データ操作サーバは、前記接続情報に従って前記ユーザインタフェースサーバとの接続方法を設定する処理を行う画面情報を生成し前記Ｗｅｂブラウザに提供する
Ｗｅｂアプリケーション構成方法。
【請求項４】
請求項２記載のＷｅｂアプリケーション構成方法において、
前記データ操作サーバは、前記ユーザインタフェース機能の動作設定をユーザ毎に行うユーザ設定情報を更に保持し、該ユーザ設定情報と前記接続情報に従って、前記ユーザインタフェースサーバとの接続方法を設定する処理を行う画面情報を生成し前記Ｗｅｂブラウザに提供する
Ｗｅｂアプリケーション構成方法。
【請求項５】
請求項２記載のＷｅｂアプリケーション構成方法において、
前記ユーザインタフェースサーバは、前記ユーザインタフェース機能の動作設定をユーザ毎に行うユーザ設定情報を保持し、該ユーザ設定情報に従って動作する
Ｗｅｂアプリケーション構成方法。
【請求項６】
請求項１記載のＷｅｂアプリケーション構成方法において、
前記データ操作サーバは、保持する前記データを分析するデータ分析機能を更に具備する
Ｗｅｂアプリケーション構成方法。
【請求項７】
請求項６記載のＷｅｂアプリケーション構成方法において、
前記データ操作サーバは、前記データ分析機能の分析結果を前記データ操作機能として提供する
Ｗｅｂアプリケーション構成方法。
【請求項８】
請求項６記載のＷｅｂアプリケーション構成方法において、
前記ユーザインタフェースサーバの前記ユーザインタフェース機能は、前記データ操作サーバが提供する前記分析結果を利用する
Ｗｅｂアプリケーション構成方法。
【請求項９】
ユーザからの要求に基づき、Ｗｅｂ上でアプリケーションのサービスを提供するためのＷｅｂアプリケーション構成システムであって、
前記ユーザが要求を入力するＷｅｂブラウザと、
前記ユーザの要求に対応するユーザインタフェース機能を提供するユーザインタフェースサーバと、
データを記憶し、データ操作に関する機能を構成するデータ操作サーバとを有し、
前記Ｗｅｂブラウザは、前記ユーザインタフェースサーバから、前記ユーザインタフェース機能のためのアプリケーションスクリプトを受信し、受信した前記アプリケーションスクリプトを用いて画面表示し、
前記データ操作サーバは、前記Ｗｅｂブラウザから入力される要求に応じて、前記データ操作機能を実行し、操作結果を前記Ｗｅｂブラウザに送信する
Ｗｅｂアプリケーション構成システム。
【請求項１０】
請求項９記載のＷｅｂアプリケーション構成システムであって、
前記データ操作サーバは、前記データ操作サーバに接続するために必要な情報を登録した接続情報を記憶し、前記接続情報に従って、前記ユーザインタフェースサーバとの接続方法を設定し、前記データ接続機能と前記ユーザインタフェース機能とを連携する
Ｗｅｂアプリケーション構成システム。
【請求項１１】
請求項１０記載のＷｅｂアプリケーション構成システムであって、前記データ操作サーバは、前記接続情報に従って前記ユーザインタフェースサーバとの接続方法を設定する処理を行う画面情報を生成し、生成した前記画面情報を前記Ｗｅｂブラウザに提供する
Ｗｅｂアプリケーション構成システム。
【請求項１２】
請求項１１記載のＷｅｂアプリケーション構成システムであって、前記データ操作サーバは、前記ユーザインタフェース機能の動作設定をユーザ毎に行うユーザ設定情報を記憶し、前記ユーザ設定情報に従って、前記ユーザ毎に前記画面情報を生成する
Ｗｅｂアプリケーション構成システム。
【請求項１３】
請求項１０記載のＷｅｂアプリケーション構成システムであって、前記ユーザインタフェースサーバは、前記ユーザインタフェース機能の動作設定をユーザ毎に行うユーザ設定情報を記憶し、前記ユーザ設定情報に従って動作する
Ｗｅｂアプリケーション構成システム。
【請求項１４】
請求項９記載のＷｅｂアプリケーション構成システムであって、
前記データ操作サーバは、前記データとしてコンテンツデータを記憶しており、
前記データ操作サーバは記憶するする前記コンテンツデータを分析する分析機能を更に具備し、前記分析機能の分析結果を前記コンテンツデータの一部として記憶する
Ｗｅｂアプリケーション構成システム。
【請求項１５】
請求項１４記載のＷｅｂアプリケーション構成システムであって、
前記データ操作サーバは、前記分析結果を前記データ操作に関する機能として提供する
Ｗｅｂアプリケーション構成システム。
【請求項１６】
請求項１４記載のＷｅｂアプリケーション構成システムであって、
前記ユーザインタフェースサーバは、広告情報を記憶し、前記広告情報を配信する配信機能を有し、
前記データ操作サーバは、前記Ｗｅｂブラウザからのコンテンツの特徴情報の取得要求に応答し、前記分析結果を前記特徴情報として前記Ｗｅｂブラウザに提供し、
前記Ｗｅｂブラウザは、前記特徴情報に適した広告情報の取得要求を前記ユーザインタフェースサーバに送信し、
前記ユーザインタフェースサーバの前記配信機能は、記憶する前記広告情報中前記特徴情報に関連するものを前記Ｗｅｂブラウザに配信する
Ｗｅｂアプリケーション構成システム。
【請求項１７】
請求項９記載のＷｅｂアプリケーション構成システムであって、
前記ユーザインタフェースサーバと前記データ操作サーバが、データ管理企業内に設置されているＷｅｂアプリケーション構成システム。
【請求項１８】
ユーザ企業からの要求に基づき、Ｗｅｂ上でアプリケーションのサービスを提供するためのＷｅｂアプリケーション構成システムであって、
前記ユーザ企業が要求を入力するＷｅｂブラウザと、
前記ユーザ企業とネットワークを介して接続されるデータ管理企業内に設置され、前記ユーザ企業の要求に対応するユーザインタフェース機能を提供するユーザインタフェースサーバと、
前記データ管理企業内に設置され、データを記憶し、データ操作に関する機能を構成するデータ操作サーバとを有し、
前記Ｗｅｂブラウザは、前記ユーザインタフェースサーバから、前記ユーザインタフェース機能のためのアプリケーションスクリプトを受信し、受信した前記アプリケーションスクリプトを用いて画面表示し、
前記データ操作サーバは、前記Ｗｅｂブラウザから入力される要求に応じて、前記データ操作機能を実行し、操作結果を前記Ｗｅｂブラウザに送信する
Ｗｅｂアプリケーション構成システム。
【請求項１９】
請求項１８記載のＷｅｂアプリケーション構成システムであって、
前記データ操作サーバは、前記データ操作サーバに接続するために必要な情報を登録した接続情報を記憶し、前記接続情報に従って、前記ユーザインタフェースサーバとの接続方法を設定し、前記データ接続機能と前記ユーザインタフェース機能とを連携する
Ｗｅｂアプリケーション構成システム。
【請求項２０】
請求項１８記載のＷｅｂアプリケーション構成システムであって、前記データ操作サーバは、前記接続情報に従って前記ユーザインタフェースサーバとの接続方法を設定する処理を行う画面情報を生成し、生成した前記画面情報を前記Ｗｅｂブラウザに提供する
Ｗｅｂアプリケーション構成システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂアプリケーションのシステム構成方法に関し、ユーザ（利用者）の扱うデータの格納先を所望の場所に制限することのできる技術に関する。
【背景技術】
【０００２】
これまでクライアント装置上で実行するデスクトップアプリケーションとして実装されてきた企業内の業務システムの多くが、Ｗｅｂ上のサービス（Ｗｅｂアプリケーション）として提供されはじめている。このようなＷｅｂ上のサービスの利用が広まるに従い、ユーザ個人のプライバシー情報や社内の営業情報などをＷｅｂサーバ側に漏洩してしまう問題があった。
【０００３】
この問題に対処すべく、特許文献１にサービスを提供するＷＥＢサービス提供装置及び認証機関へのそれぞれの情報を送信する場合に行う暗号化、復号に必要となるユーザの秘密鍵を格納する耐タンパ性記憶装置と、当該耐タンパ性記憶装置に格納されているユーザの秘密鍵により暗号化の処理を行うＣＰＵを具備する装置によりユーザのプライバシー情報を保護する方法が記載されている。
【０００４】
この方法によれば、ユーザにとって煩雑な処理操作を低減させ、秘密鍵等のユーザのプライバシー情報が第３者に獲得される危険性を低減することができる。
【０００５】
また、特許文献２に、選択されたキーワード及び選択された要素をそれぞれ秘密にして、送信された購入希望情報を受信すると、購入希望情報及び秘密鍵から送付鍵を計算し、利用者端末に送信し、利用者端末に、送付鍵、選択された要素、複数の情報から、選択されたキーワードに対応する情報のみを復号化させる装置により、利用者が選択した情報（そのアブストラクト）を情報提供者に秘匿した状態で、選択した情報の詳細を利用者に提供する方法が記載されている。
【０００６】
この方法によれば、ユーザは情報提供者にどの情報を必要としているのかを秘匿したまま、情報提供者から取得したい情報を獲得することができる。
【０００７】
【特許文献１】特開２００３−３０４２３４号公報
【特許文献２】特開２００６−３９６７４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
従来の技術では、利用者側の装置や情報の提供者側の装置に情報秘匿のための特別な装置やプログラムを設置しなければならないという課題がある。また、情報秘匿の対象が認証処理の際に通信される情報であったり、取得したい情報を示す情報であったり、限定された場面や情報を対象としており、汎用的に活用できないという課題がある。
【０００９】
本発明はこれらの課題に鑑みてなされたものであり、利用者側には特別な機能や装置を新たに導入することなく、且つ利用者のデータをアプリケーション提供者に対し渡すことなく、提供者の提供するアプリケーションを利用できるシステムを提供することにある。
【課題を解決するための手段】
【００１０】
上記の目的を達成するため、本発明のシステムは、通常単一のサーバ（組織）で提供されるＷｅｂ上でサービスされるアプリケーション（以下、Ｗｅｂアプリケーション）の機能を二つに分割し、ユーザインタフェースの機能を提供するユーザインタフェースサーバ（組織）（以下、アプリケーションプロバイダと呼ぶ）とデータ操作に関する機能を提供するデータ操作サーバ（組織）（以下、データプロバイダと呼ぶ）の二つのサーバ（組織）によりＷｅｂアプリケーションの機能を提供するように構成する。
【００１１】
旧来のＷｅｂアプリケーションでは、ユーザインタフェースの機能はＷｅｂアプリケーションを提供するサーバにより生成されるＨＴＭＬにより構成され、ユーザが情報を入力するとその情報がＷｅｂアプリケーションを提供するサーバに送信され、Ｗｅｂアプリケーションサーバは入力された情報を反映したＨＴＭＬを生成しそれをＷｅｂブラウザに送信して新たな画面を表示させる、という処理を繰り返すものである。データ操作に関する機能についても同一のサーバにより提供され、上記のユーザの入力を反映したＨＴＭＬを生成する際にデータ操作に関する処理も実行する。
【００１２】
本発明のシステムによる、アプリケーションプロバイダはＷｅｂブラウザ上で動作するプログラム（以下、アプリプログラム）をユーザが操作するＷｅｂブラウザに提供する。このアプリプログラムはＷｅｂブラウザ上で動作するプログラムであるため、画面上の表示を変更する際にアプリケーションプロバイダのサーバへのアクセスの必要をなくすことができる。
【００１３】
本発明のシステムによる、データプロバイダはユーザインタフェースを提供するためのＨＴＭＬの生成処理は行わず、データの追加・修正・削除・参照といった要求に応じて、データプロバイダ内のサーバ内で保持するデータを操作し、その結果の情報のみを要求元に返信する。
【００１４】
アプリプログラムにおいてユーザの操作に伴いデータ操作処理が必要な部分は、データプロバイダの通信の仕様に従ってデータプロバイダに対し通信を行うようにすることで、データプロバイダにデータ操作処理を行わせることができる。
【００１５】
すなわち、本発明においては、Ｗｅｂブラウザを利用するユーザからの要求に基き、Ｗｅｂ上でアプリケーションのサービスを提供するＷｅｂアプリケーション構成方法として、Ｗｅｂブラウザに対し、ユーザインタフェース機能を提供するユーザインタフェースサーバと、データを保持し、このデータの操作に関するデータ操作機能を提供するデータ操作サーバとを備え、Ｗｅｂブラウザがユーザインタフェースサーバからユーザインタフェース機能のためのアプリプログラム（アプリケーションスクリプト）を受信し、受信したアプリプログラム（アプリケーションスクリプト）に基づき画面を表示し、この画面表示されたＷｅｂブラウザから入力される要求に応じて、データ操作サーバがデータ操作機能を実行し、その操作結果をＷｅｂブラウザが受信することにより画面表示を更新するＷｅｂアプリケーション構成方法、及びその構成システムを提供する。
【発明の効果】
【００１６】
この本発明によれば、Ｗｅｂアプリケーションの機能を、ユーザインタフェースの機能とデータ操作に関する機能との二つに分割し、それぞれ別のサーバに配備することができ、Ｗｅｂアプリケーションが扱うデータをユーザインタフェースの機能を提供するユーザインタフェースサーに直接渡さずに、Ｗｅｂアプリケーションを利用することができるシステムをユーザに提供することができる。
【００１７】
更に、好適にはデータ操作に関する機能を提供するデータ操作サーバをユーザの組織内やユーザの信頼する組織内に配備することで、ユーザの扱う情報を外部に漏洩することなく、ユーザの組織およびユーザの信頼する組織の外部の組織が提供するユーザインタフェースの機能を利用したＷｅｂアプリケーションを利用することができる。
【００１８】
また更に、異なる複数のユーザインタフェース機能により共通のデータに対する操作を行うシステムを容易に提供することができる。更にまた、複数のユーザインタフェース機能を提供するサーバを利用対象として登録し選択可能にすることができるため、データを外部に送信するような不正なプログラムを排除することが可能である。
【発明を実施するための最良の形態】
【００１９】
以下、添付の図面を参照しながら、本発明にかかわる実施の形態について説明する。
【実施例１】
【００２０】
まず、図１により、第一の実施例に係るネットワークシステムの全体構成について説明する。
【００２１】
実施例1に係るネットワークシステムには、ネットワークに接続された複数の情報処理装置１０、２０、３０が含まれている。これらの情報処理装置の中には、（１）Ｗｅｂブラウザがインストールされた１台以上の情報処理装置（以下、Ｗｅｂブラウザ）１０、（２）本システムで提供するＷｅｂアプリケーションの機能のうち、データの検索・追加・削除・編集・参照といったデータ操作に関する機能を提供する情報処理装置（以下、データプロバイダ）２０、（３）本システムで提供するＷｅｂアプリケーションの機能のうちＷｅｂブラウザ上で提供するユーザインタフェースの機能を提供する情報処理装置（以下、アプリケーションプロバイダ）３０が含まれている。
なお、図１ではＷｅｂブラウザ１０はユーザの数だけ存在しうるが、ここでは説明のためひとつだけ示している。また、複数の情報処理装置はそれぞれ、通常のコンピュータシステムで構成され、処理部（ＣＰＵ）、メモリやディスク装置などの記憶部、外部ネットワークに接続される通信部等を有することは言うまでもない。
【００２２】
以下、実施例１の構成要素の機能および処理手順について説明する。データプロバイダ２０は、ネットワークを介してＷｅｂブラウザ１０からの処理要求を受け付け、処理要求に応じたＷｅｂページを返信するＷｅｂサーバ２０１と、本システムによるＷｅｂアプリケーションを実行するための初期ページを生成する初期ページ生成機能２０２と、アプリケーションプロバイダ３０が提供するアプリプログラムとしてのアプリケーションスクリプト３２とデータプロバイダ２０が提供する機能を接続するために必要な情報を保持する接続情報２０３と、本システムによるＷｅｂアプリケーションで扱うデータを操作する処理を行うためのユーザインタフェース機能を提供するデータＡＰＩ（Application Program Interface）機能２０４と、本システムによるＷｅｂアプリケーションで扱うコンテンツデータ２０５と、ユーザの個人設定情報２０６とから構成される。接続情報２０３、コンテンツデータ２０５、個人設定情報２０６は記憶部に記憶されており、初期ページ生成機能２０２とデータＡＰＩ機能２０４はプログラムであり、通常、上述の記憶部に記憶され、処理部で実行される。
【００２３】
一方、アプリケーションプロバイダ３０は、ネットワークを介してＷｅｂブラウザ１０からの処理要求を受け付け、処理要求に応じたアプリケーションスクリプトを返信するＷｅｂサーバ３１と、本システムによるＷｅｂアプリケーションの機能のうちユーザインタフェースの機能を提供するアプリプログラムであるアプリケーションスクリプト３２とから構成される。このアプリケーションスクリプト３２等のプログラムは、通常、プロバイダ３０を構成する情報処理装置の記憶部に記憶されている。
【００２４】
実施例１のシステムはＷｅｂブラウザ１０とデータプロバイダ２０およびアプリケーションプロバイダ３０との間でネットワークを介して通信を行いながら、データの操作処理（データの作成、編集、参照、削除）に関してはデータプロバイダ２０のデータＡＰＩ機能を利用し、ユーザインタフェース機能についてはアプリケーションプロバイダ３０の提供する機能を利用するアプリケーション実行環境をユーザに提供する。
【００２５】
以下、実施例１のシステムの処理手順を具体的に説明する。
【００２６】
ここでは本システムの適用例として予定管理アプリケーションを例にとって説明する。図１１に予定管理アプリケーションが提供する画面の一例を示す。同図において、１１０１の部分は２００７年２月２１日から始まる予定を新規に追加するためもので、ユーザが予定の情報を入力した状態であり、１１０２のａｄｄボタンを押すことで予定情報を追加することができる。１１０３の部分はすでに登録されている予定情報を表示している部分で、２００７年２月２３日に「ｗｅｂ  ｍｅｅｔｉｎｇ」の予定があることを示している。例にあげる予定管理アプリケーションは画面上にカレンダを表示するとともにユーザの予定情報をそのカレンダ上に表示するものであり、ユーザは予定情報の追加・修正・削除・閲覧の操作を行うことができるものとする。
【００２７】
予定管理アプリケーションを実施例１のシステムに適用する場合、アプリケーションプロバイダ３０はＷｅｂブラウザ１０の画面上にカレンダや予定情報を表示したり、予定情報の操作処理をしたりする機能を提供するアプリケーションスクリプト３２を提供し、データプロバイダ２０は予定情報をコンテンツデータ２０５に保持し、予定情報の追加・修正・削除・参照の機能をデータＡＰＩ機能２０４により提供する。
【００２８】
アプリケーションプロバイダ３０が提供するアプリケーションスクリプト３２は、そのデータ操作処理に関してはデータプロバイダ２０が提供するデータＡＰＩ機能２０４にそってデータプロバイダ２０に対し通信を行い、データプロバイダ２０にデータ操作処理を行わせるように記述される。言い換えれば、本システムにおいては、データＡＰＩが仲介となってアプリケーションプロバイダ３０とデータプロバイダ２０が連携し動作する。
【００２９】
図２はデータプロバイダ２０の初期ページ生成機能２０２が生成する初期ページのＨＴＭＬ（HyperText Markup Language）の一例を示した図である。ただし、説明のため左端には行番号を付記している。
【００３０】
図３は実施例１のシステムの処理手順を示すフロー図である。以下、実施例１の処理手順を図３のフローに従って説明する。なお、図３のうち、ステップ３０４以降の点線で囲われている部分は第二の実施例以降でも共通に用いる本システムにおける基本処理フローの部分である。
【００３１】
はじめに、本システムを利用する際、ユーザはＷｅｂブラウザ１０に対しデータプロバイダ２０が提供する初期ページにアクセスする操作を行う（ステップ３０１）。Ｗｅｂブラウザ２０はユーザ操作により初期ページの取得要求をデータプロバイダ２０に送信する（ステップ３０２）。データプロバイダ２０はＷｅｂサーバ２０１により初期ページの取得要求を受信すると、図２にその一例を示す初期ページを生成し、生成した初期ページを要求元のＷｅｂブラウザ１０に返信する（ステップ３０３）。
【００３２】
初期ページは、接続情報２０３に設定されている情報に従って、初期ページ生成機能２０２が生成する。図４、図５はその接続情報２０３の一具体例であり、図４はアプリケーションプロバイダ３０が提供するアプリケーションスクリプトのＵＲＬの情報（以下、アプリスクリプト情報）の一例であり、図５はデータプロバイダ２０が提供するデータＡＰＩ機能２０４とＵＲＬとの対応情報（以下、データＡＰＩ情報）の一例である。また、図６に個人設定情報２０６の一例を示す。
【００３３】
初期ページは基本的に図２の一例のように、４行目の破線で囲まれたアプリケーションプロバイダ３０が提供するアプリケーションスクリプト３２の参照記述部分と、５行目から１４行目までの破線で囲まれた、アプリケーションスクリプトに対しデータプロバイダ２０が提供するデータＡＰＩ機能２０４とＵＲＬの対応情報の設定と、ユーザの個人設定を反映させるためのスクリプト記述の二つの部分からなる。
【００３４】
一つ目のアプリケーションスクリプト３２の参照記述部分は接続情報２０３に設定されるアプリスクリプト情報を元に生成する。図４のアプリスクリプト情報の一例の場合、例えば、ユーザが利用するアプリケーションスクリプトの名前がｃａｌｅｎｄａｒ  ａｐｐ  Ａであれば、ｈｔｔｐ：／／ａｐｐｐｒｏｖｉｄｅｒＡ．ｃｏｍ／ｓｃｒｉｐｔ／ｃａｌｅｎｄａｒ．ｊｓをアプリケーションスクリプトの参照記述に用いる。
【００３５】
二つ目のアプリケーションスクリプトに対しデータプロバイダ２０が提供するデータＡＰＩ機能とＵＲＬの対応情報の設定と、ユーザの個人設定を反映させるスクリプト記述の部分は、接続情報２０３に設定されるデータＡＰＩ情報と、個人設定情報２０６の情報を元に生成する。図５のデータＡＰＩ情報の一例の場合、提供するデータＡＰＩの名前が「ＧＥＴ」のものは「ｈｔｔｐ：／／ｄａｔａｐｒｏｖｉｄｅｒ．ｃｏｍ／ｃａｌｅｎｄａｒ／ａｐｉ／ｇｅｔ／＄ｕｓｅｒ＄」を、「ＡＤＤ」のものは「ｈｔｔｐ：／／ｄａｔａｐｒｏｖｉｄｅｒ．ｃｏｍ／ｃａｌｅｎｄａｒ／ａｐｉ／ａｄｄ／＄ｕｓｅｒ＄」を、「ＥＤＩＴ」のものは「ｈｔｔｐ：／／ｄａｔａｐｒｏｖｉｄｅｒ．ｃｏｍ／ｃａｌｅｎｄａｒ／ａｐｉ／ｅｄｉｔ／＄ｕｓｅｒ＄／＄ｉｄ＄」を、アプリケーションスクリプトに対し設定するＵＲＬとして用いる。
【００３６】
なお、上記の例におけるＵＲＬのうち、「＄ｕｓｅｒ＄」や「＄ｉｄ＄」の部分はスクリプトの処理中に動的に変化する部分であることを意味しており、それぞれ操作対象のデータに対するユーザＩＤ、予定情報ＩＤを当該部分に埋め込んで利用することを意味している。例えば、データＡＰＩ「ＧＥＴ」のＵＲＬは、ユーザＩＤ「ｋｏｊｉｍａ」のデータに対して処理を行いたい場合であれば「ｈｔｔｐ：／／ｄａｔａｐｒｏｖｉｄｅｒ．ｃｏｍ／ｃａｌｅｎｄａｒ／ａｐｉ／ｇｅｔ／ｋｏｊｉｍａ」となる。また、図５中、「ＡＮＡＬＹＺＥ」は実施例１には関係しないため、ここでは説明を省略する。
【００３７】
個人設定情報２０６が図６の例のように設定されていた場合、ユーザが”ｋｏｊｉｍａ”である場合、アプリケーションスクリプトに対する個人設定情報として、カレンダの初期表示方法の設定情報として情報種別ｉｎｉｔＶｉｅｗの値はｍｏｎｔｌｙ（レコード６０１）を、最初に表示する曜日の設定情報として情報種別ｉｎｉｔＤａｙの値はｓｕｎｄａｙ（レコード６０２）を、表示に利用する言語の設定情報として情報種別ｌａｎｇの値はｊａ（レコード６０３）を用いる。
【００３８】
以上の手順によりデータプロバイダ２０の初期ページ生成機能２０２は初期ページを生成する。Ｗｅｂブラウザ１０は、このように生成された初期ページを受信すると画面上に初期ページとして受信したＨＴＭＬを表示する処理を行う（図３のステップ３０４）。受信した初期ページには図２の例のようにアプリケーションスクリプト３２への参照記述が含まれているため、当該参照記述に記載されているＵＲＬのスクリプトの取得要求をアプリケーションプロバイダ３０に送信する。アプリケーションプロバイダ３０はＷｅｂサーバ３１によりスクリプトの取得要求を受信すると、アプリケーションプロバイダ３０が保持しているスクリプトのうち取得要求にそったアプリケーションスクリプト３２を要求元のＷｅｂブラウザ１０に返信する（ステップ３０５）。
【００３９】
アプリケーションスクリプト３２を受信したＷｅｂブラウザ１０は、受信したアプリケーションスクリプト３２の実行を開始する（ステップ３０６）。次に初期ページ内に記述されるスクリプトに従い、データプロバイダ２０の提供するデータＡＰＩのＵＲＬ設定処理を行う（ステップ３０７）。当該設定処理に用いられる関数はアプリケーションプロバイダ３０からのスクリプト３２内で定義される。
【００４０】
図２の例では８行目から１０行目で定義されているデータＡＰＩとＵＲＬの関係情報と個人設定情報２０６で設定される情報を引数とし、１１行目の２００１の箇所でｅｘｅｃｕｔｅＣａｌｅｎｄａｒ関数を実行しているが、このｅｘｅｃｕｔｅＣａｌｅｎｄａｒ関数はアプリケーションプロバイダ３０が提供するスクリプト３２内で定義され、２００２の箇所で示す引数として渡されたデータＡＰＩとＵＲＬの関係情報を取り込み、データ操作処理の際に利用するよう動作する。また２００３の箇所で示す二つ目の引数の値に従い、ユーザインタフェースの動作を制御する。ここではユーザの個人設定の値として個人設定情報２０６に図６の一例のように設定されていた例となっており、アプリケーションスクリプトはカレンダの初期表示時に月間表示をし、最初に表示する曜日を日曜日にし、表示に用いる言語に日本語を用いる。
【００４１】
ステップ３０６でスクリプトの実行が開始されるが、ユーザの操作に伴いデータの操作を実行する処理はステップ３０７のデータＡＰＩのＵＲＬの設定処理の後から開始するよう処理する。
【００４２】
ステップ３０６の後、アプリケーションスクリプト３２の実行により、Ｗｅｂブラウザ１０は画面上に情報を表示したり、データを操作するためのユーザインタフェースを表示したりする。予定管理アプリケーションの場合、カレンダを表示し、表示されている日付に対する予定情報を追加したり、表示されている日付に設定されている予定情報を編集したり削除したりするためのインターフェースを表示する。
【００４３】
次に、図３の処理フローに示すように、ユーザがＷｅｂブラウザ１０に対し、表示されている日付に対する予定情報を追加する操作を行うと（ステップ３０８）、Ｗｅｂブラウザ１０は当該操作に対するイベントを発生させる。アプリケーションスクリプト３２は当該イベントの発生を契機に、ユーザが入力した情報に基づき予定情報の追加処理を行う。ユーザが入力した情報に従い、データプロバイダが提供するデータＡＰＩの形式にそったリクエスト情報を生成し、当該リクエスト情報をデータプロバイダ２０に非同期通信により送信する（ステップ３０９）。
【００４４】
リクエスト情報をＷｅｂサーバ２０１により受信したデータプロバイダ２０は、当該リクエスト情報に従いデータＡＰＩ機能２０４によりコンテンツデータ２０５に対し追加処理を行い、追加処理結果を要求元のＷｅｂブラウザ１０に返信する（ステップ３１０）。
【００４５】
追加処理結果を受信したＷｅｂブラウザ１０は追加処理結果の情報を、追加要求送信処理を行ったアプリケーションスクリプト３２の該当処理部に受け渡す。アプリケーションスクリプト３２は追加処理結果の情報に従ってその旨を画面上に表示するなどの追加処理の結果に対する処理を行う（ステップ３１１）。
【００４６】
図１０は実施例１におけるデータＡＰＩの通信形式の一例を示した表である。アプリケーションスクリプト３２はステップ３０９において図１０の通信形式に従い、データプロバイダ２０にリクエスト情報を送信する。また、ステップ３１１において、リクエスト情報の送信の結果得られる情報を解析し、結果の画面表示処理を行う。図１０の１００１では、予定情報の追加処理の際、予定の開始日を２００７年２月２１日、終了日を２００７年２月２２日、タイトルを「ｗｅｂ  ｃｏｎｆｅｒｅｎｃｅ」、場所を「ｔｏｋｙｏ」とする予定を追加したい場合に「ｓｔａｒｔｄａｔｅ＝２００７０２２１＆ｅｎｄｄａｔｅ＝２００７０２２２＆ｔｉｔｌｅ＝ｗｅｂ＋ｃｏｎｆｅｒｅｎｃｅ＆ｐｌａｃｅ＝ｔｏｋｙｏ」というリクエストパラメタを生成することを意味しており、その結果、追加処理が完了した場合「（｛”ｓｔａｔｕｓ”：”ｏｋ”｝）」をデータプロバイダ２０が返信することを意味している。また、１００２は予定情報の検索処理の際、開始日が２００７年１月１日以降で「ｗｅｂ」という文字列がタイトルや場所に含まれる、という条件で検索をする場合に「ｓｔａｒｔｄａｔｅ＝２００７０１０１＆ｋｅｙｗｏｒｄ＝ｗｅｂ」というリクエストパラメタを生成することを意味しており、その結果、条件に沿った予定情報として「（｛”ｓｃｈｅｄｕｌｅｓ”：［｛”ｓｔａｒｔｄａｔｅ”：”２００７０２２０”，”ｅｎｄｄａｔｅ”：”２００７０２２２”，”ｔｉｔｌｅ”：”ｗｅｂ  ｃｏｎｆｅｒｅｎｃｅ”，”ｐｌａｃｅ”：”ｔｏｋｙｏ”｝，｛”ｓｔａｒｔｄａｔｅ”：”２００７０２２３”，”ｅｎｄｄａｔｅ”：”２００７０２２３”，”ｔｉｔｌｅ”：”ｗｅｂ  ｍｅｅｔｉｎｇ”，”ｐｌａｃｅ”：”ｍｅｅｔｉｎｇ  ｒｏｏｍ”｝，．．．．．］｝）」をデータプロバイダ２０が返信することを意味している。
【００４７】
同様に、図３の処理フローにおいて、ユーザがＷｅｂブラウザ１０に対し、表示されている予定情報に対し修正する操作を行うと（ステップ３１２）、Ｗｅｂブラウザ１０は当該操作に対するイベントを発生させる。アプリケーションスクリプト３２は当該イベントの発生を契機に、ユーザが入力した情報に基づき予定情報の修正処理を行う。ユーザが入力した情報に従い、データプロバイダが提供するデータＡＰＩの形式にそったリクエスト情報を生成し、当該リクエスト情報をデータプロバイダ２０に送信する（ステップ３１３）。
【００４８】
リクエスト情報をＷｅｂサーバ２０１により受信したデータプロバイダ２０は、当該リクエスト情報に従いデータＡＰＩ機能２０４によりコンテンツデータ２０５に対し修正処理を行い、修正処理結果を要求元のＷｅｂブラウザ１０に返信する（ステップ３１４）。
【００４９】
修正処理結果を受信したＷｅｂブラウザ１０は修正処理結果の情報を、修正要求送信処理を行ったアプリケーションスクリプト３２の該当処理部に受け渡す。アプリケーションスクリプト３２は修正処理結果の情報に従ってその旨を画面上に表示するなどの修正処理の結果に対する処理を行う（ステップ３１５）。
【００５０】
その他の予定情報の削除や参照のユーザ操作に関しても同様に、Ｗｅｂブラウザ１０がデータプロバイダ２０に対し対応するリクエスト情報を送信し、当該リクエスト情報を受信したデータプロバイダ２０がデータ操作処理を実行する。
【００５１】
なお、ステップ３０８〜３１１とステップ３１２〜ステップ３１５は説明上その順で述べたが、ユーザの操作を契機に開始されるステップであり、順序に関係なく処理可能である。
【００５２】
以上説明した実施例１のシステムによれば、そのユーザは、Ｗｅｂアプリケーションを利用する際、そこで扱うデータをＷｅｂアプリケーションのうちユーザインタフェース機能を提供するアプリケーションプロバイダ３０に直接渡すことなく利用することができる。また、Ｗｅｂアプリケーションの開発者はデータＡＰＩの形式を仲介させることにより、Ｗｅｂアプリケーションのユーザインタフェース機能とデータ操作処理機能とを分離し、それぞれを別々のドメインのサーバ上に配備させることができる。
【００５３】
これにより、企業内システムの開発者は、インターネット上で公開されているアプリケーション機能に対応したデータプロバイダ２０を自社内に設置することで、データを自社内にとどめたままインターネット上で公開されているアプリケーション機能を利用することができる。逆に、インターネット上のアプリケーション開発者は、企業内に設置されているデータプロバイダに対応するデータＡＰＩに対応したアプリケーション機能を開発することで、企業内のデータを直接扱うことなく、インターネット上にアプリケーションを配備しサービスすることができる。なお、個人設定情報２０６についてはアプリケーションプロバイダ２０に配備することも可能である。
【００５４】
また、本実施例によるシステム構成にあっては、データプロバイダ２０を、Ｗｅｂブラウザ１０を利用する企業とは別のネットワークに設置して稼動させることも可能である。したがって、より安全にデータを保護することが可能なデータセンタ等にデータプロバイダ２０を配備して利用する、という形態をとることも可能である。そのため、図１８に示すように、顧客企業のデータを安全に保護しながら、外部のアプリケーションを活用可能とするといったデータ管理ビジネスにも応用できる。
【００５５】
図１８において、３０Ａ、３０Ｂ、３０Ｃ、３０Ｄはいずれも図１のアプリケーションプロバイダ３０と同様Ｗｅｂサーバ３１とアプリケーションスクリプト３２を有しており、それぞれ別の企業が提供している様子を表している。アプリケーションプロバイダ３０Ｄとデータプロバイダ２０はデータ管理企業が提供しており、そのデータ管理企業はアプリケーションの提供サービスとデータ管理のサービスを同時に行うビジネスを行っていることを示している。データプロバイダ２０は図１のデータプロバイダと同様の構成を有する。これにより、Ｗｅｂブラウザ１０のユーザである企業は、データ管理企業が提供するアプリケーションの利用を図ることができると同時に、データの安全管理も保証される。
【実施例２】
【００５６】
上述した実施例１でＷｅｂアプリケーションの機能のうち、ユーザインタフェースの機能とデータ操作の処理機能とを分離する仕組みを説明したが、データプロバイダ２０から提供される初期ページによりアクセスされるアプリケーションスクリプトが一種類に対応したものであった。データプロバイダが提供するデータ操作機能に複数のアプリケーションプロバイダが対応した機能を提供する場合、データプロバイダが提供するデータ操作機能を扱うユーザインタフェース機能をユーザが選択して利用可能である。実施例１で説明した初期ページ生成機能２０２にアプリケーションプロバイダの選択ページ生成機能を具備させることにより、この機能を提供することができる。
【００５７】
以下、実施例１で説明したシステムに対し、更にアプリケーションプロバイダの選択処理を具備した第二の実施例のシステムの処理手順を図７のフロー図を用いて説明する。
【００５８】
はじめに、ユーザはＷｅｂブラウザ１０に対しデータプロバイダ２０が提供する、アプリケーションスクリプト選択ページ（以下、アプリ選択ページ）にアクセスする操作を行う（ステップ７０１）。なお、アプリケーションスクリプト選択ページは、データプロバイダ２０が提供するデータ操作機能に対応したアプリケーションスクリプトのうち、どのアプリケーションスクリプトを利用するかを選択するユーザインタフェースを備えた構成になっているものである。図１２はアプリケーションスクリプト選択ページの一例であり、ボタンを押すことでそのボタンに記載されている名前のアプリケーションスクリプトを選択できる構成をとっている。
【００５９】
Ｗｅｂブラウザ２０はユーザ操作により、アプリ選択ページの取得要求をデータプロバイダ２０に送信する（ステップ７０２）。データプロバイダ２０はＷｅｂサーバ２０１によりアプリ選択ページの取得要求を受信するとアプリ選択ページを生成し、生成したアプリ選択ページを要求元のＷｅｂブラウザ１０に返信する（ステップ７０３）。
【００６０】
アプリ選択ページは接続情報２０３で保持するデータプロバイダ２０が提供するデータＡＰＩに対応したアプリケーションスクリプトの情報（以下、アプリスクリプト対応情報）を元に初期ページ生成機能２０２が生成する。図４はアプリスクリプト情報の一例である。データプロバイダ２０が提供するデータＡＰＩが「ｃａｌｅｎｄａｒ  ＡＰＩ」という名前である場合、「ｃａｌｅｎｄａｒ  ａｐｐ  Ａ」という名前のアプリケーションスクリプトと「Ｂｃａｌｅｎｄａｒ」というアプリケーションスクリプトがあることを意味している。そこで初期ページ生成機能２０２は選択可能なアプリケーションスクリプトとして「ｃａｌｅｎｄａｒ  ａｐｐ  Ａ」と「Ｂｃａｌｅｎｄａｒ」があり、いずれかをユーザに選択させるアプリ選択ページを生成する。
【００６１】
アプリ選択ページを受信したＷｅｂブラウザ１０はアプリ選択ページを画面上に表示する（ステップ７０４）。
【００６２】
ユーザが画面上に表示されたアプリケーションスクリプトの情報を閲覧し、いずれかのアプリケーションスクリプトを選択する操作をＷｅｂブラウザ１０に対して行う（７０５）。ユーザによるアプリケーションスクリプトの選択操作が行われると、Ｗｅｂブラウザ１０は選択されたアプリケーションスクリプトの情報とともに、選択されたアプリケーションスクリプトへの参照記述を含む初期ページの取得要求をデータプロバイダ２０に送信する（ステップ７０６）。データプロバイダ２０はＷｅｂサーバ２０１により選択されたアプリケーションスクリプトに対する初期ページ取得要求を受信すると、初期ページ生成処理機能２０２により選択されたアプリケーションスクリプトに対する初期ページを生成し、生成した初期ページを要求元のＷｅｂブラウザ１０に返信する（ステップ７０６）。このときの初期ページの生成処理は実施例１で説明した図３のステップ３０３と同様である。
【００６３】
初期ページを受信したＷｅｂブラウザ１０は初期ページの表示処理を行う（ステップ３０４）。以降の処理フローは実施例１で説明した図３のステップ３０４以降の基本フローと同様である。
【００６４】
本実施例によれば、同一のデータプロバイダ２０が提供するデータＡＰＩに対応した複数のアプリケーションスクリプトを選択して実行できるシステムをユーザに提供することができる。またこのときどのアプリケーションスクリプトを利用しても、扱われるデータはデータプロバイダ２０にあるため、複数のアプリケーションスクリプトで共通のデータを操作することができる。
【実施例３】
【００６５】
実施例２で複数のアプリケーションスクリプト３２を選択して利用する機能について説明したが、複数のデータプロバイダが提供する情報を扱うことのできるシステムを構成することもできる。予定管理システムの例であれば、仕事に関する予定情報を自社内のデータプロバイダに管理し、祝日の情報や天気予報の情報を外部のデータプロバイダから取得して仕事に関する予定情報と並べて表示する、といったことができる。
【００６６】
実施例１では接続情報２０３の一例として図５を示し、この情報に従ってデータプロバイダが提供するデータＡＰＩの情報をアプリケーションプロバイダ３０が提供するアプリケーションスクリプト３２に設定する処理を含むよう初期ページを生成することで、アプリケーションスクリプト３２がデータ操作処理を行う際にデータＡＰＩの情報に従って通信処理を行えるようにする方法を述べた。これと同様に、他に取得したい情報を持つデータプロバイダの情報を接続情報２０３に保持させ、この情報をアプリケーションスクリプト３２に設定する処理を含むよう初期ページを生成することで、アプリケーションスクリプト３２が他のデータプロバイダが提供する情報を取得する処理を行う際にこの情報に従って通信処理を行うようにすることができる。
【００６７】
この場合を第三の実施例として説明する。このとき、アプリケーションスクリプト３２は実施例１で説明した予定情報管理アプリケーションのユーザインタフェース機能の他に、他のデータプロバイダが提供する情報を取得し、その情報をその情報の種類に応じた形式で予定情報と並べて表示する処理が行う機能を持っており、他のデータプロバイダとの通信に必要な情報を設定する手段を備えているものとする。
【００６８】
図１３は接続情報２０３に設定する、他に取得したい情報を持つデータプロバイダの情報の一例である。実施例１で説明した処理フローの中で、図３のステップ３０３において初期ページを生成する際に、図１３のような情報に従い、他に取得したい情報を持つデータプロバイダの情報を設定するスクリプト記述（以下、追加データプロバイダ設定）を追加する。図１３の１３０１は情報の種類が”ｈｏｌｉｄａｙ”でＵＲＬが”ｈｔｔｐ：／／ｗｗｗ．ｈｏｌｉｄａｙｃａｌｅｎｄａｒ．ｃｏｍ／ａｐｉ／ｊｓｏｎｐ”であるデータプロバイダの情報が取得候補であることを示しており、１３０２は情報の種類が”ｗｅａｔｈｅｒ”でＵＲＬが”ｈｔｔｐ：／／ｗｗｗ．ｗｅａｔｈｅｒｉｎｆｏｒｍａｔｉｏｎ．ｃｏｍ／ｊｓｏｎｐａｐｉ”であるデータプロバイダことを示している。
【００６９】
アプリケーションスクリプト３２が持つ他のデータプロバイダとの通信に必要な情報を設定する関数の名前が「ｓｅｔＯｐｔｉｏｎｎａｌＩｎｆｏｒｍａｔｉｏｎＵＲＬ」である場合、「ｓｅｔＯｐｔｉｏｎｎａｌＩｎｆｏｒｍａｔｉｏｎＵＲＬ（｛”ｔｙｐｅ”：”ｈｏｌｉｄａｙ”，”ｕｒｌ”：”ｈｔｔｐ：／／ｗｗｗ．ｈｏｌｉｄａｙｃａｌｅｎｄａｒ．ｃｏｍ／ａｐｉ／ｊｓｏｎｐ”｝，｛”ｔｙｐｅ”：”ｗｅａｔｈｅｒ”，”ｕｒｌ”：”ｈｔｔｐ：／／ｗｗｗ．ｗｅａｔｈｅｒｉｎｆｏｒｍａｔｉｏｎ．ｃｏｍ／ｊｓｏｎｐａｐｉ”｝）；」という記述を追加生成することとなる。図２の初期ページの一例にこの処理が追加される場合は当該記述が１１行目と１２行目の間に挿入されることとなる。
【００７０】
本実施例３によれば、複数のデータプロバイダが提供する情報をアプリケーションスクリプト３２が利用することができ、多様な情報を表示するアプリケーションを構築することができる。なお、ここでは他のデータプロバイダに対してはデータ取得の操作のみを例としてあげたが、データ取得の操作に限定するものではなく、データの追加や編集、削除などの更新処理も可能である。
【実施例４】
【００７１】
上述した各実施例ではユーザは本システムを利用するときに、はじめにＷｅｂブラウザ１０を操作してデータプロバイダ２０にアクセスするところから始めていたが、利用したいアプリケーションスクリプトを探しだしてから利用することも可能である。この場合を第四の実施例として説明する。
【００７２】
アプリケーションスクリプトへの接続情報を設定する機能をデータプロバイダ２０の初期ページ生成機能２０２に配備し、この機能を利用して接続情報２０３を設定するページ（以下アプリ利用開始ページ）をアプリケーションプロバイダが提供することで、アプリケーションスクリプトを探索し、探索した結果利用したいアプリケーションスクリプトが発見できたときにそれをデータプロバイダに設定し利用する、という利用の流れをユーザに提供することができる。
【００７３】
以下、実施例１で説明したシステムに対し、アプリケーションスクリプトへの接続情報を設定する機能を具備したシステムの処理手順を図９のフロー図を用いて説明する。なお、図９は上記のうち、ユーザが利用したいアプリケーションスクリプトを発見し、アプリ利用開始ページを表示させる操作を開始するところから開始するフロー図である。
【００７４】
はじめに、ユーザはＷｅｂブラウザ１０に対しアプリケーションプロバイダ２０が提供するアプリ利用開始ページにアクセスする操作を行う（ステップ９０１）。
【００７５】
Ｗｅｂブラウザ２０はユーザ操作により、アプリ利用開始ページの取得要求をアプリケーションプロバイダ３０に送信する（ステップ９０２）。アプリケーションプロバイダ３０はＷｅｂサーバ３１によりアプリ利用開始ページの取得要求を受信するとアプリ利用開始ページを要求元のＷｅｂブラウザ１０に返信する（ステップ９０３）。
【００７６】
アプリ利用開始ページはユーザに、データプロバイダ２０のアプリケーションスクリプトの接続情報を設定する機能にアクセスするためのＵＲＬ（以下、接続情報設定用ＵＲＬ）を入力させるユーザインタフェースを備え、当該アプリケーションスクリプトの接続情報を入力されたＵＲＬに対し送信し、アプリケーションスクリプトをデータプロバイダに設定させ、アプリケーションスクリプトの利用を開始するための初期画面を生成させる機能を含んだページである。
【００７７】
アプリ利用開始ページを受信したＷｅｂブラウザ１０はアプリ利用開始ページを画面上に表示する（ステップ９０４）。
【００７８】
ユーザが接続情報設定用ＵＲＬを入力すると（ステップ９０５）、Ｗｅｂブラウザ１０は入力された接続情報設定用ＵＲＬに対し、アプリケーションスクリプトの情報とともにアプリケーションスクリプトの接続設定および当該アプリケーションスクリプトに対する初期ページ生成要求をデータプロバイダ２０（ユーザが入力する接続情報設定用ＵＲＬに対応するデータプロバイダ２０）に送信する（ステップ９０６）。データプロバイダ２０はＷｅｂサーバ２０１により接続設定および初期ページ取得要求を受信すると、初期ページ生成処理機能２０２により接続情報２０３に対しアプリケーションスクリプトの情報を追加設定し、追加設定したアプリケーションスクリプトに対する初期ページを生成し、生成した初期ページを要求元のＷｅｂブラウザ１０に返信する（ステップ９０７）。このときの初期ページの生成処理は実施例１で説明した図３のステップ３０３と同様である。
【００７９】
初期ページを受信したＷｅｂブラウザ１０は初期ページの表示処理を行う（ステップ３０４）。以降の処理フローは実施例１で説明した図３のステップ３０４以降の基本フローと同様である。
【００８０】
本実施の形態によれば、ユーザがＷｅｂブラウザ１０を操作してアプリケーションスクリプトをネットワーク内で探索し、探索した結果利用したいアプリケーションスクリプトが発見できたときにそれをデータプロバイダに設定し利用する、という利用の流れをユーザに提供することができる。
【実施例５】
【００８１】
実施例１から実施例４ではアプリケーションの機能のうちデータ操作に関する処理はデータプロバイダに、ユーザインタフェースに関する処理はアプリケーションプロバイダに配備するものとして説明したが、データ操作に関する処理のうち、データＡＰＩ機能以外の、検索処理の高速化のためのインデックス作成処理や、コンテンツ内容に即した広告配信のためのコンテンツ内容の特徴抽出処理などのデータ分析処理機能もデータプロバイダ２０に配備する必要がある。
【００８２】
以下、実施例１で示した予定情報管理アプリケーションのシステム例に対し、コンテンツ内容に即した広告を画面上に表示する処理も行うシステムを第五の実施例として説明する。
【００８３】
図１４は実施例５におけるシステム構成図である。図１と異なる構成として、データプロバイダ２０に対しデータ分析機能２０７が、アプリケーションプロバイダ３０に対し広告配信機能３３ならびに広告情報３４が追加されている。なお、データＡＰＩ機能２０４はデータ分析機能２０７により抽出されたコンテンツデータに対する特徴となる情報を提供する機能を新たに具備する。この新たに具備する機能は図５のデータＡＰＩ情報の最後の４行目で記録されているＡＰＩメソッド、ＡＮＡＬＹＺＥの機能として提供されるものとし、そのＵＲＬはｈｔｔｐ：／／ｄａｔａｐｒｏｖｉｄｅｒ．ｃｏｍ／ｃａｌｅｎｄａｒ／ａｐｉ／ａｎａｌｙｚｅ／＄ｕｓｅｒ＄であるとする。アプリケーションスクリプト３２はこのＵＲＬに対しアクセスすることで、データ分析機能２０７により抽出されたコンテンツデータに対する特徴となる情報を取得できる。
【００８４】
またアプリケーションスクリプト３２はデータＡＰＩ機能２０４からコンテンツデータに対する特徴となる情報を取得し、取得した特徴情報を広告配信機能３３に送信し、関連する広告情報を取得し、画面上に表示する処理機能を新たに具備する。
【００８５】
このデータ分析機能２０７は上記のようなデータＡＰＩ機能以外の、検索処理の高速化のためのインデックス作成処理や、コンテンツ内容に即した広告配信のためのコンテンツ内容の特徴抽出処理などのデータ分析処理を行う機能である。ここではデータ分析機能２０７はあらかじめコンテンツデータ２０５が保持する内容を分析し、各コンテンツ内容の特徴情報をコンテンツデータの一部として記録しておくものとする。
【００８６】
一方、広告配信機能３３はコンテンツ内容に即した広告を配信する機能であり、コンテンツ内容の特徴となるキーワードをＷｅｂサーバ３１で受信すると、そのキーワードに適した、関連する広告を広告情報３４から抽出し要求元に広告情報を返信する機能である。
【００８７】
図１５はアプリケーションプロバイダ３０の広告配信機能３３により送信された広告情報をＷｅｂブラウザ１０の画面上に表示した一具体例であり、１５０１がその広告の一例である。
【００８８】
図１７は広告情報３４の一例であり、特徴情報と配信すべき広告画像のＵＲＬの対応関係を示している。図１７の１７０１では特徴情報がｗｅｂであった場合はｈｔｔｐ：／／ｗｗｗ．ａｄｄ．ｃｏｍ／ｉｍａｇｅ／００１．ｐｎｇを、１７０２では特徴情報がｎｅｔｗｏｒｋであった場合はｈｔｔｐ：／／ｗｗｗ．ａｄｄ．ｃｏｍ／ｉｍａｇｅ／００２．ｐｎｇを、１７０３では特徴情報がａｐｐｌｉｃａｔｉｏｎであった場合はｈｔｔｐ：／／ｗｗｗ．ａｄｄ．ｃｏｍ／ｉｍａｇｅ／００３．ｐｎｇを、特徴情報に関連する、配信すべき広告画像として設定していることを示している。広告配信を行う予定情報管理アプリケーションの処理フローは、広告配信に関する部分以外、実施例１で説明した図３の予定情報管理アプリケーションの処理フローと大きな差はない。
【００８９】
図１６は、実施例５のシステムにおいて、図３のステップ３０７に続いて行われる広告配信のための処理フローである。以下、図１６を用いて広告配信のための処理フローを説明する。
【００９０】
アプリケーションスクリプト３２の実行が開始され（ステップ３０６）、データＡＰＩ情報の設定処理が完了（ステップ３０７）した後、表示中のコンテンツの特徴情報を取得するため、Ｗｅｂブラウザ１０はユーザの指示に基づき、データプロバイダ２０に対しコンテンツの特徴情報の取得要求を送信する（ステップ１６０１）。データＡＰＩ機能２０４はＷｅｂサーバ２０１により特徴情報の取得要求を受信すると、取得要求により指定されたコンテンツに対する特徴情報をコンテンツデータ２０５から取得し、取得した特徴情報を要求元のＷｅｂブラウザ１０に返信する（ステップ１６０２）。特徴情報を受信したＷｅｂブラウザ１０はその情報を、特徴情報の取得要求送信処理を行ったアプリケーションスクリプト３２の該当処理部に受け渡す。アプリケーションスクリプト３２は特徴情報に適した広告情報の取得要求をアプリケーションプロバイダ３０に送信する（ステップ１６０３）。
【００９１】
アプリケーションプロバイダ３０の広告配信機能３３はＷｅｂサーバ３１により広告情報の取得要求を受信すると受信した特徴情報に即した情報を広告情報３４から取得し、要求元のＷｅｂブラウザ１０に返信する（ステップ１６０４）。広告情報を受信したＷｅｂブラウザ１０はその情報を、広告情報の取得要求送信処理を行ったアプリケーションスクリプト３２の該当処理部に受け渡す。アプリケーションスクリプト３２は受信した広告情報に従い画面上に広告情報を表示する（ステップ１６０５）。
【００９２】
例えば、ステップ１６０２でコンテンツの特徴情報として”ｗｅｂ”をデータプロバイダ２０が返信した場合、ステップ１６０３で”ｗｅｂ”に適した広告情報の取得要求をアプリケーションスクリプト３２はアプリケーションプロバイダ３０に送信する。そしてステップ１６０４で”ｗｅｂ”に適した広告情報として” ｈｔｔｐ：／／ｗｗｗ．ａｄｄ．ｃｏｍ／ｉｍａｇｅ／００１．ｐｎｇ”（図１７の１７０１参照）をアプリケーションスクリプト３２に返信し、アプリケーションスクリプト３２は” ｈｔｔｐ：／／ｗｗｗ．ａｄｄ．ｃｏｍ／ｉｍａｇｅ／００１．ｐｎｇ”で示されるＵＲＬの画像をＷｅｂブラウザ１０上に表示する。
【００９３】
本実施例によればデータプロバイダ２０が保持するデータと密接に関わる、データＡＰＩ機能として外部に公開しないデータ分析処理のような機能が必要となるシステムを提供可能となり、コンテンツに即した広告配信の機能や高速な検索処理の機能を提供することができる。
【００９４】
これまでデスクトップアプリケーションとして提供されてきたアプリケーションがＷｅｂアプリケーションとしてインターネット上で公開されはじめている。しかし情報漏洩の観点から企業ユーザがこうしたＷｅｂアプリケーションを使うことは少なかった。
【００９５】
それに対し、本発明を用いることで、Ｗｅｂアプリケーションの機能をデータ操作に関する機能とユーザインタフェースに関する機能の二つにそれぞれ別のドメイン（別のサーバ）上のサービスとして分割することができるため、データ操作に関する機能を提供するサーバを自社内（もしくは信頼できる社外の組織）に配備することにより、ユーザインタフェースに関する機能を提供するサーバ（を提供する組織）に直接データを渡さず、自社内などに情報を置いたままアプリケーションの機能を利用することができる。
【００９６】
以上詳述した本発明により、企業内ユーザによるインターネット上のＷｅｂアプリケーション利用が拡大すれば、本発明を用いたユーザインタフェースに関する機能のみを提供するサービスや、信頼性の高いデータ操作機能サーバを提供もしくは構築するサービスなどの事業が広まると考えられる。
【図面の簡単な説明】
【００９７】
【図１】実施例１のシステムの機能構成およびネットワーク構成を示す図。
【図２】実施例１の初期ページの一例を示す図。
【図３】実施例１によるシステムの処理フローを示す図。
【図４】実施例１における接続情報が保持するアプリケーションスクリプト情報を示す図。
【図５】実施例１における接続情報が保持するデータＡＰＩ情報の一例を示す図。
【図６】実施例１における個人設定情報２０６の一例を示す図。
【図７】実施例２における本発明によるシステムの処理フローを示す図。
【図８】実施例３における接続情報が保持するデータＡＰＩ情報の一例を示す図。
【図９】実施例４におけるシステムの処理フローを示す図。
【図１０】実施例１におけるデータＡＰＩの通信形式を示す図。
【図１１】実施例１における予定管理アプリケーションが提供する画面の一例を示す図。
【図１２】実施例２におけるアプリケーションスクリプト選択ページの一例を示す図。
【図１３】実施例１における追加データプロバイダの情報の一例を示す図。
【図１４】実施例５におけるシステムの機能構成およびネットワーク構成を示す図。
【図１５】実施例５における予定管理アプリケーションが提供する画面の一例を示す図。
【図１６】実施例５におけるシステムの処理フローを示す図。
【図１７】実施例５における広告情報３４の一例を示す図。
【図１８】実施例１における応用例のネットワーク構成を示す図。
【符号の説明】
【００９８】
１０…Ｗｅｂブラウザ、２０…データプロバイダ、３０、３０Ａ、３０Ｂ、３０Ｃ、３０Ｄ…アプリケーションプロバイダ、３１…Ｗｅｂサーバ、３２…アプリケーションスクリプト、３３…広告配信機能、３４…広告情報、２０１…Ｗｅｂサーバ、２０２…初期ページ生成機能、２０３…接続情報、２０４…データＡＰＩ機能、２０５…コンテンツデータ、２０６…個人設定情報、２０７…データ分析機能、６０１〜６０３…個人設定情報のレコード、１７０１〜１７０３…特徴情報と配信すべき広告画像のＵＲＬの対応関係。
【図１】
2009015816.tif 000003
【図２】
2009015816.tif 000004
【図３】
2009015816.tif 000005
【図４】
2009015816.tif 000006
【図５】
2009015816.tif 000007
【図６】
2009015816.tif 000008
【図７】
2009015816.tif 000009
【図８】
2009015816.tif 000010
【図９】
2009015816.tif 000011
【図１０】
2009015816.tif 000012
【図１１】
2009015816.tif 000013
【図１２】
2009015816.tif 000014
【図１３】
2009015816.tif 000015
【図１４】
2009015816.tif 000016
【図１５】
2009015816.tif 000017
【図１６】
2009015816.tif 000018
【図１７】
2009015816.tif 000019
【図１８】
2009015816.tif 000020