Back to Patent's Contents
Before proceeding to the state machine description, there are several aspects of the preferred embodiment that need to be described in order to fully disclose what the inventor believes to be the best mode of the present invention. First, modified data tag bits in attribute bytes transmitted by the application are turned off by the preferred embodiment before the attributes are transmitted (if they are transmitted) to the terminal device. This prevents the terminal from consuming transmission capacity sending back data for unmodified fields over the link that connects the terminal and the host. The command string representation keeps track of the fact that the modified data tags have been set by the application and, when inbound data is received from the terminal, will construct strings locally that are transmitted to the application to conform to what the application expects. Thus, the preferred embodiment internally handles the transmission of the contents of unmodified fields back to the application as a result of MDTs set by the application.
Additionally, the preferred embodiment keeps track of the reset MDT bits flag of the write control characters transmitted by the application and takes appropriate action on the modified data tags it maintains in its CSR.
There are a few slight differences between native 3270 command language that could actually be transmitted to a terminal controller device and the commands that are maintained as part of the command string representation CSR. These differences are simple to modify into true native 3270 command language and indeed, the preferred embodiment includes a routine for doing so in order to allow the preferred embodiment to quickly recreate the display of one terminal on the screen of another.
As is known to those skilled in the art, in 3270 commands, the two highest order bits of the attribute bytes are not used to define part of the screen attribute. In the physical devices sold by International Business Machines, the value of these bits is dependent upon the value of the remaining six bits in the attribute byte. The preferred embodiment of the present invention uses these to indicate whether or not the attribute in the expected state command string (ESC) has actually been written to the screen buffer. This is accomplished in the following manner. Depending on whether the erase/write or write output is chosen (which is not known until after all three output objects have been created) the start field or start field extended orders may or may not be present in the actual screen buffer at the terminal. The preferred embodiment uses the two undefined bits for the purpose of indicating whether the attribute has been physically written to the buffer. The program maintains a variable that indicates whether the E/W object or the WRT object was the last one sent to the physical screen. The high order bit is set when the start field or start field extended order is not written to the E/W output object as a result of the analysis and merger. The next to the highest order bit is set if the SF or SFE order is not written to the WRT object as a result of the merger and analysis.
If, when processing the next CCS, data needs to be written to this field, the combination of the variable indicating which of the two output objects was last transmitted can be logically combined with these two bits of the attribute byte for this order to determine whether the order was actually transmitted to the screen buffer. If the last command was E/W and the highest order bit is set, the field is not on the screen. Likewise, if the next to highest bit is set and the last output object chosen was the WRT string, the field is also not on the screen.
Therefore, if data is being written to this field as a result of the currently processed CCS, this buffer order needs to be included in the string that is transmitted. Therefore, while it is not known on the current pass which of the two output objects (E/W or WRT) will be sent the two highest order bits of the attribute are used to store information that, together with the after the fact information on which one was sent is used to determine whether a needed start field or start field extended order has been previously sent to the buffer.
An example will serve to illustrate the operation of this feature. Consider the sequence of application outputs, outputs from the compressor to the screen and the new expected state command strings (ESC) shown in the following Table 1.
|PROT||data-a||data-b||Output from compressor|
|PROT||data-a||PROTX||data-b||New Expected State Command String (ESC)|
|UNPR||PROT||Output from compressor|
|UNPR||data-a||PROT||data-b||New Expected State Command String (ESC)|
|PROT||Output from compressor|
|PROT||data-a||PROT||data-b||New Expected State Command String (ESC)|
This illustrates orders for protecting and unprotecting two contiguous fields in a terminal buffer. The first output from the application is a protect order followed by Data-A and another protect order for a contiguous field followed by Data-B. The compressor of the preferred embodiment outputs the command that sends a protect order and then Data-A and Data-B in contiguous addresses since the single protect order protects both field spaces on the screen. The indication "PROTX" for the second field and the ECS indicates that one of the two high bits of the attribute character has been set on then the representation of this order in the ESC to indicate that it is logically present so far as the application is concerned, but has not actually been written to the terminal buffer.
The next group in Table 1 shows a command from the application to unprotect the first field followed by a repeat of the transmission of Data-A. It also repeats the protect order and Data-B transmission from its previous output. The output of the compressor notes that the data in the two fields is unchanged and therefore, outputs only the unprotect order and the protect order. Note that the protect order is necessary in the output from the compressor program because its command string representation notes that the protect order represented by PROTX in the CSR has not actually been transmitted. It must now be transmitted so that the unintended result of unprotecting both fields is not accomplished.
After this, the representation of the order in the second field has the high bits cleared to indicate that the protect order has actually been sent to the terminal buffer.
The third output from the application in Table 1 repeats that of the first. Compressor notes that now all it needs to do is send a protect order for the first field since the data is redundant and the order to protect Data-B and rewrite same is redundant of the current actual contents of the screen buffer. Again, the ECS after the third output has the high bits cleared to maintain the representation in the ECS (and thus, the CSR) that the protect order is actually in the terminal's buffer.
In a manner similar to the way it keeps track of orders that may or may not be present in the terminal buffer, the preferred embodiment likewise keeps track of differences between what has actually been sent to the terminal buffer and what is was asked to send to the terminal buffer in its command string representation. Therefore, three characters have been created that are used in the command string representation which are not part of the character set used by the 3270 terminal devices. This is the other difference between native 3270 language commands and how commands are stored in the command string representation of the buffer contents.
In particular, the inventor of the present invention has defined three new characters for hexadecimal values that are not defined as characters in the 3270 character set, namely, hexadecimal values 01, 02, and 03. These characters, and their use are defined in the followingTable 2.
|Character in CSR||Pseudo-Character Name||On Screen after WRT||Application Expects|
Note that all of this subject deals with areas of the screen that are blank to the user. These may correspond to buffer addresses that contain either spaces or nulls, but both of these appear as blanks to the screen viewer. However, those skilled in the art know that the 3270 terminal responds differently when, for example, inserting data into a field, depending on whether the addresses that generate blank portions of the field on the screen are filled with nulls or spaces. Thus, them are many situations in which proper operation of the application requires the application have knowledge of whether nulls or blanks are actually in certain fields of the buffer.
In Table 2, the column labeled "On Screen After WRT" indicates what characters are actually in the screen buffer that are represented by the pseudo-character in the CSR shown in the table. These characters are on the screen only as results of WRT objects being transmitted to the buffer. When the erase/write string is transmitted to the buffer, all pseudo-characters in the CSR correspond to nulls that are physically loaded into the screen buffer.
|PROT||Output from Compressor - WRT|
|PROT||ms||ms||ms||ms||ms||New Expected State Command String (ESC)|
|UNPR||sp||sp||sp||sp||sp||Output from Compressor - WRT|
|UNPR||sp||sp||sp||sp||sp||New Expected State Command String (ESC)|
|PROT||Output from Compressor - WRT|
|PROT||sp||sp||sp||sp||sp||New Expected State Command String (ESC)|
|UNPR||Output from Compressor - WRT|
|UNPR||ps||ps||ps||ps||ps||New Expected State Command String (ESC)|
An example of these pseudo-characters is shown in Table 3, which represents a sequence of four writes to the screen. First, assume initial conditions of a screen buffer that has been reset to nulls. The first application output is an order to define a protected field and a transmission of five spaces. The output from the compressor simply transmits the protect order and does not transmit the spaces, as they are not needed in order to have the screen display conform to what the application expects the user to see. From the fact that there is nothing in the previous command string representation for the screen location, the program implementing the preferred embodiment knows that nulls are at these locations and writes to its ESC output object the protect order and five occurrences of the pseudo character hex (01), i.e., the missing-space character.
On the next screen write, the application indicates that the field should be unprotected and transmits five spaces. Since the CSR on this pass indicates that missing spaces are located in this field, it knows that nulls are actually in the screen buffer and the application expects spaces. Since response of the terminal to typing in the field, now that it is unprotected, can be different for nulls and spaces, the output from the preferred embodiment is both the unprotect order and a transmission of the spaces as data. The ESC output object, which will become the CSR on a subsequent pass, now indicates true spaces.
The next output from the application again protects the field and sends the five spaces. The single pass compressor of the present invention detects the existing spaces and thus, only sends the protect order as its output, as indicated in the third cluster on Table 3. The ESC output object now includes pseudo spaces that indicates, for further processing, that spaces were actually received from the output that were not transmitted to the screen buffer on the last write command.
On the last application output, an unprotect order is sent together with five spaces. The preferred embodiment detects the pseudo spaces in the CSR and knows that these correspond to real spaces in the screen buffer. Therefore, only the unprotect order is sent by the write command and the presence of an indication of true spaces on the screen is reestablished in the ESC output object.
This method of maintaining a record of the differences between what actually appears in a terminal screen buffer and what an application thinks it has written to the screen buffer is also used sending appropriate responses back to the application over the path of communication links 30, 37, 36, 32, 31, and 27 as shown in Fig. 2B. Recall that the method of the preferred embodiment strips all modified data tags set by an application and maintains a record of these in the command string representation. When the MDTs have been set by the application for a field that includes pseudo-characters, the preferred embodiment inserts the actual character from the right hand column shown in Table 2 when returning data to the application.
For example, assume that the first application output shown in Table 3 had been sent by the application to a particular field in a screen buffer and further assume that the modified data tag for that field had been set by the application. Upon the receipt of data back from the terminal indicating that one of the terminal interrupt keys had been depressed, the preferred embodiment would note the setting of the modified data tag in the attribute bit for that field, as represented in the command string representation maintained by the program.
Noting that, in the example, five missing space characters appear in this field, the program implementing the preferred embodiment inserts five space characters and returns these to the application. Therefore, the modified data tags have never been physically transmitted to the terminal buffer. Likewise, the five spaces originally output by the application (first line, Table 3) were not transmitted outbound, and were not retransmitted inbound over the data link connecting the host and the terminal buffer under consideration.
The foregoing has been a disclosure of the method of the preferred embodiment of the present invention for implementing a single pass data compressor for use with a command driven terminal that effectively minimizes the amount of data that physically travels over the physical host-to-terminal link and does so with significantly reduced host CPU processing time as compared to the prior art. Additionally, the preferred embodiment's method of maintaining information about the difference between the data actually loaded in the buffer and what the application should expect to be loaded in the buffer, as well as how certain inbound data is expanded when provided back to the host, has also been disclosed.
This portion of the disclosure shows additional details of what the inventor believes to be the best mode of the data compression method invention described herein as well as disclosing an underlying more general invention of a novel method of representing and implementing an algorithmic state machine. The balance of this specification describes this particular implementation for two bodies of code previously described and shown in Fig. 4. From the disclosure of this particular implementation, similar implementations for the remaining blocks of code shown in Fig. 4 may be created by those skilled in the art.
In particular, the novel state machine implementation for what is indicated as the state 0 tests in Fig. 4 are shown as well as the implementation of the state 100 state submachine.
The method of representing and implementing a state machine described herein is as follows. It is preferable, although not necessary, to create a conventional state tree diagram such as those shown in Figures 6 and 7. Then, a state table such as those shown in Tables 4 and 5 is created. Consider for a moment the state diagram of Fig. 6 and its corresponding state table shown in the following Table 4.
|State Table From State 000|
|State Table From State 100|
the states are represented by the numbered circular nodes. Circular terminating nodes with
a left pointing arrowheads thereon represent branches to other states. Thus, they are used
for a convenient notation of some state transitions. The path extending from each state
node contains the name of a procedure and the name of a test. If one or the other is
missing, it simply means that no procedure or test is required when the machine is in that
The terminology used in the this description and the notation on the drawings will be described in connection with this figure and table. On
The procedure causes a particular thing to be done by the computer implementing the state machine and the test tests for certain conditions that determine the next state to which the machine moves. Therefore, in thinking of the conventional model of an algorithmic state machine, the results of the call of the particular procedure at any state, and the results of the test, may be thought of as the input to the state machine such that the next state is a function of the present state and the inputs, as is true for all algorithmic state machines. Unlike conventional state machines in which there can be a relatively large number of inputs, this state machine may be thought of as selecting only a very small set of inputs by its selection of the procedure and test that is performed at each state.
It should be noted that the use of a state variable implementation of the compressor of the preferred embodiment avoids a complicated system of flags and registers that would need to be used if more conventional programming techniques were employed. This is because there are a relatively large number of variables that describe the current condition of the one pass analysis and merger routine performed by the present invention. Consider that the program must keep track of two pointers, i.e., one for the current command string and one for the command string representation. Under many circumstances, it needs to know the type of order that opened a particular field that contains the data to which the pointer in the string representations is currently pointing. It needs to keep track of which of the output orders (WRT, E/W, and ESC) have commands open, i.e., are currently in the process of building a command. There are other variables that will need to be tracked by flags and registers in a more conventional setting.
Using a state implementation, the present state subsumes the information that would otherwise require a complicated set of variables.
As may be seen from inspection of Fig. 6, the state machine implementation employed in the preferred embodiment is a terinary tree as, for example, shown by the three paths that may be taken from state 4 to state 6, state 300, or state 400. While most exit paths from states are binary in this particular implementation, the overall structure of the state machine is tienary and one of the possible outputs is either an impossible condition, or simply duplicates one of the other conditions, such as when the machine moves to a first new state if a particular variable is less than another, and to a second new state if the particular variable is greater than or equal to the other. This structure was chosen by the inventor because the conditional branch instructions for the processor upon which the preferred embodiment was implemented provided a terinary (three state) output indicative of whether one of the tested variables was less than, equal to, or greater than the other. However, the methodology described herein is equally applicable to construction of a binary tree or an N-ary tree where N is an integer greater than one. Furthermore, a terniary state diagram can be implemented with a processor that only has two output states for conditional branching instructions simply by executing two sequential conditional branch instructions.
On Fig. 6, dashed lines are shown to state 10 from the branching node to state 400 from state 4 and to state 200 from state 7. These indicate that after exit of the 400 and 200 submachines, respectively, the state machine returns to state 10, as indicated in Fig. 4. Similarly, a dashed line shows an ultimate branch to state 2 after the branch to the submachine for state 300 is taken from state 4.
The heart of the state machine representation and implementation method of this invention may be appreciated from viewing Fig. 6 in conjunction with Table 4, which is a representation of same. The point is that the state table of Table 4 is also the source code for implementing the machine.
Table 4 is the actual source code employed in the implementation of the preferred embodiment for the state 0 submachine illustrated in Fig. 6, which forms a part of the best mode of implementing the method of data compression described hereinabove. The only modifications that have been made are that a space has been inserted between the word "state" and the state number on the labels on the left hand side of the table, and a space has similarly been inserted between the word "test" and the test numbers shown at each state in order to enhance readability of the table.
The machine operates as follows. In the representation and implementation shown in Table 4, each state variable in the left hand column is a valid label in the assembly language used to generate the object code that implements the state machine. Thus, the state numbers in the left hand column represent both the state variables shown on Fig. 6 and are labels to which the assembly language program can branch. At each labeled statement, the identical routine, referred to as "STATETAB" is called. STATETAB is a relatively short procedure that takes five arguments: a procedure identified by a label, a test procedure identified by a label, and three alternative branching labels that are either a state number label or all zeros. Thus, each branch to one of the state number labels always calls the same routine, i.e., STATETAB.
STATETAB first executes the procedure called out as its first argument and then executes the test called. When this is completed, the results of the test control branching to one of the three state labels that form the last three arguments of the STATETAB procedure. For entries in the state table for which there is a set of eight zeros in one of the state label arguments, it should be understood that this is a test condition that cannot occur. Thus, it is convenient to generate an error upon an attempt to branch to one of these. However, it is not expected that this should ever be encountered. Similarly, if a set of zeros appears as an argument in the procedure position or the test position, it indicates that no procedure or test, respectively, is to be executed while in this particular state. This is all that STATETAB does, repetitively call a procedure and test identified in its argument list, and then cause program control to branch to one of the three state labels that appear as the last three arguments in its argument list.
The procedures and test themselves take variable arguments that can be passed depending on the particular state in which the machine currently finds itself. For example, procedure 1 sets a source of commands that are being analyzed to the CCS and procedure 2 sets the source of commands to be analyzed to the CSR. Other procedures and tests test for certain conditions in the source input. The particular state in which the machine exists will determine whether the source is set to the CCS or the CSR. However, many procedures and tests that operate on information from the source or, test for conditions of the source, are generic and are equally applicable to testing for conditions in the current command string or the command string representation.
It should be noted from inspection of Tables 4 and 5 (below) that the procedures and tests are called multiple times at different states. Furthermore, these procedures and tests are used in the other state submachines, namely, the state 200 machine 85, the state 300 machine 87, and the state 400 machine 86 shown in Fig. 4.
The preferred embodiment of the present invention was implemented using system 370 assembler language, i.e., IBM S/370 Assembler Language, and those skilled in the art will recognize Tables 4 and 5 as (with the slight modification of the spaces described hereinabove) valid S/370 assembler statements.
In order to follow an example, the reader's attention is respectfully directed to Table 4, Fig. 6, and Fig. 4, all of which represent the state 0 tests performed. From this inspection in light of the following discussion, the general methodology will be appreciated. On Fig. 6, the machine starts in state 0. As shown on Fig. 6 at state 0, it executes procedure 1 (PROC1) and performs test 3. This is defined by the first two arguments of the STATETAB procedure at the STATE 000 label shown in Table 4. The state destination arguments of STATE 0 are states 1 and 2. It should be noted that there is a repetition of the state 1 label as two of the arguments in the STATE 0 entry in Table 4. Therefore, from reading the first line of Table 4, it can be determined that, depending on the results of test 3, the program should move to either STATE 1 or STATE 2.
Turning for a moment to Fig. 6, it will be seen that the path between STATE 0 and STATE 2 is labeled "MORE CSR", indicating that TEST 3 has determined that the command string representation has not yet been exhausted and therefore, the machine should move to state 2. If the command string has been exhausted, the machine moves from STATE 0 to STATE 1. Turning for a moment to Fig. 4, it should be understood that state 0 corresponds to conditional test 66 shown thereon. YES branch 76 is identical to the path over to STATE 2 shown on FIG. 6. Continuing with the example, STATE 1 on Fig. 6 corresponds to step 68 on Fig. 4. NO branch 69 from 54 goes to exit point 70 which is the DONE exit from STATE 1 shown on Fig. 6. Similarly, YES branch 67 on Fig. 4 takes the program to the STATE 100 submachine. This corresponds to the "MORE CCS" that branches to STATE 100 as shown in Fig. 6.
Likewise, STATE 4 corresponds to step 79 that has three possible branches therefrom. From inspection of the logical significance of branches 80 through 82 on Fig. 4 and the corresponding branches shown as exit paths from STATE 4 on Fig. 6, the correspondence will be appreciated.
It would belabor the point to provide a verbal description of each node and the paths therefrom on Fig. 6. They are described in state Table 4 and can be understood from the foregoing examples and the following description of the tests and the procedures in Tables 6 and 7.
|Function of the Procedure||Macro|
|PROC000||Set source of data to current command string||[Yes]|
|PROC001||Set source to command string representation||[Yes]|
|PROC002||Delete to end of screen in WRT string only|
|PROC003||Delete in WRT string only until address offset reaches input address offset|
|PROC004||Set CSR offset to maximum value (CSR exhausted)||[Yes]|
|PROC100||Move characters to E/W and ECS|
|PROC101||Move order to E/W and ECS|
|PROC102||Move protected characters to E/W and ECS|
|PROC103||Update pointer of source from an SBA order|
|PROC104||Move order to ECS only|
|PROC105||Move characters to ECS only (protected dark)||[Yes]|
|PROC106||Insert cursor in E/W|
|PROC107||Process protected repeat to address order|
|PROC108||Process protected, dark repeat to address order|
|Tests used in Figs. 6 and 7|
|Test Number||Nature of Test|
|TEST000||Test relative values of CCSP and CSRP (<, =, or >)|
|TEST001||Tests for new data, ie. CCS contains erase instruction|
|TEST002||Test input string for protected or unprotected field|
|TEST003||More input or exhausted|
|TEST004||Test input order for IC, RA, or other|
|TEST005||Test input for order or no order|
|TEST006||Test input for dark or not dark|
|TEST007||Test input order for SBA, SF, or other|
|TEST008||Test input for same SF order or different SF order (dark)|
|TEST009||Test input for same SF order or different SF order (undark)|
|TEST010||Test input for newly dark data|
|TEST100||More input or exhausted (processing order)|
Another important aspect of the preferred embodiment of the method of state machine representation implementation has to do with the significance of the macro column shown in Table 6. Each of the procedure labels that is the first argument of the STATETAB function shown in Tables 4 and 5 is a valid label to the assembler in use. The procedure names used in the state table are selected such that they may be either a valid label for a macro, i.e., a set of computer instructions to be inserted in place into the state table description, or a subroutine call. The particular choice of macro or subroutine is based on the length of the code segment that implements the procedure. The inventor of the present invention has selected shorter procedures to be expressed as macros and thus, when the state table is compiled into executable code, the inline code of a macro is directly compiled into instructions at the points at which that procedure is called. Longer procedures, particularly those called multiple times by various states, are encoded as subroutines. This provides for maximum efficiency and minimum size of the object code output from the assembler or compiler when the state table is compiled.
Therefore, the following should be noted about the representation and implementation method of this invention. Each of the procedures and tests that form the first two arguments of the state tab procedure are encoded. Their function is as described in Tables 6 and 7. STATETAB is a straightforward procedure that simply takes the arguments described herein and calls a procedure and test, as appropriate, each time it is nm and furthermore causes branching to one of its three destination arguments. The branching steps are in the form of "GO TO STATE LABEL". Therefore, while much theory of modern structured programming thinking includes an almost dogmatic notion that GO TO statements should not be used in well disciplined programs, the use of the state table representation as both a state table listing and the source code itself leads to a easily maintainable, easy to understand representation of the program that is also the source code for the main body of the program. It should be noted that by constraining the movement of the machine among its states to those that can be controlled via calls of the STATETAB procedure, it is easy to insert additional states as needed without requiring renumbering of the states or trying to keep track of a multiplicity of condition variables.
There are a couple of aspects of this constraint that can be appreciated, for example, in connection with a code onFig. 7A or 7B. For an N-iary state table, (N being the number of branch to labels that are arguments of the STATETAB function) if a condition is encountered in which the machine needs to test for more than N possible outcomes, this can be accomplished by exiting from a first state to branches for N-1 of the outcomes with the other branch branching to state for which the other outcomes are possible. This may be repeated iteratively until all of the possibilities are tested.
For example, in the state 100 submachine shown in Fig. 7A and 7B, once it has been determined that an order has been encountered at state 113, the machine needs to identify whether it is one of a set of more than three possible orders. Therefore, the three branches from step 113 lead to state 114 which is taken if the order is either an SBA or an EUA, step 115 for a start field order, and step 118 for another type order. Turning for a moment to Fig. 7B, it can be seen that state 118 leads to three possible branches, i.e., to state 121 if it is an IC order, state 122 if it is an RA order, and a branch back to step 103 if it is another type of order. In this way, the machine advances from state 113 to an appropriate state based on detection of whether it has encountered one of five classes of orders. Therefore, the state machine representation implementation method of the present invention involves defining a state table in which the state labels are valid labels for the assembler or compiler that is used to generate executable code implementing the state machine. A single multi-argument function for processing each state is included that takes arguments of at least tests, and preferably procedures, and defines at least one output label for each state. Code for the procedures and tests is written, each of which is identified by a label that is used as an argument in the state table. The single multi-argument function redirects control to one of the destination state labels each time it is run.
It should be noted that the code for the STATETAB is generated only one time when the state table is assembled or compiled, but that the resultant computer instructions are executed millions of times per day during the running of a program embodying the present invention. Therefore, the STATETAB expansion of the present invention notices occurrences of the condition when two of the three possible state destinations are the same and tests the different one only and will go to the other if appropriate. Similarly, it detects the condition when one of the outcomes is the next state and does not execute a GO TO if that outcome is appropriate. In other words, it simply lets the program counter take the machine to the next state when the test indicates that it should go to the next state. Also, STATETAB detects when no test is conducted in a particular state and lets the machine simply fall through to the next state after the procedure when the first state is completed.
In the preferred form of the method procedure and test arguments with a single function are expressed as labels that can identify either macros or subroutines, subprograms or procedures. These are selected in a manner to generate the most compact and efficient code upon compilation or assembly.
From the foregoing, it will be appreciated that the process of the current invention meets the objects stated hereinabove and overcomes the drawbacks of the prior art previously described. Since the logic of the process only deals with buffer addresses into which data either has already been written or is being written by a new set of commands, it does not waste CPU time and memory testing and comparing values representative of the contents of empty addresses of the screen buffer at the terminal being serviced. By providing both a new expected state string, which may be used to newly write the buffer contents after an erase command, as well as a write command string that will write only the needed new data, it assures that a minimum length command string is all that is physically transmitted over the remote links to the video terminals being serviced. In view of the method disclosed in this specification, other implementations of the present invention will occur to those skilled in the art and therefore the scope of the present invention is to be limited only by the claims below and equivalents thereof.
Back to Patent's Contents