U.S. patent application number 15/959138 was filed with the patent office on 2019-10-24 for systems and methods for efficient inter-device data exchange.
The applicant listed for this patent is CopyBucket, Inc.. Invention is credited to Tamer Abuelata.
Application Number | 20190324826 15/959138 |
Document ID | / |
Family ID | 68236938 |
Filed Date | 2019-10-24 |
![](/patent/app/20190324826/US20190324826A1-20191024-D00000.png)
![](/patent/app/20190324826/US20190324826A1-20191024-D00001.png)
![](/patent/app/20190324826/US20190324826A1-20191024-D00002.png)
![](/patent/app/20190324826/US20190324826A1-20191024-D00003.png)
![](/patent/app/20190324826/US20190324826A1-20191024-D00004.png)
![](/patent/app/20190324826/US20190324826A1-20191024-D00005.png)
![](/patent/app/20190324826/US20190324826A1-20191024-D00006.png)
![](/patent/app/20190324826/US20190324826A1-20191024-D00007.png)
![](/patent/app/20190324826/US20190324826A1-20191024-D00008.png)
![](/patent/app/20190324826/US20190324826A1-20191024-D00009.png)
![](/patent/app/20190324826/US20190324826A1-20191024-D00010.png)
View All Diagrams
United States Patent
Application |
20190324826 |
Kind Code |
A1 |
Abuelata; Tamer |
October 24, 2019 |
SYSTEMS AND METHODS FOR EFFICIENT INTER-DEVICE DATA EXCHANGE
Abstract
Various of the disclosed embodiments provide systems and methods
for efficiently recalling data on a single device and for
efficiently transitioning data between devices. Users may use
graphical user interfaces on one or more client devices to manage
"buckets" of data. These data collections may be stored locally on
the client devices and on a server storage system. In some
embodiments, the system may synchronize bucket collections between
client devices. Bucket data may also be cached locally on the
client device to facilitate ready user access and efficient
workflow. Various embodiments may be used, for example, in
collaborative work environments to readily store and exchange data
assets between team members.
Inventors: |
Abuelata; Tamer; (San Jose,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
CopyBucket, Inc. |
Cupertino |
CA |
US |
|
|
Family ID: |
68236938 |
Appl. No.: |
15/959138 |
Filed: |
April 20, 2018 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 3/0482 20130101;
G06F 3/04817 20130101; G06F 9/543 20130101; G06F 3/048 20130101;
G06F 3/0486 20130101 |
International
Class: |
G06F 9/54 20060101
G06F009/54; G06F 3/0481 20060101 G06F003/0481; G06F 3/0482 20060101
G06F003/0482 |
Claims
1. A computer system comprising: at least one display; at least one
processor; at least one memory, the memory comprising instructions
configured: to cause the computer system to display a graphical
user interface associated with a bucket management program on the
display, the graphical user interface comprising: a bucket
selection interface configured to receive a selection for at least
one of a plurality of buckets from a user, the bucket selection
interface further configured to depict a currently selected bucket;
and a window depicting a plurality of icons, each icon associated
with a data object within the bucket currently selected in the
bucket selection interface, the plurality of icons arranged in a
first sequential order within the window; and in response to a user
command, to cause the graphical user interface associated with the
bucket management program to: depict an additional icon in the
window, the additional icon associated with a new data object
specified by the user, wherein the new data object is an extracted
portion of a file; create a copy of the data object on the computer
system; send, across a network, a copy of the data object to a
remote server system and an indication that the new data object is
associated with the bucket currently selected in the bucket
selection interface, wherein, the plurality of icons, including the
additional icon, are arranged in a second sequential order within
the window following receipt of the user command.
2. The computer system of claim 1, wherein the user command
comprises a paste command, the paste command transferring the new
data object from a native operating system clipboard portion of
memory to the bucket management program.
3. The computer system of claim 1, wherein the extracted portion of
the file is one of a sequence of characters from less than all of a
text file, a collection of pixels from less than all the pixels of
an image file, or cell data from less than all the cells of a
spreadsheet file.
4. The computer system of claim 1, the instructions further
configured to cause the computer system to: receive a shared data
object from a peer bucket management program via the server system,
depict a second additional icon in the window, the second
additional icon associated with the shared data object, wherein the
shared data object is an extracted portion of a file, and wherein
the plurality of icons, including the second additional icon, are
arranged in a third sequential order within the window following
receipt of the shared data object, the second additional icon
appearing in the first position of the third sequential order
following receipt via the server system.
5. The computer system of claim 1, wherein the order of items in
the first sequential order corresponds to the order in which the
data objects corresponding to the icons are introduced into the
bucket, and wherein the second sequential order comprises the
additional icon in a first position and the following icon
positions in the same order as the first sequential order of
icons.
6. The computer system of claim 1, wherein the graphical user
interface further comprises: an indication that the bucket
management program is in network communication with the server; and
a memory footprint indicia indicating the memory consumed by items
associated with the bucket currently selected in the bucket
selection interface, and wherein each of the plurality of icons
indicates a type of the associated data object within the
bucket.
7. The computer system of claim 6, the graphical user interface
further comprising an action selection toolbar, the action
selection toolbar comprising a second plurality of icons, the
second plurality of icons corresponding to operations transferring
data from the bucket management program to another program running
on the computer system, and wherein the action selection toolbar is
located above the bucket selection, wherein the bucket selection is
located above the window, wherein the window is located above the
indication that the bucket management program is in network
communication with the server and the memory footprint indicia, and
wherein the plurality of icons within the window are arranged in a
vertical list within the window, the first icon of the sequential
order appearing in the top-most position of the list within the
window.
8. A computer-implemented method comprising: displaying a graphical
user interface associated with a bucket management program on a
display, the graphical user interface comprising: a bucket
selection interface configured to receive a selection for at least
one of a plurality of buckets from a user, the bucket selection
interface further configured to depict a currently selected bucket;
and a window depicting a plurality of icons, each icon associated
with a data object within the bucket currently selected in the
bucket selection interface, the plurality of icons arranged in a
first sequential order within the window; and in response to a user
command, to cause the graphical user interface associated with the
bucket management program to: depict an additional icon in the
window, the additional icon associated with a new data object
specified by the user, where the new data object is an extracted
portion of a file; create a copy of the data object on the computer
system; send, across a network, a copy of the data object to a
remote server system and an indication that the new data object is
associated with the bucket currently selected in the bucket
selection interface, wherein, the plurality of icons, including the
additional icon, are arranged in a second sequential order within
the window following receipt of the user command.
9. The computer-implemented method of claim 8, wherein the user
command comprises a paste command, the paste command transferring
the new data object from a native operating system clipboard
portion of memory to the bucket management program.
10. The computer-implemented method of claim 8, the instructions
further configured to cause the computer system to: receive a
shared data object from a peer bucket management program via the
server system, depict a second additional icon in the window, the
second additional icon associated with the shared data object,
wherein the shared data object is an extracted portion of a file,
and wherein the plurality of icons, including the second additional
icon, are arranged in a third sequential order within the window
following receipt of the shared data object, the second additional
icon appearing in the first position of the third sequential order
following receipt via the server system.
11. The computer-implemented method of claim 8, wherein the order
of items in the first sequential order corresponds to the order in
which the data objects corresponding to the icons are introduced
into the bucket, and wherein the second sequential order comprises
the additional icon in a first position and the following icon
positions in the same order as the first sequential order of
icons.
12. The computer-implemented method of claim 8, wherein the
graphical user interface further comprises: an indication that the
bucket management program is in network communication with the
server; and a memory footprint indicia indicating the memory
consumed by items associated with the bucket currently selected in
the bucket selection interface, and wherein each of the plurality
of icons indicates a type of the associated data object within the
bucket.
13. The computer-implemented method of claim 12, the graphical user
interface further comprising an action selection toolbar, the
action selection toolbar comprising a second plurality of icons,
the second plurality of icons corresponding to operations
transferring data from the bucket management program to another
program running on the computer system, and wherein the action
selection toolbar is located above the bucket selection, wherein
the bucket selection is located above the window, wherein the
window is located above the indication that the bucket management
program is in network communication with the server and the memory
footprint indicia, and wherein the plurality of icons within the
window are arranged in a vertical list within the window, the first
icon of the sequential order appearing in the top-most position of
the list within the window.
14. A non-transitory computer-readable medium comprising
instructions configured to cause a computer system to perform a
method comprising: displaying a graphical user interface associated
with a bucket management program on a display, the graphical user
interface comprising: a bucket selection interface configured to
receive a selection for at least one of a plurality of buckets from
a user, the bucket selection interface further configured to depict
a currently selected bucket; and a window depicting a plurality of
icons, each icon associated with a data object within the bucket
currently selected in the bucket selection interface, the plurality
of icons arranged in a first sequential order within the window;
and in response to a user command, to cause the graphical user
interface associated with the bucket management program to: depict
an additional icon in the window, the additional icon associated
with a new data object specified by the user, where the new data
object is an extracted portion of a file; create a copy of the data
object on the computer system; send, across a network, a copy of
the data object to a remote server system and an indication that
the new data object is associated with the bucket currently
selected in the bucket selection interface, wherein, the plurality
of icons, including the additional icon, are arranged in a second
sequential order within the window following receipt of the user
command.
15. The non-transitory computer-readable medium of claim 14,
wherein the user command comprises a paste command, the paste
command transferring the new data object from a native operating
system clipboard portion of memory to the bucket management
program.
16. The non-transitory computer-readable medium of claim 14,
wherein the extracted portion of the file is one of a sequence of
characters from less than all of a text file, a collection of
pixels from less than all the pixels of an image file, or cell data
from less than all the cells of a spreadsheet file.
17. The non-transitory computer-readable medium of claim 14, the
instructions further configured to cause the computer system to:
receive a shared data object from a peer bucket management program
via the server system, depict a second additional icon in the
window, the second additional icon associated with the shared data
object, wherein the shared data object is an extracted portion of a
file, and wherein the plurality of icons, including the second
additional icon, are arranged in a third sequential order within
the window following receipt of the shared data object, the second
additional icon appearing in the first position of the third
sequential order following receipt via the server system.
18. The non-transitory computer-readable medium of claim 14,
wherein the order of items in the first sequential order
corresponds to the order in which the data objects corresponding to
the icons are introduced into the bucket, and wherein the second
sequential order comprises the additional icon in a first position
and the following icon positions in the same order as the first
sequential order of icons.
19. The non-transitory computer-readable medium of claim 14,
wherein the graphical user interface further comprises: an
indication that the bucket management program is in network
communication with the server; and a memory footprint indicia
indicating the memory consumed by items associated with the bucket
currently selected in the bucket selection interface, and wherein
each of the plurality of icons indicates a type of the associated
data object within the bucket.
20. The non-transitory computer-readable medium of claim 19, the
graphical user interface further comprising an action selection
toolbar, the action selection toolbar comprising a second plurality
of icons, the second plurality of icons corresponding to operations
transferring data from the bucket management program to another
program running on the computer system, and wherein the action
selection toolbar is located above the bucket selection, wherein
the bucket selection is located above the window, wherein the
window is located above the indication that the bucket management
program is in network communication with the server and the memory
footprint indicia, and wherein the plurality of icons within the
window are arranged in a vertical list within the window, the first
icon of the sequential order appearing in the top-most position of
the list within the window.
Description
TECHNICAL FIELD
[0001] Various of the disclosed embodiments relate to systems and
methods for storing, organizing, and presenting data across
devices.
BACKGROUND
[0002] 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.
[0003] 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's machine, which is volatile, can easily lose the data,
and typically lacks any extensive knowledge of previous clipboard
operations.
[0004] 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
[0005] 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:
[0006] FIG. 1 is a schematic diagram illustrating an example
topology of various elements as may be implemented in some
embodiments;
[0007] FIG. 2 is a schematic block diagram illustrating an example
relation between various operational modules as may be implemented
in some embodiments;
[0008] 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;
[0009] 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;
[0010] 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;
[0011] 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;
[0012] 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;
[0013] 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;
[0014] 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;
[0015] 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;
[0016] FIG. 11 is a flow diagram illustrating various operations in
an example copy-to-bucket process as may be implemented in some
embodiments;
[0017] 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;
[0018] FIG. 13 is a flow diagram illustrating various operations in
an example memory management threshold determination process as may
be implemented in some embodiments;
[0019] FIG. 14 is a flow diagram illustrating various operations in
an example threshold-based memory reallocation process as may be
implemented in some embodiments;
[0020] FIG. 15 is a flow diagram illustrating various operations in
an example paste-from-bucket process as may be implemented in some
embodiments;
[0021] FIG. 16 is a flow diagram illustrating an example multi-item
paste process as may be implemented in some embodiments;
[0022] FIG. 17 is a flow diagram illustrating various operations in
an example item deletion process as may be implemented in some
embodiments;
[0023] 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;
[0024] 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;
[0025] FIG. 20 is a schematic diagram illustrating an example
topology of various bucket relations as may occur in some
embodiments;
[0026] 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;
[0027] 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;
[0028] 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;
[0029] FIG. 24 is a flow diagram illustrating various operations in
an example share-between-users process as may be implemented in
some embodiments;
[0030] 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;
[0031] FIG. 26A is a schematic diagram of a client graphical user
interface including a bucket selection interface as may be
implemented in some embodimetns;
[0032] 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;
[0033] FIG. 27 is a flow diagram illustrating various operations in
bucket creation process as may be implemented in some
embodiments;
[0034] 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;
[0035] FIG. 29 is a flow diagram illustrating various operations in
a quick-copy or quick-cut process as may be implemented in some
embodiments;
[0036] 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;
[0037] FIG. 31 is a flow diagram illustrating various operations in
an example search process as may be implemented in some
embodiments;
[0038] 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
[0039] FIG. 33 is a block diagram of an example computer system as
may be used in conjunction with some of the embodiments.
[0040] 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
[0041] 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 120a, 120b, 120c
may be working on a variety of both team and individual-based
tasks. For example, the users 120a-c may be game developers, each
with specific skillsets, who are now trying to integrate the
various assets they've generated (e.g., software code, graphics,
sound files) into a single product. User 120a may also
independently be assembling images and text for a wedding album by
exchanging data between devices 125a and 125b.
[0042] While the users 120a-c may be located at a single location,
in this example, they are located at three distant locations
115a-c. Users 120a-c may be performing their various tasks with the
assistance of various computer devices 125a-d. For example, user
120a may be using a desktop computer 125a and a laptop computer
125b at location 115a, while user 120b, uses a mobile device 125c
(e.g., a tablet or mobile phone) at location 115b. User 120c may
employ a desktop computer 125d at location 115c.
[0043] To accomplish their various tasks, the users 120a-c may wish
to quickly and efficiently organize and share data across the
devices 125a-d. For example, user 120a may wish to exchange images
and text between devices 125a and 125b while creating their wedding
album. Simultaneously, user 120a may wish to exchange graphical
images via device 125a with user 120c's device 125d as part of the
game development.
[0044] While the users 120a-c may connect their respective devices
via network 105 (such as a local area network or the Internet) to
transmit 110b,c,e and receive 110a,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'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 120a may use one method when communicating
between devices 125a and 125b (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 120c's device 125d via
device 125a.
[0045] Rather than pursue these disparate, ad-hoc exchange methods,
the users 120a-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 115d (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
140b, and a database 140a and may receive 110g and transmit 110h
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 140b and a database 140a) 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.
[0046] In conjunction with client-side software operating on each
of devices 125a-d, the system 150 may facilitate a centralized
method for exchanging data between the devices 125a-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 120a copies images to the client software on device 125a, the
raw image data may be stored in datastore 140b 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 140a via metadata server 130. This data may
then be accessed by user 120c via client-side software on, e.g.,
device 125d.
[0047] 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 125a-d, here, the
users may instead store large and more complicated data via server
system 150.
[0048] While this example presents a topology clearly separating
client devices 125a-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's
client software may be designated the "server system" and used as
the central repository for the other users' copying operations. In
such a circumstance, the server system 150 may also be one of
devices 125a-d.
Example System Topology Overview--Example Modular Division
[0049] 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 125a-d for
communication with server system 150. For example, user 120c may
install client software 205 onto device 125d. 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.
[0050] For example, the connection management module 210a may be
software routines configured to connect with the server system. The
clipboard item management module 210b may locate clipboard data for
the operating system of device 125d. The buckets management module
210c may coordinate bucket synchronization, using software
implementing the operations and methods discussed elsewhere herein.
The persistence module 210d may implement caching optimization
rules. The synchronization module 210e may apprise the server and
client of changes on each. The memory management module 210f may
determine when local copies or server-side copies of data objects
should be used. As described in greater detail herein, memory
management module 210f 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 210f's balancing of these competing interests.
[0051] A real-time event actuator module 210g may notify the user
of events as they occur or at the request of the server system.
Real-time event actuator module 210g 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 210g may precipitate a
corresponding deletion locally at a second device (as well as
corresponding memory management adjustments).
[0052] The user interface module 210h may present the client
software GUI described herein and facilitate GUI operations on the
user's system's operating system. The contacts/sharing module 210i
may be software for interfacing with the user's address book, as
may be stored locally in an email client, remotely on an email
server, a digital phonebook, etc. Contacts/sharing module 210i 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 210j 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.
[0053] 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 140b. For example, an
authentication module 215a may ensure that the user's interactions
are performed under the appropriate account. Account management
module 215b may store account data (e.g., membership type, data
storage and transfer quotas, billing data, etc.) while bucket
management module 215c may coordinate bucket states with buckets
management modules 210c. Bucket item metadata module 215d may
coordinate storage of data object metadata, such as the data's
type, size, corresponding chunks, etc. Sharing/permissions module
215e may ensure that users only share buckets and objects in
accordance with their sharing permissions, account levels, or other
restrictions.
[0054] Notifications module 215f may determine when users should be
notified, e.g., of errors related to a command, that a data
object's raw data will be expunged, and other notifications to
apprise the user of the system's status. Real-time event dispatch
module 215g may direct client software systems to perform immediate
events, such as begin an item removal from a bucket. An analytics
module 215h may record user behavior, client software operations,
or server operations, and may facilitate subsequent or real-time
review of the various modules' operations.
[0055] 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 140a. For
example, an authentication module 220a, like authentication module
215a may ensure that the user'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 220b may facilitates storage and retrieval of data chunks
associated with a various objects as described in greater detail
herein. Permissions checking module 220c, like permissions module
215e, may ensure that the user (as requestor or as recipient) has
appropriate permissions for a requested operations. Persistent
storage management module 220d may operate in conjunction with
persistence module 210d to ensure desired caching occurs at the
client system or at the server. Analytics management module 220e,
like analytics module 215h, may record user behavior, client
software operations, or server operations, to facilitate subsequent
or real-time review of the various modules' operations. Again,
modules may be omitted or combined in various embodiments than as
shown here to facilitate understanding.
Example Client-Side Graphical User Interface
[0056] 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
125d may comprise a keyboard 340a, mouse 340b, and display 340c.
The display 340c may depict the GUIs for a variety of programs
running on the operating system of device 125d, e.g., windows 345a
and 345b may be GUIs for text editing or graphical applications.
Note that in some embodiments, device 125d 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 345a and 345b, as shown, to facilitate ready
access. In accordance with some operating system's windowing
structure, minimization and closing icons 355 may be provided for
performing the respective operations.
[0057] 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.
[0058] Action selection toolbar 310 may comprise a plurality of
icons 310a-f associated with various user operations. For example,
icon 310a may include scissors and be associated with the cut or
with the quick-cut command discussed in greater detail herein. Icon
310b 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 310a 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 310b
may perform a Copy (Ctrl-C), or in some embodiments a "Quick Cut,"
operation (e.g., when combined with a keyboard command). Selecting
icon 310c may perform a Paste (Ctrl-V) operation. Selecting icon
310d 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 310e may perform
a "new copy from text" operation, which may allow creation of a
text item from user input. In some embodiments, the user's input
may be formatted as plain text or rich text (e.g., by presenting a
new text input window). Selecting icon 310f may present a settings
interface for setting client software program settings (e.g., user
account settings, network connectivity settings, GUI style,
etc.).
[0059] 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.
[0060] 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.
[0061] Item stack window 320 may comprise a plurality of item icons
320a-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 320a is
associated with text data comprising the phrase "Hello World!",
item icon 320b is associated with rich text copied from a Microsoft
Word.TM. document, item icon 320c 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 320e and the JPG
image file associated with icon 320g, 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 320d. 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.
[0062] Each icon may be associated with a numerical identifier in
its upper left corner. This identifier may indicate the item'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 320g was inserted into the stack for this
bucket before the rich text associated with item icon 320f 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.
[0063] A removal icon, such as an "x" may be placed in the upper
right corner of each item icon 320a-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 125d, the GUI 305 may depict many more items in
each of the buckets than it may be feasible or possible to store in
device 125d's local memory or disk.
[0064] Network/bucket-size summary region 365 may be used to inform
the user of the client software's network status and memory
footprint for a given bucket. Particularly, circular icon 325a may
provide visual indicia (e.g., via color) in conjunction with
textual indication 325b 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'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 125d. 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' 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.
[0065] 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
210f, 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's progress without disrupting
the behavior of local workspace programs (and consequently, each
user's individual efficiency).
Example Client-Side Copy and Paste Operations
[0066] 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's screen in schematic fashion, wherein a window 405
corresponding to Microsoft Notepad.TM. includes text 410 (one will
appreciate a number of text editors that may be used instead, e.g.,
Emacs.TM. Vi.TM. Microsoft Word.TM., 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.
[0067] 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.
[0068] 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.
[0069] 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'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.
[0070] 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'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'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.
[0071] 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'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.).
[0072] 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
900a, 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's
clipboard memory (e.g., using the "CTRL-C" keyboard command),
select the program 915'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 900b,
the program 915's window now reflects the data object'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
[0073] 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 1005a, a user 120c may be working on a local
computer system 125d, 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's previous actions, or items
received from other users, may have resulted in the client-side's
bucket management program'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 1005a.
[0074] That is, local computer system 125d 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's data may be
distributed across different portions of local computer system
125d'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'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
140b and metadata regarding the items in database 140a, 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.
[0075] The user 120c 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 1005b. 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'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'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
125d may facilitate various operations, including caching
operations, recovery operations, redundancy capabilities, and data
integrity verification.
[0076] For example, when a user removes an item, e.g., cuts or
deletes 1030 Item B from the local GUI 1020 at time 1005c, the
local GUI representation may indeed remove the Item as shown at
time 1005d. The metadata associated with Item B may be updated at
both the local computer system 125d 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.
[0077] However, in some embodiments, the local disk memory 1015 and
the server memory 1010, and in some embodiments peer device's
memory, may retain Item B's data. This retention may facilitate
recovery operations (e.g., an undo operation) either by the user
120c or a peer. During such recovery, the GUI 1020 may be adjusted
to reintroduce an icon associated with Item B.
[0078] In some embodiments, various metrics may be used to finally
remove data, e.g., as shown at time 1005e 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 125ds 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.
[0079] 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's icon from the user's view even though the
item's data remains at one or more of these locations).
Example Process Operations
[0080] 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's clipboard memory. For
example, in the Notepad.TM. text editor, the user may select text
and press the "control" key and the letter "C" key
simultaneously.
[0081] At block 1110, the user may manifest their intention to
transfer the data in the operating systems' 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'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.
[0082] At blocks 1115 and 1120, the client software system may
acquire the native operating system data and begin interpreting the
item'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's icon within the relevant
bucket (note that no visible update may occur in some embodiments
if the relevant bucket is not selected).
[0083] 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's databases. For example, metadata may be placed
in a database 140a and item data placed in a data store 140b (such
as Amazon Web Service S3.TM.) 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.
[0084] At block 1150, the server system may similarly direct peer
users' 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.
[0085] 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'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's data plan (for example, by consulting
account data, such as quotas, for the user at an account management
server or account management module 215b), 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's account does not
permit the data object's size, then the client-side software may
notify the user of the error at block 1265, before returning.
[0086] At block 1220, the client or server software may also check
to see if the user'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's metadata to the server and cause the
server to update the bucket's metadata to reflect the data object's
addition at block 1230.
[0087] 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.
[0088] 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's local
use.
Example Memory Management--Memory Threshold
[0089] In various embodiments, the client or server systems may
enforce constraints on item storage in quick-access memory (e.g., a
local computer's RAM memory) as opposed to slower, long-term
storage (e.g., on a local computer'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 210f. At block 1305,
the system may determine the local device'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'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.
[0090] 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.
[0091] 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
[0092] 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'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.
[0093] 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's data items,
including recently deleted ones, may be in one large list data
structure called L.
[0094] 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 & 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.
[0095] For so long as the bucket management program'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
[0096] 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.
[0097] 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'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.
[0098] 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).
[0099] 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.
[0100] 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
[0101] FIG. 16 is a flow diagram illustrating an example multi-item
paste process 1600 as may be implemented in some embodiments. On
the macOS.TM. 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.TM. 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's clipboard structure.
[0102] At block 1605, a variety of temporary field values
associated with the native operating system'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.
[0103] 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'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's clipboard rich text field to the contents of the
rich text buffer.
[0104] 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's clipboard fields to insert them
appropriately into the document.
[0105] On some native operating systems, e.g., Windows.TM., 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.
[0106] 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.
[0107] 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.
[0108] 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
[0109] 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'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.
[0110] 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'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's bucket.
[0111] 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.
[0112] 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.
[0113] 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's devices
running the application.
Example Data Object Removal Using Chunks
[0114] 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.
[0115] At block 1810, the client system may consult with an account
server, the metadata server 130 (e.g., account management module
215b and sharing/permissions module 215e), or internal records to
determine if the user'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.
[0116] 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' bucket
icon stacks updated to again depict the recovered item or
items).
[0117] At block 1825, the client and server may adjust the bucket'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.
[0118] 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'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
[0119] FIG. 20 is a schematic diagram illustrating an example
topology of various bucket relations as may occur in some
embodiments. As previously discussed user 120a may be working with
two devices, desktop computer 125a and a laptop computer 125b, at
location 115a. Each of desktop computer 125a and a laptop computer
125b may be running a client software instance, e.g., client
software instance 2010a on device 125a and client software instance
2010b on device 125b.
[0120] The user may desire the instances 2010a and 2010b to
"mirror" one another. Thus, buckets and data on instance 2010a may
also be represented in instance 2010b and vice versa. Similarly,
operations performed on a bucket and its contents via instance
2010a will also occur in instance 2010b 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 2010a and 2010b 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.
[0121] Thus, items 2020a, 2020b in bucket 2015a on instance 2010a
may correspond to items 2020e, 2020f in bucket depiction 2015d on
instance 2010b. Similarly, items 2020c, 2020d in bucket depiction
2015b on instance 2010a may correspond to items 2020g, 2020h in
bucket depiction 2015e on instance 2010b. 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 2015c and 2015f, per the user'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 125a and a
laptop computer 125b running different operating systems.
[0122] 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 2010c on device 125d bucket depictions 2015h
and 2015i may have items 2020k-n not appearing in other users'
buckets. Thus, modification of these buckets will precipitate no
change anywhere else. However, the shared bucket represented by
bucket depiction 2015g may be mirrored with each of the contents of
the buckets represented by depictions 2015b and 2015e.
Consequently, removal of either item 2020i or 2020j would result in
corresponding removal of items 2020c, 2020d and 2020g, 2020h in
their respective buckets.
[0123] 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
[0124] 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 2115a depicting a first client instance GUI 305 may
wish to send an item to a second user with display view 2115b on a
separate device depicting a second client instance GUI 2110. The
first GUI select the "Default" bucket via selection 2120a, while
the second GUI 2110 focuses on the "Received" bucket selection
2120b. While the second GUI 2110'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.
[0125] 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'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."
[0126] 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 2205a for searching, e.g., for peer user names. A region
2205b 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
2205b. Region 2205c then provides buttons for sending the item to
the selected users. In some embodiments, the contacts/sharing
module 210i may consult the user's address book to identify
friends.
[0127] 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).
[0128] 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.
[0129] 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'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 2605a in some embodiments.
[0130] 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'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.
[0131] At block 2430, the server system may update the one or more
recipients' bucket data to reflect the newly received item. In some
embodiments, this may precipitate a new item entry in the metadata
database 140a. 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.
[0132] At block 2435, the server may direct the recipient's GUI to
notify the recipient of the new item's arrival. Similarly, at block
2440, the server may direct the sender's client software to notify
the sender via the client's GUI of the operation's success.
[0133] 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's permissions permit receipt of an
item of the shared object'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.
[0134] Where adequate permissions exist, at block 2520, the server
system may generate a copy of the object's metadata. The server may
also update the metadata associated with the recipient'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's
bucket).
[0135] 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
[0136] 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.
[0137] 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
2605a as shown in FIG. 26B to the user. This window may include a
plurality of bucket summary entries in summary region 2610.
[0138] Clicking the "plus" sign 2615a may begin the creation of a
new bucket, while selecting the minus sign 2615b after selecting a
bucket in region 2610 may begin removal of the bucket.
Particularly, following selection of the "minus" sign 2615b the
system may present the dialog 2605b 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 2605b 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.
[0139] Conversely, selection of the "plus" sign 2615a will cause
the system to present dialog 2605c 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's
client interfaces. By clicking on a bucket's name in the summary
region 2610 the user may change a bucket'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's contents,
the order of the buckets may be propagated to all of the user's
devices. The order may also be reflected in the bucket selection
interface 315.
[0140] 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.
[0141] 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 2615a 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.
[0142] 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.
[0143] 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'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 2605a.
Example Operations--Quick Cut and Quick Copy Actions
[0144] 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.
[0145] 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 2805a, 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's data to be copied to the operating system's clipboard.
The quick cut operation may proceed in a similar manner, but
instead showing dialog 2805b with range input 2830 as well as
causing the system to remove the item from the bucket.
[0146] 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's
clipboard. Keyboard exclusive interaction may better align with the
user's rapid workflow.
[0147] 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.
[0148] 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
[0149] 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 3000a, 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 3000a, 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
3000a may not appear in the search for "files" of these
embodiments. Rather than PNG image data, only entire PNG files
would be retained.
[0150] The system may also filter items based on the input by
layering terms. For example, in TIFF Image search 3000b 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).
[0151] 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 3000c 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.
[0152] 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.
[0153] 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.
[0154] 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'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'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.
[0155] When an item is added to a bucket, the server system 150 may
store its raw data and metadata including, e.g., the item'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'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).
[0156] 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
[0157] 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 3200a, the client software may display only a single GUI
window 3210a on the user's screen. By, e.g., selecting "New Window"
in the dialog 3205 of the "File" selector, the user may create a
second GUI window 3210b. An arbitrary number of windows may be
generated in this manner in some embodiments.
[0158] Each window may serve as a separate instance for modifying
buckets. For example, as shown in state 3200b, the user has used
selector 3215b to view items in the "Second" bucket, while the
first window 3210a's selector 3215a remains focused on the
"Default" bucket. Note that the size indicia 3225b has changed in
the second window 3210b in accordance with the contents of the
"Second" bucket, in contrast with the size indicia 3225a of the
window 3210a, which remains associated with the "Default" bucket.
Similarly, by clicking on the network indicia 3220 of the second
window 3210b, the user may disconnect window 3210b's network
connection with the server system 150, while retaining the window
3210a's connection. In some embodiments, in contrast, only a single
network connection may be available to all the windows.
[0159] 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.
[0160] In some embodiments the user'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's
workflow and facilitate productivity.
Example Feature Augmentations for Some Embodiments--Preview for
Mobile Device
[0161] Some embodiments, rather than providing a full client user
interface 305 in a mobile device, such as mobile device 125c, 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'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
[0162] 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.
[0163] The one or more processors 3310 may include, e.g., an
Intel.TM. 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.TM. adapters,
line-of-sight interfaces, etc.
[0164] 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.
[0165] 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.
[0166] 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
[0167] 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'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.
[0168] 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.
[0169] 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.
* * * * *