Method and system for providing image rich web pages from a computer system over a network

The present invention is related to a computer system that provides a web page to a requestor over a network. Aspects of the present invention include receiving by the computer system a request to access a web page and in response, determining whether a descriptor for the requested web page is in a session memory. If the descriptor is not in the session memory, it is retrieved from a database and the stored in the session memory. From there, the descriptor is used to determine whether the web page should be retrieved and returned to the requestor. By storing the descriptor in session memory, additional accesses to the database can be avoided when the descriptor is used for subsequent tasks.

FIELD OF INVENTION

The present invention relates to sharing digital images over a network, and more particularly to a method and system for providing image rich web pages from a computer system.

BACKGROUND OF THE INVENTION

Over the past several years, photosharing has become widely accepted by photo enthusiasts. Many websites currently exist that allow users to upload digital images to the site for storage on a server and for viewing by others over the Internet. Oftentimes, images are grouped to form an album web page so that the user can invite others to view the album web page, as opposed to each individual image.

This approach to photosharing, however, presents some disadvantages. In particular, users are required to upload digital images to the site, which can be time consuming, and the site requires extensive storage capacity to store the images of all the users, which can become expensive.

To address these concerns, the assignee of the present invention has developed a web-based peer-to-peer photosharing system in which all workstations and computers (peers) in the network store images locally and act as servers to other users on the network. A central site accessible by all the peers provides additional functionality, such as coordinating the peers, providing search capabilities for the peers, purchase order fulfillment, etc.

FIG. 1is a block diagram illustrating the web-based peer-to-peer environment. The peer-to-peer environment20includes a photosharing P2P network22, which comprises multiple peer servers24running peer node software26and web server software28. The peer node and server software24and26enable the users of the computers to share images with others in the network22through a web browser30without having to upload their pictures to a web site. A proxy server36at a central site provides supporting services to the peers24as well as providing a path through which a visiting computer32, i.e., one not belonging to the peer-to-peer network22, accesses images from the peer servers24via a web browser30. As used herein, the peer servers24, proxy server36and the visiting computer32may comprise any computing device, such as PCs, workstations, mobile phones, and PDAs, with components necessary for executing the appropriate software. Also, in a preferred embodiment, the physical communications network is the Internet, although any type of network could be used.

Each peer24stores album web pages and associated images locally. Each album web page is associated with a descriptor that includes information about the album, such as which images are included in the album and who is permitted to see the album. For example, if the album is private, only the owner is allowed to view the album; if the album is “public,” then everyone can access the album; and if the album is “restricted,” then the album is accessible only to selected users. In this case, the descriptor includes an access list. The descriptor for each album web page is stored in a database in the peer24.

When a peer24receives a request (via the proxy server36) to access an album web page from either another peer24or a visiting computer32, the peer24accesses the database to retrieve the descriptor associated with the requested album web page. From the descriptor, the peer24determines whether the requestor (e.g., peer user or user of the visiting computer) is permitted to access the album and which images are in the album web page. If the access is authorized, the peer24returns the album web page, which contains embedded images representing each of the album images.

Upon receipt of the album web page, the requestor's browser30interprets the web page and then initiates separate requests for each embedded image therein. When the peer24receives the request for the image, it accesses the database again to retrieve the descriptor for the album page in which the requested image resides to ensure: (1) that the requested image is actually in the associated album page; and (2) that the requestor has permission to access the album page and its contents, i.e., images.

This step is necessary to prevent unauthorized requestors from accessing protected images, because if the requestor knows the URL for an image, a request to access an image can be initiated independently from a request to access the album page in which it resides. Accordingly, for any request to access an image, the peer24should ensure that the requestor is authorized to access the album in which it resides. In this manner, the peer24supports photo sharing while honoring permission settings.

Although the process described above provides advantages over traditional photo sharing techniques, parts of the process are not optimal. In particular, each time an album is requested, the peer24must access the database to retrieve the descriptor associated with the requested album. Moreover, the peer24accesses the database to retrieve the descriptor each time an image in an album is requested. If an album contains 100 embedded images, a simple request to access and render the album web page would require 101 database accesses (one access for the album itself and 100 accesses for each image). Multiply these accesses by the number of requests for the same album page from different web servers30and the number of accesses quickly grows to an unmanageable level.

Accordingly, what is needed is an improved method and system for providing an image rich web page from a computer system. The method and system should accelerate access to images in an album, while honoring access restrictions to authorized requesters. The present invention addresses such a need.

BRIEF SUMMARY OF THE INVENTION

The present invention provides a method and system for providing a web page from a computer system. Aspects of the present invention include receiving by the computer system a request to access a web page and in response, determining whether a descriptor for the requested web page is in a session memory. If the descriptor is not in the session memory, it is retrieved from a database and then stored in the session memory. From there, the descriptor is used to determine whether the web page should be retrieved and returned to the requester.

According to the method and system disclosed herein, storing the descriptor for the album web page in session memory eliminates the need to access the database whenever information contained in the descriptor is needed again during the same session. By reducing the number of times the database is accessed, performance is enhanced.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to sharing digital images over a network, and more particularly to a method and system for providing image rich web pages from a computer system. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. For example, although the preferred embodiment is in the context of a peer-to-peer network, the same principles can be applied to a client-server environment where the guest browser communicates directly with the computer system storing the album and images. Thus, the present invention is not intended to be limited to the embodiments shown but is to be accorded the widest scope consistent with the principles and features described herein.

The present invention provides a method and system for providing image rich web pages from a computer system. In the present invention, data about an album that is used to authorize a requestor and to verify that an image is in a particular album is retrieved from the database and stored in session memory if such data is not already stored in session memory. Preferably, such retrieval from the database is performed once when a first request for the album is received by a peer during a session. By storing the data about the album in session memory, subsequent requests for the data can be retrieved from session memory quickly and the need to access the database is eliminated. By reducing the number of times the database is accessed, performance is enhanced.

FIG. 2is a detailed block diagram of an improved peer server200according to a preferred embodiment of the present invention, where similar components have the same reference numerals. According to the present invention, the peer server200includes an album servlet222, an image servlet224, session memory226and a database230. The album servlet222manages a request to access an album web page240in the peer server200, while the image servlet224manages a request to access an image233in an album web page240. The database230stores a descriptor232corresponding to an album web page240, and the session memory226stores a copy of the descriptor232corresponding to an album web page240when access to the album web page240is requested. By storing a copy of the descriptor232in session memory226, the descriptor232can be accessed directly from memory, as opposed to being accessed from the database230, when required. Thus, the number of times the database230is accessed is significantly reduced, and performance is enhanced.

Together,FIG. 3AandFIG. 3Bis a flowchart illustrating a process for providing an image rich web page according to the preferred embodiment of the present invention. Individually,FIG. 3Ais a flowchart illustrating a process for managing a request to access an album web page240, andFIG. 3Bis a flowchart illustrating a process for managing a request to access an image233in an album web page240according to a preferred embodiment of the present invention.

Referring toFIG. 2andFIG. 3A, the process for providing an image rich web page begins when the guest browser30transmits a request to access an album web page240(step300). In a preferred embodiment, the request is a URL that identifies the peer server200, the album servlet222, and an album identifier234for the requested album web page240. Typically, the album page's owner invites others to view the album web page240and provides the URL. When the URL is selected by a user of the computer32, the web browser30transmits the request.

Once the request is transmitted, the proxy server36receives the request and routes the request to the identified peer200(step302). When the peer200receives the request, it invokes the album servlet222, which interprets the request and determines whether the descriptor232corresponding to the requested album web page240is stored in session memory226(step304). If the descriptor232is not stored in memory, the album servlet222accesses the database230, retrieves the descriptor232and stores the descriptor232in session memory226(step306). Next, the album servlet222accesses the descriptor232from session memory226to determine a sharing type238of the album web page240(step308).

The sharing type238of the album web page240defines who can access the album web page240. In a preferred embodiment, the sharing type238can be one of four types: private, public, restricted and password protected. Those skilled in the art will readily appreciate that other sharing types can be implemented and the present invention is not intended to be limited to the four described below.

If the share type238is “private” (step310) access to the album web page240is restricted to the page's owner. Thus, the album servlet222will return a message, e.g., an HTTP Error Code 403, denying access to the album140(step312). The proxy server36in turn passes the response to the guest browser30(step314).

If the share type is “restricted” (step316), access to the album page240is limited to those listed on an access list239. The album servlet222authenticates the requester (step318) by any suitable process, for example, by requiring the requester to provide authentication data, e.g., username and password, and verifying the authentication data. Once authenticated, the album servlet222then authorizes the requestor (step320) preferably by utilizing the access list239in, the descriptor232from session memory226. Once the requestor is authorized, the album servlet222returns the requested album web page240to the proxy server36(step322) and the proxy server36forwards the album web page240to the guest browser (step314).

If the share type238is “password protected” (step317), access to the album page240is granted only if the requestor provides the correct pass phrase or password237. In a preferred embodiment, the album owner provides the password237to invitees by including it with the invitation to view the album page140or through any other suitable manner, i.e., an email message or the like. The album servlet222prompts the requestor for the password237and authorizes the requester (step319) by comparing the requestor's response to the password237in the descriptor232from session memory226. In a preferred embodiment, when the requestor is authorized, i.e., a valid password has been provided, the peer server200stores a cookie38associated with the requestor's browser30in session memory226so that for subsequent requests to access the album web page140, the requestor will not be required to provide the password again.

By protecting the album page140with a password237, an album page owner can share the album page140with others without requiring the invitees to register, i.e., provide authentication data. In other words, authentication is not required.

Finally, if the share type238of the album page240is “public,” the album servlet222returns the requested album web page240to the proxy server36(step322) and the proxy server36forwards the album web page240to the guest browser (step314).

As stated above, the album web page240includes at least one embedded image233.′ Thus, after the guest browser30receives the album web page240from the proxy server36, it interprets the page240and issues a separate request for each of the embedded images233.′

Referring toFIG. 2andFIG. 3B, the process for providing an image rich web page continues when the guest browser30transmits a request to access an image233in the album web page240(step350). In a preferred embodiment, the request is a URL that identifies the peer server200, the image servlet224, an image identifier236, the image size, and the album identifier234for the album web page240in which the image is embedded.

The proxy server36routes the request to the identified peer200(step352). When the peer200receives the request, it invokes the image servlet224, which interprets the request and determines whether the descriptor232corresponding to the album web page240is in session memory226(step354). If the descriptor232is not in memory, e.g., because the request for the image233was transmitted without requesting access to the album page240, the image servlet accesses the database230, retrieves the descriptor232and stores the descriptor232in session memory226(step358).

Next (or if the descriptor232was already in session memory226), the image servlet224accesses the descriptor232from session memory226and confirms that the requested image233is in the album web page240(step356). Preferably, if the image233is not in the album240, the image servlet224returns a message denying access to the image233. The image servlet224then determines the sharing type238of the album web page240(step360) to determine whether the requestor is authorized to access the image233. As stated above, this is done to prevent unauthorized requestors from accessing protected images directly, as opposed to through an album page140.

As before, if the sharing type238is “private” (step362), a message denying access to the image233is returned (step364). If the sharing type is restricted or password protected (step368), the image233is returned (step374) only after the requestor has been authenticated (step370) and/or authorized (step372), as described above. Preferably, if the requester has been authenticated previously in the session, the authentication process need not be performed again, as is well known in the art. In addition, if the requestor previously provided a valid password and the cookie38for the browser30is in the session memory226, the image servlet224does not require the requestor to provide the password237again. Finally, if the share type238is public (step376), the image servlet224returns the image233(step374).

The proxy server36receives the response from the peer200and forwards it to the guest browser30(step366). If the album web page240includes more embedded images233′ (step378), the guest browser30transmits another image request (step350), and steps352through366are repeated. If all the embedded images233′ have been returned, the guest browser30renders the images233and displays the album web page34(step380).

According to the preferred embodiment described above, access to the database230is required only if the descriptor232associated with an album web page240is not in session memory226and only when the requestor is authenticated for the first time in a session. Thereafter, any request to access the album web page240from the same or perhaps a different web browser30and any request to access an image233in an album web page240can be managed by accessing the descriptor232in session memory, as opposed to accessing the database230. Because accessing session memory226is more efficient than accessing the database230, the preferred embodiment of the present invention offers substantial cost savings in both time and resources.

Although the preferred embodiment has been described in relation to a web-based peer-to-peer network, such as that illustrated inFIG. 1, those skilled in the art would readily appreciate that the same principles can be applied to a conventional client-server environment where the computer32communicates directly with the peer server200without utilizing the proxy server36. Moreover, the principles described could also be applied to other similar network configurations, including but not limited to the Internet.

That said, further enhancements are available in the web-based peer-to-peer network. According to a second preferred embodiment, the proxy server36provides additional support for the peers200that further improves the process for sharing image rich web pages240.

FIG. 4is detailed block diagram of the peer server200and enhanced proxy server400according to another preferred embodiment of the present invention, where similar elements are identified by the same reference numerals. According to this preferred embodiment, the enhanced proxy server400is capable of authenticating the requestor and of serving images directly. As is shown inFIG. 4, the enhanced proxy server400includes session memory420, a database430, and cache440. The session memory420stores a username422for each user that makes a request during a session. The database430includes user authentication information432that is used to authenticate the user who makes a request during a session. Presumably, the user authentication information432has been collected by either the proxy server400or by a peer server200during a registration process that takes place independently from and prior to the process described by the present invention. This registration process is well known in the art and will not be further described.

According to the preferred embodiment, the cache440stores images436that have been returned from the peer server200during the process for providing an image rich web page240. An image436is cached according to the peer server200from which it originates, resolution, and image identifier236. Preferably, an image436need not be cached by album identifier234because several album web pages240can include the image436. By caching images436in the proxy server400, the proxy server400can return a requested image233in an album web page240directly if the requested image is in cache440and if the cached image436is current. Thus, the peer server200is not required to access and return the image233, which further enhances performance.

TogetherFIG. 5,FIG. 6,FIG. 7andFIG. 8illustrate a process for providing an image rich web page utilizing the enhanced proxy server400according to a preferred embodiment of the present invention. Refer first toFIG. 4andFIG. 5.

FIG. 5is a flowchart illustrating a process for managing a request to access an album web page according to the preferred embodiment. The process begins as usual when the guest browser transmits a request to access an album web page240on the peer200(step500). Once the request is transmitted, the proxy server400receives the request and routes the request to the identified peer200(step502). When the peer200receives the request, it invokes the album servlet222, which interprets the request and determines whether the descriptor232corresponding to the requested album web page240is stored in session memory226(step504). If the descriptor232is not stored in memory, the album servlet222accesses the database230, retrieves the descriptor232and stores the descriptor232in session memory226(step506). Next, the album servlet222accesses the descriptor232from session memory226to determine the sharing type238of the album web page240(step508).

If the share type238is “private” (step510), the album servlet222will return a message, e.g., an HTTP Error Code 403, denying access to the album140(step512). The proxy server400in turn passes the response to the guest browser30(step514).

If the sharing type is “restricted” (step515), the album servlet222redirects the browser30to the proxy server400to authenticate the requestor (step517) if the requestor has not already been authenticated during the session (discussed below). In response to receiving the redirected request, the proxy server400authenticates the requestor (step518).

FIG. 6is a flowchart illustrating a process for authenticating the requestor according to a preferred embodiment of the present invention. The proxy server400displays a login page requiring the requestor to provide authentication information, such as a username and password (step602). The proxy server400then accesses the user authentication information432in the database430to authenticate the requestor (step604). Once the requestor is authenticated, the proxy server400stores the username422in session memory (step606). Then the proxy server400redirects the browser30back to the peer200and also provides the username422(step608).

In a preferred embodiment, because the requestor has been authenticated, the proxy server400can now attach a token to every subsequent HTTP request from the requestor/browser30that includes the username422associated with the requestor/browser30. When the peer200receives the request from the proxy server400and interprets the username, it immediately recognizes that the requestor/browser30has been authenticated previously and that no further authentication is necessary.

Referring again toFIG. 5, after the requestor has been authenticated by the proxy server400(step518), the peer200authorizes the requestor to access the album web page240(step520).

FIG. 7is a flowchart illustrating a process for authorizing the requestor according to a preferred embodiment of the present invention. In this case, the album servlet222extracts the requestor's username422provided by the proxy server400(step710) and then reads the access list239associated with the requested album page240from session memory (step712). If the username422matches a name on the access list239(step714), then access is authorized (step716). Otherwise, access to the album page240is denied (step718).

Referring again toFIG. 5, if the sharing type238is “password protected” (step516), the album servlet222prompts the requestor for the password237and authorizes the requester (step519) by comparing the requestor's response to the password237in the descriptor232from session memory226. Upon authorization, the cookie38associated with the requestor's browser30is stored in session memory226(step519).

After the requestor is authorized to access the requested album page240(steps519,520), the album servlet222returns the requested album web page240to the proxy server400(step522) and the proxy server400forwards the album web page240to the guest browser (step514).

Finally, if the share type238of the album page240is “public” (step524), the album servlet222returns the requested album web page240to the proxy server400(step522) and the proxy server400forwards the album web page240to the guest browser (step514).

As described above, after the guest browser30receives the album web page240from the proxy server400, it interprets the page240and issues a separate request for each of the embedded images233.′

FIG. 8is a flowchart illustrating a process for managing a request to access an image233in an album web page240utilizing the enhanced proxy server400according to a preferred embodiment of the present invention. Referring toFIG. 4andFIG. 8, the guest browser30transmits a request to access an image233in the album web page240(step800). Preferably, the request is the URL described above that identifies the peer server200, the image servlet224, the image identifier236, the image size, and the album identifier234for the album web page240in which the image is embedded.

The proxy server400receives the request and determines whether the requested image is in cache440(step802) preferably by utilizing image identifer236in the request URL. If the requested image233is in cache440, the proxy server400appends to the request a timestamp435associated with the cached image436(step806). In addition, as indicated above, if the browser30has been authenticated previously, the token containing the username422is also attached to the request. The proxy server400routes the request to the peer200identified in the request URL (step804).

When the peer200receives the request, it invokes the image servlet224, which interprets the request and determines whether the descriptor232corresponding to the album web page240is in session memory226(step808). If the descriptor232is not in memory, the image servlet224accesses the database230, retrieves the descriptor232and stores the descriptor232in session memory226(step810). Next (or if the descriptor232was already in session memory226), the image servlet224accesses the descriptor232from session memory226and confirms that the requested image233is in the album web page240(step811). Preferably, if the image233is not in the album web page240, the image servlet224returns a message denying access to the image233. The image servlet224then determines the sharing type238of the album web page240(step812).

Once again, if the sharing type238is “private” (step814), a message denying access to the image233is returned (step816). If the sharing type is “restricted” or “password protected” (step820), the image servlet224determines whether the requestor/browser needs to be authenticated by checking the request for a username422. If the username422is found, then the requestor/browser has been authenticated previously and additional authentication is not required. If the username422is not found and the sharing type is “restricted,” then the image servlet224redirects the browser30to the proxy server400for authentication (step822), as described above inFIG. 6and the related text.

Once the requestor/browser30has been authenticated or if the sharing type is “password protected,” the image servlet224authorizes the requestor to access the album web page240and therefore the image233included therein (step824). As before, the image servlet224does this either by reading the access list239in the descriptor232in session memory226, and determining whether the requestor's username422is on the access list239(seeFIG. 7), or by determining whether the cookie38associated with the browser30is present in the session memory and if not, requiring the requester to provide a valid password237.

Once the requestor is authorized (or if the sharing type238is “public” (step832)), the requestor is granted access to the image233. If the requested image233is not in the proxy server's cache440, i.e., the request does not include the timestamp435, the image servlet224returns the requested image233from the peer server200, as described above. If, however, the requested image233is in the proxy server's cache440, the image servlet224determines whether the cached image436is the same as that image233stored in the peer server200by comparing the timestamp435associated with the cached image436with a timestamp235associated with the image233stored in the peer server200(step826). Preferably, the timestamp235associated with the image233is in the descriptor232so that the image servlet224performs this step without accessing the database230or the image233itself.

If the cached timestamp435is older (step826), the cached image436is outdated and therefore, the image servlet224returns the image233stored in the peer server200(step830). If the cached timestamp435is not older, the cached image436is current and the image servlet224transmits a message to the proxy server400indicating that the image233content has not changed. Preferably, the message is a HTTP code 304—Content Unchanged.

If the proxy server400receives the HTTP code 304 message, it retrieves the cached image436(step828) and returns it to the browser30(step818). If, however, the proxy server400receives the image233from the peer server200, it stores the image233in cache440(step831) before returning the image233to the browser30(step818).

If the album web page240includes more embedded images233′ (step834), the guest browser30transmits another image request (step800), and steps802through832are repeated. If all the embedded images233′ have been returned, the guest browser30renders the images233and displays the album web page34(step836).

In a further embodiment of the present invention, a computer readable medium containing program instructions for providing a web page that includes at least one embedded image from a computer system over a network may be provided. The computer readable medium may include instructions, which, in response to receiving a request over the network to access the web page, determine whether a descriptor for the requested web page is stored in a session memory, where the descriptor includes information required to determine whether a requestor is authorized to access the web page and the at least one embedded image. The computer readable medium may also include instructions which, if the descriptor is not stored in session memory, retrieve the descriptor corresponding to the web page from a database and store the descriptor in session memory. In addition, the computer readable medium may include instructions, which utilize the descriptor to determine whether to return the web page, where additional database accesses are avoided for subsequent tasks requiring the descriptor. In further embodiments of the present invention, the computer readable medium may include the functionality discussed with reference toFIGS. 2 through 8.

The present invention provides a method and system for providing image rich web pages from a computer system. In the present invention, information in a descriptor associated with an album web page is retrieved from the database and stored in session memory when the album or the image is accessed for a first time in a session. By storing the descriptor in session memory, the information in the descriptor can be retrieved from session memory, as opposed to accessing the database. By reducing the number of times the database is accessed, performance is enhanced.

The present invention has been described in accordance with the embodiments shown, and one of ordinary skill in the art will readily recognize that there could be variations to the embodiments. For example, while the preferred embodiment has been described in relation to a web-based peer-to-peer network, those skilled in the art would readily appreciate that the same principles can be applied to a conventional client-server environment where the client computer communicates directly with the peer server without utilizing the proxy server. Any variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.