Patent Grant
7739135
Process-oriented or process-centric programs have evolved to enable processing of complex instructions modeling real-world events. Process-centric programs mirror real-world processes and mirror interactions between real-world entities. Existing systems attempt to map business problems to high-level workflows by modeling the business problem. However, real world workflows vary in a variety of dimensions such as (a) execution and modeling complexity, (b) knowledge of the structure of the flow at design time, (c) statically defined or ad-hoc/dynamic, (d) ease of authoring and editing the flow at various points in its lifecycle, and (e) weak or strong association of business logic with the core workflow process. Existing models fail to accommodate all these factors.
Further, most existing workflow models are based on either language-based approaches (e.g., BPEL4WS, XLANG/S, and WSFL) or application based approaches. Language based approaches are high-level workflow languages with a closed set of pre-defined constructs which help model the workflow process to the user/programmer. The workflow languages carry all of the semantic information for the closed set of constructs to enable the user to build a workflow model. However, the languages are not extensible by the developers and represent a closed set of primitives that constitute the workflow model. The languages are tied to the language compiler shipped by the workflow system vendor. Only the workflow system product vendor may extend the model by extending the language with a new set of constructs in a future version of the product. This often requires upgrading the compiler associated with the language. In addition, the languages usually do not declaratively expose or define functions or operations that can be readily and efficiently used by other programs.
Application based approaches are applications which have the workflow capabilities within the application to solve a domain specific problem. These applications are not truly extensible nor do they have a programmable model.
In addition, with the existing approaches, the issues of complexity, foreknowledge, dynamic workflows, authoring ease, and strength of associations with business logic and core workflows are not adequately addressed. There are no extensible, customizable, and re-hostable workflow designer frameworks available to build visual workflow designers to model different classes of workflows. Existing systems lack a rapid application development (RAD) style workflow design experience which allows users to graphically design the workflow process and associate the business logic in a programming language of developer's choice.
Also, workflow processes deal with cross cutting orthogonal and tangled concerns that span multiple steps of a workflow process model. For example, while parts of the workflow process are designed to participate in long running transactions, other parts of the same process are designed for concurrent execution or for accessing a shared resource. Due to design shortcomings, existing systems fail to provide interleaving of execution threads which enable users to design synchronous or interleaved execution of activities. Still other portions of the same workflow process require tracking, while other portions handle business or application level exceptions. There is a need to apply certain behaviors to one or more portions of a workflow process.
Some workflow modeling approaches are impractical as they require a complete flow-based description of an entire business process including all exceptions and human interventions. Some of these approaches provide additional functionality as exceptions arise, while other approaches exclusively employ a constraint-based approach instead of a flow-based approach to modeling a business process. Existing systems implement either the flow-based or constraint-based approach. Such systems are too inflexible to model many common business situations. These systems also lack the capability to asynchronously handle exceptions or cancellations.
Embodiments of the invention enable asynchronous fault or exception handling by having a faulting state in a state automaton defining execution lifetime of an activity in the workflow. By having the faulting state, aspects of the invention enable developers or programs to declaratively design programs for exception or fault handling such that portions of the program or the activity may be in fault handling in the faulting state while other portions of the program or the activity may be unaffected by the exception or the faulting event.
Alternative embodiments of the invention enable propagation or transmission of a notification of fault handling. In yet another alternative embodiment, such propagation or transmission of the notification may be suppressed or inhibited. In addition, a further alternative embodiment responds to input from a user for handling post-faulting or post-exception operations.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Other features will be in part apparent and in part pointed out hereinafter.
Appendix A illustrates an exemplary implementation of declaratively raising of an exception according to an embodiment of the invention.
Corresponding reference characters indicate corresponding parts throughout the drawings.
Referring first to
It is known by those skilled in the art that certain constraints are associated with designing software or application programs. In this example, in writing an operating system software program 104, the programming codes or routines are dependent on the type or configuration of processing units 102, being specific to the type of computing architecture (e.g., IBM® compatible, APPLE® computers, or other systems), or other constraints. In addition, programming languages typically need to accurately identify and utilize data structures such as stacks, heap, thread base, or other hardware-specific structures for the operating system 104 to function properly.
In dealing with complex workflow processes, existing applications use a concept of a managed execution environment 106 (e.g., a runtime environment where programs may share functions or common object-oriented classes) in which programs written in one programming language may call functions in other programs written in a different programming language. In such execution environment, these programs in different programming languages are compiled to an intermediate language such that the managed execution environment 106 may expose parameters, arguments, schemas or functions to the different programs so that the programs may interact with one another.
While this execution environment 106 creates a common communication environment between programs, the execution environment 106 includes various strict requirements that may not be suitable for handling the complexity and capability of process-centric programs. For example, the execution environment 106 requires programs be confirmed to a specific file format. The execution environment 106 also requires that functions or operations in the programs use a fixed set of functions or a class of functions defined by the execution environment 106.
Embodiments of the invention build on an extensible foundation or framework 202 in
Aspects of the invention free the constraint of defining activities in a particular file format by enabling workflow designs in any fashion or representation (e.g., a flow chart, a diagram, a numbered description, or the like) as long as activities in the workflow can be constructed from the representation of the workflow designs.
In addition, the workflow framework or foundation is able to handle fault or exception raised from a lower level (e.g., OS) or exception raising functions written in other formats (e.g., intermediate language).
The workflow 300 may start from a starting point 302. For example, the starting point 302 for a purchase-order workflow may be receiving an order from a customer. The workflow 300 may also include a conditional statement 304 (such as an “IF statement” or a “WHILE statement”), and it can be subdivided into additional conditional statements 306 and 308. The workflow 300 may also include a parallel structure 310, which further includes one or more sequences or activities 312. For example, the parallel structure 310 includes activities, such as checking the inventory and updating the available shippers, be processed in parallel. In the example shown, activities such as “Send E-mail” and “Get Approval” may be processed in parallel. At “drop activities here” 316, a user may further add or supplement more activities into the workflow 300. To complete the workflow 300, the processes or activities will conclude in a complete step or point 314.
In one embodiment, the activities may be arranged hierarchically in a tree structure (see
In another embodiment, activities include one or more of the following types: a simple activity, container activity and root activity. In this embodiment, there is one root activity in the model, and none or any quantity of simple activities or container activities inside the root activity. A container activity may include simple or container activities. The entire workflow process may be used as an activity to build higher-order workflow processes. Further, an activity may be interruptible or non-interruptible. A non-interruptible composite activity does not include interruptible activities. A non-interruptible activity lacks services that would cause the activity to block.
Moreover, in executing activities and the work items included in the activities, the workflow framework or an execution context or environment defines a scope or boundary for each of the work items. This scope or boundary includes and exposes information (e.g., in the form of data, metadata, or the like) such as the shared data or resources to be accessed by the work items, associated properties, handlers, constraints and interactions between autonomous agents. Also, each activity may be configured by a user code in any programming language. For example, the user code may represent business or application logic or rules written in a specific domain or execution environment. Each activity may support pre-interception hooks and post-interception hooks into execution in the user code. Each activity has associated runtime execution semantics and behavior (e.g., state management, transactions, event handling and exception handling). Activities may share state or resources with other activities. In addition, activities may be primitive activities or grouped into a composite activity. A primitive or basic activity has no substructure (e.g., child activities), and thus is a leaf node in a tree structure. A composite activity contains substructure (e.g., it is the parent of one or more child activities).
In one example, the memory area 404 may include computer readable media, either volatile, nonvolatile, removable, or non-removable media, implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. For example, computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store the desired information and that may be accessed by the system 400. The memory 404 may also include communication media embodying computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. Those skilled in the art are familiar with the modulated data signal, which has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media, are examples of communication media. Combinations of any of the above are also included within the scope of computer readable media.
For example, the memory area 404 stores a plurality of activities 406 for processing in a workflow (e.g., the workflow 300). Each of the plurality of activities 406 includes one or more work items, and the work items may be organized in a hierarchical structure such as a tree structure (see
For example, the processor 408 accesses the work items in the plurality of activities 406 via a component or a set of computer-executable instructions such as the scheduler 408 to enqueue or to store the work items 422 to a queue 410. A dispatcher 412, accessible by the processor 402, dispatches the work items 422 for execution. For example, a work item 422-1 may include an activity method or an activity operation 424, routine, or a collection of codes for performing a function of “requesting input from a user”. One or more other activity methods, activity operations, routines, or codes may be included in each of the work items 422 without departing from the scope of the invention.
Once the work items 422 are dispatched by the dispatcher 412, the processor 402 executes each of the methods 424 in the work items 422 at 414. In the example of work item 422-1, the processor 402 may provide a user via a user interface (UI) to input the requested information or data. In another embodiment, the processor 402 may connect to or access an external data source for requesting input from the user. Upon completion of the activity method or activity operation 424, the processor 402 concludes execution of the work items 422 at 416. In one embodiment, the processor 402 passivates the executing state of work items at 418 to a data store 420.
In another embodiment, the processor 402 executes the work items 422 according to a state automaton, such as the automaton shown in
For example, the state automaton 600 describes a process flow of execution of work items (e.g., work items 422) in a workflow activity. The work item 422-1, as illustrated in
For example, suppose an exception occurs during the execution of a work item (e.g., work item 422-1), such as a parameter for a function is missing. The system 400 transitions the work item 422-1 to the faulting state 608. In doing so, the system 400 also performs garbage collection (e.g., removing previously executed portion of the operations from cache or memory, reset parameter values, or the like) operations in the compensating state 610 before transitioning the work item 422-1 to the closed state 612. For example, work items in the compensating state 610 may trigger operations such as recovering data that was previously used for executing other work items. The closed state 612 indicates that the execution of the activity (e.g., activity 500 in
In one embodiment, the state automaton 600 establishes relationship between work items in a composite activity. For example, one of the relationship rules may include that, before transitioning to the closed state 612 methods or work items in the root node of the activity tree, all of the work items in the children nodes should be in the initialized state 602 or the closed state 612. Another rule may require that, in order to transition the work items in the children node of the activity tree to the executing state 604, the work item in the root node must already be in the executing state 604.
In another embodiment, one or more additional states may be defined in the state automaton 600 without departing from the scope of embodiments of the invention.
Referring next to
In
While in the executing state 710, a faulting event 722 or an exception has occurred. The faulting event 722 may include a warning notification for missing data, an execution fault, an inaccurate access to a data store, or the like. In this example, the transaction_1704 includes a handleFault( ) function 716 for handling the faulting event 722. In one embodiment, the handleFault function 716 resembles a “catch” function for fault handling in other execution environments, such as an operating system or a managed execution environment. As such, the fault propagation or dispatch to the handleFault function 716 or the “catch” handler is asynchronous.
Upon the occurrence of the faulting event 722, the transaction_1704 transitions to a faulting state 712, and the transaction_1704 is transitioned to a closed state 714. In one embodiment, in responding to the faulting event 722, the handleFault( ) function 716 is called and is placed in a queue (not shown) for processing.
With this well-defined protocol for exception propagation and handling, alternative embodiments may handle multiple exceptions, and multiple exceptions may be scheduled while the propagation of exceptions may be interleaved with the normal program execution.
In
In an alternative embodiment, the handleFault( ) function 716 may propagate or transmit a notification 720 to the remaining work items in the executing state 710 as a function of the execution hierarchy or the execution hierarchical structure of the activity. For example, while the transaction_1704 is in faulting state 712, the handleFault( ) function 716 may propagate the notification 720 (e.g., a “throw” function) so that the handleFault( ) function of the parent Activity_1702 may handle it as if the notification 720 is a faulting event or an exception. In one embodiment, a child activity may limit the target of the throw function to its parent in the activity tree. In another embodiment, exception handling may be highly associated with or tied to the tree like structure of activities.
By establishing the faulting state 712 for handling faulting events, embodiments of the invention enable asynchronous faulting handling or exception handling, and the remaining work items or activities in the executing state 710 continue to be executed. In addition, another alternative embodiment enables scheduling of handling faulting events. For example, upon responding to the notification 720, the transaction_2706 may be placed in a scheduler queue 718 before being transitioned to the faulting state 712. In another embodiment, the notification 720 may be suppressed such that other work items or activities in the executing state 710 continue to be executed. In one embodiment, the transaction_1704 transitions to a closed state 714 after propagating or transmitting the notification 720. In yet another embodiment, fault propagation and handling survive and span across passivation cycles.
In
Without limitations, Appendix A illustrates an exemplary implementation of declaratively raising of an exception according to an embodiment of the invention. In one embodiment, programmers or developers may design a fault handler for handling a particular type of faulting events or exceptions. In yet another embodiment, work items or activities in the workflow may not include a function or incapable to handle faulting events. In this embodiment, the workflow execution environment handles the faulting events. In yet another embodiment, one or more post-fault-handling operations may be provided to the user via the UI 428 to the user 430 in
While
A scheduler component 906 transitions each of the work items to the executing state at 806. An execution component 908 executes the included operation of transitioned work items in the executing state at 808. At 810, an identification component 910 identifies one or more of the transitioned work items in response to the faulting event based on the execution hierarchy and the included operation. At 812, a fault handler 912 asynchronously handles the faulting event by invoking a fault handling operation (e.g., the handleFault( ) function 716) in the one or more identified work items to transition the one or more identified work items to the faulting state while executing the included operation of the remaining transitioned work items not identified in response to the faulting event by the identification component. In one embodiment, the fault handler 912 asynchronously handles the faulting event by transitioning the one or more identified work items to the faulting state. In yet another embodiment, the fault handler 912 asynchronously handles the faulting event by enqueuing the one or more identified work items in a scheduler queue (e.g., scheduler queue 718).
In an alternative embodiment, the computer-readable medium 900 further includes a fault propagation component 914 for transmitting a notification from the one or more identified work items to the remaining transitioned work items as a function of the execution hierarchy of the activity. The notification 720 indicates that the identified one or more work items are in the faulting state. In a further embodiment, the computer-readable medium 900 further includes a transition component 916 for transitioning the remaining transitioned work items from the executing state to the faulting state in response to the transmitted notification.
The computer-readable medium may also include a compensation component 918 for recovering or compensating data associated with the activity as a function of the asynchronously handling the faulting event in yet another alternative embodiment. An inhibition component may also be part of the computer-readable medium 900 for suppressing the transmission of the notification to the remaining transitioned work items.
Although described in connection with an exemplary computing system environment, such as the system 400 in
Embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. Aspects of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In operation, the system 400 executes computer-executable instructions such as those illustrated in the figures, such as
The order of execution or performance of the operations in embodiments of the invention illustrated and described herein is not essential, unless otherwise specified. That is, the operations may be performed in any order, unless otherwise specified, and embodiments of the invention may include additional or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, contemporaneously with, or after another operation is within the scope of aspects of the invention.
Embodiments of the invention may be implemented with computer-executable instructions. The computer-executable instructions may be organized into one or more computer-executable components or modules. Aspects of the invention may be implemented with any number and organization of such components or modules. For example, aspects of the invention are not limited to the specific computer-executable instructions or the specific components or modules illustrated in the figures and described herein. Other embodiments of the invention may include different computer-executable instructions or components having more or less functionality than illustrated and described herein.
When introducing elements of aspects of the invention or the embodiments thereof, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
Having described aspects of the invention in detail, it will be apparent that modifications and variations are possible without departing from the scope of aspects of the invention as defined in the appended claims. As various changes could be made in the above constructions, products, and methods without departing from the scope of aspects of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4697266 | Finley | Sep 1987 | A |
| 4920483 | Pogue et al. | Apr 1990 | A |
| 5287537 | Newmark et al. | Feb 1994 | A |
| 5301320 | McAtee et al. | Apr 1994 | A |
| 5634127 | Cloud et al. | May 1997 | A |
| 5636204 | Mizuno et al. | Jun 1997 | A |
| 5734837 | Flores et al. | Mar 1998 | A |
| 5774661 | Chatterjee et al. | Jun 1998 | A |
| 5819022 | Bandat | Oct 1998 | A |
| 5923863 | Adler et al. | Jul 1999 | A |
| 5930512 | Boden et al. | Jul 1999 | A |
| 6016394 | Walker | Jan 2000 | A |
| 6028997 | Leymann et al. | Feb 2000 | A |
| 6073109 | Flores et al. | Jun 2000 | A |
| 6078982 | Du et al. | Jun 2000 | A |
| 6115646 | Fiszman et al. | Sep 2000 | A |
| 6158044 | Tibbetts | Dec 2000 | A |
| 6225998 | Okita et al. | May 2001 | B1 |
| 6253369 | Cloud et al. | Jun 2001 | B1 |
| 6397192 | Notani et al. | May 2002 | B1 |
| 6405364 | Bowman-Amuah | Jun 2002 | B1 |
| 6411961 | Chen | Jun 2002 | B1 |
| 6412109 | Ghosh | Jun 2002 | B1 |
| 6560626 | Hogle et al. | May 2003 | B1 |
| 6567783 | Notani et al. | May 2003 | B1 |
| 6604104 | Smith | Aug 2003 | B1 |
| 6609128 | Underwood | Aug 2003 | B1 |
| 6621505 | Beauchamp et al. | Sep 2003 | B1 |
| 6633878 | Underwood | Oct 2003 | B1 |
| 6662188 | Rasmussen et al. | Dec 2003 | B1 |
| 6678882 | Hurley et al. | Jan 2004 | B1 |
| 6708186 | Claborn et al. | Mar 2004 | B1 |
| 6807583 | Hrischuk et al. | Oct 2004 | B2 |
| 6845507 | Kenton | Jan 2005 | B2 |
| 6886094 | Blandy | Apr 2005 | B1 |
| 6889231 | Souder et al. | May 2005 | B1 |
| 6898604 | Ballinger et al. | May 2005 | B1 |
| 6898790 | Cheong et al. | May 2005 | B1 |
| 6918053 | Thatte et al. | Jul 2005 | B1 |
| 6928582 | Adl-Tabatabai et al. | Aug 2005 | B2 |
| 6964034 | Snow | Nov 2005 | B1 |
| 6971096 | Ankireddipally et al. | Nov 2005 | B1 |
| 6985939 | Fletcher et al. | Jan 2006 | B2 |
| 7069536 | Yaung | Jun 2006 | B2 |
| 7096454 | Damm et al. | Aug 2006 | B2 |
| 7100195 | Underwood | Aug 2006 | B1 |
| 7133833 | Chone et al. | Nov 2006 | B1 |
| 7222334 | Casati et al. | May 2007 | B2 |
| 7233952 | Chen | Jun 2007 | B1 |
| 7240324 | Casati et al. | Jul 2007 | B2 |
| 7272816 | Schulz et al. | Sep 2007 | B2 |
| 7490073 | Qureshi et al. | Feb 2009 | B1 |
| 20010013118 | Krishnaswamy | Aug 2001 | A1 |
| 20020032692 | Suzuki et al. | Mar 2002 | A1 |
| 20020040312 | Dhar et al. | Apr 2002 | A1 |
| 20020065701 | Kim et al. | May 2002 | A1 |
| 20020147606 | Hoffmann et al. | Oct 2002 | A1 |
| 20020170035 | Casati et al. | Nov 2002 | A1 |
| 20020184610 | Chong et al. | Dec 2002 | A1 |
| 20020188644 | Seidman | Dec 2002 | A1 |
| 20030004771 | Yaung | Jan 2003 | A1 |
| 20030018508 | Schwanke | Jan 2003 | A1 |
| 20030018643 | Mi et al. | Jan 2003 | A1 |
| 20030033191 | Davis | Feb 2003 | A1 |
| 20030055668 | Saran et al. | Mar 2003 | A1 |
| 20030084016 | Norgaard et al. | May 2003 | A1 |
| 20030084127 | Budhiraja et al. | May 2003 | A1 |
| 20030135659 | Bellotti et al. | Jul 2003 | A1 |
| 20030144891 | Leymann et al. | Jul 2003 | A1 |
| 20030177046 | Socha-Leialoha | Sep 2003 | A1 |
| 20030200527 | Lynn et al. | Oct 2003 | A1 |
| 20030217053 | Bachman et al. | Nov 2003 | A1 |
| 20030220707 | Budinger et al. | Nov 2003 | A1 |
| 20030233374 | Spinola | Dec 2003 | A1 |
| 20040078105 | Moon et al. | Apr 2004 | A1 |
| 20040078373 | Ghoneimy et al. | Apr 2004 | A1 |
| 20040078778 | Leymann et al. | Apr 2004 | A1 |
| 20040148213 | Aziz et al. | Jul 2004 | A1 |
| 20040148214 | Aziz et al. | Jul 2004 | A1 |
| 20040153350 | Kim et al. | Aug 2004 | A1 |
| 20040162741 | Flaxer et al. | Aug 2004 | A1 |
| 20040220910 | Zang et al. | Nov 2004 | A1 |
| 20040221261 | Blevins | Nov 2004 | A1 |
| 20040249846 | Randall et al. | Dec 2004 | A1 |
| 20050027585 | Wodtke et al. | Feb 2005 | A1 |
| 20050034098 | DeSchryver et al. | Feb 2005 | A1 |
| 20050050311 | Joseph et al. | Mar 2005 | A1 |
| 20050071209 | Tatavu et al. | Mar 2005 | A1 |
| 20050071347 | Chau et al. | Mar 2005 | A1 |
| 20050114401 | Conkel | May 2005 | A1 |
| 20050132252 | Fifer et al. | Jun 2005 | A1 |
| 20050149908 | Klianev | Jul 2005 | A1 |
| 20050182773 | Feinsmith | Aug 2005 | A1 |
| 20050193286 | Thatte et al. | Sep 2005 | A1 |
| 20050204333 | Denby et al. | Sep 2005 | A1 |
| 20050216482 | Ponessa | Sep 2005 | A1 |
| 20050246692 | Poteryakhin et al. | Nov 2005 | A1 |
| 20060053120 | Shum et al. | Mar 2006 | A1 |
| 20060059253 | Goodman et al. | Mar 2006 | A1 |
| 20060064335 | Goldszmidt et al. | Mar 2006 | A1 |
| 20060074734 | Shukla et al. | Apr 2006 | A1 |
| 20060074735 | Shukla et al. | Apr 2006 | A1 |
| 20060074736 | Shukla et al. | Apr 2006 | A1 |
| 20060112122 | Goldszmidt et al. | May 2006 | A1 |
| 20060143193 | Thakkar et al. | Jun 2006 | A1 |
| 20060206863 | Shenfield et al. | Sep 2006 | A1 |
| 20060271927 | Morales et al. | Nov 2006 | A1 |
| 20070239498 | Shukla et al. | Oct 2007 | A1 |
| 20070239499 | Shukla et al. | Oct 2007 | A1 |
| 20070239505 | Shukla et al. | Oct 2007 | A1 |
| 20080320486 | Bose et al. | Dec 2008 | A1 |
| 20090013089 | Sullivan et al. | Jan 2009 | A1 |
| Number | Date | Country |
|---|---|---|
| 0697652 | Feb 1996 | EP |
| 0953929 | Nov 1999 | EP |
| 1238688 | Sep 2002 | EP |
| 2006215713 | Aug 2006 | JP |
| 0054202 | Sep 2000 | WO |
| 2005033933 | Apr 2005 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20070234129 A1 | Oct 2007 | US |
