Patent Application
20090083589
U.S. Pat. No. 5,727,170 (Mitchell), which is incorporated by reference herein in its entirety, discloses that the “PLC has a user configurable protocol port attached thereto. Briefly stated, at the PLC communication port or as a result of a user program or I/O event, a special flag bit may be set which thereby allows the communication port to be activated. This is done by the flag bit causing an interrupt to occur in the PLC user program which allows a user to communicate with a user specified protocol scheme rather than the normal communication/programming protocol when this special bit is not set.” See Abstract.
U.S. Pat. No. 5,765,000 (Mitchell), which is incorporated by reference herein in its entirety, discloses that the “scan cycle in a programmable logic controller is constructed so as to allow the PLC users program to execute an instruction to assign a user program section to which the PLC system is to transfer control upon the occurance of an instruction-specified event. Also allowed is the de-assignment of a user program section from an instruction-specified event. Moreover, the interrupt may happen at any portion of the PLC scan cycle and not merely at compilation time. This thereby allows for dynamically presetting values of characters and the like as well as pipelining of interrupts in the PLC.” See Abstract.
Certain exemplary embodiments can provide a system, which can comprise a programmable logic controller (PLC). The system can comprise a serial communications port connected to the PLC. In certain exemplary embodiments, the system can comprise a controller adapted to enable a customer application program to access and control the serial communications port.
A wide variety of potential practical and useful embodiments will be more readily understood through the following detailed description of certain exemplary embodiments, with reference to the accompanying exemplary drawings in which:
Certain exemplary embodiments can provide a system, which can comprise a programmable logic controller (PLC). The system can comprise a serial communications port connected to the PLC. In certain exemplary embodiments, the system can comprise a controller adapted to enable a customer application program to access and control the serial communications port.
Certain exemplary embodiments can provide an ability to access and control a Universal Asynchronous Receiver/Transmitter (UARTs) in order to permit creation of custom communication protocols through the customer's Programmable Logic Controller (PLC) application program.
Freeport can provide the ability for the customer application program to access and control a serial communications port connected to a S7+ CPU. The operation of the communications port can be controlled by the customer application program through the use of specialized “System Functions” provided as a standard part of the PLC operating system, such as that of the S7-200 product line.
However, certain exemplary embodiments of several new features for the S7+ CPU product family can simplify the customer's creation of Freeport applications via the following capabilities, which are further described herein:
In certain exemplary embodiments, one or more new capabilities can be added to the Point-to-Point Freeport solution, which can comprise:
In certain exemplary embodiments, Point-to-Point (“PtP”) communication devices can abstract physical communications devices from the customer. This can be accomplished by providing standard “System Function” interfaces that work with messages rather than characters.
In certain exemplary embodiments, PtP communication can give an application program control of communications channels that can be a part of a PLC communication system. Communications channels can reside in the PLC, in a module of the PLC's local rack, and/or in a remote rack of modules. The concept where the application program controls the operation of a communications channel(s) can be referred to by the descriptive “Freeport”.
In embodiments where the communications channel is part of the PLC, PtP communication can be implemented as a function of PLC firmware without affecting any other system components. However, if the communications channel can be in a communications port (“CP”) and/or an annex module then it cannot be implemented in the PLC alone. The CP and/or annex module can provide the interface to the communications channel and the PLC can provide the application interface that enables access to the module. Both the PLC and the module can provide system services that allow transport of the user controls and messages adapted to facilitate this operation. In a similar manner, the configuration of a communications channel can be performed by the user application.
In certain exemplary embodiments, STEP 7+ hardware configuration can provide configuration and parameter assignment support (also potentially Smart Client Configuration) that improve the ease of use needed for creating custom protocols. Certain exemplary embodiments can provide explicit configuration support for port, transmit, and receive configuration related items. This can be similar to the PtP configuration classic STEP 7. In certain exemplary embodiments, PtP configuration might not be offered. Classic S7-200 customers can programmatically develop certain PtP applications.
1.1.1 Custom versus Provided Protocols
In certain exemplary embodiments, the target communications channel can be in the CPU and the CPU can execute the user program. The target channel can be in a module that is remotely located with respect to the CPU. For such a case, the I/O communication system can provide a transport mechanism for the data/control associated with system function calls (“SFCs”), such as certain SFCs defined herein, infra.
The original concept of custom Freeport protocol development was to provide direct control over the UART; thereby, enabling the customer to implement the protocol of choice in the application program. This can be a powerful and flexible capability, but for many customers the task of implementing a communication protocol can be difficult. Consequently, support for certain protocols can be provided, such as:
Freeport communication can be serial communication in a relatively basic form. Controls for the communication channels can be provided through SFCs which can allow channels to be configured and/or used to implement most character based protocols. For any given protocol, a minimum of two communication partners can be used. A protocol can be implemented as either a client (master) or a server (slave) in a single partner.
The following steps can be used for the implementation of the slave side of a protocol:
The last two steps of this sequence can be repeated as long as communications is active.
The following steps can be used for the implementation of the master side of a protocol:
The last two steps of this sequence can be repeated as long as communications is active.
In either of these two cases, the data on the wire at the receiver can be de-serialized and presented to the user program in the receive buffer. Likewise, the data in the transmit buffer can be serialized and put onto the wire by the transmitter. All aspects of the protocol can be generated for transmission and processed during reception in the user program, which can include timing, preambles, lengths, checksums, and/or ending characters, etc.
The user programming burden for supporting PtP communication can be greatly reduced when certain protocols are developed, tested, and provided by a supplier of programmable logic controller hardware, software, and/or firmware. For slave protocols, the port configuration SFC can be a function invoked by the user program.
For example, if the selected protocol was MODBUS RTU slave protocol and the physical interface was realized as an RS-232 connection, then the port configuration system function call (“SFC”) can be utilized for operation of the port. Even though the MODBUS protocol includes an address field, in certain exemplary embodiments, the address can be ignored because the physical medium is a point to point connection using RS-232.
If on the other hand the electrical interface was realized as a RS-485 connection, certain exemplary embodiments can supply a station address to the protocol before communication begins.
The following steps can be utilized for the implementation of a slave side protocol:
However, provided master protocols can be more complex. The following steps can be used for the implementation of a master side protocol in certain exemplary embodiments:
For example, the USS protocol can control the start/stop and speed of a motor and update the status of the drive along with the actual speed of the motor for the drives that are active on the network. In addition it can be possible to read and write parameter values as requested by user commands.
The following are examples of “provided-protocols” that can be supported by certain exemplary embodiments:
PtP communication can be a user function. As a result, certain exemplary embodiments make PtP communications available when the PLC is in the RUN mode.
Whenever the CPU is transitioned to STOP mode, any active transmission or reception can be caused to immediately and/or automatically cease. Certain buffered requests can be discarded.
Diagnostic functions can be restricted to functions inherent to basic hardware and/or firmware functions of the PLC and/or modules. PtP modules can support diagnostic detection and can utilize Diagnostic Navigation Node (DNN) facilities to report errors.
In certain exemplary embodiments, PtP protocol specific diagnostics might not be provided within the scope of the PLC system. Certain protocol specific diagnostics can be detected and handled by the user application.
Certain communication processor (CP) devices can offer a minimum of 16K bytes of memory that can be used to buffer both transmitted and received messages. The maximum size of a single transmitted message can be, for example, any value such as less than 1K, 2K, 4K, 8K, 18K, 28K, 99K, and/or 128K, etc.
In certain exemplary embodiments, PtP parameters can be accessible as “Properties” from Hardware Configuration and can be associated with PtP capable modules. Once the module is selected, the properties can become visible. Most PtP properties can be accessible as configuration related items and can be downloadable to the CPUs.
Once downloaded, these parameters can become the default configuration for the module. Configuration from the customer application program might not be specifically required.
In certain exemplary embodiments, these configuration items can be permanently stored in the CPU. Power-up or stop-to-run transitions can result in the last update of these parameters being restored.
In addition to static configuration, customers can dynamically configure PtP parameters from their application program. Dynamic configuration support can allow devices that do not support programming such as HMI or DCS systems to interact with the customer application in order to affect desired configurations. For example, customers of OEM manufacturers can configure baud rate and parity for devices that are interconnected to the OEM machine. In certain exemplary embodiments, parameters that are dynamically configured might not be permanently stored.
Certain S7-400 CPUs (CP441-1 and CP441-2) can provide support for connection and coordinated send and receive operations between two communication partners. Connections can be specified through PtP network configuration performed through NetPro. This configuration can result in a connection identifier that can be used with the send and receive instruction parameters
Coordinated operations can be accomplished using the R_ID parameter of specific send and receive instructions. This parameter can be used to specify which specific send and receive instructions belong together, i.e. a specific instruction instance or execution instance of the receive instruction can be paired with a specific instruction instance or execution instance of the send instruction.
Support for “GET/PUT”, “USEND/URCV”, or “BSEND/BRCV” operations can be a subset between the S7plus CPUs. Certain exemplary embodiments can support connection-based PtP operations.
S7-200+ can support legacy read and write (“Get” and “Put”) SPS7 services as a server only. Certain exemplary embodiments can be supported through the DP/T protocol. Certain exemplary embodiments might not support customer accessible “Get” and “Put” operations.
Parameterization of features, functions, and/or modules can originate from many different sources. Table I identifies a set of exemplary different phases of parameterization and which phase has precedent, i.e. which value will the AS use during its execution if more than one value exists. Certain exemplary PtP applications might utilize initial and temporary value types shown in TABLE I.
The system functions illustrated in TABLE II can be provided for customer application programs. The functions listed in TABLE II can be implemented via SFCs and/or SFBs.
In certain exemplary embodiments, the parameters can be configurable for Freeport utilizing devices. A subset of these parameters can be dynamically configurable as attributes during runtime. Specified defaults can be provided as recommendations for accompanying ES configuration. However, default recommendations can be different depending upon particular protocols.
Basic parameters can control how a particular communication channel can be managed. Certain exemplary parameters can select between Freeport and Provided protocols. Parameters in this category can be dynamically set using the “PORT_CFG” function.
Parameters can be dynamically set using the “SEND_CFG” function.
Parameters dynamically set using the “SEND_CFG” function can also comprise:
Parameters can specify conditions necessary to begin receiving a message. Parameters in this category can be dynamically set using the “RCV_CFG” function. In certain exemplary embodiments, a customer can select any set of combinations of start conditions. For example, both an Idle Line and Start Character or a Line Break and Start Character can be concurrently selected. Certain exemplary embodiments can have limited restrictions regarding the concurrent selection of different start conditions.
Parameters can specify conditions to complete reception of a message. In certain exemplary embodiments, a customer can select combinations of end conditions. Certain exemplary embodiments can utilize relatively few restrictions regarding the concurrent selection of different end conditions. In certain exemplary embodiments, end conditions associated with characters and character sequences can be incorporated into “Variable Characters” configuration. Parameters in this category can be dynamically set using the “RCV_CFG” function.
Flow control can be accomplished by control lines in a data communication interface (i.e. hardware flow control) and/or by reserving control characters (i.e. software flow control) to signal start and stop constraints. PtP devices can support both methods as described below. Certain exemplary PtP devices might not disable flow control to the initiator of transmission. PtP devices can be adapted to maintain sufficient resources in order to be able to process a complete message.
Hardware flow control can work through cooperative use of Request-to-Send and Clear-to-Send signals. Upon receiving a send request, the initiator can asserts an RTS line and/or wait for CTS to be asserted during the time specified by “Wait Time”. Once the CTS line is active, the initiator can begin sending data.
The initiator can monitor CTS throughout the transmission. If the responder disables CTS, transmission can immediately stop. The initiator can once again wait the amount of time specified by “Wait Time” for CTS to be re-asserted. Once re-asserted, transmission can resume.
If the wait time expires before CTS is re-asserted, the current transmission can be aborted and the customer application appropriately notified.
In certain exemplary embodiments, the use of other miscellaneous signals such as DTR and DSR can be subsets, which can be defined as optional signals that may or may not be supported across the different CPs.
As an alternative to standard hardware flow control, signal handshaking can be supported. In certain exemplary embodiments, the DTE can assert RTS by default, which can permit a modem to transmit whenever it desires.
When either a configured number of message frames or configured number of characters, the DTE can disable the RTS line in order to ensure that the receive buffer does not overflow.
If the transmitting communication device continues to send data to the extent that the receive buffer overflows, the received message can be discarded and an appropriate error message can be generated.
Software flow control works by sending specific characters for controlling and limiting transmissions. Two bytes have been predefined in the ASCII character set to be used with software flow control. These bytes can be referred to as XOFF and XON characters.
The initiator of a transmission can actively monitor it's receive line for a XOFF character. Once an XOFF is received, transmission can immediately stop. Once a corresponding XON character is received, transmission can resume.
The initiator can wait the amount of time specified by “Wait Time” for a XON to be sent after a XOFF is received. If the wait time expires before XON is re-asserted, the current transmission can be aborted and the customer application appropriately notified.
Software flow control can utilize a full-duplex communication interface since control characters can be sent from the responder during a transmission from the initiator. Similar flow control behaviors apply as described in the “Hardware Handshaking” section, supra.
Certain exemplary embodiments can provide function definitions that include the function's type, name, family, and number. In addition, each operand can be defined. Each definition can include the operand's name, data type, and interface type.
Freeport transmissions and receptions can be initiated from the customer application program by the SEND_PTP and RCV_PTP functions. However, these functions might not transmit or receive messages directly. They can work cooperatively between the CPU and the PtP CP modules or Annex modules.
These functions can be asynchronous functions that transmit and receive entire messages to and from the respective cards. Each module can be responsible for directly transmitting and receiving messages.
In order for the customer's application to determine the status of transmissions and receptions and provide necessary application control, either polling or event driven architectures can be employed.
These architectures can be further described in the following sections. Examples can be used where the PLC can be the initiator of the transmission and the connected device can be the responder.
A polling implementation can require that the customer's application program manually check the status of a transmission or reception. For Freeport protocols that transmit and receive messages using this method, handling can be accomplished with the following.
First, a transmission can be initiated using the SEND_PTP function. This function can provide the message to be transmitted to the module and the transmission can be initiated.
Next, the user application can determine when the transmission completes and if it has completed correctly. The application can repeatedly call the SEND_PTP function in order to monitor the status of the transmission. In certain exemplary embodiments, a rising edge on the REQ input can initiate the transmission of the specified message. All other calls to this function can return the current status.
Once the transmission completes, the user application program can perform any activities to prepare for the anticipated response to the transmission. The application can then initiate a RCV_PTP function. This function can repeatedly check the status of the expected response to the completed transmission. Once the reception is obtained, the status can be set appropriately and the response can be transferred to the buffer specified within the application program. For a polling architecture, all these activities can be performed in the main program thread.
An interrupt implementation can require the PLC to generate interrupts upon specific events. This is a type of “callback” architecture where customer specified communication interrupt OBs can be executed each time a transmission or reception event occurs. For Freeport protocols that transmit and receive messages using interrupts, handling can be accomplished with the following.
First, an OB can be specified to handle interrupts that can be generated by each transmit event. A transmission can be initiated using the SEND_PTP function. This function can provide the message to be transmitted to the card and the transmission can be initiated.
Next, the PLC operating system can generate a communication interrupt once the transmission completes. Execution of the main thread can be preempted and can be transferred to a previously specified interrupt OB. This OB can be responsible for performing any activities that are necessary to prepare for the anticipated response to the transmission such as specifying the interrupt OB that can be responsible for handling the receive complete event. In certain exemplary embodiments, when the transmit buffer of the CP has been emptied, the transmit interrupt can be generated, which can indicate whether the transmitted message encountered an error.
Next, the PLC operating system can generate a process interrupt once the corresponding receive message completes. Execution of the main thread can be preempted and can be transferred to a previously specified receive interrupt OB. This OB can be responsible for executing the RCV_PTP function to actually transfer the received message from the CP card or Annex card to the specified memory area. The RCV_PTP function can be executed once within the receive interrupt OB.
In certain exemplary embodiments, particular customer PtP implementations can implement protocols that exceed the maximum size of transmitted or received messages. In these situations, the customer application can be responsible for ensuring the messages have been handled correctly. For example, the customer's application can ensure that the complete message has been received before operating upon the message.
As specified above, enabling of PtP interrupts can be specified through transmit and receive parameter assignments or through dynamic configuration from the user program by the attaching of particular events. Once interrupts are enabled, all normal or abnormal completions of any transmission or reception can be indicated through the generation of a process interrupt. PtP interrupts can be categorized within the “Process Control” event class.
Once a transmission or reception has completed, corresponding PtP interrupts can be generated within a maximum of 1 millisecond. Disregarding the potential of interrupt latency, in certain exemplary embodiments the customer's application program can be notified within this specified time.
User applications can perform simultaneous executions of SEND_PTP and RCV_PTP functions. Certain exemplary embodiments might not have limitations with concurrent execution of SEND_PTP and RCV_PTP functions (as experienced within S7-200 classic today). If a transmission is in progress, the RCV_PTP function can be executed to return the current status of the receive buffer or the actual receive data.
From the PtP CP perspective, messages that are to be transmitted and messages that have been received can be buffered in CP memory. Each time the application program requests a message to be transmitted, the CP can store this message up to the limit of its buffer. In certain exemplary embodiments, the number of simultaneous transmission requests can be limited to a single message. This means that any single transmission can be complete before the second transmission begins. Buffering can be applicable for received messages. These can be stored within the CP and can be provided to the application program when requested by execution of RCV_PTP functions.
A small set of start information can be supported. This information can be useful to help identify an event when more than one event is attached to a single OB:
Each System Function can provide three outputs that can be specifically associated with determining completion status. These outputs can be described as follows:
Different error classes can be used to represent different categories of errors. For example, to distinguish between configuration errors and transmission errors, different error classes can be used.
Also, different error classes can be used to distinguish errors within specific provided protocols. Each provided protocol can report errors in distinct error classes.
This is a method that can be responsible for the dynamic configuration of the operating parameters for the specified serial port This method can be identified by the following information, which can be implemented as an SFC or an SFB.
The prototype for this method can be defined as follows:
This is a method that is responsible for the dynamic configuration of the operating parameters for an anticipated serial transmission. This method can be identified by the following information. In certain exemplary embodiments, any pending messages awaiting transmission within a CP can be discarded once a send configuration function is executed. The method can be implemented as an SFC or SFB.
The prototype for this method can be defined in Table XVIII.
This is a method that is responsible for the dynamic configuration of the operating parameters for an anticipated serial reception. This method is identified by the following information. In certain exemplary embodiments, any pending messages that have been received within a CP can be discarded once a receive configuration function is executed. The prototype for this method is defined in Table XX.
The following table lists each parameter individually for the User Defined Type “Conditions”. These are parameters needed to specify start and end conditions.
The following set of pseudo-code lists the same parameters as specified above in the form of a corresponding actual data structure for an exemplary embodiment.
The following set of pseudo-code lists the same parameters as specified above in the form of a corresponding actual data structure for an exemplary embodiment.
Certain exemplary embodiments provide a method that can be responsible for the transmission of the actual data. The send command can initiate the transmission of a buffer. This method can be identified by the following information. In certain exemplary embodiments, the “SEND_PTP” function does not actually perform a transmission of the contents of the specified buffer. The buffer contents can be transferred to the PtP device. This device can perform the actual transmission.
The prototype for this method can be defined as is TABLE XXIII.
The receive command initiates the reception of a message. The receive command can be issued once for each message. Certain exemplary embodiments might not make available within the receive buffer until a message is completely received.
The prototype for this method can defined as follows:
Certain exemplary embodiments provide a method that can be responsible for obtaining the current state for several of the RS-232 signals. This method is identified by the following information.
The prototype for this method can be defined as follows:
Certain exemplary embodiments provide a method that can responsible for setting the state for two of the RS-232 output signal, which can be identified by the following information.
The prototype for this method can be defined as follows:
This method can be responsible for clearing the receive buffer.
The prototype for this method is defined as follows:
Data Communications Equipment (DCE)
Data Terminal Equipment (DTE)
Programmable logic controller 1100 can be comprised and/or be communicatively coupled to a communications port 1400. Programmable logic controller 1100 can comprise a controller 1150, which can be adapted to enable a customer application program to access and control the serial communications port via each of a Freeport protocol, a predefined master protocol, and a predefined slave protocol.
In certain exemplary embodiments, controller 1150 can be adapted to:
In certain exemplary embodiments, programmable logic controller 1100 can be adapted to:
Programmable logic controller 100 can be communicatively coupled to an information device 1600 via a network 1500. Information device 1600 can comprise and/or be communicatively coupled to a user interface 1620 and a user program 1640. User program 1640 can be adapted to monitor and/or control one or more activities associated with programmable logic controller 1100 such as creating, modifying, and/or compiling the control program. User interface 1620 can be adapted to render information regarding programmable logic controller 1100 such as information regarding creating, modifying, and/or compiling the control program. In certain exemplary embodiments information device 1600 can be an engineering workstation.
At activity 2200, the PLC can be adapted to provide support for one or more predetermined functions. For example, the PLC can be adapted to provide:
At activity 2300, parameterization can be allowed and/or performed. Certain exemplary embodiments can allow parameterization support to be specified and provided from an Engineering Station's hardware configuration. Certain exemplary embodiments can provide Explicit parameterization and control of a UART's Request-To-Send and Data-Terminal-Ready signals.
At activity 2400, the parameters can be received by the programmable logic controller. Certain exemplary embodiments can be adapted to permit a customer to specify multiple, different character sequences, that include don't-care characters, to satisfy a series of different start and/or end conditions.
At activity 2500, a user program and/or a control program can access the port. Certain exemplary embodiments can enabling a customer application program to access and control a serial communications port connected to a programmable logic controller (PLC).
At activity 2600, the port can be controlled. Certain exemplary embodiments can be adapted to enable a customer application program to access and control a serial communications port connected to a PLC. The PLC can be adapted to enable a customer application program to access and control the serial communications port via each of a Freeport protocol, a predefined master protocol, and a predefined slave protocol. Certain exemplary embodiments can via a controller, enable a customer application program to access and control a serial communications port connected to a programmable logic controller (PLC). The controller can be adapted to perform one or more of the following functions:
At activity 2700, a signal can be transmitted via the port. The signal can be serially transmitted such as via a UART and/or an RS-232 interface.
In certain exemplary embodiments, via one or more user interfaces 3600, such as a graphical user interface, a user can view a rendering of information related to researching, designing, modeling, creating, developing, building, manufacturing, operating, maintaining, storing, marketing, selling, delivering, selecting, specifying, requesting, ordering, receiving, returning, rating, and/or recommending any of the products, services, methods, and/or information described herein.
When the following terms are used substantively herein, the accompanying definitions apply. These terms and definitions are presented without prejudice, and, consistent with the application, the right to redefine these terms during the prosecution of this application or any application claiming priority hereto is reserved. For the purpose of interpreting a claim of any patent that claims priority hereto, each definition (or redefined term if an original definition was amended during the prosecution of that patent), functions as a clear and unambiguous disavowal of the subject matter outside of that definition.
Still other substantially and specifically practical and useful embodiments will become readily apparent to those skilled in this art from reading the above-recited and/or herein-included detailed description and/or drawings of certain exemplary embodiments. It should be understood that numerous variations, modifications, and additional embodiments are possible, and accordingly, all such variations, modifications, and embodiments are to be regarded as being within the scope of this application.
Thus, regardless of the content of any portion (e.g., title, field, background, summary, description, abstract, drawing figure, etc.) of this application, unless clearly specified to the contrary, such as via explicit definition, assertion, or argument, with respect to any claim, whether of this application and/or any claim of any application claiming priority hereto, and whether originally presented or otherwise:
Moreover, when any number or range is described herein, unless clearly stated otherwise, that number or range is approximate. When any range is described herein, unless clearly stated otherwise, that range includes all values therein and all subranges therein. For example, if a range of 1 to 10 is described, that range includes all values therebetween, such as for example, 1.1, 2.5, 3.335, 5, 6.179, 8.9999, etc., and includes all subranges therebetween, such as for example, 1 to 3.65, 2.8 to 8.14, 1.93 to 9, etc.
When any claim element is followed by a drawing element number, that drawing element number is exemplary and non-limiting on claim scope.
Any information in any material (e.g., a United States patent, United States patent application, book, article, etc.) that has been incorporated by reference herein, is only incorporated by reference to the extent that no conflict exists between such information and the other statements and drawings set forth herein. In the event of such conflict, including a conflict that would render invalid any claim herein or seeking priority hereto, then any such conflicting information in such material is specifically not incorporated by reference herein.
Accordingly, every portion (e.g., title, field, background, summary, description, abstract, drawing figure, etc.) of this application, other than the claims themselves, is to be regarded as illustrative in nature, and not as restrictive.
This application claims priority to, and incorporates by reference herein in its entirety, pending U.S. Provisional Patent Application Ser. No. 60/994,522 (Attorney Docket No. 2007P18390US (1009-296)), filed 20 Sep. 2007, and pending U.S. Provisional Patent Application Ser. No. 60/994,530 (Attorney Docket No. 2007P18391US (1009-217)), filed 20 Sep. 2007.
| Number | Date | Country | |
|---|---|---|---|
| 60994522 | Sep 2007 | US | |
| 60994530 | Sep 2007 | US |
