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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 25 November 2025 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
An initial search of the newly amended claim set did not uncover any combination of references that teaches or suggests the recited “validation of the custom data collection container involves submission of the summary page of a first selected module of the two or more universal modules to a second selected module of the two or more universal modules for validation of the data fields of the first selected” (claim 1). The Examiner contacted the applicant’s representative on 8 January 2026 to resolve the outstanding double patenting rejection. However, upon conducting an updated search regarding the obvious type double patenting rejection, additional references were uncovered that the Examiner finds teaches or at least suggests the limitations of claim 1. See updated rejection below.
Claim Objections
Claims 9 and 14 are objected to because of the following informalities: “the processor” should be “the one or more processors.” 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.
Claim 3 is 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.
Claim 3 recites the limitation “the data summary page” in line 4. There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination, this has been interpreted as “the [[data]] summary page.”
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Raveh (US 2019/0042284) and further in view of Chawla (US 2014/0052617).
Regarding claim 1, Raveh teaches: A non-transitory computer-readable storage medium storing computer-readable program code executable by a processor, wherein execution of the computer-readable program code causes the processor to:
communicate, with an enterprise server, request to (¶ 36, “The configuration page 108 renders (at block 702) in a main panel 501, 601 of the configuration GUI 112 the selected component page 110.sub.i and graphical component page selection controls, e.g., 500.sub.1, 500.sub.2, 500.sub.3, 500.sub.4, 600.sub.1, 600.sub.2 . . . 600.sub.5, associated with the component pages 110, rendered in the order in which the component pages 110 are ordered”), and to generate a customized service widget based on the custom data collection container for execution within a website (¶ 37, “The configuration page 108 renders (at block 706) in the main panel 501, 601 of the configuration page 108 the page layout template 208 for the component page 110.sub.i showing the configuration setting controls”);
wherein the request comprises the selection of the two or more universal modules and the identification of the order of presentation of the two or more universal modules (¶ 24, “The component resources to configure may be organized in the component pages 110 according to a preferred ordering selected by the developer of the resource configuration object 120”), wherein the two or more universal modules comprise:
executable programming code to render user-fillable data fields and presentation elements for a graphical user interface (¶ 31, “each of the component page selection controls 500.sub.1, 500.sub.2, 500.sub.3, and 500.sub.4 render information indicating a number of configuration parameters 502.sub.1, 502.sub.2, 502.sub.3, and 502.sub.4 in the corresponding component page 110.sub.i that have not been applied in that page”) and
a summary page comprising data requirements (¶ 32, “FIG. 5 shows a conflict message 506 being displayed indicating a conflict with the selected volume size of 2000 GB, as conflicting with the free space in the pool setting”);
wherein validation of the custom data collection container involves submission of the summary page of a first selected module of the two or more universal modules to a second selected module of the two or more universal modules for validation of the data fields of the first selected module by the second selected module (¶ 38, “A dependency conflict may be determined if any of the saved values 308 for configuration parameters in the component page 110.sub.i conflict with any saved values 308 for configuration parameters in any of the other pages 110 according to dependency rules 414 in the dependency information 400.sub.i applicable to the saved values in the displayed component page 110.sub.i”);
wherein generation of the customized service widget is based on the validation (¶ 39, “If (at block 708) there is no dependency conflict for the saved values for the rendered page 110.sub.i, the configuration page 108”);
receive the customized service widget from the enterprise server (¶ 19, “The configuration server 100 may transmit the configuration pages 108 to the client systems 114 over the network 114”); and
execute, by the client server, the customized service widget within the website to generate the graphical user interface to interact with a user device to perform a service for a user (¶ 39, “If (at block 718) all saved values 308 for all the configuration parameters rendered in all the configuration pages 108 are applied, i.e., the applied flag 310 set, then the resource configuration program 106 generates (at block 720) a user selectable control to enable the user to configure the computer resource 130 with all the applied saved values 130 for all the configuration parameters set through the pages 110”).
Raveh does not teach; however, Chawla discloses: communicate, with an enterprise server, an authentication token and a request to validate and compile a custom data collection container (¶ 128, “user device 301 may transmit a widget designer request input, e.g., 374, to an API-Tool server 310. The API-Tool server may receive the widget designer request and extract user authentication information, e.g., 375”); and
the authentication token to authenticate the website and a client server to execute the customized service widget within the website (¶ 128, “Authentication information may be in the form of a clear text username/password, a hashed username/password, a cryptographic key, and/or the like. In one embodiment, the API-Tool server may query a widget designer authentication and permissions table for authorized widget designer users, e.g., 376”);
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of communicate, with an enterprise server, an authentication token and a request to validate and compile a custom data collection container; and the authentication token to authenticate the website and a client server to execute the customized service widget within the website, as taught by Chawla, in the same way to the generation of a customized service widget, as taught by Raveh. Both inventions are in the field of generating customized service widgets, and combining them would have predictably resulted in “payment widget creation,” as indicated by Chawla (¶ 7).
Regarding claim 2, Raveh teaches: The non-transitory computer-readable storage medium of claim 1, further comprises computer-readable program code that when executed causes the processor to combine one or more other data collection containers with the two or more universal modules to generate the customized service widget (claim 20, “generating a plurality of component pages, wherein each component page includes user configuration setting controls to enable a user to set configuration parameters for a component resource of a plurality of component resources to configure”), wherein the one or more other data collection containers comprise a first data collection container comprising programming code to perform one or more validation actions (claim 23, “rendering conflict information indicating a dependency conflict in response to a determination that there is a dependency conflict between the user selected value for the configuration parameter of the component resource”).
Regarding claim 3, Raveh teaches: The non-transitory computer-readable storage medium of claim 2, wherein the first data collection container comprises programming code to validate data collected via the service, against a data contract related to the service (¶ 30, “a dependency rule 414 indicating a rule for comparing saved values for the configuration parameters of the component resource 412 to determine if there is a dependency conflict, such as if the user selected a storage pool component resource that did not have enough storage space for a volume size configuration setting set by the user”) and the second selected module is operable to evaluate the data summary page of the first selected module to confirm that any data obtained via the data fields presented by the first selected module is valid (¶ 38, “A dependency conflict may be determined if any of the saved values 308 for configuration parameters in the component page 110.sub.i conflict with any saved values 308 for configuration parameters in any of the other pages 110 according to dependency rules 414 in the dependency information 400.sub.i applicable to the saved values in the displayed component page 110.sub.i”).
Regarding claim 4, Raveh teaches: The non-transitory computer-readable storage medium of claim 2, wherein the customized service widget comprises modified programming code for one or a combination of the two or more universal modules and the one or more other data collection containers, based on the data requirements of the two or more universal modules (¶ 41, “render the configuration parameters and user configuration setting controls for one of multiple pages in any order, and to cause determination of how to display a apply graphical control as unselectable”), data requirements of the one or more other data collection containers (claim 24, “accessing dependency information indicating a plurality of dependency relationships between component resources configured in any of the component pages”), the order of presentation (¶ 24, “The component resources to configure may be organized in the component pages 110 according to a preferred ordering selected by the developer of the resource configuration object 120”), or a combination thereof.
Regarding claim 5, Chawla teaches: The non-transitory computer-readable storage medium of claim 4, wherein the presentation elements comprise a client style element related to rendering the user-fillable data fields in the graphical user interface (¶ 142, “An example store social application render response 511, substantially in the form of an HTTP(S) POST message including XML-formatted data, is . . . style_sheet="merchant_custom_styles.css"”).
Regarding claim 6, Raveh teaches: The non-transitory computer-readable storage medium of claim 1, wherein a first one of the two or more universal modules collects data different from a second one of the two or more universal modules (claim 20, “each component page includes user configuration setting controls to enable a user to set configuration parameters for a component resource of a plurality of component resources to configure”).
Regarding claim 7, Chawla teaches: The non-transitory computer-readable storage medium of claim 1, wherein the authentication token enables the client server to confirm to an enterprise server that the client server is permitted to request services via the enterprise server (¶ 111, “The API-Tool server 310 may verify whether the merchant entered access ID and merchant ID, and/or other access credentials are valid 327”).
Claims 8-20 recite commensurate subject matter as claims 1-7. Therefore, they are rejected for the same reasons.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-19 of U.S. Patent No. 10,649,745 and further in view of Chawla (US 2014/0052617). Although the claims at issue are not identical, they are not patentably distinct from each other because U.S. Patent No. 10,649,745 teaches or at least suggests each and every limitation of the instant application, except for the following limitations which Chawla teaches: communicate, with an enterprise server, an authentication token and a request to validate and compile a custom data collection container (¶ 128, “user device 301 may transmit a widget designer request input, e.g., 374, to an API-Tool server 310. The API-Tool server may receive the widget designer request and extract user authentication information, e.g., 375”); and
the authentication token to authenticate the website and a client server to execute the customized service widget within the website (¶ 128, “Authentication information may be in the form of a clear text username/password, a hashed username/password, a cryptographic key, and/or the like. In one embodiment, the API-Tool server may query a widget designer authentication and permissions table for authorized widget designer users, e.g., 376”).
See claim correspondence below.
Instant Application
U.S. Patent No. 10,649,745
1. (Currently Amended) A non-transitory computer-readable storage medium storing computer-readable program code executable by a processor, wherein execution of the computer-readable program code causes the processor to: communicate, with an enterprise server, an authentication token and a request to validate and compile a custom data collection container based on selection of two or more universal modules and based on identification of an order of presentation for the two or more universal modules, and to generate a customized service widget based on the custom data collection container for execution within a website; wherein the request comprises the selection of the two or more universal modules and the identification of the order of presentation of the two or more universal modules, wherein the two or more universal modules comprise: executable programming code to render user-fillable data fields and presentation elements for a graphical user interface and a summary page comprising data requirements; wherein validation of the custom data collection container involves submission of the summary page of a first selected module of the two or more universal modules to a second selected module of the two or more universal modules for validation of the data fields of the first selected module by the second selected module; wherein generation of the customized service widget is based on the validation; the authentication token to authenticate the website and a client server to execute the customized service widget within the website; receive the customized service widget from the enterprise server; and execute, by the client server, the customized service widget within the website to generate the graphical user interface to interact with a user device to perform a service for a user.
1. A system, comprising: a memory storing programming code; a module repository storing a plurality of universal modules that make up a data input and presentation flow, wherein each universal module includes computer application code that renders information on a display, data fields that store data and a summary page of data requirements for each universal module; a composite repository storing a plurality of data collection containers, wherein each container of the plurality of data collection containers includes two or more universal modules from the plurality of universal modules; and a pipeline processing component coupled to the memory, the module repository, and the composite repository, wherein the pipeline processing component is operable to execute the programming code stored in the memory, and the pipeline processing component when executing the programming code performs functions, including functions to: select a first universal module from the plurality of universal modules stored in the module repository, wherein the selected first universal module is operable to obtain first data from a user interface; select a second universal module from the plurality of universal modules stored in the module repository, wherein the selected second universal module is configured to obtain second data from the user interface; identify data dependencies between the selected second universal module and the selected first universal module; based on the identified data dependencies, couple the selected second universal module to the selected first universal module to form a first set of coupled universal modules; populate a data collection container with the first set of coupled universal modules, wherein a unique identifier identifies the data collection container; and store the data collection container populated with the first set of coupled universal modules in the composite repository; and wherein the selected first universal module is further operable to: submit a summary page of the selected first universal module to the selected second module for preliminary validation by the selected second universal module; and submit the summary page to the pipeline processing component for final validation of the data collection container populated with the first set of coupled universal modules.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,023,213 and further in view of Chawla (US 2014/0052617). Although the claims at issue are not identical, they are not patentably distinct from each other because U.S. Patent No. 10,649,745 teaches or at least suggests each and every limitation of the instant application, except for the following limitations which Chawla teaches: communicate, with an enterprise server, an authentication token and a request to validate and compile a custom data collection container (¶ 128, “user device 301 may transmit a widget designer request input, e.g., 374, to an API-Tool server 310. The API-Tool server may receive the widget designer request and extract user authentication information, e.g., 375”); and
the authentication token to authenticate the website and a client server to execute the customized service widget within the website (¶ 128, “Authentication information may be in the form of a clear text username/password, a hashed username/password, a cryptographic key, and/or the like. In one embodiment, the API-Tool server may query a widget designer authentication and permissions table for authorized widget designer users, e.g., 376”).
See claim correspondence below.
Instant Application
U.S. Patent No. 11,023,213
1. (Currently Amended) A non-transitory computer-readable storage medium storing computer-readable program code executable by a processor, wherein execution of the computer-readable program code causes the processor to: communicate, with an enterprise server, an authentication token and a request to validate and compile a custom data collection container based on selection of two or more universal modules and based on identification of an order of presentation for the two or more universal modules, and to generate a customized service widget based on the custom data collection container for execution within a website; wherein the request comprises the selection of the two or more universal modules and the identification of the order of presentation of the two or more universal modules, wherein the two or more universal modules comprise: executable programming code to render user-fillable data fields and presentation elements for a graphical user interface and a summary page comprising data requirements; wherein validation of the custom data collection container involves submission of the summary page of a first selected module of the two or more universal modules to a second selected module of the two or more universal modules for validation of the data fields of the first selected module by the second selected module; wherein generation of the customized service widget is based on the validation; the authentication token to authenticate the website and a client server to execute the customized service widget within the website; receive the customized service widget from the enterprise server; and execute, by the client server, the customized service widget within the website to generate the graphical user interface to interact with a user device to perform a service for a user.
1. A system, comprising: a module repository included in a storage device that stores a plurality of universal modules that make up a data input and presentation flow, wherein each universal module includes computer application code that renders information on a display, data fields that store data and a summary page of data requirements for each universal module; and a pipeline processing component including a processor coupled to the module repository, wherein the pipeline processing component is operable to execute programming code, and the pipeline processing component when executing the programming code performs functions, including functions to: identify data dependencies between a first universal module and a second universal module, wherein the first universal module is selected from the plurality of universal modules in the module repository to obtain first data from a user interface and the second universal module is selected from the plurality of universal modules in the module repository to obtain second data from the user interface; validate the selected first universal module by comparing the first data obtained by the selected first universal module with data collection requirements in the summary page of the selected first universal module; validate the selected second universal module by comparing the second data obtained by the selected second universal module with data collection requirements in the summary page of the selected second universal module; based on the validations being successful, couple the first universal module to the second universal module to form a first set of coupled universal modules; populate a data collection container with the first set of coupled universal modules, wherein a unique identifier identifies the data collection container; and provide a data collection widget including the data collection container populated with the first set of coupled universal modules for delivery to a website.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,947,936 and further in view of Chawla (US 2014/0052617). Although the claims at issue are not identical, they are not patentably distinct from each other because U.S. Patent No. 10,649,745 teaches or at least suggests each and every limitation of the instant application, except for the following limitations which Chawla teaches: communicate, with an enterprise server, an authentication token and a request to validate and compile a custom data collection container (¶ 128, “user device 301 may transmit a widget designer request input, e.g., 374, to an API-Tool server 310. The API-Tool server may receive the widget designer request and extract user authentication information, e.g., 375”); and
the authentication token to authenticate the website and a client server to execute the customized service widget within the website (¶ 128, “Authentication information may be in the form of a clear text username/password, a hashed username/password, a cryptographic key, and/or the like. In one embodiment, the API-Tool server may query a widget designer authentication and permissions table for authorized widget designer users, e.g., 376”).
See claim correspondence below.
Instant Application
U.S. Patent No. 11,947,936
1. (Currently Amended) A non-transitory computer-readable storage medium storing computer-readable program code executable by a processor, wherein execution of the computer-readable program code causes the processor to: communicate, with an enterprise server, an authentication token and a request to validate and compile a custom data collection container based on selection of two or more universal modules and based on identification of an order of presentation for the two or more universal modules, and to generate a customized service widget based on the custom data collection container for execution within a website; wherein the request comprises the selection of the two or more universal modules and the identification of the order of presentation of the two or more universal modules, wherein the two or more universal modules comprise: executable programming code to render user-fillable data fields and presentation elements for a graphical user interface and a summary page comprising data requirements; wherein validation of the custom data collection container involves submission of the summary page of a first selected module of the two or more universal modules to a second selected module of the two or more universal modules for validation of the data fields of the first selected module by the second selected module; wherein generation of the customized service widget is based on the validation; the authentication token to authenticate the website and a client server to execute the customized service widget within the website; receive the customized service widget from the enterprise server; and execute, by the client server, the customized service widget within the website to generate the graphical user interface to interact with a user device to perform a service for a user.
1. A non-transitory computer-readable storage medium storing computer-readable program code executable by a processor, wherein execution of the computer-readable program code causes the processor to: receive a selection of a first universal module for presentation in a graphical user interface, wherein the first universal module includes: executable programming code that causes rendering of user-fillable data fields and presentation elements related to user-fillable data fields in the graphical user interface, and a first summary page including data requirements of the first universal module; receive a selection of a second universal module for presentation in the graphical user interface, wherein the second universal module includes: executable programming code that causes rendering of additional user-fillable data fields and additional presentation elements related to the additional user-fillable data fields in the graphical user interface, and a second summary page including data requirements of the second universal module; provide the first summary page from the first universal module to the second universal module for preliminary validation; validate the first universal module based on a comparison between the first summary page and the second summary page; and upon validation, combine the first universal module with the second universal module in a customized data collection container usable by a customized data collection widget; and deliver the customized data collection widget to a website for presentation in the graphical user interface.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-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, Pierre Vital can be reached at (571) 272-4215. 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.
/JACOB D DASCOMB/ Primary Examiner, Art Unit 2198