Prosecution Insights
Last updated: October 02, 2026
Application No. 18/947,088

GRADUAL FEATURE DISCLOSURE TO FAMILIARIZE USER WITH SYSTEM

Non-Final OA §101§103
Filed
Nov 14, 2024
Priority
Nov 28, 2023 — provisional 63/603,183 +1 more
Examiner
NGUYEN, DUY KHUONG THANH
Art Unit
Tech Center
Assignee
Koninklijke Philips N.V.
OA Round
1 (Non-Final)
82%
Grant Probability
Favorable
1-2
OA Rounds
10m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 82% — above average
82%
Career Allowance Rate
467 granted / 570 resolved
+21.9% vs TC avg
Strong +34% interview lift
Without
With
+34.0%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
17 currently pending
Career history
595
Total Applications
across all art units

Statute-Specific Performance

§101
12.7%
-27.3% vs TC avg
§103
66.1%
+26.1% vs TC avg
§102
7.0%
-33.0% vs TC avg
§112
6.1%
-33.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 570 resolved cases

Office Action

§101 §103
otice of Pre-AIA or AIA Status 1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 2. This is the initial office action based on the application filed on November 14, 2024, which claims 1-20 are presented for examination. Status of Claims 3. Claims 1-20 are pending, of which claims, of which claim 1, 14 and 20 are in independent form. Priority 4. This application has a priority PRO 63/603,183 11/28/2023. This application has a priority EP 23217095.1 12/15/2023. Information Disclosure Statement 5. Information disclosure statement filed on11/14/2024 has been reviewed and considered by Examiner. The Office's Note: 6. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. 7. Claims 14-19 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claims 14-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claims 14 recites “receiving an update for a UI, wherein features of the update are grouped into a plurality of chunks; assigning chunks of the plurality of chunks an active or hidden state; and presenting the UI including the features of the chunks assigned the active state and not including the features of the chunks assigned the hidden state.” as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the function through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1. Under Prong 2, this judicial exception is not integrated into a practical application. The additional elements ““memory”, and “processor” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components, and “presenting the UI including the features of the chunks assigned the active state and not including the features of the chunks assigned the hidden state” do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering, displaying, updating, transmitting and storing data/information. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05(g). Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of ““memory,” and “processor” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components, and “presenting the UI including the features of the chunks assigned the active state and not including the features of the chunks assigned the hidden state”, the courts have identified merely gathering, displaying, updating, transmitting and storing data/information on a display is well-understood, routine and conventional activity. See MPEP 2106.05(d). The recitation of generic computer instruction and computer components to apply the judicial exception, and merely displaying data do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101. In conclusion, claims 14-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim Rejections - 35 USC § 103 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. 8. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kuhn (“PROGRESSIVE DISCLOSURE USING AN INDICATIONS-BASED USER INTERFACE”– hereinafter Kuhn) and further in view of Morrow(US 20180341378 – hereinafter Morrow – IDS of records). Claim 1 rejected, Kuhn teaches a medical device (Kuhn, p. 1, para. 1: "patient monitoring system"; see also p. 5, last paragraph: "advanced patient management systems”), comprising: a display (Kuhn, p. 1, para. 1: "user interface of a device programmer or patient monitoring system";" therapeutic features and associated parameters are displayed at the user interface", the display on the user interface implying the presence of a display); an input interface via which patient data is received (Kuhn, part see p. 2, last paragraph: "entering the indications on an indications based programming screen of the UI", which implies an input interface); and an electronic processor implementing a user interface (UI) in which a representation of the patient data is presented on the display (Kuhn, p. 2, para. 1 : ''UI only displays features or parameters that might be useful for a patient with the selected indications'); The medical device of Kuhn is executing a software that implements the 'patient monitoring system' or 'patient management system' described in Kuhn. This requires that a version of the software, i.e. a software update, is deployed in the medical device. The deployment implies that the device processor executes code which, when running on the processor, performs the functionality described in Kuhn, which involves showing/ hiding certain groups of features to the user, as shown e.g. in p. 3, para. 1 and 2. This means that the electronic processor further programmed to perform an update of the medical device including: receiving an update for the medical device, the update comprising executable code for adding a plurality of features that modify the UI, the features being grouped into chunks (Kuhn, p. 2, para. 1: "Indications are selected based on patient risk or pathologies and are associated with certain features or groups of features for display at the UI. The UI only displays features or parameters that might be useful for a patient with the selected indications. As patient conditions change, warranting additional indications or a change in indications, the UI display progressively changes"; the groups of features being the chunks, these chunks being associated to different indications, see examples in p. 3, para. 1 and 2, concerning e.g. "1) "Primary prevention" which would allow observation and control of single V-tachy rate zone and fixed ATP/ shock therapy. 2) "Secondary prevention" which would allow observation and control of multiple V-tachy rate zones and customizable anti-tachyarrhythmia pacing (ATP) and shock therapy”); generating a data structure in which the plurality of chunks are assigned an active or hidden state (Kuhn, the statement in p. 2, last paragraph: "Each potential patient indication is mapped 110 to a subset of features used for display on a user interface (UI)" necessarily implies a data structure containing the mapping for a given user of which features are hidden and which are shown, as in the cited examples of p. 3, para. 1 and 2); progressively implementing the update of the medical device by: presenting the UI modified by the features of the chunks assigned the active state and not modified by the features of the chunks assigned the hidden state (Kuhn, p. 3, para. 1 and 2: ''Additionally, progressive disclosure provides flexibility, for example, if historical and/or co-morbidity indications are selected, thus invoking previously hidden features that become visible and available. Examples of indication-based progressive disclosure include: 1) "Primary prevention" which would allow observation and control of single V-tachy rate zone and fixed ATP/shock therapy. 2) "Secondary prevention" which would allow observation and control of multiple V-tachy rate zones and customizable anti-tachyarrhythmia pacing (ATP) and shock therapy”); and updating the data structure in response to an update trigger to reassign a triggered chunk of the plurality of chunks from the hidden state to the active state, whereby after the updating of the medical device the UI is presented modified by the features of the triggered chunk (Kuhn, as shown e.g. in p. 3, para. 2: "(Automatic transition from primary to secondary prevention indications could occur when the CRM device detects a ventricular arrhythmia.) 3) An ''Atrial arrhythmia" indication would allow observation and control of atrial therapy features such as atrial pacing reference, ventricular rate regulation, and atrial tachyarrhythmia detection features. 4) A "No atrial arrhythmia" indication would hide atrial therapy features. 5) A "Ventricular fibrillation only" indication would hide zone settings and detection enhancements. 6) A "Paroxysmal atrial arrhythmias and ventricular tachyarrhythmia" indication would show an atrial therapy suite. multi-zone ventricular tachy detection. detection enhancements. and atrial or ventricular ATP therapy"; such updates necessarily require an update of the underlying data structure supporting the information for that user). The Office would like to use prior art Morrow to back up Kuhn to further to teach limitation receiving update of the medical device (Morrow, US 20180341378, para [0160-0162], Medical treatment. As a user develops a greater understanding of underlying concepts, health, and/or treatment risks, the user is provided with additional information and medical treatment advice. For example, in one embodiment a prescription for medication is able to be obtained once a user has demonstrated by way of interaction with the online environment that they have adequate competencies in relevant topics to be trusted to use the medication in an educated and sensible fashion. [0163-0167] Equipment maintenance. A user is provided with information that assists in performing more complex maintenance tasks only where they have demonstrated competency (for example through interaction with content) in respect of simpler underlying tasks of which prior competency is recommended. para [0168], Block 206 represents a process including a trigger to generate further user interface content. This may be content that is added to an existing page object (for example a further content segment), or content that replaces that which is shown in an existing page object. In response to that trigger, the method loops to block 202. Para [0186 and 0200].), the update comprising executable code for adding a plurality of features that modify the UI (Morrow, para [0079-0080], In the context of the user activity rules engine, a user interface management interface enables an administrator user to define user activity rules by specifying a form of interaction (for example visiting a particular page, interacting with an object, and so on), and an objective measurement for that interaction (for example duration of interaction, characteristics of inputs, and so on). The user interface management interface additionally enables the administrator user to define a protocol configured to update interaction-derived values in response to identification of a given or designated one of the predefined interactions of specified form and measure. These rules are stored in computer memory in a form that allows their execution by a user activity rules engine. The user activity engine operable to implement the defined user activity rules, thereby to (i) identify predefined of the interactions between a given or designated user and the user interface; and (ii) in response to identification of a given one of the predefined interactions between the user and the user interface, update interaction-derived values associated with the user based on at least one of the user activity rules associated with that given of the predefined interactions. Para [081]. Para [0162], Medical treatment. As a user develops a greater understanding of underlying concepts, health, and/or treatment risks, the user is provided with additional information and medical treatment advice. For example, in one embodiment a prescription for medication is able to be obtained once a user has demonstrated by way of interaction with the online environment that they have adequate competencies in relevant topics to be trusted to use the medication in an educated and sensible fashion. [0163] Equipment maintenance. A user is provided with information that assists in performing more complex maintenance tasks only where they have demonstrated competency (for example through interaction with content) in respect of simpler underlying tasks of which prior competency is recommended. Para [0186 and 0200].). It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Morrow into Kuhn to define interface customization rules. The user is monitored over time and a rules engine is configured to dynamically cause modification of the way in which user interface pages are to be displayed to that user. The user interface management interface allows an administrator user to define user activity rules by specifying a form of interaction as suggested by Morrow (See abstract and summary). Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Kuhn and Morrow teach the medical device of claim 1, wherein one of: the medical device is a patient monitor, and the patient data comprise patient vital sign data received via the input interface comprising a vital sign sensor interface, the medical device is a mechanical ventilator, and the patient data comprise patient respiratory data received via the input interface comprising a respiratory sensor interface, the medical device is a medical imaging device, and the patient data comprise patient medical images acquired by the input interface comprising imaging data acquisition hardware, the medical device is a patient doctor management system, and the patient data comprise patient data retrieved from an electronic medical record or the medical device is a medical records workstation, and the patient data comprise patient medical record data received via the input interface comprising a hospital information technology (IT) network (Kuhn, p. 1, para. 1: "patient monitoring system", “cardiac rhythm management (CRM) device; see also p. 5, last paragraph: "advanced patient management systems”. Morrow, para [0079-0082]. Para [0162], Medical treatment. As a user develops a greater understanding of underlying concepts, health, and/or treatment risks, the user is provided with additional information and medical treatment advice. For example, in one embodiment a prescription for medication is able to be obtained once a user has demonstrated by way of interaction with the online environment that they have adequate competencies in relevant topics to be trusted to use the medication in an educated and sensible fashion. [0163] Equipment maintenance. A user is provided with information that assists in performing more complex maintenance tasks only where they have demonstrated competency (for example through interaction with content) in respect of simpler underlying tasks of which prior competency is recommended. Para [0186 and 0200].). Claim 3 is rejected for the reasons set forth hereinabove for claim 1, Kuhn and Morrow teach the medical device of claim 1, wherein the progressive implementing the update of the medical device further includes: updating the data structure in response to an update trigger to reassign a triggered chunk of the plurality of chunks from the hidden state to the active state, whereby after the updating the UI is presented including the features of the triggered chunk (Kuhn, as shown e.g. in p. 3, para. 2: "(Automatic transition from primary to secondary prevention indications could occur when the CRM device detects a ventricular arrhythmia.) 3) An ''Atrial arrhythmia" indication would allow observation and control of atrial therapy features such as atrial pacing reference, ventricular rate regulation, and atrial tachyarrhythmia detection features. “, implying that an update is triggered which presents newly relevant content which is supported by the relevant data structure. Morrow, para [0168], Block 206 represents a process including a trigger to generate further user interface content. This may be content that is added to an existing page object (for example a further content segment), or content that replaces that which is shown in an existing page object. In response to that trigger, the method loops to block 202.).). Claim 4 is rejected for the reasons set forth hereinabove for claim 3, Kuhn and Morrow teach the medical device of claim 3, wherein the progressive implementing the update of the medical device further includes (Morrow, para [0079-0081] and [01060-0168]): analyzing usage of the presented UI by a user (Morrow, fig. 2 and para [0167], Block 204 represents a process including monitoring user interaction with rendered content, for example time spent viewing a given or designated content segment, interactions with GUI objects, and so on. This is used at a process represented by block 205, which includes updating competency scores (and optionally other values) based on user analysis rules.); and wherein the update trigger is generated by the analyzing of the usage of the presented UI by the user (Morrow, para [0168], Block 206 represents a process including a trigger to generate further user interface content. This may be content that is added to an existing page object (for example a further content segment), or content that replaces that which is shown in an existing page object. In response to that trigger, the method loops to block 202.)). Claim 5 is rejected for the reasons set forth hereinabove for claim 4, Kuhn and Morrow teach the medical device of claim 4, wherein the progressive implementing the update of the medical device further includes(Morrow, para [0079-0081] and [01060-0168]): based on the analysis of the usage of the presented UI by the user, determining a criticality of a chunk to the usage of the presented UI by the user (Morrow, para [0140-0146], ] FIG. 4A illustrates a table showing scores available in relation to a plurality of content segments (Content Segment 1 to Content Segment 4) for a set of competencies (Competency A to Competency G). For each content segment and each competency, there is an available score associated with: non-completion; low-effectiveness completion; and high effectiveness completion. Definitions as to predefined interactions leading to each level of completion are defined, for example by reference to time spent, call-to-action response, and so on.; wherein the update trigger comprises the determined criticality satisfying a criticality trigger criterion (Morrow, para [0160-0168, Block 206 represents a process including a trigger to generate further user interface content. This may be content that is added to an existing page object (for example a further content segment), or content that replaces that which is shown in an existing page object. In response to that trigger, the method loops to block 202. Para [0169]. Para [0178-0180].). Claim 6 is rejected for the reasons set forth hereinabove for claim 4, Kuhn and Morrow teach the medical device of claim 4, wherein the progressive implementing the update of the medical device further includes: removing the features of a chunk by reassigning the chunk from the active state to the hidden state in response to the analysis indicating usage of the chunk underruns a predetermined usage threshold (Morrow, fig. 2 and para [0167], Block 204 represents a process including monitoring user interaction with rendered content, for example time spent viewing a given or designated content segment, interactions with GUI objects, and so on. This is used at a process represented by block 205, which includes updating competency scores (and optionally other values) based on user analysis rule. Para [0170], It will be appreciated that the use of a user analysis rules engine in combination with an interface customization rules engine as described above enables powerful dynamic customization in terms of user interface and user experience, for example based on determination of a user's increasing competencies in various skills and topics that re developed within the user interface itself. This allows a user interface to in essence grow with a user; it may begin by providing relatively basic content and functionality, and incrementally grow in line with the user's own progression cycle. In this manner a single user interface may be both simple and substantially infinitely complex, with the level of complexity presented to a particular user being tailored in real time to that particular user's perceived readiness for such complexity. This is especially useful in terms of delivering educational material, and, as described below, ensuring that a user has threshold levels of competency to receive certain information and/or advice. Kuhn, page 2, last paragraph and fig. 1, According to the method for progressive disclosure, features are hidden 140 and unavailable unless at least one indication suggests their use.) Claim 7 is rejected for the reasons set forth hereinabove for claim 5, Kuhn and Morrow teach the medical device of claim 5, wherein determining a criticality of a chunk to the usage of the presented UI by the user includes: analyzing at least one of a type of clinical cases performed and clinical cases scheduled with a feature list usage rate (Kuhn, as shown e.g. in p. 3, para. 2: "(Automatic transition from primary to secondary prevention indications could occur when the CRM device detects a ventricular arrhythmia.) 3) An ''Atrial arrhythmia" indication would allow observation and control of atrial therapy features such as atrial pacing reference, ventricular rate regulation, and atrial tachyarrhythmia detection features. 4) A "No atrial arrhythmia" indication would hide atrial therapy features. 5) A "Ventricular fibrillation only" indication would hide zone settings and detection enhancements. 6) A "Paroxysmal atrial arrhythmias and ventricular tachyarrhythmia" indication would show an atrial therapy suite. multi-zone ventricular tachy detection. detection enhancements. and atrial or ventricular ATP therapy"; such updates necessarily require an update of the underlying data structure supporting the information for that user. Morrow, para [0180-0182], monitoring user interface usage, background audio or activity, a determination may be made as to whether a user is acting seriously and conscientiously, or alternately the user is “mucking about”) Claim 8 is rejected for the reasons set forth hereinabove for claim 5, Kuhn and Morrow teach the medical device of claim 5, wherein the analysis of the usage of the presented UI by a user includes: tracking a gaze of the user interacting with the UI(Morrow, para [0097], ] Interactions observed via video and/or other forms of direct user monitoring. An example is monitoring via eye tracking or the like, to better assess whether a user is effectively reading written content. In one embodiment the framework is configured to rate/distinguish interactions based on observed eye movements. ). Claim 9 is rejected for the reasons set forth hereinabove for claim 1, Kuhn and Morrow teach the medical device of claim 1, wherein the analysis of the usage of the presented UI by a user includes: determining a rate of consumption of the usage of the presented UI by the user (Morrow, para [0146], User segmentation data. Based on monitoring of user interface interactions, known/inferred attributes and/or other inputs, users may be associated with particular predefined “segments”. Segments are optionally used to objectively categorize users based on observations for example by reference to factors such as: level of engagement with the user interface; attitude towards a particular issue (such as money or health); media consumption preferences; attention span; and so on. It will be appreciated that segments and rules configured to associate a user to segments may be defined on an ongoing basis to better tailor rule generation for the first and interface customization rule engines. [0147] Segment/cohort profile norms. In this regard, some data may be inferred based on the segmentation, for example rules that enable automated implementation of an observation such as “users like this tend to have X, Y and/or Z”. [0148] Interactions such as those identified in as exemplary activities further above. [0149] Data values inputted by a user via user interface objects (such as toggles, sliders, menus, input fields, end so on Fig. 2 and para [0166-0167], Block 204 represents a process including monitoring user interaction with rendered content, for example time spent viewing a given or designated content segment, interactions with GUI objects, and so on. This is used at a process represented by block 205, which includes updating competency scores (and optionally other values) based on user analysis rules.). Claim 10 is rejected for the reasons set forth hereinabove for claim 3, Kuhn and Morrow teach the medical device of claim 3, wherein generating the update trigger comprises a predetermined dependency of the triggered chunk on another chunk that is reassigned from the hidden state to the active state (Morrow, para [0150], One functionality of the interface customization rules engine is enabling relevant content prediction. As context, there are multiple situations where a user's actions in a user interface trigger the selection of new content for rendering. For example, this occurs where a user completes a section of rendered content, navigates to a new page, and so on. One or more rules implemented by the interface customization rules engine may result in selection of that new user interface content. For example, this enables prediction of a next relevant piece of content upon a user's completion (or navigation away from) a current piece of content. Such rules are optionally defined by a trigger event (for example “WHEN user completes Content Piece A”), one or more conditions (for example “IF user has competency score A greater than value B AND IF user has age value of greater than value C) and an outcome (for example “RENDER content segment X and content item Y using presentation schema Z” or “NAVIGATE to page 1234”).). Claim 11 is rejected for the reasons set forth hereinabove for claim 1, Kuhn and Morrow teach the medical device of claim 1, wherein the data structure assigns the chunks to the hidden or active states on a per user or per user group basis, and the method further includes (Kuhn, the statement in p. 2, last paragraph. Morrow, para [0079-0081] and [01060-0168]): identifying a user or user group of the UI (Morrow, fig. 2 and para [0166], Block 201 represents a process including identifying a user of a user interface environment, for example via a manual login for automated means (such as use of cookies). This provides a trigger to determine initial content for display via the user interface, for example in terms of user interface objects and one or more content segments.); and presenting the UI including the chunks assigned the active state for the identified user or user group and not including the chunks assigned the hidden state for the identified user or user group (Morrow, fig. 2 and para [0166], This is achieved at block 202 based on operation of the interface customization rules, which determine content and/or user interface functionality that is to be provided based on data maintained for that user, which includes data derived from analysis of previous interactions with the user interface environment. Based on that determination, block 203 includes generating user interface content for rendering at the client device.) Claim 12 is rejected for the reasons set forth hereinabove for claim 1, Kuhn and Morrow teach the medical device of claim 1, wherein the features of the plurality of chunks include one or more features in which the UI presents additional information, one or more features in which the UI changes a presentation format of information, one or more machine-learning processes, and/or one or more features in which the UI provides user input for modifying operation of the UI (Kuhn, p. 4, para. 2: "the customizable display may allow for a manual over-ride of indications-based hiding"). Claim 13 is rejected for the reasons set forth hereinabove for claim 1, Kuhn and Morrow teach the medical device of claim 1, wherein the data structure is configured to (Kuhn, the statement in p. 2, last paragraph): analyze a plurality of users based on different medical systems that each user interacts with (Kuhn, page 2, second and third paragraph, The progressive disclosure view of the UI may be dynamically configurable. The items or features displayed on the UI may depend on clinician-selected patient indications, on CRM device-detected clinical events, and/or a UI customization profile. In this way, the clinician’s view of the UI is simplified, until such time as patient pathology requires further observation and/or control of the CRM device, as identified by the clinician, or alternatively as automatically identified by the device. The flexibility of the UI allows for a more complex display, even if the device was initially intended as a prevention only device or was set with an at risk indication. Flexibility of the UI display allows for control of additional monitoring and/or therapy delivery without ease-of-use constraints even if prevention was the original intention for the implant.); and determine, based on the analysis, the features of the chunks assigned the active state, and the features of the chunks assigned the hidden state (Kuhn, page 2, third paragraph, Figure 1 illustrates a flowchart of a method for indications-based progressive disclosure. Each potential patient indication is mapped 110 to a subset of features used for display on a user interface (UI). Patient indications for a particular patient are identified 120 by a clinician, for example, by entering the indications on an indications based programming screen of the UI. The subset of features mapped to that patient indication are displayed 130 on the UI and are available for interaction. According to the method for progressive disclosure, features are hidden 140 and unavailable unless at least one indication suggests their use.). Claim 14 rejected, Kuhn teaches a non-transitory computer readable medium storing instructions readable and executable by an electronic processor to perform a user interface (UI) updating method for a medical device, the UI updating method comprising (Kuhn, p. 1, para. 1: "patient monitoring system"; see also p. 5, last paragraph: "advanced patient management systems”): receiving an update for a UI, wherein features of the update are grouped into a plurality of chunks ((Kuhn, p. 2, para. 1: "Indications are selected based on patient risk or pathologies and are associated with certain features or groups of features for display at the UI. The UI only displays features or parameters that might be useful for a patient with the selected indications. As patient conditions change, warranting additional indications or a change in indications, the UI display progressively changes"; the groups of features being the chunks, these chunks being associated to different indications, see examples in p. 3, para. 1 and 2, concerning e.g. "1) "Primary prevention" which would allow observation and control of single V-tachy rate zone and fixed ATP/ shock therapy. 2) "Secondary prevention" which would allow observation and control of multiple V-tachy rate zones and customizable anti-tachyarrhythmia pacing (ATP) and shock therapy'. The medical device of Kuhn is executing a software that implements the 'patient monitoring system' or 'patient management system' described in Kuhn,. This requires that a version of the software, i.e. a software update, is deployed in the medical device. The deployment implies that the device processor executes code which, when running on the processor, performs the functionality described in Kuhn, which involves showing/ hiding certain groups of features to the user, as shown e.g. in p. 3, para. 1 and 2); assigning chunks of the plurality of chunks an active or hidden state(Kuhn, the statement in p. 2, last paragraph: "Each potential patient indication is mapped 110 to a subset of features used for display on a user interface (UI)" necessarily implies a data structure containing the mapping for a given user of which features are hidden and which are shown, as in the cited examples of p. 3, para. 1 and 2); and presenting the UI including the features of the chunks assigned the active state and not including the features of the chunks assigned the hidden state (Kuhn, p. 3, para. 1 and 2: ''Additionally, progressive disclosure provides flexibility, for example, if historical and/or co-morbidity indications are selected, thus invoking previously hidden features that become visible and available. Examples of indication-based progressive disclosure include: 1) "Primary prevention" which would allow observation and control of single V-tachy rate zone and fixed ATP/shock therapy. 2) "Secondary prevention" which would allow observation and control of multiple V-tachy rate zones and customizable anti-tachyarrhythmia pacing (ATP) and shock therapy'). The Office would like to use prior art Morrow to back up Kuhn to further teach limitation receiving an update for a UI (Morrow, para [0160-0168], Block 206 represents a process including a trigger to generate further user interface content. This may be content that is added to an existing page object (for example a further content segment), or content that replaces that which is shown in an existing page object. In response to that trigger, the method loops to block 202.). It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Morrow into Kuhn to define interface customization rules. The user is monitored over time and a rules engine is configured to dynamically cause modification of the way in which user interface pages are to be displayed to that user. The user interface management interface allows an administrator user to define user activity rules by specifying a form of interaction as suggested by Morrow (See abstract and summary). Claim 15 is rejected for the reasons set forth hereinabove for claim 14, Kuhn and Morrow teach the non-transitory computer readable medium of claim 14, wherein the UI updating method further includes: updating assignments of the chunks in response to an update trigger to reassign a triggered chunk of the plurality of chunks from the hidden state to the active state, whereby after the updating the UI is presented including the features of the triggered chunk (Kuhn, as shown e.g. in p. 3, para. 2: "(Automatic transition from primary to secondary prevention indications could occur when the CRM device detects a ventricular arrhythmia.) 3) An ''Atrial arrhythmia" indication would allow observation and control of atrial therapy features such as atrial pacing reference, ventricular rate regulation, and atrial tachyarrhythmia detection features. “, Morrow, para [0168], Block 206 represents a process including a trigger to generate further user interface content. This may be content that is added to an existing page object (for example a further content segment), or content that replaces that which is shown in an existing page object. In response to that trigger, the method loops to block 202.).). Claim 16 is rejected for the reasons set forth hereinabove for claim 15, Kuhn and Morrow teach the non-transitory computer readable medium of claim 15, wherein the UI updating method further includes (Morrow, para [0079-0081] and [01060-0168]): analyzing usage of the presented UI by a user (Morrow, fig. 2 and para [0167], Block 204 represents a process including monitoring user interaction with rendered content, for example time spent viewing a given or designated content segment, interactions with GUI objects, and so on. This is used at a process represented by block 205, which includes updating competency scores (and optionally other values) based on user analysis rules.); and wherein the update trigger is generated by the analyzing of the usage of the presented UI by the user (Morrow, para [0168], Block 206 represents a process including a trigger to generate further user interface content. This may be content that is added to an existing page object (for example a further content segment), or content that replaces that which is shown in an existing page object. In response to that trigger, the method loops to block 202.)). Claim 17 is rejected for the reasons set forth hereinabove for claim 16, Kuhn and Morrow teach the non-transitory computer readable medium of claim 16, wherein the UI updating method further includes (Morrow, para [0079-0081] and [01060-0168]): based on the analysis of the usage of the presented UI by the user, determining a criticality of a chunk to the usage of the presented UI by the user(Morrow, para [0140-0146], ] FIG. 4A illustrates a table showing scores available in relation to a plurality of content segments (Content Segment 1 to Content Segment 4) for a set of competencies (Competency A to Competency G). For each content segment and each competency, there is an available score associated with: non-completion; low-effectiveness completion; and high effectiveness completion. Definitions as to predefined interactions leading to each level of completion are defined, for example by reference to time spent, call-to-action response, and so on.); wherein the update trigger comprises the determined criticality satisfying a criticality trigger criterion (Morrow, para [0160-0168, Block 206 represents a process including a trigger to generate further user interface content. This may be content that is added to an existing page object (for example a further content segment), or content that replaces that which is shown in an existing page object. In response to that trigger, the method loops to block 202. Para [0169]. Para [0178-0180].). Claim 18 is rejected for the reasons set forth hereinabove for claim 16, Kuhn and Morrow teach the non-transitory computer readable medium of claim 16, wherein the UI updating method further includes: removing the features of a chunk by reassigning the chunk from the active state to the hidden state in response to the analysis indicating usage of the chunk underruns a predetermined usage threshold (Morrow, fig. 2 and para [0167], Block 204 represents a process including monitoring user interaction with rendered content, for example time spent viewing a given or designated content segment, interactions with GUI objects, and so on. This is used at a process represented by block 205, which includes updating competency scores (and optionally other values) based on user analysis rule. Para [0170], It will be appreciated that the use of a user analysis rules engine in combination with an interface customization rules engine as described above enables powerful dynamic customization in terms of user interface and user experience, for example based on determination of a user's increasing competencies in various skills and topics that re developed within the user interface itself. This allows a user interface to in essence grow with a user; it may begin by providing relatively basic content and functionality, and incrementally grow in line with the user's own progression cycle. In this manner a single user interface may be both simple and substantially infinitely complex, with the level of complexity presented to a particular user being tailored in real time to that particular user's perceived readiness for such complexity. This is especially useful in terms of delivering educational material, and, as described below, ensuring that a user has threshold levels of competency to receive certain information and/or advice. Kuhn, page 2, last paragraph and fig. 1, According to the method for progressive disclosure, features are hidden 140 and unavailable unless at least one indication suggests their use.). Claim 19 is rejected for the reasons set forth hereinabove for claim 16, Kuhn and Morrow teach the non-transitory computer readable medium of claim 16, wherein the analysis of the usage of the presented UI by a user includes: tracking a gaze of the user interacting with the UI(Morrow, para [0097], ] Interactions observed via video and/or other forms of direct user monitoring. An example is monitoring via eye tracking or the like, to better assess whether a user is effectively reading written content. In one embodiment the framework is configured to rate/distinguish interactions based on observed eye movements. ). Claim 20 rejected, Kuhn teaches a medical device updating method, comprising (Kuhn, p. 1, para. 1: "patient monitoring system"; see also p. 5, last paragraph: "advanced patient management systems”): grouping features of a received update of the medical device into a plurality of chunks (Kuhn, p. 2, para. 1: "Indications are selected based on patient risk or pathologies and are associated with certain features or groups of features for display at the UI. The UI only displays features or parameters that might be useful for a patient with the selected indications. As patient conditions change, warranting additional indications or a change in indications, the UI display progressively changes"; the groups of features being the chunks, these chunks being associated to different indications, see examples in p. 3, para. 1 and 2, concerning e.g. "1) "Primary prevention" which would allow observation and control of single V-tachy rate zone and fixed ATP/ shock therapy. 2) "Secondary prevention" which would allow observation and control of multiple V-tachy rate zones and customizable anti-tachyarrhythmia pacing (ATP) and shock therapy'); assigning chunks of the plurality of chunks an active or hidden state (Kuhn, the statement in p. 2, last paragraph: "Each potential patient indication is mapped 110 to a subset of features used for display on a user interface (UI)" necessarily implies a data structure containing the mapping for a given user of which features are hidden and which are shown, as in the cited examples of p. 3, para. 1 and 2); presenting a user interface (UI) of the medical device modified by the features of the chunks assigned the active state and not modified by the features of the chunks assigned the hidden state (Kuhn, p. 3, para. 1 and 2: ''Additionally, progressive disclosure provides flexibility, for example, if historical and/or co-morbidity indications are selected, thus invoking previously hidden features that become visible and available. Examples of indication-based progressive disclosure include: 1) "Primary prevention" which would allow observation and control of single V-tachy rate zone and fixed ATP/shock therapy. 2) "Secondary prevention" which would allow observation and control of multiple V-tachy rate zones and customizable anti-tachyarrhythmia pacing (ATP) and shock therapy”); analyzing usage of the presented UI by a user( Kuhn, page 2, last paragraph and fig. 1, “According to the method for progressive disclosure, features are hidden 140 and unavailable unless at least one indication suggests their use.”); selecting a chunk assigned the hidden state based on the analysis of the usage of the presented UI by the user( Kuhn, page 2, last paragraph and fig. 1, “According to the method for progressive disclosure, features are hidden 140 and unavailable unless at least one indication suggests their use.”); reassigning the selected chunk from the hidden state to the active state (Kuhn, page 3, first paragraph, “Progressive disclosure allows for a simplified UI when few indications or indications associated with fewer features are selected and most features remain hidden. Additionally, progressive disclosure provides flexibility, for example, if historical and/or co-morbidity indications are selected, thus invoking previously hidden features that become visible and available.”); and after the reassigning, continuing the presenting of the UI modified by the features of the chunks assigned the active state and not modified by the features of the chunks assigned the hidden state, whereby modification of the UI produced by one or more features grouped into the selected chunk are revealed (Kuhn, as shown e.g. in p. 3, para. 2: "(Automatic transition from primary to secondary prevention indications could occur when the CRM device detects a ventricular arrhythmia.) 3) An ''Atrial arrhythmia" indication would allow observation and control of atrial therapy features such as atrial pacing reference, ventricular rate regulation, and atrial tachyarrhythmia detection features. 4) A "No atrial arrhythmia" indication would hide atrial therapy features. 5) A "Ventricular fibrillation only" indication would hide zone settings and detection enhancements. 6) A "Paroxysmal atrial arrhythmias and ventricular tachyarrhythmia" indication would show an atrial therapy suite. multi-zone ventricular tachy detection. detection enhancements. and atrial or ventricular ATP therapy"; such updates necessarily require an update of the underlying data structure supporting the information for that user. Fig. 1, last paragraph, “Figure 1 illustrates a flowchart of a method for indications-based progressive disclosure. Each potential patient indication is mapped 110 to a subset of features used for display on a user interface (UI). Patient indications for a particular patient are identified 120 by a clinician, for example, by entering the indications on an indications based programming screen of the UI. The subset of features mapped to that patient indication are displayed 130 on the UI and are available for interaction. According to the method for progressive disclosure, features are hidden 140 and unavailable unless at least one indication suggests their use.”). The Office would like to use prior art Morrow to back up Morrow to further to teach limitations receiving update of the medical device (Morrow, para [0160-0162], Medical treatment. As a user develops a greater understanding of underlying concepts, health, and/or treatment risks, the user is provided with additional information and medical treatment advice. For example, in one embodiment a prescription for medication is able to be obtained once a user has demonstrated by way of interaction with the online environment that they have adequate competencies in relevant topics to be trusted to use the medication in an educated and sensible fashion. [0163-0167] Equipment maintenance. A user is provided with information that assists in performing more complex maintenance tasks only where they have demonstrated competency (for example through interaction with content) in respect of simpler underlying tasks of which prior competency is recommended. para [0168], Block 206 represents a process including a trigger to generate further user interface content. This may be content that is added to an existing page object (for example a further content segment), or content that replaces that which is shown in an existing page object. In response to that trigger, the method loops to block 202. Para [0186 and 0200].). analyzing usage of the presented UI by a user (Morrow, fig. 2 and para [0167], Block 204 represents a process including monitoring user interaction with rendered content, for example time spent viewing a given or designated content segment, interactions with GUI objects, and so on. This is used at a process represented by block 205, which includes updating competency scores (and optionally other values) based on user analysis rules.); It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Morrow into Kuhn to define interface customization rules. The user is monitored over time and a rules engine is configured to dynamically cause modification of the way in which user interface pages are to be displayed to that user. The user interface management interface allows an administrator user to define user activity rules by specifying a form of interaction as suggested by Morrow (See abstract and summary). Inquiry Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached M-F 8 to 5. 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, Lewis Bullock can be reached on 5712723759. 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. /DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199
Read full office action

Prosecution Timeline

Nov 14, 2024
Application Filed
Aug 28, 2026
Non-Final Rejection mailed — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12748583
AUTOMOTIVE SECURITY CONFIGURATION MANAGEMENT
2y 9m to grant Granted Sep 29, 2026
Patent 12730622
RELAY DEVICE AND NON-TRANSITORY COMPUTER-READABLE STORAGE MEDIUM
2y 10m to grant Granted Sep 08, 2026
Patent 12730611
POLICY CONTROLLED FUNCTION GENERATORS
2y 5m to grant Granted Sep 08, 2026
Patent 12717566
RECOMMENDING VERSION UPDATES FOR SOFTWARE PACKAGES
3y 11m to grant Granted Aug 25, 2026
Patent 12717558
Spreadsheet-Based Software Application Development
2y 8m to grant Granted Aug 25, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
82%
Grant Probability
99%
With Interview (+34.0%)
2y 8m (~10m remaining)
Median Time to Grant
Low
PTA Risk
Based on 570 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month