Functionality is described for providing a compiled program that can be executed in a parallel and a distributed manner by any selected runtime environment. The functionality includes a compiler module for producing the compiled program based on a dataflow representation of a program (i.e., a dataflow-expressed program). The dataflow-expressed program, in turn, includes a plurality of tasks that are connected together in a manner specified by a graph (such as a directed acyclic graph). The compiler module also involves performing static type-checking on the dataflow-expressed program to identify the presence of any mismatch errors in the dataflow-expressed program. By virtue of this approach, the above-described functionality can identify any errors in constructing the graph prior to its instantiation and execution in a runtime environment.
|
1. A method, performed by physical computing functionality, for producing a compiled program, comprising:
receiving a dataflow-expressed program, the dataflow-expressed program including a plurality of tasks connected together in a manner specified by a graph, each task having at least one input associated with a specified type and an output associated with a specified type; and
in a course of compiling the dataflow-expressed program to a compiled parallel program expressed in a parallel form that is executable by any runtime environment selected from a plurality of candidate runtime environments providing a plurality of computing resources for executing the compiled program in a parallel manner, the compiled parallel program agnostic with respect to features provided by the candidate runtime environments, performing static typechecking on the dataflow-expressed program to identify presence of any mismatch errors in the dataflow-expressed program before the dataflow-expressed program instantiation and execution in the runtime environment to ensure that the nodes of the graph connect together in a permitted manner.
13. An environment for producing and executing a compiled parallel program, comprising:
compilation functionality, implemented by physical computing functionality, for producing the compiled parallel program, the compilation functionality comprising:
a graph-generation module configured to provide a dataflow-expressed program, the dataflow-expressed program including a plurality of tasks connected together in a manner specified by a directed acyclic graph, each task having at least one input associated with a specified type and an output associated with a specified type; and
a compiler module configured to produce the compiled parallel program based on the dataflow-expressed program, the compiled parallel program expressed in a parallel form that is executable by the environment providing a plurality of computing resources for executing the compiled program in a parallel manner, the compiled parallel program agnostic with respect to features provided by a set of candidate runtime environments including the environment, the compiler module comprising:
a type-checking module configured to perform static type-checking on the dataflow-expressed program to identify the presence of any mismatch errors in the dataflow-expressed program before the dataflow-expressed program instantiation and execution in the environment to ensure that the nodes of the directed acyclic graph connect together in a permitted manner.
10. A physical and tangible computer readable storage device, which is not a transitory propagating signal, for storing computer readable instructions, the computer readable instructions providing a type-checking module when executed by one or more processing devices, the computer readable instructions comprising:
logic configured to receive a dataflow-expressed program, the dataflow-expressed program including a plurality of tasks connected together in a manner specified by a graph, each task having at least one input associated with a specified type and an output associated with a specified type, the dataflow express program to be compiled to a compiled parallel program expressed in a parallel form that is executable by any runtime environment selected from a plurality of candidate runtime environments providing a plurality of computing resources for executing the compiled program in a parallel manner, the compiled parallel program agnostic with respect to features provided by the candidate runtime environments; and
logic configured to perform static type-checking on the dataflow-expressed program to statically verify dataflow connections in the graph before the dataflow-expressed program instantiation and execution in the runtime environment to ensure that the nodes of the graph connect together in a permitted manner,
said logic configured to perform static-checking comprising:
logic configured to determine, for each task, whether a type associated with each input that is supplied to the task matches an expected input type; and
logic configured to determine, for each task, whether a number of inputs that are supplied to the task matches an expected number of inputs.
2. The method of
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
receiving at least one selection consideration;
identifying and invoking a scheduler module that is deemed appropriate for executing the compiled program based on said at least one selection consideration; and
running the compiled program in a runtime environment that is associated with the scheduler module that has been selected, as directed by the scheduler module.
8. The method of
at a time of execution of a work item within the compiled program, receiving at last one condition factor;
selecting an instantiation of the work item based on said at least one condition factor; and
performing the work item using the instantiation that is selected.
9. The method of
heuristic information that identifies a user instruction;
amount information that identifies an amount of data to be processed by the work item; or
resource information that identifies amounts and kinds of computing resources that are available to perform the work item.
11. The computer readable storage device of
12. The computer readable storage device of
14. The environment of
15. The environment of
16. The environment of
logic configured to determine, for each task, whether a type associated with each input that is supplied to the task matches an expected input type; and
logic configured to determine, for each task, whether a number of inputs that are supplied to the task matches an expected number of inputs.
17. The environment of
logic configured to receive at least one selection consideration; and
logic configured to identify and invoke a scheduler module that is deemed appropriate for executing the compiled program based on said at least one selection consideration.
18. The environment of
logic configured to receive at last one condition factor at a time of execution of a work item within the compiled program;
logic configured to select an instantiation of the work item based on said at least one condition factor; and
logic configured to perform the work item using the instantiation that is selected.
19. The environment of
heuristic information that identifies a user instruction;
amount information that identifies an amount of data to be processed by the work item; or
resource information that identifies amounts and kinds of computing resources that are available to perform the work item.
|
Technology exists for partitioning a program into components and distributing those components to the computing resources of an execution environment. For example, the execution environment may include a collection of processing cores associated with a single computing device, or a collection of servers associated with a computing cluster, and so on. The computing resources that are invoked can then execute the components in distributed and parallel fashion. This technology may expedite the execution of the user program, especially in those scenarios in which the program involves the processing of a large amount of data.
However, the above-described execution approach complicates the execution of a program. This added complexity, in turn, may lead to errors in the execution of the program which are difficult to identify and fix. Among other possible negative consequences, such runtime errors are “expensive” because they waste computer resources; further, the errors may require substantial debugging effort to correct.
Functionality is described for providing a compiled program that can be executed in a parallel and a distributed manner by a selected runtime environment. The functionality includes a compiler module for producing the compiled program based on a dataflow representation of a user program (referred to herein as a “dataflow-expressed program” for brevity). The dataflow-expressed program, in turn, includes a plurality of tasks that are connected together in a manner specified by a graph (such as a directed acyclic graph). Each task has at least one input associated with a specified type and an output associated with a specified type. As part of its processing, the compiler module operates by performing static type-checking on the dataflow-expressed program to identify the presence of any mismatch errors in the dataflow-expressed program. By virtue of this approach, the above-described functionality can identify any mismatch errors in constructing the graph prior to its instantiation and execution in a runtime environment, thereby reducing or eliminating the occurrence of the above-described types of expensive runtime failures.
According to one illustrative aspect, the static type-checking can involve, for each task, determining whether a type associated with each input matches an expected input type. The static type-checking can also involve determining whether a number of inputs matches an expected number of inputs.
The above approach can be manifested in various types of systems, components, methods, computer readable media, data structures, articles of manufacture, and so on.
This Summary is provided to introduce a selection of concepts in a simplified form; these concepts 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 to limit the scope of the claimed subject matter.
The same numbers are used throughout the disclosure and figures to reference like components and features. Series 100 numbers refer to features originally found in
This disclosure is organized as follows. Section A describes illustrative functionality for producing a compiled program that can be executed in a parallel and a distributed manner by a runtime environment, where that runtime environment is selected from a plurality of candidate runtime environments. The process for producing the compiled program involves performing static type-checking to verify that tasks specified in the program are connected together in a permitted manner. Section B describes one illustrative manner of operation of the functionality of Section A in flowchart form. Section C describes illustrative processing functionality that can be used to implement any aspect of the features described in Sections A and B.
The subject matter described herein is related to the following copending applications: a) application Ser. No. 12/900,705, entitled “RUNTIME AGNOSTIC REPRESENTATION OF USER CODE FOR EXECUTION WITH SELECTED EXECUTION RUNTIME”; b) application Ser. No. 12/900,696, entitled “DYNAMIC DATA AND COMPUTE RESOURCE ELASTICITY”; and c) application Ser. No. 12/900,708, entitled “DECLARATIVE PROGRAMMING MODEL WITH A NATIVE PROGRAMMING LANGUAGE.” All three applications name the inventors of Krishnan Varadarajan and Michael L. Chu, and all three applications were filed on Oct. 8, 2010. All three applications are incorporated by reference herein in their respective entireties.
As a preliminary matter, some of the figures describe concepts in the context of one or more structural components, variously referred to as functionality, modules, features, elements, etc. The various components shown in the figures can be implemented in any manner by any physical and tangible mechanisms. In one case, the illustrated separation of various components in the figures into distinct units may reflect the use of corresponding distinct physical and tangible components in an actual implementation. Alternatively, or in addition, any single component illustrated in the figures may be implemented by plural actual physical components. Alternatively, or in addition, the depiction of any two or more separate components in the figures may reflect different functions performed by a single actual physical component.
Other figures describe the concepts in flowchart form. In this form, certain operations are described as constituting distinct blocks performed in a certain order. Such implementations are illustrative and non-limiting. Certain blocks described herein can be grouped together and performed in a single operation, certain blocks can be broken apart into plural component blocks, and certain blocks can be performed in an order that differs from that which is illustrated herein (including a parallel manner of performing the blocks). The blocks shown in the flowcharts can be implemented in any manner by any physical and tangible mechanisms.
The following explanation may identify one or more features as “optional.” This type of statement is not to be interpreted as an exhaustive indication of features that may be considered optional; that is, other features can be considered as optional, although not expressly identified in the text. Finally, the terms “exemplary” or “illustrative” refer to one implementation among potentially many implementations.
A. Illustrative Functionality
The compilation functionality 102 can be implemented in any manner. For example, the compilation functionality 102 can be implemented by one or more computing devices of any type, such as one or more personal computers, one or more computer workstations, etc. The runtime functionality 108 can likewise be implemented in any manner, such as by one or more computing devices of any type. In one case, the compilation functionality 102 is separate and distinct from the runtime functionality 108. In another case, there is at least a partial overlap between the equipment used to implement the compilation functionality 102 and the equipment used to implement runtime functionality 108.
This section describes the operation of the environment 100 of
A.1. Overview of the Environment
The compilation functionality 102 can include, or can be conceptualized to include, a graph-generation module 110. The graph-generation module 110 receives an input program that is expressed in any original form. The graph-generation module 110 then converts the input program into a program that is represented in terms of a dataflow of tasks (if in fact, the input program is not already expressed in this format). In the terminology used herein, the graph-generation module 110 is said to generate a dataflow-expressed program. To provide this service, the graph-generation module 110 can rely on resources provided by a library module 112. For example, the library module 112 can provide application programming interface (API) modules that can be referenced by the dataflow-expressed program. The below-explanation provides additional details regarding the operation of the graph-generation module 110 and the construction of an illustrative dataflow-expressed program.
A compiler module 114 then converts the dataflow-expressed program into a compiled program, e.g., by converting the instructions in the dataflow-expressed program into a binary form that is executable by one of the runtime environments (104, . . . 106). The compiler module 114 also includes a type-checking module 116. From a high-level standpoint, the type-checking module 116 examines tasks identified in the dataflow-expressed program. The type-checking module 116 ensures that the tasks are connected together in an appropriate manner so that the compiled program will not produce runtime errors when it is executed. Subsection A.2 provides additional illustrative details regarding the operation of the type-checking module 116.
Now referring to the runtime functionality 108, a runtime selection module 118 can optional receive information with respect to one or more selection considerations. Based thereon, the runtime selection module 118 can choose a runtime environment that is deemed appropriate to execute the compiled program. For example, the selection considerations can include any of: a) information regarding the characteristics of the compiled program; b) information regarding an amount of data that is to be processed by the compiled program; c) information regarding the amounts (and kinds) of computing resources that are available to run the compiled program; d) information regarding the express processing instructions identified by a user (or other agent), and so on.
A runtime engine 120 includes a plurality of scheduler modules (e.g., 122, . . . 124) that can be used to execute the compiled program in respective runtime environments. For example, scheduler module A 122 can be invoked to control the execution of the compiled program in runtime environment A 104. Scheduler module n 124 can be invoked to control the execution of the compiled program in runtime environment n 106, and so on.
Each scheduler module can include a graph instantiation module, such as graph instantiation module 126 used by scheduler module A 122. The scheduler module A 122 calls on the graph instantiation module 126 when it is ready to execute a particular work item (e.g., a particular task) specified in the compiled program. In response, the graph instantiation module 126 receives and evaluates information regarding one or more condition factors. Based thereon, the graph instantiation module 126 determines an appropriate instantiation of the work item. The condition factors can correspond to any of the information items identified above (with respect to the selection factors), such as information regarding the amount of data that is expected to be processed by the work item, information regarding the amounts and kinds of available computing resources, and so on. Again, the explanation below provides additional illustrative details regarding the operation of any scheduler module.
Advancing to
For example, in one scenario, the runtime environment 202 corresponds to a single computing machine. In that context, the plural computing resources (204, 206, . . . 208) can correspond to plural central processing cores (e.g., plural CPUs), plural graphics processing units (GPUs), etc. In a second scenario, the runtime environment 202 corresponds to a cluster of computing machines. Here, the plural computing resources (204, 206, . . . 208) correspond to the plural computing machines and/or other processing resources, which can be located at the same site or distributed over plural sites. In a third scenario, the runtime environment 202 corresponds to a more encompassing cloud of computing machines. Here, the plural computing resources (204, 206, . . . 208) correspond to the plural computing machines and/or other processing resources, which can be located at the same site or distributed over plural sites. These scenarios are representative rather than exhaustive; that is, the principles described herein can be implemented in the context of other runtime environments.
In one implementation, the tasks (304, 306, . . . 308) are side-effect free. Further, the tasks (304, 306, . . . 308) do not share data. This means that the tasks (304, 306, . . . 308) are self-contained units. And as such, the processing of one task does not affect the processing of another task, except insofar as the outcome of some tasks may feed into other tasks as input. In addition, the environment 100 as a whole is configured to accommodate the lazy execution of the tasks (304, 306, . . . 308). This means that the runtime environment can execute the tasks when (and if) there is a demand to execute the tasks, and not before.
The dataflow-expressed program 302 as a whole can perform any function, and can be expressed in any programming language. For example, the dataflow-expressed program 302 can represent a high-level application that performs any function, a component of an operating system, and so on.
In this example, a scheduler associated with a particular runtime environment can execute the tasks associated with each sort node (422, 424) when the appropriate input data is supplied to these nodes (422, 424) by the reader node 420. And the merge node 426 can perform its function when it receives the outputs provided by both sort nodes (422, 424). In this particular example, the scheduler can allocate the tasks associated with each sort node (422, 424) to two different computing resources; the two sort tasks can then be performed in a parallel and distributed fashion.
In one particular implementation, each task object is constructed as a wrapper that encapsulates a function. For example, consider the case of the first sort task object 408. The task object 408 identifies an application programming interface (API) 428, labeled as “continue when.” The library module 112 provides the code for such an API 428 (along with all other APIs). From a functional respective, the act of calling the API 428 establishes the sort node 422 in the graph; that node receives input from the reader node 420 and provides output for consumption by the merge node 426.
The function associated with a task can be expressed in any manner. In one particular example, the dataflow-expressed program 402 can be expressed as a C++ program. In this context, the dataflow-expressed program 402 can express a task's function as a C++ Lambda function, which may contain sequential code
Further note that each task object specifies the input(s) associated with each task object, as well as the output associated with each task object. Moreover, each task object specifies the type of each respective input and the type of the output. For example, consider the first sort task object 408. In code element 430, this task object 408 specifies that the task receives a single input having a type “std::vector<int>” (for a vector of integers). In code element 432, this task object 408 also specifies that the task provides a single output having a type “std::vector<int>.” Generally, in a typed system, the type of a data item specifies the manner in which the data item is to be interpreted by a computer system. Due to the type information provided by each task object in
In one implementation, the graph-generation module 110 (of
In another implementation, the graph-generation module 110 can provide an original input program in some other form that may not fully embody the type of graph content shown in
More specifically, the dataflow-expressed program 502 includes a reader task object 504 that performs a reader function; in this case, the reader function also generates data partitions in an appropriate manner. The dataflow-expressed program 502 also includes a sort-merge task object 506 that performs a sorting and merging operation with respect to a particular data partition. The sort-merge task object 506 is implemented using an API 508 labeled “foreach_when.”
In the examples above, the dataflow-expressed program represents a generic program that can be implemented by any runtime environment selected from a plurality of possible candidate runtime environments. In other words, the dataflow-expressed program is not particularly constructed to accommodate the features found in any particular runtime environment, and can therefore be said to be agnostic with respect to the features provided by the available runtime environments. This characteristic provides good user experience, as a user can generate a single user program without taking into consideration the particular strengths and constraints of a target runtime environment. Furthermore, this characteristic expands the applicability of any program developed by the user.
In the merely illustrative case of
A.2. Static-Type-Checking Functionality
As explained in Subsection A.1, the compiler module 114 includes a type-checking module 116 that verifies the integrity of the dataflow-expressed program. From a general standpoint, the type-checking module 116 performs checking to statically verify dataflow connections in the graph represented by the dataflow-expressed program. That is, this checking ensures that the nodes of the graph connect together in a permitted manner.
More specifically, the type-checking module 116 can perform at least the kinds of type-checking operations shown in
The type-checking module 116 will identify this connection as erroneous. This is because the second task is expecting an input that has the type “double.” Yet the first task provides an input of type “int.” In other words, there is an incongruity between the type of input expected by the second task and the type of input that is actually supplied to the second task.
In the example of
When applied to the example of
It is beneficial to detect errors in the compilation stage because the errors may be easier to diagnose and fix at this stage (compared to the runtime stage). Further, it is more resource-efficient (and time-efficient) to identify errors at the compilation stage (compared to the runtime stage). For example, the deployment of a error-prone program in a cluster or cloud environment can potentially waste a significant amount of computing resources.
B. Illustrative Methods
The remaining figures show illustrative procedures and accompanying examples which explain one manner of operation of various features of the environment 100 of
Starting with
In block 906, the compilation functionality 102 compiles the dataflow-expressed program to produce a compiled program. The compiled program may represent a binary executable that can be run in a parallel and distributed manner on any runtime environment selected from among plural candidate runtime environments. In this sense, the compiled program can be said to be agnostic with respect to the eventual runtime environment in which the program is executed.
As part of the compilation process, in block 908, the compilation functionality 102 can perform static type-checking on the dataflow-expressed program.
In block 1106, a particular scheduler module then begins executing the compiled program, starting with a beginning node of a graph represented by the compiled program. More specifically, in block 1106, for each work item that is ready to be processed (e.g., for each task for which input data has been provided), the scheduler module identifies one or more condition factors that have a bearing on the manner in which the work item is to be instantiated by the associated runtime environment. Section A set forth illustrative such condition factors. In block 1108, the scheduler module elastically selects an instantiation of the work item that is deemed most appropriate to implement the work item. In block 1110, the scheduler module implements the work item using the selected instantiation.
Block 1112 indicates that the operations in blocks 1106, 1108, and 1110 can be repeated throughout the execution of the program, e.g., as different work items become available for execution. The dynamic allocation of work items to computing resources is beneficial because it can account for changing conditions within the runtime environment. For example, the dynamic allocation can account for changes in the amount of input data that is expected. The dynamic allocation can also account for computing resources that become enabled and/or disabled throughout the execution of the compiled program.
C. Representative Processing Functionality
The processing functionality 1200 can include volatile and non-volatile memory, such as RAM 1202 and ROM 1204, as well as one or more processing devices 1206 (e.g., one or more CPUs, and/or one or more GPUs, etc.). The processing functionality 1200 also optionally includes various media devices 1208, such as a hard disk module, an optical disk module, and so forth. The processing functionality 1200 can perform various operations identified above when the processing device(s) 1206 executes instructions that are maintained by memory (e.g., RAM 1202, ROM 1204, or elsewhere).
More generally, instructions and other information can be stored on any computer readable medium 1210, including, but not limited to, static memory storage devices, magnetic storage devices, optical storage devices, and so on. The term computer readable medium also encompasses plural storage devices. In all cases, the computer readable medium 1210 represents some form of physical and tangible mechanism.
The processing functionality 1200 also includes an input/output module 1212 for receiving various inputs (via input modules 1214), and for providing various outputs (via output modules). One particular output mechanism may include a presentation module 1216 and an associated graphical user interface (GUI) 1218. The processing functionality 1200 can also include one or more network interfaces 1220 for exchanging data with other devices via one or more communication conduits 1222. One or more communication buses 1224 communicatively couple the above-described components together.
The communication conduit(s) 1222 can be implemented in any manner, e.g., by a local area network and/or wide area network. The communication conduit(s) 1222 can include any combination of hardwired links, wireless links, routers, gateway functionality, name servers, etc., governed by any protocol or combination of protocols.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Varadarajan, Krishnan, Chu, Michael L.
Patent | Priority | Assignee | Title |
10585653, | Oct 08 2010 | Microsoft Technology Licensing, LLC | Declarative programming model with a native programming language |
10592218, | Oct 08 2010 | Microsoft Technology Licensing, LLC | Dynamic data and compute resource elasticity |
10891326, | Jan 05 2017 | International Business Machines Corporation | Representation of a data analysis using a flow graph |
10922348, | Jan 05 2017 | International Business Machines Corporation | Representation of a data analysis using a flow graph |
11158098, | May 31 2017 | International Business Machines Corporation | Accelerating data-driven scientific discovery |
11221877, | Nov 20 2017 | SHANGHAI CAMBRICON INFORMATION TECHNOLOGY CO., LTD | Task parallel processing method, apparatus and system, storage medium and computer device |
Patent | Priority | Assignee | Title |
6182277, | Apr 15 1998 | Oracle International Corporation | Methods and apparatus for declarative programming techniques in an object oriented environment |
6321373, | |||
6457172, | Apr 13 1999 | International Business Machines Corporation | Compiler for supporting multiple runtime data representations |
7000151, | Jul 18 2002 | VALTRUS INNOVATIONS LIMITED | System and method for providing run-time type checking |
7055142, | May 10 2002 | Microsoft Technology Licensing, LLC | Permutation nuances of the integration of processes and queries as processes at queues |
7100164, | Jan 06 2000 | Synopsys, Inc | Method and apparatus for converting a concurrent control flow graph into a sequential control flow graph |
7210145, | Oct 15 2001 | EDSS, Inc. | Technology for integrated computation and communication; TICC |
7401329, | Apr 25 2005 | U-BLOX UK MELBOURN LTD; u-blox AG; U-BLOX MELBOURN LTD | Compiling computer programs to exploit parallelism without exceeding available processing resources |
7415700, | Oct 14 2003 | Hewlett Packard Enterprise Development LP | Runtime quality verification of execution units |
7458066, | Feb 28 2005 | Hewlett Packard Enterprise Development LP | Computer system and method for transferring executables between partitions |
7660884, | Nov 10 2006 | TWITTER, INC | Apparatus, system, and method for generating a resource utilization description for a parallel data processing system |
7676791, | Jul 09 2004 | Microsoft Technology Licensing, LLC | Implementation of concurrent programs in object-oriented languages |
7739663, | May 16 2006 | TWITTER, INC | Method, system and program product for validating a runtime environment |
9600250, | Oct 08 2010 | Microsoft Technology Licensing, LLC | Declarative programming model with a native programming language |
9600255, | Oct 08 2010 | Microsoft Technology Licensing, LLC | Dynamic data and compute resource elasticity |
20030229639, | |||
20040015502, | |||
20040098374, | |||
20040205179, | |||
20050166182, | |||
20070027912, | |||
20070214171, | |||
20070245319, | |||
20080201721, | |||
20080271042, | |||
20080282238, | |||
20090158248, | |||
20090183144, | |||
20090292797, | |||
20090307660, | |||
20090327458, | |||
20100153959, | |||
20100175049, | |||
20100250564, | |||
20120089967, | |||
20120089968, | |||
20120089969, | |||
JP2007328415, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Nov 19 2010 | VARADARAJAN, KRISHNAN | Microsoft Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 025424 | /0571 | |
Nov 19 2010 | CHU, MICHAEL L | Microsoft Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 025424 | /0571 | |
Nov 29 2010 | Microsoft Technology Licensing, LLC | (assignment on the face of the patent) | / | |||
Oct 14 2014 | Microsoft Corporation | Microsoft Technology Licensing, LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034544 | /0001 |
Date | Maintenance Fee Events |
Feb 24 2021 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Date | Maintenance Schedule |
Sep 12 2020 | 4 years fee payment window open |
Mar 12 2021 | 6 months grace period start (w surcharge) |
Sep 12 2021 | patent expiry (for year 4) |
Sep 12 2023 | 2 years to revive unintentionally abandoned end. (for year 4) |
Sep 12 2024 | 8 years fee payment window open |
Mar 12 2025 | 6 months grace period start (w surcharge) |
Sep 12 2025 | patent expiry (for year 8) |
Sep 12 2027 | 2 years to revive unintentionally abandoned end. (for year 8) |
Sep 12 2028 | 12 years fee payment window open |
Mar 12 2029 | 6 months grace period start (w surcharge) |
Sep 12 2029 | patent expiry (for year 12) |
Sep 12 2031 | 2 years to revive unintentionally abandoned end. (for year 12) |