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 .
1. This communication is responsive to the application filed 2/28/2024.
2. Claims 1-20 are pending in this application. Claims 1 and 11 are independent claims. This action is made Non-Final.
Claim Rejections - 35 USC § 112
3. 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.
4. Claims 5-10 and 14-15 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.
Claims 5, 12, 14 and 15 recite the limitation "the property" in 2nd line of the claim. There is insufficient antecedent basis for this limitation in the claim.
Claims 5, 12, 14 and 15 recite the limitation "the call event" in the 2nd line of the claim. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 102
5. 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
6. Claim(s) 1-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Jazdzewski (US 2002/0083415).
Regarding claim 1, Jazdzewski discloses a method, comprising:
in a software platform running process (see paragraphs [0048], [0052] and [0057]-[0061]; e.g., software platform), dynamically extracting, by an interface manager, type information relating to windows in a software platform running library (see paragraph [0082]; e.g., “As shown in FIG. 4C, the user can select "Inherit" choice 427 for indicating to the system that the form to be created inherits from an existing ancestor form. Ancestor forms can be any forms already contained in an existing project or in the object repository. Form inheritance allows the user to create a library of standard form templates”), and inheriting the type information to form a dynamically-derived basic window (see paragraph [0021]; e.g., “During system operation, the user selects an "Inherit" menu choice for indicating to the system that the form to be created inherits from an existing ancestor form. Ancestor forms can be any forms already contained in an existing projector in an "object repository" provided by the system. Form inheritance allows the user to create a library of standard form templates, either within a single application or across an entire suite of applications. Any changes made to the ancestor form immediately appear in the descendant forms.”), and at the same time, generating, by the interface manager, software platform import codes (see paragraph [0083]; e.g., “When a form inherits from another form, the system creates a reference to the ancestor form and only generates additional code for adding components and event handlers. If several forms in a project are inherited from the same ancestor, they share the inherited code. Each of these forms can include the same frames, different frames, or no frames at all.”); and
based on the type information in the software platform import codes, generating one-window dynamic creation codes and storing the software platform import codes and the one-window dynamic creation codes into an one-derivation codes file (see paragraph [0017]; e.g., “The method includes the steps of creating an ancestor frame and embedding a descendant of that frame into a form. The descendant frame inherits a set of components and a set of component properties from the ancestor frame. Modification of the descendant frame can be achieved by overriding a value stored for one property. Only the values for those properties that have been overridden are stored.”).
Regarding claim 2, Jazdzewski discloses wherein, when N+1 derivative modifications are performed on a property and/or call event of the dynamically-derived basic window, an N+1-derivation codes file is created, wherein the N+1-derivation codes file comprises N-derivation codes file import codes, N+1-window dynamic creation codes and/or user codes, and N≥1; and the N+1-derivation codes file is run to form an N+1-derived user interface (see paragraph [0017]; e.g., “The method includes the steps of creating an ancestor frame and embedding a descendant of that frame into a form. The descendant frame inherits a set of components and a set of component properties from the ancestor frame. Modification of the descendant frame can be achieved by overriding a value stored for one property. Only the values for those properties that have been overridden are stored.”).
Regarding claim 3, Jazdzewski discloses wherein, a method of, in the software platform running process, dynamically extracting, by the interface manager, the type information relating to the windows in the software platform running library comprises: introducing a system-run-time type information unit into internal implementation codes of the software platform to use a class and a method relating to the windows in the unit; using a class of “contextual type of run-time type information” in the system-run-time type information unit to create one context object, and then by a method of “obtaining a type of the run-time type information”, obtaining an object of “the run-time type information” of the windows; and by the object of “the run-time type information” of the windows, using a method of “obtaining property” to obtain property information of the windows and using a method of “obtaining method” to obtain method information of the windows (see paragraphs [0007], [0059], [0063] and [0160]; e.g., property info).
Regarding claim 4, Jazdzewski discloses wherein, the interface manager is used to create, list, design, store, import, export, encrypt and run the user interface (inherent feature; see claim 1 above).
Regarding claim 5, Jazdzewski discloses wherein, the property comprises a visual element and a child member of the windows; the child member is a function variable and/or behavior characteristic variable of the windows; and the call event comprises one or more of a user interaction event, a window life cycle event and a window function event (see paragraphs [0066]-[0072]).
Regarding claim 6, Jazdzewski discloses wherein, a method of performing derivative modifications on the property and/or call event of the dynamically-derived basic window comprises: writing the property of the windows by assignment, and forming a call relationship with the user codes; or by assignment, associating an event handle function with the call event of the windows (see paragraphs [0017]-[0023]).
Regarding claim 7, Jazdzewski discloses wherein, writing the property of the windows by assignment and forming the call relationship with the user codes further comprises: calling a function library of the windows to construct a corresponding parameter and introducing the parameter into an API function (see paragraphs [0070]-[0075] and [0142]).
Regarding claim 8, Jazdzewski discloses wherein, writing the property of the windows by assignment and forming the call relationship with the user codes further comprises: calling a function library of a user to introduce the property of the windows as a parameter into the API function (see paragraphs [0070]-[0075] and [0142]).
Regarding claim 9, Jazdzewski discloses wherein, writing the property of the windows by assignment and forming the call relationship with the user codes further comprises: calling a function library of the software system to introduce the property of the windows as a parameter into the API function (see paragraphs [0070]-[0075] and [0142]).
Regarding claim 10, Jazdzewski discloses wherein, writing the property of the windows by assignment and forming the call relationship with the user codes further comprises: calling a function library of a code language to introduce the property of the windows as a parameter into the API function (see paragraphs [0070]-[0075] and [0142]).
Claims 11-16 is similar in scope to claims 1-3, 5, 7 and 6, respectively, and are therefore rejected under similar rationale.
Claim 17 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Claim 18 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Claim 19 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Claim 20 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Conclusion
7. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bluhm et al (US 11,392,284).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RASHAWN N TILLERY whose telephone number is (571)272-6480. The examiner can normally be reached M-F 9:00a - 5:30p.
8. 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, William L Bashore can be reached at (571) 272-4088. 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.
/RASHAWN N TILLERY/Primary Examiner, Art Unit 2174
Prosecution Insights