Patent Publication Number: US-10783012-B2

Title: Systems and methods for efficient inter-device data exchange

Description:
TECHNICAL FIELD 
     Various of the disclosed embodiments relate to systems and methods for storing, organizing, and presenting data across devices. 
     BACKGROUND 
     The digital revolution precipitated by network and computer technologies has changed the habits and expectations of individual users. With the proliferation of personal computers and personal mobile devices, users are not only more empowered than they were previously, but more overwhelmed by the available information. On one hand, users now have the capacity to communicate with peers instantaneously and to access vast repositories of information. Unfortunately, this very plethora of data makes organizing so much information difficult. Similarly, users often lack quick and efficient methods for communicating the disparate and variable-sized data they encounter with their peers. 
     Some operating systems facilitate “clipboards” (or “pasteboards”), which allow users to cut, copy, and paste items between programs and between locations in an operating system. These tools may enable users to transfer text, images, files, objects, and other data from a source program or location managed by the operating system to a destination program or location. These clipboards are often used for short-term data storage or transfer and act as a temporary buffer that can be accessed by many programs on a local machine. While users have incorporated the clipboard into their fundamental set of day-to-day operations, the clipboard operation often remains an artifact of the localized, memory-limited environment in which it originated. Indeed, many operating systems continue to anticipate a single buffer for clipboard operations and provide only limited methods for transferring clipboard data to another device. Similarly, the clipboard data is often stored exclusively in dynamic memory local to the user&#39;s machine, which is volatile, can easily lose the data, and typically lacks any extensive knowledge of previous clipboard operations. 
     Consequently, there exists a need for more sophisticated clip-boarding systems and methods, which anticipate the needs and behaviors of modern, digitally-sophisticated users. For example, there exists a need for systems and methods to efficiently coordinate context-sensitive data management between users, where the users dynamically select the organizational contexts, but the system maintains an efficient record of the data allocated to each user-identified context. Such systems and methods may permit users to seamlessly interact with their devices and with one another. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Various of the embodiments introduced herein may be better understood by referring to the following Detailed Description in conjunction with the accompanying drawings, in which like reference numerals indicate identical or functionally similar elements: 
         FIG. 1  is a schematic diagram illustrating an example topology of various elements as may be implemented in some embodiments; 
         FIG. 2  is a schematic block diagram illustrating an example relation between various operational modules as may be implemented in some embodiments; 
         FIG. 3  is a schematic diagram illustrating an example client user interface for client bucket management software as may be presented to a user in some embodiments; 
         FIG. 4  is a schematic diagram illustrating an example client user screen during a portion of a copy-to-bucket process associated with a text editor in some embodiments; 
         FIG. 5  is a schematic diagram illustrating an example client user screen during another portion of a copy-to-bucket process associated with the native text editor of  FIG. 4  as may occur in some embodiments; 
         FIG. 6  is a schematic diagram illustrating an example client user screen during a completed portion of a copy-to-bucket process associated with the native text editor of  FIG. 4  as may occur in some embodiments; 
         FIG. 7  is a schematic diagram illustrating an example client user screen during a portion of a copy-to-bucket process associated with a native image editor as may occur in some embodiments; 
         FIG. 8  is a schematic diagram illustrating an example client user screen during a portion of a copy-to-bucket process associated with a native spreadsheet editor as may occur in some embodiments; 
         FIG. 9  is a collection of schematic diagrams illustrating an example client user screen during a portion of a paste-from-bucket process associated with an image item as may occur in some embodiments; 
         FIG. 10  is a collection of schematic diagrams illustrating configurations in server and client-side devices during various insertion and removal operations as may occur in some embodiments; 
         FIG. 11  is a flow diagram illustrating various operations in an example copy-to-bucket process as may be implemented in some embodiments; 
         FIG. 12  is a flow diagram illustrating various operations in an example copy-to-bucket process using data chunks as may be implemented in some embodiments; 
         FIG. 13  is a flow diagram illustrating various operations in an example memory management threshold determination process as may be implemented in some embodiments; 
         FIG. 14  is a flow diagram illustrating various operations in an example threshold-based memory reallocation process as may be implemented in some embodiments; 
         FIG. 15  is a flow diagram illustrating various operations in an example paste-from-bucket process as may be implemented in some embodiments; 
         FIG. 16  is a flow diagram illustrating an example multi-item paste process as may be implemented in some embodiments; 
         FIG. 17  is a flow diagram illustrating various operations in an example item deletion process as may be implemented in some embodiments; 
         FIG. 18  is a flow diagram illustrating various operations in an example item deletion process using data chunks as may be implemented in some embodiments; 
         FIG. 19  is a flow diagram illustrating various operations in an example data expunging operation associated with the operations of  FIG. 18  as may be implemented in some embodiments; 
         FIG. 20  is a schematic diagram illustrating an example topology of various bucket relations as may occur in some embodiments; 
         FIG. 21  is a schematic diagram illustrating an example client user screen during a portion of a share-between-users process as may occur in some embodiments; 
         FIG. 22  is a schematic diagram illustrating an example client user screen during a peer-selection portion of the share-between-users process of  FIG. 21  as may occur in some embodiments; 
         FIG. 23  is a schematic diagram illustrating an example client user screen during a completed peer-selection portion of the share-between-users process of  FIG. 21  as may occur in some embodiments; 
         FIG. 24  is a flow diagram illustrating various operations in an example share-between-users process as may be implemented in some embodiments; 
         FIG. 25  is a flow diagram illustrating various operations in an example share-between-users process using data chunks as may be implemented in some embodiments; 
         FIG. 26A  is a schematic diagram of a client graphical user interface including a bucket selection interface as may be implemented in some embodiments; 
         FIG. 26B  is a schematic diagram of a bucket management selection window as may be implemented in some embodiments;  FIG. 26C  is a schematic diagram of a bucket deletion confirmation window as may be implemented in some embodiments;  FIG. 26D  is a schematic diagram of a bucket creation confirmation window as may be implemented in some embodiments; and  FIG. 26E  is a schematic diagram of the bucket management window of  FIG. 26B  following various creation and editing operations as may occur in some embodiments; 
         FIG. 27  is a flow diagram illustrating various operations in bucket creation process as may be implemented in some embodiments; 
         FIGS. 28A-D  are schematic diagrams of various graphical user interfaces that may be presented to the user during a quick-copy or quick-cut process as may be implemented in some embodiments; 
         FIG. 29  is a flow diagram illustrating various operations in a quick-copy or quick-cut process as may be implemented in some embodiments; 
         FIG. 30  is a schematic diagram illustrating various states of a graphical user interface that may be presented to the user during a search operation as may be implemented in some embodiments; 
         FIG. 31  is a flow diagram illustrating various operations in an example search process as may be implemented in some embodiments; 
         FIG. 32  is a schematic diagram illustrating various states of a graphical user interface that may be presented to the user during window creation, bucket selection, and online status operations as may be implemented in some embodiments; and 
         FIG. 33  is a block diagram of an example computer system as may be used in conjunction with some of the embodiments. 
     
    
    
     The specific examples depicted in the drawings have been selected to facilitate understanding. Consequently, the disclosed embodiments should not be restricted to the specific details in the drawings or the corresponding disclosure. For example, the drawings may not be drawn to scale, the dimensions of some elements in the figures may have been adjusted to facilitate understanding, and the operations of the embodiments associated with the flow diagrams may encompass additional, alternative, or fewer operations than those depicted here. Thus, some components and/or operations may be separated into different blocks or combined into a single block in a manner other than as depicted. The embodiments are intended to cover all modifications, equivalents, and alternatives falling within the scope of the disclosed examples, rather than limit the embodiments to the particular examples described or depicted. 
     DETAILED DESCRIPTION 
     Example System Topology Overview 
       FIG. 1  is a schematic diagram illustrating an example topology of various elements as may be implemented in some embodiments. Particularly, in this example, users  120   a ,  120   b ,  120   c  may be working on a variety of both team and individual-based tasks. For example, the users  120   a - c  may be game developers, each with specific skillsets, who are now trying to integrate the various assets they&#39;ve generated (e.g., software code, graphics, sound files) into a single product. User  120   a  may also independently be assembling images and text for a wedding album by exchanging data between devices  125   a  and  125   b.    
     While the users  120   a - c  may be located at a single location, in this example, they are located at three distant locations  115   a - c . Users  120   a - c  may be performing their various tasks with the assistance of various computer devices  125   a - d . For example, user  120   a  may be using a desktop computer  125   a  and a laptop computer  125   b  at location  115   a , while user  120   b , uses a mobile device  125   c  (e.g., a tablet or mobile phone) at location  115   b . User  120   c  may employ a desktop computer  125   d  at location  115   c.    
     To accomplish their various tasks, the users  120   a - c  may wish to quickly and efficiently organize and share data across the devices  125   a - d . For example, user  120   a  may wish to exchange images and text between devices  125   a  and  125   b  while creating their wedding album. Simultaneously, user  120   a  may wish to exchange graphical images via device  125   a  with user  120   c &#39;s device  125   d  as part of the game development. 
     While the users  120   a - c  may connect their respective devices via network  105  (such as a local area network or the Internet) to transmit  110   b,c,e  and receive  110   a,d,f  information, it may be inefficient to do so. For example, exchanging many files via a shared network drive, instant messaging, or via email may reduce the user&#39;s productivity. Rather than work and communicate in real-time, the users may instead be inclined to transmit large “clumps” of data over long intervals. Similarly, different methods may be better suited for different tasks and interoperability requirements. Thus, user  120   a  may use one method when communicating between devices  125   a  and  125   b  (e.g., a folder shared over the network or a USB memory stick), while using a different method (e.g., email) to communicate with user  120   c &#39;s device  125   d  via device  125   a.    
     Rather than pursue these disparate, ad-hoc exchange methods, the users  120   a - c  may agree to use a centralized server system  150 . Server system  150  may be located on the same site as the users in some embodiments (e.g., when network  105  is a local area network) or, as depicted here, at a separate remote location  115   d  (e.g., when network  105  is the Internet). The server system  150  may comprise a data server  135 , a metadata server  130 , a data store  140   b , and a database  140   a  and may receive  110   g  and transmit  110   h  data via the network  105 . Though depicted here as four separate entities, one will appreciate that this illustration is provided merely to facilitate comprehension and that in some embodiments the systems may be merged (e.g., a single SQL database serving for both the data store  140   b  and a database  140   a ) or divided differently. Server system  150  may comprise a number of servers and custom software may coordinate the communication between the clients, including the upload, download of items, synchronization of “buckets” containing items to be exchanged, real-time event notification, etc. As used herein, “items” or “data objects” may be used to refer to data stored and exchanged through the bucket management programs, such as files, folders, or portions of files (substrings of text in a text file, pixels from an image, cells from a spreadsheet, etc.). Not only may “buckets” provide a vehicle for users to organize their data locally, but they may also provide a vehicle for coordinating data exchanges between users and for managing data allocation at the server system  150 . In conjunction with various memory management processes described herein, such logical divisions may facilitate both increased user efficiency and task-switching, as well as system-coordinated sharing. This may be especially useful, for example, where different users have different specific tasks involving different data types. 
     In conjunction with client-side software operating on each of devices  125   a - d , the system  150  may facilitate a centralized method for exchanging data between the devices  125   a - d . As described in greater detail herein, in some embodiments the client-side software may provide a clipboard item container interface. This interface may provide a central, persistent, synchronized system for collecting clipboard items between devices. For example, as user  120   a  copies images to the client software on device  125   a , the raw image data may be stored in datastore  140   b  via data server  135 . Similarly, metadata (e.g., the size, name, data type, time acquired, associated user(s), etc.) associated with the image may be stored in database  140   a  via metadata server  130 . This data may then be accessed by user  120   c  via client-side software on, e.g., device  125   d.    
     Thus, the client software in combination with server system  150  may enable users to easily pass information between applications on separate machines using a consolidated interface. Unlike the native operating system clipboard operation, where data resides in the local memory of one of devices  125   a - d , here, the users may instead store large and more complicated data via server system  150 . 
     While this example presents a topology clearly separating client devices  125   a - d  and the client-software thereon from the server system  150 , one will appreciate that the topology may be modified without substantial functional effect in other embodiments. For example, in a local area network, a single user&#39;s client software may be designated the “server system” and used as the central repository for the other users&#39; copying operations. In such a circumstance, the server system  150  may also be one of devices  125   a - d.    
     Example System Topology Overview—Example Modular Division 
       FIG. 2  is a schematic block diagram illustrating an example relation between various operational modules as may be implemented in some embodiments. As discussed above, each of the users may install client software on their respective devices  125   a - d  for communication with server system  150 . For example, user  120   c  may install client software  205  onto device  125   d . In the schematic block diagram of  FIG. 2 , the client software  205  may comprise a variety of software “modules.” These modules may be software code, hardware, firmware, or combinations thereof, designed to fulfill a particular purpose. 
     For example, the connection management module  210   a  may be software routines configured to connect with the server system. The clipboard item management module  210   b  may locate clipboard data for the operating system of device  125   d . The buckets management module  210   c  may coordinate bucket synchronization, using software implementing the operations and methods discussed elsewhere herein. The persistence module  210   d  may implement caching optimization rules. The synchronization module  210   e  may apprise the server and client of changes on each. The memory management module  210   f  may determine when local copies or server-side copies of data objects should be used. As described in greater detail herein, memory management module  210   f  may be used to determine which items are made readily accessible, e.g., in RAM memory, and which are cleared from RAM to more efficiently use local resources. Inefficient management may adversely impact the user experience both when too little RAM is allocated and when too much is allocated for copied items. For example, if the user is a sound or graphic designer with RAM-intensive resource requirements, even though they may wish to rapidly access previously stored items, they may also wish to have RAM available for their sound and graphic workspace. Accordingly, various methods described herein facilitate memory management module  210   f &#39;s balancing of these competing interests. 
     A real-time event actuator module  210   g  may notify the user of events as they occur or at the request of the server system. Real-time event actuator module  210   g  may also “actuate” events locally (events which may have been performed on other devices). For example, if a first user deletes an item from a bucket representation on a first device, a notice from the server to real-time event actuator module  210   g  may precipitate a corresponding deletion locally at a second device (as well as corresponding memory management adjustments). 
     The user interface module  210   h  may present the client software GUI described herein and facilitate GUI operations on the user&#39;s system&#39;s operating system. The contacts/sharing module  210   i  may be software for interfacing with the user&#39;s address book, as may be stored locally in an email client, remotely on an email server, a digital phonebook, etc. Contacts/sharing module  210   i  may also facilitate item sharing between devices running client software (e.g., as when the user clicks an item and selects “Share with friends” as described in greater detail herein). The data format converters module  210   j  may convert disparate data types to a common byte format. For example, text data received in various encodings may be converted to a common encoding format. 
     In some embodiments the metadata server  130  may also include various modules (again being software, firmware, hardware or combinations thereof) for performing various operations some of which may communicate with data store  140   b . For example, an authentication module  215   a  may ensure that the user&#39;s interactions are performed under the appropriate account. Account management module  215   b  may store account data (e.g., membership type, data storage and transfer quotas, billing data, etc.) while bucket management module  215   c  may coordinate bucket states with buckets management modules  210   c . Bucket item metadata module  215   d  may coordinate storage of data object metadata, such as the data&#39;s type, size, corresponding chunks, etc. Sharing/permissions module  215   e  may ensure that users only share buckets and objects in accordance with their sharing permissions, account levels, or other restrictions. 
     Notifications module  215   f  may determine when users should be notified, e.g., of errors related to a command, that a data object&#39;s raw data will be expunged, and other notifications to apprise the user of the system&#39;s status. Real-time event dispatch module  215   g  may direct client software systems to perform immediate events, such as begin an item removal from a bucket. An analytics module  215   h  may record user behavior, client software operations, or server operations, and may facilitate subsequent or real-time review of the various modules&#39; operations. 
     In some embodiments the data server  135  may comprise various hardware, software, or firmware modules for performing various operations some of which may communicate with database  140   a . For example, an authentication module  220   a , like authentication module  215   a  may ensure that the user&#39;s interactions are performed under the appropriate account (again, one will appreciate that modules may be merged in some embodiments and that only a single module on one of the servers may be used). Data chunks storage/retrieval module  220   b  may facilitates storage and retrieval of data chunks associated with a various objects as described in greater detail herein. Permissions checking module  220   c , like permissions module  215   e , may ensure that the user (as requestor or as recipient) has appropriate permissions for a requested operations. Persistent storage management module  220   d  may operate in conjunction with persistence module  210   d  to ensure desired caching occurs at the client system or at the server. Analytics management module  220   e , like analytics module  215   h , may record user behavior, client software operations, or server operations, to facilitate subsequent or real-time review of the various modules&#39; operations. Again, modules may be omitted or combined in various embodiments than as shown here to facilitate understanding. 
     Example Client-Side Graphical User Interface 
       FIG. 3  is a schematic diagram illustrating an example client user interface  305  for client bucket management software as may be presented to a user in some embodiments. Particularly, user device  125   d  may comprise a keyboard  340   a , mouse  340   b , and display  340   c . The display  340   c  may depict the GUIs for a variety of programs running on the operating system of device  125   d , e.g., windows  345   a  and  345   b  may be GUIs for text editing or graphical applications. Note that in some embodiments, device  125   d  may simply be relaying the screen from a remote system (e.g., via a remote login). The clipboard bucket management client system software may have likewise been installed on the operating system and may present its own GUI window  305 . The GUI  305  may generally be placed over the other program windows  345   a  and  345   b , as shown, to facilitate ready access. In accordance with some operating system&#39;s windowing structure, minimization and closing icons  355  may be provided for performing the respective operations. 
     In this example, GUI  305  may comprise five portions: a general toolbar menu  360 ; an action selection toolbar  310 ; bucket selection interface  315 ; item stack window  320 ; and a network/bucket-size summary region  365 . General toolbar  360  may comprise one or more keywords (“File,” “Edit,” “Help,” etc.) for accessing various command dropdowns. For example, selection of the File keyword may present a dialog for closing the client software program, modifying user preferences, adjusting connection properties, etc. 
     Action selection toolbar  310  may comprise a plurality of icons  310   a - f  associated with various user operations. For example, icon  310   a  may include scissors and be associated with the cut or with the quick-cut command discussed in greater detail herein. Icon  310   b  may include two documents and be associated with the copy or with the quick-copy command discussed in greater detail herein. For example, selecting icon  310   a  may perform a Cut (Ctrl-X) operation, or in some embodiments a “Quick Copy,” operation (e.g., when combined with a keyboard command). Similarly, selecting icon  310   b  may perform a Copy (Ctrl-C), or in some embodiments a “Quick Cut,” operation (e.g., when combined with a keyboard command). Selecting icon  310   c  may perform a Paste (Ctrl-V) operation. Selecting icon  310   d  may perform a “new copy from screenshot” operation. This may allow creation of an image data object from, e.g., the entire screen or a portion of the screen. Selecting icon  310   e  may perform a “new copy from text” operation, which may allow creation of a text item from user input. In some embodiments, the user&#39;s input may be formatted as plain text or rich text (e.g., by presenting a new text input window). Selecting icon  310   f  may present a settings interface for setting client software program settings (e.g., user account settings, network connectivity settings, GUI style, etc.). 
     Bucket selection interface  315  may be a drop-down selection interface used to select a “bucket.” A bucket may comprise the plurality of data items organized together. Buckets may not be limited to including just files and folders, but may also include portions of files (e.g., string of texts, collections of pixels, etc.) as data objects. The creation and use of buckets may be used to logically organize the data by the user. For example, one bucket may be dedicated to images for a first product, a second bucket for personal text notes, a third bucket for useful code snippets, etc. Some embodiments may facilitate “sub-buckets” within buckets, and varying levels, to further accommodate various organizational preference. 
     The items in a bucket may be depicted in item stack window  320  when the user selects the corresponding bucket name from selection interface  315 . In some embodiments, the user may reorder items within a clipboard item container by moving/dragging single items or several items up or down in the item stack window  320 . Though the items may originally be ordered as they were received by the program (e.g., from the user or from a server), using drag-and-drop movements, the user may override the original order of the items. For example, items that are often accessed can be moved up closer to the top of the list. In some embodiments, the user may drag a single item or multiple items from the clipboard item container to another application or the operating system file system. The target application may then receive the items and can handle them directly, e.g., as it would have received a “normal” paste operation. 
     Item stack window  320  may comprise a plurality of item icons  320   a - g  organized as a vertical, sequentially ordered stack, in that each item is either above or below each of the other items. Each item icon is associated with a corresponding portion of data entered into the clipboard system. For example, item icon  320   a  is associated with text data comprising the phrase “Hello World!”, item icon  320   b  is associated with rich text copied from a Microsoft Word™ document, item icon  320   c  is associated with a Python file, etc. As indicated in this embodiment, the icons may change depending upon the nature of the copied content. For example, for each of the PNG image file associated with icon  320   e  and the JPG image file associated with icon  320   g , a reduced size “thumbnail” of the image may be included in the icon (in some embodiments, a generic “image” icon may be used, where a thumbnail cannot be easily generated). Similarly, a folder of directory files may be presented by a folder icon as in item icon  320   d . File and folder items may be displayed as icons with their names, similar to how they would appear on the local operating system. In some embodiments, if the item is text, the text in the icon representation may be truncated to fit in the available space (the user may be able to specify icon dimensions in some embodiments). If the item is an image in some embodiments it may be resized to fit in the available icon image space. 
     Each icon may be associated with a numerical identifier in its upper left corner. This identifier may indicate the item&#39;s position in the stack in reverse chronological order (i.e., the first items is the most recently added) based upon the order in which it was added to the stack (until, e.g., the user reorders the items). For example, prior to any user reordering, the JPG image associated with item icon  320   g  was inserted into the stack for this bucket before the rich text associated with item icon  320   f  was inserted. Consequently, the numerical identifier ( 7 ) associated with the JPEG image is greater than the numerical identifier ( 6 ) associated with the rich text. The “Hello World!” text, having a numerical identify of “1” is the most recent item to be added to the stack. 
     A removal icon, such as an “x” may be placed in the upper right corner of each item icon  320   a - g  to facilitate removal of the item from the bucket by the user as discussed in greater detail herein. Note that more than seven items may be present in the stack and scroll bar  335  may be used to view additional items at lower positions in the stack. In some embodiments, as the data for each of the items may be stored in server system  150 , rather than locally on device  125   d , the GUI  305  may depict many more items in each of the buckets than it may be feasible or possible to store in device  125   d &#39;s local memory or disk. 
     Network/bucket-size summary region  365  may be used to inform the user of the client software&#39;s network status and memory footprint for a given bucket. Particularly, circular icon  325   a  may provide visual indicia (e.g., via color) in conjunction with textual indication  325   b  whether the client software is in network communication with server system  150 . Though a textual indication is shown here, one will appreciate that only a graphical indication or auditory indication may instead be used in some embodiments. When the client software is in communication with the server system  150 , the user may have complete access to all their buckets, as well as their contents, and the capacity to add as many new items as the server system&#39;s  150  memory may support. Conversely, when the client software is not in communication with the server system  150 , only locally cached copies of the bucket contents may be available. Similarly, the user may be limited to the number of new items they may add, based on memory limitations local to device  125   d . A memory footprint indicia  330  may also be provided to assist the user with assessing the memory consumed by the selected bucket. Note that this may be the cumulative size of all the items&#39; sizes in the bucket, rather than the actual memory consumed by all copies (in local memory, in local disk, on the server, etc.) of the items created by the system. Understanding the collective size of the items in the bucket may, e.g., help the user assess how best to transfer the bucket to another user, whether to redistribute bucket contents, anticipate offline access, etc. 
     Some embodiments use this arrangement of interfaces and icons discussed above in GUI window  305 , the quick copy/cut functions, and the bucket-based memory management operations described herein to improve user efficiency via GUI interactions and via interactions with the server system. The harmonized interfacing of GUI and server-side operations facilitates a sense of seamless integration between various client devices. For example, simultaneous appreciation by multiple users of the available buckets, their contents, and relative size via the components of GUI window  305 , in combination with efficient respective memory management, e.g., via memory management module  210   f , can encourage users to use GUI window  305  as an indirect method for communicating with one another. Depositing and viewing items in various buckets may become not only a method for exchanging data directly between users, but also a tool for implicitly coordinating one another&#39;s progress without disrupting the behavior of local workspace programs (and consequently, each user&#39;s individual efficiency). 
     Example Client-Side Copy and Paste Operations 
       FIG. 4  is a schematic diagram illustrating an example client user screen during a portion of a copy-to-bucket process associated with a text editor in some embodiments. For example,  FIG. 4  may depict the user&#39;s screen in schematic fashion, wherein a window  405  corresponding to Microsoft Notepad™ includes text  410  (one will appreciate a number of text editors that may be used instead, e.g., Emacs™ Vi™ Microsoft Word™, etc.). The user has selected the text  410  and clicked with the right mouse button to present the option window  415  and then selected “copy” to place the text in the operating system clipboard member. While this visual, graphical approach is shown here to facilitate understanding, one will appreciate that different programs will facilitate disparate ways for moving data to the operating system clipboard, including, e.g., combinations of keypresses, dedicated keyboard keys, mouse gestures, etc. 
       FIG. 5  is a schematic diagram illustrating an example client user screen during another portion of a copy-to-bucket process associated with the native text editor of  FIG. 4  as may occur in some embodiments. Here, following the events of  FIG. 4 , the user has selected the “Paste” option from the Edit keyword  510  to produce an overlay  505 . Again, one will appreciate that the user could have instead brought the window  305  into focus and hit the keyboard commands “control” and the letter “v,” in some embodiments dragged the selected text to the GUI  305 , etc. 
       FIG. 6  is a schematic diagram illustrating an example client user screen during a completed portion of a copy-to-bucket process associated with the native text editor of  FIG. 5 . Here, the text data has been pushed to the top of the stack and item stack window  320  has been updated with a new item icon  605  corresponding to the new data object associated with the “Default” bucket. As explained previously, the remaining items have been moved to a “lower” position in the stack and their numerical indicator updated accordingly. In this example, the system associates the newly inserted data with the “Default” bucket as that bucket is presently selected. In some embodiments, various buckets may be associated with various datatypes and data inserted in the appropriate bucket, rather than simply the bucket presently selected. In some embodiments, such an insertion may cause the system to select the appropriate bucket and present the corresponding item icons in item stack window  320 . Here, however, the text item is added to the top of the list of items at the first position and a preview is generated. If the text is too long to fit in the available space, the preview generated may be in the form of truncated text. 
     In some embodiments, the client software alone may recognize the nature of the data, while in some embodiment the client software may defer to the server system. In either case, the encoding and active programs may be used to infer the data type. In some embodiments, for an item introduced locally into the client software, the client software may perform the initial type determination based upon encoding formats, filename conventions, operation system parameters, etc. The client may communicate these findings to the server as metadata indicating what kind of data an item contains (e.g., txt, rtf, png, bmp, tif, file, etc.). A remote client may then recreate the data of the local environment based upon the item&#39;s raw data and metadata received from the server. For example, if the metadata says “txt”, the remote client may interpret the data as a UTF-8 encoded byte array and recreate that string locally. 
     One will readily appreciate that the operations of  FIGS. 4-6  may be applied in the context of other programs and data types. For example,  FIG. 7  is a schematic diagram illustrating an example client user screen during a portion of a copy-to-bucket process associated with an native image editor as may occur in some embodiments. Here, the user has copied an image of a flower from a paint program window  705  to the client software. For example, the user may have copied the entire image from the desktop, or may have selected a pixel subset via the editor and pasted the subset into the client software program. Again, the client software program has updated the stack window  320  to include new item icon  710  corresponding to the image data. Similarly,  FIG. 8  is a schematic diagram illustrating an example client user screen during a portion of a copy-to-bucket process associated with a native spreadsheet editor as may occur in some embodiments. In this example, the user selects a number of cells in a spreadsheet program window  805 , copies them to the operating system clipboard and then pastes them to the clipboard item container GUI  305 , precipitating the creation of the new icon  810 . Analogous operations may be performed by copying and pasting folders and files from the operating system&#39;s file manager, terminal text, etc. As discussed in greater detail below, these spreadsheet values may be sent to another client software instance on another device via the server system  150 . The other device&#39;s user may then copy the cells from the item container and paste them into another spreadsheet software instance or other suitable receiving program. In this manner, the users may seamlessly move a portion of spreadsheet data between computer systems. 
     One will appreciate that data may be moved from the clipboard item container GUI  305  to a program on the operating system by performing operations in the opposite direction. For example, the user may click on one or more items in the clipboard item container stack window  320  and choose “Copy” (either through a program menu, context menu, button, keyboard shortcut, drag-and-drop operations with a mouse, or toolbar button). The client program may then load these items into the local operating system&#39;s clipboard. The user may then switch to another program and select the “Paste” action within that program (again, via a graphical interface, via keyboard commands, drag-and-drop operations with a mouse, etc.). The item(s) may then be pasted into the program (e.g. word processor, desktop publishing software, image editing program, code editor, etc.). 
     To facilitate understanding,  FIG. 9  is a collection of schematic diagrams illustrating an example client user screen during a portion of a paste-from-bucket process associated with an image item as may occur in some embodiments. Initially at state  900   a , an image editing program  915  may present an empty image layer. The client GUI  305  (shown here with a reduced vertical height to facilitate illustration) may be presented on the same screen. The user may select the PNG image data object via icon  710  and indicate a desire to transfer  910  (via a cut or, as shown here, copy operation) the data object to the native operating system memory and then to the program  915 , or, in some embodiments, to the program  915  directly. For example, the user may use a quick cut or quick copy operation as described elsewhere herein. The user may select the icon  710  and copy its contents to the operating system&#39;s clipboard memory (e.g., using the “CTRL-C” keyboard command), select the program  915 &#39;s window and then paste the clipboard memory (e.g., using the “CTRL-V” keyboard command). In some embodiments, the user may transfer  910  the data object by selecting the icon  710  with their mouse and dragging it directly to the window of program  915 . Once transferred, the native operation may process the pasted data as it would do so normally. Here, for example, in state  900   b , the program  915 &#39;s window now reflects the data object&#39;s image data. Had a cut, rather than copy, been performed, item icon  710  would be removed and the stack adjusted. 
     Example Data Object Management 
       FIG. 10  is a collection of schematic diagrams illustrating configurations in server and client-side devices during various insertion and removal operations as may occur in some embodiments. Initially, at a time  1005   a , a user  120   c  may be working on a local computer system  125   d , using a bucket management program, e.g., with GUI  305 , to store or exchange data objects, such as files, folders, or portions of files (substrings of text in a text file, pixels from an image, cells from a spreadsheet, etc.), with other users. In this initial state, the user&#39;s previous actions, or items received from other users, may have resulted in the client-side&#39;s bucket management program&#39;s Disk Memory  1015  and GUI icon display  1020  (e.g., the icon order appearing in item stack window  320 ) being as shown in at time  1005   a.    
     That is, local computer system  125   d  may allocate Disk Memory  1015  for the bucket program to store data objects represented here as Items A, B, C, D. Similarly, the GUI display may show icons corresponding to each of Items A, B, C, and D. Note that the local storage need not mirror the linear ordering of the GUI icons. For example, in some embodiments, a single data object&#39;s data may be distributed across different portions of local computer system  125   d &#39;s disk memory, e.g., in chunks. Hash functions and compression techniques may be used for storing and retrieving object data, locally and at server system  150 . Server system  150  may also reflect the current client&#39;s state by retaining copies of the data objects in server memory  1010  (e.g., a long-term storage disk memory). For example, raw item data may be stored in data store  140   b  and metadata regarding the items in database  140   a , such as their size, data type, bucket correspondence, bucket position, etc. Metadata may include a hash index, indicating where distributed chunks of a data object copy appear in the server memory or database. 
     The user  120   c  may introduce  1025  a new data object, shown here by Item X, into the bucket management program (e.g., by dragging and dropping a file). This may precipitate a change in state as shown at time  1005   b . Here, a new icon for Item X appears in the GUI  1020  at a topmost position of the sequential order. Similarly, the raw data for Item X has been stored in the local disk memory  1015  and may also include metadata indicating Item X&#39;s bucket correspondence, data type, etc. The raw data and accompanying metadata may also be replicated in the server memory  1010 . In some embodiments, Item X&#39;s data and metadata may also be pushed to other peers sharing the bucket. Data object and bucket replication between server system  150  and local computer system  125   d  may facilitate various operations, including caching operations, recovery operations, redundancy capabilities, and data integrity verification. 
     For example, when a user removes an item, e.g., cuts or deletes  1030  Item B from the local GUI  1020  at time  1005   c , the local GUI representation may indeed remove the Item as shown at time  1005   d . The metadata associated with Item B may be updated at both the local computer system  125   d  and server system  150  to reflect the removal (e.g., an index relating data objects to buckets may be updated). This change may likewise be pushed to metadata and GUI representations on client systems sharing the bucket. 
     However, in some embodiments, the local disk memory  1015  and the server memory  1010 , and in some embodiments peer device&#39;s memory, may retain Item B&#39;s data. This retention may facilitate recovery operations (e.g., an undo operation) either by the user  120   c  or a peer. During such recovery, the GUI  1020  may be adjusted to reintroduce an icon associated with Item B. 
     In some embodiments, various metrics may be used to finally remove data, e.g., as shown at time  1005   e  where Item B has been removed from both the disk memory  1015  and GUI  1020 . In some embodiments removal may proceed in stages based, e.g., on caching expectations in the event of a recovery operation. For example, the retained data may be removed from peer data after a first delay has elapsed without a recovery operation. If, after a second delay, the data continues not to be recovered, then the copy on the computer system  125   ds  disk memory  1015  may be removed. Finally, after a third delay the item may be removed from the server memory  1010 , thereby making recovery impossible. One will appreciate that a different order of removal may be applied in some embodiments, depending on the functionality being optimized. 
     To facilitate understanding with respect to the distinction between data content storage and item representation during deletion, this example indicates the presence of item data in disk memory  1015  simply. However, as discussed, e.g., with respect to  FIGS. 13 and 14 , one will appreciate that the client software may further distinguish between storing item data exclusively in local quick-access memory (e.g., RAM), exclusively in local disk storage memory (e.g., a local hard drive), storing data in both, or in neither in favor of server-side quick-access or disk storage memory. The representation in GUI  1020  may perform independently in each of these cases, e.g., as described in this example (e.g., the GUI may remove the item&#39;s icon from the user&#39;s view even though the item&#39;s data remains at one or more of these locations). 
     Example Process Operations 
       FIG. 11  is a flow diagram illustrating various operations in an example copy-to-bucket process  1100 , e.g., as described above in  FIGS. 4-8 , as may be implemented in some embodiments. As indicated, many of the operations may be performed at the client software in this example. At block  1105 , the user may perform a copy operation native to the application running on the operating system, thus placing the data in the operating system&#39;s clipboard memory. For example, in the Notepad™ text editor, the user may select text and press the “control” key and the letter “C” key simultaneously. 
     At block  1110 , the user may manifest their intention to transfer the data in the operating systems&#39; clipboard to the bucket. For example, the user may select the client application window GUI, select the desired bucket, and press the “control” key and the letter “V” key. As indicated in  FIG. 5 , the user may also use the window&#39;s “Paste” option from the Edit keyword  510 , to move the operating system clipboard data into the bucket. Similarly, in some embodiments, the user may drag and drop items to the bucket window. 
     At blocks  1115  and  1120 , the client software system may acquire the native operating system data and begin interpreting the item&#39;s properties. For example, the client software system may determinate the data size and type of the data. At block  1125 , the system may note the active bucket with which the item is to be associated. At block  1130 , the client software system may store a local copy of the data object (e.g., using hashes and chunks). However, in some embodiments, e.g., those where local memory is limited on the client device or the data objects are large, this block may be omitted in favor of exclusively server or peer-side storage. At block  1135 , the client software system may update the GUI to reflect the new data object&#39;s icon within the relevant bucket (note that no visible update may occur in some embodiments if the relevant bucket is not selected). 
     If the client software determines that a network connection with the server system  150  is available at block  1140 , e.g., if the user has not disconnected the connection with the server and the network is still online, then at block  1145 , the client software may transmit the item data and metadata for insertion into the server system  150 &#39;s databases. For example, metadata may be placed in a database  140   a  and item data placed in a data store  140   b  (such as Amazon Web Service S3™) Database and datastore separation of data in this manner may facilitate more efficient access management at the server. Although not depicted in the diagram, when the client cannot access the server system  150 , in some embodiments, the client may store the item locally at block  1130  until a follow up attempt to connect with the server is successful. Subsequently, when the client software connects with the server system  150 , the locally stored items may be pushed to and, and reconciled, with the server data. 
     At block  1150 , the server system may similarly direct peer users&#39; GUIs to depict the presence of the new item in the bucket. In some embodiments, the refresh is performed following server confirmation that the new item has been successfully stored. However, the refresh may instead occur once the local copy has been created, or after the data was transmitted to the server. At block  1145 , the server may likewise direct peer clients to refresh their bucket representations to reflect the change. 
     While  FIG. 11  indicates common operations to some embodiments, more refined interactions between the client software and server software may be performed to facilitate memory efficiency in some embodiments. The operations may also be refined to enforce various permission levels and privacy settings. For example,  FIG. 12  is a flow diagram illustrating various operations in an example copy-to-bucket process  1200  using data chunks as may be implemented in some embodiments. Following receipt of the user&#39;s indication to introduce a data object into the bucket, at block  1205 , the client software system may determine the memory size of the data object. If the size is determined to be acceptable at block  1210  for the user&#39;s data plan (for example, by consulting account data, such as quotas, for the user at an account management server or account management module  215   b ), then the client-side application may proceed to block  1215 , and make a copy of the data object in the client device memory (this copy may or may not be “chunked” as described below). If the user&#39;s account does not permit the data object&#39;s size, then the client-side software may notify the user of the error at block  1265 , before returning. 
     At block  1220 , the client or server software may also check to see if the user&#39;s permissions permit placement of a copy on the server system, generating an error notice if not. If the permissions are in order, then at block  1225 , the client program may push the data object&#39;s metadata to the server and cause the server to update the bucket&#39;s metadata to reflect the data object&#39;s addition at block  1230 . 
     In some embodiments, rather than uploading raw data object data to the server, the raw data may be divided into “chunks” to facilitate management operations, security operations, and to provide storage efficiency via de-duplication. In this manner, e.g., if multiple data objects share similar sequences of byes, the storage may be compressed such that only one copy of that sequence need reside on the server or client. Accordingly, at block  1235 , the system may determine chunks in the data object (e.g., separating the data object into sequence of bytes within a sliding window or searching the data object for matches with previously identified chunks). The client system may compute hashes for the chunks at block  1240  (e.g., performing an MD5 hash). These hashes may then be used to determine if preexisting copies of these chunks already reside on the server at block  1245 . For those chunks which are absent from the server, the server may create a copy at block  1250 . 
     The server may then update its records to reflect the addition of the copy object in its memory. For example, at block  1255 , the server-side system may update the reference count for chunks (both preexisting and newly created at block  1250 ) associated with the data object. Peer devices monitoring the bucket may then be updated at block  1260 , receiving a copy of the data object, either by transmitting chunks for local assembly, or transmitting the whole data object, for the peer system&#39;s local use. 
     Example Memory Management—Memory Threshold 
     In various embodiments, the client or server systems may enforce constraints on item storage in quick-access memory (e.g., a local computer&#39;s RAM memory) as opposed to slower, long-term storage (e.g., on a local computer&#39;s disk memory, an external hard drive, or on a server memory).  FIG. 13  is a flow diagram illustrating various operations in an example memory management threshold determination process  1300  as may be implemented in some embodiments, e.g., at memory management module  210   f . At block  1305 , the system may determine the local device&#39;s total quick-access memory (e.g., RAM) capacity. At block  1310 , the system may determine a threshold T, indicating the maximum allowable usage of quick-access memory by the bucket-management programs (this threshold may be imposed for all buckets, or for items in only a single bucket, in different embodiments) as the product of the total available local quick-access memory R and an proportional factor A. In some embodiment&#39;s, A may be set by the user, determined by the system based on local workspace program requirements, or inferred over time. Some values of A may be selected based on R and empirically determined ratios. Thus, for example, with a proportional factor A of 10% and 2 GB of RAM, the threshold T may be 200 Megabytes. 
     At block  1315 , the system may determine U, the amount of quick-access memory used by the client bucket management program alone, absent the bucket data. At block  1320 , U may be scaled by a factor m to anticipate bucket items to create a final memory footprint S. In some embodiments, m may be set to 2 at all times, as this number has provided viable performance results during experimentation under different workspace environments. However, in some embodiments, m may be determined based upon the quick-access memory usage of other presently running programs on the client device or user preferences (e.g., computationally intensive graphics programs). Accordingly, U may vary over time in some embodiments. In some embodiments, m is required to be greater than one. 
     At block  1325 , the system may determine if S is greater than T, and if so, set T to S at block  1330 . The threshold T may then be used at block  1335  to determine how many items to remove from quick-access memory. For example, block  1335  may be the process  1400  described in greater detail below. 
     Example Memory Management—Deletion Prioritization 
       FIG. 14  is a flow diagram illustrating various operations in an example threshold-based memory reallocation process  1400  as may be implemented in some embodiments. The process may be used prevent the client program from using too much RAM so as to remain respectful of a system&#39;s resources (e.g., to accommodate usage of other workspace programs). This may be done by clearing from RAM memory low-priority data items and restoring them back into RAM when the user needs them. 
     Process  1400  may be run as a background process in some embodiments, performing operations as buckets change and T takes on new values. For example, the process may be run when items are added (pasted, drag-and-dropped, etc.) into a bucket. At block  1405 , the system may create a new empty list L and may add all the items from all the buckets into L at block  1410 . One will appreciate that L may simply be a logical structure and that the items need not be physically “moved.” At block  1415 , the system may additionally add all the deleted items into the list L. Accordingly, after block  1415 , all of the user&#39;s data items, including recently deleted ones, may be in one large list data structure called L. 
     At block  1420 , the system may sort L by size, e.g., placing the largest items first. Though sorting by size is depicted in this example, there are several factors that may be used to sort the items, including: the last used timestamp (e.g., when the item was created, copied, deleted &amp; restored, moved, or touched in any way); bucket association(s) (e.g., items associated with buckets not currently being or recently used by the user, may be more likely to be cleared); position within bucket (e.g., items lower in the stack may be more likely to be cleared); and items associated with a deleted flag (e.g., items in a temporary list of deleted items, which is used when in “Undo” operations are performed). Note that as items are copied, pasted, deleted, restored, re-ordered, etc., their “last used” timestamp may be updated to the current time. 
     For so long as the bucket management program&#39;s quick access memory usage exceeds T at block  1425 , the system may remove the topmost element from the list (the element least favored per the above criteria) at block  1430  and determine if it has been cleared at block  1435 . If the item has already been cleared, the next element may be removed from the list L at block  1430  either until no items remain in the list, or an uncleared item has been found. Uncleared items may be removed from quick access memory at block  1440  and their corresponding cleared flag updated at block  1445 . To reiterate for clarity, clearing items from RAM results in their being stored elsewhere (local computer disk memory, server memory, etc.) and the in-GUI preview will continue to depict the item within its bucket. 
     Example Multiple Item Paste Handling 
       FIG. 15  is a flow diagram illustrating various operations in an example paste-from-bucket process as may be implemented in some embodiments. These operations may be performed when the user copies or cuts data from a bucket and moves it to an operating system program. At block  1505 , the user may indicate their intention to copy or cut an item from a bucket. For example, the user may click and drag the item in the GUI, the user may press keyboard controls, such as “Control” and “C” to copy after selection the item or “Control” and “X” to cut after selecting the item, etc. 
     At block  1510 , the client software may determine whether to use a local copy of the item data to perform the requested operation, or to retrieve data from the server at block  1515 . For example, if the data is not available locally, the client software system may need to warn the user that the operation cannot be performed until the server is available. Conversely, if the data is available locally and a network connection with the server is unavailable, the client may use a local copy of the item&#39;s data to perform a copy operation. If the server is unavailable and a cut operation is performed, the client software may note the update and notify the server once the connection is reestablished. It may not be necessary, e.g., to notify server of successful copy operations. However, as successful cut operations change the contents of the bucket, the client software may notify the server. The server system may communicate such updates to other shared or mirrored buckets as discussed in greater detail herein. 
     In some embodiments permitting selection of multiple items in the client GUI, at block  1520 , the system may determine if the multiple icons require context handling, e.g., where disparate types of items are selected for placement on the native operating system clipboard. If such a multiple selection has been made, then at block  1525  the system may merge and prepare the items for clipboard placement, e.g., using the process discussed herein with respect to  FIG. 16  (one will appreciate that portions of  FIG. 16  may include operations in block  1530 ). 
     At block  1530 , the client software may proceed to move the data to the native operating system clipboard. From here, the user may paste the clipboard data into their native program of choice (e.g., a text editor, image editing program, etc.). In some embodiments, dropping the icon into a program may precipitate a direct introduction from the native clipboard memory into that program. At block  1535 , the client software may notify the server of the operation. Such notification may be important where a cut was successfully performed, so that the server may update the bucket stack. In some embodiments, such notification may occur simultaneously with the data retrieval at block  1515 . Successful or failed copy operations may also be communicated to the server, e.g., so that the server may anticipate future caching priorities. The server may, e.g., direct the client software to more prioritize the caching of frequently copied items locally over less frequently copied items. A cache may also be implemented at the server system  150  to avoid database lookups for frequently requested data. In some embodiments, rather than hold all the data in RAM, the system may push data to disk, or reload data into RAM on-demand as needed. In some embodiments, the client software may offload rarely referenced data to the server system  150  when the server system  150  is available. 
     At block  1540 , the client software may refresh the GUI. This may not be necessary for a copy operation, but may be performed following the cut operation to reflect the change in item placement within the bucket stack. 
     Example Multiple Item Paste Merge Handling 
       FIG. 16  is a flow diagram illustrating an example multi-item paste process  1600  as may be implemented in some embodiments. On the macOS™ operating system, the local clipboard may have separate fields for audio, image, and text data and may permit multiple items of the same type to be placed on the clipboard. Windows™ may permit placement of only a single item of each type on the clipboard. Thus, multi-item pastes may need to consider the particular operating system&#39;s clipboard structure. 
     At block  1605 , a variety of temporary field values associated with the native operating system&#39;s clipboard may be cleared, including a plaintext string, rich text string, and file list. Until all the items selected by the user for pasting are considered at block  1610 , the system may consider the next unconsidered item at  1615 . Based on the type of the item, the system may then adjust the temporary fields in anticipation of transfer to the native operating system clipboard. For example, if the current item is determined to be an image at block  1620  or an audio file at block  1630 , then the corresponding image or audio buffer, as well as the field flags may be set at blocks  1625  and  1635  respectively. The audio and image field flags may be used to ensure that the first encountered item of the image and audio types is placed in the buffer and not overwritten by a subsequent item. This may accommodate user expectations that the first such selected item will be transferred to the clipboard, though one will appreciate variations based on other expectations. 
     In contrast to the limited audio and image buffers, if a file item, plaintext item or rich text item is encountered at blocks  1640 ,  1650 , or  1660 , respectively, then they may be appended to any preexisting values in the corresponding temporary fields at blocks  1645 ,  1655 , and  1665 , respectively. Once all the items are considered at block  1610 , at block  1670 , the system may set the native operating system&#39;s clipboard file list to the temporary file list. Similarly, at block  1675 , the system may set the native operating system clipboard plaintext field the contents of the plaintext buffer and at block  1680 , the system may set the native operating system&#39;s clipboard rich text field to the contents of the rich text buffer. 
     Thus, if the user selected several items in a bucket (some text, rich text, and images), then dragged and dropped them into a word processing program, the word processing program may consult the native operating system&#39;s clipboard fields to insert them appropriately into the document. 
     On some native operating systems, e.g., Windows™, the native operating system clipboard may only contain one item of each type. For example, the system may place some text, a bitmap image, and some audio on the native clipboard, but you cannot have two text entries, or two bitmap images, or two audio items. Accordingly, some embodiments may merge items of the same type into a single, larger item to be placed on the native clipboard field (e.g., concatenating strings and images). In other embodiments, only the first item may be placed in the native clipboard field. 
     In some embodiments, rich and plaintext items may both be concatenated together so as to accord with user expectations. There is also another type of items that can be placed on the clipboard in Windows, called a “file drop list” including a list of strings representing file paths in the file system. Like text strings, these may also be concatenated. 
     Similarly, if multiple file/directory items are selected, some embodiments combine all of the items into a file drop list and place that file drop list onto the native clipboard. The receiving applications can then access all of the files/directories at once. 
     In some operating systems, when selecting a file in the native operating system and “Copying” it to the clipboard, the operating system copies only the path of the file (and similarly for a folder, only the path to the folder) is copied to the clipboard (not its content). Upon paste, it is then the responsibility of the receiving program to look at the path in the clipboard and go read/copy data at that path. In this case, the client software system, when pasting a file, may look at the path in the clipboard and copy the entire file locally to a hidden data folder. This raw data and the accompanying determined metadata may then be sent to the server (or simply the raw data sent and the metadata determined at the server). 
     Example Item Removal Handling 
       FIG. 17  is a flow diagram illustrating various operations in an example item deletion process  1700  as may be implemented in some embodiments. At block  1705 , the user may indicate a desire to remove an item from a bucket, e.g., by clicking on the removal indicia, e.g. indicia  360 , associated with an item&#39;s icon. Removal may also be performed through a program menu, context menu, button, keyboard shortcut, drag-and-drop, toolbar button, etc. Removal may also occur, e.g., as discussed with respect to  FIG. 15 , during a cut operation. 
     At block  1710 , if the server is available, the client software may notify the server of the removal so that the server may update the bucket and its representation on relevant peer devices, as well as its internal records. At block  1715 , the client and server systems may remove the item data (both raw data and metadata) from the bucket&#39;s stack. In some embodiments, where network connectivity between the client software and server is available, then block  1715  may reflect only the server-side modification of the data which will in turn drive the GUI revisualizations at block  1720 . Conversely, where connectivity is not available, the client software may update its local, cached, bucket data to initiate the item removal at block  1715  and update the GUI at block  1720 , in accordance with the modified local data, at its own initiative. Once connectivity is reestablished, the client software may then notify the server of the removal operation. The server system may then indicate the removal operation in the stack representation of each peer device synchronized with the item&#39;s bucket. 
     As discussed above with respect to  FIG. 10 , some embodiments facilitate the ability to “undo” a removal operation. When performed, the item may be restored back into the bucket at its former location (accounting for any subsequent modifications to the bucket). Such item revivals may be propagated to other user devices in a fashion analogous to the insertion of new items describe elsewhere herein. 
     As items are added and removed from a bucket, the overall size of the bucket may be recomputed on the client side for the purpose of displaying that information to the user (e.g., at memory footprint indicia  330 ) and on the backend for the purposes of tracking storage and transfer quotas. The overall account size is computed as the sum of the size of the buckets that belong to a user. The overall account size may also be updated as buckets are created/deleted. 
     In some embodiments, the user may also activate a “Redo” action (either through a program menu, context menu, button, keyboard shortcut, or toolbar button) and the item once again deleted. The action may be propagated to all of the user&#39;s devices running the application. 
     Example Data Object Removal Using Chunks 
     As previously discussed, some embodiments may use chunks to economize memory spaces on the server.  FIG. 18  is a flow diagram illustrating various operations in an example item deletion process  1800  using data chunks as may be implemented in some embodiments. At block  1805 , the user may indicate a desire to remove an item from the bucket. For example, the user may perform a keyboard command or drag and drop command that directs the bucket management program to remove a data object from the currently selected bucket. 
     At block  1810 , the client system may consult with an account server, the metadata server  130  (e.g., account management module  215   b  and sharing/permissions module  215   e ), or internal records to determine if the user&#39;s account permits removal operations. For example, the user may be able to view a shared bucket, but not modify the bucket unless they are the owner. Where the user lacks appropriate permissions, the client program may notify the user at block  1815 . 
     Where permissions are satisfactory, at block  1820 , the client system may direct the server system to indicate that the data object in the bucket has been deleted. The raw data object data and data object metadata may be retained however until a subsequent purge. For example, setting the “deleted flag” to true, or otherwise indicating that the data object has been removed, may initiate a timer for a delayed purging. Only after adequate time has passed may the data be genuinely updated to reflect removal. In this manner, “undo” and recovery operations may be permitted to the user for a period following the removal request (e.g., following an undo request, the timer may be disabled and the client GUIs&#39; bucket icon stacks updated to again depict the recovered item or items). 
     At block  1825 , the client and server may adjust the bucket&#39;s internal ordering to reflect the omission of the data object. At block  1830 , the GUI representation on the client device may be adjusted to reflect the removal and a new item ordering presented within the bucket window. 
     As mentioned with respect to block  1820 , marking a data object for deletion may result in delayed expunging operations.  FIG. 19  is a flow diagram illustrating various operations in an example data expunging operation  1900  in association with the operations of  FIG. 18  as may be implemented in some embodiments. For example, once the timer expires following marking of the deletion flag, the purging process may begin. At block  1905 , the server system may decrease the server-side reference count for each chunk associated with the item marked for deletion. For each chunk associated with the data item, at block  1910 , the system may determine if this results in the chunk&#39;s reference count being zero, and if so, removes the chunk from the server memory at block  1915 . Any data object for which at least one data chunk is missing may be construed as “permanently deleted” in the system. As in this example, some embodiments may favor storing data object raw data and metadata on the server rather than on the client. 
     Example Bucket Correspondence Topology 
       FIG. 20  is a schematic diagram illustrating an example topology of various bucket relations as may occur in some embodiments. As previously discussed user  120   a  may be working with two devices, desktop computer  125   a  and a laptop computer  125   b , at location  115   a . Each of desktop computer  125   a  and a laptop computer  125   b  may be running a client software instance, e.g., client software instance  2010   a  on device  125   a  and client software instance  2010   b  on device  125   b.    
     The user may desire the instances  2010   a  and  2010   b  to “mirror” one another. Thus, buckets and data on instance  2010   a  may also be represented in instance  2010   b  and vice versa. Similarly, operations performed on a bucket and its contents via instance  2010   a  will also occur in instance  2010   b  and vice versa. The data for each instance may be synchronized and consolidated at the server system via network  2005  (e.g., the Internet, a local area network, etc.). Thus, the instances  2010   a  and  2010   b  may agree on their buckets and contents via the complete mirroring, however, each instance may have its copy of the data corresponding to the icon depicted in the respective GUI in some embodiments. 
     Thus, items  2020   a ,  2020   b  in bucket  2015   a  on instance  2010   a  may correspond to items  2020   e ,  2020   f  in bucket depiction  2015   d  on instance  2010   b . Similarly, items  2020   c ,  2020   d  in bucket depiction  2015   b  on instance  2010   a  may correspond to items  2020   g ,  2020   h  in bucket depiction  2015   e  on instance  2010   b . Again, the appearance of these items may be the same in each bucket (e.g., they will each have corresponding item icons in the same stack position). Such mirroring may occur for all or some of the remaining buckets until buckets  2015   c  and  2015   f , per the user&#39;s preference. Again, this mirroring may occur via reference to the server system  150  across network  2005  and in some embodiments may be managed by, and use data objects stored on, the server system exclusively. Also note that the mirroring may occur despite desktop computer  125   a  and a laptop computer  125   b  running different operating systems. 
     Instances may also be mirrored between the different devices of different users as described above. However, in some embodiments, only specific buckets may be mirrored between different users. Unlike “local” buckets, which are local to a user and not shared, these “shared” buckets are mirrored between peers. Thus, on the instance  2010   c  on device  125   d  bucket depictions  2015   h  and  2015   i  may have items  2020   k - n  not appearing in other users&#39; buckets. Thus, modification of these buckets will precipitate no change anywhere else. However, the shared bucket represented by bucket depiction  2015   g  may be mirrored with each of the contents of the buckets represented by depictions  2015   b  and  2015   e . Consequently, removal of either item  2020   i  or  2020   j  would result in corresponding removal of items  2020   c ,  2020   d  and  2020   g ,  2020   h  in their respective buckets. 
     Note that the sequential ordering may be consistent across devices. Thus, if another team member inserts an item, her peers may have some idea of when it was inserted relative to their own. In some embodiments, users may set permissions to add, insert, reorder, and delete items in a container to avoid data loss or confusion. In some embodiments, users may reorder items in a bucket or may assign the stack locations based on factors other than chronological insertion (e.g., data size, type, etc.). 
     Example Item-Specific Bucket Transfer 
     Rather than mirror and synchronize entire buckets as discussed with respect to  FIG. 20 , in some embodiments, the client or server systems may accommodate the transfer of individual items to a peer client system via a “share-between-users” operation.  FIG. 21  is a schematic diagram illustrating an example client user screen during a portion of a share-between-users process as may occur in some embodiments. In this example, a first user with display view  2115   a  depicting a first client instance GUI  305  may wish to send an item to a second user with display view  2115   b  on a separate device depicting a second client instance GUI  2110 . The first GUI select the “Default” bucket via selection  2120   a , while the second GUI  2110  focuses on the “Received” bucket selection  2120   b . While the second GUI  2110 &#39;s stack window  2125  is empty for the bucket in this example, one will appreciate that the bucket may have previously received items. The “Received” bucket may be a bucket included in the initial client installation in some embodiments. 
     The first user may activate the “Send to friend” action (e.g., through a program menu, context menu, button, keyboard shortcut, or toolbar button) and a list of the user&#39;s friends may be displayed. For example, here the user has right-clicked on the second item icon  710  to present menu  2105  from which the user has selected the option “Send to Friend.” 
       FIG. 22  is a schematic diagram illustrating an example client user screen during a peer-selection portion of the share-between-users process of  FIG. 21  as may occur in some embodiments. Menu  2105  may close and window  2205  be presented when the user selects “Send to Friend.” The window  2205  may include a search box  2205   a  for searching, e.g., for peer user names. A region  2205   b  may show the available peer users (in this example only two are available, though one will appreciate that an arbitrary number may be available in difference instances). The user may select one or more peers for transmission by selecting the icons in region  2205   b . Region  2205   c  then provides buttons for sending the item to the selected users. In some embodiments, the contacts/sharing module  210   i  may consult the user&#39;s address book to identify friends. 
       FIG. 23  is a schematic diagram illustrating an example client user screen during a completed peer-selection portion of the share-between-users process of  FIG. 21  as may occur in some embodiments. Window  2205  may close once the first user clicks “send.” The second user may then be presented with a notification widow  2310  and updated stack window  2125  including an icon  2305  for the newly received item. Memory indication  2315  may likewise be updated to reflect the memory footprint created by the newly received item. In this manner, unlike mirrored buckets, only specific items may be transferred between client software instances (though other buckets may permit mirroring functionality). 
     To facilitate understanding of the benefits of the various bucket topologies, consider the example situation where the users are writing software code on computers in text editors or integrated development environments (IDE). One user may wish to send a portion of the code (e.g. a line, block, or several blocks of code) to his colleague. The user copies the code and pastes it into a bucket. The user then uses the aforementioned “Send to friend” feature. On the other end, the colleague receives the code, copies it and pastes it where needed. 
     In some embodiments, when the user selects “Share with friend” and then chooses friend(s) from the list of contacts, they may also choose privileges (such as “can view”, “can edit”, “can edit and share”). The icon in the recipient&#39;s GUI may reflect the privileges, e.g., with a textual indication. In some embodiments, entire buckets, rather than just items, may be shared using this “send to friend” functionality. Note that, in some embodiments, individual item sharing (e.g., via “share with friend”) may not consider different levels of privileges. In some embodiments, even if the sender deletes his item, the recipient will retain hers within her “Received” bucket as the items are not treated as the “same” item by the server (e.g., as in mirrored buckets). This variation in bucket functionality may accommodate user workflow behaviors, accommodating certain expectations regarding item retention. Bucket sharing may be specified via the “Manage Buckets” window  2605   a  in some embodiments. 
       FIG. 24  is a flow diagram illustrating various operations in an example share-between-users process  2400  as may be implemented in some embodiments. At block  2405 , the user may indicate a desire to share an item (e.g., by selecting the “Send to Friend” option discussed above). At block  2410 , the client or server system may then determine the user&#39;s contact list and present this list via the GUI interface to the user at block  2415 . The user may then indicate one or more contacts to receive the item at block  2420 . At block  2425 , the client software may notify the server of the intention to share the item, the recipient contacts, and the selected item. 
     At block  2430 , the server system may update the one or more recipients&#39; bucket data to reflect the newly received item. In some embodiments, this may precipitate a new item entry in the metadata database  140   a . The system may then update the reference counts of every chunk of the item (e.g., reference counts are incremented by 1 for every user that we share with). Thus, the item may not be shared but duplicated (once per recipient). In this manner, if the sender deletes his item, the recipients will still retain theirs. 
     At block  2435 , the server may direct the recipient&#39;s GUI to notify the recipient of the new item&#39;s arrival. Similarly, at block  2440 , the server may direct the sender&#39;s client software to notify the sender via the client&#39;s GUI of the operation&#39;s success. 
       FIG. 25  is a flow diagram illustrating various operations in an example share-between-users process  2500  using data chunks as may be implemented in some embodiments. At block  2505 , the user may indicate a desire to share an item with a peer (e.g., as discussed above) and select one or more peers at block  2510 . In some embodiments, at block  2515 , the client software may verify with a server system that the recipient&#39;s permissions permit receipt of an item of the shared object&#39;s size. For example, higher tiered users may have the ability to share larger items. Conversely, in some embodiments, it may be the sender who is prevented from sending items over a specified size (indeed, both sender and receiver may sometimes require adequate permissions). If the transmission is not permitted, the user requesting to send the object(s) may be notified at block  2550 . 
     Where adequate permissions exist, at block  2520 , the server system may generate a copy of the object&#39;s metadata. The server may also update the metadata associated with the recipient&#39;s bucket at block  2525  (e.g., a “received” data bucket as discussed elsewhere herein). Similarly, at block  2530 , the server system may update the reference counts for the chunks associated with this item (reflecting the additional presence of the item in the recipient&#39;s bucket). 
     At block  2535 , the recipients may be notified, e.g., with a loading indication, that the server will be sending the data object to their system. The data object may be assembled at the server in some embodiments from the chunks, or the chunks may be sent to the client for assembly in some embodiments. In this example, the assembly may occur locally at block  2540 , before an icon corresponding to the final assembled data object is presented to the recipient at block  2545 . 
     Example Operations—Bucket Management 
       FIG. 26A  is a schematic diagram of a client graphical user interface including a bucket selection interface as may be implemented in some embodiments.  FIG. 26B  is a schematic diagram of a bucket management selection window as may be implemented in some embodiments;  FIG. 26C  is a schematic diagram of a bucket deletion confirmation window as may be implemented in some embodiments;  FIG. 26D  is a schematic diagram of a bucket creation confirmation window as may be implemented in some embodiments; and  FIG. 26E  is a schematic diagram of the bucket management window of  FIG. 26B  following various creation and editing operations as may occur in some embodiments. 
     When the user clicks upon or otherwise selects bucket selection interface  315 , as shown in  FIG. 26A , the system may present a dropdown list  2620  indicating the available buckets from which the user may select. When a user clicks a bucket name, the list in the below bucket window may be updated to show the content of the selected bucket. An additional “manage buckets” option may also presented as indicated in dropdown list  2620 . By selecting this option, the system may present a bucket management window  2605   a  as shown in  FIG. 26B  to the user. This window may include a plurality of bucket summary entries in summary region  2610 . 
     Clicking the “plus” sign  2615   a  may begin the creation of a new bucket, while selecting the minus sign  2615   b  after selecting a bucket in region  2610  may begin removal of the bucket. Particularly, following selection of the “minus” sign  2615   b  the system may present the dialog  2605   b  to confirm removal. If the user selects “ok” in this dialog, the bucket may be removed and any associated client or server-side memory marked for reallocation. While the text  2605   b  indicates “WARNING: you cannot undo this action,” in some embodiments, as discussed above with respect to data objects, bucket data may likewise be retained for a period of time before being permanently expunged, to facilitate undo behaviors. 
     Conversely, selection of the “plus” sign  2615   a  will cause the system to present dialog  2605   c  of  FIG. 26D . Here the user may type in the name of the new bucket in text input  2625 . After selecting “ok” in this dialog, a new entry for the new bucket (here “Test bucket”) may be presented in the summary region  2610  as shown in  FIG. 26E . The initial memory associated with this bucket may be “Zero KB.” Note that when this is a “mirrored” or “shared” bucket, a new bucket with the same name may now appear on peer user&#39;s client interfaces. By clicking on a bucket&#39;s name in the summary region  2610  the user may change a bucket&#39;s name. For example, in  FIG. 26E  the user is removing the last two characters of the bucket that was named “Second.” As discussed herein, changing a bucket name for a “mirrored” or “shared” bucket may precipitate a change in the name on peer client interfaces as well. The name may also be changed in the bucket selection interface  315 . Users may reorder buckets by dragging them up or down in the summary region  2610 . In some embodiments, analogous to the order of a bucket&#39;s contents, the order of the buckets may be propagated to all of the user&#39;s devices. The order may also be reflected in the bucket selection interface  315 . 
     In some embodiments the system begins with two buckets: a “Default” bucket, which may be used by default for initial copying and pasting, and a “Received” bucket, for receiving items from peers as described elsewhere herein. Users may create “custom” containers in addition to these two initial buckets. 
       FIG. 27  is a flow diagram illustrating various operations in bucket creation process  2700  as may be implemented in some embodiments. At block  2705 , the user may indicate a desire to create a new bucket, e.g., by selecting the “plus” indicia  2615   a  of the dialog in  FIG. 26B . The GUI may present inputs for receiving information about the new bucket, e.g., the name input in the dialog of  FIG. 26D , at block  2710 . 
     At block  2715 , the client software may convey the bucket creation request to the server. Though not shown in this example, where the server is not available, the client software may perform the bucket operation using a local copy of the bucket. Once the server system is again available, the client software may push the bucket and its data to the server system for processing. 
     At block  2720 , the sever may decide whether creation of the bucket is possible. For example, there may not be adequate space or resources for additional buckets or the user&#39;s account may be limited to a finite number of buckets. If such resources are absent, the server may direct the client software to notify the user of the failure at block  2725 . If instead, the resources are available, then at block  2730 , the server system may instead allocate resources for the bucket and include the bucket for consideration in subsequent updates (e.g., if the bucket is designated for sharing with peers). The server system may then notify the client software of the user requesting the bucket creation, as well as the client software of other subscribing/shared users, of the successful bucket creation at block  2735 . The users may be informed, e.g., via an update to bucket management window  2605   a.    
     Example Operations—Quick Cut and Quick Copy Actions 
       FIGS. 28A-D  are schematic diagrams of various graphical user interfaces that may be presented to the user during a quick-copy or a quick-cut process as may be implemented in some embodiments. Users familiar with the client software may wish to rapidly move data to and from the the clipboard during their workflow. To accommodate this desire for speed, the client software may accommodate “quick” operations in some embodiments, including “quick copy” and “quick cut” operations. A quick copy operation may quickly facilitate the transfer of items from the bucket to a data program, without removing the items from the bucket. In contrast, a quick cut operation may move items from the bucket to the clipboard and remove them from the bucket. 
     In some embodiments the user may employ a keyboard command (e.g., the control key pressed simultaneously with an alphanumeric key) to begin the quick copy and quick cut operations. When the user begins the quick copy operation, the client software system may present a dialog  2805   a , including a range input  2820 . Here, as there are 29 items in the bucket, the initial indication in the input  2820  is 1-29. The user may type a single number for a single item or use a dash to indicate a range of items. For example, in  FIG. 28C , the user has identified only the item with numerical identifier “2” (the PNG image of a flower corresponding to icon  2810 ) for transfer. Hitting “ok” or pressing “enter” may then cause the item&#39;s data to be copied to the operating system&#39;s clipboard. The quick cut operation may proceed in a similar manner, but instead showing dialog  2805   b  with range input  2830  as well as causing the system to remove the item from the bucket. 
     In some embodiments the client system may validate the input and present an error notification if the input is invalid. For example, the requested copy range may exceed the items in the bucket. Because these operations may be performed by keyboard, they allow users to use keyboard shortcuts to interact with the bucket. In this manner, the user may not have to take their hands off the keyboard to select and copy an item to the local operating system&#39;s clipboard. Keyboard exclusive interaction may better align with the user&#39;s rapid workflow. 
       FIG. 29  is a flow diagram illustrating various operations in a quick-copy or quick-cut process  2900  as may be implemented in some embodiments. At block  2905 , the user may indicate a desire to perform a quick-copy or quick-cut operation. In response, at block  2910 , the system may present an input window to user. For example, the window may include a range input  2820  corresponding the range of items in the bucket stack to perform the operation. 
     At block  2915 , the user may input the desired items, e.g., the item range, into the client software system. At block  2920 , the client or server system software may determine whether the selected items require context handling. For example, a single item may be copied to the native operating system clipboard at block  2925 . A single item may behave as expected when pasted by the user to an application running on the operating system. Similarly, some items in combination may be merged and behave as expected when pasted by the user. For example, several text items may be merged into a single set of text data and placed on the operating system clipboard. In contrast, a combination of disparate items may require contextual considerations. Accordingly, at block  2930  the system may coordinate clipboard placement based on the types of selected items. As mentioned, such merging may be performed during normal paste operations and not simply those following quick-cut/copy.  FIG. 16  is an example process handling such placement, which may also be used here. 
     Example Operations—Item Search 
       FIG. 30  is a schematic diagram illustrating various states of a graphical user interface that may be presented to the user during a search operation as may be implemented in some embodiments. In some embodiments, a search input  3010  may take the place of bucket selection interface  315  (as shown) or be placed in the GUI in addition to bucket selection interface  315  when the user begins a search (via, e.g., a keyboard command, selection from an element within general toolbar  360 , a search icon appended to action selection toolbar  310 , etc.). As the user types characters into search input  3010 , the client system may iterate over the metadata of each item in the bucket (as the metadata resides on the client or server system) and determine whether to hide or show the item in stack window  3015  of GUI  3005 . For example, during file search  3000   a , the user has typed the word “files” into search input  3010 . The client system may consult with the server system, or a local index, which in turn consults the metadata associated with the bucket items in the data store to determine which items correspond to this input. The system may include “keywords” such as “image,” “file,” “text,” etc. that precipitate specific filtering of metadata. The search inputs may be compared with these keywords and items retained whose data type metadata correspond to the keyword. In file search  3000   a , images, PDF files, directories containing files, etc. are retained while, e.g., textual values and spreadsheet values are removed from view in item stack window  3015 . In some embodiments, file search may return files and directories but not discrete pieces of data such as image or text snippets. Consequently, the rich text snippet and PNG image of file search  3000   a  may not appear in the search for “files” of these embodiments. Rather than PNG image data, only entire PNG files would be retained. 
     The system may also filter items based on the input by layering terms. For example, in TIFF Image search  3000   b  the user has input both the keyword “image” and the format specifier “tiff.” The system may first filter based on the keyword (removing all non-image items). For the items that remain, the system may then apply a second filter based on the format specifier (e.g., removing all JPEG, PNG, and other non-TIFF images). 
     When the search input does not match a keyword, the system may retain items having any metadata value corresponding to the input. For example, the input “hello” in text search  3000   c  is not a keyword and does not correspond to a type of item. However, the raw content of some items (itself construed as metadata for search purposes associated with the item) may correspond to the input. In this case, a text item has raw data matching the input. Thus, while all other items in the bucket are hidden, the “Hello World!” text item remains. 
     Note that the numerical identifiers for the items may be adjusted as items are removed from view. In some embodiments, the change in the item stack window  3015  may be local to the user performing the search, regardless of whether the bucket is local, mirrored, or shared. In some embodiments, however, the filter results and the search input are replicated for peers to see. 
       FIG. 31  is a flow diagram illustrating various operations in an example search process  3100  as may be implemented in some embodiments. Once the user first initiates a search, at block  3105 , the system may initially mark all the items in the selected bucket as “visible.” As the user inputs search parameters (e.g., a new character in the search input) the parameters may be included in the search at block  3110 . Note that in some embodiments the search parameters need not be textual characters, but may be, e.g., file size ranges, file size limits, item creation dates, etc. 
     At block  3115 , the system may iterate through the visible items in the selected bucket and consider any unconsidered items at block  3120 . At block  3125 , the client or server system may then iterate through the current search parameters, considering the next parameter at block  3130 . If the server of client determine that the considered item&#39;s metadata (including, in some embodiments, its raw data) satisfies the parameter (e.g., at least one metadata property associate with the item agrees with the search parameter) at block  3135 , then the item may be retained as visible at block  3145  (e.g., it&#39;s metadata may continue to include a positive visibility flag). Otherwise, if the search parameter has not been satisfied, then the item may be marked as hidden at block  3140 . 
     When an item is added to a bucket, the server system  150  may store its raw data and metadata including, e.g., the item&#39;s type, size, associated operating system programs, insertion time, etc. This raw data or metadata may then be referenced during the search query. Thus, for example, if the parameters are a succession of characters in a word (“fold” in the word “folder”), then an item&#39;s metadata will satisfy the parameters if it contains the entire word (“folder”). Similarly, if the parameters included two words (“TIFF images”), the metadata considered here may satisfy the parameters if it contains either of the two words (“TIFF” or “images,” though both words will need to appear in at least one metadata parameter for the item to remain visible). 
     Once all the visible items have been considered at block  3115  and all the items properly identified as visible or hidden, the system may proceed to block  3150  and present the updated item window stack to the user. If the client system receives a new, additional search parameter at block  3155 , the items may be further filtered by seeing if their metadata agrees with all of the new search criteria. Again, in some embodiments, the raw item data may also be searched (e.g., the user may search for words within text/rich text data items). 
     Example Multi-Client Window Operations 
       FIG. 32  is a schematic diagram illustrating various states of a graphical user interface that may be presented to the user during window creation, bucket selection, and online status operations as may be implemented in some embodiments. Initially, in state  3200   a , the client software may display only a single GUI window  3210   a  on the user&#39;s screen. By, e.g., selecting “New Window” in the dialog  3205  of the “File” selector, the user may create a second GUI window  3210   b . An arbitrary number of windows may be generated in this manner in some embodiments. 
     Each window may serve as a separate instance for modifying buckets. For example, as shown in state  3200   b , the user has used selector  3215   b  to view items in the “Second” bucket, while the first window  3210   a &#39;s selector  3215   a  remains focused on the “Default” bucket. Note that the size indicia  3225   b  has changed in the second window  3210   b  in accordance with the contents of the “Second” bucket, in contrast with the size indicia  3225   a  of the window  3210   a , which remains associated with the “Default” bucket. Similarly, by clicking on the network indicia  3220  of the second window  3210   b , the user may disconnect window  3210   b &#39;s network connection with the server system  150 , while retaining the window  3210   a &#39;s connection. In some embodiments, in contrast, only a single network connection may be available to all the windows. 
     Multiple windows may facilitate convenient data organization for the user. For example, when designing a video game, a user may wish to have simultaneous access to a software code bucket, a sound asset bucket, and a graphical asset bucket. If a peer sound engineer is providing new software assets in real-time, however, the user may wish to have direct access to the shared bucket via a new window. In contrast, the user may wish to save code snippets for their own use, which are not yet intended to be shared with his peers. Consequently, a separate window and bucket dedicated to code snippets may be created and taken offline to prevent synchronization. 
     In some embodiments the user&#39;s windows configurations are saved at the end of each client software session and recreated at the beginning of the next session. This may streamline the user&#39;s workflow and facilitate productivity. 
     Example Feature Augmentations for Some Embodiments—Preview for Mobile Device 
     Some embodiments, rather than providing a full client user interface  305  in a mobile device, such as mobile device  125   c , may instead receive a client program with modified functionality. For example, rather than all the buckets and corresponding items being synchronized, “previews” may be displayed. In some embodiments, only when the user requests to copy an item will the item&#39;s full data be downloaded from the server. This limited functionality may be provided to avoid having to download all the data to the mobile device before it is needed. This functionality may likewise be applied to desktop and laptop devices in some embodiments. 
     Computer System 
       FIG. 33  is a block diagram of an example computer system as may be used in conjunction with some of the embodiments. The computing system  3300  may include an interconnect  3305 , connecting several components, such as, e.g., one or more processors  3310 , one or more memory components  3315 , one or more input/output systems  3320 , one or more storage systems  3325 , one or more network adaptors  3330 , etc. The interconnect  3305  may be, e.g., one or more bridges, traces, busses (e.g., an ISA, SCSI, PCI, I2C, Firewire bus, etc.), wires, adapters, or controllers. 
     The one or more processors  3310  may include, e.g., an Intel™ processor chip, a math coprocessor, a graphics processor, etc. The one or more memory components  3315  may include, e.g., a volatile memory (RAM, SRAM, DRAM, etc.), a non-volatile memory (EPROM, ROM, Flash memory, etc.), or similar devices. The one or more input/output devices  3320  may include, e.g., display devices, keyboards, pointing devices, touchscreen devices, etc. The one or more storage devices  3325  may include, e.g., cloud based storages, removable USB storage, disk drives, etc. In some systems memory components  3315  and storage devices  3325  may be the same components. Network adapters  3330  may include, e.g., wired network interfaces, wireless interfaces, Bluetooth™ adapters, line-of-sight interfaces, etc. 
     One will recognize that only some of the components, alternative components, or additional components than those depicted in  FIG. 33  may be present in some embodiments. Similarly the components may be combined or serve dual-purposes in some systems. The components may be implemented using special-purpose hardwired circuitry such as, for example, one or more ASICs, PLDs, FPGAs, etc. Thus, some embodiments may be implemented in, for example, programmable circuitry (e.g., one or more microprocessors) programmed with software and/or firmware, or entirely in special-purpose hardwired (non-programmable) circuitry, or in a combination of such forms. 
     In some embodiments, data structures and message structures may be stored or transmitted via a data transmission medium, e.g., a signal on a communications link, via the network adapters  3330 . Transmission may occur across a variety of mediums, e.g., the Internet, a local area network, a wide area network, or a point-to-point dial-up connection, etc. Thus, “computer readable media” can include computer-readable storage media (e.g., “non-transitory” computer-readable media) and computer-readable transmission media. 
     The one or more memory components  3315  and one or more storage devices  3325  may be computer-readable storage media. In some embodiments, the one or more memory components  3315  or one or more storage devices  3325  may store instructions, which may perform or cause to be performed various of the operations discussed herein. In some embodiments, the instructions stored in memory  3315  can be implemented as software and/or firmware. These instructions may be used to perform operations on the one or more processors  3310  to carry out processes described herein. In some embodiments, such instructions may be provided to the one or more processors  3310  by downloading the instructions from another system, e.g., via network adapter  3330 . 
     REMARKS 
     The drawings and description herein are illustrative. Consequently, neither the description nor the drawings should be construed so as to limit the disclosure. For example, titles or subtitles have been provided simply for the reader&#39;s convenience and to facilitate understanding. Thus, the titles or subtitles should not be construed so as to limit the scope of the disclosure, e.g., by grouping features which were presented in a particular order or together simply to facilitate understanding. Unless otherwise defined herein, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. In the case of conflict, this document, including any definitions provided herein, will control. A recital of one or more synonyms herein does not exclude the use of other synonyms. The use of examples anywhere in this specification including examples of any term discussed herein is illustrative only and is not intended to further limit the scope and meaning of the disclosure or of any exemplified term. 
     Similarly, despite the particular presentation in the figures herein, one skilled in the art will appreciate that actual data structures used to store information may differ from what is shown. For example, the data structures may be organized in a different manner, may contain more or less information than shown, may be compressed and/or encrypted, etc. The drawings and disclosure may omit common or well-known details in order to avoid confusion. Similarly, the figures may depict a particular series of operations to facilitate understanding, which are simply exemplary of a wider class of such collection of operations. Accordingly, one will readily recognize that additional, alternative, or fewer operations may often be used to achieve the same purpose or effect depicted in some of the flow diagrams. For example, data may be encrypted, though not presented as such in the figures, items may be considered in different looping patterns (“for” loop, “while” loop, etc.), or sorted in a different manner, to achieve the same or similar effect, etc. 
     Reference herein to “an embodiment” or “one embodiment” means that at least one embodiment of the disclosure includes a particular feature, structure, or characteristic described in connection with the embodiment. Thus, the phrase “in one embodiment” in various places herein is not necessarily referring to the same embodiment in each of those various places. Separate or alternative embodiments may not be mutually exclusive of other embodiments. One will recognize that various modifications may be made without deviating from the scope of the embodiments.