DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
Claim 6-7 and 15-16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The following terms are unclear and indefinite:
As for claim 6 and 7, they claim “validating the software module modification…”. However, no preceding claim upon which either claim 6 or 7 depends on (claims 4, 3, and 1) teaches a validating step. Rendering it entirely unclear what is the met and bound of the claimed limitation or what it is further defining at all. For the purpose of examination, Examiner assume the validating step can refer to any generic validation of instruction for modifying a software module.
As for claims 15 and 16, they are rejected for containing similar defects as claims 6 and 7 respectively above.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1-2, 5, 8-11, 14, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Olsson et al. (US PGPUB 2021/0208856), in view of Dhanjal et al. (US PGPUB 20070055936)
As for claim 1, Olsson teaches a method, comprising:
receiving, from a client device [Tenant user device 205-a] and by a software as a service (SaaS) platform [cloud platform 115], a request to import a software module [container component] into an application having a graphical user interface (GUI), the software module to modify the GUI of the application and written in a first format (paragraph 34, “component developer, such as a cloud client 105…sends a package including the data structure for the custom container component…may request …to store…”, paragraph 37, “…transmit the package over a communication link…”, paragraph 38, “…user device …maybe an example of a tenant of the application builder server…”, and paragraph 51, “…user device …may send a request message …request to store a data structure corresponding to a container component…” teaching request to, and importing of software component. Paragraph 59, “…a user interface of the application builder application 410 may include a canvas 425, a component pane 430, and a component editor pane 435…” in view of paragraph 35, “…the custom container component maybe listed on the component pane…shown on the application building pane…” and paragraph 62, “…render the droppable region …in the indicated part of the custom container component…” in view of paragraph 39, “…declaring the attribute in the design file of the component…for example….container array attribute (e.g., “aura. Component[]”) ….component maybe a container component…” teaching received into application having GUI and the GUI of the application GUI is modified (i.e. canvas, component pane, etc.) based on component attribute which is considered the first format. In addition, paragraphs 24, 20 and 27 teaching the cloud platform offer services and is constructively a SAAS platform understood in view of present specification).
receiving, via an application programming interface (API) call, a request to modify the software module, the request identifying a software module modification (paragraphs 51-52, “…request message….process the request message …using a declarative use feature model 335, or a component modifier module…” paragraph 55, “modify a component stored in the component data base …or uploaded by the user device….add or remove an attribute…change a value for an attribute…change text in a label of the component…” paragraph 29, “….based on the declarative use features, the user can avoid writing or modifying code…” and also paragraph 63, “…component editor pane …maybe used to modify…labels, data source, visual or style characteristics…” teaching requests to modify the component. Examiner note, either request message and/or component editor pane-based input are understood as forms of API call-based request submission.); and
providing for presentation the GUI of the application based at least on the application and the software module modification (paragraph 44, “…inject components configured by the user into facets of the container component at runtime…renders the tabs as configured by the user…transmit rendering instructions to user device…”).
While Olsson already teaches the request are processed using a declarative use feature model (see, e.g., paragraph 52), thus, it would have been obvious to a person of ordinary skill in the art that the API call (i.e., user request) is a declarative api. Nevertheless, in the interest of compact prosecution, examiner note Olsson does not explicitly state the request is entered using an API call of a declarative API nor the modification is in a second format.
However, Dhanjal teaches a known method of programmable user interface modification including request to modify using an API call of a declarative API (paragraph 35, “…user interface …is programmed and structured according to a markup language such as ….XML…other languages suitable for programming and structuring a user interface ….may be utilized…” in view of paragraph 39, “….specify a desired location for a new user interface component…” and paragraph 41 “…the resulting amended XML file…illustrates changes made…” and paragraph 17, “…receiving a modification to the XML representation according to the XML schema file…”), and the modification is specified in a second format (paragraph 7, “…XML or other suitable representations of user interface modifications do not necessarily follow the same programming language as the original user interface”).
In addition, Dhanjal also teaches providing for presentation the GUI of the application based at least on the application and the software module modification (paragraph 7 and paragraph 42). This known technique is applicable to the system of Olsson as they both share characteristics and capabilities, namely, they are directed to module customization.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Dhanjal would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Dhanjal to the teachings of Olsson would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such code free module customization features into similar systems. Further, applying request to modify using an API call of a declarative API and the modification is specified in a second format to Olsson with request to modify using an API call and the modification is specified in a specific format accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow improved validation, cross-module protection by using schema-governed declarative markup separate from module code (Dhanjal, paragraphs 7-8, 35-40).
As for claims 10 and 19, they contain similar limitations as claim 1 above. Thus, they are rejected under the same rationales.
As for claim 2, Olsson also teaches the request to modify the software module comprises a request to modify a GUI element corresponding to the software module (paragraph 63, “…modify labels, …visual or style characteristics….”).
Dhanjal also teaches the same limitations (paragraphs 9, 38, 55).
As for claims 11 and 20, they contain similar limitations as claim 2 above. Thus, they are rejected under the same rationales.
As for claim 5, Olsson also teaches responsive to receiving the request to modify the software module, validating the software module modification (paragraph 61).
As for claim 14, it contains similar limitations as claim 5 above. Thus, it is rejected under the same rationales.
As for claim 8, Dhanjal also teaches the software module modification written in a second format (paragraph 41).
As for claim 17, it contains similar limitations as claim 8 above. Thus, it is rejected under the same rationales.
As for claim 9, Olsson also teaches a user selection of a GUI element representing a corresponding GUI element defined by the software module (paragraph 35, 54 and 62).
As for claim 18, it contains similar limitations as claim 9 above. Thus, it is rejected under the same rationales.
Claims 3-4, 6-7, 12-13 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Olsson et al. (US PGPUB 2021/0208856), in view of Dhanjal et al. (US PGPUB 20070055936), in view of Gilboa et al. (US PGPUB 2007/0094609).
As for claim 3, Olsson already teaches a form of conversion of software module related data from one format to another (i.e., paragraph 39 and 54, declaring component attributes in a file, storing corresponding data structures in the component data database, which can be understood as a form of deriving the platform’s internal representation from the module as uploaded.) and Dhanjal teaches integrating a markup representation of the GUI and integrating the additional amended XML (paragraphs 35, 39, where the XML can be different from the internal representation as mentioned in paragraph 7 would implicitly include conversion.). Nevertheless, in the interest of compact prosecution, Examiner note Olsson and Dhanjal do not explicitly state an explicit format translation of the module.
However, Gilboa teaches a known method of utilizing declarative format specification for graphical user interfaces including converting the software module from the first format to the second format (paragraph 10, “….mapping rules for generating the abstract representation from the model representation…..generating the first GUI comprises using a second set of mapping rules for generating the first GUI from the abstract representation…”) This known technique is applicable to the system of Olsson and Dhanjal as they both share characteristics and capabilities, namely, they are directed to UI of module customization.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Gilboa would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Gilboa to the teachings of Olsson and Dhanjal would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such code free module customization features into similar systems. Further, applying converting the software module from the first format to the second format Olsson and Dhanjal with request to modify using an API call of a format that is different than the original format accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow easier runtime implementation of UI elements by designers (Gilboa, paragraphs 5).
As for claim 12, it contains similar limitations as claim 3 above. Thus, it is rejected under the same rationales.
As for claim 4, Dhanjal also teaches the second format corresponds to a format associated with JavaScript Object Notation (JSON) (paragraph 7 and 35, “…or other suitable representations…” “…other languages suitable for programming and structuring a user interface…may be utilized.” Examiner note, applicant admits JSON merely an exemplary and known data exchange format for conveying GUI configuration between servers and web clients. (Specification, paragraphs, 82, “….schema information ….can define a data interchange schema (e.g., forma A, JSON format, etc.) …” Substituting JSON for XML as the declarative representation is a simple substitution of one well-known element for another to obtain predictable results. MPEP 2143(I)(B) See, e.g., Unknown Author, “SAPUI5 Flexibility Services, help.sap.com/saphelp_snc700_ehp04/helpdata/en/a8/e55aa2f8bc4127923b20685a6d1621/content.htm?no_cache=true, Jan 22, 2015, for well-known use of JSON as a declarative representation for UI changes.). Rationale to combine same as claim 1 above.
As for claim 13, it contains similar limitations as claim 4 above. Thus, it is rejected under the same rationales.
As for claim 6, Dhanjal also teaches determining whether the software module modification written in the second format conforms to a schema associated with the second format (paragraph 36 and 37, dictation of what can be included is functional a form of determining whether the input conforms to what is dictated.). Rationale to combine same as claim 1 above.
As for claim 15, it contains similar limitations as claim 6 above. Thus, it is rejected under the same rationales.
As for claim 7, Dhanjal also teaches determining whether the software module modification written in the second format conflicts with another software module of the application (paragraphs 40, 50, 52, 62. Determining whether second format modification is allowed in view of existing component/modifications clearly includes whether that second format modification conflicts with the other software module/modification.). Rationale to combine same as claim 1 above.
As for claim 16, it contains similar limitations as claim 7 above. Thus, it is rejected under the same rationales.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN X LU whose telephone number is (571)270-1233. The examiner can normally be reached M-F 10am-6pm.
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, Lewis Bullock can be reached on 5712723759. 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.
/KEVIN X LU/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights