DETAILED ACTION
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 .
Response to Amendment
The rejections under 35 U.S.C. §112(b) of claims 1-20 are withdrawn in view of the amendments to the independent claims.
The rejections under 35 U.S.C. §112(a) of claims 5 and 14 are withdrawn in view of the amendments to claims 5 and 14.
Examiner acknowledges the amendments to the claims received on 4/10/2026 have been entered, and that no new matter has been added.
Response to Arguments
Argument 1: Applicant argues on page 16 in the filing on 4/10/2026 that the cited prior art does not teach “the previously presented "request to generate at least one user interface" or the newly added "rule that dictates how components interact"” in claim 1.
Response to Argument 1: Respectfully, Azmoon discloses a “request to generate at least one user interface” with a user input to request rendering of the GUI [Azmoon 0123, Fig. 6]. Regarding a “rule that dictates how components interact,” Azmoon discloses a framework definition that specifies predetermined components and a layout of the predetermined components within the GUI. This layout rule dictates component placements, which is how components interact with the GUI layout. See rejection below for more details.
Argument 2: Applicant argues on page 17 that the cited prior art does not teach an “access management provider” in claim 1.
Response to Argument 2: Respectfully, Azmoon teaches an identity provider and an access management provider. Azmoon 0122, Fig. 6, teaches a login/password prompt that linked to a user identifier, as an identity provider. Further, in Azmoon 0129, certain components are determined, adapted, changed, or provided, based on attributes with the user identifier. This “allows the GUI to automatically provide each respective user with… resources that are relevant to the respective user [Azmoon 0129].” See rejection below for more details.
Argument 3: Applicant argues on page 18 that the cited prior art does not teach “configuration software plugin” in claim 1.
Response to Argument 3: Respectfully, on page 19 in the remarks filed 4/10/2026, the Applicant argues that a “plugin” is “a software component that adds functionality… without requiring any changes to its core code.”
Azmoon discloses “components may… take the form of cards, lists, drop-down menus [Azmoon 0133],” and that components may be replaced or moved by dragging [Azmoon 0153]. These GUI elements are added or moved without changing programming code.
Azimi discloses “potential modifications may be selected from one of more of: adding a component, deleting a component, moving a component and modifying an attribute of a component [Azimi 0010].” These GUI elements are modified or moved without changing programming code.
Thus Azmoon’s components and Azimi’s components appear to match applicant’s definition of a plugin. See rejection below for more details.
This meets the claim limitations as currently claimed, and Applicant's Arguments 1-2 filed on 4/10/2026 are moot in view of new grounds of rejection necessitated by the applicant’s amendment; Applicant’s Argument 3 is not persuasive. Applicant’s remaining statements regarding the remaining independent and dependent claims are moot or not persuasive for the reasons stated 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.
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.
Claims 1-4, 6-7, 10-13, 15-16, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Azmoon et al., Patent Application Publication number US 20220091726 A1, (hereinafter “Azmoon”), in view of Kamadolli et al., Patent Application Publication number US 20170185612 A1, (hereinafter “Kamadolli”), in view of Azimi et al., Patent Application Publication number US 20230131183 A1, (hereinafter “Azimi”), in view of Williams et al., Patent Number US 8452876 B1, (hereinafter “Williams).
Claim 1: Azmoon teaches “A method for providing an intelligent end-to-end platform to facilitate dynamic user interface configuration (i.e. user input may include a request the rendering of a GUI. For example, the GUI may be associated with a particular software application and/or webpage provided by server application 600 [Azmoon 0123]), the method being implemented by at least one processor (i.e. memory 104 may store these program instructions on a non-transitory, computer-readable medium, such that the instructions are executable by processor 102 [Azmoon 0050]… input devices, such as a keyboard, a mouse, a touch screen, and so on [Azmoon 0053]), the method comprising:
automatically generating, by the at least one processor, a plurality of core layouts (Azmoon’s 0124’s visual formats; formats noted as plural) based on a predetermined platform structure (i.e. framework definition may specify a first plurality of predetermined components of the GUI… the framework definition may also specify visual formats for the first plurality of predetermined components [Azmoon 0124])… , each of the plurality of core layouts utilizing at least one corresponding executable microapp to perform at least one respective task (i.e. second plurality of components thus allows the GUI to automatically provide each respective user with references to software applications, webpages, files, and/or other resources that are relevant to the respective user [Azmoon 0129]… in FIG. 8A, the second plurality of components may… populate favorites tab 806 and/or recommended tab 808. For example, favorites panel 812 (displayed in response to selection of favorites tab 806) may be populated with text field 814, cards 818, 822, 826, and 830 (i.e., cards 818-830), and list items 836, 840, 844, and 848 (i.e., list items 836-848) [Azmoon 0158, Fig. 8A-8C] note: each component of each visual format corresponds to a function/microapp of the main parent GUI) and the at least one corresponding executable microapp including an authentication layer that secures the at least one corresponding executable microapp by utilizing an identity provider (i.e. user identifier may take the form of a session token/identifier (e.g., a session cookie) which may have been provided to client device 602 by server application 600 based on and/or in response to successful authentication by client device 602. For example, the user identifier may be provided to client device 602 by server application 600 based on a username and password [Azmoon 0122, Fig. 6] note: the authentication validation occurs before each component (microapp) is presented to the user, see fig. 6. Thus, this is an authentication layer that secures the microapp), and an access management provider (i.e. the second plurality of components may be dynamically-determined and thus able to adapt to changes in the attributes associated with the user identifier… allows the GUI to automatically provide each respective user with references to software applications, webpages, files, and/or other resources that are relevant to the respective user [Azmoon 0129] note: the user identifier of the authentication service determines which components (microapps) to display. Thus, this is another layer of authentication that secures the microapps), to perform validation services;
persisting, by the at least one processor, the plurality of core layouts in a core repository (i.e. from persistent storage, a framework definition that specifies a first plurality of predetermined components of a graphical user interface and a layout of the first plurality of predetermined components within the graphical user interface [Azmoon [0169] note: at least a portion of the layout is stored);
displaying, by the at least one processor via a graphical user interface, at least one graphical element that is configured to receive at least one input (i.e. one or more predetermined components of the first plurality of predetermined components may be a navigational component, such as a tab or button of a toolbar. Selection of the navigational component may cause display of a panel, overlay, or other section of the GUI [Azmoon 0007]);
receiving, by the at least one processor via the graphical user interface, a request to generate at least one user interface based on a rule that dictates how components interact (i.e. user input may include a request the rendering of a GUI [Azmoon 0123, Fig. 6]… in response to reception of the request at arrow 608, server application 600 may be configured to transmit, to persistent storage 604, a request for a framework definition, as indicate by arrow 610. The framework definition may specify a first plurality of predetermined components of the GUI, as well as a layout of the first plurality of predetermined components within the GUI [Azmoon 0124] note: following a layout rule that dictates components placements, which is how components interact with the GUI layout), the request being received from an action of dragging and dropping… onto a build screen (i.e. the layout and appearance… are manually modified by, for example, the user, an administrator, and/or a programmer [Azmoon 0127]… The GUI may be configured to allow users to make manual modifications to the GUI after it is displayed. Specifically, the GUI may allow for manual modifications to dynamically-determined components 724 (e.g., replacement of a component with another component that is not part of components 724), component positions 730 (e.g., dragging one or more of components 724 to different locations)… manual modifications may indicate corrections or improvements that the user has made to the output of model 700 and/or 702. In some cases, the state of the GUI after a manual modification may be considered to be more preferable and/or optimal than the initially-generated GUI [Azmoon 0153] note: dragging/dropping components modifies the GUI, or re-generates the GUI) to form a combination of the rule and at least one from among a business logic and a service (Azmoon 0153 above, discloses drag/drop to update the GUI. A replacement (or movement) of components updates the GUI in both the layout rule (the new component takes the same space as the removed component), and the component’s service (such as table 887, graph 889) in Fig. 8C);
identifying, by the at least one processor, based on the request, at least one matching core layout (i.e. a request for a framework definition, as indicate by arrow 610. The framework definition may specify… a layout of the first plurality of predetermined components within the GUI [Azmoon 0124] note: a request for a framework definition which includes a layout. In essence, a request for a layout) from the plurality of core layouts in the core repository (i.e. persistent storage 604 may be configured to transmit, to server application 600, the framework definition, as indicated by arrow 612. In some cases, the transmission at arrow 612 may also include the data to be displayed by way of the first plurality of predetermined components of the GUI [Azmoon 0126, Fig 6] note: Fig. 6 element 608 and 610 requesting a framework definition/layout. Note2: Fig. 6 element 612 returns the framework definition from the storage of framework definitions (layouts), above. This indicates identifying a matching layout from among the plurality of layouts in the storage); and
automatically generating, by the at least one processor, the at least one user interface by using the at least one matching core layout (Azmoon 0137’s framework definition/layout), and the request (Azmoon Fig. 6 element 608 and 610’s requests) (i.e. client device 602 may be configured to render the GUI based on the framework definition [Azmoon 0137]), to produce a… component that comprises a configuration software plugin (i.e. components may… take the form of cards, lists, drop-down menus [Azmoon 0133]… GUI may allow for manual modifications to dynamically-determined components 724 (e.g., replacement of a component with another component that is not part of components 724), component positions 730 (e.g., dragging one or more of components 724 to different locations [Azmoon 0153] note: GUI elements are added or moved without changing programming code, thus they are software plugins)…”
Azmoon is silent regarding a predetermined platform structure “that outlines a necessary arrangement of backend services that facilitate functionalities of the plurality of core layouts.”
Kamadolli teaches “automatically generating, by the at least one processor, a plurality of core layouts (i.e. there may be multiple layout configurations for rendering the named webpage. The user (e.g., an administrator) can select any configuration/version for rendering the webpage [Kamadolli 0040]) based on a predetermined platform structure that outlines a necessary arrangement of backend services that facilitate functionalities of the plurality of core layouts (i.e. When the function getpagelayout( ) is called, a page layout backend service may be invoked [Kamadolli 0040]… page layout backend service invokes page layout template store… the page layout template store invokes each widget (i.e., each UI component) included in the page layout template. Invoking a widget may include invoking a backend callback service [Kamadolli 0041] note: page layout backend service invokes… each widget. “Layout” indicates arrangement of each widget/backend service/function of the webpage layout)…;”
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention/combination of Azmoon to include the feature of having the ability to configure backend services as disclosed by Kamadolli.
One would have been motivated to do so, before the effective filing date of the invention because it provides the benefit to automatically call and configure backend services, which automatically calls and configures functions of the layout, which reduces manual user input, which increases efficiency.
Azmoon and Kamadolli are silent regarding to produce a “grid” component that comprises a configuration software plugin “that is configured to activate each feature that is associated with the at least one user interface.”
Azimi teaches “to produce a grid component (Azimi Fig. 12D-A and 12D-B shows boxes, or grids) that comprises a configuration software plugin (i.e. an algorithm is applied to decompose the screen into main sections and extracts the attributes for the main screen and each section. A section is a group of elements that perform a function such as a buy section and an image view section [Azimi 0055]… A library of UI guidelines is used which is constructed from a set of standardized UI guidelines… for designing each interface component as well as the overall layout [Azimi 0059]… potential modifications may be selected from one of more of: adding a component, deleting a component, moving a component and modifying an attribute of a component [Azimi 0010] note: components are moved without changes in core software code, thus these components are software plugins) that is configured to activate each feature that is associated with the at least one user interface (i.e. in FIGS. 12D-A and 12D-B, by leveraging the model created from the auto-assessment, the system may create a mockup to visually modify the interface to apply a template to match the style of the target interface… In the present example, the template copy and optimal location for “free shipping” is integrated into an appropriate area of the “buy” section of the UI… By applying the training method for the auto-heal algorithm the system is able to analyze and understand the target interface and apply the template in a visually consistent and suitable manner [Azimi 0107, Fig. 12D-A and 12D-B] note: activates the “free shipping” feature by integrating it into the “buy” section of the UI. The “free shipping” also features center font adjustment to match the “Buy” text in that section).”
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention/combination of Azmoon and Kamadolli to include the feature of having the ability to have a region share attributes as disclosed by Azimi.
One would have been motivated to do so, before the effective filing date of the invention because it provides the benefit to “apply the template in a visually consistent and suitable manner [Azimi 0107].”
Azmoon and Kamadolli and Azimi are silent regarding dragging and dropping “the rule” onto a build screen.
Williams teaches “an action of dragging and dropping the rule onto a build screen to form a combination of the rule and at least one from among a business logic and a service (i.e. a network manager to add rules to that policy by dragging, e.g., with a mouse, associated rule templates from the area identified as 402 into the Policy and Configuration Area 403 and then dropping them there. FIG. 3 shows a panel area identified as 401, on the left side of the component, where completed and named policies are displayed, using abbreviations for a policy's rules, such as "B" for Block and "R" for Rate Shape. FIG. 4 also shows an area identified as 404, where the network manager might associate a rule in a policy with an application, such as the P2P application, GNUtella [Williams Col 9 lines 2-12]).”
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention/combination of Azmoon and Kamadolli and Azimi to include the feature of having the ability to drag and drop configurations as disclosed by Williams.
One would have been motivated to do so, before the effective filing date of the invention because it provides the benefit to allow people to configure user interface elements, without needing computer programming coding knowledge.
Claim 2: Azmoon and Kamadolli and Azimi and Williams teach all the limitations of claim 1, above. Azmoon teaches “further comprising:
aggregating, by the at least one processor, configuration data that correspond to the at least one user interface (Azmoon 0149’s components (layouts) and visual formats), the configuration data including information that relates to at least one from among the request, the at least one matching core layout, and the at least one user interface (i.e. Component appearance model 702 may be configured to generate component positions 730 and component visual formats 732… based on… predetermined component(s) 718 [layouts]… prior visual formats 726, and/or prior positions 728 [user interface] [Azmoon 0149] note: from claim 1, layouts are generated based on requests. The components/layouts match a component/layout from storage 604. The layouts relate to the user interface. Note2: based on, indicates that the data has been formatted for use, or aggregated);
associating, by the at least one processor, the configuration data with a line of business (i.e. models 700 and 702 may dynamically determine components that are expected to be useful for summarizing application states to a particular user. Different users may thus see different components when viewing IT overview overlay 878. For example, a different user might instead be provided with a graph as part of agent workspace component 880 [Azmoon 0165] note: different user roles as a line of business) by using identifying data that is extracted from the request (i.e. collaboration owner workspace 886 may be populated with table 887, software asset management component 888 may be populated with graph 889, and vulnerability incident response component 890 may be populated with graph 891. Table 887, graph 889, and graph 891 may be selected, for example, one the basis of the user frequently viewing these tables/graphs when using the corresponding software applications, and/or based on other users frequently viewing these tables/graphs [Azmoon 0165] note: a request for a GUI for different roles identifies which table (data) to use); and
persisting, by the at least one processor, the configuration data and the association in a historical configuration database (i.e. Component appearance model 702 may be configured to generate component positions 730 and component visual formats 732… based on… predetermined component(s) 718 [layouts]… prior visual formats 726, and/or prior positions 728 [user interface] [Azmoon 0149] note: prior formats and positions indicates that historical interfaces are being persisted/stored).”
Claim 3: Azmoon and Kamadolli and Azimi and Williams teach all the limitations of claim 2, above. Azmoon teaches “further comprising:
determining, by the at least one processor using at least one model (i.e. Model 700 and model 702 may each represent one or more machine learning algorithms [Azmoon 0139, Fig. 7]), at least one suggested configuration for the line of business (i.e. models 700 and 702 may dynamically determine components that are expected to be useful for summarizing application states to a particular user. Different users may thus see different components when viewing IT overview overlay 878. For example, a different user might instead be provided with a graph as part of agent workspace component 880 [Azmoon 0165, Fig. 7] note: different user roles as a line of business) based on the corresponding configuration data in the historical configuration database (i.e. Component appearance model 702 may be configured to generate component positions 730 and component visual formats 732… based on… predetermined component(s) 718 [layouts]… prior visual formats 726, and/or prior positions 728 [user interface] [Azmoon 0149]); and
displaying, by the at least one processor via the graphical user interface, the at least one suggested configuration in the at least one graphical element (i.e. a first plurality of predetermined components [layouts, from claim 1] and a second plurality of components determined by way of a machine learning model [Azmoon 0155]… one or more predetermined components of the first plurality of predetermined components may be a navigational component, such as a tab or button of a toolbar. Selection of the navigational component may cause display of a panel, overlay, or other section of the GUI [Azmoon 0007]) for the line of business (i.e. models 700 and 702 may dynamically determine components that are expected to be useful for summarizing application states to a particular user. Different users may thus see different components when viewing IT overview overlay 878. For example, a different user might instead be provided with a graph as part of agent workspace component 880 [Azmoon 0165, Fig. 7] note: different user roles as a line of business).”
Claim 4: Azmoon and Kamadolli and Azimi and Williams teach all the limitations of claim 3, above. Azmoon teaches “wherein the at least one model includes at least one from among a machine learning model, a mathematical model, a process model, and a data model (i.e. Model 700 and model 702 may each represent one or more machine learning algorithms [Azmoon 0139, Fig. 7] note: machine learning algorithm is also a machine learning model, a mathematical model, a process model, and a data model).”
Claim 6: Azmoon and Kamadolli and Azimi and Williams teach all the limitations of claim 1, above. Azmoon teaches “wherein receiving the request further comprises:
receiving, by the at least one processor via the graphical user interface, at least one user action (i.e. users and/or administrators may be able to determine whether a particular component is predetermined or is configured to be dynamically-determined as part of the GUI [Azmoon 0130]… client device 602 may be configured to render the GUI based on the framework definition [Azmoon 0137]… the layout and appearance… are manually modified by, for example, the user, an administrator, and/or a programmer [Azmoon 0127]) that corresponds to the selection, wherein the at least one user action includes a drag and drop action to select at least one from among the rule (i.e. manual modifications may indicate corrections [Azmoon 0153] note: what is correct as a rule; e.g. fixing corrections as a rule), the business logic (i.e. more preferable and/or optimal than the initially-generated GUI [Azmoon 0153] note: optimization as a business logic), and the service (i.e. manual modifications may indicate… improvements [Azmoon 0153] note: improvements as a service) (i.e. The GUI may be configured to allow users to make manual modifications to the GUI after it is displayed. Specifically, the GUI may allow for manual modifications to dynamically-determined components 724 (e.g., replacement of a component with another component that is not part of components 724), component positions 730 (e.g., dragging one or more of components 724 to different locations)… manual modifications may indicate corrections or improvements that the user has made to the output of model 700 and/or 702. In some cases, the state of the GUI after a manual modification may be considered to be more preferable and/or optimal than the initially-generated GUI [Azmoon 0153]).”
Claim 7: Azmoon and Kamadolli and Azimi and Williams teach all the limitations of claim 1, above. Azmoon teaches “wherein automatically generating the at least one user interface further comprises:
extracting, by the at least one processor, at least one configuration from the request, the at least one configuration corresponding to the at least one user interface (i.e. Component appearance model 702 may be configured to generate component positions 730 and component visual formats 732… based on… predetermined component(s) 718 [layouts]… prior visual formats 726, and/or prior positions 728 [user interface] [Azmoon 0149] note: from claim 1, layouts are generated based on requests. The user interface is based on, or configured corresponding to, prior components/layouts/formats/positions);
generating, by the at least one processor, a configuration component for each of the at least one matching core layout based on the extracted at least one configuration (i.e. models 700 and 702 may dynamically determine components that are expected to be useful for summarizing application states to a particular user. Different users may thus see different components when viewing IT overview overlay 878. For example, a different user might instead be provided with a graph as part of agent workspace component 880 [Azmoon 0165]); and
automatically generating, by the at least one processor, the at least one user interface by combining the at least one matching core layout with the corresponding configuration component (i.e. models 700 and 702 may dynamically determine components that are expected to be useful for summarizing application states to a particular user. Different users may thus see different components when viewing IT overview overlay 878. For example, a different user might instead be provided with a graph as part of agent workspace component 880 [Azmoon 0165] note: different user roles as a line of business).”
Claim 10: Azmoon and Kamadolli and Azimi and Williams teach a computing device configured to implement an execution of a method for providing an intelligent end-to-end platform to facilitate dynamic user interface configuration, the computing device comprising: a processor; a memory; and a communication interface coupled to each of the processor and the memory (i.e. memory 104 may store these program instructions on a non-transitory, computer-readable medium, such that the instructions are executable by processor 102 [Azmoon 0050]… input devices, such as a keyboard, a mouse, a touch screen, and so on [Azmoon 0053]), wherein the processor is configured to perform operations corresponding to the method of claim 1; therefore, it is rejected under the same rationale.
Claim 11: Claim 11 is similar in content and in scope to claim 2, thus it is rejected under the same rationale.
Claim 12: Claim 12 is similar in content and in scope to claim 3, thus it is rejected under the same rationale.
Claim 13: Claim 13 is similar in content and in scope to claim 4, thus it is rejected under the same rationale.
Claim 15: Claim 15 is similar in content and in scope to claim 6, thus it is rejected under the same rationale.
Claim 16: Claim 16 is similar in content and in scope to claim 7, thus it is rejected under the same rationale.
Claim 19: Azmoon and Kamadolli and Azimi and Williams teach a non-transitory computer readable storage medium storing instructions for providing an intelligent end-to-end platform to facilitate dynamic user interface configuration, the storage medium comprising executable code which, when executed by a processor (i.e. memory 104 may store these program instructions on a non-transitory, computer-readable medium, such that the instructions are executable by processor 102 [Azmoon 0050]… input devices, such as a keyboard, a mouse, a touch screen, and so on [Azmoon 0053]), causes the processor to perform operations corresponding to the method of claim 1; therefore, it is rejected under the same rationale.
Claim 20: Claim 20 is similar in content and in scope to claim 2, thus it is rejected under the same rationale.
Claims 5 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Azmoon, in view of Kamadolli, in view of Azimi, in view of Williams, in view of Ambekar et al., Patent Application Publication number US 20050204368 A1 (hereinafter “Ambekar”).
Claim 5: Azmoon and Kamadolli and Azimi and Williams teach all the limitations of claim 1, above. Azmoon and Kamadolli and Azimi and Williams are silent regarding “wherein automatically generating the plurality of core layouts further comprises: identifying, by the at least one processor, at least one code library that corresponds to the predetermined platform structure and comprises at least one core actions library that is stored within the core repository and relates to a configurable workflow that is utilized by each Java archive (JAR) file that is inside the core repository; identifying, by the at least one processor, at least one interaction that corresponds to the predetermined platform structure; identifying, by the at least one processor, at least one dependency that corresponds to the predetermined platform structure; and
automatically generating, by the at least one processor, each of the plurality of core layouts based on the at least one code library, the at least one interaction, and the at least one dependency.”
Ambekar teaches “wherein automatically generating the plurality of core layouts further comprises:
identifying, by the at least one processor, at least one code library that corresponds to the predetermined platform structure and comprises at least one core actions library that is stored within the core repository and relates to a configurable workflow that is utilized by each Java archive (JAR) file that is inside the core repository (i.e. developing and testing an interface system according to invention principles is reduced relative to previous known processes due in part to automatic generation of wrapper code encapsulating selected interface code components derived from a library of stored code components [Ambekar 0015] note: code library corresponding to an interface system; and “developing and testing” as a configurable workflow. Note2: developing and testing an interface encompasses testing each portion of an interface, so the workflow test/utilizes each feature/code of the interface);
identifying, by the at least one processor, at least one interaction that corresponds to the predetermined platform structure (i.e. predetermined functions including those of an operating system, healthcare information system or other information processing system, for example, in response user command or input [Ambekar 0017, Fig. 2] note: Fig. 2’s user interface 27 provides interaction to the previous system/structure/template);
identifying, by the at least one processor, at least one dependency that corresponds to the predetermined platform structure (i.e. automatically generates thin layer interface wrapper code encapsulating selected interface code components derived from a library of stored code components (such as functional Application Programming Interfaces (APIs)) to provide resultant interface code components [Ambekar 0016, Fig. 2] note: Fig. 2’s Legacy Product, Database, Web, User Interface, Enterprise/Web Product, and External Systems are all dependencies of the new generated adaptation interface system, 50); and
automatically generating, by the at least one processor, each of the plurality of core layouts based on the at least one code library, the at least one interaction, and the at least one dependency (see Ambekar 0015-0017, Fig 2, above).”
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention/combination of Azmoon and Kamadolli and Azimi and Williams to include the feature of having the ability to identify components as disclosed by Ambekar.
One would have been motivated to do so, before the effective filing date of the invention because it provides the benefit to be able to generate user interfaces that use or depend on the components, which increases the variety of user interfaces that can be generated, which increases user flexibility.
Claim 14: Claim 14 is similar in content and in scope to claim 5, thus it is rejected under the same rationale.
Claims 8-9 and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Azmoon, in view of Kamadolli, in view of Azimi, in view of Williams, in view of Yen et al., Patent Application Publication number US 20220245507 A1 (hereinafter “Yen”).
Claim 8: Azmoon and Kamadolli and Azimi and Williams teach all the limitations of claim 1, above. The combination of Azmoon and Kamadolli and Azimi and Williams teach automatically generated user interfaces (see claim 1).
Azmoon and Kamadolli and Azimi and Williams are silent regarding “capturing, by the at least one processor via the automatically generated at least one user interface, user profile data and corresponding search history data; utilizing a historical configuration database to determine, by the at least one processor using at least one model, at least one predicted data set; and preloading, by the at least one processor, the at least one predicted data set in a temporary quick access repository for the user.”
Yen teaches “capturing, by the at least one processor via the… at least one user interface, user profile data and corresponding search history data;
utilizing a historical configuration database (i.e. models may implement various types of machine learning algorithms and/or model parameters to process user features of users (e.g., … user profile information… user search history…) [Yen 0036] note: using sets of data in memory, i.e. a database) to determine, by the at least one processor using at least one model, at least one predicted data set (i.e. A content serving platform may utilize models to select what content to provide to particular users… models may implement various types of machine learning algorithms and/or model parameters to process user features of users… models may process the user features of the users and/or the content features of the content in order to select a particular content item to provide to a particular user based upon the content item having a relatively high predicted likelihood of being engaged with by that user [Yen 0036]); and
preloading, by the at least one processor, the at least one predicted data set in a temporary quick access repository for the user (i.e. models may process the user features of the users and/or the content features of the content in order to select a particular content item to provide to a particular user based upon the content item having a relatively high predicted likelihood of being engaged with by that user [Yen 0036] note: the data that is selected is at least stored in RAM, as a function of a generic computer system).”
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention/combination of Azmoon and Kamadolli and Azimi and Williams to include the feature of having the ability to predict data as disclosed by Yen.
One would have been motivated to do so, before the effective filing date of the invention because it provides the benefit to be able to generate UI components with less user intervention, saving manual labor.
Claim 9: Azmoon and Kamadolli and Azimi and Williams and Yen teach all the limitations of claim 8, above. Yen teaches “further comprising:
automatically archiving, by the at least one processor using the at least one model, the at least one predicted data set (i.e. models may process the user features of the users and/or the content features of the content in order to select a particular content item to provide to a particular user based upon the content item having a relatively high predicted likelihood of being engaged with by that user [Yen 0036] note: the data that is selected is at least stored [archived] in RAM, as a function of a generic computer system) based on the user profile data and the corresponding search history data (i.e. models may implement various types of machine learning algorithms and/or model parameters to process user features of users (e.g., … user profile information… user search history…)),
wherein the at least one predicted data set is automatically archived at a time determined by using the at least one model (i.e. models may process the user features of the users and/or the content features of the content in order to select a particular content item to provide to a particular user based upon the content item having a relatively high predicted likelihood of being engaged with by that user [Yen 0036] note: the data that is selected is at least stored [archived] in RAM, as a function of a generic computer system).”
One would have been motivated to combine Azmoon and Kamadolli and Azimi and Williams and Yen, before the effective filing date of the invention because it provides the benefit to generate UI components with less user intervention, saving manual labor.
Claim 17: Claim 17 is similar in content and in scope to claim 8, thus it is rejected under the same rationale.
Claim 18: Claim 18 is similar in content and in scope to claim 9, thus it is rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lee (US 20220036756 A1) listed on 892 is related to designing GUI interfaces.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL SHEN whose telephone number is (469)295-9169 and email address is samuel.shen@uspto.gov. The examiner can normally be reached Monday-Thursday, 7:00 am - 5:00 pm CT.
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, Fred Ehichioya can be reached on (571) 272-4034. 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.
/S.S./Examiner, Art Unit 2179
/IRETE F EHICHIOYA/Supervisory Patent Examiner, Art Unit 2179
Prosecution Insights