FIELD OF THE INVENTION
The present invention relates generally to organizing, maintaining and accessing electronic data. More particularly, the invention concerns organizing, accessing and/or maintaining electronic image and other types of user data so as to provide a more convenient way to browse, search and view electronically stored information.
BACKGROUND OF THE INVENTION
Digital cameras and other devices for digital imaging, video recording and audio recording have become commonplace. For example, many wireless telephones and other mobile devices also create digital photographs, video segments and audio segments. The increasing ease with which users can create and store digital images creates challenges, however. Unlike conventional photography, where costs of film and developing tend to limit the number photographs created on a given occasion, electronic imaging encourages users to create a larger number of images. Because there are no film or developing costs involved, it is easier to generate multiple images. However, this advantage often comes at the cost of having to review and organize a much larger number of images. As more and more images accumulate, it becomes more and more difficult for a user to organize the images, as well as to find a particular stored image. In part because of the inconvenience and time required to organize these images into folders (or “albums”) and/or delete redundant and/or undesirable images, many users simply allow a large number of images (and/or video clips and/or audio clips) to accumulate.
When a user later wishes to locate one or more images, the user must often browse through a great number of images in order to find the material of interest. In many cases, the mobile device used to create the images automatically names each image file. However, those names are usually not descriptive of the image, and many users do not take the time to rename the image files. Accordingly, the user must then view the images themselves in order to find the desired material. In some cases, numerous smaller versions of those images (or “thumbnails”) can be arrayed on a display screen, thereby allowing the user to see multiple images at once. These thumbnails may sometimes be arranged chronologically, i.e., based on the dates of image creation. Although such an array is helpful in certain respects, thumbnail images are typically low resolution and not useful for seeing finer details. It is sometimes difficult to evaluate image quality from a thumbnail. Moreover, many images will often have very similar content (e.g., a user may have taken two or three images of persons posing for a photograph). Accordingly, the user is often required to sequentially select multiple thumbnail images for enlargement in order to find a single image of interest. This is often time-consuming and inconvenient.
Similar challenges exist with regard to other types of user data files. Throughout this specification (including claims), “user data file” also includes, but is not limited to, video files (e.g., MPEG and other file types), audio files (e.g., MP3, MIDI, WAV and other file types), text files, message files (e.g., SMS and MMS messages), e-mails, HTML files, presentations, etc. As with digital images, many wireless telephones and other types of portable devices have increased the ease with which various types of data files may be generated and/or retained. Users often accumulate large numbers of various types of files and want to save many of those files for future reference. As with image files, however, organizing these other file types can be a tedious process. Accordingly, many users fail to organize file collections, thereby increasing the difficulty when later searching for a desired file. For these and other reasons, there remains a need for systems and methods by which desired images and other types of user data can be more conveniently located.
SUMMARY OF THE INVENTION
Aspects of the present invention are directed to allowing a user to locate user data files stored in a memory. User data files for electronic images and/or other types of information are stored in the memory and have priorities based on prior activity regarding those files. As used in this specification (including claims), a file “priority” generally refers to a manner of distinguishing a file from other files. A priority may be a value assigned to a file (e.g., in a table or other listing of files, or as an attribute or metadata included in the file itself). Priority also includes a file ranking without explicit assignment of a value to that file, such as by placing a file in a particular location within an ordered group of files. By way of example, file activities affecting image file priority can include enlarging an image, editing an image and copying an image to another folder. When the user views an array of thumbnail images in some embodiments, thumbnail images are only displayed for user data files meeting a priority threshold. The user can adjust the priority threshold so as to increase or decrease the number of thumbnail images shown.
In a first embodiment, the invention includes a method for providing information about user data files based on file priorities. A plurality of user data files are stored in a memory, each of the user data files having a priority. One or more file actions are performed with regard to one or more user data files of the plurality. The priorities of the user data files are modified in response to performance of those file actions. A designation of a priority threshold is received, and a determination made regarding which user data files have a priority above that threshold. Information is then provided about user data files of the plurality having a priority above the priority threshold. A second embodiment includes a machine-readable medium having instructions for performing a method similar to that of the first embodiment. A third embodiment includes a server or other electronic device having a processor configured to perform steps similar to those of the first embodiment.
These and other features of the invention will be apparent upon consideration of the following detailed description of preferred embodiments.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing summary of the invention, as well as the following detailed description of preferred embodiments, is better understood when read in conjunction with the accompanying drawings, which are included by way of example, and not by way of limitation with regard to the claimed invention.
FIG. 1 is a block diagram of an example of a wireless communication system in which various aspects of the present invention may be implemented.
FIG. 2 is a block diagram of an illustrative mobile device according to at least one embodiment of the invention.
FIG. 3 is a block diagram of a server according to at least one embodiment of the invention.
FIG. 4 shows, in partially schematic form and according to at least some embodiments of the invention, a thumbnail view of multiple images on a display, corresponding image files, and a table for data regarding the corresponding image files.
FIG. 5 shows, in partially schematic form and according to at least some embodiments of the invention, update of an image file table based on enlargement of an image.
FIG. 6 shows, in partially schematic form and according to at least some embodiments of the invention, update of an image file table based on editing of an image.
FIG. 7 shows, in partially schematic form and according to at least some embodiments of the invention, update of an image file table based on copying of an image to an album.
FIGS. 8-11 show, in partially schematic form and according to at least some embodiments of the invention, different thumbnail image displays based on different priority levels.
FIG. 12 shows, in partially schematic form and according to at least certain other embodiments of the invention, a thumbnail image display based on a specified priority level.
FIGS. 13 and 14 show examples of user interfaces for adjusting a priority threshold for display of thumbnail images.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
FIG. 1 shows an example of a wireless communication system 110 in which the systems and methods of the present invention may be advantageously employed. One or more network-enabled remote control devices or mobile devices 112, such as a personal digital assistant (PDA), digital camera, cellular phone, mobile terminal, or combinations thereof, is in communication with a server 114. Although not shown in FIG. 1, server 114 may act as a file server, such as a personal server or personal storage device, for a network such as home network, some other Local Area Network (LAN), or a Wide Area Network (WAN). Server 114 may be a computer or other device capable of storing and accessing data, such as a laptop, set-top box, DVD, television, PVR, DVR, TiVo device, personal portable server, personal portable media player, network server or other device capable of storing and accessing data, and which is coupled to a display device 158. Mobile device 112 may communicate with server 114 in a variety of manners; in at least some embodiments, a single mobile device 112 communicates with a server 114 in multiple manners. For example, mobile device 112 may communicate with server 114 via wireless network 118. Wireless network 118 may be a third-generation (3G) cellular data communications network, a Global System for Mobile communications network (GSM), or other wireless communication network.
Remote control device or mobile device 112 may also have one or more ports allowing a wired connection to server 114 via, e.g., universal serial bus (USB) cable 115. Mobile device 112 may also be capable of short-range wireless connection 120 (e.g., a BLUETOOTH, WLAN, WiFi or IrDA link) to server 114. A mobile personal server 113 may also be used. Personal server 113, which may be relatively small and/or more portable than server 114, provides additional storage capacity for images and other user data created with mobile device 112 (or created by other devices). In at least some embodiments, personal server 113 may be the same as the server 114, or may have some or all of the features of server 114 described below. Data may be periodically saved from mobile device 112 to personal server 113 via USB, BLUETOOTH or other type of link (shown collectively as an arrow from mobile device 112 to personal server 113). Data from personal server 113 may then be later downloaded to server 114 via USB, BLUETOOTH or other type of link (also shown collectively as an arrow).
Server 114 may act as a repository for storing files received from mobile device 112 and/or from other sources. Server 114 may have, or be coupled to, a wireless interface 122 configured to transmit communications (such as messages, files, or other data) to, and receive communications from, mobile network 118 or WLAN network. Server 114 may alternatively (or also) have one or more other communication network connections. For example, server 114 may be linked (directly or via one or more intermediate networks) to the Internet, to a conventional wired telephone system, or to some other communication or broadcast network, such as a TV, a radio, or IP datacasting network.
In one embodiment, mobile device 112 has a wireless interface configured to send and/or receive digital wireless communications within wireless network 118. As part of wireless network 118, one or more base stations (not shown) may support digital communications with mobile device 112 while the mobile device is located within the administrative domain of wireless network 118. The base station of wireless network 118 that is in communication with mobile device 112 may be the same or a different base station that is in communication with server 114. Indeed, mobile device 112 and server 114 may each be in communication with different wireless networks (e.g., mobile device 112 could be roaming), which could in turn be interlinked via one or more intermediate wired or wireless networks. For simplicity, server 114 and mobile device 112 are shown within the same wireless network 118.
Mobile device 112 communicates with server 114 via wireless network 118 and is configured to transmit user data for remote storage on server 114. As used herein, “user data” refers to information stored in a “user data file.” As previously discussed, a “user data file” includes, but is not limited to, video files (e.g., MPEG and other file types), audio files (e.g., MP3, MIDI, WAV and other file types), text files, message files (e.g., SMS and MMS messages), e-mails, HTML files, presentations, etc. Mobile device 112 may also be configured to access data previously stored on server 114. In one embodiment, file transfers between mobile device 112 and server 114 may occur via Short Message Service (SMS) messages and/or Multimedia Messaging Service (MMS) messages transmitted via short message service center (SMSC) 124 and/or a multimedia messaging service center (MMSC) 126. Although shown as part of network 118, SMSC 124 and MMSC 126 may be part of another network or otherwise outside of network 118. Although shown as separate logical entities, SMSC 124 and MMSC 126 could be a single entity. Further, SMSC 124 and MMSC 126 may coordinate via signaling between themselves for improving the file transfer process. For example, because SMSC 124 and MMSC 126 may be store-and-forward systems, rather than real-time systems, a file requested via an SMS message from mobile device 112 may still reside on MMSC 126 based upon a previous request. As such, SMSC 124 may copy MMSC 126 on an SMS file request and, if applicable, MMSC 126 may notify the user of the previously stored file. Further, MMSC 126 may simply transfer the requested file based on its stored copy of the file. In other embodiments, MMSC 126 may act as a repository for files, and mobile device 112 may simply request transfer of files from MMSC 126.
As shown in FIG. 2, mobile device 112 may include processor 128 connected to user interface 130, one or more wireless communications interface 132, such as cellular telephone connection or short-range wireless connection (such as Bluetooth, WLAN, WiFi or IrDA), memory 134 and/or other storage, display 136, and digital camera 138. User interface 130 may further include a keypad, four arrow keys, joy-stick, data glove, mouse, roller ball, touch screen, voice interface, or the like. Software 140 may be stored within memory 134 and/or other storage to provide instructions to processor 128 for enabling mobile device 112 to perform various functions. For example, software 140 may configure processor 128 to enable mobile device 112 to take digital photographs via digital camera 138, to automatically name a photograph, to save photographs as image files, to transfer image files to server 114, to retrieve and display image files from server 114, and to browse the Internet using communications interface 132. Software 140 may further configure processor 128 to enable mobile device 112 to create, store, play, send and/or receive audio, video, text and/or other types of user data files. Audio files (or audio portions of video files) are displayed by playing the file contents on a speaker within mobile device 112 (not shown) or on headphones (also not shown). Although not shown, communications interface 132 could include additional wired (e.g., USB) and/or wireless (e.g., BLUETOOTH, WLAN, WiFi or IrDA) interfaces configured to communicate over different communication links.
As shown in FIG. 3, server 114 may include processor 142 coupled via bus 144 to one or more communications interfaces 146, 148, 150 and 152. Interface 146 may be a cellular telephone or other wireless network communications interface. There may be multiple different wireless network communication interfaces. Interface 148 may be a conventional wired telephone system interface. Interface 150 may be a cable modem. Interface 152 may be a BLUETOOTH interface or any other short range wireless connection interface. Additionally, there may be multiple different interfaces. Server 114 may also include volatile memory 154 (e.g., RAM) and/or non-volatile memory 156 (such as a hard disk drive, tape system, or the like). Software and applications may be stored within memory 154 and/or memory 156 that provides instructions to processor 142 for enabling server 114 to perform various functions, such as processing file transfer requests (such as for image files), storing files in memory 154 or memory 156, displaying images and other data, and organizing images and other data. The other data may e.g. video files, audio files, emails, SMS/MMS messages, other message files, text files, presentations, etc. Although shown as part of server 114, memory 156 could be remote storage coupled to server 114, such as an external drive or another storage device in communication with server 114. Preferably, server 114 also includes or is coupled to a display device 158 (FIG. 1) via a video interface (not shown), which may or may not have a speaker for outputting audio. Display device 158 may be a computer monitor, a television set, an LCD projector, or other type of display device. In at least some embodiments, server 114 also includes a speaker 155 over which audio clips (or audio portions of video clips) stored in memory 154 or 156 may be played. In some other embodiments input device 112 and display 158, or alternatively input device 112, display device 158 and server 114, may be combined in a single device unit, such as a mobile phone, a digital camera, a digital audio device, etc.
A user accesses server 114 through a local input device, such as input device 112. Server 114 also displays various user interfaces (e.g., such as are described below) on display device 158 in addition to thumbnails, enlarged images, and other information. Possible input devices 112 include wired and wireless keyboards, mice and remote control units. Mobile device 112 could also function as a remote control unit and communicate with server 114 by BLUETOOTH or other wireless link, or via a cable connection to a port on mobile device 112. In such embodiments, various user interfaces (including the thumbnail views, slider bars and other interfaces described below) may be displayed on display 136, and files may be presented on mobile device 112 (e.g., images enlarged, video and audio clips played, text displayed, etc.). In some embodiments, server 114 is accessible remotely via mobile device 112 or (other devices) over wireless network 118, the Internet, or another communication network.
According to one embodiment of the invention, a method is provided for prioritizing files (i.e., assigning or modifying a file priority) stored on a device such as server 114, and for then displaying content of (or information about) those files based on those priorities. As used in this specification (including claims), “displaying” file content includes reproducing an audio file (on a speaker or other device) or the sound portion of a video or other file. A file type for which the file content has visual and sound components can be “displayed” if either a sound or visual component is reproduced. Although the following description refers to photographic image files received from one or more mobile devices 112, the invention is not limited by data type or source, nor by file type, format or source. In particular, embodiments of the invention include methods for prioritizing and/or displaying content/information for any type of user data file.
As images are created by mobile device 112, each image is stored as a data file in memory 134. Each image file is assigned a file name, and the files are ordered based on those assigned file names or based on the order in which the images are created. At some point, a user transfers those image files to server 114, where they are placed in storage memory 156. When initially transferred from mobile device 112 to server 114, image files are stored in the same order in which they were stored in memory 134 of mobile device 112. Other user data file types may be similarly named, ordered transferred and stored.
At some later point, a user then accesses images stored within storage memory 156. In at least some embodiments, the user is able to view multiple image files simultaneously as thumbnail images in a thumbnail view user interface. FIG. 4 shows, in partially schematic form, a thumbnail view interface on display 158. For simplicity, images are represented within the drawings as stippled and numbered boxes; an image file for a particular image is represented in the drawings as an unstippled box having the same number. As shown in FIG. 4, thumbnails of images or files 1 through 15 are arrayed on display 158 in chronological order, i.e. based on order of date/time of image creation. Additionally, thumbnails of images or files may be presented in a time-line manner, i.e. images or files related to specific periods or a moments of time are presented in own their specific groups, and the groups are presented in a time-line order, e.g. by date order. One or more groups in the time-line may be presented on the display simultaneously. Corresponding image files (which may be in JPEG or other format) are stored in storage memory 156 in one or more file folders 164. As shown in FIG. 4, only a limited number of thumbnails (fifteen in this example) are viewable on display 158 at one time. However, folder 164 contains numerous other image files, represented collectively as vertical ellipses above and below image files 1 and 15 (image file m represents an arbitrary image file preceding image file 1, and image file n represents an arbitrary image file following image file 15). “Page forward” and “page back” arrows 160 (or other appropriate interface) are provided in the thumbnail display so that the user may move forward (or backward) to additional screens (or pages) of thumbnail images. If the user selects the page back arrow, for example, thumbnail images for image files that chronologically precede file 1 are displayed. If the user selects the forward arrow, thumbnail images for image files that chronologically follow file 15 are displayed. Similarly, when presented in a time-line manner, arrows 160 may be used to scroll between groups in the time-line.
As also shown in FIG. 4, a table 166 having metadata information is associated with the image files in folder 164. Associated with each image file is a row having various metadata fields. A first field (“viewed”) holds a value corresponding to the number of times that image file has been enlarged for viewing (i.e., in a non-thumbnail view). In some embodiments, the “viewed” field (or a separate field) may also hold value(s) corresponding to the duration for which an image has been viewed. A second field (“edit”) holds a value representing whether (and/or, in some embodiments, the degree to which) the image file has been edited or manipulated. A third field (“album”) holds a value indicating whether the image has been copied to one or more albums. For example, a user may have grouped selected images from a particular event into a separate album (or folder) for that event, but not deleted those image files from folder 164. Such images would thus be accessible either by viewing the separate album, or by finding the images in a chronological thumbnail view of image files in folder 164. Although table 166 contains three named fields for each image file, numerous other fields (represented collectively as an ellipsis) could be added or substituted for the fields shown. For example, each image file could also have a field holding a value indicating which user of multiple users created the image file. As will be appreciated in light of the following explanation, such a field would permit each of multiple users to locate and view images that he or she created when images created by multiple users are stored in server 114. As another example, each image file could have a field holding a value based on the number of times that the image has been sent or received as an e-mail or as a file attachment to some other type of communication. Such a field could be used to locate and view thumbnails of images considered important enough to send to other persons. Still other examples include fields indicating whether the file has been annotated, whether there are “bookmarks” to the file from other sources, and/or whether the file contains links to other files. A field could be included for a manually input priority level assigned by a user. For video and audio files, a field could indicate whether the user has watched or listened to a portion of the file or to the entire file, and/or to the amount of the file that has been watched or to which the user has listened.
In alternate embodiments, file-specific fields may be separately implemented in each file. In still other embodiments, each file may only have a single priority value calculated from metadata of the type stored in table 166, and the underlying metadata used to calculate priority may not be saved.
In FIG. 5, a user has selected a thumbnail image of interest (thumbnail 8), and the image is enlarged on display 158. When thumbnail image 8 is enlarged, processor 142 automatically updates the “viewed” field of image file 8 to indicate that the image has been selected by the user for enlarged viewing. In the embodiment of FIG. 5, the “viewed” field holds a value corresponding to a cumulative number of times the image has been enlarged. In other embodiments, the “viewed” field holds a graduated ranking based on how many times the image has been enlarged (e.g., “1” if enlarged between 1 and 3 times, “2” is enlarged between 4 and 10 times, “3” if enlarged more than 10 times). In still other embodiments, the viewed field simply holds a “0” if the image has never been enlarged and a “1” if the image has been enlarged (regardless of how many times).
In FIG. 6, the user has next selected a thumbnail image 4 (thumbnail 4) for enlargement, and then edited and manipulated the enlarged image. In the example of FIG. 6, the user has rotated image 4 counterclockwise, and has cropped the rotated image from the bottom and right sides. As in FIG. 5, processor 142 automatically updates the “viewed” field for image file 4 to indicate that the image has been enlarged. In this case, however, processor 142 further updates the “edit” field based on the edits made to and the manipulation of the enlarged image. In the embodiment of FIG. 6, the “edit” field value is either “0” or “1”; the value is “0” if the image has never been edited or manipulated, and “1” if the image has been edited or manipulated (regardless of how many times or to what extent). In other embodiments, the “edit” field is updated with a value corresponding to the number of edits and/or manipulations. This may be a simple count, a graduated ranking based on the number of edits and/or manipulations, or some other value based on the number of edits and/or manipulations. In still other embodiments, the “edit” field value is updated based on the types of edits and/or manipulations. For example, if the image has been rotated (regardless of how many times), the “edit” field value is incremented by 1. If the image has been cropped (regardless of how many times), the “edit” field value is incremented by 2. Other types of actions could similarly cause incrementing of the “edit” field value. Of course, the “edit” field can be updated in numerous other manners based on the number and/or types of edits and/or manipulations. In some embodiments, “edit” field data is stored with regard to the original image file, while in other embodiments the “edit” and other field data is stored with regard to a separate file for the edited/manipulated image. In still other embodiments, the edit field data is stored with regard to the original image file and with regard to a separate file for the edited/manipulated image. In some embodiments, there are separate “edit” and “manipulated” fields for a file.
In FIG. 7, the user selects a thumbnail image (thumbnail 13) for copying to a separate folder (or “album”). As in FIGS. 5 and 6, processor 142 automatically updates the “album” field for image file 13 to indicate that the image has been copied to an album. In this case, the user has elected to copy image file 13 to the album without first enlarging the image. Accordingly, the “viewed” value is 0. If the user had first enlarged image 13 and then copied the image file to the album, the “viewed” field would have a value of 1. In the embodiment of FIG. 7, the “album” field value is either “0” or “1”; the value is “0” if the image has never been copied to an album, and “1” if the image has been copied to one or more albums. In other embodiments, the “album” field is updated with a value corresponding to the number of albums to which the image has been copied. This may either be a simple count of the number of albums, or a graduated ranking based on the number of albums. In the embodiment shown, the “album” field value remains the same even if the user later deletes the image from the album(s) to which it has been copied. In other embodiments, deletion of an image from an album causes update (e.g., decrementing) of the “album” field value for that image.
As the user (or users) enlarges, edits and/or copies additional images (whether in the same session or in multiple sessions), processor 142 makes similar updates to table 166. Using the data in table 166, processor 142 modifies the way in which thumbnails are displayed for image files in folder 164. Instead of displaying thumbnail images for all image files in folder 164, processor 142 only displays images meeting a designated priority threshold. In particular, processor 142 computes a priority for each image file based on the values in the “view,” “edit” and “album” fields for that image file. Based on the priorities for each image, processor 142 determines which image files to display as thumbnails.
FIG. 8 shows table 166 after the user has enlarged, edited and copied additional image files. By providing desired priority level input using slider bar 170 or other appropriate user interface, the number of thumbnails displayed is limited based on the values in table 166. By selecting “ALL” (as shown in FIG. 8), thumbnails are shown for all image files in folder 164. In other words, the priority threshold is such that all image files meet the threshold, and the thumbnail image display is not adjusted based on the values in table 166. Additionally, the number of thumbnails displayed may also be filtered before or after providing the desired priority level. For example, the user could specify that thumbnail images having a particular priority level and a particular keyword (e.g., “summer” and “2003”, “family,” “mother,” etc.) as content or metadata should be displayed.
In FIG. 9, the user has selected priority level “A.” Based on this selection, processor 142 displays thumbnails for image files which have previously been enlarged, edited or copied. In other words, the priority threshold requires prior performance on a file of at least one of the specific actions. In at least some embodiments, and as shown in FIG. 9, the thumbnails shown for priority A are ordered based on the values of the “viewed” fields in the image files. For example, a thumbnail for an image file having a “viewed” value of 3 (thumbnail 8) is placed before thumbnails for image files having a “viewed” value of 1 (thumbnails m, 3, 4, 5, 7, 10 and 14). If several image files have the same “viewed” field value, thumbnails for those images are ordered chronologically. In other embodiments, all thumbnails shown for priority level A are ordered chronologically, or in some other manner.
If the user selects priority level “B” (FIG. 10), processor 142 displays thumbnails for image files which have been enlarged and which have been edited. In other words, the priority threshold requires prior performance on a file of at least two specific actions. As in FIG. 9, the order in which thumbnails are arrayed is also dependent upon the values for the “viewed” fields of each corresponding image file. In other words, thumbnail images are ordered based on the number of times that the image has been enlarged. Where several images have the same values for the “viewed” field, thumbnails for those images are ordered chronologically. In embodiments where the “edit” field may have values in addition to 0 or 1, those additional values may be used for further ordering of thumbnails having the same “viewed” field value. In other embodiments, all thumbnails shown for priority level B are ordered chronologically, or in some other manner.
If the user selects priority level “C” (FIG. 11), processor 142 displays thumbnails for image files which have been enlarged, which have been edited and which have been copied to an album. In other words, the priority threshold now requires prior performance on a file of three specific actions. As in FIGS. 9 and 10, the order in which thumbnails are arrayed is also dependent upon the values for the “viewed” fields of each corresponding image file. Where several images have the same values for the “viewed” field, thumbnails for those images are ordered chronologically. In embodiments where the “album” field may have values in addition to 0 or 1, those additional values may be used for further ordering of thumbnails having the same “viewed” field values. In other embodiments, all thumbnails shown for priority level C are ordered chronologically, or in some other manner.
In the examples of FIGS. 8-11, selections “A,” “B” or “C” resulted in a thumbnail display that could be shown on one screen. This will not always be the case. In some cases (e.g., a large number of image files in folder 164), selection of “A,” “B” or “C” (or other user instruction to display less than all thumbnails) will reduce the number of thumbnails shown, but will still result in a multi-page display. However, the number of pages which the user must view (using, e.g., “page forward” or “page back” arrows 160) may be greatly reduced.
The preceding discussion of FIGS. 8-11 provides an example of an algorithm by which a display of thumbnails may be limited to less than all thumbnails in a particular group. As but another example, setting “B” in FIG. 10 could result in display of thumbnails for image files that have been enlarged and copied. As yet another possibility, setting “B” could cause display of thumbnails for image files that have been edited and copied. Other combinations of field values for a specific priority level are also within the scope of the invention, as are combinations of priority settings. For example, one priority level setting may specify images which have been enlarged, another may specify images which have been copied, and another may specify images which have been edited or otherwise manipulated. The user could then select any combination of these settings to, e.g., specify images which have been enlarged, images enlarged and copied, images enlarged and edited, etc. These and other prioritization algorithms and selection schemes are within the scope of the invention.
FIG. 12 is an example of another prioritization algorithm. In the embodiment of FIG. 12, the field values are summed for each image to yield a priority score for that image. Thumbnails are then displayed for images having a score above a user-defined threshold. In at least one embodiment, values for the fields of table 166′ are set in accordance with Table 1.
TABLE 1
|
|
value =value =value =value =
field0 if:1 if:2 if:3 if:
|
“view”notenlargedenlargedenlarged
previouslybetweenbetweenmore than
enlarged1 and 23 and 55 times
timestimes
“edit”notedited 1edited 2edited 3
previouslytimetimesor more
editedtimes
“album”not copiedcopied tocopied tocopied to
1 album2 albums3 or more
albums
|
If an image has not been enlarged, the “view” value for that image is 0. If the image has been enlarged once or twice, the “view” value is 1. If the image has been enlarged between 3 and 5 times, the “view” value is 2. If the image has been enlarged more than 5 times, the view value is 3. The values for the “edit” and “album” fields are similarly determined in accordance with Table 1.
By manipulating on-screen slider bar 170′ in FIG. 12, a user sets the priority threshold for images to be displayed as thumbnails. Moving the slider in one direction (“lower”) decreases the threshold, while moving in another direction (“higher) increases the threshold. In FIG. 12, the setting of slider 170′ corresponds to a priority threshold of three. In other words, image files having a priority score of three or more are displayed as thumbnails, while image files have a priority score less then three are not displayed as thumbnails. Notably, an image file not shown as a thumbnail (image file 4) has been enlarged more times than several image files that are shown as thumbnails (image files 1, 5, 12, 15 and n). As can be appreciated, the embodiment of FIG. 12 recognizes that a particular image may not have been enlarged as frequently as other image files, but nonetheless be very important. In the embodiment of FIG. 12, the displayed thumbnails are ordered based on the respective priority scores of the corresponding image files. Thumbnails having corresponding image files with identical priority scores are ordered chronologically. In other embodiments, all thumbnails are ordered chronologically, or in some other manner.
In yet another embodiment, user data files which are not presented, edited, or manipulated during a first, second, or third (or more) reviewing session may be deleted, removed, or hidden from collection folder 164. The selection of user data files may be based on a threshold value. Selecting user data files based on a threshold value allows a user to define a permanent view that presents only relevant data files. Deleted, removed, or hidden data files may be either restored or presented by a user selected command.
In yet another embodiment, a value is calculated for a manipulated user data file and added to a sum of priority data for the manipulated data file. In a system and method according to this embodiment, a user data file having priority data is selected to be presented, edited, or manipulated. The value of priority data may be zero or empty (i.e. NULL) if the file has not yet been presented, edited or manipulated, or it may already have a value if the file has already been presented, edited or manipulated. The data file manipulation file value is calculated based on how the file is presented, edited, or manipulated. In providing this calculation, table 1 or any other table describing values and multipliers of different types of presentations, edits or manipulations may be used. After the calculation is completed, the value of the manipulation is added to the value of the priority data for the user data file. The sum may then be used for presenting user data files or information about the user data files in a prioritized manner.
Referring back to FIG. 1, an embodiment is shown in which the data files are stored in a portable personal server 114. In yet another embodiment, the data files may be stored in a network server, which may include a service by a service provider. According to an aspect of the invention, a user may access the server and present, edit or manipulate the data files using a mobile communication device (or a wireline communication device like a PC computer) in the same manner as described throughout this specification. The network server may receive the data files from the mobile communication device (or from the PC computer) or from any other source, such as a photo service provider, or a music or video service provider. Users may access the server and service through the mobile communication device via a wireless network, such as wireless telecom network, or a short range wireless network, such as WLAN, Bluetooth etc. Commands for presenting, manipulating and editing the data files may be transmitted through the network. Data files may be retrieved for presentation through the network where a display is provided by the user's mobile communication device. Alternatively, if the display is external to the user's mobile communication device, such as a TV device, set-top box, or personal computer, the selected data files may directed to the display device through a second wireless or wireline communication network, such as a wireless telecom network, or a short range wireless network, such as WLAN, Bluetooth etc.
In additional embodiments, a user is provided more control over the thumbnails to be included in a thumbnail view. For example, a user interface such as is shown in FIG. 13 permits a user to specify that thumbnail images are to be displayed for image files enlarged, edited and/or copied a certain number of times. If, for example, the user wishes to see thumbnails for image files enlarged 3 or more times (regardless of whether a file has been edited or copied to an album), the user could set the “enlarged at least” value to 3, and the other values to 0. As another example, the user could set the “enlarged at least” value to 3, the “edited at least” value to 1, and the “copied to at least” value to 1 if the user only wishes to see thumbnails for image files that have been enlarged 3 or more times, edited 1 or more times and copied to at least one album. As shown in FIG. 14, some or all of these settings could alternately be adjusted using a slider bar or other appropriate interface.
FIGS. 4-12 schematically show tables 166 and 166′ stored separately from the image files in folder 164. Accordingly, when the individual image files in folder 164 are enlarged, edited, etc., table 166 or table 166′ is separately (and automatically) accessed and an appropriate field updated. In other embodiments, the data contained within table 166 or table 166′ is stored in a different manner. For example, the attributes shown in the various fields can be added to each of the individual image files as metadata. When determining which of the image files to display in a thumbnail view, those attributes are accessed by the thumbnail viewer software, and the appropriate image files selected. In still other embodiments, explicit values are not assigned to files; files are instead prioritized by adjusting the locations of each file within a group of files, and/or by adjusting the locations of file names within a listing of file names. When determining which files to display in a thumbnail view, files above (or below, preceding, after, etc.) a specified location in the file group or file list are identified.
As can be appreciated from the preceding description, embodiments of the invention allow a user to locate electronic images in a convenient manner. As previously indicated, the invention is not limited to data for still images. Although the above description and FIGS. 4-14 use still images as examples, the invention is equally applicable to other types of user data files. In the case of video clips, the thumbnail images could be of the first frame of the clip. Upon selecting a video thumbnail, the video clip is played in an enlarged view. Playing a video clip file in an enlarged view, editing the file and/or copying the file to an album causes automatic update of appropriate fields in a table. Other aspects of the embodiments described above are similarly applicable. Alternatively (and in the case of audio clips), the user can be presented with a display of icons or a simple list of file names as the “thumbnail” view. Selecting a file name or icon would then cause the corresponding image, video or audio file to be enlarged (or played), with other features of the previously-described embodiments being similarly applicable. In the case of text files and other types of files, a “thumbnail view” could provide a miniaturized representation of each file's contents or a portion thereof (e.g., the first page for multipage files), could be a listing of files, or could be some other type of display providing information about the files. Indeed, the invention is not limited to providing information about prioritized files in a thumbnail view or other file selection user interface. In some embodiments, for example, information regarding files having a priority above a priority threshold is provided in another manner (e.g., a seriatim display of file contents for files having above-threshold priorities).
Although specific examples of carrying out the invention have been described, those skilled in the art will appreciate that there are numerous variations and permutations of the above-described systems and methods that are contained within the spirit and scope of the invention as set forth in the appended claims. For example, the algorithms, user interfaces and screen layouts described are only examples; other algorithms, user interfaces and screen layouts are within the scope of the invention. Instead of only displaying information about files having a priority above a specified threshold, certain embodiments display information about files with priorities above and below the threshold, but with the files having above-threshold priorities indicated in some way (e.g., flagged with an icon, placed at the beginning of a list, etc.). In certain embodiment the invention may display information about files having a priority below a specified threshold instead of displaying information about files having a specified threshold above a specified threshold. Images need not be created with a mobile device capable of communication via long-range wireless transmission. For example, images could be created by a digital camera which must download images by USB or BLUETOOTH connection or by transfer to a removable medium, or by scanning a previously-created drawing, photograph or other document. As yet a further alternative, a machine-readable medium could have machine-executable instructions stored thereon such that, when the instructions are read and executed by an appropriate device (or devices), steps of a method according to the invention are performed. These and other modifications are within the scope of the invention as defined in the attached claims. In the claims, various portions of the claims are prefaced with parenthetical letter or number references for convenience. However, use of such references does not imply a temporal relationship not otherwise required by the language of the claims.
Patent Application
20060004698
