Maintaining and utilizing copy histories

In some embodiments a method comprises detecting a request to copy and determining information related to the copied data from the document. The method can also comprise augmenting a copy history to include the data and the information related to the data, and storing this copy history. The method can also include detecting a request to access the copy history associated with the document, presenting the copy history including the data and the information related to the copied data, and copying the data from the copy history for further use. The method can also comprise blocking copying of data if the document's copy rules are violated.

TECHNICAL FIELD

Embodiments of the inventive subject matter generally relate to the field of computer software, data processing systems, and networks and, more particularly, to creating and accessing clipboards with a persistent copy history.

BACKGROUND

Users often copy text from documents to a clipboard. However, after the documents are closed, many systems purge the clipboard. Typically, users later reopen the same documents in need of the same text (i.e., the text that was copied to the clipboard). As a result, users may again spend time searching for the text. The time spent finding the needed text may be large, depending on the document size, the user's knowledge of the document, the document's organization, etc.

SUMMARY

In some embodiments a method comprises detecting a request to copy and determining information related to the copied data from the document. The method can also comprise augmenting a copy history to include the data and the information related to the data, and storing this copy history. The method can also include detecting a request to access the copy history associated with the document, presenting the copy history including the data and the information related to the copied data, and copying the data from the copy history for further use. The method can also comprise blocking copying of data if the document's copy rules are violated.

DESCRIPTION OF EMBODIMENT(S)

The description that follows includes exemplary systems, methods, techniques, instruction sequences and computer program products that embody techniques of the present inventive subject matter. However, the described embodiments may be practiced without these specific details. In some instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description.

Introduction

Users commonly copy and paste data within a document or into other applications. For some documents, many different users frequently copy the same data. For example, many users may frequently access a computer configuration document from which they copy login information into a separate computer login application. Before copying the login information into the login application, each user must locate the login information in the document. Finding the information can be a time consuming task, depending on the size of the document, the users' knowledge of the document, available search features, etc. As a result, users may want a system which allows them to search for data within a document based on the document's copy history. Some embodiments of the inventive subject matter enable users to quickly access a documents' earlier-copied data by providing a dynamic but persistent copy history for documents. Some embodiments use metadata to facilitate filtering and data access. The discussion below describes these and other important features in greater detail.

Example Architectures and Operating Environments

Standalone System

FIG. 1is a block diagram illustrating a standalone computer system configured to utilize a persistent copy history for documents, according to some embodiments of the invention. The computer system100includes a processor102. The processor102is connected to an input/output controller hub124(ICH), also known as a south bridge. A memory unit130interfaces with the processor102and the ICH124. The main memory unit130can include any suitable random access memory (RAM), such as static RAM, dynamic RAM, synchronous dynamic RAM, extended data output RAM, etc.

In one embodiment, the memory unit130includes application programs131, documents135, a copy history manager132, and a copy history133. The application programs131can include word processors, text editors, web browsers, or any program that facilitates copying data from a document or other file. The copy history manager132can maintain a persistent copy history for the documents135. That is, if an application program131allows a user to copy a document's content, the copy history manager132can record the copied content and information about the copied content (e.g., information about the user who copied the content, etc.) in the copy history133. As other users access the document, the copy history manager132can present the copy history information. Therefore, users can quickly access content in the copy history without having to locate the content in the body of the document.

In some embodiments, the document's copy history133can be stored as part of the document135as metadata (not shown). In some embodiments, the copy history manager132, copy history133, and application programs131can reside on other forms of machine-readable medium such as flash RAM devices, CD-ROM, magneto-optical storage medium, erasable programmable memory (e.g., EPROM and EEPROM), or other types of media suitable for storing electronic instructions and data.

The ICH124connects and controls peripheral devices. InFIG. 1, the ICH124is connected to IDE/ATA drives108(used to connect external storage devices) and to universal serial bus (USB) ports110. The ICH124may also be connected to a keyboard112, a selection device114, firewire ports116(for use with video equipment), CD-ROM drive118, and a network interface120. The ICH124can also be connected to a graphics controller104. The graphics controller is connected to a display device (e.g., monitor).

In some embodiments, the computer system100can include additional devices and/or more than one of each component shown inFIG. 1(e.g., video cards, audio cards, peripheral devices, etc.). For example, in some instances, the computer system100may include multiple processors, multiple cores, multiple external CPU's. In other instances, components may be integrated or subdivided. In addition, embodiments may be embodied in an electrical, optical, acoustical or other form of propagated signal (e.g., carrier waves, infrared signals, digital signals, etc.), or wireline, wireless, or other communications medium.

FIG. 2is a block diagram illustrating a client-server system configured to maintain and present document copy histories, according to some embodiments of the invention. As shown inFIG. 2, the system200includes a server208and clients201. The server208includes server application programs211, a document repository220, a master copy history manager210, and a master copy history209. The server application programs211can include word processors, text editors, software developments tools, and any other program that facilitates copying data from a document or other file. The clients201include an application program client203, client copy manager202, and document(s)204. In some embodiments, the document's copy history209can also be stored as part of the document220as metadata (not shown).

In some embodiments, the server208enables the clients201to remotely execute application programs and access copy histories. In some instances, the server application programs211(e.g., word processors, text editors, etc.) send data and code for remote execution on the clients201. For example, a server application program211can send a text document and Java script to a client's application program client203. Additionally, the master copy history manager210can send copy history information and Java script for remotely presenting and maintaining a copy history for the text document. In turn, the application program client203can execute the Java scripts, enabling a user to edit and copy the document's content, and to view and utilize the copy history associated with the text document.

The server208and clients201can be any suitable computing devices capable of executing software in accordance with the embodiments described herein. In some embodiments, the application program client203and client copy manager202are included in a web browser.

The server208and the clients201are connected through a communication network214. The communication network214can include any technology suitable for passing communication between the clients and servers (e.g., Ethernet, 802.11n, SONET, etc.). Moreover, the communication network214can be part of other networks, such as cellular telephone networks, public-switched telephone networks, cable television networks, etc.

Example Copy Manager Operations

This section describes operations associated with some embodiments of the invention. The flow diagrams will be described with reference to the architectural block diagrams presented above. Some embodiments can perform more or less than the operations shown in any flow diagram.

FIG. 3is a flow diagram illustrating the operations for creating and storing a persistent copy history, according to some embodiments of the invention. The following discussion will describe the flow300with reference to the client-server system ofFIG. 2. The flow diagram300begins at block301.

At block301, the client copy history manager202detects a copy operation associated with data in a document204. In some instances, a user provides input instructing the client application program203to copy a portion of the document204(or the whole document). The client copy manager202can detect the copy operation by receiving communications from the client application program203, by monitoring copy operations by an operations system (not shown), or by other means. The flow continues at block302.

At block302, the client copy history manager202determines information about the copied data and other related information. For example, the copy manager202can determine what data the user wants to copy, line numbers of the copy data, etc. The related information may include information about the source and target (e.g., source file name, destination file name, source file location, destination file location, etc), user name, user login information, date and time of copying, etc. The flow continues at block303.

At block303, the client copy history manager202determines whether copy rules are enabled. In some embodiments, a “copy rules” flag may be associated with the document (e.g., stored in the document itself or separately). The copy rules flag can indicate that certain copy operations are forbidden (e.g., large block copy operations) to prevent plagiarism, copyright violations, or other unwanted copying. If the copy rules are enabled, the flow continues at block304. Otherwise, the flow continues at block306.

At block304, the client copy history manager202determines whether the copy request violates the document's copy rules. In some embodiments, the client copy manager202itself makes this determination. Some copy rules may prohibit particular users from copying certain documents, while other copy rules may forbid copying from certain files, etc. These copy rules may be associated with the document, user, application, etc. If the copy request violates copy rules, the flow continues at block305. Otherwise, the flow continues at block306.

At block305, the client copy history manager202prevents execution of the copy request. The client copy history manager202can prevent the copy request by sending a message to the client application program203, by sending a message to the operating system (not shown), or by other means. From block305, the flow ends without any updates to the copy history209.

At block306, the client copy history manager202augments the master copy history209to identify the copied data and to include any related information. As shown, the copy history209includes copy information for each document in the document repository220(seeFIG. 2). Thus, when users access a document, they have access to the document's copy history. In some embodiments, the copy information can be associated with a user, source file, destination file, machine, operating system, software, browser, a server, etc. As a result, some embodiments allow users to request copy information based on any of these associations. The server208can provide access to the copy history209via the communication network214. From block306, the flow ends.

The sequence of operations described inFIG. 3can also be performed by the embodiment described inFIG. 1, where the copy history manager132and copy history133reside on the same machine.

FIG. 4is a flow diagram illustrating the operations for accessing and presenting a copy history, according to some embodiments of the invention. As noted above, the copy history manager202can act as an interface between the master copy history209and the client application program203. The copy history manager202can access and display the document's copy history when it receives a request from the user. The following discussion will describe the flow400with reference to the client-server system ofFIG. 2. The flow diagram400begins at block401.

At block401, the client copy history manager202detects a request to access copy history209. In some instances, when the client application program203opens a document, the copy history manager202presents graphical user interface (GUI) controls (e.g., icon, tool bar, etc.) that allow users to access the document's copy history information. If a user activates the GUI controls, the copy history manager202can present the document's copy history information in a window or other GUI component. The client copy history manager202may acquire the document's copy history information from the master copy history manager210when the document is opened or later when a user requests it using the GUI controls. In some embodiments, the copy history information arrives as an XML file. The flow continues at block402.

At block402, the client copy history manager202displays the document's copy history information. In some embodiments, the copy history manager202displays the document's copy history in the GUI window. In some embodiments, the most frequently copied content (e.g., characters, words, phrases) appears most prevalently in the window (e.g., at the top). However, the copy history manager202can decide prevalence based on user attributes, user preferences such as username, user's role in the organization, etc. In addition to the copied content, the copy history information can include source file name, destination file name, source file location, destination file location, date and time of copying, etc. The flow continues at block403.

At block403, the client copy history manager202receives search criteria or keywords related to the previously copied data. The manager's GUI window may include textboxes in which the user types keywords related to the data to be found. The GUI window may also include checkboxes or drop down menus allowing the user to select from a list of pre-defined search criteria (e.g., file location, time of copying, etc). When the user clicks on a “search” button initiating the search, the client copy history manager202receives these keywords and criteria. The client copy history manager202uses these keywords to locate and display the related information. The flow continues at block404.

At block404, the copy history manager202uses the keywords to locate the specified information in the master copy history209. In some embodiments, the client copy history manager202can send the keywords to the master copy history manager210. In turn, the master copy history manager210can use any suitable search procedure or an algorithm to search the copy history209. In some embodiments, the search procedure looks for the actual search terms in the copy history209. However, the search procedure may also look for other related terms. In some embodiments, the master copy history manager210can filter the copy history based on criteria, such as who has copied the data, how many times it has been copied or pasted, when the document was last accessed, which applications used the document, etc. In some embodiments, the manager210can also use the metadata to identify the user's usage patterns and filter the copy history209based on the user or the group of users that have used the document. That is, the manager210may draw on the user's or a group's copy/paste history to locate specific information in the copy history and display the relevant search results to the user. The flow continues at block405.

At block405, the copy history manager202determines whether the relevant information was found in the master copy history209. If the relevant information is in the document's copy history, the server208may send a message to the client201containing the specified information. The message may also have a “data unavailable” flag in its header. This flag can notify the client copy history manager202when information related to the user specified search criteria was not found. If the specified information is not found in the copy history, flow continues at block406. Otherwise, the flow continues at block407.

At block406, the client copy history manager202indicates that the specified information does not exist in the copy history. The client copy history manager202can notify the user by displaying a message in its GUI window or by other means. Alternatively, it can send a message to the client application program203, which notifies the user. From block406, the flow ends without displaying any information.

At block407, the client copy history manager202displays links to the specified information in the document. For example, the client copy history manager202can retrieve the information from the message sent by the server (see above) and present this information in its GUI window. The user can click the links to jump to locations in the document containing the specified information. From block408, the flow ends.

The discussion ofFIG. 4describes the master copy history manager210performing search operations and other functions. However, in some embodiments, the master copy history manager210only delivers a document's copy history to the client201. In turn, the client's components can perform searching and other operations. Furthermore, the sequence of operations described inFIG. 4can also be performed by the embodiment described inFIG. 1where the copy manager132and copy history133reside on the same machine.

CONCLUSION

While the embodiments are described with reference to various implementations and exploitations, these embodiments are illustrative and the scope of the inventive subject matter is not limited to them. In general, techniques for creating, storing and using a persistent copy history are described herein and may be implemented with facilities consistent with any hardware system or hardware systems. Many variations, modifications, additions, and improvements are possible.

In some instances, structure and functionality presented as separate components in example configurations may be implemented with combined structures or components. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the inventive subject matter. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the inventive subject matter.