An embodiment of the invention is a technique for maintaining application availability during a change in a resource dynamic link library (dll). A shim resource dll is linked to a resource dll managed by a resource manager in a clustered system. The managed resource dll exports a function to control a resource in the clustered system. During a normal mode, the shim resource dll passes to the managed resource dll a call to an exported function unchanged. During a change mode, the shim resource dll is unlinked from the managed resource dll to allow the managed resource dll to be changed, and the shim resource dll handles a call to an exported function without passing the call to the managed resource dll.
|
8. A system comprising:
a plurality of nodes forming a clustered system, each of the nodes being a computer having a cluster software and a dependency group application, the cluster software including a resource manager and a shim resource dynamic link library (dll), the dependency group application having a resource dll managed by the resource manager; and
a plurality of resources coupled to the plurality of nodes, one of the resources being controlled by a function exported by the managed resource dll;
wherein the shim resource dll is linked to the resource manager and the managed resource dll to pass a call to the exported function to the managed resource dll unchanged during a normal mode and is unlinked from the managed resource dll to allow the managed resource dll to be changed, and to handle a call to the exported function without passing the call to the managed resource dll during a change mode.
1. A method for maintaining application availability during a change of a resource dynamic link library (dll) in a clustered system, the clustered system including a plurality of nodes, each of the nodes being a computer having a cluster software and a dependency group application, the cluster software including a resource manager and a shim resource dynamic link library (dll), the dependency group application having the resource dll managed by the resource manager, the method comprising:
linking the shim resource dll to the managed resource dll, the managed resource dll exporting a function to control a resource in the clustered system;
passing, by the shim resource dll, to the managed resource dll a call to an exported function unchanged during a normal mode; and
during a change mode, the shim resource dll:
unlinking from the managed resource dll to allow the managed resource dll to be changed, and
handling a call to an exported function without passing the call to the managed resource dll.
15. An article of manufacture comprising:
a machine-accessible medium including data that, when accessed by a machine, cause the machine to perform operations comprising:
linking a shim resource dynamic link library (dll) to a resource dll managed by a resource manager in a clustered system, wherein the clustered system including a plurality of nodes, each of the nodes being a computer having a cluster software and a dependency group application, the cluster software including the resource manager and the shim resource dynamic link library (dll), the dependency group application having the resource dll managed by the resource manager, the managed resource dll exporting a function to control a resource in the clustered system;
passing, by the shim resource dll, to the managed resource dll a call to an exported function unchanged during a normal mode; and
during a change mode, the shim resource dll:
unlinking from the managed resource dll to allow the managed resource dll to be changed, and
handling a call to an exported function without passing the call to the managed resource dll.
2. The method of
dynamically linking the shim resource dll to the managed resource dll during an initialization mode or after the change mode.
3. The method of
unlinking the shim resource dll from the managed resource dll to allow the managed resource to be upgraded or replaced with a new resource dll.
4. The method of
5. The method of
6. The method of
7. The method of
9. The system of
10. The system of
11. The system of
12. The system of
13. The system of
14. The system of
16. The article of manufacture of
17. The article of manufacture of
18. The article of manufacture of
19. The article of manufacture of
20. The article of manufacture of
|
|||||||||||||||||||||||||
1. Field of the Invention
Embodiments of the invention are in the field of clustered computer systems, and more specifically, relate to techniques for changing a resource dynamic link library (DLL) in a clustered computer system.
2. Description of Related Art
A cluster is a group of computers that work together to run a common set of applications and appear as a single system to the client and applications. In a traditional cluster, the computers are physically connected by cables and programmatically connected by cluster software. These connections allow the computers to use failover and load balancing, which is not possible with a stand-alone computer.
A clustered system typically has a variety of resources. Clustered resources may include a disk drive, a logical unit on redundant arrays of inexpensive disks (RAIDS) subsystem, an Internet Protocol (IP) address, a network name, an application program, etc. Many clustered systems allow the management of clustered resources in a separate executable library associated with a resource, referred to as a resource dynamic link library (DLL).
When a resource DLL is changed, e.g., upgraded, updated, modified or replaced with a newer version, the associated resource is taken off line or moved to another member computer in the clustered system during the change process. In some clustered systems, each member computer may have to be re-booted in order to complete this resource DLL change process. In a high-availability environment, such as that of a clustered system, such a temporary unavailability of a resource or system interruption may not be acceptable.
Thus, it is desirable to have a technique to provide availability in a clustered system during a change of a resource DLL.
An embodiment of the invention is a technique for maintaining application availability during a change in a resource dynamic link library (DLL). A shim resource DLL is linked to a resource DLL managed by a resource manager in a clustered system. The managed resource DLL exports a function to control a resource in the clustered system. During a normal mode, the shim resource DLL passes to the managed resource DLL a call to an exported function unchanged. During a change mode, the shim resource DLL is unlinked from the managed resource DLL to allow the managed resource DLL to be changed, and the shim resource DLL handles a call to an exported function without passing the call to the managed resource DLL.
Embodiments of the invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:
An embodiment of the invention is a technique for maintaining application availability during a change in a resource dynamic link library (DLL). A shim resource DLL is linked to a resource DLL managed by a resource manager in a clustered system. The managed resource DLL exports a function to control a resource in the clustered system. During a normal mode, the shim resource DLL passes to the managed resource DLL a call to an exported function unchanged. During a change mode, the shim resource DLL is unlinked from the managed resource DLL to allow the managed resource DLL to be changed, and the shim resource DLL handles a call to an exported function without passing the call to the managed resource DLL.
The shim resource DLL is dynamically linked to the managed resource DLL and the resource manager during an initialization mode or after the change mode. The function exported by the managed resource DLL may be one the following: an On_Line function, an Off_Line function, an Is_Alive function, and a Resource Control function. During the change mode, the shim resource DLL returns success to a call to the Is_Alive function, and returns error to any call to one of the On_Line function, the Off_line function, and the Resource Control function. In this manner, the change to the managed resource DLL may be transparent to the operations of the system and availability of application or system is maintained. The resource may be one of a mass storage device, a device driver, a network address, a network name, an application program, a system service, and a system software module.
In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in order not to obscure the understanding of this description.
Elements of one embodiment of the invention may be implemented by hardware, firmware, software or any combination thereof. When implemented in software or firmware, the elements of an embodiment of the present invention are essentially the code segments to perform the necessary tasks. The software/firmware may include the actual code to carry out the operations described in one embodiment of the invention, or code that emulates or simulates the operations. The program or code segments can be stored in a processor or machine accessible medium or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium. The “processor readable or accessible medium” or “machine readable or accessible medium” may include any medium that can store, transmit, or transfer information. Examples of the processor readable or machine accessible medium include an electronic circuit, a semiconductor memory device, a read only memory (ROM), a flash memory, an erasable ROM (EROM), a floppy diskette, a compact disk (CD) ROM, an optical disk, a hard disk. The code segments may be downloaded via computer networks such as the Internet, Intranet, etc. The machine accessible medium may be embodied in an article of manufacture. The machine accessible medium may include data that, when accessed by a machine, cause the machine to perform the operations described above. The machine accessible medium may also include program code embedded therein. The program code may include machine-readable code to perform the operations described above. The term “data” here refers to any type of information that is encoded for machine-readable purposes. Therefore, it may include program, code, data, file, etc.
All or part of an embodiment of the invention may be implemented by hardware, software, or firmware, or any combination thereof. The hardware, software, or firmware element may have several modules coupled to one another. A hardware module is coupled to another module by mechanical, electrical, optical, electromagnetic or any physical connections. A software module is coupled to another module by a function, procedure, method, subprogram, or subroutine call, a jump, a link, a parameter, variable, and argument passing, a function return, etc. A software module is coupled to another module to receive variables, parameters, arguments, pointers, etc. and/or to generate or pass results, updated variables, pointers, etc. A firmware module is coupled to another module by any combination of hardware and software coupling methods above. A hardware, software, or firmware module may be coupled to any one of another hardware, software, or firmware module. A module may also be a software driver or interface to interact with the operating system running on the platform. A module may also be a hardware driver to configure, set up, initialize, send and receive data to and from a hardware device. An apparatus may include any combination of hardware, software, and firmware modules.
One embodiment of the invention may be described as a process, which is usually depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. A loop or iterations in a flowchart may be described by a single iteration. It is understood that a loop index or loop indices or counter or counters are maintained to update the associated counters or pointers. In addition, the order of the operations may be re-arranged. A process terminates when its operations are completed. A process may correspond to a method, a program, a procedure, etc.
The N computer nodes 1101 to 110N form a clustered system. Each of the nodes 1101 to 110N may be a computer or a server. The N computer nodes 1101 to 110N may be homogeneous or heterogeneous. In one embodiment, they have identical cluster software components that may be configured according to the specific environment or platform. The computer node includes a node processor 1201, a node software 1301, and input/output (I/O) unit 1401. Each of the nodes 1101 to 110N may have a local memory, mass storage device, peripheral devices, a network interface device, and any other components, which are not shown for clarity. The N computer nodes 1101 to 110N may be interconnected via an interconnection network/network 160. The interconnection network/network 160 may be any suitable network having any topology such as bus interconnect, hierarchical interconnect, cross-bar switch, hypercube, multi-stage interconnection, Local Area Network (LAN), Wide Area Network (WAN), intranet, extranet, the Internet, wireless network, etc.
The processor 1201 represents a central processing unit of any type of architecture, such as embedded processors, single core processors, multi-core processors, mobile processors, micro-controllers, digital signal processors, superscalar computers, vector processors, single instruction multiple data (SIMD) computers, complex instruction set computers (CISC), reduced instruction set computers (RISC), very long instruction word (VLIW), or hybrid architecture.
The node software 1301 contains the software that is run on the computer node 1101. It includes a cluster software, a resource management software 1351, and application programs. Application programs may include any application programs to perform application-level tasks. They may also include redundant applications that are used to support high availability and fault-tolerant applications. The cluster software is common to all the nodes in the N computer nodes 1101 to 110N. Identical cluster-level software, including cluster operating system and drivers, resides in each of the N computer nodes 1101 to 110N. The resource management software 1351 includes software components or programs that manage the resource group 150. Part of the resource management software 1351 overlaps with the cluster software (see
The resource group 150 includes a number of resources that support the N computer nodes 1101 to 110N. The resource group 150 may include any type of resource that may be utilized by an application program, such as a mass storage device 162, a network address 164, a network name 166, an application program 168. The mass storage device 162 is any non-volatile memory subsystem such as hard disk drive, optical disk, redundant arrays of inexpensive disks (RAID), tape drive, etc. The network address 164 contains the address of the network such as the Internet Protocol (IP) address. The network name 166 is the name of the network. The application 168 is an application program that uses the resource group 150.
The computer node k 110k, where k=2, . . . , N, contains essentially similar components as the computer node 1101. For example, the computer node N 110N includes a node processor 120N, a node software 130N, and an I/O unit 140N. These components are similar to the node processor 1201, the node software 1301, and the I/O unit 1401 described above.
The cluster service module 210 includes software, programs, or functions that provide clustering service for the clustered system. It is part of a cluster software such as the Microsoft Cluster Service (MSCS).
The resource manager 220 provides a communication, monitoring, and processing layer between the cluster service 210 and one or more resources. The resource manager 220 is also part of the cluster software. The resource manager 220 manages the use of the resource group 150 (shown in
The application dependency group 230 includes grouping of resources used by an application program. It interfaces with and supported by the individual resource DLLs that control the respective resources within the application dependency group 230. The managed resource DLL 250 may be any one of these individual resource DLLs. When any resource within the group 230 fails, the cluster software attempts to move the group 230 to another computer node in the cluster. For example, when a cable connecting a disk drive fails, the disk resource DLL detects that it can no longer access the disk drive. It then sets the status of the disk resource as failed and notifies the cluster software. The cluster software, upon receipt of the failure notification, brings the application dependency group 230 on line on another computer node of the clustered system.
The shim resource DLL 240 of the present invention provides a communication and processing layer between the resource manager 220 and the managed resource DLL 250 to maintain availability of the application that uses the resource supported by the managed resource DLL 250 during a change of the managed resource DLL 250. The shim resource DLL 240 is linked to the resource manager 220 and the managed resource DLL 250. The shim resource DLL 240 may have a number of operational modes. It may pass to the managed resource DLL 250 a call to a function 245 exported from the managed resource DLL 250. It may receive a function status from the function 245. It may also return a function status to the resource manager 220.
The function 245 is associated with a resource controlled by the managed resource DLL 250. The function 245 may be called by the cluster service 210, via the resource manager 220, or by an application program via the cluster service 210, to perform a control function on the specified resource. It may return a status of the operation. The status may be a success status, an error or failure status, or other status.
The managed resource DLL 250 is a resource DLL that is managed by the resource manager 220. The managed resource DLL 250 is associated with and supports one of the resources in the resource group 150 (shown in
In one embodiment of the invention, the managed resource DLL 250 is a custom resource DLL created using the Microsoft Visual C++® development system. Microsoft Corporation has published a number of Technical Articles for Writing Microsoft Cluster Server (MSCS) Resource DLLs. These articles describe in detail how to use the Microsoft Visual C++® development system to develop resource DLLs. Resource DLLs are created by running the “Resource Type AppWizard” of Microsoft Corporation within the developer studio. This builds a skeletal resource DLL and/or Cluster Administrator extension DLL. The skeletal resource DLL provides only the most basic capabilities. The skeletal resource DLL is then customized to produce the managed resource DLL 250.
The On_Line function 310 brings the resource on line, i.e., starts the resource and makes it available to the clustered system. It is typically used during initialization, failover, moving an application, or after a change of the resource DLL. The Off_Line function 320 takes the resource off line, i.e., performs a graceful shutdown of the resource. It is typically used when a failure is detected or when moving an application to another computer node in the clustered system. The Is_Alive function 330 determines if a resource is actually operational. It is typically used during periodic checking of “heartbeats”. The Resource Control function 340 provides resource specific control operation. It provides for resource specific directives to be sent to the resource DLL 250.
Typically, the On_Line and Off_Line functions 310 and 320 are used rarely. The Resource Control function 340 is also not used frequently. The Is_Alive function 330, however, is used much more frequently. It may be called as often as once per second to monitor the health or status of the resource to ensure that the resource is operational. The Is_Alive function 330 represents functions that are frequently called. The On_Line function 310, the Off_Line function 320, and the Resource Control function 340 represent functions that are non-frequently called.
The On_Line and Off_Line functions 310 and 320 and the Is_Alive function 330 may be used during a failover in which resources may be moved across the cluster from one computer node to another computer node, or in an application migration where an application is moved across the cluster. A typical failover scenario is as follows. The cluster software on a first computer node detects a failed resource as a result of periodic calls to the Is_Alive function 330. The cluster software on the first computer node then calls the Off_Line function 320 for all other resources in the same application dependency group as the failed resource. Then, on a second computer, the cluster software calls the On_Line function 310 of all the resources in the dependency group. When all the resources have come on line on the second computer, the failover is complete. A typical application migration is similar to the failover scenario except that no failure is detected. When the cluster administrator moves an application, the cluster software on the first computer node calls the Off_Line function 320 for all resources in the application's dependency group. Then, on a second computer, the cluster software calls the On_Line function 310 of all the resources in the dependency group. When all the resources have come on line on the second computer, the application migration is complete.
The initialization mode 410 is a mode in which the resource management software 135 (shown in
The normal mode 420 is a mode in which the system or the managed resource DLL 250 operates normally or when the managed resource DLL 250 is not being changed, upgraded, updated, modified, or replaced. In this mode, the shim resource DLL 240 exports the same control functions as the managed resource DLL 250. It passes a call to an exported function (e.g., the On_Line function 310, the Off_Line function 320, the Is_Alive function 330, and the Resource Control function 340 shown in
The change mode 430 is a mode in which the managed resource DLL 250 is changed, such as when it is upgraded, updated, modified, or replaced by a new resource DLL. During this mode, it is desirable to keep the application program continuing to function without being taken down to maintain availability. In this mode, the shim resource 240 invokes an unlink module 440 and then a handle module 450. The unlink module 440 unlinks the shim resource DLL 240 from the managed resource DLL 250 to allow the managed resource DLL 250 to be changed. When the shim resource DLL 240 is unlinked from the managed resource DLL 250, it frees the managed resource DLL 250 for upgrade or replacement. The managed resource DLL 250 may be upgraded by a module 442 or replaced by a new version by a module 444. The modules 442 and 444 may be performed by another program or module. The handle module 450 handles a call to an exported function without passing the call to the managed resource DLL 250. By continuing handling calls to exported functions, the shim resource DLL 240 keeps the application program operational and avoids temporary interruption caused by change to the managed resource DLL 250. The handle module 450 performs its function by a success return module 452 and an error return module 454. The success return module 452 returns success to the calling program when the called exported function is a frequently called function such as the Is_Alive function 330. The error return module 454 returns error to the calling program when the called exported function is a non-frequently called function such as the On_Line function 310 or the Off_Line function 320 or the Resource Control function 340. Since the On_Line function 310, the Off_Line function 320, and the Resource Control function 340 are not called frequently, the probability that they are called when the managed resource DLL 250 is being changed is very low.
From the change mode, the shim resource DLL returns to the normal mode when a Resource Administration program calls the Resource Control function with appropriate implementation-specific control codes.
Upon Start, process 500 links to the managed resource DLL managed by the resource manager in a clustered system (Block 502). Process 500 may also link to the resource manager if it has not been linked. Process 500 is then terminated.
Upon Start, process 600 receives a call to the Resource Control function to enter the change mode (Block 602). Next, the process 600 determines if the current mode is the change mode (Block 604). If the current mode is already the change mode, the process 600 returns error (Block 606) and is then terminated. If the current mode is not the change mode, the process 600 unlinks from the managed resource DLL to allow it to be changed (Block 608), returns success (Block 610) and is then terminated. The managed resource DLL may be changed by being upgraded, modified, or replaced with a new version.
Upon Start, process 700 receives a call to the Resource Control function to exit the change mode (Block 702). Next, the process 700 determines if the current mode is the change mode (Block 704). If the current mode is not the change mode, the process 600 returns error (Block 706) and is then terminated. If the current mode is the change mode, process 500 links to the managed resource DLL managed by the resource manager in the clustered system (Block 708). Process 700 returns success (Block 710) and is then terminated. The managed resource DLL may be changed by being upgraded, modified, or replaced with a new version.
Upon START, process 800 receives a call to an exported function (Block 802). Next, the process 800 determines if the current mode is the change mode (Block 804). If the current mode is not the change mode, process 800 passes the call to the exported function to the managed resource DLL unchanged (Block 806) and is then terminated. If the current mode is the change mode, process 800 determines if the exported function being called is the Is_Alive function (Block 808). If it is the Is_Alive function, the process 800 returns success to the calling program (Block 812), and is then terminated. Otherwise, this means that the exported function being called is one of the On_Line function, the Off_Line function, and the Resource Control function; in this situation, the process 500 returns error to the calling program (Block 810), and is then terminated.
While the invention has been described in terms of several embodiments, those of ordinary skill in the art will recognize that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.
Legg, Chris B., Moreno, Brenda Ann
| Patent | Priority | Assignee | Title |
| 8839256, | Jun 09 2010 | International Business Machines Corporation | Utilization of special purpose accelerators using general purpose processors |
| 9141919, | Feb 26 2010 | International Business Machines Corporation | System and method for object migration using waves |
| 9489286, | Jan 30 2013 | NEC Corporation | Method and system for computer assisted hot-tracing mechanism |
| Patent | Priority | Assignee | Title |
| 6438705, | Jan 29 1999 | Pure Storage, Inc | Method and apparatus for building and managing multi-clustered computer systems |
| 6442752, | Aug 26 1999 | Unisys Corporation | METHOD, APPARATUS, AND COMPUTER PROGRAM PRODUCT FOR REPLACING A DYNAMIC LINK LIBRARY (DLL) OF A FIRST COMPUTING ENVIRONMENT WITH A DLL OF A SECOND COMPUTING ENVIRONMENT THAT CAN BE INVOKED FROM THE FIRST COMPUTING ENVIRONMENT IN A TRANSPARENT MANNER |
| 6665735, | Oct 06 1997 | Kabushiki Kaisha Toshiba | Method of changing a dynamic link library function efficiently and a computer system for executing the same |
| 7461374, | Dec 01 2003 | Cisco Technology, Inc | Dynamic installation and activation of software packages in a distributed networking device |
| 20020073410, | |||
| 20020194578, | |||
| 20030074426, | |||
| 20040254984, | |||
| 20050010915, | |||
| 20050071837, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Jun 17 2005 | Unisys Corporation | (assignment on the face of the patent) | / | |||
| Jun 17 2005 | LEGG, CHRIS B | Unisys Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 016719 | /0965 | |
| Jun 17 2005 | MORENO, BRENDA ANN | Unisys Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 016719 | /0965 | |
| May 31 2006 | UNISYS HOLDING CORPORATION | CITIBANK, N A | SECURITY AGREEMENT | 018003 | /0001 | |
| May 31 2006 | Unisys Corporation | CITIBANK, N A | SECURITY AGREEMENT | 018003 | /0001 | |
| Jun 01 2009 | CITIBANK, N A | UNISYS HOLDING CORPORATION | RELEASE BY SECURED PARTY | 023086 | /0255 | |
| Jun 01 2009 | CITIBANK, N A | Unisys Corporation | RELEASE BY SECURED PARTY | 023086 | /0255 | |
| Feb 24 2010 | Unisys Corporation | DEUTSCHE BANK | SECURITY AGREEMENT | 024351 | /0482 | |
| Jun 23 2011 | Unisys Corporation | GENERAL ELECTRIC CAPITAL CORPORATION, AS AGENT | SECURITY AGREEMENT | 026509 | /0001 | |
| Nov 27 2012 | DEUTSCHE BANK TRUST COMPANY AMERICAS, AS COLLATERAL TRUSTEE | Unisys Corporation | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 030082 | /0545 | |
| Nov 27 2012 | DEUTSCHE BANK TRUST COMPANY | Unisys Corporation | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 030004 | /0619 | |
| Apr 17 2017 | Unisys Corporation | WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATERAL TRUSTEE | PATENT SECURITY AGREEMENT | 042354 | /0001 | |
| Oct 05 2017 | WELLS FARGO BANK, NATIONAL ASSOCIATION SUCCESSOR TO GENERAL ELECTRIC CAPITAL CORPORATION | Unisys Corporation | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 044416 | /0358 | |
| Oct 05 2017 | Unisys Corporation | JPMORGAN CHASE BANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 044144 | /0081 | |
| Mar 19 2020 | Wells Fargo Bank, National Association | Unisys Corporation | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 054231 | /0496 |
| Date | Maintenance Fee Events |
| May 24 2013 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| May 24 2017 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| May 24 2021 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
| Date | Maintenance Schedule |
| Nov 24 2012 | 4 years fee payment window open |
| May 24 2013 | 6 months grace period start (w surcharge) |
| Nov 24 2013 | patent expiry (for year 4) |
| Nov 24 2015 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Nov 24 2016 | 8 years fee payment window open |
| May 24 2017 | 6 months grace period start (w surcharge) |
| Nov 24 2017 | patent expiry (for year 8) |
| Nov 24 2019 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Nov 24 2020 | 12 years fee payment window open |
| May 24 2021 | 6 months grace period start (w surcharge) |
| Nov 24 2021 | patent expiry (for year 12) |
| Nov 24 2023 | 2 years to revive unintentionally abandoned end. (for year 12) |