|Publication number||US7231630 B2|
|Application number||US 10/427,735|
|Publication date||Jun 12, 2007|
|Filing date||Apr 30, 2003|
|Priority date||Jul 12, 2002|
|Also published as||EP1380944A2, EP1380944A3, US20040010794|
|Publication number||10427735, 427735, US 7231630 B2, US 7231630B2, US-B2-7231630, US7231630 B2, US7231630B2|
|Inventors||Troy Steven Acott, Joanna Mason, Michael W. Wallace, Larry Alan Westerman|
|Original Assignee||Ensequence Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (24), Non-Patent Citations (1), Referenced by (11), Classifications (8), Legal Events (9)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This invention claims priority from U.S. Provisional Application No. 60/395,653, entitled “METHOD AND SYSTEM FOR AUTOMATIC CONTROL OF GRAPHICAL COMPUTER APPLICATION APPEARANCE AND EXECUTION,” filed Jul. 12, 2002.
This patent application is related to concurrently-filed patent applications entitled “METHOD AND SYSTEM FOR FLEXIBLE TIME-BASED CONTROL OF APPLICATION APPEARANCE AND BEHAVIOR,” bearing Ser. No. 10/427,343 , “METHOD AND SYSTEM FOR PROVIDING FLEXIBLE TIME-BASED CONTROL OF APPLICATION APPEARANCE AND BEHAVIOR,” bearing Ser. No. 10/427,255, and “METHOD AND SYSTEM FOR GENERATING FLEXIBLE TIME-BASED CONTROL OF APPLICATION APPEARANCE AND BEHAVIOR,” bearing Ser. No. 10/427,357, all of which are incorporated by reference.
This invention relates generally to computer software applications and, more specifically, to programming and execution of graphical user interface programs.
Many positive consequences have resulted from the continual improvements in the price performance of microcomputer technologies. For example, graphical user interface driven applications have displaced less user-friendly command driven applications. Also, microcomputers have proliferated from the desktop computer to the laptop computer, personal digital assistants, cellular telephones, set-top boxes for televisions, and myriad other devices.
On the other hand, the improvements in microcomputer technologies have also resulted in some issues. With improvements in microprocessor systems, data transfer to and from the microprocessor presents more of a concern in processing throughput. Similarly, with the proliferation of microcomputer devices, demand on both wired and wireless networking bandwidth is constantly increasing. At the same time, the luxury of fast microprocessors and inexpensive large capacity memory systems has led to software engineers and programmers tending to generate less efficient code. The cost of the human capital to develop efficient code cannot be justified in the face of cheaper processing power that in many cases allows relatively inefficient code to run sufficiently quickly.
Within this context, there are challenges faced in creating an interactive computer application in today's environment. First, there is a conflict between the proliferation of computing devices on one hand and the tendency to create less efficient code because of the improved price performance of hardware. To take one example, a ubiquitous yet often overlooked home computer is the digital set-top box (STB) present in households receiving digital cable or digital satellite television signals. Most applications evident to the user are simple, such as changing channels; displaying a program guide; identifying the program; name; specifying the start time and run time of a program; and perhaps a short synopsis of the program. At the same time, the STB has to undertake many functions which may not be apparent to the user. For example, the STB has to coordinate which “channel” chosen by the user is represented by which data stream, and has to receive and decode the mass of video and audio data blocks which contain the program content.
Improved price performance of hardware has made the proliferation of these devices affordable and, therefore, practical. However, the computer hardware within the STB is very rudimentary by today's standards. A typical STB is operated by a relatively slow microprocessor, has very little random access memory, and little or no program storage. Because of this last reason, the STB frequently has to update the application code or data it stores, and cannot store large quantities of data at any time. Further, even though the STB necessarily has access to broadband data input, even if more memory were available to the STB, loading large quantities of non-video and non-audio data is not readily possible because the data stream is largely filled by video and audio data blocks for all the channels made available to the user through the cable or satellite feed.
Overcoming such concerns would allow STBs to be more fully exploited and thereby enhance the television production and viewing experience. For example, the addition of graphical information in a television program conventionally is performed in show postproduction by an editor, and the information actually becomes embedded as part of the visual data transmitted by the program. This same information could be received as data and superimposed on the video images of the telecast. Moreover, STBs could be used to allow user interaction with a program, such as by playing along with game shows or purchasing items displayed during a telecast. Currently, while it is possible to offer a telephone number, a web address, a vendor name, and similar information to allow an interested viewer to purchase an item indirectly, there are not opportunities to interactively purchase via the STB.
Second, when creating an application to be interactively engaged by a user, the designer of the application considers the application's behaviors in response to the user's actions as well as other changing circumstances. These circumstances may include the passage of time, direct user interaction with the input interface of the computer, or alterations in internal or external control signals. The challenge of creating a computer application to encapsulate the desired behavior is to accurately define these behaviors, then incorporate the behavior into a series of algorithmic statements. Typically, a designer or implementer of an interactive application will create explicit algorithmic statements in the coding language which implement the desired behavior. Control statement constructs, such as IF-THEN-ELSE or DO-WHILE logical constructions, are used to test for various conditions, the result of which can initiate simple operations. The sequential testing of these multiple control statements and the combination of the simple operations keyed thereby can then be combined into more complex behavior to create the appearance of a sophisticated application.
These first and second challenges may, however, conflict with each other. Capturing desired application behavior in a series of testing statements can require extensive code. Further, in the STB environment, both storing and securing the bandwidth to obtain necessary conditional coding sections present problems.
In order to try to effectuate desired conditional programming behavior in a compact data size, some program logic can be converted into equivalent data content. The data content, with the desired behavioral aspects of the application embedded therein, can interact with the control logic to execute the desired behavior without downloading all new application code for each desired set of functions.
One example of how this is done is a data-driven control mechanism such as that described by Watanabe et al. in U.S. Pat. No. 6,223,347, “DATA DISPLAY CONTROL APPARATUS” (“Watanabe”). Watanabe discloses a system which uses pre-encoded data to specify changing the appearance of an application according to predetermined behaviors which are instituted by the receipt of user actions, or by the passage of time. For each of a set of display screens, modifications of properties of elements of the screen can be made by invoking a “handler.” A handler is a small byte code sequence which accomplishes some change in the system properties, such as making a button visible or invisible, or displaying an alternative screen.
Viewed practically, Watanabe's data element 100 is a code fragment which dictates the response of the application in response to changing conditions. The data element 100 manifests an IF-THEN construct keyed by whether a user selects a VIDEO button 106 or a STEREO button 110. Moreover, the data element only encapsulates one aspect of the behavior for one single, conditional choice. To create a complex behavioral response to the user input, a series of stacked data elements like data element 100 would have to be created.
In addition, the system of Watanabe has a drawback which is shared by other similar systems such as web browsers. The Watanabe solution employs discrete code fragments which are executed in response to particular behavior, in just the same way that a web page is encoded to activate a link when the user clicks on a button or block to which the link is associated. As such, just as in a web browser the navigation available to the user is limited to the pre-defined URL links embedded in the source code for the page, under Watanabe the programming logic is fixed at design time to handlers pre-coded in the application. Also like a web browser, in which the transition to a new page represented by the link is automatic in response to the link being chosen, under Watanabe's system the behavior is responsive to the last conditional branch taken by the system in response to a user selection. Watanabe cannot take account of previous states from which the user selection was made or based on a combination of variables. The user's experience is based solely on the application's response to the last individual selection made by the user.
One alternative to the simple selection/pre-encoded direct response system of Watanabe is to create an executable application which implements behavior based on conditional testing of multiple application variables or inputs. However, an inefficiency inherent in constructing application behavior from conditional program logic is that each potential alternative condition must continually be tested for and operated upon. Some reuse of code is always possible, but generally the code has to be modified to manifest all the variables and the consequences of their values to handle each new special case of behavior. In other words, with reference to the example from Watanabe, the same byte code specified in the Bytecode_Part 150 would have to be incorporated into the conditional program logic, but would be surrounded by code to test for which subset of byte code should be executed. This conditional code must be executed before the ‘operational’ effect can be realized from the core byte code, which leads to inefficiency.
Adding or updating code also presents concerns from the standpoint of program storage, loading time, and data communications bandwidth.
Thus, there is an unmet need in the art for controlling appearance and execution of computer applications without having to create, load, and store code instruction segments to control desired computer behavior in response to changing variables and conditions in which the application operates.
Embodiments of the present invention provide a method, a computer readable medium, a data system for controlling operation of a computer system, or an interactive media control system for efficient control of the operation of a computer, data, or media control system. Desired behaviors in response to changes in state of a system using the present invention are coded in data form, and the data is processed in response to state changes. Accordingly, the present invention advantageously allows for application behaviors to be coded without writing new code. Moreover, behaviorial functions of the system can be controlled or changed by changing the data without changing or loading an entire application. The data suitably takes the form of a state table which governs the operation of programming elements, such as function calls or values being set, in response to state changes without having to create and load conditional code for monitoring every behavior.
More specifically, embodiments of the present invention provide a method and system for controlling computer system operation in response to state changes in the computer system. At least one state table is created, and the state table has a first dimension and a second dimension. At least one programming element is listed along the first dimension and a plurality of states of the computer system are listed along the second dimension. At each intersection of the first dimension and the second dimension is a cell in which an operand is specified for the programming element at each state. For each state change of the computer system, each programming element listed along the first dimension is executed according to the operand listed for a current state.
In accordance with further aspects of the invention, non-null operands are pushed onto a stack from which they are retrieved for processing. In one embodiment, the non-null operands suitably are pushed onto the stack by an execution model, and retrieved and processed by a byte-code interpreter. The programming elements may represent function calls, for which the function is specified as an operand, automatic function calls, or value setting functions to set a value for a program variable. The programming element also can be a code segment of its own, as the state table can be of variable or fixed length. Further, the state table can be subdivided into a state table structure, specifying the programming elements, and a state table file, specifying the operands such that the state table structure and state table file can be changed and loaded separately. Forms of transitions between states for programming elements can be specified with the operands, such as transition types, final states, or transition durations, or a default transition can be used.
The preferred and alternative embodiments of the present invention are described in detail below with reference to the following drawings.
Embodiments of the present invention provide a method and system for controlling computer system operation in response to state changes in the computer system. At least one state table is created, and the state table has a first dimension and a second dimension. At least one programming element is listed along the first dimension and a plurality of states of the computer system are listed along the second dimension. At each intersection of the first dimension and the second dimension is a cell in which an operand is specified for the programming element at each state. For each state change of the computer system, each programming element listed along the first dimension is executed according to the operand listed for a current state.
At intersections of each of the rows 302 and each of the columns 308 after the first column 306 are cells 320 containing operands 322. In each cell 322 is listed an operand for the programming element specified in the first column 306 for that row. Thus, there are n+1 operands 322 specified for each programming element 308 listed in the first column 306 of each row 302, one for each contemplated state, State 0 314 through State n 318. The operands 322 specify an argument needed for the programming element at each of the states 312.
Operation of a system can begin at a non-state (not shown) or with State 0 314. Upon initiating State 0 314 and upon progressing to each state 312, the programming element 308 in each row is executed according to the operand 322 specified in the cell 320 for that programming element 308 at that state 312. In the embodiment shown in
Given by way of non-limiting example, the first programming element 308 listed in the first row 330 of the first column 306 is “Store in Button1.Visible” 324. For the sake of this non-limiting example, a button represents a displayed icon, having a particular position, size, and appearance, which a user of the system, such as a computer or an interactive media control system, can select to direct the system according to his or her desires. The programming element 308 suitably represents an automatic function call, one of a number of suitable programming element types. The “Store in Button1. Visible” programming element accepts two operands 322: “True” 326, as specified at State 0 314 and “False” 328, as specified at State 1 316. As will be appreciated, while the operands “True” 326 and “False” 328 are spelled out, they could be represented by numerical codes, one-byte symbols, and other forms. In response to the True operand 326 and the False operand 328, the programming element 324 causes Button 1 to become visible at State 0 314, but become invisible at State 1 316, respectively. A transition from State 0 314 to State 1 316 may be indicated by expiration of a set time interval, receipt of a state change signal by the system running the state table, a user initiating a state change by pressing a button or otherwise issuing a command, or in other ways. The data table manifested in the state table 300 thus dictates program behavior in response to state changes.
The state table 300, however, need not execute only one row and thus one programming element at a time. The state table 300 suitably causes to be executed each programming element listed for each operand specified for each state. By way of this non-limiting example, for this state table 300 with five rows 302 of programming elements 308, up to five programming elements are executed for each state change, as will be further described. At State 0 314, the first programming element “Store in Button1.Visible” 324 first is executed with the operand “True” 326. Second, the programming element “Integer Value” 330, a value-setting programming element, sets the value to 43. Third, the programming element “Store in Button1.Left” 334, another automatic function call, sets the left-hand position of Button 1 to 100. Fourth, the “Call Math Func( ) with argument” programming element 338 specifies that function Math( ) is executed with the argument 12. Finally, the “Call given function” programming element 340 initiates the function specified by data element 336 at State 0 314, namely “Func12,” which will then be executed. It will be noted that this programming element is a function call that is not an automatic function call as are programming elements 324 and 334. Instead of the programming element 308 specifying the function to be executed, the function to be executed is specified by the operand 336. Using a non-automatic function call advantageously allows for different functions to be executed by the state table for different applications by changing only operands in the state table, without changing the programming elements. As will be described further below, this allows the state table structure to be reused between different applications while changing only the state table data.
Upon the transition to the next state that is State 1 316, the programming elements 308 are executed according to the operand specified for each programming element at this state, with one exception noted in the example. First, “Store in Button1.Visible” 324 is executed with the operand “False” 328, thereby making the button invisible. Second, the programming element “Integer Value” 330 sets the value to 26. This value can be read by program code. Third, the programming element “Store in Button1.Left” 334, this time, is not executed. This is because there is a null operand “NO_CHANGE” specified for the programming element 334 for the current state. When a null operand is specified for a programming element, the programming element is skipped. Therefore, a vast number of programming elements could be specified, even if some of them are seldom used, and the programming elements are merely skipped until transitioning to a state where a non-null operand is specified. Fourth, the “Call Func( ) with argument” programming element 338 calls the function Func( ) with argument 14. Finally, the “Call given function” programming element 340 initiates the function Func2 specified for the programming element 338 at State 1 316.
It will be appreciated that, as the programming elements 308 are executed (or not executed, if a null operand is associated with the programming elements 308 for a current state change), no conditions need to be tested, let alone coded. The desired behaviors are encapsulated in the state table 300 to manifest and control the execution of the system based on the operands coded for each of the programming elements.
It also will be appreciated that transitions between the states can be controlled in a number of ways known to those ordinarily skilled in the art. For example, arguments could be supplied with the operands specifying whether the transition is to be made abruptly, faded in, wiped from one side or the other, or another way. Similarly, the speed of transitions or a duration during which the state change remains in effect could be specified by an argument. Default transition types and durations could be supplied if such arguments are not specified.
For clarity, an extended non-limiting example of the operation of such a state, table-driven system is provided in
An embodiment of the present invention allows this graphical information to be transmitted to a device displaying the program. The changes in information can be keyed to triggers in the program, and interactive opportunities similarly can be created. It will be appreciated that these advantages can be accomplished by modifying a state table, such as the state table 500 shown in
Referring now to
At State 0 520, the programming elements 502 for position of a series of buttons are established to present graphics shown in
At State 1 530, it will be appreciated that all but three of the operands specified for the programming elements are NO_CHANGE null operands. As a result, advantageously these programming elements can be skipped without processing or conditional programming, and thus dealt with very efficiently. More accurately, these programming elements with null operands are not dealt with at all. Accordingly, while great flexibility for adjusting the parameters controlled by these programming values exists in the state table 500, the application need not process them at each step. Therefore, there is great flexibility without continual complexity.
On the other hand, at State 1 530, the values for the “Store in Button1.Visible,” “Store in Button2.Visible,” and “Store in Button1.Visible,” which represent the recipe are changed from “False” to “True,” thereby causing the recipe 404 (
At State 2 540, once again most of the operands for the programming elements are set to NO_CHANGE as the display changes from
At State 3 550, once more most of the operands are NO_CHANGE. The salient changes in the displayed image of
With regard to the “Call given function” programming element, it will be appreciated that instead of a pre-coded function the actual function code could be inserted here so that such features need not be pre-coded. The cells of the state table can be variable in length, including even programming segments that original programmers wanted to leave open or did not foresee.
At State 4 560, more things change on the display than at any other time, thus more programming elements have non-null operands than for any other state since the initial parameters were set at State 0 520. First, to move the recipe 404 (
Finally, at State 5 570, the only change to be manifested is that the recipe 404 once again disappears as shown in
Therefore, because the programming elements do not change, but only the operands to control the same might be encoded, changing the application advantageously does not require the creation and/or transmission of an entirely new state table. Instead, according to the invention the programming elements 308 (
In the state-table driven system 800 shown in
As will be appreciated from
Bandwidth benefits of using the state table driven system 800 can be seen by examining the contrast between
The computer system 1200 receives input from the network 1206 via an input/output controller 1210, which directs signals to and from a video controller 1212, an audio controller 1214, and a central processing unit (CPU) 1216. In the case of a STB, the input/output controller 1210 suitably is a multiplexer for routing video data blocks received from the network 1206 to a video controller 1212 in the nature of a video decoder, audio data blocks to an audio controller 1214 in the nature of an audio decoder, and for routing other data blocks to a CPU 1216 for processing. In turn, the CPU 1216 communicates through a system controller 1218 with input and storage devices such as read only memory (ROM) 1220, system memory 1222, system storage 1224, and input device controller 1226.
The computer system 1200 shown in
While the preferred embodiment of the invention has been illustrated and described, as noted above, many changes can be made without departing from the spirit and scope of the invention. Accordingly, the scope of the invention is not limited by the disclosure of the preferred embodiment. Instead, the invention should be determined entirely by reference to the claims that follow.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5163016 *||Mar 6, 1990||Nov 10, 1992||At&T Bell Laboratories||Analytical development and verification of control-intensive systems|
|US5386464||Dec 19, 1991||Jan 31, 1995||Telefonaktiebolaget L M Ericsson||Feature control system utilizing design oriented state table language|
|US5485600||Nov 9, 1992||Jan 16, 1996||Virtual Prototypes, Inc.||Computer modelling system and method for specifying the behavior of graphical operator interfaces|
|US5509116||Oct 24, 1994||Apr 16, 1996||International Business Machines Corporation||Graphical user interface management system|
|US5537528||Feb 16, 1993||Jul 16, 1996||International Business Machines Corporation||System and method for inputting scene information|
|US5561457||May 26, 1995||Oct 1, 1996||International Business Machines Corporation||Apparatus and method for selectively viewing video information|
|US5596331 *||May 13, 1988||Jan 21, 1997||Lockheed Martin Corporation||Real-time control sequencer with state matrix logic|
|US5604907||Mar 10, 1995||Feb 18, 1997||International Business Machines Corporation||Computer system for executing action slots including multiple action object classes|
|US5680617||May 16, 1994||Oct 21, 1997||Apple Computer, Inc.||Computer-human interface which provides for user customization of object behavior|
|US5724472||May 1, 1995||Mar 3, 1998||Abecassis; Max||Content map for seamlessly skipping a retrieval of a segment of a video|
|US5830193 *||Dec 19, 1994||Nov 3, 1998||Higashikawa; Tetsuro||Syringe|
|US5870727||May 22, 1995||Feb 9, 1999||Gte Data Services Incorporated||Rule-based system for the provision of complex navigational logic|
|US5883670||Aug 2, 1996||Mar 16, 1999||Avid Technology, Inc.||Motion video processing circuit for capture playback and manipulation of digital motion video information on a computer|
|US5903886 *||Apr 29, 1997||May 11, 1999||Smartlynx, Inc.||Hierarchical adaptive state machine for emulating and augmenting software|
|US6088028||Dec 16, 1997||Jul 11, 2000||At&T Corp.||Method for enabling rapid modification of a display controlled by a computer program|
|US6182206 *||Feb 26, 1998||Jan 30, 2001||Ricoh Corporation||Dynamically reconfigurable computing using a processing unit having changeable internal hardware organization|
|US6211872||Oct 19, 1998||Apr 3, 2001||Fujitsu Limited||Apparatus for constructing and operating interactive software|
|US6223347||Sep 11, 1997||Apr 24, 2001||Matsushita Electric Industrial Co., Ltd.||Data display control apparatus|
|US6263339||Aug 25, 1998||Jul 17, 2001||Informix Software, Inc.||Dynamic object visualization and code generation|
|US6467078 *||Jul 1, 1999||Oct 15, 2002||Nec Corporation||Program development system, method for developing programs and storage medium storing programs for development of programs|
|US6628303||Jul 29, 1996||Sep 30, 2003||Avid Technology, Inc.||Graphical user interface for a motion video planning and editing system for a computer|
|DE20116722U1||Oct 11, 2001||Feb 28, 2002||Vjd Av Media B V||Vorrichtung zum Speichern und Abspielen von Bild- und/oder Tonaufnahmen sowie Zusammenstellung einer solchen Vorrichtung und einer Kamera|
|EP0335638A2||Mar 28, 1989||Oct 4, 1989||Digital Equipment Corporation||System for facilitating coordination of activities by a plurality of actors|
|WO2001045391A1||Dec 16, 1999||Jun 21, 2001||Liang Kee Goh||System and method for video production|
|1||*||Schuett, et al., A soft state protocol for accessing mulitmedia archieves, Jul. 1998, NOSSDAV, Dept of EECS, UC, Berkley, pp. 1-11.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7627518 *||May 1, 2006||Dec 1, 2009||Trading Technologies International, Inc.||System and method for event driven virtual workspace|
|US7765143||Nov 4, 2003||Jul 27, 2010||Trading Technologies International, Inc.||System and method for event driven virtual workspace|
|US7788634 *||Sep 3, 2004||Aug 31, 2010||Ensequence, Inc.||Methods and systems for efficient behavior generation in software application development tool|
|US7805361||Oct 14, 2009||Sep 28, 2010||Trading Technologies International, Inc.||System and method for event driven virtual workspace|
|US7953657||Jun 18, 2010||May 31, 2011||Trading Technologies International, Inc.||System and method for event driven virtual workspace|
|US8069111||Apr 21, 2011||Nov 29, 2011||Trading Technologies International, Inc.||System and method for event driven virtual workspace|
|US8392879 *||Oct 6, 2003||Mar 5, 2013||National Instruments Corporation||Parameter assistant for automatically specifying parameter values for a software program|
|US8521641||Oct 19, 2011||Aug 27, 2013||Trading Technologies International, Inc.||System and method for event driven virtual workspace|
|US20050076002 *||Oct 6, 2003||Apr 7, 2005||Patrick Williams||Parameter assistant for automatically specifying parameter values for a software program|
|US20050278537 *||Jun 10, 2004||Dec 15, 2005||Dustin Kirkland||Logging off a user from a website|
|US20060053443 *||Sep 3, 2004||Mar 9, 2006||Acott Troy S||Methods and systems for efficient behavior generation in software application development tool|
|U.S. Classification||717/105, 719/318|
|International Classification||G06F3/00, G06F9/44|
|Cooperative Classification||G06F8/31, G06F9/4443|
|European Classification||G06F8/31, G06F9/44W|
|Jul 14, 2003||AS||Assignment|
Owner name: ENSEQUENCE INC., OREGON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ACOTT, TROY STEVEN;MASON, JOANNA;WALLACE, MICHAEL W.;ANDOTHERS;REEL/FRAME:014272/0419
Effective date: 20030602
|Jun 30, 2006||AS||Assignment|
Owner name: FOX VENTURES 06 LLC, WASHINGTON
Free format text: SECURITY AGREEMENT;ASSIGNOR:ENSEQUENCE, INC.;REEL/FRAME:017869/0001
Effective date: 20060630
|May 14, 2007||AS||Assignment|
Owner name: ENSEQUENCE, INC., OREGON
Free format text: RELEASE OF SECURITY INTEREST;ASSIGNOR:FOX VENTURES 06 LLC;REEL/FRAME:019474/0556
Effective date: 20070410
|Apr 15, 2009||AS||Assignment|
Owner name: CYMI TECHNOLOGIES, LLC, OHIO
Free format text: SECURITY AGREEMENT;ASSIGNOR:ENSEQUENCE, INC.;REEL/FRAME:022542/0967
Effective date: 20090415
|Oct 7, 2009||AS||Assignment|
Owner name: ENSEQUENCE, INC., OREGON
Free format text: ASSIGNMENT AND RELEASE OF INTELLECTUAL PROPERTY SECURITY AGREEMENT;ASSIGNOR:CYMI TECHNOLOGIES, LLC;REEL/FRAME:023337/0001
Effective date: 20090908
|Sep 27, 2010||FPAY||Fee payment|
Year of fee payment: 4
|Oct 12, 2010||AS||Assignment|
Free format text: SECURITY AGREEMENT;ASSIGNOR:ENSEQUENCE, INC.;REEL/FRAME:025126/0178
Owner name: CYMI TECHNOLOGIES, LLC, OHIO
Effective date: 20101011
|Jun 6, 2012||AS||Assignment|
Free format text: ASSIGNMENT OF SECURITY INTEREST;ASSIGNOR:CYMI TECHNOLOGIES, LLC;REEL/FRAME:028332/0066
Effective date: 20120531
Owner name: MYRIAN CAPITAL FUND, LLC (SERIES C), OHIO
|Oct 13, 2014||FPAY||Fee payment|
Year of fee payment: 8