DETAILED ACTION
This action is in response to the RCE and Amendment dated 08 January 2026. Claims 1, 11 and 21 are amended. No claims have been added or cancelled. Claims 1, 2, 4-12 and 14-21 remain pending and have been considered below.
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 .
Claim Rejections - 35 USC § 103
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.
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.
Claims 1, 2, 4, 6-12, 14 and 16-21 are rejected under 35 U.S.C. 103 as being unpatentable over Almecija et al. (US 2018/0365025 A1) in view of Cote (US 2013/0212487 A1) and further in view of Kotler et al. (US 2013/0019203 A1).
As for independent claim 1, Almecija teaches a method comprising:
generating a simulation of an application executable to provide a display of a graphic user interface that includes an arrangement of application elements [(e.g. see Almecija paragraphs 0071, 0116 and Fig. 3) ”The computing environment 1700 includes a cloud deployment architecture consisting of one or more clients 1702 that can be communicatively coupled to a system cloud 1704 via a network (e.g., the Internet). The system cloud 1704 can include a cloud load balances, one or more application container, one or more cloud service containers, a cloud data store, and a cloud network that communicatively couples the one or more cloud components to the cloud data store. In accordance with the cloud deployment architecture, the clients 1702 can include one or more clients devices (e.g., a mobile device, a laptop computer, a desktop computer, etc.) which can include or employ a suitable application (e.g., a native mobile application, a web-based application, a thin/thick client application, etc.) to access and employ one or more features and functionalities of the subject native/reconstructed medical imaging systems deployed in the system cloud 1704. In various implementations, the one or more components of system 100 can be distributed between the clients 1702 and the system cloud 1704 … FIG. 3 shows a user interface that may presented to a more experienced user, according to an embodiment. Generally, more experienced users have learned about what various buttons, menus, and imaging layouts do when interacted with. These advanced users have learned the details of working with the program and prefer to have all of their options available to them. The user interface may still be adapted to show features they are most likely to need or want based on their working habits, history, profile, and other factors, but the UI is likely to include more options and features on the outputted UI. Thus FIG. 3 shows user interface 300 with UI buttons 304 and UI imaging layouts 302”].
transmitting the simulation to one or more mobile devices over a communication network [(e.g. see Almecija paragraph 0116) ”The computing environment 1700 includes a cloud deployment architecture consisting of one or more clients 1702 that can be communicatively coupled to a system cloud 1704 via a network (e.g., the Internet). The system cloud 1704 can include a cloud load balances, one or more application container, one or more cloud service containers, a cloud data store, and a cloud network that communicatively couples the one or more cloud components to the cloud data store. In accordance with the cloud deployment architecture, the clients 1702 can include one or more clients devices (e.g., a mobile device, a laptop computer, a desktop computer, etc.) which can include or employ a suitable application (e.g., a native mobile application, a web-based application, a thin/thick client application, etc.) to access and employ one or more features and functionalities of the subject native/reconstructed medical imaging systems deployed in the system cloud 1704. In various implementations, the one or more components of system 100 can be distributed between the clients 1702 and the system cloud 1704”].
polling the mobile devices for a user selection corresponding to one or more of the application elements [(e.g. see Almecija paragraph 0050 and Fig. 2 numeral 204) ”At step 204, an initial user interface is selected. This can be a simple selection of a beginner user experience level user interface or advanced user interface in some embodiments. In alternate embodiments, there may be a sliding scale where the selection is along a scale from beginner on one end and advanced on another, like a score from 1 to 100 in an example. In alternate embodiments, a certain number of options are available, such as beginner, moderate, and advanced. The selection can be made … by the user directly with no assistance from user experience system 104, by a setting in an options menu or the like, or through a suggestion by user experience determination component 144 that the user reviews and selects the desired UI”].
querying a database based on the user selections, wherein querying the database includes identifying one or more options for changing one or more of the arrangement of application elements [(e.g. see Almecija paragraphs 0047, 0092) ”Adaptive UI output 708 layer decides as to how to adapt the user interface based on the factors, groupings, and ratings within the system. This can be in the form of a simple tool bar, advanced tool bar, simple layout, advanced layout, hints, tooltips, automation suggestions, no change, change paradigm, and many others as discussed throughout. For an example, if the user has a lower level of experience with the software application but is exactly following the best practice to complete a specific task, the system may give a simple tool bar and a simple layout to help the user perform the exact task. For an example, if the user experience level is low and user speed is needed, the user experience system may output hints in the form of arrows to exactly the buttons or steps needed to complete the task. For an example, if the user experience level is high and user speed is not needed, the system may provide more buttons in the tool bar to help give the user time to explore the options they may want without hiding the options in sub-menu … This includes compiling whatever UI assets, images, sounds, and the like are needed. These may be stored in memory 152, a hard drive in hardware systems 108, and/or a remote storage device in an external data source 110”].
receiving one or more selected options corresponding to an identified change [(e.g. see Almecija paragraphs 0046, 0047) ”At step 612, user experience system 104, through UI adaptive component 148 in an embodiment, adapts a user interface per user experience level and/or assigned grouping. Adapting the user interface can mean re-sizing the screen, changing the layout, reducing or adding buttons, changing menus, altering what content is shown, changing fonts, changing paradigms (e.g. visual to audible), changing icons, re-arranging UI assets, and more … At step 614, user experience system 104, through UI output component 150 in an embodiment, outputs the adapted UI to user IO 102. This includes compiling whatever UI assets, images, sounds, and the like are needed. These may be stored in memory 152, a hard drive in hardware systems 108, and/or a remote storage device in an external data source 110”].
updating the display of the graphic user interface in real-time based on the selected options [(e.g. see Almecija paragraph 0047) ”At this point a user has an improved user interface experience based on the user experience system adapting the user interface particularly to the user, the user's hardware, and the user's situation. The whole process 600 can take place almost instantaneously so that the user sees the UI adapt in real-time”].
Almecija does not specifically teach publishing the application that includes an updated display of the graphic user interface to a plurality of different user devices each associated with a different user, wherein application usage data from the plurality of different user devices is collected for user in rearranging the arrangement of application elements. However, in the same field of invention, Cote teaches:
publishing the application that includes an updated display of the graphic user interface to a plurality of different user devices each associated with a different user, wherein application usage data from the plurality of different user device is collected for user in rearranging the arrangement of application elements [(e.g. see Cote paragraphs 0031, 0032, 0042, 0050, 0073, 0122) ”the user device may store interaction data and periodically send it to the layout customization server 201b … the user device 201a will create a usage monitor package containing multiple usage records … user device 301 may transmit a usage monitor package for processing by the layout customization server 302 … obtain in-session and summarized behavioral metrics representing how … a user group (e.g., by community or demographic), and/or a user base (e.g., all users of an application) interacts with pages … a behavior adapter server can generate changing user interfaces for more than one user, such as for a group of users, such as a group of users using a particular software program over the world wide web … If the template identifier specifies that the data is for a base template, e.g., 308, the layout customization server may notify the template layout server of the received usage monitor package, e.g., 307. The template layout server 303 may then update the base layout record or update stored customized layouts. Updating may include modifying the layout template … the baseline values may be used by the template layout server 303 and/or the layout customization server 302 in determining layout modifications and/or layout selections for the user. In one embodiment, the baseline interaction values (or other data processed by LUM) may be aggregated across users in order to enable layout template modifications using demographic or user cohort data. In one example, the aggregated data may be used to determine a default or baseline layout template for a user based on the experience/usage monitor data of users in a similar demographic profile”].
Therefore, considering the teachings of Almecija and Cote, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add publishing the application that includes an updated display of the graphic user interface to a plurality of different user devices each associated with a different user, wherein application usage data from the plurality of different user devices is collected for user in rearranging the arrangement of application elements, as taught by Cote, to the teachings of Almecija because dynamically modifying and customizing the interface layout based on the aggregated behavior of similar users makes the user’s life easier (e.g. see Cote paragraphs 0050, 0052 and Fig. 1).
Almecija and Cote do not specifically teach wherein the application elements are rearranged in accordance with an order and location of a sequence of clicks based on the application usage data from the plurality of different user devices. However, in the same field of invention, Kotler teaches:
wherein the application elements are rearranged in accordance with an order and location of a sequence of clicks based on the application usage data from the plurality of different user devices [(e.g. see Kotler paragraphs 0029, 0036, 0039, 0040 and claims) ”controls may be dynamically positioned by the application in the menu 302 according to use patterns. The application may place high frequency controls close to a convenient location of the menu … A convenient location may be user dependent and may be determined by evaluating user input patterns … the application may determine frequency of a user input on a control in the context based menu. The application may keep count the number of control activations. Additionally, the application may classify activations according to user action such as a tap action or a swipe action. Next, the application may move the control to another location in the context based menu to ease access to the control based on determined frequency matching a threshold. The threshold may be system defined to sort controls according to activation frequency. There may be multiple thresholds corresponding to regions in the menu to enable a control to be eligible for placement within a region of the menu … On the behavior side, customization may include aspects such as when a command is clicked if the menu is to stay up or close, whether a sub-menu is to act as a most recently used type menu (i.e., bubbling up the last command chosen from the sub-menu) … the application may determine frequency of a user input on a control in another context based menu or any other user interface. The application may move the control from the other context based menu into the context based menu according to the determined frequency matching a threshold. The application may move frequently used controls from sub menus into a top level menu … adjust a number of controls to be displayed in the context based menu dynamically according to an interaction pattern with one of the context based menu … This may be accomplished by observing at what multiple users do”].
Therefore, considering the teachings of Almecija, Cote and Kotler, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the application elements are rearranged in accordance with an order and location of a sequence of clicks based on the application usage data from the plurality of different user devices, as taught by Kotler, to the teachings of Almecija and Cote because moving controls based on past user actions allows the controls to be easily accessed by the user at a convenient location (e.g. see Kotler paragraphs 0036, 0039).
As for dependent claim 2, Almecija, Cote and Kotler teach the method as described in claim 1 and Almecija further teaches:
further comprising generating a display of the identified options, wherein the selected options are received via the display of the identified options [(e.g. see Almecija paragraphs 0050, 0055) ”The selection can be made automatically by the user experience determination component 144, by the user directly with no assistance from user experience system 104, by a setting in an options menu or the like, or through a suggestion by user experience determination component 144 that the user reviews and selects the desired UI … the user may always leave such an adaptive UI on so as to have the most efficient user of the software application. In some embodiments, the user can “pin” certain UI elements they like to be static while the rest of the user interface adapts according to the UI adaptive component 148”].
As for dependent claim 4, Almecija, Cote and Kotler teach the method as described in claim 1, but Almecija does not specifically teach wherein collecting the application usage data from the user devices includes polling the user devices for the application usage data. However, Cote teaches:
wherein collecting the application usage data from the user devices includes polling the user devices for the application usage data [(e.g. see Cote paragraphs 0031, 0032, 0042, 0122) ”the user device may store interaction data and periodically send it to the layout customization server 201b … the user device 201a will create a usage monitor package containing multiple usage records … user device 301 may transmit a usage monitor package for processing by the layout customization server 302 … obtain in-session and summarized behavioral metrics representing how … a user group (e.g., by community or demographic), and/or a user base (e.g., all users of an application) interacts with pages”].
The motivation to combine is the same as that used for claim 1.
As for dependent claim 6, Almecija, Cote and Kotler teach the method as described in claim 1 and Almecija further teaches:
wherein the application is executable by one or more of the user devices to record the application usage data [(e.g. see Almecija paragraphs 0042, 0058) ”through input tracking component 140 in an embodiment, records the user action. This input is tracked by input tracking component 140. Input tracking component 140 adds the action to a buffer, database, or vector of current and previous user actions in the current session … Each user has a profile that is dynamically created. This profile includes their user interface actions, history, and preferences, as well as other information about them that may affect how a UI is adapted. These can be stored, and retrieved from, user UI profile store 146”].
As for dependent claim 7, Almecija, Cote and Kotler teach the method as described in claim 1 and Almecija further teaches:
wherein the application usage data includes one or more measurements associated with each of the application elements in the graphic user interface [(e.g. see Almecija paragraphs 0052, 0086, 0087) ”The system registers buttons clicked, screens interacted (mouse or touch interactions with the screens in an embodiment) … The system has registered how many times the user has used certain help menus and for what types of issues, what tasks (series of actions) that user has performed, and past user outputted user interfaces have been presented to that user … a user has clicked buttons in the UI over a threshold amount”].
As for dependent claim 8, Almecija, Cote and Kotler teach the method as described in claim 7 and Almecija further teaches:
further comprising: averaging a set of measurements associated with an identified one of the application elements based on the measurements received from the user devices [(e.g. see Almecija paragraph 0052) ”if a user uses the help menus more than an average amount, the user may be grouped into the “beginner” group and/or the “higher desire to learn” group”].
comparing the measurement average associated with the identified application element to a threshold [(e.g. see Almecija paragraph 0052) ”if a user has logged in to this software application less than ten times, they may be grouped into the “beginner” group. But if that same user has logged into a software application in a software application suite that has a similar UI as the currently used software over 100 times, they may not be grouped in the “beginner group” and may be put into another group such as “advanced UI multi-app” (as shown more in FIG. 7). Another example is that if a user has clicked buttons in the UI over a threshold amount, they are no longer a beginner user”].
generating an alert based on the comparison, wherein the alert includes one or more links based on the identified application element associated with the measurement average [(e.g. see Almecija paragraphs 0064-0066, 0092) ”UI output component 150, depending on the circumstances, can provide UI hinting. User interface hinting is the dynamic providing of hints to help the user navigate or otherwise use the UI. Such hints can be tailored to the user based on user experience level as well as various aspects of their user profile … UI hinting of buttons to show the user where the buttons are located that are the most likely buttons the user may look for next … UI hinting in the form of a box providing a textual hint to the user, providing helpful information on how the user may choose to use the software … For an example, if the user experience level is low and user speed is needed, the user experience system may output hints in the form of arrows to exactly the buttons or steps needed to complete the task”].
As for dependent claim 9, Almecija, Cote and Kotler teach the method as described in claim 1 and Almecija further teaches:
further comprising identifying that the application usage data includes an order and set of locations associated with selections made within the graphic user interface, and wherein updating the display of the graphic user interface in real-time further includes rearranging the arrangement of application elements within the graphic user interface based on the identified order and set of locations [(e.g. see Almecija paragraphs 0033, 0034, 0043, 0068, 0069) ”These adaptive user interfaces do not just affect a single user interface experience or screen. The whole software application workflow of completing a task that may require many steps/screens/buttons can be improved by adapting the workflow and user interface throughout the workflow. The user's workflow and user interfaces can be adapted dynamically and automatically … Additional examples of an adaptive UI in various embodiments are moving less-used interface elements out of the way, automating frequently used combinations into single clicks … it learns and develops an understanding of overall usage of the UI to group certain patterns and usages with similar patterns and usages. This is discussed further in relation to FIG. 5 and FIG. 7, among other places within. The user experience learning component 142 can automatically determine changes and patterns in the user's UI behavior and needs. For example, a user may have a similar way of working most sessions, but one session clicking buttons fast and furiously (i.e. shorter intervals between button clicks and faster mouse travel). Thus, the system can learn to group the user into a “speed needed” or “urgent” grouping that may dynamically update the user interface to show only the one anticipated next action or even automate some actions that would normally be clicks by the user in order to save time … Certain users may perform the same task 100 times a day (such as a medical workflow for retrieving and enhancing a patient image). The system can, based on the training base developed in 222, know that the particular user may not need to click multiple buttons to get to the end of their task and may automatically automate such tasks … Top toolbar has now been adapted to show the most likely buttons that the system has predicted in step 210 based on the user selection on user interface 1200. Thus, the system dynamically shortcuts to the most likely buttons the user may need”].
As for dependent claim 10, Almecija, Cote and Kotler teach the method as described in claim 9 and Almecija further teaches:
wherein rearranging the arrangement of application elements within the graphic user interface is further based on a frequency of the identified order and set of locations associated with the user devices [(e.g. see Almecija paragraphs 0033, 0034, 0043, 0068, 0069) ”These adaptive user interfaces do not just affect a single user interface experience or screen. The whole software application workflow of completing a task that may require many steps/screens/buttons can be improved by adapting the workflow and user interface throughout the workflow. The user's workflow and user interfaces can be adapted dynamically and automatically … Additional examples of an adaptive UI in various embodiments are moving less-used interface elements out of the way, automating frequently used combinations into single clicks … it learns and develops an understanding of overall usage of the UI to group certain patterns and usages with similar patterns and usages. This is discussed further in relation to FIG. 5 and FIG. 7, among other places within. The user experience learning component 142 can automatically determine changes and patterns in the user's UI behavior and needs. For example, a user may have a similar way of working most sessions, but one session clicking buttons fast and furiously (i.e. shorter intervals between button clicks and faster mouse travel). Thus, the system can learn to group the user into a “speed needed” or “urgent” grouping that may dynamically update the user interface to show only the one anticipated next action or even automate some actions that would normally be clicks by the user in order to save time … Certain users may perform the same task 100 times a day (such as a medical workflow for retrieving and enhancing a patient image). The system can, based on the training base developed in 222, know that the particular user may not need to click multiple buttons to get to the end of their task and may automatically automate such tasks … Top toolbar has now been adapted to show the most likely buttons that the system has predicted in step 210 based on the user selection on user interface 1200. Thus, the system dynamically shortcuts to the most likely buttons the user may need”].
As for independent claim 11, Almecija, Cote and Kotler teach a system. Claim 11 discloses substantially the same limitations as claim 1. Therefore, it is rejected with the same rational as claim 1.
As for dependent claim 12, Almecija, Cote and Kotler teach the system as described in claim 11; further, claim 12 discloses substantially the same limitations as claim 2. Therefore, it is rejected with the same rational as claim 2.
As for dependent claim 14, Almecija, Cote and Kotler teach the system as described in claim 11; further, claim 14 discloses substantially the same limitations as claim 4. Therefore, it is rejected with the same rational as claim 4.
As for dependent claim 16, Almecija, Cote and Kotler teach the system as described in claim 11; further, claim 16 discloses substantially the same limitations as claim 6. Therefore, it is rejected with the same rational as claim 6.
As for dependent claim 17, Almecija, Cote and Kotler teach the system as described in claim 11; further, claim 17 discloses substantially the same limitations as claim 7. Therefore, it is rejected with the same rational as claim 7.
As for dependent claim 18, Almecija, Cote and Kotler teach the system as described in claim 17; further, claim 18 discloses substantially the same limitations as claim 8. Therefore, it is rejected with the same rational as claim 8.
As for dependent claim 19, Almecija, Cote and Kotler teach the system as described in claim 11; further, claim 19 discloses substantially the same limitations as claim 9. Therefore, it is rejected with the same rational as claim 9.
As for dependent claim 20, Almecija, Cote and Kotler teach the system as described in claim 19; further, claim 20 discloses substantially the same limitations as claim 10. Therefore, it is rejected with the same rational as claim 10.
As for independent claim 21, Almecija, Cote and Kotler teach a non-transitory computer-readable storage medium. Claim 21 discloses substantially the same limitations as claim 1. Therefore, it is rejected with the same rational as claim 1.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Almecija et al. (US 2018/0365025 A1) in view of Cote (US 2013/0212487 A1) and further in view of Kotler et al. (US 2013/0019203 A1), as applied to claim 4 above, and further in view of Raghav et al. (US 2017/0118261 A1).
As for dependent claim 5, Almecija, Cote and Kotler teach the method as described in claim 4, but do not specifically teach further comprising continuing to poll the user devices until a sample size corresponding to the plurality of user devices meets a predetermined sample size threshold. However, in the same field of invention, Raghav teaches:
further comprising continuing to poll the user devices until a sample size corresponding to the plurality of user devices meets a predetermined sample size threshold [(e.g. see Raghav paragraphs 0021, 0061) ”Once this interaction pattern has been observed over a threshold number of users … The crowd-sourced information can be threshold-based where thresholds have been set for a defined number of users. For example, if less than 10 users have provided crowd-sourced information, then it may be considered that no relevant crowd-sourced information exists. On the other hand, if more than 10 users have provided crowd-sourced information, then it may be considered that relevant crowd-sourced information exists”].
Therefore, considering the teachings of Almecija, Cote, Kotler and Raghav, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add continuing to poll the user devices until a sample size corresponding to the plurality of user devices meets a predetermined sample size threshold, as taught by Raghav, to the teachings of Almecija, Cote and Kotler because employing crowd-sourced thresholds helps to ensure that meaningful information is collected (e.g. see Raghav paragraph 0061).
As for dependent claim 15, Almecija, Cote and Kotler teach the system as described in claim 14; further, claim 15 discloses substantially the same limitations as claim 5. Therefore, it is rejected with the same rational as claim 5.
Response to Arguments
Applicant's arguments, filed 08 January 2026, have been fully considered but they are not persuasive.
Applicant argues that [“the cited references therefore – individually or in any combination – fail to teach all the elements of the [amended] independent claim.” (Page 9).].
The argument described above, in paragraph number 7, with respect to the newly added limitations to the independent claims has been considered, but is moot in view of the new grounds of rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. PGPub 2014/0040819 A1 issued to Duffy on 06 February 2014. The subject matter disclosed therein is pertinent to that of claims 1, 2, 4-12 and 14-21 (e.g. modifying a window layout based on user input sequencing).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER J FIBBI whose telephone number is (571)-270-3358. The examiner can normally be reached Monday - Thursday (8am-6pm).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, William Bashore can be reached at (571)-272-4088. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHRISTOPHER J FIBBI/Primary Examiner, Art Unit 2174