|Publication number||US7461090 B2|
|Application number||US 10/835,309|
|Publication date||Dec 2, 2008|
|Filing date||Apr 30, 2004|
|Priority date||Apr 30, 2004|
|Also published as||US20050246374|
|Publication number||10835309, 835309, US 7461090 B2, US 7461090B2, US-B2-7461090, US7461090 B2, US7461090B2|
|Inventors||Arnold N. Blinn, Jerry Koh|
|Original Assignee||Microsoft Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (11), Referenced by (12), Classifications (21), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
Embodiments of the present invention relate to selection and presentation of media items to users. More particularly, embodiments of the invention relate to a technique for selective presentation appropriate for multiple situations.
In current media environments, there is not a great deal of flexibility if a user plans to output a series of media items such as photographs, videos, or musical selections. Typical state of the art allows the user to specify a complete directory of media items, multiple directories, a specific media item, or a network share of media items (e.g. a web site collection such as an MSN Group). These techniques for grouping and selecting media items are very limited in scope.
The use of media items in computerized environments has become increasingly common. Computer users often have thousands of digital images or music files archived on their hard disks. Many computer users now use photo or music organizational products to categorize and organize their photographs or music. These organizational products allow users to tag their media with metadata. The metadata may include information about the tagged photo, such as date taken, subjects, or relevant event. For music this may include information about the artist, album or genre of the music. For both photo and music this may include a user “rating” of the data. This metadata is currently useful for searching for a particular photograph or music file, but is typically not used for more advanced selection.
Unlike music files which are often casually listened to, other than occasional printing and sharing with other computer users via electronic mail or photo archives, users have few uses for their digital images. Some users will set a screen saver to display stored digital images and others display stored digital images on external display devices.
These external display devices are becoming less expensive and more common. As the prices of electronic picture frames drop, these devices will become even more commonplace. More advanced sharing applications are also being developed, such as through e-mail or instant messaging. As this happens, users will demand more flexibility in the selection of photographs for display on these devices and for existing and future applications of sharing. Without more advanced techniques for selecting photos, the vast majority of stored digital images sit idly.
Another problem with most currently known techniques of sharing media items is that a user is typically required to take an overt action to access the media items (e.g. open the mail, interact with an IM session, visit a web site). Devices such as the electronic picture frames mentioned above are compelling because the photos are displayed in a more “passive” fashion. However, the electronic picture frames typically hold a small fixed number of photos and display this fixed list of photos until the list is updated.
Accordingly, a solution is needed that improves and develops the concept of selecting a series of media items (photographs) for either sharing or display. The solution should allow specific rules to be developed for determining which media items should be selected and or displayed.
Embodiments of the present invention are directed to a system operating within a computerized environment for selecting and arranging media items as output. The system includes selection components for selecting multiple media items for output. The selection components include a source selection component for selecting media items from at least one source. The system additionally includes a query component for searching media items based on tagged or derived metadata and for selecting the multiple media items based on tagged or derived metadata specified by a user. This tagged metadata might be user specified and defined, or might be pre-defined from templates. The derived metadata might include file attributes such as date created, date modified, or attributes of the content of the file (lightness, darkness), or might be embedded by the device creating the file (e.g. camera picture taken with).
In an additional aspect of the invention, a system operating within a computerized environment is provided for selecting and arranging media items as output. The system includes a source selection component for selecting media items from at least one source. The system also includes weighting tools for causing a first set of selected media items to be selected with a first frequency and a second set of selected media items to be selected with a second frequency.
In yet a further aspect of the invention, a method is provided for operating within a computerized environment for selecting and arranging media items as output. The method includes selecting at least one source for providing media items and formulating a query to search for media items associated with user-selected tagged metadata. The method additionally includes retrieving media items from the at least one selected source having the tagged metadata and organizing the retrieved media items for output.
In yet an additional aspect of the invention, a method is provided for operating within a computerized environment for selecting and arranging media items as output. The method includes selecting at least one source for providing media items and applying weighting tools to the media items for causing a first set of media items to be selected with a first frequency and a second set of media items to be selected with a second frequency. The method additionally includes organizing the selected media items for output.
The present invention is described in detail below with reference to the attached drawings figures, wherein:
I. System Overview
Embodiments of the invention include a method and system for selecting and presenting media items to a user.
Media items or objects may include music, photographs, videos, or other items taken from a variety of sources. In accordance with embodiments of the invention, media item users are able to select and present media items in a balanced and normalized fashion. The presentation of media items can include printing, sharing, or other presentation modes. In the case of photographs, the items can be used for creating a slide show, displaying in a screen saver, displaying in a dedicated part of the screen, or for displaying on an external device such as a picture frame or hand held display.
II. Exemplary Operating Environment
The invention is described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
With reference to
Computer 110 typically includes a variety of computer readable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/nonremovable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
The computer 110 in the present invention will operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
Although many other internal components of the computer 110 are not shown, those of ordinary skill in the art will appreciate that such components and the interconnection are well known. Accordingly, additional details concerning the internal construction of the computer 110 need not be disclosed in connection with the present invention.
III. Media Item List
The selection components 310 are the components used for selecting a media item. The selection components 310 may include a source selection component 312, weighting tools 316, a query component 314, and a counting component 318.
The source selection components 312 select a source from a plurality of sources such as those shown in
The query component 314 is capable requesting, based on user specified parameters, a particular a media item (or media items) having a particular characteristic (or characteristics) and searching for that characteristic throughout each available source. For instance, if a user wants to select all or some photographs of Jane and Jim, the query component 314 is capable of searching through metadata to locate all photos that include Jane and Jim. Other examples could include photographs of a vacation in Mexico, photographs from a graduation party, photographs taken on a particular date, photographs of a certain color, etc.
The weighting tools 316 are capable determining proportions of selected media items to be displayed. For instance, a viewer may want to see some photographs of the Mexico vacation and some photographs of the graduation party, but the viewer may want to see 75% vacation photos and 25% party photos. The weighting tools 316 ensure that the viewer receives the correct proportions. The proportions are maintained regardless of the number of photos that meet the input criteria. So if 1200 vacation photos are found but 10 party photos, the results would still balance the party photos against the vacation photos. This would either be by select 10 party and 30 vacation photos, by selecting the 1200 vacation photos but repeating the 10 party photos 40 times yielding 400 party photos, or by some balance in the middle.
The counting component 318 determines how many photos to ultimately select from to create the list for the output display. This could be a specific number of photos (e.g. ten) or could be as many photos as the media item list 300 generates. The photos returned may include a number less than the number of specific photos requested. For instance, a requester may ask for ten photos, but only receives five based on the selections made by the aforementioned components. The counting component will indicate if the selected photos list should “repeat” photos to get ten. In the aforementioned case each one would be returned twice. Accordingly, the counting component 318 regulates the number of photos sent to output from each selected source and having each requested type of metadata to reach a requested number.
The sorting components 320 determine how the selected elements in the list should be returned. Sort order could be determined by a random sorting component 322, which is to say that the order could be left to random selection. Alternatively, an identifying data component 324 could determine the sort order be based on name, date taken, date modified, date saved, file size, or any other photo attribute that can be represented as a scalar and sort-able value, such as lightness or darkness. Sort order could also be based on any other of the photo metadata such as tagged keywords. A directional component 326 can determine if the sort is ascending or descending (dark to light or light to dark).
IV. Media Item List Commands
The selection components 310 and sorting components 320 implement their functions through a series of commands. These commands are described herein using photographs as an example of a media item. However, similar commands could be used for other types of media items. Table 1 below provides examples of commands applicable to the media item list 300. These commands may include a “photolist” command, an “imagefile” command, a directory command, and a “photolistfile” command. Furthermore, these commands are further controlled by parameters that include a count parameter, a depth parameter, and a sort command. Each of these commands is further explained below.
<photolist count=“5” sort=“random” repeat=“0”>
<directory count=“10” depth=“2” sort=“random”
An “imagefile” command may be used for source selection and points to a file in a specified location such as on the hard disk or the URL of an image on the Internet. The “imagefile” command will select the image and cause the specifically referenced item to be returned. The item will be output assuming the containing command returns all items for selection or if the containing command constrains the number returned but the item is selected.
A “photolist” command executes an embedded photo list. The “photolist” command may include a count of the number of photos to return from the embedded list once executed. The “photolist” command may also include a repeat command. For the repeat command, a value of “1” may direct the list to repeat photos to reach the specified count if the current count is less than a target count. A “0” value may indicate that the sequence should not be repeated. The “photolist” command may also include a sort command for designating a random sort, a sort by name, a date sort, a size sort, etc. A value of “1” may indicate a descending sort and a value of “0” may indicate an ascending sort.
When an embedded photo list is executed, its rules are applied and the resulting items returned. Once these items are returned, the items are inserted in the larger media list. The following is an example.
<photolist count=“1” sort=“random”>
<photolist count=“1” sort=“random” repeat=“0”>
When the embedded “photolist” from Table 2 is executed, it returns one random file. If the random file is c:\image2jpg, the photo list takes the form of Table 3.
<photolist count=“1” sort=“random”>
After the embedded list is executed, the “photolist” command selects one of the image files in Table 3 randomly. Fifty percent of the time http://domain.com/photojpg would be selected. The other fifty percent of the time, one of the three files in directory c:\ (in this case image2.jpg) will be selected. In a nutshell, embedded “photolist” commands are executed recursively depth first
Table 1 also shows a “photolistfile” command. The command is the similar to the “photolist” command, but the referenced list is an external file. Because a photo list contained in a file has its own root photolist command with parameters, there are no parameters to this command. Instead, the parameters in the embedded list control the number of photos returned. In another embodiment, the commands might be placed with the photolistfile command. In yet another embodiment, the commands in the photlistfile command might override the commands in the embedded file.
A “directory” command is also shown in Table 1. This command returns a list of media items contained in a directory. Subdirectories in a directory element can also be executed recursively to allow normalization to be applied across subdirectories. In certain embodiments, this recursion can be controlled by additional parameters on the directory command. Parameters within a directory command may include a count command, the depth of directories to recurse, the order of the subdirectories to recurse, a file and/or directory mask to include/exclude files, etc. A count command can specify the number of photos to return from the directory/sub-directories. A repeat command may indicate whether or not to repeat photo display if the count is less than the target count. A “1” may be used to order a repeat and a “0” may be used to avoid repeating. A sort command may include random sort, name sort, date sort, and size sort commands. A descending sort and ascending sort command may be available. A directory mask or “DirMask” command may provide a mask for directory recursion (e.g. *, *foo). A “FileMask” command may include a mask for file inclusion (e.g. *.jpg).
A directory command parameter might control if recursion is done, or might control “depth” through which normalization and weighting may be applied. The following Table 4 is a directory structure that might contain images from a photo library:
A user may want three media items from each of the events in Table 4. By specifying a count of three and a depth of two, the list will output three photos from each event, at the depth of two on the directory traversal. The specification of count and depth allows the user to normalize directories that are at different depths in the same tree.
The directory command applies the photo list rules (count, sort, repeat) recursively through each subdirectory depth first. Table 5 represents a directory tree.
If count=1, repeat=1, sort=random, dirmask=*, filemask=* and the directory command is executed, another parameter called the “root” parameter dictates the handling of files one.jpg and two.jpg because these are files that exist in a directory with additional subdirectories.
“None” will cause the files to be ignored. “Even” will cause the files to be considered with equal weighting with all the subdirectories. This would be equivalent to taking the files one.jpg and two.jpg and putting them in a subdirectory called “misc” as shown below in Table 6.
Because the algorithm executes depth first, it is first applied to the “misc” subdirectory and one is randomly selected. The algorithm is subsequently applied to the January directory and the algorithm randomly selects one item. If one.jpg is randomly selected from the miscellaneous subdirectory and three.jpg from the January subdirectory, these two elements are returned, and the algorithm applied again. Again, an item, for example three.jpg, is randomly selected. There is a 25% chance of any file being returned.
Returning to Table 5, the media item list would output different elements if the root parameter is “heavy. In contrast to “even”, which applied the normalization first, the “heavy” root parameter causes one.jpg and two.jpg be considered before applying a normalization. In this example, there is a 33.3% chance that one.jpg is chosen, 33.3% chance that two.jpg is chosen, a 16.66% chance that three.jpg is chosen overall, and a 16.66% chance that four.jpg is chosen overall. The “depth” parameter simply controls the depth in the tree for applying normalizations.
The following Table 7 illustrates a more complex example.
If a user wants to select one photo from January, February, and March with equal weighting, the user can specify a depth of “3” to tell the system to start applying the filters at the 3rd subdirectory and append the results together to form an overall list. If count is “1” and depth is “3”, the system will select one photo from January (each with a 50% chance), one from February (always five.jpg), and ultimately one from March (each with a 25% chance of being selected). The command would return, as an example, three.jpg, five.jpg and eight.jpg. Alternatively, it might return four.jpg, five.jpg, and seven.jpg. In fact, the command might return one of eight different permutations possible as indicated in Table 8.
Three.jpg, five.jpg, six.jpg
Three, five, seven
Three, five, eight
Three, five, nine
Four, five, six
Four, five seven
Four, five, eight
Four, five, nine
Although not shown in Table 5, a group command may also be provided. The group command may point to an online group, online community or Internet based group of files. An example of this is the MSN groups and community system. Online MSN communities are basically directories and follow the same rules as directories. However, a group command would point to a root URL rather than a file path.
Using all of the commands described above as well possible additional commands, the functions of source selection, weighting, queries, counting, and sorting are accomplished to send a plurality of desired media items to the output device 200.
V. Implementation Examples
The components of the media item list 300 utilize the commands described above interact to create a variety of unique scenarios. The following paragraphs illustrate the capabilities of the media item list 300.
In a first implementation example, the media item list 300 may be a photo list including two embedded photo lists. The first embedded photo list might contain one thousand photos and the second embedded photo list may include one hundred photos. The selection components 310 explained above may select two photos from each of the embedded photo lists, resulting in a total of four photos, in order to effectively normalize the number of times that photos from each of the categories would be displayed. In this case, the list with one hundred photos displays the same number of photos as the list of one thousand photos, thereby giving the photos from the smaller list a ten times weighting.
If a user wanted to display one hundred photos from each list, the user could select all one hundred photos from the list of one thousand photos or all one hundred from the list of one hundred. However, a user might also want to display twice as many photos from the list of one hundred than from the list of one thousand. The user could simply select two photos from the list of one hundred and one photo from the list of one thousand.
In another scenario, the user could select one hundred photos from the list of one hundred and fifty photos from the list of one thousand, resulting in a total of one hundred and fifty photos. If a user needed three hundred photos for output, the user could run the algorithm twice using a repeat command, but this might result in the same photos from the larger list being selected each run. Optionally, the user could select two hundred photos from the smaller list and one hundred photos from the larger list. In this scenario, none of the same photos would be sent to output twice. Weighting could be applied in a more specific manner, by having a weight associated with the embedded photo or photo list when randomly selecting photos. This weight would be relative to all other weights in randomly selecting the photo.
In a screensaver application, a user could configure a screen saver to display his favorite photos (for example, photos marked with metadata of “favorites”) 10% of the time, to display “timely” seasonal photos (for example, either photos taken around the same time of year or photos for a current holiday and tagged as such) 20% of the time, to display photos that were shared in the last week (for example, photos that the IM and e-mail sharing application put into a specific directory) 30% of the time, photos from a family web site (for example, photos from an online group) 20% of the time, and the remaining time (20%) display random photos from the entire collection. This aforementioned task can be accomplished simply by using the photo list 300 explained above to create output. The user could select ten photos using a query to obtain favorite photos and also select ten random photos. Another query might select twenty photos from a query that returns Christmas photos. A third query might select thirty photos from a share directory where the date shared was less than one week ago. A fourth list element might include selecting twenty photos from a source such as an online community or web site, and the remaining twenty photos may be selected from a collection on the hard drive.
As set forth above, the query component 314 can search for media items based on stored metadata to select a series of media items in an intelligent manner. In the case of photographs, this metadata can be user driven. For instance, the user may tag metadata on the photo. Metadata may include attributes of the photo itself such as date, time, location taken, what camera, or physical location as specified by a directory. Alternatively, metadata could indicate how a photo was acquired. For instance, the user may have taken the photo or may have received it from another user. Different weights can be applied to this metadata for consideration in algorithms to select photos to display. These weights could be user driven. For instance, a user could tag photos as favorites and these photos could receive greater weight. Alternatively, photos taken more recently could be given greater weight.
In another embodiment, a photo list may include an embedded query command. This command may return a list of photos according to an arbitrary query, such a SQL query into a relational database. As discussed above, a query might be based on file attributes, images characteristics, or more likely photo metadata such as tagged key words. An embedded query list element may contain attributes describing the source list, the query, and how many photos to ultimately use from the list. In this regard, the embedded query is similar to the embedded list 350. Sort, repeat, and count features might also be present in the embedded query element.
With all of the features shown in
VI. Selection Method
In step A12, the user sets selection criteria. The selection criteria can be set using the query component 314, weighting tools 316, and counting component 318. The selection can be made using a query command for locating specific metadata, a root command for weighting some sources more heavily than others, and a count command for determining how many media items to include from a give source. Other commands may also be used to set selection criteria.
In step A14, the user may determine sort order using the sort commands such as random sort, name sort, date sort. The user may also select ascending and descending sorts. Any number of sort criteria may be used and this list is intended to be merely exemplary and not exhaustive.
In step A16, the media item list constructed by the user can be executed to provide output in the form of media items. The output of media items using the media item list can happen at any time an application desires. Timing could be on demand and user driven. Renewal may occur whenever a list is exhausted or at pre-scheduled intervals.
VII. User Interface
In order to implement the media item list described above, a user may be presented with a series of user interface list building components 500. The list building components 500 may be contained within a list selection wizard 510 that presents options to a user. The list selection wizard 510 may provide a user with a series of source selection options 512 for providing an available list of sources in which accessible media items may be contained. In embodiments of the invention, the user will be able to add sources as the sources are created. The list selection wizard 514 may also provide metadata selection options 514. The metadata selection options 514 may include tags applied by the user, dates, names, etc. The weighting factor selection options 516 may present a user with weighting options after the user has selected a source of media items. Totals selection options 518 may be provided to the user in order to allow the user to select a total number of media items to be output. Finally, sort order selection options 520 may be provided to the user to allow the user to determine an output order. These user interface components are merely exemplary.
The above-described media item list has many potential applications. The media item list may have operating system (OS) level functionality. In this regard, the media item list might apply to photo integration with the OS. The media item list may also be implemented in conjunction with photo organizational products that manage global lists of images. These products “categorize” images with metadata and the media item list provides functionality for the categorization. The media item list may also be implemented in conjunction with any photo sharing product in order to exert granular control over shared media items. It may apply to other media types (e.g. music) that are similarly organized in tools, the operating system, and ultimately selected for use, in this case playback vs. display.
The media item list allows for future extensibility. By defining new list element types, new rules can be built and applied as necessary. A command to apply a weighting factor on a logarithmic scale may be based on how recently the photo was shared. Thus, photos shared less then one week ago are very likely to show up, photos within three weeks somewhat likely, within ten weeks somewhat unlikely, and older than that very unlikely to be selected. By building this extensibility into the system, a wide variety of rules and algorithms can be expressed simply by building these photo lists.
While particular embodiments of the invention have been illustrated and described in detail herein, it should be understood that various changes and modifications might be made to the invention without departing from the scope and intent of the invention. The embodiments described herein are intended in all respects to be illustrative rather than restrictive. Alternate embodiments will become apparent to those skilled in the art to which the present invention pertains without departing from its scope.
From the foregoing it will be seen that this invention is one well adapted to attain all the ends and objects set forth above, together with other advantages, which are obvious and inherent to the system and method. It will be understood that certain features and sub-combinations are of utility and may be employed without reference to other features and sub-combinations. This is contemplated and within the scope of the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6654742 *||Feb 11, 2000||Nov 25, 2003||International Business Machines Corporation||Method and system for document collection final search result by arithmetical operations between search results sorted by multiple ranking metrics|
|US6697800 *||May 19, 2000||Feb 24, 2004||Roxio, Inc.||System and method for determining affinity using objective and subjective data|
|US6865600 *||May 19, 2000||Mar 8, 2005||Napster, Inc.||System and method for selecting internet media channels|
|US20030003433 *||Jun 29, 2001||Jan 2, 2003||Ignite, Inc.||Method and system for constructive, modality focused learning|
|US20030182157 *||Mar 25, 2003||Sep 25, 2003||Valk Jeffrey W.||System architecture for information management system|
|US20040019658 *||Jul 18, 2003||Jan 29, 2004||Microsoft Corporation||Metadata retrieval protocols and namespace identifiers|
|US20040083273 *||Jan 18, 2002||Apr 29, 2004||Madison Justin Paul||Method and system for managing digital content, including streaming media|
|US20040199529 *||Apr 5, 2004||Oct 7, 2004||Caelo Software Inc.||System for managing and organizing stored electronic messages|
|US20050015389 *||Jul 18, 2003||Jan 20, 2005||Microsoft Corporation||Intelligent metadata attribute resolution|
|US20050091271 *||Oct 23, 2003||Apr 28, 2005||Kasy Srinivas||Systems and methods that schematize audio/video data|
|US20050131731 *||Jan 31, 2005||Jun 16, 2005||Brydon Robert B.||System and method for selecting internet media channels|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8024347 *||Sep 27, 2007||Sep 20, 2011||International Business Machines Corporation||Method and apparatus for automatically differentiating between types of names stored in a data collection|
|US8639706 *||Jul 1, 2011||Jan 28, 2014||Google Inc.||Shared metadata for media files|
|US8892560 *||Nov 26, 2008||Nov 18, 2014||Adobe Systems Incorporated||Intuitive management of electronic files|
|US9152677 *||Dec 23, 2013||Oct 6, 2015||Google Inc.||Shared metadata for media files|
|US20060069991 *||Sep 23, 2005||Mar 30, 2006||France Telecom||Pictorial and vocal representation of a multimedia document|
|US20070097402 *||Dec 21, 2005||May 3, 2007||Jung-Lieh Chen||Method for printing an image during an image playing mode|
|US20090089284 *||Sep 27, 2007||Apr 2, 2009||International Business Machines Corporation||Method and apparatus for automatically differentiating between types of names stored in a data collection|
|US20100057713 *||Mar 4, 2010||International Business Machines Corporation||Entity-driven logic for improved name-searching in mixed-entity lists|
|US20100241648 *||Mar 23, 2010||Sep 23, 2010||Konica Minolta Business Technologies, Inc.||Image processing apparatus|
|US20120081275 *||Apr 5, 2012||Microsoft Corporation||Media Display Device|
|US20130166560 *||Nov 26, 2008||Jun 27, 2013||Adrian Secord||Intuitive Management of Electronic Files|
|US20140114966 *||Dec 23, 2013||Apr 24, 2014||Google Inc.||Shared metadata for media files|
|U.S. Classification||1/1, 707/E17.009, 707/999.104, 707/999.107, 707/999.003, 707/999.004, 707/999.006, 707/999.002|
|International Classification||G06Q10/00, G06F7/00, G06F17/30|
|Cooperative Classification||Y10S707/99948, Y10S707/99945, Y10S707/99936, Y10S707/99933, Y10S707/99932, G06Q10/10, G06F17/30038, Y10S707/99934|
|European Classification||G06Q10/10, G06F17/30E2M|
|Apr 30, 2004||AS||Assignment|
Owner name: MICROSOFT CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BLINN, ARNOLD N.;KOH, JERRY;REEL/FRAME:015289/0673
Effective date: 20040427
|May 2, 2012||FPAY||Fee payment|
Year of fee payment: 4
|Dec 9, 2014||AS||Assignment|
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034541/0477
Effective date: 20141014