DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The abstract of the disclosure is objected to because it should be in one paragraph. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Applicant is reminded of the proper content of an abstract of the disclosure.
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives.
Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps.
Extensive mechanical and design details of an apparatus should not be included in the abstract. The abstract should be in narrative form and generally limited to a single paragraph within the range of 50 to 150 words in length.
See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts.
The disclosure is objected to because of the following informalities: it recites verbatim as claim language. Appropriate correction is required.
The use of the term Java and more…, which is a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Content of Specification
(a) TITLE OF THE INVENTION: See 37 CFR 1.72(a) and MPEP § 606. The title of the invention should be placed at the top of the first page of the specification unless the title is provided in an application data sheet. The title of the invention should be brief but technically accurate and descriptive, preferably from two to seven words. It may not contain more than 500 characters.
(b) CROSS-REFERENCES TO RELATED APPLICATIONS: See 37 CFR 1.78 and MPEP § 211 et seq.
(c) STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT: See MPEP § 310.
(d) THE NAMES OF THE PARTIES TO A JOINT RESEARCH AGREEMENT. See 37 CFR 1.71(g).
(e) INCORPORATION-BY-REFERENCE OF MATERIAL SUBMITTED ON A READ-ONLY OPTICAL DISC, AS A TEXT FILE OR AN XML FILE VIA THE PATENT ELECTRONIC SYSTEM: The specification is required to include an incorporation-by-reference of electronic documents that are to become part of the permanent United States Patent and Trademark Office records in the file of a patent application. See 37 CFR 1.77(b)(5) and MPEP § 608.05. See also the Legal Framework for Patent Electronic System posted on the USPTO website (https://www.uspto.gov/sites/default/files/documents/2019LegalFrameworkPES.pdf) and MPEP § 502.05
(f) STATEMENT REGARDING PRIOR DISCLOSURES BY THE INVENTOR OR A JOINT INVENTOR. See 35 U.S.C. 102(b) and 37 CFR 1.77.
(g) BACKGROUND OF THE INVENTION: See MPEP § 608.01(c). The specification should set forth the Background of the Invention in two parts:
(1) Field of the Invention: A statement of the field of art to which the invention pertains. This statement may include a paraphrasing of the applicable U.S. patent classification definitions of the subject matter of the claimed invention. This item may also be titled “Technical Field.”
(2) Description of the Related Art including information disclosed under 37 CFR 1.97 and 37 CFR 1.98: A description of the related art known to the applicant and including, if applicable, references to specific related art and problems involved in the prior art which are solved by the applicant’s invention. This item may also be titled “Background Art.”
(h) BRIEF SUMMARY OF THE INVENTION: See MPEP § 608.01(d). A brief summary or general statement of the invention as set forth in 37 CFR 1.73. The summary is separate and distinct from the abstract and is directed toward the invention rather than the disclosure as a whole. The summary may point out the advantages of the invention or how it solves problems previously existent in the prior art (and preferably indicated in the Background of the Invention). In chemical cases it should point out in general terms the utility of the invention. If possible, the nature and gist of the invention or the inventive concept should be set forth. Objects of the invention should be treated briefly and only to the extent that they contribute to an understanding of the invention.
(i) BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S): See MPEP § 608.01(f). A reference to and brief description of the drawing(s) as set forth in 37 CFR 1.74.
(j) DETAILED DESCRIPTION OF THE INVENTION: See MPEP § 608.01(g). A description of the preferred embodiment(s) of the invention as required in 37 CFR 1.71. The description should be as short and specific as is necessary to describe the invention adequately and accurately. Where elements or groups of elements, compounds, and processes, which are conventional and generally widely known in the field of the invention described, and their exact nature or type is not necessary for an understanding and use of the invention by a person skilled in the art, they should not be described in detail. However, where particularly complicated subject matter is involved or where the elements, compounds, or processes may not be commonly or widely known in the field, the specification should refer to another patent or readily available publication which adequately describes the subject matter.
(k) CLAIM OR CLAIMS: See 37 CFR 1.75 and MPEP § 608.01(m). The claim or claims must commence on a separate sheet or electronic page (37 CFR 1.52(b)(3)). Where a claim sets forth a plurality of elements or steps, each element or step of the claim should be separated by a line indentation. There may be plural indentations to further segregate subcombinations or related steps. See 37 CFR 1.75 and MPEP 608.01(i) - (p).
(l) ABSTRACT OF THE DISCLOSURE: See 37 CFR 1.72 (b) and MPEP § 608.01(b). The abstract is a brief narrative of the disclosure as a whole, as concise as the disclosure permits, in a single paragraph preferably not exceeding 150 words, commencing on a separate sheet following the claims. In an international application which has entered the national stage (37 CFR 1.491(b)), the applicant need not submit an abstract commencing on a separate sheet if an abstract was published with the international application under PCT Article 21. The abstract that appears on the cover page of the pamphlet published by the International Bureau (IB) of the World Intellectual Property Organization (WIPO) is the abstract that will be used by the USPTO. See MPEP § 1893.03(e).
(m) SEQUENCE LISTING: See 37 CFR 1.821 - 1.825 and MPEP §§ 2421 - 2431. The requirement for a sequence listing applies to all sequences disclosed in a given application, whether the sequences are claimed or not. See MPEP § 2422.01.
Claim Objections
Claim 1 is objected to because of the following informalities: see item C [0018 specification definition and numbers should be avoided]. Appropriate correction is required.
Claims 1-9 are objected to because of the following informalities: use of trademark TM (Java etc.). Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Regarding claim 1, the phrase "such as" “that”, “can” renders the claim indefinite because it is unclear whether the limitations following the phrase are part of the claimed invention. See MPEP § 2173.05(d). Further claim language is vague and unclear with use of “multiple inheritance”, “concrete regular method”, “factory method”, “global free function”
Claims 1-9 are rejected as failing to define the invention in the manner required by 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
The claim(s) are narrative in form and replete with indefinite language. The structure which goes to make up the device must be clearly and positively specified. The structure must be organized and correlated in such a manner as to present a complete operative device. The claim(s) must be in one sentence form only. Note the format of the claims in the patent(s) cited.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Balakrishnan et al USPN 8,707,278 in view of Ghaleb et al USPN 10,437,572
Regarding claim 1
Balakrishnan et al teaches
for each class the programmers want to model, split into two classes, the first is its data interface class and the second is its data implementation class (column 2, line 55, in accordance with the present principles, a model is provided for transforming object-oriented programs (e.g., C++ programs) in a manner which is amenable for program analysis. An object-oriented program may be written in a manner which utilizes multiple inheritance (shared or replicated), and may include complex expressions and implicit calls to certain features. Prior to program analysis, the program may be transformed into an equivalent program which is less complex and which does not include any inheritance. The transformed source code is generated in a manner which is optimized for program analysis. Program analysis can be performed on the original program by analyzing the transformed program which is translated in an analysis-friendly fashion) and (column 6, line 25, After translation of the program, the object model builder 144 further transforms the program by removing all inheritance (e.g., shared inheritance or replicated inheritance) from the classes in the program. This may involve converting the intermediate program 130 so that the classes or objects in the program are represented in a manner which does not include inheritance. In a preferred embodiment, the object model builder 144 may employ one of the CHROME or FORM object models described herein to remove inheritance from the program. Transforming the program in this manner helps to eliminate, or at least reduce, the use of low-level pointer manipulations and virtual function pointer lookups during program analysis);
the data implementation class inherits the data interface class, defines the actual data fields, and overrides or implements the concrete virtual property methods using these actual fields, or using computation instead of raw data fields (column 4, line 55, Referring now to the drawings in which like numerals represent the same or similar elements and initially to FIG. 1, a block/flow diagram illustrates a system 100 for transforming a program in accordance with one embodiment of the present principles. The system includes a central processing unit (CPU) 101 for executing instructions and a memory storage device 102 (e.g., RAM, ROM, etc.) for storing data. A program 110 is provided in an object-oriented language (e.g., C++). The program may include objects which are defined using multiple class inheritance (e.g., which include a class that inherits behaviors and features from more than one superclass or which defines an object using more than one superclass);
for each sub-class its data interface class inherits from its (multiple) super-classes’ data interface classes, and can optionally choose to overrides any of the inherited virtual properties depending on the computer program’s application semantics (column 3, line 40, after the above transformations have been applied, inheritance may be removed from intermediate program. Removing inheritance may involve resolving casts, field accesses and function calls. The resulting program represents an analysis-friendly program which can be easily analyzed, and which does not utilize virtual table lookup pointers, runtime libraries, and other features which are not desirable for analysis. The resulting analysis-friendly program may represent a semantically equivalent program written in C or a semantically equivalent C++ program without any inheritance);
implement the sub-class’s data implementation class independently from its super-classes’ data implementation classes, wherein it can still optionally inherit from one of more its super-classes’ data implementation classes, but it is not mandated to do so (column 9, line 1, alternatively, C++ also provides for "shared inheritance". Shared inheritance is implemented with "virtual base classes" to prevent replication of base classes. Unlike a non-virtual base class, an object of a virtual base class type is shared among the objects of all its direct and transitive derived classes. Applying this to the above example, the B-object would include sub-objects of type L and R as usual. However, because the T-object is a virtual base class, a single T-object would be created which would be shared among the direct and transitive derived classes L, R, and B);
for each field that is semantically branched [0018 Definition 2] in each data interface class of the sub-class that is immediately below the semantic branching site [0018 Definition 2], introduce a new abstract semantic assigning property, which use a different name from its original field name (column 1, line 65, In accordance with the present principles, a method is provided for transforming a program. A given program having inheritance is provided. Inheritance is removed from the given program to produce an analysis-friendly program which does not include virtual-function pointer tables and runtime libraries associated with inheritance-related operations. The analysis-friendly program preserves the semantics of the given program with respect to a given class hierarchy. In accordance the present principles, another system is provided for transforming a program with a priori given class hierarchy that is induced by inheritance. An inheritance remover is configured to remove inheritance from a given program to produce an analysis-friendly program which does not include virtual-function pointer tables and runtime libraries associated with inheritance-related operations. The analysis-friendly program preserves the semantics of the given program with respect to a given class hierarchy. A clarifier is configured to identify implicit expressions and function calls in the given program and transform the given program into at least one intermediate program with explicit expressions and function calls);
each regular method in the sub-class data interface class can optionally choose to use the said new semantic assigning property introduced in the previous step (1.c.i) depending on the computer program’s application semantics (column 3, line 1, producing the analysis-friendly program may involve applying one or more semantic-preserving transformations to the original program. The transformations may produce a sequence of intermediate programs in intermediate languages. After the transformations are applied, the resulting program is semantically equivalent to the original program (for the a priori loaded class hierarchy), but is less complex and does not include inheritance. Consequently, the transformed program eliminates, or at least substantially reduces, the use of complex pointer arithmetic operations, virtual-base offsets, virtual function pointer tables, and run-time libraries. Eliminating these features from the translation facilitates program analysis. The present principles may be applied to any program written in any object-oriented programming language. In accordance with one embodiment, the present principles may be applied to transform a C++ program. A C++ program can be converted into a semantically equivalent program which is less complex and which does not include inheritance.). Balakrishnan et al teaches inheritance, class, sub class, semantics and modeling but doesn’t teach explicitly the data interface class only defines the abstract virtual accessor / property methods for each of the class fields but does not define the raw data fields themselves, and defines other concrete regular methods using these abstract virtual property methods, however Ghaleb et al teaches define one or more factory methods, which create an object of the type of the data implementation class and return it as the type of the data interface class; the said factory methods can be defined as global free functions, or as the data interface class static member functions (column 3, line 52, the operations can further include providing the compiler with a node factory including one or more design pattern nodes, and parsing source code containing one or more concise expressive design pattern source code elements using the parser/generator and the lexer. The operations can also include verifying syntax of the source code containing one or more concise expressive design pattern source code elements using the parser/generator, and performing semantic checking of the source code containing one or more concise expressive design pattern source code elements using the parser/generator. The operations can further include translating the one or more concise expressive design pattern source code elements into one or more expanded design pattern source code elements using the parser/generator and input from the node factory) and (column 7, line 48, the three new statements rules are represented above as non-terminals, which means that they involve sub-rules as will be described below. Whenever the compiler comes across one of these sub-statements of the newly defined rules, it creates a new Node from the extended node factory 120 using the design pattern node extensions 118. The node factory 120 can include the construction of all the nodes defined in Java and AspectJ as well as the design patterns nodes 118. Each node in the node factory 120 is built separately to capture the creation of the desired node based on the parameters passed from the PPG (i.e. in each rule of the PPG there is a call to a specific node the node factory and passing the actual parameters to that node). The node factory of our extension is created as follows). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate factory method. The modification would have been obvious because one of ordinary skill in the art would have been motivated to combine teaching into software development where object-oriented programing is involved and object flexibility like inheritance and polymorphism, which allow for adaptable, reusable, and scalable code and inheritance enables child objects to inherit properties from parent objects, while polymorphism allows different objects to respond to the same.
Regarding claims 2-3
Balakrishnan et al teaches
define the data interface class of as the interface in these languages, and each sub-class inherit from its (multiple) super-classes data interfaces (column 4, line 55, referring now to the drawings in which like numerals represent the same or similar elements and initially to FIG. 1, a block/flow diagram illustrates a system 100 for transforming a program in accordance with one embodiment of the present principles. The system includes a central processing unit (CPU) 101 for executing instructions and a memory storage device 102 (e.g., RAM, ROM, etc.) for storing data. A program 110 is provided in an object-oriented language (e.g., C++). The program may include objects which are defined using multiple class inheritance (e.g., which include a class that inherits behaviors and features from more than one superclass or which defines an object using more than one superclass). The feature of providing interface class…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 4, 6 and 8
Balakrishnan et al teaches
wherein each step is implemented as compiler (or interpreter) rules of any OOP languages that support native multiple inheritance (such as C++, Python, Ocaml, Lisp, and Eiffel, etc.) to report any violations in the source code to the programmers (column 5, line 1, a clarifier 120 compiles the program 110 and transforms the program 110 into an intermediate program(s) 130 (also referred to herein as "CILPP") that is semantically equivalent to the original program 110 but which is less complex. In the case that the program 110 is written in C++, the clarifier 120 may include a GIRA (Generation of Intermediate Representation for Analysis) front-end 120. The GIRA front-end 120 is conceptually related to the well-known C Intermediate Language (CIL) front-end which is used to support program verification tools for the C language. However, unlike the CIL front-end, the GIRA front-end 120 includes extensions for C++ features and provides a set of tools which permit source-to-source translation of C and C++ programs. The GIRA front-end 120 can compile C and C++ programs into a few core constructs with a very clean semantics). The feature of providing compiler…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claims 5 and 9
Ghaleb et al teaches
wherein each step is implemented as rules in the static source code analysis tool (e.g. just like lint for C) of any OOP languages that support native multiple inheritance (such as C++, Python, Ocaml, Lisp, and Eiffel, etc.) to report any violations in the source code to the programmers (column 7, line 1, the extensions can also include design pattern parser/generator extensions 114 and/or design pattern grammar extensions 116. Grammar is the set of formal rules that define how to construct new expressions of the language from a set of symbols. In programming languages, there are some formal method of describing syntax such as CFG, BNF, and EBNF. In the examples described herein, the AspectJ grammar is extended by modifying the parser of the language. For example, using abc and the Polyglot frontend, the extension is done by extending the PPG (Polyglot Parser Generator) which enables adding new and removing existing rules to or from the language. PPG internally uses the EBNF (Extended BNF) due to its usage in most of programming languages and its simplicity to demonstrate the syntactic forms. In an aspect of the present disclosure, the compiler PPG grammar 112 is extended with new rules (e.g., 116) in order to capture the programmer's application of our new constructs. The new constructs could be provided as simple, but expressive, language keywords and statements. To this end, two major grammar rules have been extended to support parsing the new statements users may use to apply the intended design pattern. The first extended grammar rule is class_declaration, which will help in specifying the application of certain design patterns to class types at the time of application. For example, users, while declaring a class, can add modifier, say <singleton_decl>, to the class definition to tell the compiler that this particular class is applying this particular design pattern. The second rule to extend is statement_without_trailing_substatement, which permits users to create new instances or scenarios of the desired design pattern. For example, statements for instantiating an object of the singleton class observing a class, and decorating a class can be supported by the extended statements <instantiate_stmt>, <let_observes_stmt>, and <decorate_with_stmt>, respectively. extend class_declaration::= <singleton_decl> |<facade_decl> | . . . extend statement_without_trailing_substatement::= <instantiate_stmt > |<let_observes_stmt> |<decorate_with_stmt> | ) and (column 21, line 42, hedin also introduced a new technique that is slightly similar to LayOM but using rules and pattern roles. (see, Hedin G. Language support for design patterns using attribute extension. Object-Oriented Technologys. Springer, 1998; 137-140, incorporated herein by reference). The rules and roles can be defined as a class inheritance and specified by attribute declarations. The Hedin technique permits the extended compiler to automatically check the application of patterns against the specified rules. However, the creation of rules, roles, and attributes has a complex syntax that lacks expressiveness and may require an extensive effort to learn and build them). The feature of providing rules…would be obvious for the reasons set forth in the rejection of claim 1.
Regarding claim 7
Ghaleb et al teaches
wherein each step is implemented as rules in the static source code analysis tool (e.g. just like lint for C) of any OOP languages that does not support native multiple inheritance but support default interface methods (such as Java, C#, etc.) to report any violations in the source code to the programmers (column 21, line 42, Hedin also introduced a new technique that is slightly similar to LayOM but using rules and pattern roles. (see, Hedin G. Language support for design patterns using attribute extension. Object-Oriented Technologys. Springer, 1998; 137-140, incorporated herein by reference). The rules and roles can be defined as a class inheritance and specified by attribute declarations. The Hedin technique permits the extended compiler to automatically check the application of patterns against the specified rules. However, the creation of rules, roles, and attributes has a complex syntax that lacks expressiveness and may require an extensive effort to learn and build them) and (column 7, line 48, The three new statements rules are represented above as non-terminals, which means that they involve sub-rules as will be described below. Whenever the compiler comes across one of these sub-statements of the newly defined rules, it creates a new Node from the extended node factory 120 using the design pattern node extensions 118).
Relevant Prior Art
US 7627863 B2 Chen teaches Typed Intermediate Language Support For Languages With Multiple Inheritance
US 8060864 B1 Michelsen teaches System And Method For Live Software Object Interaction
US 6651240 B1 Yamamoto et al teaches Object-oriented Software Development Support Apparatus And Development Support Method
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Anil Khatri whose telephone number is (571)272-3725. The examiner can normally be reached M-F 8:30-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at 571-272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANIL KHATRI/Primary Examiner, Art Unit 2197