(57)【要約】  アプリケーションで使用するユーザの個人データを容易に管理することができるようにする。  データ処理手段（１ａ）は、第１のアクセス先情報（４）を生成する。位置情報取得手段（１ｂ）は、ユーザ指定のデータ格納装置（３）の識別情報および該データ格納装置（３）内のユーザ指定のディレクトリの位置を示す第１の位置情報（５）を取得する。位置情報生成手段（１ｃ）は、ユーザ指定のディレクトリ配下の、データ処理手段（１ａ）に一意に割り当てられたディレクトリの位置を示す第２の位置情報（６）を生成する。アクセス先情報生成手段（１ｅ）は、第２の位置情報（６）で示される位置を基準位置とした場合の第２のアクセス先情報（７）を生成する。そしてアクセス手段（１ｆ）は、データ格納装置（３）内のアクセス対象のデータを含むファイルにアクセスする。
2012077223.tif 000002
【特許請求の範囲】
【請求項１】
ユーザからの要求に応じてデータ処理を実行し、該ユーザの個人データにアクセスする場合、基準位置から該個人データを含むファイルまでディレクトリ構造を辿ったときの経路および該ファイルのファイル名を示す第１のアクセス先情報を生成するデータ処理手段と、
ユーザ指定のデータ格納装置の識別情報および該データ格納装置内のユーザ指定のディレクトリの位置を示す第１の位置情報を取得する位置情報取得手段と、
前記第１の位置情報に基づいて、前記ユーザ指定のディレクトリ配下の、前記データ処理手段に一意に割り当てられたディレクトリの位置を示す第２の位置情報を生成する位置情報生成手段と、
前記第１のアクセス先情報と前記第２の位置情報とに基づいて、前記第２の位置情報で示される位置を基準位置とした場合の前記アクセス対象のデータを含むファイルの格納位置および該ファイルのファイル名を示す第２のアクセス先情報を生成するアクセス先情報生成手段と、
前記第２のアクセス先情報に基づいて、前記データ格納装置内の前記アクセス対象のデータを含むファイルにアクセスするアクセス手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記位置情報生成手段は、前記情報処理装置で実行可能な複数のデータ処理手段それぞれに対して一意に割り当てられた、前記ユーザ指定のディレクトリ配下のディレクトリの位置が設定されたアプリケーション毎ＵＲＬリストを取得し、該位置情報リストから、前記ユーザからの要求に応じてデータ処理を実行しているデータ処理手段に一意に割り当てられたディレクトリの位置を抽出することを特徴とする請求の範囲第１項記載の情報処理装置。
【請求項３】
前記位置情報生成手段は、前記アプリケーション毎ＵＲＬリストを、前記データ格納装置から取得することを特徴とする請求の範囲第２項記載の情報処理装置。
【請求項４】
前記位置情報生成手段は、前記データ格納装置に対して、前記データ処理手段の識別子を付加した位置情報取得要求を送信し、前記データ格納装置から、前記データ処理手段に一意に割り当てられたディレクトリの位置を取得することを特徴とする請求の範囲第１項記載の情報処理装置。
【請求項５】
前記位置情報生成手段は、予め設定されたルールに従って、前記データ処理手段に一意に割り当てられたディレクトリの位置を示す第２の位置情報を取得することを特徴とする請求の範囲第１項記載の情報処理装置。
【請求項６】
前記位置情報取得手段は、前記データ処理手段が実行する処理の内容が記述されたプログラムを格納する装置に、前記ユーザを特定する情報を付加して該プログラムの取得要求を送信し、該プログラムと共に該装置から応答された前記第１の位置情報を取得することを特徴とする請求の範囲第１項乃至第５項のいずれかに記載の情報処理装置。
【請求項７】
前記位置情報取得手段は、前記ユーザの認証手段を有する装置から、前記ユーザの認証時に前記第１の位置情報を取得することを特徴とする請求の範囲第１項乃至第５項のいずれかに記載の情報処理装置。
【請求項８】
前記位置情報取得手段は、前記ユーザにより入力された前記第１の位置情報を取得することを特徴とする請求の範囲第１項乃至第５項のいずれかに記載の情報処理装置。
【請求項９】
前記位置情報取得手段は、前記ユーザにより入力された前記第１の位置情報を記憶手段に格納し、該記憶手段から前記第１の位置情報を取得することを特徴とする請求の範囲第８項記載の情報処理装置。
【請求項１０】
前記位置情報取得手段は、ネットワークを介して接続された端末装置から、前記ユーザから操作入力された前記第１の位置情報を取得することを特徴とする請求の範囲第８項または第９項のいずれかに記載の情報処理装置。
【請求項１１】
前記データ格納装置は、ネットワークを介して前記情報処理装置に接続されていることを特徴とする請求の範囲第１項乃至第１０項のいずれかに記載の情報処理装置。
【請求項１２】
コンピュータに、
ユーザ指定のデータ格納装置の識別情報および該データ格納装置内のユーザ指定のディレクトリの位置を示す第１の位置情報を取得し、
前記第１の位置情報に基づいて、前記ユーザ指定のディレクトリ配下の、所定のデータ処理に一意に割り当てられたディレクトリの位置を示す第２の位置情報を生成し、
ユーザからの要求に応じて前記データ処理を実行し、該ユーザの個人データにアクセスする場合、基準位置から該個人データを含むファイルまでディレクトリ構造を辿ったときの経路および該ファイルのファイル名を示す第１のアクセス先情報を生成し、
前記第１のアクセス先情報と前記第２の位置情報とに基づいて、前記第２の位置情報で示される位置を基準位置とした場合の前記アクセス対象のデータを含むファイルの格納位置および該ファイルのファイル名を示す第２のアクセス先情報を生成し、
前記第２のアクセス先情報に基づいて、前記データ格納装置内の前記アクセス対象のデータを含むファイルにアクセスする、
処理を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザの個人データを利用したデータ処理を行う情報処理装置およびプログラムに関する。
【背景技術】
【０００２】
クラウドコンピューティング（cloud computing）と呼ばれるように、ネットワークに接続されたサーバで提供されるコンピューティングリソースを、ユーザが、端末装置を用いてネットワーク経由で適宜利用するサービス形態がある。提供されるコンピューティングリソースとしては、例えばアプリケーションプログラムをコンピュータが実行することで実現されるデータ処理機能（以下アプリケーションと呼ぶ）がある。インターネットでは、様々なアプリケーションが、多数のサーバで提供されている。ユーザは、端末装置を用いて目的に応じたアプリケーションを提供しているサーバにアクセスし、アプリケーションを用いたサービスの提供を受けることができる。【０００３】
ユーザがサーバで提供されるサービスを利用する場合、アプリケーションの実行に使用されるユーザの個人データを、サービスを提供するサーバ上に保持させることができる。ユーザの個人データをサーバに管理させることで、ユーザは、どこからでも自己のデータを用いたサービスの提供を受けることができるという利点がある。なお個人データには、例えばユーザの操作入力によって編集された文書、ユーザ個人の属性情報（名前や住所など）、ユーザがアプリケーションを使用する際の環境情報（メールサーバ名、メールアドレス、パスワードなど）がある。【０００４】
ネットワークに接続されたサーバでユーザの個人データを管理するようになったことで、サーバ上でユーザの個人データを管理するために有用な様々な技術が考えられている。例えばクライアント端末から指定されたデータファイルが、当該クライアント端末に応じた暗号鍵を用いて暗号化された状態で当該クライアント端末に送信されるシステムがある。このシステムでは、正当な送信先であることが認証されたクライアント端末のみが、復号鍵によって暗号化データファイルを復号化することができる。また複数の異なるデータベースを統一的に使用できるようにしたアプリケーションシステムも考えられている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−９９４９１号公報
【特許文献２】特開２００６−３０２１５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、ユーザの個人データをサーバに管理させると、複数のサーバそれぞれで提供される複数のアプリケーションをユーザが利用した場合に、ユーザの個人データが複数のサーバに分散してしまう。その結果、ユーザによる自己のデータの管理負担が増大していた。【０００７】
１つの側面では、本発明は、アプリケーションで使用するユーザの個人データを容易に管理することができる情報処理装置およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
１つの案では、データ処理手段、位置情報取得手段、位置情報生成手段、アクセス先情報生成手段、およびアクセス手段を有する情報処理装置が提供される。データ処理手段は、ユーザからの要求に応じてデータ処理を実行し、該ユーザの個人データにアクセスする場合、基準位置から該個人データを含むファイルまでディレクトリ構造を辿ったときの経路および該ファイルのファイル名を示す第１のアクセス先情報を生成する。位置情報取得手段は、ユーザ指定のデータ格納装置の識別情報および該データ格納装置内のユーザ指定のディレクトリの位置を示す第１の位置情報を取得する。位置情報生成手段は、第１の位置情報に基づいて、ユーザ指定のディレクトリ配下の、データ処理手段に一意に割り当てられたディレクトリの位置を示す第２の位置情報を生成する。アクセス先情報生成手段は、第１のアクセス先情報と第２の位置情報とに基づいて、第２の位置情報で示される位置を基準位置とした場合のアクセス対象のデータを含むファイルの格納位置および該ファイルのファイル名を示す第２のアクセス先情報を生成する。アクセス手段は、第２のアクセス先情報に基づいて、データ格納装置内のアクセス対象のデータを含むファイルにアクセスする。【０００９】
他の１つの案では、コンピュータに以下の処理を実行させるプログラムが提供される。該プログラムに基づいてコンピュータは、ユーザ指定のデータ格納装置の識別情報および該データ格納装置内のユーザ指定のディレクトリの位置を示す第１の位置情報を取得する。次にコンピュータは、第１の位置情報に基づいて、ユーザ指定のディレクトリ配下の、所定のデータ処理に一意に割り当てられたディレクトリの位置を示す第２の位置情報を生成する。次にコンピュータは、ユーザからの要求に応じてデータ処理を実行し、該ユーザの個人データにアクセスする場合、基準位置から該個人データを含むファイルまでディレクトリ構造を辿ったときの経路および該ファイルのファイル名を示す第１のアクセス先情報を生成する。次にコンピュータは、第１のアクセス先情報と第２の位置情報とに基づいて、第２の位置情報で示される位置を基準位置とした場合のアクセス対象のデータを含むファイルの格納位置および該ファイルのファイル名を示す第２のアクセス先情報を生成する。そしてコンピュータは、第２のアクセス先情報に基づいて、データ格納装置内のアクセス対象のデータを含むファイルにアクセスする。
【発明の効果】
【００１０】
データ処理で使用するユーザの個人データを、ユーザが指定したデータ格納装置で容易に管理することができる。
本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。
【図面の簡単な説明】
【００１１】
【図１】第１の実施の形態に係る情報処理装置の機能構成例を示す図である。
【図２】第１の実施の形態に係る情報処理装置の処理手順を示すフローチャートである。
【図３】第２の実施の形態のシステム構成例を示す図である。
【図４】第２の実施の形態に用いる端末装置のハードウェアの一構成例を示す図である。
【図５】第２の実施の形態の各装置の機能を示すブロック図である。
【図６】ルートＵＲＬ管理テーブルのデータ構造の一例を示す図である。
【図７】端末装置の記憶部内のディレクトリ構造の一例を示す図である。
【図８】アプリケーション毎ＵＲＬリストのデータ構造の一例を示す図である。
【図９】アプリケーションの機能の一例を示すブロック図である。
【図１０】第２の実施の形態の処理手順を示すシーケンス図である。
【図１１】ユーザルートＵＲＬを含むＨＴＭＬ文書の一例を示す図である。
【図１２】アプリケーションの初期画面の一例を示す図である。
【図１３】スケジュール表示画面の一例を示す図である。
【図１４】第３の実施の形態の処理手順の一例を示すシーケンス図である。
【図１５】第４の実施の形態の処理手順の一例を示すシーケンス図である。
【図１６】第５の実施の形態の各装置の機能の一例を示すブロック図である。
【図１７】第５の実施の形態の処理手順の一例を示すシーケンス図の前半である。
【図１８】ＯｐｅｎＩＤ入力画面の一例を示す図である。
【図１９】ポップアップ表示されたログインウィンドウの一例を示す図である。
【図２０】第５の実施の形態の処理手順の一例を示すシーケンス図の後半である。
【図２１】第６の実施の形態の各装置の機能を示すブロック図である。
【図２２】第６の実施の形態の処理手順の一例を示すシーケンス図である。
【図２３】ユーザルートＵＲＬ入力画面の一例を示す図である。
【図２４】第７の実施の形態の各装置の機能を示すブロック図である。
【図２５】第７の実施の形態の処理手順の一例を示すシーケンス図である。
【図２６】ログイン画面の一例を示す図である。
【発明を実施するための形態】
【００１２】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
第１の実施の形態では、複数のサーバそれぞれで提供されるアプリケーションを利用しながらも、ユーザ個人のデータは、ユーザが指定した１つの場所で一括して管理できるようにしたものである。これにより、複数のサーバそれぞれで提供されるアプリケーションを利用するユーザによるユーザの個人データの管理が容易となる。
【００１３】
すなわち、今後、インターネット上などで提供されるサービスは更に増加することが予想される。そうすると、一般的には、ある一人のユーザの個人データが、そのユーザが利用する複数のサーバ上でそれぞれ別個に管理されることになる。
【００１４】
個人情報が個人の管理の及ぶ範囲外の複数の箇所に格納されている状況は、ユーザ個人にとってはデータの管理負担が大きくなる。例えば、データをどこのサーバに格納したのかをユーザが失念した場合、ユーザは、サービスの提供を受けているすべてのサーバ内を検索することとなる。さらにインターネットのような広域ネットワーク上の複数のサーバにアクセスするには、多くの場合、ユーザ認証の手続きが行われる。そのため、複数のサーバそれぞれに格納した多数のデータの中から所望のデータを探し出すには、各サーバでユーザ認証手続きを行うこととなり、作業効率が非常に悪い。しかも、ユーザは、各サーバでのユーザ認証情報として、ユーザ名やパスワードの組を多数管理することとなり、ユーザ認証情報の管理負担も大きくなる。
【００１５】
そこで、第１の実施の形態では、ユーザの個人データを１つのサーバで一括管理可能とすることで、ユーザの負担軽減を図っている。なおユーザが複数のアプリケーションを利用している場合、複数のアプリケーションそれぞれで使用するデータを、１つのディレクトリ内に集約してしまうと、データ保管場所の衝突の危険性がある。データ保管場所の衝突とは、１つのアプリケーションのデータを格納した保管場所（例えばファイル）に、他のアプリケーションがデータを保管してしまうことである。このようなデータの保管場所の衝突は、複数のアプリケーションそれぞれが同じ名称のファイルを作成した場合などに発生する。第１の実施の形態では、データ保管場所の衝突を抑止する機能を備えることで、複数のアプリケーションそれぞれで利用されるユーザの個人データを１つのデータ格納装置で一括管理することを可能としている。
【００１６】
図１は、第１の実施の形態に係る情報処理装置の機能構成例を示す図である。情報処理装置１は、データ処理手段１ａ、位置情報取得手段１ｂ、位置情報生成手段１ｃ、記憶手段１ｄ、アクセス先情報生成手段１ｅ、およびアクセス手段１ｆを有している。また、情報処理装置１で処理される情報には、例えば第１のアクセス情報４、第１の位置情報５、第２の位置情報６、第２のアクセス情報７、およびアクセス結果８がある。これらの情報は、情報処理装置１で処理される情報の一例である。また図１では、情報処理装置１の処理手段と情報とを区別するため、情報は破線の矩形で示している。
【００１７】
データ処理手段１ａは、ユーザ９からの要求に応じてデータ処理を実行する。例えばユーザ９は、入力装置２を用いてデータ処理の要求をデータ処理手段１ａに入力することができる。またデータ処理手段１ａは、ユーザ９の個人データにアクセスする場合、基準位置から該個人データを含むファイルまでディレクトリ構造を辿ったときの経路および該ファイルのファイル名を示す第１のアクセス先情報４を生成する。
【００１８】
なお、以下の説明において、ファイルという文言を用いるが、これは、ファイルシステム上の１個の独立したデータファイルという狭義の意味のみで用いているのではない。以下の説明において、ファイルという文言は、例えばデータベースシステム内のある１行のデータのように、何らかのデータを格納したり読み出したりできる一区切りの領域、すなわちデータリソースという広義の意味も含む。
【００１９】
また、以下の説明において、ディレクトリまたはディレクトリ構造という文言を用いるが、これは、単一のコンピュータの中のファイルシステムにおけるファイルの位置を示す情報という狭義の意味のみで用いているのではない。以下の説明において、ディレクトリまたはディレクトリ構造という文言は、例えばＵＲＬ（Uniform Resource Locator）のような、複数のコンピュータ間をまたがってファイルの位置を示す識別子における、ファイル階層配置や参照構造を表現するための情報という広義の意味も含む。
【００２０】
位置情報取得手段１ｂは、ユーザ指定のデータ格納装置３の識別情報および該データ格納装置３内のユーザ指定のディレクトリの位置を示す第１の位置情報５を取得する。例えば、位置情報取得手段１ｂは、ユーザ９が入力装置２を用いて入力した第１の位置情報５を取得する。
【００２１】
位置情報生成手段１ｃは、第１の位置情報５に基づいて、ユーザ指定のディレクトリ配下の、データ処理手段１ａに一意に割り当てられたディレクトリの位置を示す第２の位置情報６を生成する。例えば位置情報生成手段１ｃは、データ処理手段１ａを一意に示す名称を、第１の位置情報５の後に、ユーザ指定のディレクトリ配下のディレクトリ名として追加する。そして位置情報生成手段１ｃは、データ処理手段１ａを一意に示す名称追加後の位置情報を、第２の位置情報６とする。位置情報生成手段１ｃは、例えば生成した第２の位置情報６を記憶手段１ｄに格納する。
【００２２】
記憶手段１ｄは、第２の位置情報６を記憶する。
アクセス先情報生成手段１ｅは、第１のアクセス先情報４と第２の位置情報６とに基づいて、第２のアクセス先情報７を生成する。第２のアクセス先情報７は、第２の位置情報６で示される位置を基準位置とした場合のアクセス対象のデータを含むファイルの格納位置および該ファイルのファイル名を示している。例えばアクセス先情報生成手段１ｅは、第２の位置情報６を記憶手段１ｄから取得する。次にアクセス先情報生成手段１ｅは、取得した第２の位置情報６の後ろに、第１のアクセス先情報４を繋げて第２のアクセス先情報７とする。アクセス先情報生成手段１ｅは、第２のアクセス先情報７をアクセス手段１ｆに渡す。
【００２３】
アクセス手段１ｆは、第２のアクセス先情報７に基づいて、データ格納装置３内のアクセス対象のデータを含むファイルにアクセスする。そしてアクセス手段１ｆは、アクセス結果８をデータ処理手段１ａに渡す。例えば、データ処理手段１ａがアクセス対象の個人データに対して行うアクセスが書き込みアクセスの場合、アクセス手段１ｆがデータ格納装置３内のアクセス対象の個人データを含むファイルに、個人データの書き込みを行う。この場合、アクセス結果８として書き込み完了応答が、アクセス手段１ｆからデータ処理手段１ａに渡される。またデータ処理手段１ａがアクセス対象の個人データに対して行うアクセスが読み出しアクセスの場合、アクセス手段１ｆがデータ格納装置３内のアクセス対象の個人データを含むファイル内のデータを読み出す。この場合、アクセス結果８として読み出されたファイル内のデータが、アクセス手段１ｆからデータ処理手段１ａに渡される。
【００２４】
図２は、第１の実施の形態に係る情報処理装置の処理手順を示すフローチャートである。以下、図２に示す処理を、図１を参照しながらステップ番号に沿って説明する。
［ステップＳ１］位置情報取得手段１ｂは、ユーザ指定のデータ格納装置３の識別情報および該データ格納装置３内のユーザ指定のディレクトリの位置を示す第１の位置情報５を取得する。図１の例では、「//api.data.example/user1/」という第１の位置情報５を取得している。この第１の位置情報５には、「api.data.example」というユーザ指定のデータ格納装置３の識別情報と、「/user1/」というユーザ指定のディレクトリの位置を示す情報とが含まれる。
【００２５】
［ステップＳ２］位置情報生成手段１ｃは、第１の位置情報５に基づいて、ユーザ指定のディレクトリ配下の、データ処理手段１ａに一意に割り当てられたディレクトリの位置を示す第２の位置情報６を生成する。図１の例では、「//api.data.example/user1/app1/」という第２の位置情報６が生成されている。この第２の位置情報６は、第１の位置情報５の後に、「app1/」というディレクトリ名を追加したものである。
【００２６】
［ステップＳ３］データ処理手段１ａは、ユーザ９からの要求に応じてデータ処理を実行する。
［ステップＳ４］データ処理手段１ａは、ユーザ９からの要求に応じたデータ処理が終了したか否かを判断する。例えばデータ処理手段１ａは、ユーザ９からデータ処理終了を示す操作入力があった場合、データ処理終了と判断する。またデータ処理手段１ａは、例えばユーザ９との間の対話型の入力を取得せずに実行可能なデータ処理の場合、予定されたすべてのデータ処理が終了した時点で、データ処理終了と判断する。データ処理終了であれば、図２の処理を終了する。データ処理が終了していなければ、データ処理手段１ａは、処理をステップＳ５に進める。
【００２７】
［ステップＳ５］データ処理手段１ａは、ユーザ９の個人データへのアクセスが発生したか否かを判断する。データ処理手段１ａは、個人データへのアクセスが発生した場合、基準位置から該個人データを含むファイルまでディレクトリ構造を辿ったときの経路および該ファイルのファイル名を示す第１のアクセス先情報４を生成する。図１の例では、「/data/file1」という第１のアクセス先情報４が生成されている。この第１のアクセス先情報４は、基準位置の下の「/data」というディレクトリ名のディレクトリの下の「file1」というファイル名のファイルがアクセス先であることを示している。その後、処理をステップＳ６に進める。ユーザの個人データへのアクセスが発生していなければ、データ処理手段１ａは処理をステップＳ３に進める。
【００２８】
［ステップＳ６］アクセス先情報生成手段１ｅは、第１のアクセス先情報４と第２の位置情報６とに基づいて、第２のアクセス先情報７を生成する。例えばアクセス先情報生成手段１ｅは、第２の位置情報６の後に第１のアクセス先情報４を繋げ、第２のアクセス先情報７とする。図１の例では、「//api.data.example/user1/app1/data/file1」という第２のアクセス先情報７が生成されている。
【００２９】
［ステップＳ７］アクセス手段１ｆは、第２のアクセス先情報７に基づいて、データ格納装置３内のアクセス対象のデータを含むファイルにアクセスする。アクセス手段１ｆは、アクセス結果をデータ処理手段１ａに通知する。その後、アクセス手段１ｆは、処理をステップＳ３に進める。
【００３０】
このようにして、情報処理装置１は、ユーザ９が指定した第１の位置情報５配下のデータ処理手段１ａを一意に示すディレクトリに対して、ユーザ９の個人データのアクセスを行うことができる。ユーザ９が複数のデータ処理手段を使用する場合にも、ユーザ９はすべてのデータ処理手段に対して同一の第１の位置情報５を入力すればよい。この場合でも、複数のデータ処理手段それぞれが使用するユーザ９の個人データは、データ格納装置３内で、データ処理手段を一意に示すディレクトリによって分類して管理される。
【００３１】
例えば、ユーザ９が、ネットワーク上の多数のサーバそれぞれで提供されているアプリケーションを、図１に示したデータ処理手段１ａとして利用できる。この場合、複数のアプリケーションで使用されるユーザ９の個人データが、データ格納装置３で管理される。
【００３２】
ユーザ９の個人データを１つのデータ格納装置３で統一して管理できることで、ユーザ９は、自己のデータの管理が容易になる。
なお、データ処理手段１ａ、位置情報取得手段１ｂ、位置情報生成手段１ｃ、アクセス先情報生成手段１ｅ、およびアクセス手段１ｆは、情報処理装置１が有するＣＰＵ（Central Processing Unit）により実現することができる。また、記憶手段１ｄは、情報処理装置１が有するＲＡＭ（Random Access Memory）やハードディスクドライブ（ＨＤＤ:Hard Disk Drive）などの記憶媒体により実現することができる。
【００３３】
上記の第１、２の位置情報の記述方式としては、例えばＵＲＬを用いることができる。そこで、以後、第１の実施の形態に示した第１の位置情報を「ユーザルートＵＲＬ」、第２の位置情報を「アプリケーション毎ＵＲＬ」と呼ぶこととする。また、第１のアクセス先情報を「アプリケーションローカルパス」、第２のアクセス先情報を「アクセス先ＵＲＬ」と呼ぶこととする。
【００３４】
ところで、図１の情報処理装置１に示したデータ処理手段１ａ、位置情報取得手段１ｂ、位置情報生成手段１ｃ、記憶手段１ｄ、アクセス先情報生成手段１ｅ、およびアクセス手段１ｆは、例えば１つのアプリケーションとして提供される。提供されるアプリケーションの実行形態には、例えば以下の３つの形態が考えられる。
【００３５】
＜第１のアプリケーション実行形態＞
第１のアプリケーション実行形態は、アプリケーションの機能が必要となったときに、その都度、サーバから端末装置へアプリケーションプログラムをダウンロードする実施形態である。端末装置は、ダウンロードしたアプリケーションプログラムに基づいてアプリケーションを実行する。
【００３６】
＜第２のアプリケーション実行形態＞
第２のアプリケーション実行形態は、アプリケーションをサーバで実行する形態である。第２のアプリケーション実行形態では、例えばサーバから端末装置のブラウザに、画面描画指示（ＨＴＭＬ（HyperText Markup Language）文書の表示指示）が送信され、端末装置において画面表示が行われる。表示された画面に対してユーザが操作入力を行うと、操作内容に応じてブラウザがＨＴＴＰ（HyperText Transfer Protocol）リクエストをサーバに送信する。画面描画指示には、ユーザに対する端末装置に送信される。サーバで実行されているアプリケーションは、端末装置からのＨＴＴＰリクエストに応じてデータ処理を実行し、実行結果を含む画面描画指示を端末装置に送信する。
【００３７】
＜第３のアプリケーション実行形態＞
第３のアプリケーション実行形態は、予め端末装置にアプリケーションを導入しておく実施形態である。第３のアプリケーション実行形態では、ユーザは、予めアプリケーションプログラムを端末装置内の記憶媒体に、起動可能な状態で格納しておく。例えばユーザが端末装置を操作してアプリケーションのインストール作業を行うことで、アプリケーションが起動可能な状態で格納される。
【００３８】
以上の３つのアプリケーション実行形態のいずれかで実行されたアプリケーションがユーザルートＵＲＬを取得する方法としては、例えば以下の４つの方法がある。
＜第１のユーザルートＵＲＬ取得方法＞
第１のユーザルートＵＲＬ取得方法は、アプリケーションがユーザに対してユーザルートＵＲＬの入力を促す画面表示を行い、その画面に対してユーザがユーザルートＵＲＬを入力するものである。
【００３９】
＜第２のユーザルートＵＲＬ取得方法＞
第２のユーザルートＵＲＬ取得方法は、任意のタイミングでユーザが入力したユーザルートＵＲＬを所定の記憶領域に記憶しておき、アプリケーションは、所定の記憶領域からユーザルートＵＲＬを読み出すものである。このユーザルートＵＲＬ取得方法では、第１回目のユーザルートＵＲＬの取得においては、例えば第１のユーザルートＵＲＬ取得方法を用いた取得が行われ、取得したユーザルートＵＲＬが所定の記憶領域に格納される。
【００４０】
＜第３のユーザルートＵＲＬ取得方法＞
第３のユーザルートＵＲＬ取得方法は、アプリケーションプログラムのダウンロードと同時に、サーバから、ユーザに対応するユーザルートＵＲＬを取得するものである。例えばサーバにおいて、ユーザのためのエンドポイントＵＲＬを用意する。エンドポイントＵＲＬとは、各ユーザそれぞれに対応して用意されたＵＲＬである。ユーザがエンドポイントＵＲＬにアクセスすることで、そのエンドポイントＵＲＬに対応するユーザの好みに合わせて加工された文書が、ユーザに提供される。サーバは、ユーザがアプリケーションを利用するために、端末装置を用いてサーバで用意されたエンドポイントＵＲＬにアクセスすると、アプリケーションプログラムを端末装置に送信する。この際、サーバは、アプリケーションプログラムの送信に加え、予めエンドポイントＵＲＬに対応付けられたユーザルートＵＲＬを端末装置に送信する。
【００４１】
＜第４のユーザルートＵＲＬ取得方法＞
第４のユーザルートＵＲＬ取得方法は、ＯｐｅｎＩＤを用いたものである。ＯｐｅｎＩＤは、複数のウェブサイトで利用できる認証用の識別子である。１つのＯｐｅｎＩＤによって、複数のウェブサイトで認証を受けることが可能である。第４のユーザルートＵＲＬ取得方法では、例えばＯｐｅｎＩＤを管理しているウェブサイトがユーザルートＵＲＬをアプリケーションに通知する。またＯｐｅｎＩＤ内にユーザルートＵＲＬの情報を含ませ、ユーザはＯｐｅｎＩＤを用いてアプリケーションにログインするようにする。これにより、アプリケーションは、ログインに用いられたＯｐｅｎＩＤからユーザルートＵＲＬを取得できる。
【００４２】
また、ユーザルートＵＲＬ配下でアプリケーションを一意に識別するためのパス（ディレクトリ名など）を取得してアプリケーション毎ＵＲＬを決定するアプリケーション毎ＵＲＬ決定方法については、例えば以下の３つの方法が考えられる。
【００４３】
＜第１のアプリケーション毎ＵＲＬ決定方法＞
第１のアプリケーション毎ＵＲＬ決定方法は、ルールベースにより、アクセス先ＵＲＬを決定するものである。第１のアプリケーション毎ＵＲＬ決定方法では、例えば、アプリケーションそれぞれを一意に識別可能なディレクトリ名の生成規則がルールベースで定義されている。そして、アプリケーションは、ユーザルートＵＲＬの後にアプリケーションに応じたディレクトリ名をルールベースに従って繋げることで、アプリケーション毎ＵＲＬを生成する。
【００４４】
＜第２のアプリケーション毎ＵＲＬ決定方法＞
第２のアプリケーション毎ＵＲＬ決定方法では、ユーザルートＵＲＬに対応するサーバが、予めアプリケーション毎ＵＲＬリストを保持する。アプリケーション毎ＵＲＬリストには、アプリケーションの識別情報に対応付けて、そのアプリケーションのアプリケーション毎ＵＲＬが登録されている。ユーザルートＵＲＬに対応するサーバは、アプリケーションに対してアプリケーション毎ＵＲＬリストを提供する。アプリケーションは、提供されたアプリケーション毎ＵＲＬリストから、自己のアプリケーション毎ＵＲＬを取得する。なお、アプリケーション毎ＵＲＬリストには、アクセス制限をかけることができる。例えばアプリケーション毎ＵＲＬリストを取得する際に、アプリケーションは、ＯＡｕｔｈなどの認証トークンをサーバに送信する。ＯＡｕｔｈは、ＡＰＩ（Application Programming Interface）の承認を委譲するプロトコルである。サーバでは、認証トークンによってユーザ認証を行う。
【００４５】
＜第３のアプリケーション毎ＵＲＬ決定方法＞
第３のアプリケーション毎ＵＲＬ決定方法は、アプリケーションがユーザルートＵＲＬに対応するサーバに対して、アプリケーション毎ＵＲＬを問い合わせ、サーバが、そのアプリケーションに対応するアプリケーション毎ＵＲＬを応答するものである。第３のアプリケーション毎ＵＲＬ決定方法においても、認証トークンなどによる、サーバに対するアプリケーション毎ＵＲＬの問い合わせに対して制限を設けることができる。
【００４６】
以上のように、３つのアプリケーション実行形態、４つのユーザルートＵＲＬ取得方法、および３つのアプリケーション毎ＵＲＬ決定方法を任意に組み合わせて、様々な実施形態が可能となる。以下、そのうちのいくつかの実施形態について詳細に説明する。
【００４７】
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、第１のアプリケーション実行形態、第３のユーザルートＵＲＬ取得方法、および第２のアプリケーション毎ＵＲＬ決定方法を組み合わせたものである。
【００４８】
図３は、第２の実施の形態のシステム構成例を示す図である。ネットワーク１０には、端末装置１００、複数のアプリケーションサーバ２００，２００−１，２００−２、およびデータ格納サーバ３００が接続されている。端末装置１００は、ユーザ２１が操作入力を行うコンピュータである。
【００４９】
複数のアプリケーションサーバ２００，２００−１，２００−２は、それぞれ個別のアプリケーションによりサービスを提供するコンピュータである。ユーザ２１は端末装置１００を用いてアプリケーションサーバ２００，２００−１，２００−２のいずれかにアクセスし、所望のサービスの提供を受けることができる。
【００５０】
データ格納サーバ３００は、ユーザ２１の個人データを格納するコンピュータである。データ格納サーバ３００には、複数のアプリケーションサーバ２００，２００−１，２００−２それぞれのアプリケーションの実行に利用されるユーザ２１の個人データが格納される。
【００５１】
複数のアプリケーションサーバ２００，２００−１，２００−２とデータ格納サーバ３００とは、例えばドメイン名によってネットワーク１０上で識別される。図３の例では、アプリケーションサーバ２００のドメイン名は、「app1.example.com」である。アプリケーションサーバ２００−１のドメイン名は、「app2.isv1.example」である。アプリケーションサーバ２００−２のドメイン名は、「app3.a-soft.example」である。データ格納サーバ３００のドメイン名は、「api.data-service.example」である。
【００５２】
また、ネットワーク１０を介した各装置間の通信は、例えばＨＴＴＰまたはＨＴＴＰＳ（Hypertext Transfer Protocol over Secure Socket Layer）に従って行われる。
図４は、第２の実施の形態に用いる端末装置のハードウェアの一構成例を示す図である。端末装置１００は、ＣＰＵ１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０８を介してＲＡＭ１０２と複数の周辺機器が接続されている。
【００５３】
ＲＡＭ１０２は、端末装置１００の主記憶装置として使用される。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。
【００５４】
バス１０８に接続されている周辺機器としては、ハードディスクドライブ（ＨＤＤ）１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、および通信インタフェース１０７がある。
【００５５】
ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、端末装置１００の二次記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。
【００５６】
グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。モニタ１１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。
【００５７】
入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号をＣＰＵ１０１に送信する。なお、マウス１３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
【００５８】
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク１４に記録されたデータの読み取りを行う。光ディスク１４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク１４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
【００５９】
通信インタフェース１０７は、ネットワーク１０に接続されている。通信インタフェース１０７は、ネットワーク１０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
【００６０】
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお図４には端末装置１００のハードウェア構成例を示したが、複数のアプリケーションサーバ２００，２００−１，２００−２やデータ格納サーバ３００も同様のハードウェア構成で実現することができる。また、図１に示した第１の実施の形態の情報処理装置１も、図４に示した端末装置１００と同様のハードウェア構成で実現することができる。
【００６１】
図５は、第２の実施の形態の各装置の機能を示すブロック図である。端末装置１００は、ブラウザ１１０とアプリケーション１２０とを有している。ただし、アプリケーション１２０は、ユーザ２１がアプリケーション１２０によるデータ処理機能を利用する際に、その都度、端末装置１００に実装される。
【００６２】
ブラウザ１１０は、ＨＴＭＬ文書を解析し、ＨＴＭＬ文書の内容をモニタ１１の画面に表示する。またブラウザ１１０は、構造化文書内にアプリケーション１２０の実行指示が記述されている場合、アプリケーションサーバ２００からアプリケーションプログラムを取得し、端末装置１００のＲＡＭ１０２やＨＤＤ１０３に格納する。なおブラウザ１１０は、アプリケーション１２０の実行指示が記述されたＨＴＭＬ文書から、ユーザ２１に対応するユーザルートＵＲＬを抽出する。ユーザ２１に対応するユーザルートＵＲＬは、データ格納サーバ３００内のユーザ２１のデータが格納された記憶領域を示している。そしてブラウザ１１０は、アプリケーション１２０の起動要求を出力する際に、起動コマンドにおいて、抽出したユーザルートＵＲＬをパラメータとして指定する。
【００６３】
アプリケーション１２０は、ユーザ２１からの要求に応じてデータ処理を実行する。なおアプリケーション１２０は、起動時に、パラメータで指定されたユーザルートＵＲＬに基づいてデータ格納サーバ３００にアクセスし、ユーザ２１に対応するアプリケーション毎ＵＲＬリスト３１２を取得する。アプリケーション毎ＵＲＬリスト３１２には、ユーザ２１が利用する各種アプリケーションに対応付けて、アプリケーション毎ＵＲＬが設定されている。そしてアプリケーション１２０は、取得したアプリケーション毎ＵＲＬリスト３１２の中から、自己のアプリケーション毎ＵＲＬを取得する。アプリケーション１２０は、その後、データ処理中にユーザ２１の個人データへのアクセスが発生すると、アクセス先ＵＲＬを生成する。例えばアプリケーション１２０は、取得したアプリケーション毎ＵＲＬで指定された位置を基準位置とする。アプリケーション１２０は、その基準位置からディレクトリ構造を辿ったときのアクセス対象のデータの位置を示す位置情報を、アプリケーション毎ＵＲＬに追加して、アクセス先ＵＲＬを生成する。そしてアプリケーション１２０は、アクセス先ＵＲＬを指定したデータアクセスを、データ格納サーバ３００に対して行う。
【００６４】
アプリケーションサーバ２００は、記憶部２１０、文書提供部２２０、およびルートＵＲＬ判定部２３０を有している。
記憶部２１０には、複数のＨＴＭＬ文書２１１，２１１ａ，２１１ｂ，・・・、アプリケーションプログラム２１２、およびルートＵＲＬ管理テーブル２１３が格納されている。アプリケーションプログラム２１２は、アプリケーション１２０が実行するデータ処理の内容が記述されたプログラムである。ルートＵＲＬ管理テーブル２１３には、ユーザごとのユーザルートＵＲＬが設定されている。
【００６５】
文書提供部２２０は、端末装置１００のブラウザ１１０からの要求に応じて、ＨＴＭＬ文書やアプリケーションプログラム２１２を端末装置１００に送信する。なお文書提供部２２０には、ユーザ２１に対応するエンドポイントＵＲＬが設けられている。例えば、ユーザ２１に対応するエンドポイントＵＲＬには、正しく認証された後にアクセス可能となる。文書提供部２２０は、ブラウザ１１０からエンドポイントＵＲＬにアクセスがあると、ユーザ２１に対応付けて用意されており、アプリケーションプログラム２１２の実行指示が記述されたＨＴＭＬ文書２１１を端末装置１００に送信する。この際、文書提供部２２０は、ルートＵＲＬ判定部２３０から、ユーザ２１のユーザルートＵＲＬを取得し、送信するＨＴＭＬ文書２１１内に挿入する。また文書提供部２２０は、端末装置１００のブラウザ１１０からアプリケーションプログラム２１２の取得要求を受け取ると、アプリケーションプログラム２１２をブラウザ１１０に送信する。
【００６６】
ルートＵＲＬ判定部２３０は、文書提供部２２０からの要求に応じ、ルートＵＲＬ管理テーブル２１３を参照し、アプリケーションプログラム２１２を使用するユーザ２１のユーザルートＵＲＬを判定する。そして、ルートＵＲＬ判定部２３０は、判定したユーザルートＵＲＬを文書提供部２２０に通知する。
【００６７】
データ格納サーバ３００は、記憶部３１０、アプリケーション毎ＵＲＬ管理部３２０、およびデータ管理部３３０を有している。
記憶部３１０は、ファイル３１１，３１１ａ，３１１ｂ，・・・と、アプリケーション毎ＵＲＬリスト３１２とが格納されている。ファイル３１１，３１１ａ，３１１ｂ，・・・は、ユーザ２１の個人データを含むファイルである。アプリケーション毎ＵＲＬリスト３１２には、ユーザ２１が使用する複数のアプリケーションそれぞれに対応付けて、アプリケーションが使用するデータが格納されたファイルの所在を示すアプリケーション毎ＵＲＬが設定されている。
【００６８】
アプリケーション毎ＵＲＬ管理部３２０は、アプリケーション１２０からの要求に応じてアプリケーション毎ＵＲＬリスト３１２を送信する。なおアプリケーション毎ＵＲＬ管理部３２０は、例えば、予めアプリケーション１２０を使用しているユーザ２１を正しく認証した場合にのみ、アプリケーション毎ＵＲＬリスト３１２を送信するようにしてもよい。
【００６９】
データ管理部３３０は、アプリケーション１２０からのアクセス要求に応じて、指定されたファイルへのアクセスを行う。例えばアクセス要求がファイルの取得要求であれば、データ管理部３３０は、アクセス要求で指定されたファイルをアプリケーション１２０に送信する。またアクセス要求がファイルの書き込み要求であれば、データ管理部３３０は、指定されたファイルを記憶部３１０内の指定された位置に書き込む。なお、ファイル取得要求では、アクセス先ＵＲＬによってアクセス対象のファイルの位置が指定される。
【００７０】
次に、各装置に格納されている情報のデータ構造について、詳細に説明する。
図６は、ルートＵＲＬ管理テーブルのデータ構造の一例を示す図である。ルートＵＲＬ管理テーブル２１３には、ユーザＩＤ、エンドポイントＵＲＬ、およびユーザルートＵＲＬとの欄が設けられている。
【００７１】
ユーザＩＤの欄には、アプリケーションサーバ２００を利用するユーザを一意に識別する識別子（ユーザＩＤ）が設定される。
エンドポイントＵＲＬの欄には、ユーザＩＤに対応付けて、そのユーザＩＤで示されるユーザのエンドポイントＵＲＬが設定される。
【００７２】
ユーザルートＵＲＬの欄には、ユーザＩＤに対応付けて、そのユーザＩＤで示されるユーザのユーザルートＵＲＬが設定される。
ルートＵＲＬ判定部２３０は、ルートＵＲＬ管理テーブル２１３を参照して、各ユーザに応じたユーザルートＵＲＬを判定する。例えばユーザＩＤ「ＡＢ１２３４」のユーザ２１から、そのユーザＩＤに対応するエンドポイントＵＲＬに対してアクセスがあった場合、ルートＵＲＬ判定部２３０は、ユーザＩＤ「ＡＢ１２３４」に対応付けられたユーザルートＵＲＬを抽出する。そしてルートＵＲＬ判定部２３０は、抽出したユーザルートＵＲＬを、アクセスを行ったユーザ２１のユーザルートＵＲＬとして、文書提供部２２０に通知する。
【００７３】
なお、図６の例示では、ユーザＩＤ「ＡＢ１２３４」に対応するエンドポイントＵＲＬは、「http://app1.example/?userUrl=http%253A%252F%252Fdata.example%252Fshimono」である。このエンドポイントＵＲＬは、「http://app1.example/」というＵＲＬで特定される文書管理部２２０が「userUrl」というパラメータの値として「http://api.data.example/user1/」というユーザルートＵＲＬを受け取ることを示している。文書管理部２２０は、エンドポイントＵＲＬを指定したリクエストに対する応答の中で、受け取ったＵＲＬ「http://api.data.example/user1」を、アプリケーション１２０に設定するユーザルートＵＲＬとして返す。
【００７４】
ユーザルートＵＲＬ判定方法としては、ルートＵＲＬ判定部２３０が、エンドポイントＵＲＬからユーザルートＵＲＬを生成するロジックは、テーブルを参照することで生成する方法に加え、クエリパラメータを解釈して生成する方法もある。
【００７５】
すなわち、ルートＵＲＬ判定部２３０がユーザルートＵＲＬを判定する方法は、上記のように、ユーザＩＤに対応するエンドポイントＵＲＬを用いてテーブルを参照することによりユーザルートＵＲＬを判定するやり方に限るものではない。例えば、ユーザＩＤに対応するエンドポイントＵＲＬから文字列計算によりユーザルートＵＲＬを生成することが考えられる。また例えば、ユーザ認証をしてその際使われたユーザＩＤからテーブル突合によりユーザルートＵＲＬを判定することも考えられる。
【００７６】
また、上記処理で用いるテーブルも、図６に例示したものに限る必要は無い。図６では、ユーザＩＤ、エンドポイントＵＲＬ、ユーザルートＵＲＬの３つの項目を互いに対応付けて格納している例を示している。これ以外にも例えば、ユーザＩＤとユーザルートＵＲＬとの２項目や、エンドポイントＵＲＬとユーザルートＵＲＬとの２項目を互いに対応付けて格納したテーブルであってもよい。
【００７７】
なお第２の実施の形態では、ルートＵＲＬ管理テーブル２１３によってユーザルートＵＲＬを管理しているが、各ユーザに提供するＨＴＭＬ文書内に予めユーザルートＵＲＬを埋め込んでおくこともできる。例えば、エンドポイントＵＲＬを指定したアクセスがあった場合に送信するＨＴＭＬ文書に、エンドポイントＵＲＬに対応するユーザルートＵＲＬを予め書き込んでおく。この場合、ルートＵＲＬ判定部２３０やルートＵＲＬ管理テーブル２１３は不要となる。
【００７８】
次に、データ格納サーバ３００の記憶部３１０内のディレクトリ構造について説明する。
図７は、端末装置の記憶部内のディレクトリ構造の一例を示す図である。記憶部３１０には、データ格納サーバ３００のＯＳが有するファイルシステムにより、階層的なディレクトリ構造でファイルが格納されている。図７の例では、最上位の「root」のディレクトリ３１３の配下にディレクトリ名「user1」のディレクトリ３１４が設けられている。ディレクトリ名「user1」のディレクトリ３１４は、ユーザ２１の個人データ用に設けられたディレクトリである。
【００７９】
ディレクトリ名「user1」のディレクトリ３１４の配下には、ディレクトリ名「app1」のディレクトリ３１５、ディレクトリ名「app2」のディレクトリ３１６、およびディレクトリ名「app3」のディレクトリ３１７が設けられている。ディレクトリ名「app1」のディレクトリ３１５は、アプリケーションサーバ２００で提供されているアプリケーション１２０が使用するユーザ２１の個人データの格納用のディレクトリである。ディレクトリ名「app2」のディレクトリ３１６は、アプリケーションサーバ２００−１で提供されているアプリケーションが使用するユーザ２１の個人データの格納用のディレクトリである。ディレクトリ名「app3」のディレクトリ３１７は、アプリケーションサーバ２００−２で提供されているアプリケーションが使用するユーザ２１の個人データの格納用のディレクトリである。
【００８０】
ディレクトリ名「app1」のディレクトリ３１５の配下には、複数のファイル３１１，３１１ａ，３１１ｂ，・・・が格納されている。ファイル３１１のファイル名は「file1」である。ファイル３１１ａのファイル名は「file2」である。ファイル３１１ｂのファイル名は「file3」である。
【００８１】
またディレクトリ名「user1」のディレクトリ３１４の配下には、ファイル名「url＿list」のファイル３１２ａが格納されている。ファイル名「url＿list」のファイル３１２ａには、アプリケーション毎ＵＲＬリスト３１２が格納されている。
【００８２】
次に、アプリケーション毎ＵＲＬリストのデータ構造について説明する。
図８は、アプリケーション毎ＵＲＬリストのデータ構造の一例を示す図である。図８の例ではアプリケーション毎ＵＲＬリスト３１２の内容がＸＭＬ（Extensible Markup Language）で記述されている。アプリケーション毎ＵＲＬリスト３１２内には、各アプリケーションのアプリケーション毎ＵＲＬが、そのアプリケーションを提供しているアプリケーションサーバのドメイン名に対応付けて設定されている。
【００８３】
例えば、ドメイン名「app1.example.com」に対応付けて、アプリケーション毎ＵＲＬ「http://api.data-service.example/user1/app1/」が設定されている。ドメイン名「app2.isv1.example」に対応付けて、アプリケーション毎ＵＲＬ「http://api.data-service.example/user1/app2/」が設定されている。ドメイン名「app3.a-soft.example」に対応付けて、アプリケーション毎ＵＲＬ「http://api.data-service.example/user1/app3/」が設定されている。
【００８４】
次に、アプリケーション１２０の機能について詳細に説明する。
図９は、アプリケーションの機能の一例を示すブロック図である。アプリケーション１２０は、データ処理部１２１、ユーザルートＵＲＬ取得部１２２、ユーザルートＵＲＬ記憶部１２３、アプリケーション毎ＵＲＬ判定部１２４、アプリケーション毎ＵＲＬ記憶部１２５、アクセス先ＵＲＬ生成部１２６、およびアクセス部１２７を有する。
【００８５】
データ処理部１２１は、ブラウザ１１０からの起動要求に応じて起動され、ユーザ２１からの操作入力などによる要求に従って、データ処理を実行する。データ処理部１２１は、データ処理過程において、ユーザ２１の個人データを使用する場合、所定の基準位置からディレクトリを辿ったときの該当個人データの位置を示すアプリケーションローカルパスを伴うアクセス要求をアクセス先ＵＲＬ生成部１２６に渡す。アプリケーションローカルパスは、例えば、その基準位置からデータが格納されたファイルへのディレクトリ構造における相対パスと、そのデータが格納されたファイルのファイル名とで指定される。またデータ処理部１２１は、アクセス要求に応じたアクセス結果を、アクセス部１２７から取得する。
【００８６】
ユーザルートＵＲＬ取得部１２２は、ブラウザ１１０から位置情報を取得する。例えばユーザルートＵＲＬ取得部１２２は、ブラウザ１１０からの起動要求から、その起動要求にパラメータで指定されたユーザルートＵＲＬを取得する。ユーザルートＵＲＬ取得部１２２は、取得したユーザルートＵＲＬをユーザルートＵＲＬ記憶部１２３に格納する。
【００８７】
ユーザルートＵＲＬ記憶部１２３は、ユーザルートＵＲＬを記憶する。例えばＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部がユーザルートＵＲＬ記憶部１２３として使用される。
【００８８】
アプリケーション毎ＵＲＬ判定部１２４は、ユーザルートＵＲＬ記憶部１２３に格納されたユーザルートＵＲＬに基づいて、アプリケーション毎ＵＲＬを判定する。例えばアプリケーション毎ＵＲＬ判定部１２４は、ユーザルートＵＲＬ直下の、ファイル名「url＿list」を指定して、データ格納サーバ３００にアクセス（ファイル取得要求）する。すると、データ格納サーバ３００からはアプリケーション毎ＵＲＬリスト３１２が応答される。アプリケーション毎ＵＲＬ判定部１２４は、アプリケーション毎ＵＲＬリスト３１２を参照し、自己のアプリケーション毎ＵＲＬを判断する。例えばアプリケーション毎ＵＲＬ判定部１２４には、アプリケーション１２０を提供したアプリケーションサーバ２００のドメイン名が予め設定されているものとする。この場合、アプリケーション毎ＵＲＬ判定部１２４は、予め設定されているドメイン名に対応するアプリケーション毎ＵＲＬを、自己のアプリケーション毎ＵＲＬと判定する。アプリケーション毎ＵＲＬ判定部１２４は、判定したアプリケーション毎ＵＲＬをアプリケーション毎ＵＲＬ記憶部１２５に格納する。
【００８９】
アプリケーション毎ＵＲＬ記憶部１２５は、アプリケーション毎ＵＲＬを記憶する。例えばＲＡＭ１０２またはＨＤＤ１０３の記憶領域の一部がアプリケーション毎ＵＲＬ記憶部１２５として使用される。
【００９０】
アクセス先ＵＲＬ生成部１２６は、アプリケーション毎ＵＲＬ記憶部１２５に記憶されたアプリケーション毎ＵＲＬと、データ処理部１２１から出力されたアクセス要求で指定されているアプリケーションローカルパスとに基づいてアクセス先ＵＲＬを生成する。そしてアクセス先ＵＲＬ生成部１２６は、生成したアクセス先ＵＲＬをアクセス部１２７に渡す。
【００９１】
アクセス部１２７は、アクセス先ＵＲＬでアクセス先を指定して、ネットワーク１０を介したアクセスを行う。アプリケーション１２０で生成されるアクセス先ＵＲＬは、データ格納サーバ３００内のファイルを示している。従って、アクセス部１２７は、データ格納サーバ３００に対してアクセス要求を送信することとなる。するとデータ格納サーバ３００からは、アクセス結果が応答される。例えば、アクセス要求がデータの読み取り要求であれば、アクセス対象のデータがデータ格納サーバ３００から応答される。またアクセス要求がデータの書き込み要求であれば、書き込み処理の結果がデータ格納サーバ３００から応答される。
【００９２】
各装置が以上のような機能を有していることで、複数のアプリケーションサーバ２００，２００−１，２００−２で提供されている各アプリケーションが使用するユーザ２１の個人データを、データ格納サーバ３００に一括して管理させることができる。以下、アプリケーションサーバ２００で提供されるアプリケーション１２０が、データ格納サーバ３００内のデータを利用する場合を想定し、データアクセスまでの処理手順を説明する。
【００９３】
図１０は、第２の実施の形態の処理手順を示すシーケンス図である。以下、図１０に示す処理をステップ番号に沿って説明する。
［ステップＳ１１］ユーザ２１は、ユーザ２１に対応付けられたＵＲＬを指定した、アプリケーションの起動指示を、端末装置１００内のブラウザ１１０に対して入力する。例えば、ユーザ２１に対応付けられたＵＲＬのショートカット（特定のＵＲＬに対応付けられたアイコン）を、ユーザ２１がポインタにより選択することで、アプリケーションの起動指示が入力される。
【００９４】
［ステップＳ１２］ブラウザ１１０は、入力されたＵＲＬを指定したＧＥＴリクエストをアプリケーションサーバ２００に送信する。
［ステップＳ１３］アプリケーションサーバ２００の文書提供部２２０は、ＧＥＴリクエストを受け取ると、指定されたＨＴＭＬ文書を記憶部２１０から取得する。そして文書提供部２２０は、ルートＵＲＬ判定部２３０に対してユーザルートＵＲＬ判定要求を送信する。
【００９５】
［ステップＳ１４］ルートＵＲＬ判定部２３０は、ユーザルートＵＲＬ判定要求に応じて、ユーザ２１に対応するユーザルートＵＲＬを判定する。例えばユーザ２１がユーザＩＤ「ＡＢ１２３４」で認証を受け、そのユーザＩＤに対応するエンドポイントＵＲＬを指定して、アプリケーションの起動指示を行った場合を想定する。この場合、ルートＵＲＬ判定部２３０は、ルートＵＲＬ管理テーブル２１３を参照し、ユーザＩＤ「ＡＢ１２３４」に対応するユーザルートＵＲＬを、ユーザ２１のユーザルートＵＲＬと判定する。
【００９６】
［ステップＳ１５］ルートＵＲＬ判定部２３０は、判定したユーザルートＵＲＬを文書提供部２２０に応答する。
［ステップＳ１６］文書提供部２２０は、ユーザルートＵＲＬを含むＨＴＭＬ文書を端末装置１００に応答する。
【００９７】
［ステップＳ１７］端末装置１００のブラウザ１１０は、アプリケーションサーバ２００からＨＴＭＬ文書を受信すると、そのＨＴＭＬ文書を評価する。すなわちブラウザ１１０は、ＨＴＭＬ文書の記述内容を解析する。そしてブラウザ１１０は、例えばオブジェクトの埋め込みを示すタグを検出する。
【００９８】
［ステップＳ１８］ブラウザ１１０は、ＨＴＭＬ文書からアプリケーションプログラム２１２を指定したオブジェクトの埋め込みのタグを検出すると、アプリケーションプログラム２１２のＧＥＴ要求をアプリケーションサーバ２００に送信する。
【００９９】
［ステップＳ１９］アプリケーションサーバ２００の文書提供部２２０は、アプリケーションプログラム２１２を記憶部２１０から取得する。そして文書提供部２２０は、アプリケーションプログラム２１２を端末装置１００に応答する。
【０１００】
［ステップＳ２０］端末装置１００のブラウザ１１０は、アプリケーションサーバ２００から送られたアプリケーションプログラム２１２を例えばＲＡＭ１０２に格納する。そしてブラウザ１１０は、ユーザルートＵＲＬをパラメータで指定したアプリケーションプログラム２１２の実行命令をＯＳに対して出力することで、アプリケーション１２０を起動する。
【０１０１】
［ステップＳ２１］起動されたアプリケーション１２０は、ユーザルートＵＲＬを指定して、データ格納サーバ３００に対してアプリケーション毎ＵＲＬリストの問い合わせを行う。
【０１０２】
［ステップＳ２２］データ格納サーバ３００のアプリケーション毎ＵＲＬ管理部３２０は、端末装置１００からの問い合わせに応じて、アプリケーション毎ＵＲＬリスト３１２を端末装置１００に応答する。
【０１０３】
［ステップＳ２３］端末装置１００のアプリケーション１２０は、取得したアプリケーション毎ＵＲＬリスト３１２から、自己のアプリケーション毎ＵＲＬを判断する。そしてアプリケーション１２０は、自己のアプリケーション毎ＵＲＬを、アプリケーション毎ＵＲＬ記憶部１２５に格納する。
【０１０４】
［ステップＳ２４］アプリケーション１２０は、初期画面のデータをブラウザ１１０に送信する。ブラウザ１１０は、ステップＳ１６で取得したＨＴＭＬ文書に応じた画面に、アプリケーション１２０の初期画面を埋め込み、モニタ１１に表示する（図１２参照）。
【０１０５】
［ステップＳ２５］モニタ１１の表示画面を見たユーザ２１は、キーボード１２やマウス１３を用いて、アプリケーション１２０に対してデータ処理の実行を指示する操作入力を行う。
【０１０６】
［ステップＳ２６］アプリケーション１２０は、ユーザ２１からの指示に応じてデータ処理を実行する。アプリケーション１２０は、ユーザ２１の個人データを使用する場合、アプリケーション毎ＵＲＬの後に、使用する個人データのアプリケーションローカルパスを繋げ、アクセス先ＵＲＬを生成する。
【０１０７】
［ステップＳ２７］アプリケーション１２０は、アクセス先ＵＲＬを指定して、データ格納サーバ３００にアクセスする。
［ステップＳ２８］データ格納サーバ３００のデータ管理部３３０は、アクセス先ＵＲＬに対するアクセスを行い、アクセス結果を端末装置１００に応答する。
【０１０８】
［ステップＳ２９］端末装置１００のアプリケーション１２０は、データ格納サーバ３００からアクセス結果の応答を受信すると、アクセス結果に応じたデータ処理を実行する。そしてアプリケーション１２０は、データ処理の結果を示すデータをブラウザ１１０に送信する。するとブラウザ１１０により、アプリケーションの処理結果を示す画面がモニタ１１に表示される（図１３参照）。
【０１０９】
このようにして、アプリケーション１２０は、データ格納サーバ３００に格納されたユーザ２１の個人データを使用して、データ処理を実行することができる。なおアプリケーション１２０は、アプリケーションサーバ２００から送られるユーザルートＵＲＬを含むＨＴＭＬ文書によって、ユーザルートＵＲＬを取得することができる。
【０１１０】
図１１は、ユーザルートＵＲＬを含むＨＴＭＬ文書の一例を示す図である。図１１に示すＨＴＭＬ文書３０では、<object>タグ３１によって、アプリケーション１２０の画像を埋め込むことが示されている。また、<param>タグ３２の「value」属性に、ユーザルートＵＲＬが設定されている。
【０１１１】
このようなＨＴＭＬ文書３０を取得したブラウザ１１０は、アプリケーションサーバ２００から、<object>タグ３１の「data」属性で指定されたアプリケーションプログラム２１２を取得する。またブラウザ１１０は、取得したアプリケーションプログラム２１２に基づいてアプリケーション１２０を起動する際に、<param>タグ３２の「value」属性に設定されたユーザルートＵＲＬを、パラメータとして指定する。
【０１１２】
アプリケーション１２０が起動されると、端末装置１００のモニタ１１には、アプリケーション１２０の初期画面が表示される。
図１２は、アプリケーションの初期画面の一例を示す図である。図１２の例は、スケジューラのアプリケーションを起動した場合の初期画面である。初期画面４０には、スケジュール表示対象の月のリストが表示されている。ユーザ２１がいずれかの月を選択すると、アプリケーション１２０はその月のユーザ２１のスケジュールの表示処理を行う。
【０１１３】
特定の月のユーザ２１のスケジュールを表示するために、アプリケーション１２０は、ユーザ２１のスケジュールが登録された個人データを読み出す。そのために、アプリケーション１２０は、アプリケーション毎ＵＲＬにアプリケーションローカルパスを追加したアクセス先ＵＲＬを生成し、そのアクセス先ＵＲＬに対してＧＥＴ要求を出力する。
【０１１４】
するとデータ格納サーバ３００から端末装置１００へ、ユーザ２１の一月分のスケジュールが格納されたファイルが送信される。アプリケーション１２０は、データ格納サーバ３００から送られたファイルからユーザ２１のスケジュールの情報を取得し、画面に表示する。
【０１１５】
図１３は、スケジュール表示画面の一例を示す図である。スケジュール表示画面４１には、指定された月（図１３の例では2010年12月）のユーザ２１のスケジュールが表示されている。
【０１１６】
このようにアプリケーションサーバ２００で提供されるアプリケーション１２０は、ユーザ２１の個人データについてはデータ格納サーバ３００から取得することができる。同様に他のアプリケーションサーバ２００−１，２００−２で提供されるアプリケーションについても、ユーザ２１の個人データについてはデータ格納サーバ３００から取得することができる。すなわち、ユーザ２１の個人データは、データ格納サーバ３００のみで管理することが可能となる。
【０１１７】
〔第３の実施の形態〕
次に第３の実施の形態について説明する。第３の実施の形態は、第１のアプリケーション実行形態、第３のユーザルートＵＲＬ取得方法、および第３のアプリケーション毎ＵＲＬ決定方法を組み合わせたものである。なお第３の実施の形態のシステム構成は、図３に示した第２の実施の形態のシステム構成と同様である。また第３の実施の形態の各装置の要素は、図５および図９に示した第２の実施の形態の要素と同じである。ただし、第３の実施の形態における少なくとも一部の要素については、第２の実施の形態と異なる処理を行う。そこで、図５に示した各要素の符号を用いて、第３の実施の形態の処理のうち、第２の実施の形態と異なる処理を説明する。
【０１１８】
図１４は、第３の実施の形態の処理手順の一例を示すシーケンス図である。なお、図１４に示す処理のうち、ステップＳ４１〜Ｓ５０，Ｓ５４〜Ｓ６０の処理は、それぞれ図１０に示した第２の実施の形態のステップＳ１１〜ステップＳ２０，Ｓ２３〜Ｓ２９の処理と同様である。そこで以下に、第２の実施の形態と異なるステップＳ５１〜ステップＳ５４の各処理についてステップ番号に沿って説明する。
【０１１９】
［ステップＳ５１］起動されたアプリケーション１２０は、ユーザルートＵＲＬと、アプリケーション１２０自身の識別子を指定して、データ格納サーバ３００に対してアプリケーション毎ＵＲＬの問い合わせを行う。アプリケーションの識別子は、例えばアプリケーション１２０を提供しているアプリケーションサーバ２００のドメイン名を含む文字列（http://app1.example.com/）である。
【０１２０】
［ステップＳ５２］データ格納サーバ３００のアプリケーション毎ＵＲＬ管理部３２０は、端末装置１００からの問い合わせに応じて、アプリケーション毎ＵＲＬを判定する。例えばアプリケーション毎ＵＲＬ管理部３２０は、ユーザ２１のアプリケーション毎ＵＲＬリスト３１２を参照し、問い合わせで指定されたアプリケーション１２０の識別子に対応するアプリケーション毎ＵＲＬを取得する。
【０１２１】
［ステップＳ５３］アプリケーション毎ＵＲＬ管理部３２０は、取得したアプリケーション毎ＵＲＬを端末装置１００に応答する。
［ステップＳ５４］端末装置１００のアプリケーション１２０は、取得したアプリケーション毎ＵＲＬを、アプリケーション毎ＵＲＬ記憶部１２５に格納する。
【０１２２】
このようにして、第３の実施の形態では、データ格納サーバ３００によってアプリケーション１２０に対応するアプリケーション毎ＵＲＬが特定される。第２の実施の形態と比較すると、データ格納サーバ３００から端末装置１００に応答される情報が、アプリケーション毎ＵＲＬリスト全体ではなく、その一部である特定のアプリケーション毎ＵＲＬのみとなる。これにより、通信のデータ量を少なくすることができる。
【０１２３】
〔第４の実施の形態〕
次に第４の実施の形態について説明する。第４の実施の形態は、第１のアプリケーション実行形態、第３のユーザルートＵＲＬ取得方法、および第１のアプリケーション毎ＵＲＬ決定方法を組み合わせたものである。なお第４の実施の形態のシステム構成は、図３に示した第２の実施の形態のシステム構成と同様である。また第４の実施の形態の端末装置とアプリケーションサーバとの要素は、図５および図９に示した第２の実施の形態の要素と同じである。ただし、第４の実施の形態における少なくとも一部の要素については、第２の実施の形態と異なる処理を行う。
【０１２４】
また第４の実施の形態のデータ格納サーバの要素は、第２の実施の形態と同様に記憶部とデータ管理部とを有するが、アプリケーション毎ＵＲＬ管理部は有していない。第４の実施の形態のデータ格納サーバの記憶部には、ユーザ２１の個人データを含む複数のファイルが格納されているが、アプリケーション毎ＵＲＬリストは格納されていない。
【０１２５】
このように、第４の実施の形態の各装置の要素は、図５に示した第２の実施の形態の要素に含まれている。そこで、図５に示した各要素の符号を用いて、第４の実施の形態の処理のうち、第２の実施の形態と異なる処理を説明する。
【０１２６】
図１５は、第４の実施の形態の処理手順の一例を示すシーケンス図である。なお、図１５に示す処理のうち、ステップＳ８１〜Ｓ９０，Ｓ９４〜Ｓ９６の処理は、それぞれ図１０に示した第２の実施の形態のステップＳ１１〜ステップＳ２０，Ｓ２７〜Ｓ２９の処理と同様である。そこで以下に、第２の実施の形態と異なるステップＳ９１〜ステップＳ９３の各処理についてステップ番号に沿って説明する。
【０１２７】
［ステップＳ９１］起動されたアプリケーション１２０は、データ格納サーバ３００に対するアプリケーション毎ＵＲＬリストの問い合わせは行わずに、初期画面のデータをブラウザ１１０に送信する。ブラウザ１１０は、ステップＳ８６で取得したＨＴＭＬ文書に応じた画面に、アプリケーション１２０の初期画面を埋め込み、モニタ１１に表示する。
【０１２８】
［ステップＳ９２］モニタ１１の表示画面を見たユーザ２１は、キーボード１２やマウス１３を用いて、アプリケーション１２０に対してデータ処理の実行を指示する操作入力を行う。
【０１２９】
［ステップＳ９３］アプリケーション１２０は、ルールベースでアクセス先ＵＲＬを生成する。すなわち、アプリケーション１２０には、アクセス先ＵＲＬ生成のルールが予め定義されている。例えば、アプリケーション１２０を一意に識別する文字列を生成し、生成した文字列をディレクトリ名としたパスを、ユーザルートＵＲＬの後ろに接続することが、ルールで定義される。アプリケーション１２０を一意に識別する文字列としては、例えば、アプリケーション１２０を提供しているアプリケーションサーバ２００のドメイン名を含む文字列である。
【０１３０】
このように、第４の実施の形態では、ルールベースでアプリケーション毎ＵＲＬを決定するため、データ格納サーバ３００においてアプリケーション毎ＵＲＬを管理せずに済む。また、アプリケーション１２０起動時に、端末装置１００とデータ格納サーバ３００との間でアプリケーション毎ＵＲＬリストの問い合わせやその応答の通信を行わずに済み、通信量を削減できる。
【０１３１】
〔第５の実施の形態〕
次に第５の実施の形態について説明する。第５の実施の形態は、第１のアプリケーション実行形態、第４のユーザルートＵＲＬ取得方法、および第２のアプリケーション毎ＵＲＬ決定方法を組み合わせたものである。
【０１３２】
図１６は、第５の実施の形態の各装置の機能の一例を示すブロック図である。端末装置１００ａは、ブラウザ１１０ａとアプリケーション１２０ａとを有している。ブラウザ１１０ａとアプリケーション１２０ａとは、図５に示した第２の実施の形態の端末装置１００の同名の要素と同じ機能を有している。またアプリケーション１２０ａは、ＯｐｅｎＩＤに基づいて、データ格納サーバ３００ａからアプリケーション実行の認可を受ける機能も有している。
【０１３３】
アプリケーションサーバ２００ａは、記憶部２１０ａと文書提供部２２０ａとを有している。記憶部２１０ａは、複数のＨＴＭＬ文書２１１，２１１ａ，２１１ｂ，・・・と、アプリケーション１２０ａが実行する処理が記載されたアプリケーションプログラム２１４とを記憶する。文書提供部２２０ａは、端末装置１００ａからの要求に応じて、ＨＴＭＬ文書やアプリケーションプログラム２１４を送信する。
【０１３４】
データ格納サーバ３００ａは、記憶部３１０ａ、アプリケーション毎ＵＲＬ管理部３２０ａ、データ管理部３３０ａ、および認証部３４０を有する。記憶部３１０ａ、アプリケーション毎ＵＲＬ管理部３２０ａ、およびデータ管理部３３０ａの機能は、図５に示した第２の実施の形態のデータ格納サーバ３００の同名の要素と同じ機能を有している。
【０１３５】
認証部３４０は、ＯｐｅｎＩＤによるユーザ認証機能を有している。認証部３４０は、例えばＩＤとパスワードとの組をクレデンシャルとして受け取り、そのクレデンシャルに基づいてユーザ認証を行う。認証部３４０は、正しいユーザであると認証できた場合、クレデンシャルの送信元に対して、認証成功の応答を行う。
【０１３６】
図１７は、第５の実施の形態の処理手順の一例を示すシーケンス図の前半である。以下、図１７に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］ユーザ２１は、アプリケーションサーバ２００ａのＵＲＬを指定した、アプリケーションの起動指示を、端末装置１００ａ内のブラウザ１１０ａに対して入力する。
【０１３７】
［ステップＳ１０２］ブラウザ１１０ａは、入力されたＵＲＬを指定したＧＥＴリクエストをアプリケーションサーバ２００ａに送信する。
［ステップＳ１０３］アプリケーションサーバ２００ａの文書提供部２２０ａは、ＧＥＴリクエストを受け取ると、指定されたＨＴＭＬ文書を記憶部２１０ａから取得する。そして文書提供部２２０ａは、取得したＨＴＭＬ文書を端末装置１００ａに応答する。
【０１３８】
［ステップＳ１０４］端末装置１００ａのブラウザ１１０ａは、アプリケーションサーバ２００ａからＨＴＭＬ文書を受信すると、そのＨＴＭＬ文書を評価する。
［ステップＳ１０５］ブラウザ１１０ａは、ＨＴＭＬ文書からアプリケーションプログラム２１４を指定したオブジェクトの埋め込みのタグを検出すると、アプリケーションプログラム２１４のＧＥＴ要求をアプリケーションサーバ２００ａに送信する。
【０１３９】
［ステップＳ１０６］アプリケーションサーバ２００ａの文書提供部２２０ａは、アプリケーションプログラム２１４を記憶部２１０ａから取得する。そして文書提供部２２０ａは、アプリケーションプログラム２１４を端末装置１００ａに応答する。
【０１４０】
［ステップＳ１０７］端末装置１００ａのブラウザ１１０ａは、アプリケーションサーバ２００ａから送られたアプリケーションプログラム２１４を例えばＲＡＭ１０２に格納する。そしてブラウザ１１０ａは、アプリケーションプログラム２１４の実行命令をＯＳに対して出力することで、アプリケーション１２０ａを起動する。
【０１４１】
［ステップＳ１０８］起動されたアプリケーション１２０ａは、ＯｐｅｎＩＤ入力画面のデータをブラウザ１１０ａに送信する。するとブラウザ１１０ａにより、ＯｐｅｎＩＤ入力画面がモニタ１１に表示される（図１８参照）。
【０１４２】
［ステップＳ１０９］ユーザ２１は、端末装置１００ａのアプリケーション１２０ａに対して、ユーザルートＵＲＬをＯｐｅｎＩＤとして入力する。
［ステップＳ１１０］アプリケーション１２０ａは、ＯｐｅｎＩＤとして入力されたユーザルートＵＲＬを記憶する。
【０１４３】
［ステップＳ１１１］アプリケーション１２０ａは、新たなウィンドウのポップアップでの表示を、ブラウザ１１０ａに指示する。ポップアップ表示を行うＯｐｅｎＩＤの認証技術としては、例えばＵＸ（User Experience） Extensionがある。
【０１４４】
［ステップＳ１１２］ブラウザ１１０ａは、リダイレクトでＯｐｅｎＩＤ画面要求をデータ格納サーバ３００ａに対して送信する。
［ステップＳ１１３］データ格納サーバ３００ａの認証部３４０は、ＯｐｅｎＩＤ画面要求に応答して、ログイン用ＨＴＭＬ文書を端末装置１００ａに応答する。端末装置１００ａのブラウザ１１０ａは、ログイン用ＨＴＭＬ文書に基づいて、ポップアップウィンドウによってログイン画面を表示する（図１９参照）。
【０１４５】
図１８は、ＯｐｅｎＩＤ入力画面の一例を示す図である。ＯｐｅｎＩＤ入力画面４２には、ＯｐｅｎＩＤ入力用のテキストボックス４２ａとＯＫボタン４２ｂとが表示されている。ユーザ２１は、テキストボックス４２ａにユーザルートＵＲＬを入力する。そしてユーザ２１は、マウス１３などを用いてＯＫボタン４２ｂを押下する。これにより、ＯｐｅｎＩＤとして、ユーザルートＵＲＬがアプリケーション１２０ａに渡される。
【０１４６】
その後、アプリケーション１２０ａからの要求に応じてブラウザ１１０ａがログイン用のウィンドウをポップアップ表示する。
図１９は、ポップアップ表示されたログインウィンドウの一例を示す図である。ログインウィンドウ４３には、ログインＩＤを入力するテキストボックス４３ａと、パスワードを入力するテキストボックス４３ｂとが表示されている。端末装置１００ａにこのような画面が表示された後、図２０に示す処理が行われる。
【０１４７】
図２０は、第５の実施の形態の処理手順の一例を示すシーケンス図の後半である。以下、図２０に示す処理をステップ番号に沿って説明する。
［ステップＳ１２１］ユーザ２１は、ログインウィンドウ４３に対してクレデンシャル（信用情報）を入力する。例えば、ユーザ２１は、ログインウィンドウ４３のテキストボックス４３ａに、データ格納サーバ３００ａに設定されているユーザ２１のＩＤを入力する。またユーザは、テキストボックス４３ｂにパスワードを入力する。入力されたＩＤとパスワードとの組が、ログイン用のクレデンシャルである。
【０１４８】
［ステップＳ１２２］端末装置１００ａのブラウザ１１０ａは、入力されたクレデンシャルをデータ格納サーバ３００ａに送信する。
［ステップＳ１２３］データ格納サーバ３００ａの認証部３４０は、クレデンシャルに基づいてユーザ２１の認証処理を行う。
【０１４９】
［ステップＳ１２４］認証部３４０は、ユーザ２１を正しく認証できた場合、認証成功のリダイレクト応答を端末装置１００ａに送信する。
［ステップＳ１２５］端末装置１００ａのブラウザ１１０ａは、認証成功のイベントをアプリケーション１２０ａに通知する。
【０１５０】
［ステップＳ１２６］アプリケーション１２０ａは、認証成功により、ステップＳ１０９で入力されたＯｐｅｎＩＤに含まれるユーザルートＵＲＬが、ユーザ２１の正しいユーザルートＵＲＬであると認識する。そこでアプリケーション１２０ａは、認識したユーザルートＵＲＬを指定して、データ格納サーバ３００ａに対してアプリケーション毎ＵＲＬリストを問い合わせる。
【０１５１】
以後のステップＳ１２７〜Ｓ１３４の処理は、それぞれ図１０に示す第２の実施の形態のステップＳ２２〜Ｓ２９の処理と同様である。
このようにして、ＯｐｅｎＩＤを用いて認証されたユーザルートＵＲＬを取得することができる。ＯｐｅｎＩＤを用いたことで、ユーザは、１つのクレデンシャルによって複数のアプリケーションの使用が可能となる。その結果、ユーザのクレデンシャルの管理負荷が軽減される。
【０１５２】
〔第６の実施の形態〕
次に第６の実施の形態について説明する。第６の実施の形態は、第３のアプリケーション実行形態、第２のユーザルートＵＲＬ取得方法、および第３のアプリケーション毎ＵＲＬ決定方法を組み合わせたものである。なお第６の実施の形態では、第２〜第５の実施の形態と異なり、アプリケーションサーバは用いられない。
【０１５３】
図２１は、第６の実施の形態の各装置の機能を示すブロック図である。端末装置１００ｂは、アプリケーション１２０ｂと記憶部１３０とを有する。アプリケーション１２０ｂは、予め端末装置１００ｂに導入されている。アプリケーション１２０ｂは、図９に示したアプリケーション１２０と同様の機能を有している。ただし第６の実施の形態に係るアプリケーション１２０ｂは、ブラウザを介さずにユーザルートＵＲＬの入力を受け付けると共に画面表示を行う。記憶部１３０は、データ格納サーバ３００ｂから取得したアプリケーション毎ＵＲＬ１３１を記憶する。
【０１５４】
データ格納サーバ３００ｂは、記憶部３１０ｂ、アプリケーション毎ＵＲＬ管理部３２０ｂ、およびデータ管理部３３０ｂを有する。データ格納サーバ３００ｂ内の各要素の機能は、図５に示した第２の実施の形態のデータ格納サーバ３００内の同名の要素と同じである。
【０１５５】
図２２は、第６の実施の形態の処理手順の一例を示すシーケンス図である。以下に、図２２に示す処理をステップ番号に沿って説明する。
［ステップＳ１４１］ユーザ２１が、アプリケーション１２０ｂの起動指示を端末装置１００ｂに対して入力する。
【０１５６】
［ステップＳ１４２］アプリケーション１２０ｂは、起動指示に応じて起動する。
［ステップＳ１４３］アプリケーション１２０ｂは、アプリケーション毎ＵＲＬをすでに保持しているか否かを確認する。
【０１５７】
［ステップＳ１４４］アプリケーション１２０ｂは、アプリケーション毎ＵＲＬを保持していない場合、ユーザルートＵＲＬ入力画面をモニタ１１に表示する（図２３参照）。
［ステップＳ１４５］ユーザ２１は、ユーザルートＵＲＬ入力画面に対して、ユーザルートＵＲＬを入力する。
【０１５８】
［ステップＳ１４６］端末装置１００ｂのアプリケーション１２０ｂは、入力されたユーザルートＵＲＬに基づいて、データ格納サーバ３００ｂに対してアプリケーション毎ＵＲＬリストの問い合わせを行う。
【０１５９】
［ステップＳ１４７］データ格納サーバ３００ｂのアプリケーション毎ＵＲＬ管理部３２０ｂは、端末装置１００ｂからの問い合わせに応じて、アプリケーション毎ＵＲＬリスト３１２を端末装置１００ｂに応答する。
【０１６０】
［ステップＳ１４８］端末装置１００ｂのアプリケーション１２０ｂは、取得したアプリケーション毎ＵＲＬリスト３１２から、自己のアプリケーション毎ＵＲＬを判断する。そしてアプリケーション１２０ｂは、自己のアプリケーション毎ＵＲＬを格納する。
【０１６１】
［ステップＳ１４９］ユーザ２１は、キーボード１２やマウス１３を用いて、アプリケーション１２０ｂに対してデータ処理の実行を指示する操作入力を行う。
［ステップＳ１５０］アプリケーション１２０ｂは、ユーザ２１からの指示に応じてデータ処理を実行する。アプリケーション１２０ｂは、ユーザ２１の個人データを使用する場合、アプリケーション毎ＵＲＬの後に、使用する個人データのアプリケーションローカルパスを繋げ、アクセス先ＵＲＬを生成する。
【０１６２】
［ステップＳ１５１］アプリケーション１２０ｂは、アクセス先ＵＲＬを指定して、データ格納サーバ３００ｂにアクセスする。
［ステップＳ１５２］データ格納サーバ３００ｂのデータ管理部３３０ｂは、アクセス先ＵＲＬに対するアクセスを行い、アクセス結果を端末装置１００ｂに応答する。
【０１６３】
［ステップＳ１５３］端末装置１００ｂのアプリケーション１２０ｂは、データ格納サーバ３００ｂからアクセス結果の応答を受信すると、アクセス結果に応じたデータ処理を実行する。そしてアプリケーション１２０ｂは、データ処理の結果を示す画面をモニタ１１に表示する。
【０１６４】
図２３は、ユーザルートＵＲＬ入力画面の一例を示す図である。ユーザルートＵＲＬ入力画面６０には、ユーザルートＵＲＬを入力するテキストボックス６１と、ＯＫボタン６２とが設けられている。ユーザ２１は、テキストボックス６１にユーザルートＵＲＬを入力し、ＯＫボタン６２を押下する。これにより、ユーザルートＵＲＬがアプリケーション１２０ｂに対して入力される。
【０１６５】
以上のようにして、予め端末装置１００ｂに導入されているアプリケーション１２０ｂが利用するユーザ２１の個人データを、データ格納サーバ３００ｂで管理することができる。
【０１６６】
〔第７の実施の形態〕
次に第７の実施の形態について説明する。第７の実施の形態は、第２のアプリケーション実行形態、第２のユーザルートＵＲＬ取得方法、および第２のアプリケーション毎ＵＲＬ決定方法を組み合わせたものである。
【０１６７】
図２４は、第７の実施の形態の各装置の機能を示すブロック図である。端末装置１００ｃは、ブラウザ１１０ｃを有している。ブラウザ１１０ｃは、図５に示した第２の実施の形態のブラウザ１１０と同様の機能を有している。
【０１６８】
アプリケーションサーバ２００ｃは、記憶部２１０ｃとアプリケーション２４０とを有している。
記憶部２１０ｃは、ルートＵＲＬ管理テーブル２１３を記憶する。アプリケーション２４０は、図９に示した第２の実施の形態のアプリケーション１２０と同様の機能を有している。ただし、ブラウザ１１０ｃとの間の通信は、ネットワーク１０を介して行われる。またアプリケーション２４０は、ユーザルートＵＲＬを、記憶部２１０ｃ内のルートＵＲＬ管理テーブル２１３から取得する。
【０１６９】
データ格納サーバ３００ｃは、記憶部３１０ｃ、アプリケーション毎ＵＲＬ管理部３２０ｃ、およびデータ管理部３３０ｃを有している。データ格納サーバ３００ｃの各要素は、図５に示した第２の実施の形態のデータ格納サーバ３００内の同名の要素と同じ機能を有している。
【０１７０】
図２５は、第７の実施の形態の処理手順の一例を示すシーケンス図である。以下、図２５に示す処理をステップ番号に沿って説明する。
［ステップＳ１６１］ユーザ２１は、アプリケーション２４０のＵＲＬを指定したログイン操作を、端末装置１００ｃのブラウザ１１０ｃによって表示されたログイン画面に対して行う（図２６参照）。
【０１７１】
［ステップＳ１６２］ブラウザ１１０ｃは、クレデンシャルをアプリケーションサーバ２００ｃに送信する。クレデンシャルは、例えばユーザのＩＤとパスワードとの組である。
【０１７２】
［ステップＳ１６３］アプリケーションサーバ２００ｃのアプリケーション２４０は、クレデンシャルを受け取ると、ユーザ認証を行う。そしてアプリケーション２４０は、ユーザ２１を正しく認証すると、ルートＵＲＬ管理テーブル２１３を参照し、ユーザ２１のユーザＩＤに対応するユーザルートＵＲＬを特定する。
【０１７３】
［ステップＳ１６４］アプリケーション２４０は、ユーザルートＵＲＬを指定して、データ格納サーバ３００ｃに対してアプリケーション毎ＵＲＬリストの問い合わせを行う。
［ステップＳ１６５］データ格納サーバ３００ｃのアプリケーション毎ＵＲＬ管理部３２０ｃは、アプリケーションサーバ２００ｃからの問い合わせに応じて、アプリケーション毎ＵＲＬリスト３１２をアプリケーションサーバ２００ｃに応答する。
【０１７４】
［ステップＳ１６６］アプリケーションサーバ２００ｃのアプリケーション２４０は、取得したアプリケーション毎ＵＲＬリスト３１２から、自己のアプリケーション毎ＵＲＬを判断する。
【０１７５】
［ステップＳ１６７］アプリケーション２４０は、自己のアプリケーション毎ＵＲＬを、端末装置１００ｃとの間の通信のセッションに対応付けて記憶する。
［ステップＳ１６８］アプリケーション２４０は、セッションクッキー付きＨＴＭＬ文書を端末装置１００ｃに送信する。すると、端末装置１００ｃのブラウザ１１０ｃがアプリケーション２４０の画面をモニタ１１に表示する。
【０１７６】
［ステップＳ１６９］モニタ１１の表示画面を見たユーザ２１は、キーボード１２やマウス１３を用いて、アプリケーション２４０の操作指示を、ブラウザ１１０ｃに対して入力する。
【０１７７】
［ステップＳ１７０］ブラウザ１１０ｃは、ユーザ２１からの操作入力に応答し、セッションクッキー付きＨＴＴＰリクエストをアプリケーションサーバ２００ｃに送信する。
［ステップＳ１７１］アプリケーションサーバ２００ｃのアプリケーション２４０は、リクエストに応じたデータ処理を実行する。そしてアプリケーション２４０は、ユーザ２１の個人データを使用する場合、端末装置１００ｃとの間の通信のセッションに対応付けられたアプリケーション毎ＵＲＬを取得する。
【０１７８】
［ステップＳ１７２］アプリケーション２４０は、アプリケーション毎ＵＲＬの後に、アプリケーションローカルパスを接続したアクセス先ＵＲＬを生成する。
［ステップＳ１７３］アプリケーション２４０は、アクセス先ＵＲＬを指定して、データ格納サーバ３００ｃにアクセスする。
【０１７９】
［ステップＳ１７４］データ格納サーバ３００ｃのデータ管理部３３０ｃは、アクセス先ＵＲＬに対するアクセスを行い、アクセス結果をアプリケーションサーバ２００ｃに応答する。
【０１８０】
［ステップＳ１７５］アプリケーションサーバ２００ｃのアプリケーション２４０は、データ格納サーバ３００ｃからアクセス結果の応答を受信すると、アクセス結果に応じたデータ処理を実行する。そしてアプリケーション２４０は、データ処理の結果を示すデータを端末装置１００ｃに送信する。すると端末装置１００ｃのブラウザ１１０ｃにより、アプリケーションの処理結果を示す画面がモニタ１１に表示される。
【０１８１】
図２６は、ログイン画面の一例を示す図である。ログイン画面５０には、ログインＩＤ入力用のテキストボックス５１、パスワード入力用のテキストボックス５２、およびＯＫボタン５３が設けられている。ユーザ２１は、テキストボックス５１にユーザＩＤを入力し、テキストボックス５２にパスワードを入力する。そしてユーザ２１がＯＫボタン５３２を押下すると、ユーザＩＤとパスワードとの組によるクレデンシャルがアプリケーションサーバ２００ｃに渡される。すると、ユーザＩＤに関連づけられたユーザルートＵＲＬがアプリケーションサーバ２００ｃで特定される。
【０１８２】
このようにして、アプリケーションサーバ２００ｃで動作するアプリケーション２４０が使用するユーザ２１の個人データを、データ格納サーバ３００ｃで管理することができる。
【０１８３】
〔その他の実施の形態〕
上記の実施の形態では、第１のユーザルートＵＲＬ取得方法について説明していないが、第１のユーザルートＵＲＬ取得方法は、第２のユーザルートＵＲＬ取得方法の処理過程で実施されている。例えば図２２に示した第６の実施の形態のシーケンス図におけるステップＳ１４４，Ｓ１４５の処理が、第１のユーザルートＵＲＬ取得方法の処理である。
【０１８４】
なお、上記の各実施の形態に示した処理機能は、コンピュータによって実現することができる。その場合、端末装置、アプリケーションサーバ、およびデータ格納サーバのそれぞれが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ／ＲＷなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disc）などがある。
【０１８５】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１８６】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１８７】
また、上記の処理機能の少なくとも一部を、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現することもできる。
【０１８８】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【０１８９】
上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。
【符号の説明】
【０１９０】
１  情報処理装置
１ａ  データ処理手段
１ｂ  位置情報取得手段
１ｃ  位置情報生成手段
１ｄ  記憶手段
１ｅ  アクセス先情報生成手段
１ｆ  アクセス手段
２  入力装置
３  データ格納装置
４  第１のアクセス先情報
５  第１の位置情報
６  第２の位置情報
７  第２のアクセス先情報
８  アクセス結果
９  ユーザ
【図１】
2012077223.tif 000003
【図２】
2012077223.tif 000004
【図３】
2012077223.tif 000005
【図４】
2012077223.tif 000006
【図５】
2012077223.tif 000007
【図６】
2012077223.tif 000008
【図７】
2012077223.tif 000009
【図８】
2012077223.tif 000010
【図９】
2012077223.tif 000011
【図１０】
2012077223.tif 000012
【図１１】
2012077223.tif 000013
【図１２】
2012077223.tif 000014
【図１３】
2012077223.tif 000015
【図１４】
2012077223.tif 000016
【図１５】
2012077223.tif 000017
【図１６】
2012077223.tif 000018
【図１７】
2012077223.tif 000019
【図１８】
2012077223.tif 000020
【図１９】
2012077223.tif 000021
【図２０】
2012077223.tif 000022
【図２１】
2012077223.tif 000023
【図２２】
2012077223.tif 000024
【図２３】
2012077223.tif 000025
【図２４】
2012077223.tif 000026
【図２５】
2012077223.tif 000027
【図２６】
2012077223.tif 000028
【手続補正書】
【提出日】平成25年6月7日(2013.6.7)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】変更
【補正の内容】
【００１１】
【図１】第１の実施の形態に係る情報処理装置の機能構成例を示す図である。
【図２】第１の実施の形態に係る情報処理装置の処理手順を示すフローチャートである。
【図３】第２の実施の形態のシステム構成例を示す図である。
【図４】第２の実施の形態に用いる端末装置のハードウェアの一構成例を示す図である。
【図５】第２の実施の形態の各装置の機能を示すブロック図である。
【図６】ルートＵＲＬ管理テーブルのデータ構造の一例を示す図である。
【図７】データ格納サーバの記憶部内のディレクトリ構造の一例を示す図である。
【図８】アプリケーション毎ＵＲＬリストのデータ構造の一例を示す図である。
【図９】アプリケーションの機能の一例を示すブロック図である。
【図１０】第２の実施の形態の処理手順を示すシーケンス図である。
【図１１】ユーザルートＵＲＬを含むＨＴＭＬ文書の一例を示す図である。
【図１２】アプリケーションの初期画面の一例を示す図である。
【図１３】スケジュール表示画面の一例を示す図である。
【図１４】第３の実施の形態の処理手順の一例を示すシーケンス図である。
【図１５】第４の実施の形態の処理手順の一例を示すシーケンス図である。
【図１６】第５の実施の形態の各装置の機能の一例を示すブロック図である。
【図１７】第５の実施の形態の処理手順の一例を示すシーケンス図の前半である。
【図１８】ＯｐｅｎＩＤ入力画面の一例を示す図である。
【図１９】ポップアップ表示されたログインウィンドウの一例を示す図である。
【図２０】第５の実施の形態の処理手順の一例を示すシーケンス図の後半である。
【図２１】第６の実施の形態の各装置の機能を示すブロック図である。
【図２２】第６の実施の形態の処理手順の一例を示すシーケンス図である。
【図２３】ユーザルートＵＲＬ入力画面の一例を示す図である。
【図２４】第７の実施の形態の各装置の機能を示すブロック図である。
【図２５】第７の実施の形態の処理手順の一例を示すシーケンス図である。
【図２６】ログイン画面の一例を示す図である。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１６
【補正方法】変更
【補正の内容】
【００１６】
図１は、第１の実施の形態に係る情報処理装置の機能構成例を示す図である。情報処理装置１は、データ処理手段１ａ、位置情報取得手段１ｂ、位置情報生成手段１ｃ、記憶手段１ｄ、アクセス先情報生成手段１ｅ、およびアクセス手段１ｆを有している。また、情報処理装置１で処理される情報には、例えば第１のアクセス先情報４、第１の位置情報５、第２の位置情報６、第２のアクセス先情報７、およびアクセス結果８がある。これらの情報は、情報処理装置１で処理される情報の一例である。また図１では、情報処理装置１の処理手段と情報とを区別するため、情報は破線の矩形で示している。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００３６
【補正方法】変更
【補正の内容】
【００３６】
＜第２のアプリケーション実行形態＞
第２のアプリケーション実行形態は、アプリケーションをサーバで実行する形態である。第２のアプリケーション実行形態では、例えばサーバから端末装置のブラウザに、画面描画指示（ＨＴＭＬ（HyperText Markup Language）文書の表示指示）が送信され、端末装置において画面表示が行われる。表示された画面に対してユーザが操作入力を行うと、操作内容に応じてブラウザがＨＴＴＰ（HyperText Transfer Protocol）リクエストをサーバに送信する。サーバで実行されているアプリケーションは、端末装置からのＨＴＴＰリクエストに応じてデータ処理を実行し、実行結果を含む画面描画指示を端末装置に送信する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００７３
【補正方法】変更
【補正の内容】
【００７３】
なお、図６の例示では、ユーザＩＤ「ＡＢ１２３４」に対応するエンドポイントＵＲＬは、「http://app1.example/?userUrl=http%253A%252F%252Fdata.example%252Fshimono」である。このエンドポイントＵＲＬは、「http://app1.example/」というＵＲＬで特定される文書提供部２２０が「userUrl」というパラメータの値として「http://api.data.example/user1/」というユーザルートＵＲＬを受け取ることを示している。文書提供部２２０は、エンドポイントＵＲＬを指定したリクエストに対する応答の中で、受け取ったＵＲＬ「http://api.data.example/user1」を、アプリケーション１２０に設定するユーザルートＵＲＬとして返す。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００７８
【補正方法】変更
【補正の内容】
【００７８】
次に、データ格納サーバ３００の記憶部３１０内のディレクトリ構造について説明する。
図７は、データ格納サーバの記憶部内のディレクトリ構造の一例を示す図である。記憶部３１０には、データ格納サーバ３００のＯＳが有するファイルシステムにより、階層的なディレクトリ構造でファイルが格納されている。図７の例では、最上位の「root」のディレクトリ３１３の配下にディレクトリ名「user1」のディレクトリ３１４が設けられている。ディレクトリ名「user1」のディレクトリ３１４は、ユーザ２１の個人データ用に設けられたディレクトリである。
【手続補正６】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ユーザからの要求に応じてデータ処理を実行し、該ユーザの個人データにアクセスする場合、基準位置から該個人データを含むファイルまでディレクトリ構造を辿ったときの経路および該ファイルのファイル名を示す第１のアクセス先情報を生成するデータ処理手段と、
ユーザ指定のデータ格納装置の識別情報および該データ格納装置内のユーザ指定のディレクトリの位置を示す第１の位置情報を取得する位置情報取得手段と、
前記第１の位置情報に基づいて、前記ユーザ指定のディレクトリ配下の、前記データ処理手段に一意に割り当てられたディレクトリの位置を示す第２の位置情報を生成する位置情報生成手段と、
前記第１のアクセス先情報と前記第２の位置情報とに基づいて、前記第２の位置情報で示される位置を基準位置とした場合の前記アクセス対象のデータを含むファイルの格納位置および該ファイルのファイル名を示す第２のアクセス先情報を生成するアクセス先情報生成手段と、
前記第２のアクセス先情報に基づいて、前記データ格納装置内の前記アクセス対象のデータを含むファイルにアクセスするアクセス手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記位置情報生成手段は、前記情報処理装置で実行可能な複数のデータ処理手段それぞれに対して一意に割り当てられた、前記ユーザ指定のディレクトリ配下のディレクトリの位置が設定されたアプリケーション毎ＵＲＬリストを取得し、該アプリケーション毎ＵＲＬリストから、前記ユーザからの要求に応じてデータ処理を実行しているデータ処理手段に一意に割り当てられたディレクトリの位置を抽出することを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記位置情報生成手段は、前記アプリケーション毎ＵＲＬリストを、前記データ格納装置から取得することを特徴とする請求項２記載の情報処理装置。
【請求項４】
前記位置情報生成手段は、前記データ格納装置に対して、前記データ処理手段の識別子を付加した位置情報取得要求を送信し、前記データ格納装置から、前記データ処理手段に一意に割り当てられたディレクトリの位置を取得することを特徴とする請求項１記載の情報処理装置。
【請求項５】
前記位置情報生成手段は、予め設定されたルールに従って、前記データ処理手段に一意に割り当てられたディレクトリの位置を示す第２の位置情報を取得することを特徴とする請求項１記載の情報処理装置。
【請求項６】
前記位置情報取得手段は、前記データ処理手段が実行する処理の内容が記述されたプログラムを格納する装置に、前記ユーザを特定する情報を付加して該プログラムの取得要求を送信し、該プログラムと共に該装置から応答された前記第１の位置情報を取得することを特徴とする請求項１乃至５のいずれかに記載の情報処理装置。
【請求項７】
前記位置情報取得手段は、前記ユーザの認証手段を有する装置から、前記ユーザの認証時に前記第１の位置情報を取得することを特徴とする請求項１乃至５のいずれかに記載の情報処理装置。
【請求項８】
前記位置情報取得手段は、前記ユーザにより入力された前記第１の位置情報を取得することを特徴とする請求項１乃至５のいずれかに記載の情報処理装置。
【請求項９】
前記位置情報取得手段は、ネットワークを介して接続された端末装置から、前記ユーザから操作入力された前記第１の位置情報を取得することを特徴とする請求項８記載の情報処理装置。
【請求項１０】
コンピュータに、
ユーザ指定のデータ格納装置の識別情報および該データ格納装置内のユーザ指定のディレクトリの位置を示す第１の位置情報を取得し、
前記第１の位置情報に基づいて、前記ユーザ指定のディレクトリ配下の、所定のデータ処理に一意に割り当てられたディレクトリの位置を示す第２の位置情報を生成し、
ユーザからの要求に応じて前記データ処理を実行し、該ユーザの個人データにアクセスする場合、基準位置から該個人データを含むファイルまでディレクトリ構造を辿ったときの経路および該ファイルのファイル名を示す第１のアクセス先情報を生成し、
前記第１のアクセス先情報と前記第２の位置情報とに基づいて、前記第２の位置情報で示される位置を基準位置とした場合の前記アクセス対象のデータを含むファイルの格納位置および該ファイルのファイル名を示す第２のアクセス先情報を生成し、
前記第２のアクセス先情報に基づいて、前記データ格納装置内の前記アクセス対象のデータを含むファイルにアクセスする、
処理を実行させることを特徴とするプログラム。
【国際調査報告】
2012077223.tif 000029
2012077223.tif 000030
2012077223.tif 000031
2012077223.tif 000032