Patent Description:
Cloud computing is known as a type of services allowing users to utilize computing resources available on a network of servers, as needed, with their terminal devices and network connections. The available computer resources include, for example, data processing functions that are realized by executing application programs on a computer. Such data processing functions are referred to herein as "applications". A variety of applications are provided by many servers on the Internet. The users make access to different servers from their terminal devices, depending on what application services to use to achieve their respective purposes.

In relation to the provision of services to users, the servers may be configured to hold personal data of the users, so as to allow an application to use such data during its execution. One of the benefits of letting servers manage users' personal data is that the users can receive personalized services wherever they are. The personal data of users may include, for example, documents that they edited, attribute data (e.g., name and residence address) of individuals, and information about the environment in which they use applications (e.g., mail server name, mail address, password).

The servers on the network manage such personal data of users, and various useful techniques may be applied for this purpose. For example, one proposed system is designed to deliver data files to a requesting client terminal in encrypted form by using a cryptographic key associated with that client terminal. In this system, the client terminal can decode encrypted data files with a decryption key only if the client terminal is authenticated as the rightful destination of the files. Another proposed technique permits an application system to use a plurality of different databases in a unified manner.

Yet another proposed system is designed to map a first uniform resource locator (URL) for a file of a first protocol server to a second URL for the file of a second protocol server. Finally, another proposed technique maps access to a set of applications associated with a universal resource locator in a data processing system.

Some users may use a plurality of applications provided in different servers. This means, however, that their personal data is distributed across a plurality of servers. The users are more burdened with the management of their personal data in those servers.

According to one aspect, it is an object of the present invention to provide an information processing apparatus and program that facilitate management of personal data of users which is used by applications.

The object of the invention is solved by the subject matter of the independent claims. Advantageous embodiments are disclosed in the dependent claims.

The invention make it easier to manage personal data of a user in a user-specified data storage device, for use in data processing operations.

The above and other objects, features and advantages of the present invention will become apparent from the following description when taken in conjunction with the accompanying drawings which illustrate preferred embodiments of the present invention by way of example.

Several embodiments will be described below with reference to the accompanying drawings. These embodiments may be combined with each other as long as there are no contradictions between them.

The first reference technology described in this section is designed to manage personal data of a user centrally in a single place specified by the user, while allowing him or her to use applications provided in a plurality of servers. This feature of the first reference technology makes it easier for the user to manage his or her personal data, despite the use of applications in multiple servers.

The services provided in the Internet and the like are expected to have a continuing growth. This means in general that the personal data of a single user is managed separately in a plurality of servers that he or she uses.

That is, private information of a single person may be distributed across so many places that the management of such data could get out of hand because of its increased burden on the person. People have to search all the servers they are using when they happen to forget which server stores a particular piece of their personal data. Further, most servers on a wide-area network such as the Internet implement a user authentication procedure to confirm the authenticity of users before accepting their requests. This feature may degrade the usability of servers because the users have to go through the authentication procedure at each server from which they are trying to retrieve desired data. The users have also to bear a burden of managing varieties of authentication data (e.g., different pairs of user name and password) to use servers.

In view of the above, the first reference technology provides features for managing personal data of users centrally at a single server to alleviate their burden. When a user uses a plurality of applications, and if those applications store their respective data in a single directory, the shared use of the directory could lead to a conflict of data storage locations. That is, one application may overwrite an existing data location (e.g., files) created by some other application. This kind of conflict could arise when two or more applications happen to create files with the same name. The first reference technology therefore provides a function of preventing such conflict of data storage locations. This function realizes unified management of personal data with a single data storage device while allowing a plurality of applications to use the data.

<FIG> illustrates an exemplary functional structure of an information processing apparatus according to the first reference technology. The illustrated information processing apparatus <NUM> includes a data processing means 1a, a location information obtaining means 1b, a location information producing means 1c, a storage means 1d, an access target information producing means 1e, and an access means 1f. This information processing apparatus <NUM> handles, for example, first access target information <NUM>, first location information <NUM>, second location information <NUM>, second access target information <NUM>, and access result <NUM>. These pieces of information are only an example of what is processed by the information processing apparatus <NUM>. <FIG> uses broken-line boxes to represent such information, as opposed to processing means in the information processing apparatus <NUM>.

The data processing means 1a performs data processing operations requested by the user <NUM>. For example, the user <NUM> may enter a data processing request to the data processing means 1a through an input device <NUM>. The data processing means 1a may also make access to personal data of the user <NUM>. To this end, the data processing means 1a produces first access target information <NUM> that indicates a path and name of a target data file containing the personal data, where the path points to the target data file by following the directory structure from a specific reference location.

It is noted here that the term "file" used in this description does not only refer to an individual data file in a file system. Rather, the term "file" may broadly refer to a data resource, or a single segment of storage areas for writing or reading data, such as a row of data in a database system.

It is also noted that the terms "directory" and "directory structure" used in this description does not only refer to a location of files in the file system of a single computer. Rather, the terms "directory" and "directory structure" broadly refer to information representing a hierarchical arrangement and reference structure of files, as in the Uniform Resource Locator (URL), or the identifier indicating the global location of a file in a multiple-computer environment.

The location information obtaining means 1b obtains first location information <NUM> indicating an identifier of a data storage device <NUM> specified by the user and the location, within the data storage device <NUM>, of a user-specified directory specified by the user. For example, the location information obtaining means 1b receives first location information <NUM> that the user <NUM> enters through the input device <NUM>.

Based on the first location information <NUM>, the location information producing means 1c produces second location information <NUM> indicating the location of a directory that is placed below the user-specified directory and uniquely assigned to the data processing means 1a. For example, the location information producing means 1c gives a unique name to the data processing means 1a and appends the produced unique name to the first location information <NUM>. Here the unique name serves as the directory name of a directory placed below the user-specified directory. By appending the unique name of the data processing means 1a to the first location information <NUM>, the location information producing means 1c produces second location information <NUM>. The location information producing means 1c enters this second location information <NUM> in the storage means 1d, for example.

The storage means 1d stores the second location information <NUM>.

The access target information producing means 1e produces second access target information <NUM>, based on the first access target information <NUM> and second location information <NUM>. Here the location indicated by the second location information <NUM> is used as the reference location mentioned above. The second access target information <NUM> indicates the storage location and name of the target data file. For example, the access target information producing means 1e retrieves the second location information <NUM> from the storage means 1d and then appends the first access target information <NUM> to the retrieved second location information <NUM>, thereby producing second access target information <NUM>. The access target information producing means 1e passes the produced second access target information <NUM> to the access means 1f.

Based on the second access target information <NUM>, the access means 1f makes access to the target data file in the data storage device <NUM> and passes its access result <NUM> back to the data processing means 1a. For example, what the data processing means 1a is doing to the personal data may be a data write operation or a data read operation. In the case of a data write operation, the access means 1f executes it by writing new data to the target data file in the data storage device <NUM> and returns a write completion notice to the data processing means 1a as an access result <NUM>. In the case of a data read operation, the access means 1f executes it by reading data from the target data file in the data storage device <NUM> and passes the read data to the data processing means 1a as an access result <NUM>.

<FIG> is a flowchart illustrating operation of the information processing apparatus according to the first reference technology. Each step in <FIG> is described below in the order of step numbers.

(Step S1) It is supposed that the user has specified a data storage device <NUM> and a particular directory in the data storage device <NUM>. The location information obtaining means 1b obtains first location information <NUM> that indicates the identifier of the user-specified data storage device <NUM> and the location of the user-specified directory. In the example of <FIG>, the location information obtaining means 1b obtains "//api. example/user1/" as the first location information <NUM>. This first location information <NUM> is formed from "api. example" and "/user1/", the former part being the identifier of the user-specified data storage device <NUM> and the latter part being the location of the user-specified directory.

(Step S2) Based on the first location information <NUM>, the location information producing means 1c produces second location information <NUM> that indicates the location of a directory placed below the user-specified directory. This directory is uniquely assigned to the data processing means 1a. In the foregoing example of <FIG>, the second location information <NUM> reads "//api. example/user1/app1/". This second location information <NUM> has been produced by appending a directory name "app1/" to the first location information <NUM> obtained above.

(Step S3) The data processing means 1a executes data processing operations requested by the user <NUM>.

(Step S4) The data processing means 1a determines whether the data processing operations requested by the user <NUM> have been finished. For example, the end of data processing operations may be indicated explicitly by the requesting user <NUM>. The data processing means 1a may also recognize the end of data processing operations when all scheduled operations are finished. This is applied to a class of data processing that can be executed without the need for interaction with the user <NUM>. The process of <FIG> is terminated when the requested data processing operations are found to be done. When the requested operations are still under way, the data processing means 1a advances the process to step S5.

(Step S5) The data processing means 1a determines whether there is a need for access to personal data of the user <NUM>. When there is such a need for access, the data processing means 1a produces first access target information <NUM> that indicates a path and name of a target data file containing desired personal data, so that the file is reached by following the directory structure from a specific reference location. The produced first access target information <NUM> reads "/data/file1" in the example of <FIG>, which indicates that the access is directed to a target data file named "file1" in a directory named "/data". The process of <FIG> then proceeds to step S6. When there is no need for access to the user's personal data, the data processing means 1a goes back to step S3.

(Step S6) The access target information producing means 1e produces second access target information <NUM> based on the first access target information <NUM> and second location information <NUM>. For example, the access target information producing means 1e appends the first access target information <NUM> to the second location information <NUM>, thereby producing second access target information <NUM>. Referring again to the example of <FIG>, the resulting second access target information <NUM> reads "//api. example/user1/app1/data/file1".

(Step S7) Based on the second access target information <NUM> produced above, the access means 1f makes access to the target data file in the data storage device <NUM> and passes its access result <NUM> back to the data processing means 1a. The access means 1f goes back to step S3.

The above-described steps permit the information processing apparatus <NUM> to make access to personal data of the user <NUM> which resides in a directory that is located below the directory specified by the first location information <NUM> and uniquely associated with the data processing means 1a. The user <NUM> may use a plurality of data processing means by entering the same first location information <NUM> to them. The personal data of the user <NUM> in the data storage device <NUM> is managed separately in different directories uniquely associated with different data processing means, so that those data processing means refer to their respective sets of personal data.

For example, the user <NUM> may use a plurality of applications provided by many servers on the network. Each of those applications acts as the data processing means 1a discussed in <FIG>, which uses personal data of the user <NUM> managed in the data storage device <NUM>.

The above features enable the user <NUM> to handle his or her own personal data easily because the data is consolidated and managed in a single data storage device <NUM>.

The above-described data processing means 1a, location information obtaining means 1b, location information producing means 1c, access target information producing means 1e, and access means 1f may be implemented as functions performed by a central processing unit (CPU) in the information processing apparatus <NUM>. The storage means 1d, on the other hand, may be implemented as a data storage medium such as random access memory (RAM) or hard disk drive (HDD) in the information processing apparatus <NUM>.

The above-described first and second location information may take the form of URLs, for example. Accordingly, the following description uses the terms "user root URL" and" "application-specific URL" to refer respectively to the first location information and second location information discussed in the first reference technology. The following description also uses the terms "application local path" and "access target URL" to denote the first access target information and second access target information, respectively.

For example, a single application may be provided to embody the data processing means 1a, location information obtaining means 1b, location information producing means 1c, storage means 1d, access target information producing means 1e, and access means 1f in the information processing apparatus <NUM> of <FIG>. This application may be executed in, for example, one of the following three modes.

In the first application execution mode, a terminal device downloads an appropriate program from a server to a terminal device each time a need arises for some functions of a particular application. The terminal device executes the application with the downloaded program.

In the second application execution mode, applications are executed on servers. For example, a server sends drawing commands (e.g., commands for displaying a HyperText Markup Language (HTML) document) to browser software running on a terminal device, so that a page is displayed on the terminal screen. The user may do some operations on the displayed screen, which causes the browser to transmit a HyperText Transfer Protocol (HTTP) request to the server. The application running on the server executes data processing operations in response to the HTTP request from the terminal device and transmits drawing commands back to the terminal device to display the execution result.

In the third application execution mode, applications are previously installed in terminal devices. The user sets up an application program in a storage medium of his or her terminal device, so that the application is ready to run. For example, the user interacts with the terminal device to install an application in an executable state.

Applications are executed in one of the above three execution modes. Such applications may obtain a user root URL by using one of the following four methods.

The first method provides a display screen to prompt the user to enter his or her user root URL and obtains a URL entered through the screen.

The second method permits the user to enter his or her user root URL at a convenient time, and stores the entered URL in an appropriate storage space for future reference by the applications. This method actually use the above first method to obtain a user root URL for the first time. The obtained user root URL is then stored in an appropriate storage space.

The third method obtains a user root URL from a server simultaneously with downloading of an application program. For example, a server prepares endpoint URLs corresponding to individual users, so that the users receive a document personalized for them when they make access to their corresponding endpoint URLs. The endpoint URL prepared for a user by the server may also be accessed from the terminal device of the user when he or she wishes to use an application on the server. In response, the server sends a relevant application program back to the requesting terminal device, together with a user root URL that is previously associated with the endpoint URL.

The fourth method utilizes OpenID, an identifier for authentication applicable to multiple websites, to obtain user root URLs. A single OpenID enables its owner to be authenticated at a plurality of websites. For one example of the fourth method, a website managing OpenID notifies an application of a user root URL. An OpenID may include information on the user root URL of a user, and the user logs in to an application by using such an OpenID. The application obtains the user root URL from the log-in OpenID that the user has used.

An application-specific URL is determined by obtaining a path (directory names etc) that uniquely identifies an application under a given user root URL. This operation may be achieved with, for example, one of the following three methods.

The first method determines an access target URL according to a rule base. For example, a rule base is defined as a set of rules for generating directory names that uniquely identify each different application. The application produces an application-specific URL for a specific application by appending such directory names of the application to the given user root URL in accordance with the rule base.

The second method relies on an application-specific URL list prepared in a server corresponding to a user root URL. This application-specific URL list is a collection of application-specific URLs associated with the identifiers of applications. When a specific user root URL is given, its corresponding server provides an application-specific URL list to the application. The application then obtains its own application-specific URL from the application-specific URL list. Such application-specific URL lists may be access-restricted. For example, the server may request transmission of an authentication token from applications each time they try to use the server's application-specific URL list. Authentication tokens may comply with, for example, the OAuth protocol, which transfers authentication of Application Programming Interface (API) access. The server performs user authentication based on the received authentication token.

The third method involves querying from an application to a server corresponding the given user root URL, as to an application-specific URL relevant to the application. The third method may also use the aforementioned authentication tokens or the like for a server to restrict queries about application-specific URLs.

The above-described three application execution modes, four methods for obtaining user root URLs, and three methods for determining application-specific URLs may be combined in various ways. It is therefore possible to provide a variety of embodiments based on such combinations. The following sections will describe in detail some of those possible embodiments.

This section describes a second reference technology. The second reference technology implements a combination of the foregoing first application execution mode, third method for obtaining user root URLs, and second method for determining application-specific URLs.

<FIG> illustrates an exemplary system configuration according to the second reference technology. The illustrated network <NUM> interconnects a terminal device <NUM>, a plurality of application servers <NUM>, <NUM>-<NUM>, and <NUM>-<NUM>, and a data storage server <NUM>. The terminal device <NUM> is a computer through which a user <NUM> interacts with the system.

The application servers <NUM>, <NUM>-<NUM>, and <NUM>-<NUM> are computers configured to offer services with their own applications. Using his or her terminal device <NUM>, the user <NUM> makes access to one of those application servers <NUM>, <NUM>-<NUM>, and <NUM>-<NUM> to request and receive a desired service.

The data storage server <NUM> is a computer configured to store personal data of the user <NUM>. Specifically, the data storage server <NUM> stores personal data of the user <NUM>, which may be used by different applications that the application servers <NUM>, <NUM>-<NUM>, and <NUM>-<NUM> provide.

In the illustrated network <NUM>, the application servers <NUM>, <NUM>-<NUM>, and <NUM>-<NUM> and data storage server <NUM> are distinguished from each other by their domain names. In the example of <FIG>, the three application servers <NUM>, <NUM>-<NUM>, and <NUM>-<NUM> have domain names of "app1. com", "app2. example", and "app3. example", respectively. The data storage server <NUM> has a domain name of "api. data-service.

The above devices on the network <NUM> communicate with each other according to, for example, the HTTP or the HTTP over Secure Socket Layer (HTTPS).

<FIG> illustrates an exemplary hardware configuration of a terminal device used in the second reference technology. The illustrated terminal device <NUM> has a CPU <NUM> to control the entire device. The CPU <NUM> is connected to a RAM <NUM> and other various devices and interfaces via a bus <NUM>.

The RAM <NUM> serves as primary storage of the terminal device <NUM>. Specifically, the RAM <NUM> is used to temporarily store at least some of the operating system (OS) programs and application programs that the CPU <NUM> executes, in addition to other various data objects that the CPU <NUM> manipulates at runtime.

Other devices on the bus <NUM> are a hard disk drive (HDD) <NUM>, a graphics processor <NUM>, an input device interface <NUM>, an optical disc drive <NUM>, and a communication interface <NUM>.

The HDD <NUM> writes and reads data magnetically on its internal platters. The HDD <NUM> serves as secondary storage of the terminal device <NUM> to store program and data files of the operating system and applications. Flash memory and other semiconductor memory devices may also serve as secondary storage.

The graphics processor <NUM>, coupled to a monitor <NUM>, produces video images in accordance with drawing commands from the CPU <NUM> and displays them on a screen of the monitor <NUM>. The monitor <NUM> may be, for example, a cathode ray tube (CRT) display or a liquid crystal display.

The input device interface <NUM> is connected to input devices such as a keyboard <NUM> and a mouse <NUM> and supplies signals from those devices to the CPU <NUM>. The mouse <NUM> is a pointing device, which may be replaced with other kinds of pointing devices such as touchscreen, tablet, touchpad, and trackball.

The optical disc drive <NUM> reads out data encoded on an optical disc <NUM>, by using laser light. The optical disc <NUM> is a portable data storage medium, the data recorded on which can be read as a reflection of light. The optical disc <NUM> may be a digital versatile disc (DVD), DVD-RAM, compact disc read-only memory (CD-ROM), CD-Recordable (CD-R), or CD-Rewritable (CD-RW), for example.

The communication interface <NUM> is connected to a network <NUM> and exchanges data with other computers over the network <NUM>.

The above-described hardware platform may be used to realize the processing functions of the embodiments discussed in this description. While <FIG> only depicts a terminal device <NUM> as an example of hardware configuration, the same hardware configuration may similarly be used to implement the application servers <NUM>, <NUM>-<NUM>, and <NUM>-<NUM> and data storage server <NUM>, as well as the foregoing information processing apparatus <NUM> according to the first reference technology discussed in <FIG>.

<FIG> is a block diagram illustrating functions of several devices used in the second reference technology. The illustrated terminal device <NUM> includes a browser <NUM> and an application <NUM>. It is noted that the application <NUM> is loaded to the terminal device <NUM> each time a user <NUM> needs a data processing function of the application <NUM>.

The browser <NUM> parses an HTML document and displays its content on a screen of the monitor <NUM>. If a given structured document contains a script for execution of an application <NUM>, the browser <NUM> downloads a relevant application program from the application server <NUM> and stores it in RAM <NUM> or HDD <NUM> of the terminal device <NUM>. Here the browser <NUM> extracts a user root URL of the user <NUM> from the HTML document as it includes a script for execution of an application <NUM>. The extracted user root URL points to a specific storage space in the data storage server <NUM> in which data of the user <NUM> is stored. The browser <NUM> includes this user root URL as a parameter of a start command when issuing it to launch the application <NUM>.

The application <NUM> performs data processing operations requested by the user <NUM>. When launched, the application <NUM> makes access to the data storage server <NUM> by using the above-noted parameter of the user root URL to obtain an application-specific URL list <NUM> for the user <NUM>. This application-specific URL list <NUM> is a collection of application-specific URLs associated with various applications that the user <NUM> may use. The application <NUM> finds its own associated application-specific URL from the obtained application-specific URL list <NUM>. The application <NUM> produces an access target URL when a need arises for access to personal data of the user <NUM> during the course of data processing. For example, the obtained application-specific URL points to a specific place in the directory structure, which the application <NUM> regards as the reference location. The application <NUM> produces an access target URL by appending additional location information to the application-specific URL, where the additional location information points to the location of intended data by following the directory structure from the reference location. The application <NUM> uses this access target URL to execute a data access to the data storage server <NUM>.

The application server <NUM> includes a storage unit <NUM>, a document serving unit <NUM>, and a root URL determination unit <NUM>.

The storage unit <NUM> contains a plurality of HTML documents <NUM>, 211a, 211b,. , an application program <NUM>, and a root URL management table <NUM>. The application program <NUM> is a program code describing what data processing operations the application <NUM> is supposed to execute. The root URL management table <NUM> is a collection of user root URLs of different users.

The document serving unit <NUM> transmits an HTML document or an application program <NUM> to the terminal device <NUM> when so requested from the browser <NUM> in the terminal device <NUM>. The document serving unit <NUM> has an endpoint URL associated with the user <NUM>, and an authentication procedure may be implemented to grant access to this endpoint URL. When there is an access request from the browser <NUM> to the endpoint URL, the document serving unit <NUM> sends the terminal device <NUM> an HTML document <NUM> that is associated with the requesting user <NUM>. This HTML document includes a script for execution of the application program <NUM>. The document serving unit <NUM> obtains a user root URL of the user <NUM> from the root URL determination unit <NUM> and inserts the user root URL into the HTML document <NUM> to be transmitted. The document serving unit <NUM> may also transmit an application program <NUM> to the browser <NUM> in the terminal device <NUM> when the browser <NUM> requests it.

Upon request from the document serving unit <NUM>, the root URL determination unit <NUM> consults the root URL management table <NUM> to find a user root URL of the user <NUM> who wishes to use the application program <NUM>. The root URL determination unit <NUM> then informs the document serving unit <NUM> of the user root URL that is found.

The data storage server <NUM> includes a storage unit <NUM>, an application-specific URL management unit <NUM>, and a data management unit <NUM>.

The storage unit <NUM> stores files <NUM>, 311a, 311b,. and an application-specific URL list <NUM>. The files <NUM>, 311a, 311b,. contain personal data of the user <NUM>. The application-specific URL list <NUM> is a collection of application-specific URLs each indicating the location of a data file used by a specific application. As the user <NUM> may use a plurality of applications, the application-specific URL list <NUM> includes a plurality of such application-specific URLs.

The application-specific URL management unit <NUM> sends an application-specific URL list <NUM> upon request from the application <NUM>. For example, the application-specific URL management unit <NUM> may be configured to send an application-specific URL list <NUM> only if the user <NUM> of the application <NUM> is successfully authenticated in advance.

The data management unit <NUM> makes access to a specified file upon receipt of an access request from the application <NUM>. In one case, the access request asks for retrieval of a specific file. The data management unit <NUM> thus reads and transmits the requested file to the application <NUM>. Here the location of the requested file is specified by an access target URL. In another case, the access request specifies a file to be written. The data management unit <NUM> then writes the specified file to the specified location in the storage unit <NUM>.

The following section goes into details of the structure of data stored in the above devices.

<FIG> illustrates an exemplary data structure of a root URL management table. The illustrated root URL management table <NUM> is formed from three data fields named user ID, endpoint URL, and user root URL.

The user ID field contains an identifier (user ID) for uniquely identifying each user of the application server <NUM>.

The endpoint URL field is associated with a specific user ID to indicate the endpoint URL of a user identified by that user ID.

The user root URL field is also associated with a specific user ID to indicate the user root URL of a user identified by that user ID.

The root URL determination unit <NUM> determines the user root URL of a user in question by consulting this root URL management table <NUM>. Suppose, for example, that the user <NUM> makes access to an endpoint URL corresponding to his or her user ID of "AB1234. " In this case, the root URL determination unit <NUM> extracts a user root URL associated with the user ID AB1234 and informs the document serving unit <NUM> of the extracted user root URL as being relevant to the requesting user <NUM>.

The exemplary endpoint URL seen in <FIG> is "http://app1. example/?userUrl=http%253A%252F%252Fdata. examp le%252Fshimono" for user ID "AB1234". This endpoint URL indicates that a document serving unit <NUM> identified by the URL "http://app1. example/" is supposed to receive a user root URL of "http://api. example/user1/" as the value of a parameter named "userUrl". When there is a request specifying the above endpoint URL, the document serving unit <NUM> returns a response including the received URL "http://api. example/user1" as a user root URL for configuration of the application <NUM>.

The determination method executed by the root URL determination unit <NUM> involves a logic to produce a user root URL from a given endpoint URL. One possible logic is to use a table for looking up such URLs. Another possible logic is to produce a URL by parsing query parameters.

Although the above-described root URL determination unit <NUM> finds a user root URL by consulting a table with the endpoint URL corresponding to a user ID, the embodiment of the root URL determination unit <NUM> is not limited to that specific method. For example, another possible method is to produce a user root URL by manipulating character strings from the endpoint URL corresponding to a user ID. Yet another possible method is to determine a user root URL by consulting a table with a user ID submitted in the preceding user authentication.

Also, the above-described processing may use other tables than the one illustrated in <FIG>. The exemplary table of <FIG> is formed from three associated data fields of user ID, endpoint URL, and user root URL. One variation of this table may only combine two of those data fields, e.g., user ID and user root URL, or endpoint URL and user root URL.

The above-described second reference technology uses a root URL management table <NUM> to manage user root URLs. Alternatively, it is also possible to embed a user root URL in HTML documents before they are provided to users. For example, a user root URL corresponding to an endpoint URL is previously written in the HTML document, so that the user root URL will be transmitted as part of the document in response to an access request to the endpoint URL. This implementation eliminates the need for the root URL determination unit <NUM> and root URL management table <NUM>.

The storage unit <NUM> in the data storage server <NUM> stores data in the following directory structure.

<FIG> illustrates an exemplary directory structure of a storage unit in a data storage server. The illustrated storage unit <NUM> stores the files in a hierarchical directory structure under the control of a file system supported by the OS of the data storage server <NUM>. In the example of <FIG>, a directory <NUM> named "user1" is located immediately below the topmost "root" directory <NUM>. This "user1" directory <NUM> is provided for the purpose of storing personal data of a user <NUM>.

Located below the "user1" directory <NUM> are a directory <NUM> named "appl," a directory <NUM> named "app2," and a directory <NUM> named "app3. " The "app1" directory <NUM> is for storing personal data of the user <NUM> which the application <NUM> provided in one application server <NUM> may use. The "app2" directory <NUM> is for storing personal data of the user <NUM> which the application provided in another application server <NUM>-<NUM> may use. The "app3" directory <NUM> is for storing personal data of the user <NUM> which the application provided in yet another application server <NUM>-<NUM> may use.

A plurality of files <NUM>, 311a, 311b,. are stored in the "app1" directory <NUM>. One file <NUM> is named "file1". Another file 311a is named "file2". Yet another file 311b is named "file3".

A file 312a named "url_list" is stored in the "user1" directory <NUM>. This "url_list" file 312a contains an application-specific URL list <NUM>.

The application-specific URL list has a data structure described below.

<FIG> illustrates an exemplary data structure of an application-specific URL list. The illustrated application-specific URL list <NUM> describes its content by using the Extensible Markup Language (XML). Specifically, the application-specific URL list <NUM> includes application-specific URLs corresponding to different applications, together with the domain names of application servers providing those applications.

For example, an application-specific URL "http://api. data-service. example/user1/app1/" is associated with a domain name "app1. Another application-specific URL "http://api. data-service. example/user1/app2/" is associated with another domain name "app2. Yet another application-specific URL "http://api. data-service. example/user1/app3/" is associated with yet another domain name "app3.

The next section will describe in detail what functions are provided in the application <NUM>.

<FIG> is a block diagram illustrating exemplary functions of an application. The illustrated application <NUM> includes a data processing unit <NUM>, a user root URL obtaining unit <NUM>, a user root URL storage unit <NUM>, an application-specific URL determination unit <NUM>, an application-specific URL storage unit <NUM>, an access target URL generation unit <NUM>, and an accessing unit <NUM>.

The data processing unit <NUM>, responsive to a start request from the browser <NUM>, executes data processing operations according to commands or the like from a user <NUM>. When the data processing operations use personal data of the user <NUM>, the data processing unit <NUM> sends an access request to the access target URL generation unit <NUM>, together with an application local path pointing to the personal data by following the directories from a specific reference location. More specifically, this application local path is a combination of a relative path of a personal data file with respect to the reference location in the directory structure and the name of the personal data file. The data processing unit <NUM> also receives the result of the access request from the accessing unit <NUM>.

The user root URL obtaining unit <NUM> obtains location information from the browser <NUM>. For example, the user root URL obtaining unit <NUM> obtains a user root URL specified as a parameter in the activation request from the browser <NUM> and enters the obtained user root URL in the user root URL storage unit <NUM>.

The user root URL storage unit <NUM> stores the user root URL. For example, the user root URL storage unit <NUM> may be implemented as part of storage space of the RAM <NUM> or HDD <NUM>.

The application-specific URL determination unit <NUM> determines an application-specific URL based on the user root URL stored in the user root URL storage unit <NUM>. For example, the application-specific URL determination unit <NUM> makes access to the data storage server <NUM> to request a file named "url_list", residing immediately below the user root URL. In response to this file request, the data storage server <NUM> returns an application-specific URL list <NUM>. The application-specific URL determination unit <NUM> determines its application-specific URL by consulting this application-specific URL list <NUM>. Suppose that, for example, that the application-specific URL determination unit <NUM> is previously informed of a specific domain name that indicates the application server <NUM> providing the application <NUM>. In this case, the application-specific URL determination unit <NUM> selects an application-specific URL associated with the given domain name as being relevant to the application <NUM> itself. The application-specific URL determination unit <NUM> stores the selected application-specific URL in the application-specific URL storage unit <NUM>.

The application-specific URL storage unit <NUM> holds the application-specific URL. For example, the application-specific URL storage unit <NUM> may be implemented as part of storage space of the RAM <NUM> or HDD <NUM>.

The access target URL generation unit <NUM> produces an access target URL based on the application-specific URL stored in the application-specific URL storage unit <NUM> and the foregoing application local path in the access request from the data processing unit <NUM>. The access target URL generation unit <NUM> passes the produced access target URL to the accessing unit <NUM>.

The accessing unit <NUM> makes access to the access target URL over the network <NUM>. The access target URL produced by the application <NUM> actually points to a particular file in the data storage server <NUM>. The accessing unit <NUM> thus submits an access request to the data storage server <NUM> and receives a response indicating the result from the data storage server <NUM>, depending on the type of access request. In the case of a data read request, the response contains data read out of the access target. In the case of a data write request, the response indicates the result of the requested write operation.

The above-described functions of devices enable the data storage server <NUM> to manage personal data of the user <NUM> in a consolidated way, while the data may be used by a plurality of applications provided by applications servers <NUM>, <NUM>-<NUM>, and <NUM>-<NUM>. The next section will describe a procedure up to a data access, assuming that the application <NUM> provided by the application server <NUM> uses data in the data storage server <NUM>.

<FIG> is a sequence diagram illustrating a procedure executed in the second reference technology. Each operation in <FIG> is described below in the order of step numbers.

(Step S11) The user <NUM> enters an application start command to the browser <NUM> in his or her terminal device <NUM>, specifying a URL associated with himself or herself. For example, the user <NUM> selects a shortcut icon associated with a particular URL by using a pointing device, thus entering an application start command.

(Step S12) The browser <NUM> transmits a GET request specifying the entered URL to the application server <NUM>.

(Step S13) Upon receipt of the GET request, the document serving unit <NUM> in the application server <NUM> retrieves an HTML document from the specified location in the storage unit <NUM>. The document serving unit <NUM> submits a user root URL determination request to the root URL determination unit <NUM>.

(Step S14) In response to the user root URL determination request, the root URL determination unit <NUM> determines what user root URL corresponds to the user <NUM>. Suppose, for example, that the user <NUM> has been authenticated with his or her user ID of "AB1234" and has issued an application start command specifying an endpoint URL corresponding to that user ID. In this case, the root URL determination unit <NUM> consults the root URL management table <NUM> to extract therefrom a user root URL associated with the user ID "AB1234", thus determining what user root URL corresponds to the user <NUM>.

(Step S15) The root URL determination unit <NUM> sends the determined user root URL to the document serving unit <NUM> as its response.

(Step S16) The document serving unit <NUM> sends an HTML document containing the received user root URL to the terminal device <NUM> as its response.

(Step S17) The browser <NUM> in the terminal device <NUM> evaluates the HTML document received from the application server <NUM>. That is, the browser <NUM> analyzes what is written in the HTML document and detects, for example, a tag that indicates an embedded object.

(Step S18) When the object embedding tag detected in the HTML document specifies an application program <NUM>, the browser <NUM> sends a request to the application server <NUM> to get that application program <NUM>.

(Step S19) In the application server <NUM>, the document serving unit <NUM> retrieves the application program <NUM> from its storage unit <NUM> and sends the retrieved application program <NUM> back to the terminal device <NUM> as its response.

(Step S20) Upon receipt of the application program <NUM> from the application server <NUM>, the browser <NUM> in the terminal device <NUM> stores the application program <NUM> in its local RAM <NUM>, for example. The browser <NUM> then sends the OS an execution command for the application program <NUM> with a parameter specifying the user root URL, thus launching an application <NUM>.

(Step S21) The launched application <NUM> issues a query for application-specific URL list to the data storage server <NUM>, specifying the user root URL.

(Step S22) In response to the query from the terminal device <NUM>, the application-specific URL management unit <NUM> in the data storage server <NUM> returns an application-specific URL list <NUM> to the terminal device <NUM>.

(Step S23) In the terminal device <NUM>, the application <NUM> searches the received application-specific URL list <NUM> to find out which application-specific URL is relevant to the application <NUM> itself. The application <NUM> then stores its own application-specific URL in the application-specific URL storage unit <NUM>.

(Step S24) The application <NUM> sends data for an initial screen to the browser <NUM>. The browser <NUM> displays the HTML document received at step S16 on the monitor <NUM>, embedding an initial screen of the application <NUM> (see <FIG>) in the resulting view.

(Step S25) Viewing the screen on the monitor <NUM>, the user <NUM> operates his or her keyboard <NUM> and mouse <NUM> to enter a command for the application <NUM> to execute data processing operations.

(Step S26) The application <NUM> executes data processing operations requested by the user <NUM>. To use personal data of the user <NUM>, the application <NUM> produces an access target URL of the personal data by appending its application local path to the application-specific URL.

(Step S27) The application <NUM> makes access to the data storage server <NUM>, specifying the produced access target URL.

(Step S28) In the data storage server <NUM>, the data management unit <NUM> executes access to the specified access target URL and returns its result to the terminal device <NUM>.

(Step S29) The application <NUM> in the terminal device <NUM> continues the data processing operations according to the access result received from the data storage server <NUM>. The application <NUM> then sends data indicating the result of data processing operations back to the browser <NUM>. The browser <NUM> produces a screen on the monitor <NUM> to display what the application has done (see <FIG>).

The above steps permit the application <NUM> to execute data processing operations using personal data of the requesting user <NUM> which is stored in the data storage server <NUM>. It is noted that the application <NUM> obtains a user root URL from the HTML document supplied from the application server <NUM>.

<FIG> illustrates an example of an HTML document including a user root URL. The illustrated HTML document <NUM> includes an <object> tag <NUM> to embed an image representing an application <NUM>. The HTML document <NUM> also contains a <param> tag <NUM> that includes a user root URL as its "value" attribute.

This HTML document <NUM> causes the browser <NUM> to obtain an application program <NUM> from the application server <NUM> according to what is designated in the "data" attribute in the <object> tag <NUM>. With the obtained application program <NUM>, the browser <NUM> starts execution of an application <NUM>, specifying the user root URL in the "value" attribute of a <param> tag <NUM> as a parameter for the execution.

Upon startup of the application <NUM>, the terminal device <NUM> outputs an initial screen of the application <NUM> on the monitor <NUM>.

<FIG> illustrates an example of an initial screen produced by an application. The example seen in <FIG> is an initial screen of a scheduler application. This initial screen <NUM> gives a list of months for which the application <NUM> has schedule data to display. The user <NUM> may select one of those months, and the application <NUM> displays scheduled events of the user <NUM> in the selected month.

To display schedules in a specified month, the application <NUM> has to retrieve relevant personal data of the user <NUM>. To this end, the application <NUM> produces an access target URL by appending an application local path to the application-specific URL and sends a request to the access target URL to get desired data.

In response, the data storage server <NUM> sends the terminal device <NUM> a file describing a single-month schedule of the user <NUM>. The application <NUM> then takes schedule data out of the file received from the data storage server <NUM> and displays it on a monitor screen.

<FIG> illustrates an example of a schedule screen. This schedule screen <NUM> represents schedules of the user <NUM> in a specified month (December <NUM> in the example of <FIG>).

As can be seen from the above example, the application <NUM> provided by the application server <NUM> obtains personal data of the user <NUM> from the data storage server <NUM>. The same applies to other applications provided by other application servers <NUM>-<NUM> and <NUM>-<NUM>. In other words, the personal data of the user <NUM> can be managed only in one data storage server <NUM>.

This section describes a first embodiment. The first embodiment implements a combination of the foregoing first application execution mode, third method for obtaining user root URLs, and third method for determining application-specific URLs. The first embodiment assumes the same system configuration illustrated in <FIG> for the second reference technology. While the first embodiment uses the same components of each device discussed in <FIG> and <FIG> for the second reference technology, at least some of those components operate differently from the second reference technology. The following description is directed to such dissimilar features of the first embodiment while using same reference numerals of the components seen in <FIG>.

<FIG> is a sequence diagram illustrating an exemplary procedure executed in the first embodiment. In this sequence, steps S41 to S50 and S54 to S60 are similar to steps S11 to S20 and S23 to S29 of <FIG> discussed in the second reference technology, whereas steps S51 to S54 are different from the second reference technology. The following description explains these different steps in the order of step numbers.

(Step S51) The started application <NUM> issues a query for an application-specific URL to the data storage server <NUM>, specifying the user root URL and the identifier of the application <NUM> itself. The application identifier may be, for example, a character string (e.g., http://app1. com/) that contains the domain name of the application server <NUM> hosting the application <NUM>.

(Step S52) In response to the query from the terminal device <NUM>, the application-specific URL management unit <NUM> in the data storage server <NUM> determines an application-specific URL. For example, the application-specific URL management unit <NUM> consults the application-specific URL list <NUM> for the user <NUM> to find an application-specific URL corresponding the identifier of the application <NUM> that is specified in the query.

(Step S53) The application-specific URL management unit <NUM> sends the found application-specific URL to the terminal device <NUM> as its response.

(Step S54) In the terminal device <NUM>, the application <NUM> stores the received application-specific URL in the application-specific URL storage unit <NUM>.

The above steps of the first embodiment enable the data storage server <NUM> to determine which application-specific URL corresponds to the application <NUM>. According to the foregoing second reference technology, the data storage server <NUM> returns a whole list of application-specific URLs to the terminal device <NUM>. In contrast, the data storage server <NUM> in the first embodiment only returns a part of the list, i.e., a single application-specific URL that is found to be relevant, thus reducing the amount of communication data.

This section describes a third reference technology. The third reference technology implements a combination of the foregoing first application execution mode, third method for obtaining user root URLs, and first method for determining application-specific URLs. The third reference technology assumes the same system configuration illustrated in <FIG> for the second reference technology. While the third reference technology uses the same components of the terminal device and application servers discussed in <FIG> and <FIG> for the second reference technology, at least some of those components of the third reference technology operate differently from the second reference technology.

Another difference is that the third reference technology includes no application-specific URL management unit in its data storage server, whereas the storage unit and data management unit remain as in the second reference technology. The data storage server stores in its storage unit a plurality of files, including a personal data file of the user <NUM>. The third reference technology, however, does not include application-specific URL lists.

As can be seen from the above, the components of the third reference technology are a subset of those discussed in <FIG> for the second reference technology. The following description is directed to unlike features of the third reference technology while using same reference numerals of the components seen in <FIG>.

<FIG> is a sequence diagram illustrating an exemplary procedure executed in the third reference technology. In this sequence, steps S81 to S90 and S94 to S96 are similar to steps S11 to S20 and S27 to S29 of <FIG> discussed in the second reference technology, whereas steps S91 to S93 are different from the second reference technology. The following description explains these different steps in the order of step numbers.

(Step S91) The started application <NUM> sends data of an initial screen to the browser <NUM>, without issuing queries for an application-specific URL list to the data storage server <NUM>. The browser <NUM> displays the HTML document received at step S86 on the monitor <NUM> after embedding an initial screen of the application <NUM>.

(Step S92) Viewing the screen on the monitor <NUM>, the user <NUM> operates his or her keyboard <NUM> and mouse <NUM> to enter a command for the application <NUM> to execute data processing operations.

(Step S93) The application <NUM> produces an access target URL according to a rule base. For this purpose, the application <NUM> is configured with a predefined set of rules for generation of access target URLs. For example, the rules may define a procedure that produces first a unique character string identifying an application <NUM>, forms a path that includes the produced character string as a directory name, and appends the path to the given user root URL. The unique character string for an application <NUM> may include, for example, the domain name of the application server <NUM> hosting the application <NUM>.

As can be seen from the above, the third reference technology uses a rule base to determine application-specific URLs, thus eliminating the need for configuring the data storage server <NUM> to manage application-specific URLs. The third reference technology also eliminates query-and-response interactions about application-specific URL list between the terminal device <NUM> and data storage server <NUM> before launching an application <NUM>, thus reducing the burden of communication.

This section describes a fourth reference technology. The fourth reference technology implements a combination of the foregoing first application execution mode, fourth method for obtaining user root URLs, and second method for determining application-specific URLs.

<FIG> is a block diagram illustrating exemplary functions of devices used in the fourth reference technology. The illustrated terminal device 100a includes a browser 110a and an application 120a that function in the same way as their respective counterparts in the terminal device <NUM> discussed in <FIG> for the second reference technology. Also, the application 120a has the function of negotiating with a data storage server 300a on the basis of OpenID for the right of execution of applications.

The illustrated application server 200a includes a storage unit 210a and a document serving unit 220a. The storage unit 210a stores a plurality of HTML documents <NUM>, 211a, 211b,. and an application program <NUM> describing what the application 120a is supposed to execute. The document serving unit 220a transmits an HTML document and the application program <NUM> upon request from the terminal device 100a.

The illustrated data storage server 300a includes a storage unit 310a, an application-specific URL management unit 320a, a data management unit 330a, and an authentication unit <NUM>. The storage unit 310a, application-specific URL management unit 320a, and data management unit 330a function in the same way as their respective counterparts in the data storage server <NUM> discussed in <FIG> for the second reference technology.

The authentication unit <NUM> provides a user authentication mechanism based on the OpenID standard. The authentication unit <NUM> authenticates a user based on, for example, a combination of ID and password received as a credential of the user. The authentication unit <NUM> returns an affirmative response to the sender of the credential when it proves the sender's identity as an authorized user.

<FIG> is a first half of a sequence diagram illustrating an exemplary procedure executed in the fourth reference technology. Each operation in <FIG> is described below in the order of step numbers.

(Step S101) The user <NUM> enters an application start command to the browser 110a in his or her terminal device 100a, specifying URL of an application server 200a.

(Step S102) The browser <NUM> transmits a GET request that specifies the entered URL to the application server 200a.

(Step S103) Upon receipt of the GET request, the document serving unit 220a in the application server 200a retrieves an HTML document from the specified location in the storage unit 210a. The document serving unit 220a transmits this HTML document back to the requesting terminal device 100a.

(Step S104) The browser 110a in the terminal device 100a evaluates the HTML document received from the application server 200a.

(Step S105) When an object embedding tag is detected in the HTML document, and if the tag specifies an application program <NUM>, the browser 110a sends a request to the application server 200a to get that application program <NUM>.

(Step S106) The document serving unit 220a in the application server 200a retrieves the requested application program <NUM> from the storage unit 210a and transmits it to the requesting terminal device 100a.

(Step S107) The browser 110a in the terminal device 100a stores the received application program <NUM> in its local RAM <NUM>, for example. The browser 110a then sends the OS an execution command for the application program <NUM>, thus starting an application 120a.

(Step S108) The started application 120a sends data of an OpenID entry screen to the browser 110a. The browser 110a produces a screen on the monitor <NUM> to prompt the user to enter his or her OpenID (see <FIG>).

(Step S109) The user <NUM> enters a user root URL as his or her OpenID to application 120a in the terminal device 100a.

(Step S110) The application 120a stores the user root URL that the user <NUM> has entered as his or her OpenID.

(Step S111) The application 120a requests the browser 110a to produce a new pop-up window. For example, the User Experience (UX) Extension, an authentication technique of OpenID, may be used for this pop-up window.

(Step S112) The browser 110a redirects the above OpenID screen request to the data storage server 300a.

(Step S113) In response to the OpenID screen request, the authentication unit <NUM> in the data storage server 300a sends an HTML document to the terminal device 100a for login operation. Based on this HTML document, the browser 110a in the terminal device 100a produces a pop-up log-in window (see <FIG>).

<FIG> illustrates an example of an OpenID entry screen. This OpenID entry screen <NUM> has a text box 42a for entry of an OpenID, and an OK button 42b. The user <NUM> types a user root URL in the text box 42a and presses the OK button 42b using a mouse <NUM> or the like, thus causing the entered user root URL to be passed as an OpenID to the application 120a.

Afterwards, the browser 110a produces a pop-up window for login operation, in response to a request from the application 120a.

<FIG> illustrates an example of a pop-up login window. The illustrated login window <NUM> contains a text box 43a for entry of a login ID and another text box 43b for entry of a password. With this screen of the terminal device 100a, the fourth reference technology proceeds to the next processing seen in <FIG>.

<FIG> is a second half of the sequence diagram illustrating an exemplary procedure executed in the fourth reference technology. Each operation in <FIG> is described below in the order of step numbers.

(Step S121) The user <NUM> enters a credential in the login window <NUM> to prove his or her legitimacy. For example, the user <NUM> enters his or her ID into one text box 43a in the login window <NUM>. This ID is supposed to have been registered with the data storage server 300a. The user also enters his or her password into another text box 43b. The entered ID-password pair serves as the login credential of the user <NUM>.

(Step S122) The browser 110a in the terminal device 100a sends the entered credential to the data storage server 300a.

(Step S123) In the data storage server 300a, the authentication unit <NUM> executes authentication of the user <NUM> based on the received credential.

(Step S124) When the user <NUM> is authenticated properly, the authentication unit <NUM> sends the terminal device 100a a redirect response indicating the successful authentication.

(Step S125) In the terminal device 100a, the browser 110a informs the application 120a of the event of successful authentication.

(Step S126) Because of the successful authentication, the application 120a is sure that what the user <NUM> has entered as an OpenID at step S109 is his or her genuine user root URL. Accordingly, the application 120a sends a query for an application-specific URL list to the data storage server 300a, specifying the confirmed user root URL of the user <NUM>.

The subsequent steps S127 to S134 are similar to step S22 to S29 discussed in <FIG> for the second reference technology.

The above-described steps permit an application to obtain a correct user root URL proved through an OpenID authentication. The use of OpenID enables the user to have access to a plurality of applications with a single credential. What this means to the user is a reduced burden of credential management.

This section describes a second embodiment. The second embodiment implements a combination of the foregoing third application execution mode, second method for obtaining user root URLs, and third method for determining application-specific URLs. It is noted that no application servers are used in the second embodiment, unlike the foregoing second to fourth reference technologys.

<FIG> is a block diagram illustrating functions of devices used in the second embodiment. The illustrated terminal device 100b includes an application 120b and a storage unit <NUM>. The application 120b has previously been installed in the terminal device 100b. Besides providing the same functions as the application <NUM> discussed in <FIG>, the application 120b according to the second embodiment accepts entry of user root URLs and produces its own display screens without intervention of browsers. The storage unit <NUM> stores an application-specific URL <NUM> obtained from the data storage server 300b.

The data storage server 300b includes a storage unit 310b, an application-specific URL management unit 320b, and a data management unit 330b. These components of the data storage server 300b function in the same way as their respective counterparts in the data storage server <NUM> according to the second reference technology discussed in <FIG>.

<FIG> is a sequence diagram illustrating an exemplary procedure executed in the second embodiment. Each operation in <FIG> is described below in the order of step numbers.

(Step S141) The user <NUM> enters an application start command to the terminal device 100b.

(Step S142) The application 120b is thus started in accordance with the start command.

(Step S143) The application 120b checks whether it already has an application-specific URL.

(Step S144) If no application-specific URL is present, the application 120b displays a user root URL entry screen on the monitor <NUM> (see <FIG>).

(Step S145) The user <NUM> enters his or her user root URL in the user root URL entry screen.

(Step S146) The started application 120b in the terminal device 100b issues a query for an application-specific URL list to the data storage server 300b, based on the user root URL entered by the user <NUM>.

(Step S147) In response to the query from the terminal device 100b, the application-specific URL management unit 320b in the data storage server 300b returns an application-specific URL list <NUM> to the terminal device 100b.

(Step S148) In the terminal device 100b, the application 120b searches the received application-specific URL list <NUM> to find out which application-specific URL is relevant to the application 120b itself. The application 120b then stores its own application-specific URL locally.

(Step S149) The user <NUM> operates his or her keyboard <NUM> and mouse <NUM> to enter a command for the application 120b to execute data processing operations.

(Step S150) The application 120b executes data processing operations requested by the user <NUM>. To use personal data of the user <NUM>, the application 120b produces an access target URL of the personal data by appending its application local path to the application-specific URL.

(Step S151) The application 120b makes access to the data storage server 300b, specifying the produced access target URL.

(Step S152) In the data storage server 300b, the data management unit 330b executes access to the specified access target URL and returns its result to the terminal device 100b.

(Step S153) The application 120b in the terminal device 100b continues the data processing operations according to the access result received from the data storage server 300b. The application 120b displays the result of data processing operations on a screen of the monitor <NUM>.

<FIG> illustrates an example of a user root URL entry screen. The illustrated user root URL entry screen <NUM> contains a text box <NUM> for entry of a user root URL, and an OK button <NUM>. The user <NUM> types his or her user root URL in the text box <NUM> and then presses the OK button <NUM>, thus entering the user root URL to the application 120b.

As can be seen from the above, the second embodiment enables the data storage server 300b to manage personal data of the user <NUM> for use by a pre-installed application 120b in the terminal device 100b.

This section describes a fifth reference technology. The fifth reference technology implements a combination of the foregoing second application execution mode, second method for obtaining user root URLs, and second method for determining application-specific URLs.

<FIG> is a block diagram illustrating functions of devices used in the fifth reference technology. The illustrated terminal device 100c includes a browser 110c that functions in the same way as the browser <NUM> discussed in <FIG> for the second reference technology.

The illustrated application server 200c includes a storage unit 210c and an application <NUM>.

The storage unit 210c stores a root URL management table <NUM>. The application <NUM> functions in the same way as the application <NUM> discussed in <FIG> for the second reference technology, except that it is configured to communicate with the browser 110c via a network <NUM>. The application <NUM> obtains a user root URL from the root URL management table <NUM> in the storage unit 210c.

The illustrated data storage server 300c includes a storage unit 310c, an application-specific URL management unit 320c, and a data management unit 330c. These components of the data storage server 300c function in the same way as their respective counterparts in the data storage server <NUM> discussed in <FIG> for the second reference technology.

<FIG> is a sequence diagram illustrating an exemplary procedure executed in the fifth reference technology. Each operation in <FIG> is described below in the order of step numbers.

(Step S161) The user <NUM> logs in to an application <NUM> through a login screen produced by the browser 110c in the terminal device 100c (see <FIG>). Here the user <NUM> specifies the application <NUM> by entering its URL.

(Step S162) The browser 110c sends a credential to the application server 200c. This credential may be, for example, a combination of the user's ID and password.

(Step S163) In the application server 200c, the application <NUM> performs user authentication upon receipt of the credential. When the user <NUM> is authenticated properly, the application <NUM> consults the root URL management table <NUM> to find a user root URL associated with user ID of the user <NUM>.

(Step S164) The application <NUM> issues a query for an application-specific URL list to the data storage server 300c, specifying the above user root URL.

(Step S165) In response to the query from the application server 200c, the application-specific URL management unit 320c in the data storage server 300c returns an application-specific URL list <NUM> to the requesting application server 200c.

(Step S166) In the application server 200c, the application <NUM> searches the received application-specific URL list <NUM> to find out which application-specific URL is relevant to the application <NUM> itself.

(Step S167) The application <NUM> stores its own application-specific URL, associating the URL with the current communication session with the terminal device 100c.

(Step S168) The application <NUM> sends the terminal device 100c an HTML document having a session cookie. In the terminal device 100c, the browser 110c displays a screen for the application <NUM> on the monitor <NUM>.

(Step S169) Viewing the screen on the monitor <NUM>, the user <NUM> operates his or her keyboard <NUM> and mouse <NUM> to enter a command to the application <NUM> via the browser 110c.

(Step S170) In response to the command from the user <NUM>, the browser 110c sends the application server 200c an HTTP request with a session cookie.

(Step S171) The application <NUM> in the application server 200c executes requested data processing operations. During this course, the application <NUM> may use personal data of the user <NUM>. In that case, the application <NUM> obtains an application-specific URL associated with its current communication session with the terminal device 100c.

(Step S172) The application <NUM> produces an access target URL by appending an application local path to the obtained application-specific URL.

(Step S173) The application <NUM> makes access to the data storage server 300c, specifying the produced access target URL.

(Step S174) In the data storage server 300c, the data management unit 330c executes access to the specified access target URL and returns its result to the application server 200c.

(Step S175) The application <NUM> in the application server 200c continues the data processing operations according to the access result received from the data storage server 300c. The application <NUM> then sends data indicating the result of data processing operations back to the terminal device 100c. In response, the browser 110c in the terminal device 100c produces a screen on the monitor <NUM> to display what the application has done.

<FIG> illustrates an example of a login screen. This login screen <NUM> contains a text box <NUM> for entry of a login ID, another text box <NUM> for entry of a password, and an OK button <NUM>. The user <NUM> types his or her user ID in the former text box <NUM> and password in the latter text box <NUM>. The user <NUM> then presses the OK button <NUM>, causing the entered combination of user ID and password to be sent as the user's credential to the application server 200c. This credential permits the application server 200c to determine a user root URL associated with the user ID.

As can be seen from the above, the fifth reference technology enables the data storage server 300c to manage personal data of the user <NUM> for access from an application <NUM> running on an application server 200c.

While the first method for obtaining user root URLs is not explained in the above-described embodiments, the first method is actually used as part of the procedure of the second method for obtaining user root URLs. Referring to, for example, the sequence diagram of <FIG>, what is done at steps S144 and S145 of the second embodiment corresponds to the first method for obtaining user root URLs.

The functions of the above-described embodiments may be implemented as a computer application. That is, computer programs are provided for each of the terminal device, application server, and data storage server to implement the functions that these devices are supposed to do. Computers execute such programs to realize the processing functions discussed in the preceding sections. The programs may be encoded in a computer-readable storage medium. Computer-readable storage media include magnetic storage devices, optical discs, magneto-optical storage media, semiconductor memory devices, and others. Magnetic storage devices include hard disk drives (HDD), flexible disks (FD), and magnetic tapes, for example. Optical disc media include DVD, DVD-RAM, CD-ROM, CD-RW, and others. Magneto-optical storage media include magneto-optical discs (MO), for example.

Portable storage media, such as DVD and CD-ROM, are used for distribution of program products. Network-based distribution of programs may also be possible, in which case several master program files are made available on a server computer for downloading to other computers via a network.

For example, a computer stores programs in its local storage device, which have previously been installed from a portable storage medium or downloaded from a server computer. The computer executes programs read out of the local storage device, thereby performing the programmed functions. Where appropriate, the computer may execute a program read out of a portable storage medium, without installing them in its local storage device. Another alternative method is that the computer executes a program upon downloading from a server computer.

Claim 1:
An information processing apparatus comprising:
location information obtaining means (1b) for obtaining first location information (<NUM>) indicating an identifier of a data storage device that the user specifies as a unified location of personal data of the user, the first location information (<NUM>) further indicating a location of a user-specified directory within the data storage device;
location information producing means (1c) for sending the data storage device a location information request including an identifier of an application and receiving second location information (<NUM>) indicating a location of a directory that is placed below the user-specified directory and uniquely assigned to the application as a response from the data storage device;
storage means (1d) for storing the second location information (<NUM>);
data processing means (1a) for executing the application, determining if there is a need to access the personal data of the user and producing, when it is determined there is the need to access the personal data of the user, first access target information (<NUM>) that is subordinated to the second location information (<NUM>) in the storage means (1d) and indicates a relative path and name of a target data file including the personal data of the user;
second access target information producing means (1e) for producing, based on the first access target information (<NUM>) and the second location information (<NUM>) in the storage means (1d), second access target information (<NUM>) indicating a storage location and name of the target data file; and
access means (1f) for making access to the target data file in the data storage device, based on the second access target information (<NUM>).