U.S. patent application number 12/021277 was filed with the patent office on 2008-07-31 for real time online video editing system and method.
Invention is credited to Andrew Gavin, Scott Shumaker.
Application Number | 20080183844 12/021277 |
Document ID | / |
Family ID | 39669042 |
Filed Date | 2008-07-31 |
United States Patent
Application |
20080183844 |
Kind Code |
A1 |
Gavin; Andrew ; et
al. |
July 31, 2008 |
REAL TIME ONLINE VIDEO EDITING SYSTEM AND METHOD
Abstract
A system and method for online video editing allowing multiple
users to simultaneously edit a production in real time. The system
includes a method for exchanging asynchronous messages between a
client computer and a server. The system further includes an atomic
data structure of commands for manipulating multimedia assets.
Client computers subscribe to a production on the server. Changes
made to the production on the client computer are applied to the
local state of the production and are also transmitted to the
server via asynchronous messaging. The server checks for conflicts,
resolves the conflicts, applies any necessary changes to the state
of the production on the server, and pushes any resulting changes
to the production to all subscribing client computers via
asynchronous messaging.
Inventors: |
Gavin; Andrew; (Pacific
Palisades, CA) ; Shumaker; Scott; (Los Angeles,
CA) |
Correspondence
Address: |
CHRISTIE, PARKER & HALE, LLP
PO BOX 7068
PASADENA
CA
91109-7068
US
|
Family ID: |
39669042 |
Appl. No.: |
12/021277 |
Filed: |
January 28, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60897558 |
Jan 26, 2007 |
|
|
|
60897552 |
Jan 26, 2007 |
|
|
|
60897559 |
Jan 26, 2007 |
|
|
|
60897544 |
Jan 26, 2007 |
|
|
|
60898201 |
Jan 29, 2007 |
|
|
|
60913204 |
Apr 20, 2007 |
|
|
|
60915427 |
May 1, 2007 |
|
|
|
Current U.S.
Class: |
709/217 |
Current CPC
Class: |
G06Q 40/00 20130101;
G06Q 30/06 20130101; G07F 17/16 20130101 |
Class at
Publication: |
709/217 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A web-based video editing system comprising: a server connected
to a network; a client communications device connected to the
network, wherein the client communications device is in
communication with the server; media storage connected to the
server, the media storage including media files that are used in a
video production; production storage connected to the server, the
production storage including a set of atomic production commands
and references to media files related to the atomic production
commands, the commands and references defining a video production;
wherein the server is configured to send the set of atomic
production commands and references to media files to the client
communications device; receive a new production command from the
client communications device; determine if the new production
command is valid for the set of atomic production commands and
references to media files; add the new production command to the
set of atomic production commands and references to media files and
send a production command accepted communication to the client
communications device when the new production command is determined
to be valid, and send a production command rejected communication
to the client communications device when the new production command
is determined not to be valid.
2. The system of claim 1 wherein the server is further configured
to: send the set of atomic production commands and references to
media files to a plurality of client communications devices;
receive a new production command from any of the plurality of
client communications devices, wherein the server is configured to
send an update to the set of atomic production commands and
references to media files to one or more of the plurality of client
communications devices; and receive a plurality of new production
commands from more than one of the plurality of client
communications devices before the server sends an update to the set
of atomic production commands and references to media files for the
first of the plurality of new production commands from more than
one of the plurality of client communications devices to one or
more of the plurality of client communications devices.
3. The system of claim 1 wherein the client communications device
is in communication with the server using asynchronous
messaging.
4. The system of claim 1 wherein the server includes the media
storage.
5. The system of claim 1 wherein the server includes the production
storage.
6. The system of claim 1 wherein the server includes the media
storage and the production storage
7. The system of claim 1 wherein the server is further configured
to send software to the client communications device that displays
the video production according to the set of atomic production
commands and references to media files and provides a graphical
user interface for making modifications to the video production
according to the set of atomic production commands and references
to media files and transmits a production command to the server in
response to a user's interaction with the graphical user
interface.
8. The system of claim 1 wherein the client communications device
comprises a graphical user interface.
9. The system of claim 8 wherein the client communications device
comprises at least one selected from the group consisting of: a
personal computer, a laptop computer, a handheld computer, a phone,
and a video player.
10. The system of claim 1 wherein the network is the Internet.
11. A web-based video editing method using a server connected to a
network, media storage connected to the server, the media storage
including media files that are used in a video production,
production storage connected to the server, the production storage
including a set of atomic production commands and references to
media files related to the atomic production commands, the commands
and references defining a video production, and a client
communications device connected to the network wherein the client
communications device is in communication with the server, the
method comprising: the server sending the set of atomic production
commands and references to media files to the client communications
device; the server receiving a new production command from the
client communications device; determining if the new production
command is valid for the set of atomic production commands and
references to media files; adding the new production command to the
set of atomic production commands and references to media files and
sending a production command accepted communication to the client
communications device when the new production command is determined
to be valid, and sending a production command rejected
communication to the client communications device when the new
production command is determined not to be valid.
12. The method of claim 11 further comprising: the server sending
the set of atomic production commands and references to media files
to a plurality of client communications devices; the server
receiving a new production command from any of the plurality of
client communications devices and sending an update to the set of
atomic production commands and references to media files to one or
more of the plurality of client communications devices; and the
server receiving a plurality of new production commands from more
than one of the plurality of client communications devices before
the sending an update to the set of atomic production commands and
references to media files for the first of the plurality of new
production commands from more than one of the plurality of client
communications devices to one or more of the plurality of client
communications devices.
13. The method of claim 11 further comprising the client
communications device communicating with the server using
asynchronous messaging.
14. The method of claim 11 wherein the server includes the media
storage.
15. The method of claim 11 wherein the server includes the
production storage.
16. The method of claim 11 wherein the server includes the media
storage and the production storage
17. The method of claim 11 further comprising the server sending
software to the client communications device that displays the
video production according to the set of atomic production commands
and references to media files and provides a graphical user
interface for making modifications to the video production
according to the set of atomic production commands and references
to media files and transmits a production command to the server in
response to a user's interaction with the graphical user
interface.
18. The method of claim 11 wherein the client communications device
comprises a graphical user interface.
19. The method of claim 18 wherein the client communications device
comprises at least one selected from the group consisting of: a
personal computer, a laptop computer, a handheld computer, a phone,
and a video player.
20. The method of claim 11 wherein the network is the Internet.
Description
[0001] This application claims priority to and the benefit of U.S.
Provisional Application No. 60/897,558, filed on Jan. 26, 2007,
which is incorporated by reference as if set forth in full herein.
This application is also related to the co-pending U.S. Provisional
Application No. 60/897,552, filed on Jan. 26, 2007, titled "Video
Downloading and Scrubbing System and Method" (Atty. docket no.
58745), U.S. Provisional Patent Application No. 60/897,559, filed
on Jan. 26, 2007, titled "Payment System and Method for Web-Based
Video Editing System" (Atty. docket no. 58891), U.S. Provisional
Patent Application No. 60/897,544, filed on Jan. 26, 2007, titled
"System and Method for Editing Web-Based Video" (Atty. docket no.
58981), U.S. Provisional Patent Application No. 60/898,201, filed
on Jan. 29, 2007, titled "Image Editing System and Method" (Atty.
docket no. 58744), U.S. Provisional Patent Application No.
60/913,204, filed on Apr. 20, 2007, titled "Image Editing System
and Method" (Atty. docket no. 59717), and U.S. Provisional Patent
Application No. 60/915,427, filed on May 1, 2007, titled "System
and Method for Flow Control in Web-Based Movie Editing System"
(Atty. docket no. 59323), the entire contents of each of which are
expressly incorporated herein by reference.
BACKGROUND OF THE INVENTION
Field of the Invention
[0002] The present invention relates to the field of web-based
software, and more particularly, to a system and method for
creating interactive multimedia widgets for use on web pages.
BRIEF DESCRIPTION OF THE DRAWINGS
[0003] FIG. 1 shows client computers connected to a server via the
internet.
[0004] FIG. 2 shows a block diagram of a system for asynchronous
messaging over the internet.
[0005] FIG. 3a shows a flowchart for a computer routine for
updating data between a client computer and a server using
asynchronous messaging.
[0006] FIG. 3b shows a flowchart for a computer routine for
performing conflict resolution on a server when the server receives
data from a client computer.
[0007] FIG. 3c shows a flowchart for a computer routine for
updating the data on a client computer in response to data received
from a server.
[0008] FIG. 4 shows a sample representation of a data
structure.
[0009] FIG. 5 shows one possible representation of a graphical user
interface as seen on a client computer.
DETAILED DESCRIPTION OF THE INVENTION
[0010] The present invention relates to an online project, referred
to as a production, for the creation of a widget (or any other form
of a portable chunk of code that can be installed and executed
within any separate html-based web page by an end user without
requiring additional compilation) or video that includes any media
with interactive properties. In some embodiments of the present
invention, the widget may display a movie including one or more
forms of interactive or non-interactive media.
[0011] In some embodiments of the present invention, each
production exists as a set of data on the server. Individual users
can create external links to a production such that it can be
viewed in a web-browser or such that it can be embedded as an
object in a webpage. Further, users may run the client version of
the present invention in a web-browser and use it to edit a
currently existing production or to create an entirely new
production to which that user, or other users, may then subscribe.
Subscribing to a production shall mean the creation of a channel of
communication between the client computer and the server through
which the client computer receives real time updates of the current
state of the production from the server. Thus, when a user
subscribes to a production, the client computer receives constant
feedback and updates from the server, as discussed below, so that
the client computer always has the most recent version of the
production.
[0012] Referring to FIG. 1, according to an embodiment, the present
invention includes one or more client computers 110 and a server
120 running a connection manager 130 where either the server, the
connection manager, or both are in communication with a backend
server 180, and where the client computers 110 communicate with the
server via the Internet 140. The client computers may be a personal
computer, a PDA, a cellular phone, or any other device with a
graphical user interface capable of sending and receiving data. The
client computer may be connected to the server with a wireless or
wireline connection and may communicate with the server over a
local area network, a wide area network, or the Internet.
[0013] Referring to FIG. 2, according to an embodiment of the
invention, backend server 280 is an instance of backend server 180,
server 220 is an instance of server 120, client 210 is and instance
of client computers 110 and connection manager 230 is an instance
of connection manager 130. Server 220 is connected to client 210 by
one or more TCP (often HTTP over TCP) connections 240. Server 220
receives queries 260 from the client computers 210 and communicates
responses 270 to the client computers 210. Server 220 also runs a
connection manager 230 that maintains an open socket connection 250
with the client computer 210 and that uses asynchronous messaging
to communicate with the client computer 210. This open socket
connection 250 is a lasting, dedicated connection between the
client computer 210 and the server 220. The connection manager
maintains this open socket connection 250 with the client computer
and, by so doing, allows the server 220 to push data to the client
computer 210 without having the client computer 210 first send a
query 260 as in a traditional web communication. Additionally, the
application running on the client computer 210 may transmit packets
of data as asynchronous messages via the open socket connection 250
to the connection manager 230 and server 220 and may continue its
operations without waiting for a response from the server 220.
Further, because of the dedicated nature of the open socket
connection 250, the connection manager 230 can push small,
piecemeal packets of data to the client computer 210 without having
to send the entire production each time the production has been
updated.
[0014] In many embodiments, there are many client computers 210
and/or many client applications on the same or different client
computers (additional client computers not shown) connected to
server 220 and connection manager 230 at the same time. In some of
these embodiments, more than one client computer 210 connected to
server 220 and connection manager access the same production at the
same time. In some of these embodiments, any particular connection
could also be accessing more than one production
simultaneously.
[0015] In many embodiments, if it is not possible to create a
direct socket connection 250 between the client computer 210 and
the connection manager 230, then a virtual connection can be
created using the more generic HTTP connections 240. Because there
is no direct socket in this case, the client computer 210 must
periodically pick up its messages by sending a "check mailbox"
query to the server 220. The server 220 then responds by
transmitting to the client computer 210 over the TCP connection 240
data pertaining to any updates to the publication, or data
pertaining to any other pertinent information.
[0016] In some embodiments of the present invention, still
referring to FIG. 2, when the client computer 210 wants to start
communicating the connection manager 230 creates an open socket
connection 250 with the client computer 210. When a user wishes to
edit or view a specific production, the client computer 210
software attempts to subscribe to the production by sending a
message over the socket 250 which is relayed to the backend servers
280. If the backend server 280 accepts the request to subscribe to
the production, the connection manager 230 sends the client
computer 210 the current production data. In some embodiments of
the present invention, the server 220 first sends a response 270 to
the client computer 210 containing data necessary to create the
open socket connection 250 with the connection manager. In other
embodiments, the client 210 sends the data necessary to create the
open socket connection 250 in the query 260. For example, in an
Adobe Flash based implementation, a client computer 210 may load a
webpage containing HTML code embedding a flash player which knows
which production to play. This player will then negotiate its
connections to the servers 230 and 220 via the socket connection
250 and/or the TCP/HTTP connection 240 protocols.
[0017] When any changes occur to the production (e.g., if that user
or another user edits the production), the connection manager 230
may push the update data via the open socket connection 250 to each
client computer 210 currently subscribed to the production. Because
of the nature of the open socket connection 250, the connection
manager 230 need only push the small bit of data pertinent to the
update rather than all the data for the entire production. If the
subscriber is permitted to edit the production, the client computer
210 may send any data pertinent to changes in the production to the
server via asynchronous messaging as the changes occur.
Alternatively, the connection manager 230 may wait until the client
computer 210 requests an update before pushing data to the client
computer 210 over the open socket connection 250. This may be
performed by comparing the state of the production on the client
computer 210 with the state of the production on the server 220,
comparing the most recent changes to the production on the server
220 to those on the client computer 210, or by any other acceptable
technique.
[0018] Referring to FIG. 3a, in an embodiment of the present
invention, the system uses asynchronous messaging to provide real
time co-editing of a production amongst multiple users. To
accomplish this, the system maintains data pertaining to the
current state of the production on the client computers as well as
on the server. The data includes a file, whether stored locally on
the server or remotely, for any form of media content, including,
but not limited to: audio clips, video clips, images, and
interactive widgets, such as polls, quizzes, photo books, video
transitions, overlays, webcam broadcasts, chat rooms, and the like
and is referred to as an asset. The actual data maintained on the
client computer may vary, depending on the implementation of the
system, from an exact replica of the data on the server to a
minimal amount of data that merely indicates where pertinent data
is located on the server, and any representation in between. When a
single user edits a production, the application running on the
client computer accepts 300 and processes user input into data
pertinent to changing the current state of a production (e.g., add,
move, modify, or delete as asset). The client computer sends 310 an
asynchronous message containing the data pertinent to the changes
in the production to the server via the dedicated open socket
connection (or an equivalent proxy). Without waiting for a response
from the server, the client computer changes 320 the state of the
local production in accordance with the user input and allows the
user to continue to modify the production in this manner. Depending
on the embodiment, the steps represented by blocks 310 and 320 may
be reversed in order.
[0019] Referring to FIG. 3b, when the server receives 330 the
asynchronous message from the client computer, the server
determines 340 whether the new instructions conflict with the
current state of the production as it is maintained on the server.
If the new instructions do not conflict the server pushes 350 an
asynchronous message back to the client computer indicating that
the state of the production was successfully changed. In alternate
embodiments, if there is only one subscriber, an asynchronous
message is not necessarily pushed back to the client computer. In
the case where more than one client computer is subscribed to the
production, the server pushes 350 data, in the form of an
asynchronous message, containing the changes to the production to
all of the other subscribers.
[0020] If the new instructions conflict, the server rejects 360 the
instructions, does not make any changes to the state of the
production, and pushes 370 data to the client indicating that a
conflict has occurred. In some embodiments, the server immediately
pushes data pertinent to the current state of the production to the
client computer. In another embodiment, the server pushes a request
for the client computer's current state of the production to the
client computer, receives a response, and then only pushes the data
necessary to update the current state of the production on the
client computer. In yet another embodiment, the server waits for a
request from the client computer for an update regarding the
current state of the production.
[0021] Referring to FIG. 3c, in some embodiments of the present
invention, when the client computer receives 380 a data push from
the server and determines 382 that submitted changes to the state
of the production were rejected, the client computer removes 384
the changes from the state of the production maintained on the
client computer. The client computer also determines whether any
subsequent changes to the state of the production relied on the
rejected changes and removes 388 those changes as well. Any changes
that have not been rejected are left as applied. If the data push
did not contain a rejection of a previous update made by the client
computer, the system applies 390 any update to the production from
the server.
[0022] The above described use of the connection manager greatly
facilitates real-time interaction and co-editing amongst multiple
users. Some embodiments of the present invention employ the
connection manager such that when multiple users are subscribed to
a production, any changes to the production made by one user are
subsequently pushed to all of the other subscribing users. In this
way, the system does not require individual users to continuously
have to request updates to a production. Thus, when one user makes
a modification to the current state of the production, once that
modification is accepted by the server, it is pushed to all of the
other subscribing client computers, which then make the appropriate
modification to the current state of the locally maintained
production.
[0023] In some embodiments of the present invention, production
data is stored in an atomic structure. Thus, each production
includes a plurality of assets and a plurality of instructions or
command elements. Command elements are data dictating the proper
manipulation and placement of each asset within a production. For
example, in addition to other data, each command element contains
an operator indicating the action to be applied to an asset, such
as being added, modified, moved, deleted, etc. The command elements
may be independently executable, or they may depend on one another.
Authoritative command elements are a type of command element that
do not depend on other command elements and thus may be processed
without reference to another command element. Non-authoritative
commands are a type of command element that can only be processed
in conjunction with one or more additional command elements.
[0024] Referring to FIG. 4, in some embodiments of the present
invention, each production includes a block of data 400 in computer
memory (not shown) having a series of discrete items of data each
representing one editing command element 410. Each editing command
element 410 includes a Command Identification Number ("CID")
variable 420, a sequence number 430, a flag variable 440 indicating
whether the command is authoritative, and operator data 450
including the actual command execution data as well as any other
data required to identify a particular asset and manipulate it
within a production.
[0025] Still referring to FIG. 4, in some embodiments of the
present invention, when a user adds content to a production (e.g.,
adding a video clip, adding sound, adding a still image, etc.), the
client computer software generates a command element 410 with a
unique CID 420 and a unique sequence number 430 containing operator
data 450 that corresponds to the relevant instruction within the
system. The sequence number 430 for each new command element 410
increases sequentially with each additional command element. In
some embodiments, the CID 420 for each command element 410
increases sequentially with each newly added asset and corresponds
to the particular asset that has been added to the production. In
some embodiments, each command element has a CID that corresponds
to a particular asset, and the command element shares that CID with
all other command elements that manipulate (e.g., move, delete,
etc.) that particular asset. Thus, the sequence number 430
indicates the order in which each of the command elements 410 was
added to the production and the CID 420 refers to the specific
asset the operator data 450 of the command element 410
manipulates.
[0026] For example, still referring to FIG. 4, if a user adds n
assets to the production, n command elements 411, 412, 413, . . . ,
41n will be added to the data representing the production with the
CID 420 and the sequence number 430 ranging sequentially from 1 to
n and each having operator data 450 indicating, for example, which
asset is to be added as well as an operator indicating that the
asset should be added to the production and any other data
pertinent to the operation. When, however, the user further
manipulates an asset that is already part of the production (e.g.,
deletes the asset from the production or moves the asset to another
time index or location within the production), such as the asset
represented by the command element 412 having a CID with a value of
"2," the command element 415 containing the operator data 450 to
manipulate the asset that was added to the production with command
element 412 will contain the next sequential sequence number 430
(n+1), but will have the same CID 420 as the original command
element 412 (i.e., "2").
[0027] In some embodiments, the system employs shadowing. Shadowing
includes determining whether an asset or a command element becomes
unnecessary because of a more recent command element. In some
embodiments, the above described system will shadow assets or
command elements when the value stored in the CID of one command
element is the same as the value stored in a second command element
and the operator data in the more recent of the two command
elements (i.e., the one with the greater sequence number) indicates
an operation that would make the previous command element
unnecessary. For example, referring again to FIG. 4, if the user
adds two assets to a production, two command elements 411 and 412
will be created having sequential sequence numbers 430 and
sequential CIDs 420. Assuming the user continues to add assets to
the production until n command elements 413, . . . , 41n exist, if
the user then chooses to delete the second asset added, a new
command element 415 will be created containing a CID 420 with the
value of "2" (to correspond with the CID 420 of the command element
412 that adds the asset to the production 400) and a sequence
number 430 with the value of n+1. The new command element 415 will
further contain operator data 450 indicating that the asset should
be removed from the production. Because this command element 415
indicates that the asset is to be deleted, all other command
elements (e.g., command element 412) that manipulate this
particular asset (e.g., adding the asset to the production, moving
the location of the asset, etc.) become unnecessary and thus are
termed shadow assets. To accomplish this shadowing, the system
builds and maintains a list of all relevant command elements by
only populating the list with command elements that are still
relevant in relation to command elements with a greater sequence
number 430 and the same CID 420. Thus, in the previous example,
when the system populates the list of relevant command elements and
when it encounters the first command element 412 with a CID 420
with a value of "2," it will examine all subsequent command
elements 415 with a CID 420 with a value of "2." When the system
determines that the latest command element 415 sharing this CID 420
contains an operator 450 indicating deletion, the system will not
populate the list with any of the command elements 412 and 415 with
a CID 420 of "2." Similarly, if the asset is being moved to a
different place in the timeline of the production, the system can
ignore all previous move command elements and thus only move the
asset once when building the production.
[0028] In other embodiments of the invention, the CID of each
command element is not strictly associated with a particular asset.
Instead, the CID is unique to a command element unless a new
command element affects a previous command element, in which case,
the CID for each of these command elements would have the same
value. For example, referring to FIG. 4, if a user adds two assets
to a production in the form of video clips, two command elements
411 and 412 with CIDs 420 and sequence numbers 430 with values of
"1" and "2" will be generated, each containing operator data 450
for adding each of the assets. If, for example, the user then adds
an image overlay to the second asset or otherwise manipulates or
edits the image in the second asset, a third command element 413
with a CID 420 having a value of "3" and a sequence number 430
having a value of "3" would be generated. While both command
elements affect the same asset, one does not shadow the other, as
described above, because it does not make the previous command
element 412 irrelevant. If the user subsequently deletes the second
asset from the production, then command element 415 is generated
with a CID 420 having a value of "2;" a sequence number 430 having
a value of "n+1;" and with operator data 450 containing an operator
indicating the asset should be deleted from the production because
this new command element 415 makes the command element 412 adding
the asset unnecessary and irrelevant. Similarly, because command
element 413 depends on command element 412, it would also become
shadowed. This may be accomplished by checking for dependent
command elements when one element is shadowed and then adding
command elements to delete the dependent command elements and
making this last set of command elements dependent on the original
deleting command element. This may also be accomplished by only
populating the relevant command elements list with command elements
that are not shadowed and that do not depend on command elements
that are shadowed.
[0029] In another embodiment, the above described shadowing of
assets allows the system to create a clean version of the
production such that the list of relevant elements replaces the
master list of relevant elements. The clean version of the
production thus only contains the non-shadowed assets in the
production. The system may prepare the clean version at the user's
command. Alternatively, the system may be configured to create
clean versions of productions at fixed time intervals or after a
period where a specific production has not been modified for some
fixed time period. Further, a clean version of a production may be
generated at a time when a user has completed editing a production
and makes it available to the public. Generating a clean version
decreases storage requirements by decreasing the overall size of
the production. The clean version also makes for a faster download
for client computers subscribing to the production due to its
decreased size.
[0030] In another embodiment of the above described system,
referring again to FIG. 4, each command element 410 also contains
flag data 440 indicating whether the command element 410 is
authoritative. Each non-authoritative command must depend on one
authoritative command element; however, an authoritative command
can have multiple dependant command elements. The authoritative
commands may thus act as undo and redo points within the
production. For example, if the user provides input to the system
indicating that he or she wishes to undo the last command, the
system will remove the command as well as all non-authoritative
commands that depend on that authoritative command. Similarly, if
the user provides input to the system that indicates he or she
wishes to redo a command, the system will redo the authoritative
command only and will allow the user to selectively redo each
subsequent non-authoritative command following the last
authoritative command. In this manner, the authoritative command
flag served to indicate legal undo and redo points.
[0031] In some embodiments, the system further includes a variable
containing the maximum sequence number. This allows the system to
keep track of which command element is the most recent while at the
same time allowing it to not delete the command elements that the
user has chosen to undo. In some embodiments, the above described
system further includes a maximum sequence number variable
containing the value of the sequence number of the last command
with which the system should populate any clean version of the
production. Thus, if a user has added a variety of command elements
and then later chooses to undo them, rather than permanently remove
these command elements from memory, the system instead merely
decreases the maximum sequence number such that the system will not
process those command elements. Thus, the user can easily "redo" or
reapply those command elements. Further, this variable allows for a
variety of system optimization techniques.
[0032] In some embodiments, each production has a current sequence
number and a maximum sequence number. The current sequence number
represents the current undo/redo state. When the system receives
input indicating that the user wishes to undo a command, the
current sequence number decreases, or winds backwards. When the
system receives input indicating that the user wishes to redo a
command, the system increases the current sequence number. The
maximum sequence number represents the total number of commands,
including those that the user has chosen to undo but has not chosen
to redo. Using the maximum sequence number, the system can track
whether there currently exist any legal redo commands. If the
system has received input indicating that one or more commands are
to be undone and the system has decreased the current sequence
number accordingly, when the system receives input from the user
indicating a change to the production, the system truncates the
maximum sequence number to have a value equal to the current
sequence number after the change because the old undone commands
would no longer be compatible with the new changes the
production.
[0033] In some embodiments, there are two versions, sometimes
referred to here as contexts, of each production, a published
version, sometimes referred to here as an audience version or
context, and a private version, sometimes referred to here as an
author version or context. Each context has a maximum and a current
sequence number, as discussed above. In these embodiments, whenever
the system receives input from the user indicating a change to the
production the system only applies the changes the author context.
When the system receives input from the user indicating that he or
she wishes to publish the production by making it viewable by the
public, the system will copy any information in the author context
to the audience context, which is viewable by the public.
[0034] In some embodiments, the system makes use of more than just
two contexts and may thus include, for example, semi-private
contexts. For example, a semi-private context might only be
viewable by a limited audience. Further, such a context might be
password protected or require some other appropriate form of user
authentication.
[0035] In some embodiments, the above described system further
includes a conflict resolution system whereby multiple users can
simultaneously co-edit the same production. In this embodiment, the
user adds, deletes, and otherwise manipulates assets in the
production resulting in a series of command elements. The client
computer transmits each new command element to the server. In order
to provide real time editing, the client computer does not wait for
a server response and instead assumes as true and accepted by the
server each of the user's edits unless the server indicates
otherwise. The system thus allows the user to continue to make
additional edits to the production without any lag time. When the
server receives a command element from the client computer, the
server compares the sequence number of the command element with the
last sequence number of the server's version of the production. If
the new command element's sequence number indicates that there have
been changes made to the server version since the client executed
the command, the system checks for a conflict. One indication that
changes have been made to the server version since the client
executed the command is when the new command element's sequence
number is less than or equal to the last sequence number in the
server version. One method by which the server may check for
conflicts is by checking the previous command elements having CIDs
having the same value to see if they conflict with one another. For
example, if a previous command element sent by the first user
deletes the asset that was added to the production by the command
element having a CID having a value of "2" and if the second user
then sends a command element containing instructions to move the
asset that was added to the production by the command element
having a CID having a value of "2" to a different point in the time
line, the server will reject this later command element and will
then push data to the client version of the program running on the
second user's computer. The pushed data would indicate that the
proposed command element was rejected and would also contain the
command elements added to the production by the other user.
Alternatively, more sophisticated conflict checking methods are
implemented. For example, the conflict resolution aspect of the
invention may instead process all of the command elements received
since the second user made an edit and check each one regardless of
the CID and then perform the data push. This data push not only
indicates that the proposed command element was rejected, but it
also contains the command elements added by other users that have
been accepted by the server. Once the client computer receives this
information, it will determine whether any of the next command
elements it submitted relied on this rejected command element and
will remove them if necessary.
[0036] In another embodiment of the invention, the operator data
portion of a command element may include a pointer to another
command element or to another array of command elements. In this
manner, the invention allows for arbitrary nesting of command
elements and of command element arrays. Thus, a command element in
a production may refer to another set of command elements, or it
may refer to another external production. In this manner,
productions may become nested within one another. Further, the use
of nested command elements allows the production to incorporate
assets that make further use of the atomic command element
structure.
[0037] FIG. 5 shows one possible representation of the graphical
user interface 500 as seen on the client computer. The interface
includes a timeline 510, assets 520 on the timeline in the order
they will be processed in the production, and a playback window
530. While a production is being edited, any user subscribed to the
production may play the current state of the production and view it
in the playback window 530. If any user adds a new asset 540 to the
publication, all of the client computers subscribed to the
production will immediately display the asset 540 being added. Any
client computer currently playing the production will continue to
play the production and will include the new asset in the playback
when it reaches it in the timeline.
* * * * *