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 .
Claims 1-24 are presented for examination.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes claim limitations in claims 1-8 and 13-20 that use the term “module” as a substitute for “means” and that meet the three-prong analysis above, and those limitations are therefore being interpreted under 35 U.S.C. 112(f). The term “module” is a generic placeholder that does not connote sufficiently definite structure, and it is modified by functional language without reciting sufficient structure to perform the claimed function. The claim limitations interpreted under 35 U.S.C. 112(f) are:
(a) “an input module for facilitating input of client data in at least a first programming language” (claim 1) and the corresponding “input module” of claim 13;
(b) “a framework module” that “automatically utilises one or more of the pre-programmed code blocks of the second type and one or more of the pre-programmed code blocks of the third type to generate the customised software product” (claims 1 and 13);
(c) “a first programming language module for receiving the inputted client data” (claims 1 and 13);
(d) “a second controller module including data in a second programming language” (claims 1 and 13);
(e) “a third centralised data controller module” that “utilizes a plurality of data rendering objects to map” and is “configured to read one or more annotation instructions to automatically carry out one or more create, read, update, and delete (CRUD) operation” (claims 1 and 13);
(f) “an output module for outputting the customised software product” (claims 1 and 13);
and (g) “one or more view modules” (claims 6-8 and 17-20).
The dependent claims 2-8 and 14-20 recite or incorporate the above module limitations and are likewise interpreted under 35 U.S.C. 112(f).
Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are construed to cover the corresponding structure described in the specification that performs the claimed function, and equivalents thereof. A review of the specification shows that the corresponding structure for the claimed functions is the software development platform 100 implemented on a server or computing device having a processor and a memory (Spec. [0047], [0099], and [00139]); the input module 101, framework module 102, first programming language module 111, second controller module 112, third centralised data controller module 113, and output module 103 (Spec. [0041] and Figure 3); programmed to carry out the algorithm described as the model-view-controller based create, read, update, and delete process flow and the widget process flow (Spec. [0043], [0067], and [0087]). Because the specification discloses corresponding structure for the claimed functions, a rejection under 35 U.S.C. 112(b) for failure to disclose corresponding structure is not made on the basis of this 35 U.S.C. 112(f) interpretation.
If applicant does not intend to have these claim limitations interpreted under 35 U.S.C. 112(f), applicant may amend the claims so that they will clearly not invoke 35 U.S.C. 112(f), or present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed functions so as to avoid them being interpreted under 35 U.S.C. 112(f). See MPEP 2173 et seq. and 2181 et seq.
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.
Claims 1-12 and 17-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding claim 1, the claim recites “a CRID list column annotation including one or more of: a parameter name attribute; a column heading attribute; and a filter field attribute.” The term “CRID” lacks a definite meaning and renders the claim indefinite. The term “CRID” is not defined anywhere in the claim or the specification, and it is inconsistent with the acronym “CRUD” that is expressly defined earlier in the same claim as “create, read, update, and delete” and that is used throughout the specification. The specification recites “a CRUD list column annotation” at paragraphs [0060] and [0130], whereas claim 1 recites “a CRID list column annotation.” Because it is unclear whether “CRID” is intended to be the previously recited and defined “CRUD” or is instead a separate and distinct term, one of ordinary skill in the art would not be able to determine the metes and bounds of the claim. For purposes of applying prior art below, the Examiner interprets “a CRID list column annotation” as “a CRUD list column annotation” consistent with the specification. Correction or clarification is required.
Regarding claim 6, the claim recites “wherein the customised software model includes one or more view modules.” There is insufficient antecedent basis for “the customised software model” in the claim. Claim 1, from which claim 6 depends, recites “a customised software product” and does not recite a “customised software model.” It is therefore unclear whether “the customised software model” refers to the previously recited “customised software product” or to a different element. Correction is required.
Regarding claim 17, the claim recites “wherein the customised software model includes one or more view modules.” There is insufficient antecedent basis for “the customised software model” in the claim. Claim 13, from which claim 17 depends, recites “a customised software product” and does not recite a “customised software model.” It is therefore unclear whether “the customised software model” refers to the previously recited “customised software product” or to a different element. Correction is required.
Claims 2-5, 7-12, and 18-20 are rejected under 35 U.S.C. 112(b) as depending from, or otherwise incorporating, indefinite claim 1 and 17 and failing to cure the indefiniteness identified above.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-4, 6, 7, 9-18 and 21-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kheiri (US 2011/0145699 A1) in view of Adya (US 2007/0226203 A1) further in view of Harmon (US 2011/0167408 A1).
Regarding Claim 1, Kheiri (US 2011/0145699 A1) teaches
A software development platform for creating a customised software product in the form of a persistent storage application associated with a relational database, the platform including (Para. [0023]-[0026], “the annotation-driven REST web service identifies a platform-independent WWW application for a WWW site ... the annotation-driven REST web service determines that the JAVA application links features of and access to a backend enterprise database to the WWW site for access by a user”) Examiner Comments: Kheiri builds a platform-independent web application that is linked to a backend enterprise database, which is a customised software product in the form of a persistent storage application associated with a database.
an input module for facilitating input of client data in at least a first programming language (Para. [0024], “a developer can use a Graphical User Interface (GUI) or even a web interface to interact with the annotation-driven REST web service and provide a reference to the application”) Examiner Comments: The developer-facing GUI or web interface through which the application and its annotations are provided is an input module that facilitates input of client data.
a framework module including: a first programming language module for receiving the inputted client data (Para. [0032], “the annotation-driven REST web service generates HTTP formatted WWW pages that describe the application using the annotations when the WWW site is accessed by a user”) Examiner Comments: Kheiri generates the HTTP or HTML pages of the application from the inputted client data, which is a first programming language module of the framework module receiving the inputted client data.
a second controller module including data in a second programming language, the second module including a plurality of pre-programmed code blocks of a second type (Para. [0053], “the annotation-driven REST web service web service can be called from various clients (browsers, javascript, Perl code, JAVA applications, Microsoft Net applications, etc.)”) Examiner Comments: Kheiri teaches that the service is invoked by JavaScript clients, so the client-side JavaScript that calls the service is a second controller module containing pre-programmed code blocks of a second programming language.
a third centralised data controller module including data in a third programming language, the third module including a plurality of pre-programmed code blocks of a third type, wherein the first, second and third modules are operatively associated with each other such that, based on the inputted client data, the framework module automatically utilises one or more of the pre-programmed code blocks of the second type and one or more of the pre-programmed code blocks of the third type to generate the customised software product (Para. [0037], “The framework of the annotation-driven REST web service allows the interface to the Web Service to be defined by JAVA annotations applied to the JAVA interface, which actually supports the web service”; Para. [0056], “When the RestfulEndpoint class is instantiated, it reads the annotations to set up the necessary information to allow the servlet to correctly identify the service class for each web service call”) Examiner Comments: Kheiri teaches a Java framework whose RestfulEndpoint class reads the annotations and, together with the generated pages and the JavaScript-callable endpoints, automatically produces the running application, which is a third centralised data controller module of Java code blocks operatively associated with the first and second modules.
an output module for outputting the customised software product (Para. [0078], “The annotated application 301 is configured to generate the WWW page 302 in response to a user accessing a WWW site”) Examiner Comments: The component that generates and serves the WWW page of the running application is an output module that outputs the customised software product.
and the second controller module calls from the third module the third programming language data rendering object to be rendered in a text-based data format for forming at least part of the outputted customised software product (Para. [0031], “the annotation-driven REST web service generates an XML schema definition (XSD) for the serialization of both the input data and the output data of the application for purposes of augmenting the exposed RESTful methods”) Examiner Comments: The JavaScript client of Kheiri calls the Java service, which serializes the data rendering object of Adya into a text-based data format for the output pages, which forms part of the outputted product.
further wherein the third centralised data controller module is configured to read one or more annotation instructions to automatically carry out one or more create, read, update, and delete (CRUD) operation (Para. [0056], “When the RestfulEndpoint class is instantiated, it reads the annotations to set up the necessary information to allow the servlet to correctly identify the service class for each web service call”; Adya, Para. [0084], “one can interact with objects and perform regular Create, Read, Update and Delete (CRUD) operations on the objects”) Examiner Comments: Kheiri teaches a controller that reads the annotations at runtime to set up and perform the service operations, and Adya teaches that those operations on the mapped objects are the create, read, update and delete operations, so reading annotation instructions to automatically carry out CRUD operations is taught.
Kheiri did not specifically teach:
wherein the third centralised data controller module utilizes a plurality of data rendering objects to map: a third programming language entity to the relational database and subsequently maps to the third programming language entity a third programming language data rendering object;
further wherein the platform provides within the third module at least the following distinct framework annotations to define an entity: an entity annotation including one or more of: a rendering entity attribute; an entity document attachment path prefix attribute; an entity file type attribute; an entity validation method attribute; an entity display name attribute; and an entity description attribute
a CRUD list behavior annotation including one or more of: a list column order attribute; a list ascending or descending order attribute; and a list columns attribute
and a CRID list column annotation including one or more of: a parameter name attribute; a column heading attribute; and a filter field attribute
wherein the third centralised data controller module is separate from a page dispatcher.
However, Adya (US 2007/0226203 A1) teaches:
wherein the third centralised data controller module utilizes a plurality of data rendering objects to map: a third programming language entity to the relational database and subsequently maps to the third programming language entity a third programming language data rendering object (Para. [0087], “a mapping that establishes a relationship between the application data and the data stored in the database ... the objects/entities in the client layer can be considered as rich views over the table rows”; Para. [0049], “Some entities need to be transformed into programming language objects to implement application business logic; others need to be transformed into XML streams for web service invocations; still others need to be transformed into in-memory structures such as lists or dictionaries for the purposes of user-interface data binding”) Examiner Comments: Adya maps an entity to relational table rows and then transforms that entity into a rich view or presentation object, which is a data rendering object mapped from the entity, and Adya notes that an object service exists per programming language runtime including Java, teaching mapping a third programming language entity to the relational database and to a data rendering object.
further wherein the platform provides within the third module at least the following distinct framework annotations to define an entity: an entity annotation including one or more of: a rendering entity attribute; an entity document attachment path prefix attribute; an entity file type attribute; an entity validation method attribute; an entity display name attribute; and an entity description attribute (Adya, Para. [0036], “the mappings between the database and applications are expressed in a custom structure, or via schema annotations”; Harmon, Para. [0039], “field control properties 265 may include metadata columns for a section identifier (integer), a field control identifier (integer), a field control type identifier (integer), a label (string)”) Examiner Comments: Adya teaches defining the entity to database mapping via schema annotations, and Harmon teaches that each defined entity element carries a metadata label, which reads on an entity annotation having at least a display name attribute for the entity, only one of the listed attributes being required by the claim.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the annotation-driven Java web framework of Kheiri with the object-relational mapping and data rendering views of Adya in order to reduce the impedance mismatch between the application objects and the relational database and to expose entity data as reusable rendering objects, which raises the level of abstraction from the relational level to the conceptual entity level and increases developer productivity while allowing the database schema to evolve independently of the application (Adya, Para. [0032]).
Kheiri and Adya did not specifically teach:
a CRUD list behavior annotation including one or more of: a list column order attribute; a list ascending or descending order attribute; and a list columns attribute
and a CRID list column annotation including one or more of: a parameter name attribute; a column heading attribute; and a filter field attribute
wherein the third centralised data controller module is separate from a page dispatcher.
However, Harmon (US 2011/0167408 A1) teach:
a CRUD list behavior annotation including one or more of: a list column order attribute; a list ascending or descending order attribute; and a list columns attribute (Para. [0038], “In addition to having properties for controlling content and presentation (e.g., view as single records, list view, sub-pages of another page 220, etc.), a page 220 may include a page menu 225 and page controls 230”; Para. [0039], “a sort order (integer), a user required status (bit), a visibility (bit), a read-only status (integer), a control width (integer), a client-side control identifier (string), a database field name (string), a type (string), a use in workflow wizard status (bit), a show in grid status (bit)”) Examiner Comments: Harmon configures a list view whose per-field metadata includes a sort order and a show in grid flag, which reads on a list behavior annotation having at least a list column order attribute and a list columns attribute, only one of the listed attributes being required by the claim.
and a CRID list column annotation including one or more of: a parameter name attribute; a column heading attribute; and a filter field attribute (Para. [0038], “an event service parameter may include metadata columns for the event service identifier (integer), an event service parameter identifier (integer), a field control identifier (integer), a parameter name (string)”; Para. [0036], “controlling a presentation style of records, printing, displaying a history, generating reports, firing ticklers, controlling workflows, defining filters, specifying search criteria, or other controls”) Examiner Comments: Harmon provides per-column metadata including a parameter name and a metadata-defined filter or search criteria, which reads on a list column annotation having at least a parameter name attribute and a filter field attribute, only one of the listed attributes being required by the claim.
wherein the third centralised data controller module is separate from a page dispatcher (Para. [0046], “The framework page may also serve as a starting point for page-specific functionality by calling an application definition controller ... may communicate with a data controller to access metadata in a database”) Examiner Comments: Harmon separately provides a data controller that the framework page calls to access data, so the data controller module is separate from the page dispatcher.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine Kheiri and Adya with the configurable metadata driven framework of Harmon in order to allow end users to configure the presentation of the application, including list views, list columns, column labels, parameters and filters, and to decouple the presentation layer, the business services layer and the data control layer from one another so that the application can be reconfigured for different purposes without custom programming (Harmon, Para. [0006]).
Regarding Claim 2, Kheiri, Adya and Harmon teach
the software development platform of Claim 1.
Kheiri further teaches, wherein the first programming language is HyperText Markup Language (HTML) (Kheiri, Para. [0032], “the annotation-driven REST web service generates HTTP formatted WWW pages that describe the application using the annotations when the WWW site is accessed by a user”) Examiner Comments: Kheiri generates the WWW pages of the application in HTML, so the first programming language is HTML.
Regarding Claim 3, Kheiri, Adya and Harmon teach the software development platform of Claim 1.
Kheiri further teaches, wherein the second programming language is JavaScript (JS) (Kheiri, Para. [0053], “the annotation-driven REST web service web service can be called from various clients (browsers, javascript, Perl code, JAVA applications, Microsoft Net applications, etc.)”) Examiner Comments: The client that calls the service is written in JavaScript, so the second programming language is JavaScript.
Regarding Claim 4, Kheiri, Adya and Harmon teach the software development platform of Claim 1.
Kheiri further teaches wherein the third programming language is Java (Kheiri, Para. [0025], “the annotation-driven REST web service recognizes the application as a JAVA application”) Examiner Comments: Kheiri recognizes and processes the application as a Java application, so the third programming language is Java.
Regarding Claim 6, Kheiri, Adya and Harmon teach the software development platform of Claim 1.
Harmon further teaches, wherein the customised software model includes one or more view modules (Harmon, Para. [0038], “In addition to having properties for controlling content and presentation (e.g., view as single records, list view, sub-pages of another page 220, etc.), a page 220 may include a page menu 225 and page controls 230”) Examiner Comments: Harmon provides configurable page and list view modules that present records to the user, which reads on the customised product including one or more view modules.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine Kheiri and Adya with the configurable metadata driven framework of Harmon in order to allow end users to configure the presentation of the application, including list views, list columns, column labels, parameters and filters, and to decouple the presentation layer, the business services layer and the data control layer from one another so that the application can be reconfigured for different purposes without custom programming (Harmon, Para. [0006]).
Regarding Claim 7, Kheiri, Adya and Harmon teach the software development platform of Claim 6.
Harmon further teaches, wherein the one or more view modules includes one or more CRUD input tags (Harmon, Para. [0039], “Individual data fields in application 110 may be controlled by metadata for field controls 260. Field controls 260 may define which fields are to be displayed”) Examiner Comments: Harmon provides metadata-defined field controls that render individual input fields used to view, add, edit and delete data, which reads on the view modules including one or more CRUD input tags.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine Kheiri and Adya with the configurable metadata driven framework of Harmon in order to allow end users to configure the presentation of the application, including list views, list columns, column labels, parameters and filters, and to decouple the presentation layer, the business services layer and the data control layer from one another so that the application can be reconfigured for different purposes without custom programming (Harmon, Para. [0006]).
Regarding Claim 9, Kheiri (US 2011/0145699 A1) teaches
A method for creating a customised software product in the form of a persistent storage application associated with a relational database, using the software development platform of claim 1, the method including the steps of: setting up, via the input module, a server environment upon which the software development platform is deployed (Para. [0021], “The processing perspective of the annotation-driven REST web service describes how a RESTful service or (application) can be created, installed, and initiated on a web site for usage by other automated programs or users that access that web site”) Examiner Comments: Kheiri installs and initiates the service application on a web site server environment, which reads on setting up, via the input module, a server environment upon which the platform is deployed.
creating, via the input module, an empty product from the software development platform (Para. [0024], “a developer can use a Graphical User Interface (GUI) or even a web interface to interact with the annotation-driven REST web service and provide a reference to the application”) Examiner Comments: The developer uses the GUI or web interface to reference and begin the application, which reads on creating an empty product via the input module.
inputting client data in at least a first programming language into the input module, the client data including code for rendering one or more features to be included in the customised software product (Para. [0027], “the annotation-driven REST web service integrates one or more annotations received from a developer. So, the developer provides the direction to integrate the annotations into the application”) Examiner Comments: The developer inputs the application code and annotations that define the features of the application, which reads on inputting client data including code for rendering features.
based on the inputted client data, automatically utilising one or more of the pre-programmed code blocks of the second type and one or more of the pre-programmed code blocks of the third type to generate the customised software product; and outputting, via the output module, the customised software product (Para. [0032], “the annotation-driven REST web service generates HTTP formatted WWW pages that describe the application using the annotations when the WWW site is accessed by a user”) Examiner Comments: Kheiri automatically generates and outputs the running application pages from the inputted annotations, which reads on automatically utilising the code blocks to generate and output the product.
wherein the third centralised data controller module is separate from a page dispatcher (Kheiri, Para. [0056], “the annotation-driven REST web service is implemented as a servlet and a RestfulEndpoint class”) Examiner Comments: Kheiri implements the data-handling RestfulEndpoint class separately from the dispatching servlet, teaching this incorporated platform limitation.
Kheiri did not specifically teach
the third centralised data controller module utilizes a plurality of data rendering objects to map a third programming language entity to the relational database and subsequently maps to the third programming language entity a third programming language data rendering object
the third centralised data controller module is configured to read one or more annotation instructions to automatically carry out one or more create, read, update, and delete (CRUD) operation
the distinct framework annotations to define an entity and the CRUD list behavior and list column annotations.
However, Adya (US 2007/0226203 A1) teaches
the third centralised data controller module utilizes a plurality of data rendering objects to map a third programming language entity to the relational database and subsequently maps to the third programming language entity a third programming language data rendering object (Para. [0087], “a mapping that establishes a relationship between the application data and the data stored in the database ... the objects/entities in the client layer can be considered as rich views over the table rows”) Examiner Comments: Adya maps an entity to the relational table rows and then to a rich view or data rendering object, teaching this incorporated platform limitation.
the third centralised data controller module is configured to read one or more annotation instructions to automatically carry out one or more create, read, update, and delete (CRUD) operation (Para. [0084], “one can interact with objects and perform regular Create, Read, Update and Delete (CRUD) operations on the objects”) Examiner Comments: Adya teaches that the operations carried out on the mapped objects are the create, read, update and delete operations, teaching this incorporated platform limitation.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the annotation-driven Java web framework of Kheiri with the object-relational mapping and data rendering views of Adya in order to reduce the impedance mismatch between the application objects and the relational database and to expose entity data as reusable rendering objects, which raises the level of abstraction from the relational level to the conceptual entity level and increases developer productivity while allowing the database schema to evolve independently of the application (Adya, Para. [0032]).
Kheiri and Adya did not specifically teach
the distinct framework annotations to define an entity and the CRUD list behavior and list column annotations.
However, Harmon (US 2011/0167408 A1) teaches
the distinct framework annotations to define an entity and the CRUD list behavior and list column annotations (Para. [0039], “field control properties 265 may include metadata columns for a section identifier (integer), a field control identifier (integer), a field control type identifier (integer), a label (string)”) Examiner Comments: Harmon provides metadata that defines each entity field with a label, sort order and show in grid status, which reads on the entity, list behavior and list column annotation attributes incorporated into claim 9.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine Kheiri and Adya with the configurable metadata driven framework of Harmon in order to allow end users to configure the presentation of the application, including list views, list columns, column labels, parameters and filters, and to decouple the presentation layer, the business services layer and the data control layer from one another so that the application can be reconfigured for different purposes without custom programming (Harmon, Para. [0006]).
Regarding Claim 10, Kheiri, Adya and Harmon teach the method of Claim 9.
Kheiri further teaches, wherein the first programming language is HyperText Markup Language (HTML) (Kheiri, Para. [0032], “the annotation-driven REST web service generates HTTP formatted WWW pages that describe the application using the annotations when the WWW site is accessed by a user”) Examiner Comments: Kheiri generates the WWW pages in HTML, so the first programming language is HTML.
Regarding Claim 11, Kheiri, Adya and Harmon teach the method of Claim 9.
Kheiri further teaches, wherein the second programming language is JavaScript (JS) (Kheiri, Para. [0053], “the annotation-driven REST web service web service can be called from various clients (browsers, javascript, Perl code, JAVA applications, Microsoft Net applications, etc.)”) Examiner Comments: The calling client is written in JavaScript, so the second programming language is JavaScript.
Regarding Claim 12, Kheiri, Adya and Harmon teach the method of Claim 9.
Kheiri further teaches, wherein the third programming language is Java (Kheiri, Para. [0025], “the annotation-driven REST web service recognizes the application as a JAVA application”) Examiner Comments: Kheiri processes the application as a Java application, so the third programming language is Java.
Regarding Claim 13, Kheiri (US 2011/0145699 A1) teaches
A software development platform for creating a customised software product including a displayed widget, the platform including: an input module for facilitating input of client data (Para. [0024], “a developer can use a Graphical User Interface (GUI) or even a web interface to interact with the annotation-driven REST web service and provide a reference to the application”) Examiner Comments: The developer-facing GUI or web interface is an input module that facilitates input of client data.
a framework module including: a first programming language module for receiving at least part of the inputted client data in a first programming language (Para. [0032], “the annotation-driven REST web service generates HTTP formatted WWW pages that describe the application using the annotations when the WWW site is accessed by a user”) Examiner Comments: Kheiri generates the application pages from the inputted client data, which is a first programming language module receiving the inputted client data.
a second controller module including data in a second programming language, the second module including a plurality of pre-programmed code blocks of a second type (Para. [0053], “the annotation-driven REST web service web service can be called from various clients (browsers, javascript, Perl code, JAVA applications, Microsoft Net applications, etc.)”) Examiner Comments: The JavaScript client that calls the service is a second controller module containing pre-programmed code blocks of a second programming language.
a third centralised data controller module including data in a third programming language, the third module for receiving at least part of the inputted client data in a third programming language, wherein the first, second and third modules are operatively associated with each other such that, based on the inputted client data, the framework module automatically calls data in a third programming language to utilise one or more of the pre-programmed code blocks of the second type to generate the customised software product (Para. [0037], “The framework of the annotation-driven REST web service allows the interface to the Web Service to be defined by JAVA annotations applied to the JAVA interface, which actually supports the web service”; Para. [0056], “When the RestfulEndpoint class is instantiated, it reads the annotations to set up the necessary information to allow the servlet to correctly identify the service class for each web service call”) Examiner Comments: Kheiri teaches a Java framework whose RestfulEndpoint class reads the annotations and, operatively associated with the first and second modules, automatically produces the running application, which reads on the third centralised data controller module that automatically calls and generates the product.
an output module for outputting the customised software product including the displayed widget (Harmon, Para. [0029], “The data may optionally be provided to an SQL reporting service 120 for further processing using a report application program interface (API). In another implementation, reporting service 120 may be configured and/or created in Crystal Reports or other ODBC compliant report writers to be added into chapter or pages of application 110”) Examiner Comments: Harmon outputs configurable reporting and framework control widgets added into the pages of the application, which reads on outputting the customised software product including a displayed widget.
wherein the third centralised data controller module is separate from a page dispatcher (Kheiri, Para. [0056], “the annotation-driven REST web service is implemented as a servlet and a RestfulEndpoint class”) Examiner Comments: Kheiri implements the data-handling RestfulEndpoint class separately from the dispatching servlet.
Kheiri did not specifically teach
the third centralised data controller module utilizes a plurality of data rendering objects to map a third programming language entity to the relational database and subsequently maps to the third programming language entity a third programming language data rendering object
reads one or more annotation instructions to automatically carry out one or more create, read, update, and delete (CRUD) operation, and provides the distinct framework annotations to define an entity
the entity annotation, CRUD list behavior annotation and CRUD list column annotation attributes.
However, Adya (US 2007/0226203 A1) teaches
the third centralised data controller module utilizes a plurality of data rendering objects to map a third programming language entity to the relational database and subsequently maps to the third programming language entity a third programming language data rendering object (Para. [0087], “a mapping that establishes a relationship between the application data and the data stored in the database ... the objects/entities in the client layer can be considered as rich views over the table rows”) Examiner Comments: Adya maps an entity to the relational table rows and then to a rich view or data rendering object.
reads one or more annotation instructions to automatically carry out one or more create, read, update, and delete (CRUD) operation, and provides the distinct framework annotations to define an entity (Para. [0084], “one can interact with objects and perform regular Create, Read, Update and Delete (CRUD) operations on the objects”) Examiner Comments: Adya teaches performing the create, read, update and delete operations on the mapped objects defined via annotations.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the annotation-driven Java web framework of Kheiri with the object-relational mapping and data rendering views of Adya in order to reduce the impedance mismatch between the application objects and the relational database and to expose entity data as reusable rendering objects, which raises the level of abstraction from the relational level to the conceptual entity level and increases developer productivity while allowing the database schema to evolve independently of the application (Adya, Para. [0032]).
Kheiri and Adya did not specifically teach
the entity annotation, CRUD list behavior annotation and CRUD list column annotation attributes.
However, Harmon (US 2011/0167408 A1) teaches
the entity annotation, CRUD list behavior annotation and CRUD list column annotation attributes (Harmon, Para. [0039], “a sort order (integer), a user required status (bit), a visibility (bit), a read-only status (integer), a control width (integer), a client-side control identifier (string), a database field name (string), a type (string), a use in workflow wizard status (bit), a show in grid status (bit)”) Examiner Comments: Harmon provides per-field metadata including a label, sort order and show in grid status, which reads on the entity, list behavior and list column annotation attributes, only one attribute in each group being required by the claim.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine Kheiri and Adya with the configurable metadata driven framework of Harmon in order to allow end users to configure the presentation of the application, including list views, list columns, column labels, parameters and filters, and to decouple the presentation layer, the business services layer and the data control layer from one another so that the application can be reconfigured for different purposes without custom programming (Harmon, Para. [0006]).
Regarding Claim 14, Kheiri, Adya and Harmon teach the software development platform of Claim 13.
Kheiri further teaches, wherein the first programming language is HyperText Markup Language (HTML) (Kheiri, Para. [0032], “the annotation-driven REST web service generates HTTP formatted WWW pages that describe the application using the annotations”) Examiner Comments: Kheiri generates the WWW pages in HTML, so the first programming language is HTML.
Regarding Claim 15, Kheiri, Adya and Harmon teach the software development platform of Claim 13.
Kheiri further teaches, wherein the second programming language is JavaScript (JS) (Kheiri, Para. [0053], “the annotation-driven REST web service web service can be called from various clients (browsers, javascript, Perl code, JAVA applications, Microsoft Net applications, etc.)”) Examiner Comments: The calling client is written in JavaScript, so the second programming language is JavaScript.
Regarding Claim 16, Kheiri, Adya and Harmon teach the software development platform of Claim 13.
Kheiri further teaches, wherein the third programming language is Java (Kheiri, Para. [0025], “the annotation-driven REST web service recognizes the application as a JAVA application”) Examiner Comments: Kheiri processes the application as a Java application, so the third programming language is Java.
Regarding Claim 17, Kheiri, Adya and Harmon teach the software development platform of Claim 13.
Harmon further teaches, wherein the customised software model includes one or more view modules (Harmon, Para. [0038], “In addition to having properties for controlling content and presentation (e.g., view as single records, list view, sub-pages of another page 220, etc.), a page 220 may include a page menu 225 and page controls 230”) Examiner Comments: Harmon provides configurable page and list view modules that present records to the user, which reads on the customised product including one or more view modules.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine Kheiri and Adya with the configurable metadata driven framework of Harmon in order to allow end users to configure the presentation of the application, including list views, list columns, column labels, parameters and filters, and to decouple the presentation layer, the business services layer and the data control layer from one another so that the application can be reconfigured for different purposes without custom programming (Harmon, Para. [0006]).
Regarding Claim 18, Kheiri, Adya and Harmon teach the software development platform of Claim 17.
Kheiri further teaches, wherein the one or more view modules includes one or more widget templates (Harmon, Para. [0025], “the configurable controls may include, among other aspects, controls for screen presentation, menu bars, help, navigation, wizards, rule processing, reporting, tickler managing, standard phrases, look ups, merging, printing, chapter control, page control, field control”) Examiner Comments: Harmon provides a set of reusable configurable framework control templates such as reporting, page control and field control that are placed into the view modules, which reads on the view modules including one or more widget templates.
Regarding Claim 21, Kheiri (US 2011/0145699 A1) teaches
A method for creating a customised software product including a displayed widget, using the software development platform of claim 13, the method including the steps of: setting up, via the input module, a server environment upon which the software development platform is deployed (Para. [0021], “The processing perspective of the annotation-driven REST web service describes how a RESTful service or (application) can be created, installed, and initiated on a web site for usage by other automated programs or users that access that web site”) Examiner Comments: Kheiri installs and initiates the service application on a web site server environment, which reads on setting up a server environment via the input module.
creating, via the input module, an empty product from the software development platform (Para. [0024], “a developer can use a Graphical User Interface (GUI) or even a web interface to interact with the annotation-driven REST web service and provide a reference to the application”) Examiner Comments: The developer uses the GUI or web interface to reference and begin the application, which reads on creating an empty product via the input module.
inputting client data in a first programming language into the input module, the client data including code for rendering one or more features to be included in the customised software product; based on the inputted client data, automatically calling data in a third programming language to utilise one or more of the pre-programmed code blocks of the second type to generate the customised software product; and outputting, via the output module, the customised software product (Para. [0032], “the annotation-driven REST web service generates HTTP formatted WWW pages that describe the application using the annotations when the WWW site is accessed by a user”) Examiner Comments: The developer inputs the annotated application code and Kheiri automatically calls the Java service to generate and output the running application, which reads on automatically calling and utilising the code blocks to generate and output the product.
Kheiri did not specifically teach
the data rendering object mapping and the CRUD annotation reading of the platform of claim 13
the customised software product including a displayed widget
the entity, list behavior and list column annotation attributes, and the separation from a page dispatcher, of the platform of claim 13.
However, Adya teaches
the data rendering object mapping and the CRUD annotation reading of the platform of claim 13 (Adya, Para. [0087], “a mapping that establishes a relationship between the application data and the data stored in the database ... the objects/entities in the client layer can be considered as rich views over the table rows”) Examiner Comments: Adya maps an entity to the relational table rows and to a rich view or data rendering object on which CRUD operations are performed, teaching the incorporated platform limitations.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the annotation-driven Java web framework of Kheiri with the object-relational mapping and data rendering views of Adya in order to reduce the impedance mismatch between the application objects and the relational database and to expose entity data as reusable rendering objects, which raises the level of abstraction from the relational level to the conceptual entity level and increases developer productivity while allowing the database schema to evolve independently of the application (Adya, Para. [0032]).
Kheiri and Adya did not specifically teach
the customised software product including a displayed widget
the entity, list behavior and list column annotation attributes, and the separation from a page dispatcher, of the platform of claim 13.
However, Harmon teaches
the customised software product including a displayed widget (Para. [0029], “reporting service 120 may be configured and/or created in Crystal Reports or other ODBC compliant report writers to be added into chapter or pages of application 110”) Examiner Comments: Harmon adds configurable reporting and framework control widgets into the pages of the output application, which reads on the product including a displayed widget.
the entity, list behavior and list column annotation attributes, and the separation from a page dispatcher, of the platform of claim 13 (Para. [0039], “a sort order (integer), a user required status (bit), a visibility (bit), a read-only status (integer), a control width (integer), a client-side control identifier (string), a database field name (string), a type (string), a use in workflow wizard status (bit), a show in grid status (bit)”) Examiner Comments: Harmon provides per-field metadata defining the annotation attributes and a data controller separate from the framework page, teaching the incorporated platform limitations.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further combine Kheiri and Adya with the configurable metadata driven framework of Harmon in order to allow end users to configure the presentation of the application, including list views, list columns, column labels, parameters and filters, and to decouple the presentation layer, the business services layer and the data control layer from one another so that the application can be reconfigured for different purposes without custom programming (Harmon, Para. [0006]).
Regarding Claim 22, Kheiri, Adya and Harmon teach the method of Claim 21.
Kheiri further teaches, wherein the first programming language is HyperText Markup Language (HTML) (Kheiri, Para. [0032], “the annotation-driven REST web service generates HTTP formatted WWW pages that describe the application using the annotations”) Examiner Comments: Kheiri generates the WWW pages in HTML, so the first programming language is HTML.
Regarding Claim 23, Kheiri, Adya and Harmon teach the method of Claim 21.
Kheiri further teaches, wherein the second programming language is JavaScript (JS) (Kheiri, Para. [0053], “the annotation-driven REST web service web service can be called from various clients (browsers, javascript, Perl code, JAVA applications, Microsoft Net applications, etc.)”) Examiner Comments: The calling client is written in JavaScript, so the second programming language is JavaScript.
Regarding Claim 24, Kheiri, Adya and Harmon teach the method of Claim 21.
Kheiri further teaches, wherein the third programming language is Java (Kheiri, Para. [0025], “the annotation-driven REST web service recognizes the application as a JAVA application”) Examiner Comments: Kheiri processes the application as a Java application, so the third programming language is Java.
Claim(s) 5, 8, 19 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kheiri (US 2011/0145699 A1) in view of Adya (US 2007/0226203 A1), in view of Harmon (US 2011/0167408 A1), further in view of Modo (US 10,331,424 B1).
Regarding Claim 5, Kheiri, Adya and Harmon teach the software development platform of Claim 1, wherein Kheiri teaches serializing the input and output data into a text-based data format (Para. [0031]).
Kheiri, Adya and Harmon did not specifically teach that the text-based data format is JSON.
However, Modo (US 10,331,424 B1) teaches:
wherein the text-based data format is JavaScript Object Notation (JSON) (Modo, Abstract, “a web service that provides, through HTTP requests and responses, JavaScript Object Notation objects declaring instances of user interface elements according to a predefined specification”) Examiner Comments: Modo renders the user interface data communicated between the client and the service as JavaScript Object Notation objects, which reads on the text-based data format being JSON.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to serialize the text-based data of Kheiri, Adya and Harmon in the JavaScript Object Notation format of Modo in order to communicate user interface and application data to a JavaScript client in a lightweight, widely supported, and natively parseable text-based format, which is the format for which the JavaScript client is natively suited (Modo, Abstract).
Regarding Claim 8, Kheiri, Adya and Harmon teach the software development platform of Claim 7.
Kheiri, Adya and Harmon did not specifically teach
wherein the one or more CRUD input tags includes one or more of: a text tag; an email tag; a password tag; a number tag; a uniform resource locator (URL) tag; a contact tag; one or more date tags; a text area tag; a toggle button tag; an address tag; a dropdown menu tag (single or multi selection); a checkbox tag; a radios tag; and a hidden input tag.
However, Modo (US 10,331,424 B1) teaches:
wherein the one or more CRUD input tags includes one or more of: a text tag; an email tag; a password tag; a number tag; a uniform resource locator (URL) tag; a contact tag; one or more date tags; a text area tag; a toggle button tag; an address tag; a dropdown menu tag (single or multi selection); a checkbox tag; a radios tag; and a hidden input tag (Col 10, lines 25-30, “Form elements can include various input items, such as text fields, password fields, radio buttons, checkboxes, drop-down lists, and other user interface components”) Examiner Comments: Modo provides form input tags including a text field, a password field, a radios tag, a checkbox tag and a drop-down list, which reads on the recited CRUD input tags, only one of the listed tag types being required by the claim.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to serialize the text-based data of Kheiri, Adya and Harmon in the JavaScript Object Notation format of Modo in order to communicate user interface and application data to a JavaScript client in a lightweight, widely supported, and natively parseable text-based format, which is the format for which the JavaScript client is natively suited (Modo, Abstract).
Regarding Claim 19, Kheiri, Adya, Harmon teach the software development platform of Claim 18.
Kheiri, Adya and Harmon did not specifically teach
wherein the one or more widget templates includes one or more of: a chart widget; a document widget; one or more multimedia widgets; a map widget; a table widget; and a vector map widget.
However, Modo (US 10,331,424 B1) teaches:
wherein the one or more widget templates includes one or more of: a chart widget; a document widget; one or more multimedia widgets; a map widget; a table widget; and a vector map widget (Col 4, 1-35, “various user interface elements that can be included in an XModule, including but not limited to buttons, text areas, multicolumn and multirow formats, images, videos, formatted text, entry fields, sliders, scroll bars, radio buttons, checkboxes, drop-down boxes, forms, calendars, maps, links, portlets, social media feeds, share buttons, and the like”) Examiner Comments: Modo provides user interface element templates including images and videos, which are multimedia widgets, and a maps element, which is a map widget, only one of the listed widget types being required by the claim.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to serialize the text-based data of Kheiri, Adya and Harmon in the JavaScript Object Notation format of Modo in order to communicate user interface and application data to a JavaScript client in a lightweight, widely supported, and natively parseable text-based format, which is the format for which the JavaScript client is natively suited (Modo, Abstract).
Regarding Claim 20, Kheiri, Adya, Harmon and Modo teach the software development platform of Claim 19.
Kheiri, Adya and Harmon did not specifically teach
wherein the one or more multimedia widgets includes one or more images widgets and/or one or more video widgets.
However, Modo (US 10,331,424 B1) teaches:
wherein the one or more multimedia widgets includes one or more images widgets and/or one or more video widgets (Col 4, lines 1-35, “images, videos, formatted text, entry fields, sliders, scroll bars, radio buttons, checkboxes, drop-down boxes, forms, calendars, maps, links, portlets, social media feeds, share buttons”) Examiner Comments: Modo provides an images user interface element and a videos user interface element, which read on the multimedia widgets including an images widget and a video widget.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to serialize the text-based data of Kheiri, Adya and Harmon in the JavaScript Object Notation format of Modo in order to communicate user interface and application data to a JavaScript client in a lightweight, widely supported, and natively parseable text-based format, which is the format for which the JavaScript client is natively suited (Modo, Abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
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, Wei Mui can be reached at (571) 272-3708. 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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights