server-based systems and methods for performing tests involving system components which use non-standardized command languages. In one embodiment, the system comprises a set of servers and an httpd user interface, all of which communicate with each other in a standardized format, such as xml. A user enters a script through the httpd user interface, which forwards the script through a central server to a connections/test server. The connections/test server is configured to break the script into its components and to transmit them to the appropriate test equipment (test sets and switches.) servers for each of the of the equipment components include libraries which allow the servers to translate the scripts into commands which are recognized by the equipment. The results generated by the equipment are translated, if necessary, back into the standardized format by the test equipment servers and are forwarded through the central server to the httpd user interface.
|
24. A method for automated equipment testing comprising:
(a)providing as an input to a test system a test script formatted in xml format; (b)parsing the test script into xml script components; (c)forwarding each xml script component to a corresponding test system component; (d)translating each xml script component into equivalent commands in a non-standardized format of the corresponding test system component; and (e)executing each equivalent command in the corresponding test system component.
18. A method for automated equipment testing comprising:
(a)providing as an input to a test system a test script in a first standardized format (b)parsing the test script into script components; (c)forwarding each script component to a corresponding component of the test system; (d)translating each script component into equivalent commands in a non-standardized format of the corresponding component of the test system; and (e)executing each script component in the corresponding component of the test system.
16. A test system employing a server model comprising:
an httpd user interface; one or more servers coupled to the user interface, wherein the one or more servers are configured to communicate with each other in a standardized format; and a plurality of test equipment components, wherein each of the plurality of test equipment components is coupled to a corresponding one of the one or more servers and configured to communicate with the corresponding server in a component-specific format; wherein the user interface is configured to accept user input in the form of xml scripts and to forward the xml scripts to the connections/test server.
9. A test system employing a server model comprising:
a user interface; one or more servers coupled to the user interface, wherein the one or more servers are configured to communicate with the user interface in a standardized format; and a test equipment component coupled to at least one of the one or more servers, wherein the test equipment component is configured to communicate with the at least one of the one or more servers in a non-standardized format specific to the test equipment component; wherein the user interface is configured to accept user input in the form of xml scripts and to forward the xml scripts to the connections/test server.
15. A test system employing a server model comprising:
an httpd user interface; one or more servers coupled to the user interface, wherein the one or more servers are configured to communicate with each other in a standardized format; and a plurality of test equipment components, wherein each of the plurality of test equipment components is coupled to a corresponding one of the one or more servers and configured to communicate with the corresponding server in a component-specific format; wherein the one or more servers comprises a library configured to enable the conversion of scripts in the standardized format into commands in the non-standardized format specific to the test equipment component.
8. A test system employing a server model comprising:
a user interface; one or more servers coupled to the user interface, wherein the one or more servers are configured to communicate with the user interface in a standardized format; and a test equipment component coupled to at least one of the one or more servers, wherein the test equipment component is configured to communicate with the at least one of the one or more servers in a non-standardized format specific to the test equipment component; wherein one of the one or more servers comprises a library configured to enable the conversion of scripts in the standardized format into commands in the non-standardized format specific to the test equipment component.
6. A test system employing a server model comprising:
a user interface; one or more servers coupled to the user interface, wherein the one or more servers are configured to communicate with the user interface in a standardized format; and a test equipment component coupled to at least one of the one or more servers, wherein the test equipment component is configured to communicate with the at least one of the one or more servers in a non-standardized format specific to the test equipment component; wherein the one or more servers comprise a connections/test server, wherein the connections/test server is configured to parse the user input into commands and determine a test equipment component corresponding to each command, wherein the connections/test server is configured to forward each command to the corresponding test equipment component.
12. A test system employing a server model comprising:
an httpd user interface; one or more servers coupled to the user interface, wherein the one or more servers are configured to communicate with each other in a standardized format; and a plurality of test equipment components, wherein each of the plurality of test equipment components is coupled to a corresponding one of the one or more servers and configured to communicate with the corresponding server in a component-specific format; wherein the user interface is configured to provide scripts to the servers corresponding to the test equipment components and wherein each of the servers corresponding to one of the test equipment components is configured to generate one or more commands corresponding to the scripts and to forward the commands to the test equipment component, wherein the commands are in the non-standardized format specific to the corresponding test equipment component.
1. A test system employing a server model comprising:
a user interface; one or more servers coupled to the user interface, wherein the one or more servers are configured to communicate with the user interface in a standardized format; and a test equipment component coupled to at least one of the one or more servers, wherein the test equipment component is configured to communicate with the at least one of the one or more servers in a non-standardized format specific to the test equipment component; wherein the one or more servers comprise a connections/test server and a test equipment component server, wherein the user interface is configured to provide scripts to the connections/test server, and wherein the connections/test server is configured to transmit commands in the standardized format to the test equipment component server, and wherein the test equipment component server is configured to generate one or more commands in the non-standardized format to the test equipment component, wherein the non-standardized format is specific to the test equipment component.
2. The system of
3. The system of
4. The system of
5. The system of
7. The system of
10. The system of
11. The system of
13. The system of
14. The system of
17. The system of
20. The method of
21. The method of
22. The method of
23. The method of
25. The method of
26. The method of
27. The method of
28. The method of
|
1. Field of the Invention
The present invention relates generally to test equipment and more particularly to improved systems and methods for automated testing of equipment such as optical networking components using server-based XML.
2. Description of Related Art
Testing is an integral part of the processes for designing and manufacturing equipment of any sort. In order to improve the efficiency of these processes, testing is often automated. Specialized test equipment, and sometimes specialized test software is developed to enable the automation of the test processes.
One example of an automated test environment relates to high-speed optical network testing. Obviously, network component designs have to be tested to ensure that they have the proper functionality. In the case of high-speed optical network testing, this functionality generally involves the generation of a known pattern of data traffic and transmitting this traffic through the system. The system's performance in response to the generated traffic can then be analyzed.
As indicated above, test systems may employ equipment and/or software which is specially developed for a particular component of the test system. In the field of high-speed optical networks, each component may be designed to respond to a customized set of commands which are presented in a particular format. Each of the components must, of course, be addressed using the particular commands which it recognizes.
In the high-speed optical network environment, testing is typically accomplished using a set of interconnected servers through which a user communicates tasks to the components of the system under test. The servers may include, for example, an httpd interface through which the user provides input in the form of a script, a scripter which is configured to interpret and execute the script and to generate component-specific commands which can be executed by the components of the network, a connections language handler which is configured to set up any connections which must be made prior to the execution of the test set commands, a starter which is configured to monitor the servers and a message handler which is configured to route all of the message traffic and between the different servers. (These servers are in addition to the test set and optical switch which are controlled by the servers.)
One of the problems with these prior art automated testing systems is that there is little, if any, consistency between components. In other words, each component typically has its own set of commands and its own scripting format, so a single test script generally cannot be used to test several different components. When it is desired to run a particular task on a particular component, a shell script has to be written for that task/component combination, and the user interface to the component must be modified as well. If it is desired to modify a test sequence for each of several components, the scripts for each of the components must be separately modified--the modification is not made to a single, common test script.
As a result of the inconsistencies between the commands and scripting formats of the different components, the development of testing solutions is a difficult task. Setting up the test system is a time-consuming process which prevents rapid development of these systems. Further, when it is necessary to modify the testing performed by the system, modifications must be made to the scripts for each of the affected components, as well as the servers which handle these scripts. Consequently, prior art test systems are difficult to maintain.
It would therefore be desirable to provide systems and methods for automated testing which use a consistent format to test a range of components, thereby decreasing the time and effort required to set up, maintain or modify the test system.
One or more of the problems outlined above may be solved by the various embodiments of the invention. Broadly speaking, the invention comprises systems and methods for performing tests on a test system, wherein the system components employ non-standardized command languages.
In one embodiment, the system comprises a set of servers and a user interface, all of which communicate with each other in a standardized format. The user interface may comprise an httpd server. The standardized format may, for example, comprise XML. The servers include a connections/test server which is configured to parse scripts which are provided by a user through the user interface. The connections/test server is further configured to forward the parsed scripts, through a central server, to servers corresponding to components of the system under test. The servers corresponding to the components of the test system are configured to translate the parsed scripts into commands in a non-standardized formats corresponding to the respective components of the test system. These commands are then executed by the respective components of the test system, potentially generating results which our sent back to the servers for the corresponding test system components. These servers translate the results into the standardized format and forward them to the user interface.
Another embodiment of the present invention comprises a method. In this method, a user enters a script through the (httpd) user interface. The user interface forwards the script through a central server (a master process server) to a connections/test server. The connections/test server is configured to break the script into its components and to initiate execution of the script. In the initial stages of execution, the connections/test server establishes the appropriate connections between the test equipment by sending individual connection scripts to servers for each of the components of the equipment. These servers include libraries which allow the servers to translate the scripts into commands which are recognized by the equipment itself. After the connections have been established, the connections/test server goes through the remainder of the script and forwards the script commands to the servers for the appropriate components of the equipment. These servers translate the script commands into the local command language and forward them to the corresponding equipment components. The results generated by the equipment are translated, if necessary, back into the standardized format by the test equipment servers and are forwarded through the central server to the httpd user interface.
Numerous other embodiments are also possible.
Other objects and advantages of the invention may become apparent upon reading the following detailed description and upon reference to the accompanying drawings.
While the invention is subject to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and the accompanying detailed description. It should be understood, however, that the drawings and detailed description are not intended to limit the invention to the particular embodiment which is described. This disclosure is instead intended to cover all modifications, equivalents and alternatives falling within the scope of the present invention as defined by the appended claims.
A preferred embodiment of the invention is described below. It should be noted that this and any other embodiments described below are exemplary and are intended to be illustrative of the invention rather than limiting.
Broadly speaking, the invention comprises server-based systems and methods for performing tests involving system components which use non-standardized command languages. In one embodiment, the system comprises a set of servers and an httpd user interface, all of which communicate with each other in a standardized format, such as XML. A user enters a script through the httpd user interface. The user interface forwards the script through a central server (a master process server) to a connections/test server. The connections/test server is configured to break the script into its components and to initiate execution of the script. In the initial stages of execution, the connections/test server establishes the appropriate connections between the test equipment by sending individual connection scripts to servers for each of the components of the equipment. These servers include libraries which allow the servers to translate the scripts into commands which are recognized by the equipment itself. After the connections have been established, the connections/test server goes through the remainder of the script and forwards the script commands to the servers for the appropriate components of the equipment. These servers translate the script commands into the local command language and forward them to the corresponding equipment components. The results generated by the equipment are translated, if necessary, back into the standardized format by the test equipment servers and are forwarded through the central server to the httpd user interface.
The various embodiments of the invention provide a convenient means to perform system testing using a unified format for the scripting and test mechanisms. The ease of testing may be improved by overcoming a number of problems, such as having to be familiar with the specialized command languages of each individual equipment component, and having to modify both the equipment component library and central CGI when the components and/or test capabilities of the components change. A user should have to write no low-level code to accomplish the same tasks.
It may aid in understanding of the invention to the first consider the structure and drawbacks of the conventional systems and methods.
Prior art test systems use what may be referred to as a datagram methodology to implement testing of high-speed optical networks. Referring to
httpd user interface 11; message handler 12; connections language handler 13;
scripter 14; starter 15; switch 16; and test set 17.
The flow of data between the components illustrated in
Starter 15 is configured to start all of the other processes in the system. It is also configured to monitor each of these processes. The data transmitted between starter 15 and the other components is indicated by the dashed arrows.
Message handler 12 is configured to pass messages from a one node to another. These messages are communicated in the form of custom datagram packets. As indicated above, data communicated to and from message handler 12 is indicated by the un-numbered, solid, single-segment lines.
Httpd user interface 11 is configured to pass a connection string to connections language handler 13. This data is passed from user interface 11 to message handler 12, which in turn forwards the message to connections language handler 13. This data path is indicated by reference numerals 23a and 23b. User interface 11 is also configured to transmit a test script to scripter 14. Again, this data is transmitted first to message handler 12, and is then forwarded to scripter 14. This data path is indicated by reference numerals 24a and 24b.
Scripter 14 is configured to pass commands which are generated from the test script to switch 16 and test set 17. The data paths for the transfer of this information are indicated by reference numerals 25a, 25b and 25c. (The path from scripter 14 to switch 16 comprises segments 25a and 25c, while the path from scripter 14 to test set 17 comprises segments 25a and 25b.) The scripter is capable of distributing segments of code to sub-components, re-interpreting it in languages appropriate for the sub-components if necessary. The scripter also executes code specifically intended for the scripter, performing higher level data functions, including much of the logic behind tests, data comparisons and tracking, and data recording.
Connections language handler 13 is configured to interpret a connection portion of the test script and to generate instructions before for scripter 14 to make the appropriate connections. These instructions are transmitted via the path indicated by reference numerals 26a and 26b.
Referring to
ingress_endpoint <connection parameters> egress_endpoint
The httpd interface then transmits the script via the message handler to the connections language handler. The connections language handler then decodes the connection description embodied in this connection script and generates appropriate scripts to establish the connection. These scripts may look something like the examples below.
[endpoint_script] | |||
testset::set_mode(ingress_endpoint, mode); | |||
testset::generator on; | |||
switch::connect( ) | [switch_script] | ||
[endpoint_script] | |||
testset::set_mode(egress_endpoint, mode); | |||
testset::generator on; | |||
There is one script for each end point test set and one script for the switch connection. The connections language handler then transmits each of the scripts which it has generated via the message handler to the scripter. The scripter executes each of the scripts received from the connections language handler. As each script is executed by the scripter, it generates corresponding commands which it sends to the appropriate test set or switch. These commands are, of course, transmitted via the message handler. The necessary connections are thereby established.
After the connections are established, the user enters a test script into the httpd user interface. The script may look something like the following example.
testset::reset_pm(egress_endpoint);
testset::analyzer_on(egress_endpoint);
sleep(10);
$retval=testset::analyzer_off(egress_endpoint);
return("fail") if ($retval==undef);
This script is sent via the message handler to the scripter. The scripter parses the script and checks it. Again, the scripter generates commands corresponding to the test script for the respective test sets or switches and forwards them via the message handler to the appropriate destination components. The test sets and/or switches receive the commands from the scripter and execute them. The output resulting from the execution of these commands is transmitted via the message handler back to the scripter. The scripter then forwards this information through the message handler to the httpd user interface.
Referring to
Conventional systems typically employ very well formed languages which may describe which nodes are involved in testing, which test sets are used, what the traffic parameters are, what policing is used, which different bits should be set, and so on. The format of the language may be very distinct, or even inconsistent. One of the problems with these well formed languages is that it may take months to write to the original server applications (e.g., a parser) and weeks to make any modifications to them. It is important to be able to accomplish the same functions using a very standard format.
The present systems and methods differ from the prior art in several ways. For example, they are based on a server model, rather than employing the datagram methodology of prior art systems. The present systems and methods are also based on the use of a uniform protocol for most communications. In a preferred embodiment, HTTP is used. (Although the servers communicate in a standardized format, the servers themselves may be written to use any suitable protocol, e.g., SMTP, SNMP, etc.) The use of a common communication format allows the same logic to be used to control the scripting and connection mechanisms. This minimizes the time and expense of setting up, maintaining or modifying a test system.
Referring to
The flow of data between the components is illustrated in
Httpd user interface 41 comprises a Web server and a set of CGIs. This interface enables the user to access any of the equipment interfaces in the system (e.g., the master process server 42, the test set 44, . . . ) More particularly, interface 41 is configured to receive user input in the form of a script which defines the connections to be established and the subsequent tests to be performed. Interface 41 is configured to transmit the script to the connections/test server via the master process server.
A CGI (Common Gateway Interface) or CGI program is a program which is run on a web server and is designed to transfer data (which is potentially dynamic) to or from the web server. The program can be written in any programming language, including C, Perl, Java, Visual Basic or others. CGIs are commonly used to allow web servers to interact dynamically with users.
Master process server 42 comprises a simple CGI which essentially serves as a wrapper around the libraries for the other equipment (e.g., the test set.) Master process server 42 is configured to forward scripts from the httpd user interface to the connections/test server, and to forward/translate commands originating with the connections/test server to the test sets and switches.
Connections/test server 43 comprises a CGI which is configured to parse test scripts, transmit code objects to other servers and execute data operations. Connections/test server 43 receives scripts (having connection and test portions) from the httpd user interface and parses these scripts. It then generates commands for the other servers and transmits the commands, via the user interface and the master process server, to the appropriate servers. Both the original script and the commands generated by the connections/test server are in standardized formats. The commands are translated into the non-standardized syntax of the respective test sets and/or switches by the corresponding libraries.
Test set 44 comprises a library corresponding to the test set equipment. This library controls the equipment and is configured to translate the commands which are received from the connections/test server (via the user interface and master process server) and a standardized format into commands in the non-standardized format of the test equipment.
Switch 45, similar to test set 44, comprises a library corresponding to the switch equipment. This library is configured to translate the standardized connection commands which are received from the connections/test server into the non-standardized commands which are recognized by the switch equipment.
Referring to
<ctx>
<connection alias george>
<adtech port=1 slot=2>
<ingress><egress>
</adtech>
</connection>
<test>
<make_connection george>
<generator on>
<wait 10>
<generator off>
<compare>
</test>
Httpd user interface 41 transmits the script to connections/test server 43 via master process server 42. Connections/test server 43 parses the script into its component parts. Connections/test server 43 then begins to send out commands according to the test script (the <test> block.) When it reaches the <make_connection> command, connections/test server 43 retrieves the <testset> and <switch> blocks of the <connection> block of the script (which had previously been stored) and sends each part to its respective server (i.e., the <testset> block to test set 44 and the <switch> block to switch 45.) These commands are routed through httpd user interface 41 and master process server 42 to the respective servers. Each of the test set and switch servers (44 and 45) then executes the corresponding commands. This process is repeated for the remainder of the <test> block.
Referring to
It should be noted that, while a given test configuration may include additional components (e.g., other switches, test sets or devices under test,) only two are shown in
The present systems and methods may provide a number of benefits. For example, when a component of the tested equipment is changed, or when its capabilities change, it is not necessary to rewrite everything from end to end. The present systems and methods play off of the similarities which exist in the test structure and utilize the same test script for different components. Consequently, a change in components or capabilities typically requires a change only to the corresponding test set library.
While the present invention has been described with reference to particular embodiments, it should be understood that the embodiments are illustrative and that the scope of the invention is not limited to these embodiments. Many variations, modifications, additions and improvements to the embodiments described above are possible. It is contemplated that these variations, modifications, additions and improvements fall within the scope of the invention as detailed within the following claims.
Patent | Priority | Assignee | Title |
11003571, | Apr 05 2019 | Oracle International Corporation | Customizable enterprise automation test framework |
11436126, | Apr 05 2019 | Oracle International Corporation | Customizable enterprise automation test framework |
6772083, | Sep 03 2002 | SAP SE | Computer program test configurations with data containers and test scripts |
6959329, | May 15 2002 | ServiceNow, Inc; International Business Machines Corporation | System and method for transforming configuration commands |
6961937, | Jul 11 2001 | Oracle America, Inc | Registry service for use in a distributed processing framework system and methods for implementing the same |
7054946, | Dec 06 2000 | Daedalus Blue LLC | Dynamic configuration of network devices to enable data transfers |
7065562, | Nov 26 2001 | International Business Machines Corporation | System and method for generating a representation of a configuration schema |
7114159, | Jul 11 2001 | Oracle America, Inc | Processing resource for use in a distributed processing framework system and methods for implementing the same |
7124401, | Sep 03 2002 | SAP SE | Testing versions of applications |
7127641, | Mar 29 2002 | Intellectual Ventures II LLC | System and method for software testing with extensible markup language and extensible stylesheet language |
7150037, | Mar 21 2001 | International Business Machines Corporation | Network configuration manager |
7165256, | Sep 11 2001 | Oracle America, Inc | Task grouping in a distributed processing framework system and methods for implementing the same |
7210066, | Dec 31 2002 | Oracle America, Inc | Method and system for determining computer software test coverage |
7219278, | Mar 08 2004 | MORGAN STANLEY SENIOR FUNDING, INC | Configurator arrangement and approach therefor |
7237014, | Aug 01 2002 | DRUMMOND GROUP, LLC | System and method for in situ, real-time, supply chain, interoperability verification |
7243137, | Sep 28 2001 | Oracle America, Inc | Remote system controller and data center and methods for implementing the same |
7249170, | Dec 06 2000 | FOCUS GLOBAL SOLUTIONS LLC | System and method for configuration, management and monitoring of network resources |
7305659, | Sep 03 2002 | SAP SE | Handling parameters in test scripts for computer program applications |
7366893, | Aug 07 2002 | International Business Machines Corporation | Method and apparatus for protecting a network from attack |
7421621, | Sep 19 2003 | MATADOR TECHNOLOGIES CORP | Application integration testing |
7426729, | Jul 11 2001 | Oracle America, Inc | Distributed processing framework system |
7454660, | Oct 13 2003 | SAP SE | System and method for testing applications at the business layer |
7464145, | Jul 11 2002 | International Business Machines Corporation | Repository-independent system and method for asset management and reconciliation |
7558847, | Sep 13 2002 | International Business Machines Corporation | System and method for mapping between and controlling different device abstractions |
7650396, | Dec 06 2000 | FOCUS GLOBAL SOLUTIONS LLC | System and method for defining a policy enabled network |
7681079, | Feb 26 2007 | Oracle International Corporation | Diagnostic test sets |
7698694, | Jun 08 2005 | Cisco Technology, Inc. | Methods and systems for transforming an AND/OR command tree into a command data model |
7779398, | Jun 08 2005 | Cisco Technology, Inc. | Methods and systems for extracting information from computer code |
7784036, | Jun 08 2005 | Cisco Technology, Inc. | Methods and systems for transforming a parse graph into an and/or command tree |
7831635, | Aug 26 2005 | MICRO FOCUS LLC | Collecting information at a remote site |
7895576, | Nov 10 2006 | International Business Machines Corporation | Method for automating internationalization software testing |
7908594, | Jul 29 2005 | Cisco Systems, Inc | External programmatic interface for IOS CLI compliant routers |
7953886, | Jul 08 2005 | Cisco Systems, Inc | Method and system of receiving and translating CLI command data within a routing system |
8024206, | Aug 30 2001 | Mercury Kingdom Assets Limited | Travel |
8103913, | Sep 19 2003 | Matador Technologies Corp. | Application integration testing |
8214421, | Jun 17 2002 | International Business Machines Corporation | Conformance testing without reference implementation of an XML standard |
8219662, | Dec 06 2000 | Daedalus Blue LLC | Redirecting data generated by network devices |
8296400, | Aug 29 2001 | International Business Machines Corporation | System and method for generating a configuration schema |
8751946, | Apr 05 2006 | International Business Machines Corporation | Enhanced display of properties for a program object |
8812556, | Apr 06 2006 | International Business Machines Corporation | Storing modification data for recreating modifications |
8898523, | Aug 31 2009 | Red Hat, Inc. | Generating imperative test tasks from declarative test instructions |
8966314, | Aug 31 2009 | Red Hat, Inc. | Declarative test result validation |
9760567, | Oct 21 2013 | CA, Inc.; CA, INC | Method and apparatus for using a common dialect for testing on multiple execution interfaces |
Patent | Priority | Assignee | Title |
6249886, | Oct 17 1997 | Computer system and computer implemented process for performing user-defined tests of a client-server system with run time compilation of test results | |
6269330, | Oct 07 1997 | Cisco Technology, Inc | Fault location and performance testing of communication networks |
6304982, | Jul 14 1998 | Autodesk, Inc. | Network distributed automated testing system |
6446120, | Nov 26 1997 | International Business Machines Corporation | Configurable stresser for a web server |
6457143, | Sep 30 1999 | International Business Machines Corporation | System and method for automatic identification of bottlenecks in a network |
6490690, | Jul 22 1999 | International Business Machines Corporation | Method and apparatus for unix system catastrophic recovery aid |
6510402, | Feb 04 1999 | International Business Machines Corporation | Component testing with a client system in an integrated test environment network |
6565609, | Jun 15 1999 | ZHIGU HOLDINGS LIMITED | Translating data into HTML while retaining formatting and functionality for returning the translated data to a parent application |
20020144187, | |||
20030078678, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
May 17 2001 | ANDREW ROBERTSON | Yotta Networks | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 011656 | /0376 | |
Jun 12 2001 | Yotta Networks | (assignment on the face of the patent) | / | |||
Sep 26 2002 | YOTTA NETWORKS, INC | Lighthouse Capital Partners IV, LP | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 016016 | /0005 | |
Sep 26 2002 | Lighthouse Capital Partners IV, LP | Yotta Networks, LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 018787 | /0225 | |
Sep 21 2007 | Yotta Networks, LLC | YT Networks Capital, LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 019965 | /0880 | |
Aug 12 2015 | YT Networks Capital, LLC | S AQUA SEMICONDUCTOR, LLC | MERGER SEE DOCUMENT FOR DETAILS | 036872 | /0774 | |
Dec 22 2022 | S AQUA SEMICONDUCTOR, LLC | INTELLECTUAL VENTURES ASSETS 191 LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 062666 | /0716 | |
Feb 14 2023 | MIND FUSION, LLC | INTELLECTUAL VENTURES ASSETS 191 LLC | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 063295 | /0001 | |
Feb 14 2023 | MIND FUSION, LLC | INTELLECTUAL VENTURES ASSETS 186 LLC | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 063295 | /0001 | |
Feb 14 2023 | INTELLECTUAL VENTURES ASSETS 191 LLC | MIND FUSION, LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 064270 | /0685 | |
Mar 26 2024 | MIND FUSION, LLC | FINTEGRAPH, LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 066912 | /0311 |
Date | Maintenance Fee Events |
Jun 01 2007 | LTOS: Pat Holder Claims Small Entity Status. |
Aug 13 2007 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Aug 17 2007 | STOL: Pat Hldr no Longer Claims Small Ent Stat |
Aug 20 2007 | R2551: Refund - Payment of Maintenance Fee, 4th Yr, Small Entity. |
Jul 21 2011 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Jul 28 2015 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Feb 24 2007 | 4 years fee payment window open |
Aug 24 2007 | 6 months grace period start (w surcharge) |
Feb 24 2008 | patent expiry (for year 4) |
Feb 24 2010 | 2 years to revive unintentionally abandoned end. (for year 4) |
Feb 24 2011 | 8 years fee payment window open |
Aug 24 2011 | 6 months grace period start (w surcharge) |
Feb 24 2012 | patent expiry (for year 8) |
Feb 24 2014 | 2 years to revive unintentionally abandoned end. (for year 8) |
Feb 24 2015 | 12 years fee payment window open |
Aug 24 2015 | 6 months grace period start (w surcharge) |
Feb 24 2016 | patent expiry (for year 12) |
Feb 24 2018 | 2 years to revive unintentionally abandoned end. (for year 12) |