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 .
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 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.
Claims 1-3, 5-21 are rejected in the Instant Application.
Status of claims
Claims 1-3, 5-12, 15-20 have been amended
Claim 4 has been cancelled
Claim 21 is a newly added claim
Claims 1-3, 5-21 are pending in the instant application
Claims 1-3, 5-21 are rejected in the instant application
Response to Arguments
Applicant’s arguments with respect to claims 1-3, 5-21 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection. The amendments filed 03/11/2026 changed the scope of the claims, based on the amendments a change in reference(s) was required.
Examiner kindly suggests prior to filing a response, the applicant set up a formal interview with the examiner such that details about specific limitations can be clarified inventive concept clearly defined.
Claim Rejections - 35 USC § 103
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 of this title, 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.
Claims 1-3, 5-21 are rejected under 35 U.S.C. 103 as being unpatentable over Stone et al. (US20220334809A1) hereinafter Stone in view of Shemesh et al (US9887969B1) hereinafter Shemesh.
Regarding claims 1, 10, 18: Stone teaches a method comprising [abstract: methods are provided for visual design and customization of processes for web applications]:
receiving, from a client device, a request to fill out a form, wherein the form comprises a plurality of fields for specifying parameters (¶0038 see the client-side web browser application 108 loads the web page and executes the process flow web component incorporated therein within the preview region 602, while the visual process designer 140 listens for events with respect to the data JSON and/or server actions for dynamically updating the sidebar region 604 in accordance with the selected tab 620…¶0034 see GUI elements that are configurable to allow the developer user to manually input or otherwise define the values for the attributes, properties, or fields of metadata to be associated with the configured telephone input component 416, such as, for example, a value for a name field (e.g., “Phone”), a value for a field label field (e.g., “Account Phone”), default values, minimum allowable values and/or maximum allowable values for any fields);
retrieving, a script associated with the form (¶0027 see the configured process flow web component 200 includes HTML code or other presentation code 202 that defines the graphical structure or other characteristics of the web page GUI display(s) associated with a process flow for the web application along with JavaScript code or other client-side executable behavioral code 204 that defines the event-driven behavior associated with the process flow depicted using the web page GUI display(s) defined by the presentation code 202), wherein the script includes logic stored in a document object model (DOM) of a webpage that hosts the form (¶0038 see in FIG. 6, the data JSON tab 620 is selected, which, in turn results in the visual process designer 140 generating a graphical representation of the preview region 602 in the browser document object model (DOM) format, where each element displayed within the preview region 602 has a corresponding JSON key and value, where the JSON key/value pairs control conditions on the display and are input);
generating, on a server, data based on the script, wherein the data is indicative of one or more parameters available for each field of the plurality of fields (¶0042 see behavioral code 214 and configured metadata 216 associated with the configured get account data action component 312 may cause the visual process designer 140 to query a network location designated by the metadata 216 (e.g., database system 130) to retrieve the name, phone number, and/or other details associated with an account and apply the retrieved data to the browser DOM and/or JSON data, which, in turn, may be referenced or otherwise utilized by the code 212, 214 associated with the account details display component 314 to automatically populate a name field of the account details display with the retrieved name, by the code); and
transmitting the data to the client device (¶0028 see the configured web components 210 that are incorporated into a web page GUI display for the process flow similarly includes HTML code or other presentation code 212 [GUI display ie data/page transmitted from server to client])
Stone does not explicitly teach retrieving a script from a script database
Shemesh however in the same field of computer networking teaches from a scripts database (Col 9 lines 5-20 the application manager apparatus 14 using the determined hash value, obtains a stored obfuscated JavaScript code from the obfuscated JavaScript database 22)
Accordingly, it would have been obvious to one of ordinary skill in the art of computer networking at the effective filing date of the claimed invention given the scripts of Stone and the teachings of Shemesh for providing a scripts database to combine the teachings such that Stone utilizes the database as part of the script library. One of ordinary skill in the art would recognize that the results of the combination are predictable because each element in the combination is merely performing the same function it would perform separately. One would be motivated to combine these teachings because doing so will prevent theft of sensitive information present in the JavaScript code and make it harder to reverse engineer the JavaScript code. (Shemesh Col 2 lines 5-15).
Further regarding claim 10. Stone further teaches a system, comprising:
processing circuitry; and a memory, accessible by the processing circuitry, and storing instructions that, when executed by the processing circuitry, cause the processing circuitry to execute a client instance, wherein the client instance is configured to perform operations comprising (¶0019 see a processing system 112, which may be implemented using any suitable processing system and/or device, such as, for example, one or more processors, central processing units (CPUs), controllers, microprocessors, microcontrollers, processing cores and/or other hardware computing resources configured to support the operation of the processing system described herein. The processing system 112 may include or otherwise access a data storage element 114 (or memory) capable of storing programming instructions for execution by the processing system)
Further regarding claim 18. Stone further teaches a non-transitory, computer readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations comprising (¶0070 see machine-readable media 1426 having stored therein software 1428 (which includes instructions executable by the set of one or more processor(s) 1422). The machine-readable media 1426 may include non-transitory and/or transitory machine-readable media)
Regarding claims 2,11: The already combined references teach the method of claim 1, comprising:
providing, to the client device, a request for an input defining a value for a field of the plurality of fields of the form (Stone Fig 3 see form with fields - ¶0025 see incorporated into a web page and generated or otherwise rendered at run-time in accordance with user-defined or user-configured values for various metadata fields or parameters of the respective web component template); and
receiving, from the client device, the input (Stone ¶0031 see a user input search string. For example, in the illustrated implementation, in response to a user inputting a search string for a telephone number)
Regarding claims 3, 12. The already combined references teach the method of claim 2, comprising:
receiving a second input changing the value of the field of the form (Stone ¶0033 see editing region 302 as an initial component to be associated with the process flow);
regenerating, on the server, the data based on the script, wherein the data is indicative of one or more parameters available for a second field of the plurality of fields of the form based on the change to the value of the form (Stone ¶0033 see a database system 130 which may be utilized to prefill fields of a GUI display), followed by a display component..¶0049 see web components 124, 210, 314, 416 to dynamically update the web page GUI displays associated with the web application in real-time in accordance with the user-defined behaviors for the presented web components )
providing, to the client device, a request for a third input defining a second value for the second field of the form (Stone ¶0033 a display component 314 that may be populated using the results or outputs from the preceding components 310, 312) [fields are cascaded, thus second selection allows for other third level fields to be filtered/populated thus allowing for their selection]); and
receiving, from the client device, the third input (Stone Fig 3 see account details selecting account name/number and getting the details allowing users to select a first/second/third etc inputs in the form).
Regarding claim 5 The already combined references teach the method of claim 3, wherein the form comprises an order for a catalog item (Stone ¶0076 see the system 1440 is a multi-tenant cloud computing architecture supporting multiple services, such as one or more of the following types of services: Customer relationship management (CRM); Configure, price, quote (CPQ); Business process modeling (BPM); Customer support; Marketing; External data connectivity; Productivity; Database-as-a-Service; Data-as-a-Service (DAAS or DaaS); Platform-as-a-service (PAAS or PaaS); Infrastructure-as-a-Service (IAAS or IaaS) (e.g., virtual machines, servers, and/or storage); Analytics; Community; Internet-of-Things (IoT); Industry-specific; Artificial intelligence (AI); Application marketplace (“app store”); Data modeling; Authorization; Authentication; Security; and Identity and access management (IAM) [order is a broad term interpreted here in claim 12 as a lookup to the CRM – however Stone does teach the system as being a CPQ and/or app stores])
wherein the script defines possible combinations of characteristics of the catalog item (¶Stone 0026 see The configured web component 124 may also include behavioral code (e.g., JavaScript or other client-side executable code) defining the event-driven behavior of the configured web component 124 within the client application 108 (e.g., in response to user actions, server actions, an event associated with another web component, etc.). The configured web component 124 also includes the user-defined metadata values for the configured web component 124 which may be invoked, referenced, or otherwise utilized by the presentation code and/or behavioral code to generate and render the configured web component 124)
Regarding claims 6, 15 The already combined references teach the method of claim 2, comprising auto-populating, via an auto-populate handler, the field of the form (Stone ¶0015 see a respective configured web component object is created that includes autogenerated code for providing a desired behavior for the respective web component and/or autogenerated code for rendering or otherwise presenting the respective web component in accordance with the input user configuration for the respective web component instance. In this regard, a configured web component object maintains the autogenerated code for effectuating the respective web component in association with user input values for various metadata fields associated with the respective web component. In some implementations, the user configuration may include one or more uniform resource locator (URL) addresses or other network locations for a remote data source from which data is to be retrieved at run-time to generate, render or otherwise implement the respective web component in a manner that may vary dynamically based on the current state of the data at the remote data source)
Regarding claims 7, 16. The already combined references teach the method of claim 6, comprising determining, via a UI policy handler, one or more characteristics of a user interface transmitted to the client device for display (Stone ¶0026 see instance of the web component template [UI policy] 122 in association with the other code and/or data defining the layout, rendering, or behavior of the respective web component template 122. For example, the configured web component 124 may include presentation code (e.g., Hypertext Markup Language (HTML), cascading style sheet (CSS), and/or the like) defining the manner in which the configured web component 124 is to be displayed, rendered or otherwise presented by the client application 108. The configured web component 124 may also include behavioral code (e.g., JavaScript or other client-side executable code) defining the event-driven behavior of the configured web component 124).
Regarding claims 8, 17. The already combined references teach the method of claim 6, comprising retrieving, via a catalog data lookup handler, catalog data for one or more catalog items from a catalog data database (Stone ¶0033 see a functional component 310 to set default values that may drive conditional GUI logic or be used in a later API call (e.g., set a node in the JSON AccountType=Customer) has been added to the process flow editing region 302 as an initial component to be associated with the process flow, followed by an action component 312 to get account data (e.g., a DataRaptor to GET account record data, such as name and phone number, from a database system 130 which may be utilized to prefill fields of a GUI display [catalog is interpreted as customer database ie catalog]).
Regarding claim 9. The already combined references teach the method of claim 1, wherein the script is retrieved via a script handler (Stone ¶0030 see the client application 108 retrieves or otherwise obtains the configured process flow web component 124, 200 via the page generator application 150 and processes or otherwise executes the process flow HTML or other presentation code 202 and the process flow JavaScript or other behavioral code 204 to generate a web page GUI display within the client application 108 at the client device 106. Based on the configured web component sequence metadata 206, the client application 108 and/or the page generator application 150 retrieves or otherwise obtains the configured web component(s))
Regarding claim 13. The already combined references teach the system of claim 12, wherein the form comprises an order for a catalog item (Stone ¶0076 see the system 1440 is a multi-tenant cloud computing architecture supporting multiple services, such as one or more of the following types of services: Customer relationship management (CRM); Configure, price, quote (CPQ); Business process modeling (BPM); Customer support; Marketing; External data connectivity; Productivity; Database-as-a-Service; Data-as-a-Service (DAAS or DaaS); Platform-as-a-service (PAAS or PaaS); Infrastructure-as-a-Service (IAAS or IaaS) (e.g., virtual machines, servers, and/or storage); Analytics; Community; Internet-of-Things (IoT); Industry-specific; Artificial intelligence (AI); Application marketplace (“app store”); Data modeling; Authorization; Authentication; Security; and Identity and access management (IAM) [order is a broad term interpreted here in claim 12 as a lookup to the CRM – however Stone does teach the system as being a CPQ and/or app stores])
Regarding claim 14. The already combined references teach the system of claim 13, wherein the script defines possible combinations of characteristics of the catalog item (Stone ¶0026 see The configured web component 124 may also include behavioral code (e.g., JavaScript or other client-side executable code) defining the event-driven behavior of the configured web component 124 within the client application 108 (e.g., in response to user actions, server actions, an event associated with another web component, etc.). The configured web component 124 also includes the user-defined metadata values for the configured web component 124 which may be invoked, referenced, or otherwise utilized by the presentation code and/or behavioral code to generate and render the configured web component 124)
Regarding claim 19. The already combined references teach the non-transitory, computer readable medium of claim 18, wherein the operations comprise:
providing, to the client device, a request for an input defining a value for a field of the plurality of fields of the form (Stone Fig 3 see form with fields - ¶0025 see incorporated into a web page and generated or otherwise rendered at run-time in accordance with user-defined or user-configured values for various metadata fields or parameters of the respective web component template);
receiving, from the client device, the input (Stone ¶0031 see a user input search string. For example, in the illustrated implementation, in response to a user inputting a search string for a telephone number)
receiving a second input changing the value of the field of the form (Stone ¶0033 see editing region 302 as an initial component to be associated with the process flow);
regenerating, on the server, the data based on the script, wherein the data defines is indicative of one or more parameters available values for a second field of the plurality of fields of the form based on the change to the value of the form (Stone ¶0033 see a database system 130 which may be utilized to prefill fields of a GUI display), followed by a display component..¶0049 see web components 124, 210, 314, 416 to dynamically update the web page GUI displays associated with the web application in real-time in accordance with the user-defined behaviors for the presented web components )
providing, to the client device, a request for a third input defining a second value for the second field of the form (Stone ¶0033a display component 314 that may be populated using the results or outputs from the preceding components 310, 312) [fields are cascaded, thus second selection allows for other third level fields to be filtered/populated thus allowing for their selection]); and
receiving, from the client device, the third input (Stone Fig 3 see account details selecting account name/number and getting the details allowing users to select a first/second/third etc inputs in the form).
Regarding claim 20. The already combined references teach the non-transitory, computer readable medium of claim 18, wherein the operations comprise:
auto-populating, via an auto-populate handler, a field of the plurality of fields of the form (Stone ¶0015 see a respective configured web component object is created that includes autogenerated code for providing a desired behavior for the respective web component and/or autogenerated code for rendering or otherwise presenting the respective web component in accordance with the input user configuration for the respective web component instance. In this regard, a configured web component object maintains the autogenerated code for effectuating the respective web component in association with user input values for various metadata fields associated with the respective web component. In some implementations, the user configuration may include one or more uniform resource locator (URL) addresses or other network locations for a remote data source from which data is to be retrieved at run-time to generate, render or otherwise implement the respective web component in a manner that may vary dynamically based on the current state of the data at the remote data source)
determining, via a UI policy handler, one or more characteristics of a user interface transmitted to the client device for display (Stone ¶0026 see instance of the web component template [UI policy] 122 in association with the other code and/or data defining the layout, rendering, or behavior of the respective web component template 122. For example, the configured web component 124 may include presentation code (e.g., Hypertext Markup Language (HTML), cascading style sheet (CSS), and/or the like) defining the manner in which the configured web component 124 is to be displayed, rendered or otherwise presented by the client application 108. The configured web component 124 may also include behavioral code (e.g., JavaScript or other client-side executable code) defining the event-driven behavior of the configured web component 124); and
retrieving, via a catalog data lookup handler, catalog data for one or more catalog items from a catalog data database (Stone ¶0033 see a functional component 310 to set default values that may drive conditional GUI logic or be used in a later API call (e.g., set a node in the JSON AccountType=Customer) has been added to the process flow editing region 302 as an initial component to be associated with the process flow, followed by an action component 312 to get account data (e.g., a DataRaptor to GET account record data, such as name and phone number, from a database system 130 which may be utilized to prefill fields of a GUI display [catalog is interpreted as customer database ie catalog]).
Regarding claim 21. The already combined references teach the method of claim 1, comprising loading, on the server, a javascript proxy object, wherein generating the data based on the script is via the javascript proxy object (Stone ¶0038 see generating a graphical representation of the preview region 602 in the browser document object model (DOM) format, where each element displayed within the preview region 602 has a corresponding JSON key and value, where the JSON key/value pairs control conditions on the display and are input to any external application programming interface (API) calls [REST/SOAP APIs on server act as proxies for JSON (JavaScript Object Notation) to send the data])
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
References are cited not only for their quoted language but for all that they teach.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Atta Khan whose telephone number is 571-270-7364. The examiner can normally be reached on M-F 09:00-6:00.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Vivek Srivastava can be reached on (571) 272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ATTA KHAN/
Examiner, Art Unit 2449
