Imperative programming is a computer programming paradigm that describes computation as a series of statements that change a program state. Imperative programming can be contrasted with functional programming, which avoids state and mutable data. For example, purely functional programs have no side effects, which are modifications of some state while returning a value. On the other hand, a purely functional program can do nothing because without side effects a program accepts no input, produces no output, and does not interface with external devices. Imperative programming uses side effects to implement state and input/output functions. Accordingly, many programmers and software development engineers are most familiar with imperative programming and often these programmers take for granted that data structures change over time.
Mutability was less of a concern in programming for single processor architectures. Mutability is a challenge, however, in the now ubiquitous concurrent (such as multiprocessor or parallel) processing architectures. Adding immutability to existing imperative, or mutability-oriented, programming languages such as C++, C#, Visual Basic, and Java, can simplify imperative programming in concurrent architectures. A major difficulty in building concurrent systems today is related to how an imperative system approaches ever-changing states.
Many programmers attempt to address the issue of mutability through the creation of “locks” of the state, and synchronization to control concurrent reads and writes of states. Locks are used on an object when the program only desires to inspect a state to avoid changing the state during inspection. Locks and synchronization lead to recursive lock acquisitions, deadlocks, additional overhead, and other undesireable affects. Further, locks and synchronization can create related problems such as races.
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 to limit the scope of the claimed subject matter.
In one embodiment, an imperative framework having more than one type is defined. At least one of the types is an immutable type, and the immutable type has at least one immutable field.
The accompanying drawings are included to provide a further understanding of embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and together with the description serve to explain principles of embodiments. Other embodiments and many of the intended advantages of embodiments will be readily appreciated, as they become better understood by reference to the following detailed description. The elements of the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding similar parts.
In the following Detailed Description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims. It is also to be understood that features of the various exemplary embodiments described herein may be combined with each other, unless specifically noted otherwise.
Computing device 100 can also have additional features/functionality. For example, computing device 100 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or solid state memory, or flash storage devices such as removable storage 108 and non-removable storage 110. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any suitable method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory 104, removable storage 108 and non-removable storage 110 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, universal serial bus (USB) flash drive, flash memory card, or other flash storage devices, or any other medium that can be used to store the desired information and that can be accessed by computing device 100. Any such computer storage media may be part of computing device 100.
Computing device 100 includes one or more communication connections 114 that allow computing device 100 to communicate with other computers/applications 115. Computing device 100 may also include input device(s) 112, such as keyboard, pointing device (e.g., mouse), pen, voice input device, touch input device, etc. Computing device 100 may also include output device(s) 111, such as a display, speakers, printer, etc.
The computing system 100 can be configured to run an operating system software program and one or more software applications, which make up a system platform. In one example, the computing system 100 includes a software component referred to as a managed environment. The managed environment can be included as part of the operating system or can be included later as a software download. The managed environment typically includes pre-coded solutions to common programming problems to aid software developers to create software programs such as applications to run in the managed environment, and it also typically includes a virtual machine that allows the software applications to run in the managed environment so that the programmers need not consider the capabilities of the specific processors 102.
The hardware implementation of computing device 100 is imperative and is designed to execute machine readable code 138, written in an imperative style. Imperative programming is known in the art as a programming paradigm that describes computation as statements that change a program state. For example, imperative programs are a sequence of commands for the computer to perform. The program state is defined by the contents of memory, such as memory 104, and the statements are instructions in the native machine language 138 of the computing device 100. Higher-level imperative languages, such as the C# 124, VB.NET 126, and J# 128 use variables and more complex statements, but still follow the same paradigm.
Mutable types are prevalent in imperative programming languages, and a mutable type is one where instances can change over time. In contrast, an immutable type is one where post-construction changes are not possible. One example used to establish an immutable type in an imperative language is the creation of support for “initonly” fields. Initonly indicates that variable assignment can only occur as part of the declaration or in a static constructor in the same class. An initonly field is one which is not written to once the object on which that field resides has been fully constructed. In this context, fully constructed means the constructer of the object has finished executing. Imperative languages can include a type system support that verifies this property, and reject programs that do not adhere to the rules. In C#, support for initonly fields includes readonly. In an example illustration of initonly, the program can only read a copy, and can not access the pointer (address) so that every operation is performed on the copy.
Based on initonly and the presence of the type system verification, several rules can be put in place. An example is an immutable attribute to be applied to types. In fictional C# syntax:
In this example syntax, the instances of String, once created, will never change. Annotating a type with an immutable attribute indicates that the objects of that type are immutable. The type could be subject to rules or restriction.
An example rule is where [Rule 1] “Fields of immutable types are initonly,” such as the readonly keyword in C#. As an example, applying this to the String type being created as above provides:
These fields are assigned to in the constructor of the program, as per initonly rules. As such Rule 1 provides for a first level of immutability takes advantage of type system and language support for initonly fields.
Another example rule is where [Rule 2] “The types used as fields in an immutable type are also immutable.” Rule 2 provides for transitivity, i.e., transitive immutability, or another level of immutability under the level of Rule 1. Applying Rule 2 to the example above, the String only references type which the state also does not change after the String has been constructed, e.g. int and LinkedList<char>. The types are initialized to have been fully completed in the constructor of String. For example:
The mutability of a complex object is often but not always, comprised of its own field and also the state in the objects it refers to. Rules 1 and 2 cover a vast majority of immutable situations.
One extension of Rule 2 provides that [Rule 3] “Immutable types should not derive from mutable types.” In practice, this rule is perhaps stronger than needed, but it is effective. A policy behind this rule is that the immutability of a derived type is not affected with mutations in the base type. A related extension of Rule 2 can be achieved with a rule that relaxes the conditions of Rule 3 where [Rule 3a] “An immutable type does not override any virtual members and does not access fields from a base type.” In another example, Rule 3 can be relaxed in cases of certain immutability transparent types. These are types that are not immutable, e.g., the type does not require that all subclasses are immutable, but they do not have observable immutability. Therefore, they can be suitable of which to base off immutable types. Accordingly, Rule 3b can be “Base types can be immutability transparent such as objects.” Two examples in the current type system are System.Object and System.VaueType available from Microsoft Corp.
Another extension of Rule 2, and related to Rules 3, 3a, or 3b is [Rule 4] “Mutable types should not derive from immutable types.” A mutable type that can derive from an immutable type could override behavior in such a way that the base type appears to have become mutable. This could be the case if a virtual method on an immutable base type is overridden to add mutability. This can appear deceptive even if fields of the base type have not been modified because the behavior was accessed through a virtual member of the immutable type. In one example, the public immutable types are sealed to prevent outside classes that do not abide by the immutability analysis from breaking up code that relies on a given type being immutable. In another example, virtual members are eliminated.
Rule 5 provides that “Immutable types can not share ‘this’ reference during construction.” Although it is considered undesirable programming practice, the ‘this’ references is accessible to a constructor and all of the code it calls, and can thus be published to other threads before construction is complete. If this would happen for an immutable object, other threads may observe it an entirely invalid state thus breaking several assumptions that an immutable type in an imperative language seeks to set out. As an example, another thread may read the fields of an object before the fields have been initialized, and this would cause issues with establishing immutability.
Verification of Rule 5 is difficult for a system where all code called from a constructor is statically known and can be analyzed; although it is still possible to verify. In other systems, such as the .NET framework, over-conservative restrictions can be placed on the code callable during construction. In general, these restrictions can include
(1) Code can be analyzed for stores of the ‘this’ reference, which can be made illegal.
(2) Code can be analyzed for aliasing the ‘this’ reference. This can be made legal, but if alias analysis is unable to track a reference for any reason, it can be made illegal.
(3) Static method calls made from the constructor can be traced recursively and checked.
(4) Dynamic method calls, such as function pointer delegate or virtual method can be made illegal.
Object reference published prior to the initialization of its fields can also devolve into the problems mentioned with regard to Rule 5. Therefore, the writing of a reference to an immutable object can imply a store-release barrier in the memory module. Accordingly, [Rule 6] provides for “Publication of a immutable objects implies a memory module barrier.” The memory of .NET 2.0 from Microsoft Corp. provides for this by default, but managed environments, such as Java Memory Module from Sun Microsystems and the ECMA .NET (standardized by Ecma International) memory module, do not include this feature. In these cases, extra compiler support can be provided to safeguard against publication prior to the initialization of fields.
In cases where transitive immutability is not needed, the rules can be relaxed even further. For example, [Rule 7] provides that “Fields may be immutable if transitive immutability is not needed.” For example, a list can refer to the individual elements, but does not need to mutate them. It is illegal, however, for the list to accept a comparer that can cast the elements and mutate them. Although irregular and technically illegal, some mutable fields can be used as an optimization technique that also provides the appearance of semantic provider of immutability. For example, an array of chars in the String type above can be used because a linked list incurs much space overhead for each character. Mechanisms such as a mutable field modifier can be provided as long as the characters are not mutated in such a way that users of the String class can observe the mutability.
Still further, [Rule 8] provides “Generic type constraints can specify immutability.” The language support can also provide for generic constraints that indicate the only suitability type arguments are either immutable or mutable. For example, for an immutable list to have a safe comparer, the element type arguments of the list can be constrained to immutable types, such as with the syntax:
class ImmutableList<T> where T is immutable { . . . }
Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the specific embodiments discussed herein. Therefore, it is intended that this invention be limited only by the claims and the equivalents thereof.
Number | Name | Date | Kind |
---|---|---|---|
5075845 | Lai et al. | Dec 1991 | A |
5175851 | Johnson et al. | Dec 1992 | A |
5375215 | Hanawa et al. | Dec 1994 | A |
5454108 | Devarakonda et al. | Sep 1995 | A |
5459871 | Van Den Berg | Oct 1995 | A |
5682537 | Davies et al. | Oct 1997 | A |
5787431 | Shaughnessy | Jul 1998 | A |
6009269 | Burrows et al. | Dec 1999 | A |
6092156 | Schibinger et al. | Jul 2000 | A |
6182277 | DeGroot et al. | Jan 2001 | B1 |
6542891 | Loen et al. | Apr 2003 | B1 |
6601120 | Schimmel | Jul 2003 | B1 |
6604109 | Federighi et al. | Aug 2003 | B1 |
6721747 | Lipkin | Apr 2004 | B2 |
6810363 | Newman et al. | Oct 2004 | B2 |
6817009 | Flanagan et al. | Nov 2004 | B2 |
6925638 | Koved et al. | Aug 2005 | B1 |
7013469 | Smith et al. | Mar 2006 | B2 |
7058655 | Goldberg et al. | Jun 2006 | B2 |
7086065 | Yeluripati et al. | Aug 2006 | B1 |
7165150 | Alverson et al. | Jan 2007 | B2 |
7188344 | Blue | Mar 2007 | B1 |
7209918 | Li | Apr 2007 | B2 |
7240331 | Vion-Dury et al. | Jul 2007 | B2 |
7316005 | Qadeer et al. | Jan 2008 | B2 |
7437741 | Crisan et al. | Oct 2008 | B2 |
7469403 | Choi et al. | Dec 2008 | B2 |
8032859 | Meijer et al. | Oct 2011 | B2 |
8316369 | Laksberg et al. | Nov 2012 | B2 |
8380965 | Bouillet et al. | Feb 2013 | B2 |
8495329 | Duffy et al. | Jul 2013 | B2 |
8566544 | Gustafsson et al. | Oct 2013 | B2 |
20020107874 | DeLorme et al. | Aug 2002 | A1 |
20030135576 | Bodin | Jul 2003 | A1 |
20040205392 | Wu | Oct 2004 | A1 |
20050108695 | Li et al. | May 2005 | A1 |
20050149914 | Krapf et al. | Jul 2005 | A1 |
20050198619 | Crisan et al. | Sep 2005 | A1 |
20060015528 | Hejlsberg et al. | Jan 2006 | A1 |
20060156286 | Morgan et al. | Jul 2006 | A1 |
20060248131 | Marwinski et al. | Nov 2006 | A1 |
20070005658 | Myllymaki | Jan 2007 | A1 |
20070078890 | Hsu et al. | Apr 2007 | A1 |
20070130621 | Marinescu et al. | Jun 2007 | A1 |
20070143335 | Antoch et al. | Jun 2007 | A1 |
20070261043 | Ho et al. | Nov 2007 | A1 |
20070282916 | Albahari et al. | Dec 2007 | A1 |
20070288538 | Bacon et al. | Dec 2007 | A1 |
20080077922 | Doring | Mar 2008 | A1 |
20080162552 | Bonev et al. | Jul 2008 | A1 |
20080163124 | Bonev et al. | Jul 2008 | A1 |
20080209433 | McKenney | Aug 2008 | A1 |
20080222602 | Vaziri-Farahani et al. | Sep 2008 | A1 |
20080313613 | Bierhoff et al. | Dec 2008 | A1 |
20090138850 | Yamaoka | May 2009 | A1 |
20090193417 | Kahlon | Jul 2009 | A1 |
20090198899 | Revanuru | Aug 2009 | A1 |
20090328047 | Li et al. | Dec 2009 | A1 |
20100262801 | Duffy et al. | Oct 2010 | A1 |
20100275191 | Duffy et al. | Oct 2010 | A1 |
20110161604 | Laksberg et al. | Jun 2011 | A1 |
20110161610 | Gustafsson et al. | Jun 2011 | A1 |
20110161962 | Laksberg et al. | Jun 2011 | A1 |
20140108438 | Duffy et al. | Apr 2014 | A1 |
Number | Date | Country |
---|---|---|
101055518 | Oct 2007 | CN |
101082866 | Dec 2007 | CN |
1019980079611 | Nov 1998 | KR |
0203198 | Jan 2002 | WO |
W02005043388 | May 2005 | WO |
2006039239 | Apr 2006 | WO |
Entry |
---|
BEA “WebLogic Integration 2.1 documentation: Class SOMType”, 2000, pp. 1-14, [online][retrieved on May 29, 2013]. Retrieved from <http://docs.oracle.com/cd/E13214—01/wlintegration/v2—1/classdocs/com/bea/schema/type/SOMType.html>. |
Prentice Hall “Visual C++® 2008: How to Program, Second Edition” by: P. J.Deitel & Associates, Dec. 31, 2007, p. 445. |
Tschantz, et al., “Javari: Adding Reference Immutability to Java”, Proceedings of the 20th annual ACM SIGPLAN conference on Object oriented programming systems languages and applications, vol. 40, Issue 10 Oct. 2005, pp. 211-214. |
Zibin, et al., “Object and Reference Immutability using Java Generics”, Computer Science and Artificial Intelligence Laboratory Technical Report, Mar. 16, 2007, 14 pages. |
Michael D. Ernst, “Annotations on Java Types”, Nov. 12, 2007, pp. 1-34. |
Jan Schafer, “Encapsulation and Specification of Object-Oriented Runtime Components”, Sep. 30, 2004, 89 pages. |
Artzi, et al., “Combined Static and Dynamic Mutability Analysis”, Computer Science and Artificial Intelligence Laboratory Technical Report, Mar. 23, 2007, 19 pages. |
“International Search Report & Written Opinion for PCT Patent Application No. PCT/US2013/065139”, Mailed Date: Jan. 30, 2014, Filed Date: Oct. 15, 2013, 8 Pages. |
Stasenko, Igor, “Re: [squeak-dev] Re: The solution of (Was: Creating An Image From First Principles)”, retrieved at http://www.nabble.com/Re:—squeak-dev—Re:-The-solution-of-(Was:-Creating-an-image-from-first-principles)- p18860090.html, Aug. 7, 2008, pp. 3. |
Garg, et al., “Type-Directed Concurrency”, retrieved at <<http://citeseerx.ist.psu.edu/viewdoc/summary? doi=10.1.1.61.1659>>, pp. 1-15. Aug. 2005. |
Aditya, et al., “A Type System for Functional Imperative Programming (Technical Summary)”, retrieved at <<http:// csg.csail.mit.edu/pubs/memos/Memo-368/memo-368.pdf>>, Jul. 1994, pp. 19. |
Gifford, et al., “Integrating Functional and Imperative Programming”, retrieved at <<http://delivery.acm.org/10.1145/320000/319848/p28-gifford.pdf? key1=319848&key2=3891481321&coll=GUIDE&d1=GUIDE&CFID=17666327&CFTOKEN=64628890>>, ACM, 1986, pp. 28-38. |
Beckman, Nels E., “Verifying Correct Usage of Atomic Blocks using Access Permissions”, retrieved at <<http://www.cse.unl.edu/-grother/isstadoc-papers/beckman.pdf>>, pp. 4. 0ct. 23, 2008. |
Flanagan, et al., Types for Safe Locking, retrieved at <<http://citeseerx.ist.psu.edu/viewdoc/summary? doi=10.1.1.36.849, pp. 18. Oct. 16, 2009. |
The Office Action for U.S. Appl. No. 12/429,874 mailed Mar. 29, 2012 (19 pgs). |
The International Preliminary Report on Patentability for International Application No. PCT/US2010/029716 mailed Oct. 27, 2011 (6 pages). |
The Final Office Action for U.S. Appl. No. 12/429,874 mailed Oct. 26, 2012 (21 pgs). |
Yi Lu and John Potter, “On Ownership and Accessibility” 2006, Springer-Verlag Berlin Heidelberg, 25 Pages. |
The Office Action for U.S. Appl. No. 12/429,874 mailed Jan. 31, 2014 (22 pgs). |
Boyapati et al.,“Ownership Types for Object Encapsulation,” Jan 15-17 2003, 11 pages. |
The International Search Report, Mailed Date: Nov. 4, 2010, Application No. PCT/US2010/029716, Filed Date: Apr. 1, 2010, pp. 6. |
The Written Opinion, Mailed Date: Nov. 4, 2010, Application No. PCT/US2010/029716, Filed Date: Apr. 1, 2010, pp. 4. |
The Office Action for U.S. Appl. No. 12/422,764 mailed Aug. 1, 2011 (20 pgs). |
The Final Office Action for U.S. Appl. No. 12/422,764 mailed Dec. 15, 2011 (15 pgs). |
The Office Action for U.S. Appl. No. 12/422,764 mailed Oct. 25, 2012 (18 pgs). |
Zibin, Yoav et al., “Object and Reference Immutability Using Java Generics,” Proceedings of the 6th Joint Meeting of the European Software Engineering Conference and the ACM Sigsoft Symposium on the Foundations of Software Engineering, pp. 10 (Jan. 2007). |
The Supplemental European Search Report for Application No. EP 10 76 4898 mailed Dec. 18, 2012 (9 pgs). |
The Notice of Allowance for U.S. Appl. No. 12/422,764 mailed Mar. 18, 2013 (10 pgs). |
First Office Action received in China Patent Application No. 201 080017093.9, Mailed Date: Nov. 4, 2013, Filed Date: Apr. 1,2010, 14 Pages. |
Bierhoff, et al., “Modular Typestate Checking of Aliased Objects”, in Proceedings of the 22nd Annual ACM 2 SIGPLAN Conference on Object-oriented Programming Systems and Applications, vol. 42, Issue 10, Oct. 25, 2007, pp. 301-320. |
Office Action Received in European Patent Application No. 10764898.2, Mailed Date: Feb. 3, 2014, Filed Date: Apr. 1, 2010, 5 Pages. |
Colin S. Gordon, et. al., “Uniqueness and Reference Immutability for Safe Parallelism”, University of Washington, US 20 pages, (Oct. 19-26, 2012). |
The Office Action dated Jun. 20, 2013 cited in U.S. Appl. No. 12/649,255. |
The Notice of Allowance for U.S. Appl. No. 12/649,252 mailed Jun. 24, 2013 (13 pages). |
The Office Action dated Apr. 10, 2012 cited in U.S. Appl. No. 12/649,254. |
The Notice of Allowance dated Aug. 8, 2012 cited in U.S. Appl. No. 12/649,254. |
The Office Action for U.S. Appl. No. 12/649,252 mailed Mar. 4, 2013 (9 pages). |
Thought Exercise: Axum + F#: Isolation, Agents, and Message-passing in .Net—Published Date: Mar. 31, 2009 http://blogs.msdn.com/maestroteam/ (26 pages). |
Stork et al., Concurrency by Default Using Permissions to Express Dataflow in Stateful Programs—Published Date: Oct. 25-29, 2009 http://www.cs.cmu.edu/-aldrich/papers/onward2009-concurrency.pdf (8 pages). |
Isolation in Maestro: Isolation, Agents, and Message-passing in .Net—Published Date: 2009 http://blogs.msdn.com/maestroteam/archive/2009/02/27/isolation-in-maestro.aspx (7 pages). |
Axum, Microsoft's Approach to Parallelism—Published Date: Apr. 23, 2009 http://www.infoq.com/news/2009/04/Axum (2 pages). |
Greenhouse et al, Assuring and Evolving Concurrent Programs: Annotations and Policy—Published Date: May 19-25, 2002http://fluid.cs.cmu.edu:8080/Fluid/fluid-publications/p453-greenhouse.pdf (11 pages). |
Taming Your Sequence's Side-Effects through lEnumerable.Let—Published Date: Sep. 12, 2009 http://bartdesmet.net/blogs/bart/archive/2009/09/12/taming-your-sequence-s-side-effects-through-ienumerable-let.aspx (20 pages). |
Kieburtz, Taming Effects with Monadic Typing1—Published Date: 1998 http://delivery.acm.org/10.1145/290000/289428/p51-kieburtz.pdf? key1=28942&key2=9659755521&coll=GUIDE&dl=GUIDE&CFID=56555689&CFTOKEN=92779120 (12 pages). |
Andrade et al., Software Synthesis from Dataflow Models for G and LabVIEW—Published Date Mar. 16, 1998 http://users.ece.utexas.edu/—bevans/courses/ee382c/projects/spring98/andrade-kovner/litsurvey.pdf (9 pages). |
Ha et al., Compile-Time Scheduling of Dynamic Constructs in Dataflow Program Graphs, IEEE Transactions of Computers, vol. 46, No. 7, Published Date: Jul. 1997 http://ptolemy.eecs.berkeley.edu/publications/papers/97/ compile/compile.pdf (12 pages). |
Munnich, PRED-DF—A Data Flow Based Semantic Concurrency Control Protocol for Real-Time Main-Memory Database Systems—Published Date: 2000 http://ieeexplore.ieee.org/stamp/stamp.jsp? tp=&arnumber=896428&isnumber=19358 (5 pages). |
Cox et al., Adding Parallelism to Visual Data Flow Programs—Published Date—2005 http://users.cs.dal.ca/˜arc/publications/2-36/paper.pdf (10 pages). |
Templ et al., Lock-Free Synchronization of Date Flow between Time-Triggered and Event-Triggered Activities in a Dependable Real-Time System—Retrieved Date: Oct, 14, 2009 http://embeddedcmmi.at/fileadmin/src/docs/ publications/C088.pdf (6 pages). |
Leung et al., Data Race: Tame the Beast,—Published Date 2009 http://www.cs.otago.ac.nz/research/publications/oucs-2009-01.pdf (11 pages). |
Nienaltowski, Efficient Data Race and Deadlock Prevention in Concurrent Object-Oriented Programs—Published Date: 2004 http://se.inf.ethz.ch/people/nienaltowski/papers/oopsla04.pdf (2 pages). |
Boyapati, et al., “Ownership Types for Safe Programming: Preventing Data Races and Deadlocks”, retrieved at <<http://www.eecs.umich.edu/˜bchandra/publications/oopsla02.pdf>>, ACM Conference on Object-Oriented Programming, Systems, Languages and Applications (OOPSLA), Nov. 2002, pp. 211-230. |
The Office Action for U.S. Appl. No. 13/652,436 mailed Oct. 3, 2014 (22 pages). |
Number | Date | Country | |
---|---|---|---|
20090327999 A1 | Dec 2009 | US |