Patent Application
20140359488
Most computer programs which allow a computer to access resources on a computer network, such as browser applications through which a computer accesses the Internet, allow users to store, on the computer, data used to access resources that they access frequently or otherwise would like to remember to be able to access again. Such data to access a resource is distinct from a path and file name in a file system for the computer, as such file names are in the file name space of the computer's file system. Other resources, such as web pages on the Internet, are accessed using data outside the file name space of the file system of the operating system of the computer. Data used to access such resources on a network typically is in the form of a uniform resource locator (URL) or uniform resource indicator (URI). The data stored by applications is commonly called a “bookmark” or “favorite” or “link” or “history” or the like. Herein, the data used to access a resource on a network is called “link data,” an example of which is a URL.
Link data commonly is stored on a computer separately for each application. For example, a browser application may store its link data in one or more data files in a directory or path in the file system of the computer on which the browser application is installed. Other applications in turn store their link data in one or more different data files in different directories or paths in the file system. If a user has multiple computers, each computer also has applications that store their own link data.
This Summary introduces selected concepts in simplified form that are further described below in the Detailed Description. This Summary is intended neither to identify key or essential features of the claimed subject matter, nor to limit the scope of the claimed subject matter.
Using conventional applications, users access links using the applications through which the links are stored. Thus, users tend to replicate link data in different applications on different devices. Also, remembering the application in which the link data is stored can be difficult. Alternatively, users can use an application that stores links, and data accessed from resources using such links, for later reading.
To address such problems, an operating system of a computer provides an interface, such as an application programming interface, through which applications on that computer can store link data in a consistent format across applications and resources. Thus, when an application stores link data, it sends a command to the operating system providing the link data, invoking a command to store the link data. When an application retrieves link data, it sends a command to the operating system to retrieve link data. Thus, an application can store link data for a history of resources accessed, favorite resources accessed, and other types of resources to be accessed. As a result, the operating system provides a single mechanism for a heterogeneous set of applications and a heterogeneous set of resources to store link data in a single repository.
The computer can connect over a computer network to a networked storage service, associated with a user account, in which such link data can be stored. In the event that multiple computers are associated with that user account, the networked storage service and each computer can synchronize their sets of link data. Thus, a user who accesses a user account with different computers has the same set of link data on the different computers. This link data in turn is available to multiple applications through the respective operating systems of those computers. Such link data also can be shared with others.
The link data is stored in a consistent format across multiple applications and multiple resources. This format can include the data used to access a resource, such as one or more URL(s), and various metadata. Such metadata can include, for example but not limited to: an indication of the application(s) associated with the link data, one or more time stamps indicating when the resource was accessed, added or last updated, a geographic location of the device when the resource was accessed, a plain text title or description of the resource, and an indication of the device that hosts the application accessing the link, a type of the resource, data from the application such as a name and image associated with the resource, keywords, user entered tags, deadline for reading, and the like. Data from the resource, such as a cache of the data received when the resource was last accessed, or other information, can be stored. An expiration date for the link and/or its metadata also can be set. The applications associated with the link data can include the application that instructed the device to store the link data. This link data format also allows multiple URL(s) to be associated with a resource, while providing link data for different applications to access the same resource or equivalent resources.
In addition, a computer program dedicated to management of link data, herein called a “link manager,” also can be provided. The computer program can be part of the operating system of a computer or an application running on the computer that communicates with the operating system to access link data. This link manager allows a user to access, search, view and manage various link data. The link manager can include a graphical user interface through which the user can search, view and manipulate link data. For example, the graphical user interface can provide a variety of ways to search, filter and sort link data for display, using the various metadata from the link data. As an example, link data can be sorted and grouped by date of last access. Link data for a resource can be displayed in a format that indicates to a viewer a title of the resource, a time it was last accessed and the application and/or device through which the resource was accessed. Link data can be filtered, for example, by date, application, read or unread status, resource type, keywords, user entered tags, and the like. The link manager can prompt a user to install an application on a device, if link data is available for an application that is not installed on the device.
In the following description, reference is made to the accompanying drawings which form a part hereof, and in which are shown, by way of illustration, specific example implementations of this technique. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the disclosure.
The following section provides an example operating environment in which management of link data for accessing resources on a computer network can be centralized.
Referring to
The resources generally are identified using data outside the file name space of the file system of the operating system of the computer. Such data typically identifies a host computer and a name of a resource on that host computer. Such data also can include an indication of a method for accessing a resource on its host computer. An example of such data is a W3C defined standard URL (e.g., http://www.host.com/index.html), which for a web page identifies its host computer using a domain name (e.g., www.host.com), the web page using a path and file name (e.g., “index.html”), and a protocol used to communicate with the host computer to access the web page (e.g., “http”). While it is possible for a link to reference a data file or other resource within the name space of the file system of the computer, the link data in such a case also includes information that indicates that the resource is located within the computer's file system, using a format such as “file:\\path\filename.”
Applications 104 and 106 can use an application programming interface 108 of the operating system to store 110 and retrieve 112 information about links. The operating system 102 maintains this information about links in a repository 114. The repository can be a data file, database or other form of structured storage of information about links such that information about links can be readily stored, searched and retrieved.
Referring to
Given this context, an example implementation will be described in more detail in connection with
In the example shown in
For each resource identifier, various metadata 304 can be stored. Such metadata can include, for example but not limited to: an indication of the application(s) associated with the link data, one or more time stamps indicating when the resource was accessed, a geographic location of the device when the resource was accessed, a plain text title or description of the resource, an indication of the device that hosts the application accessing the link, a type of the resource, data from the application such as a name and image associated with the resource, and the like. Data 308 from the resource, such as a cache of the data received when the resource was last accessed, or other information such as an expiration date for the link and/or the metadata, can be stored. The applications associated with the link data can include the application that instructed the device to store the link data. The link data for a resource 300 also can include metadata 306 not associated with a particular resource identifier, such as keywords, user entered tags, deadline for reading, and the like.
In one implementation, the metadata can indicate whether a particular link is marked as private to a user or to a particular application. Such data can be used to prevent sharing of links between users and/or to prevent links of an application from being accessed by another application. Such metadata can be checked by the operating system or link manager or other application that may be invoked when the link data is accessed or shared.
In one implementation, the metadata also can indicate whether a particular link has been marked for deletion. Links that are marked for deletion can be removed from search results, and sorting and filtering, and other display operations. Links that are marked for deletion can be presented in a separate graphical user interface, for searching, sorting and filtering, and selection, though which links can be undeleted or permanently deleted and purged form the system.
One implementation, in which link data is stored in a data file in the eXtensible Markup Language (XML) format, will now be described in more detail. In such a format, a markup language defines a hierarchical structure of data. Markup elements, defined by labeled start tags and end tags, delineate different data.
In this example format, the data is stored in two parts, delineated by separate markup elements: indexed data and unindexed data. The indexed data includes application information and metadata, also delineated by separate markup elements, where the metadata is defined as a sequence of properties, with each property being defined as a key/value pair within a property markup element, e.g., “<property> <key> key name</key> <value> key value </value> </property>”.
The indexed properties for a link, in this example, include a title, name of the source application providing the link, summary text, date acquired, a deleted flag, a date deleted, and an archive flag. A read/unread flag and a date read also may be stored.
The unindexed metadata for a link, in this example, includes a unique identifier for the link, a URI for the link, a name for the application, image properties for any image associated with the link, and logo properties for any icon associated with the application that provided the link. A creation date and deletion date also can be stored.
This XML data can be stored in a data file for persistent storage of data to be used by the operating system or a link manager application as described below. The data in such an XML file can be processed by the operating system, link manager, or other application into a runtime representation of the data in another data structure.
It should be understood that the stored link data is subject to a variety of possible implementations in terms of the data format and content and storage mechanism, and the foregoing is merely an example.
Referring now to
An application obtains 400 data to access a resource, such as a URL. For example, a browser application receives a URL. The application then submits 402 this link data to the operating system to be stored. For example, the browser application can store the link data in its history, or the user can instruct the browser application to store the link as a “bookmark” or “favorite.” The operating system receives 404 the request and stores the link data. This link data now can be shared with other applications. For example, a second application can request 406 link data from the operating system. The operating system, in response to the request, retrieves 408 link data and provides the link data to the requesting application. The application can then process 410 the received link data. The application, for example, can be a different browser application from which a user can select a link from a list of bookmarks or favorites.
In
Referring now to
In one implementation as shown in
The link manager can include a graphical user interface, examples of which are described below, through which the user can view and manipulate link data. For example, the graphical user interface can present links to a user, and receive an indication of a selected link from the user, and in turn invoke the application that was the source of the link to access the resource represented by the link. An example implementation of such a use case is described by
The link manager also can prompt a user to install an application on a device, if link data is available for an application that is not installed on the device. An example implementation of this use case is shown in
The graphical user interface of the link manager can provide a variety of ways to, search, filter and sort link data for display, using the various metadata from the link data. As an example, link data can be searched for by keyword and field values. Link data also can be sorted and grouped by date of last access. Link data for a resource can be displayed in a format that indicates to a viewer a title of the resource, a time it was last accessed and the application and/or device through which the resource was accessed. Link data can be filtered, for example, by date, application, read or unread status, resource type, keywords, user entered tags, and the like.
An example graphical user interface 900 is shown in
Referring now to
In such a graphical user interface, the display of the link data in the various groups also can be color coded. For example, a light color bar can indicate ‘today’ and a slightly darker bar can indicate “yesterday”, and slightly darker bar can indicate “last week” entries, and then a black bar can indicate the last group. Also, the display of the groups can be limited to only a few groups, or only the headings of the groups for example, and then after some user manipulation, the information in the groups can be expanded.
Through an application programming interface to access such link data from an operating system, applications other than the link manager and operating system also can provide a graphical user interface supporting similar functionality.
With such a system, link data is stored in a consistent format across applications and resources. As a result, the operating system provides a single mechanism for a heterogeneous set of applications and a heterogeneous set of resources to store link data in a single repository. For multiple computers that are associated with a same user account with a networked storage service, link data is stored consistently across a heterogeneous set of devices as well. Further, link data can be shared among users in a consistent manner.
Having now described an example implementation, a computer with which components of such a system are designed to operate will now be described. The following description is intended to provide a brief, general description of a suitable computer with which such a system can be implemented. The computer can be any of a variety of general purpose or special purpose computing hardware configurations. Examples of well-known computers that may be suitable include, but are not limited to, personal computers, server computers, hand-held or laptop devices (for example, media players, notebook computers, cellular phones, personal data assistants, voice recorders), multiprocessor systems, microprocessor-based systems, set top boxes, game consoles, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
With reference to
Additionally, computer 1100 may also have additional features/functionality. For example, computer 1100 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in
Computer 1100 may also contain communications connection(s) 1112 that allow the device to communicate with other devices over a communication medium. Communication media typically carry computer program instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal, thereby changing the configuration or state of the receiving device of the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Communications connections 1112 are devices that interface with the communication media to transmit data over and receive data from communication media, such as a network interface.
Computer 1100 may have various input device(s) 1114 such as a keyboard, mouse, pen, camera, touch input device, and so on. Output device(s) 1116 such as a display, speakers, a printer, and so on may also be included. All of these devices are well known in the art and need not be discussed at length here. Various input and output devices can implement a natural user interface (NUI), which is any interface technology that enables a user to interact with a device in a “natural” manner, free from artificial constraints imposed by input devices such as mice, keyboards, remote controls, and the like.
Examples of NUI methods include those relying on speech recognition, touch and stylus recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, and machine intelligence, and may include the use of touch sensitive displays, voice and speech recognition, intention and goal understanding, motion gesture detection using depth cameras (such as stereoscopic camera systems, infrared camera systems, and other camera systems and combinations of these), motion gesture detection using accelerometers or gyroscopes, facial recognition, three dimensional displays, head, eye, and gaze tracking, immersive augmented reality and virtual reality systems, all of which provide a more natural interface, as well as technologies for sensing brain activity using electric field sensing electrodes (EEG and related methods).
Each component of this system that operates on a computer generally is implemented by software, such as one or more computer programs, which include computer-executable instructions and/or computer-interpreted instructions, such as program modules, being processed by the computer. Generally, program modules include routines, programs, objects, components, data structures, and so on, that, when processed by a processing unit, instruct the processing unit to perform particular tasks or implement particular abstract data types. This computer system may 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.
Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.
The terms “article of manufacture”, “process”, “machine” and “composition of matter” in the preambles of the appended claims are intended to limit the claims to subject matter deemed to fall within the scope of patentable subject matter defined by the use of these terms in 35 U.S.C. §101.
Any or all of the aforementioned alternate embodiments described herein may be used in any combination desired to form additional hybrid embodiments. It should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific implementations described above. The specific implementations described above are disclosed as examples only.
