DETAILED ACTION
This action is responsive to the Amendment filed on 06/02/2026. Claims 1-14 remain pending in the case. Claim 11 was amended. Claims 1-10 and 14 remain withdrawn from consideration.
Claim Interpretations/Examiner’s Notes
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. Further, during examination, the claims must be interpreted as broadly as their terms reasonably allow (see In re American Academy of Science Tech Center, 367 F.3d 1359, 1369, 70 U.S.P.Q.2d 1827, 1834 (Fed. Cir. 2004)). Also, although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims (see In re Van Geuns, 988 F.2d 1181, 26 U.S.P.Q.2d 1057 (Fed. Cir. 1993)). The following is provided to aid the reader in understanding how at least some claim elements (also commonly referred to as claim limitations), as a whole, have been considered in the rejections below:
“if” [e.g. claim 11, lines 15, 17, and 20] = The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. Therefore, as currently claimed, functionalities that currently depend on “if” conditions being true may not be narrowing the claims to the extent it may have been intended since, for purposes of prior art analysis, any prior art scenario showing at least one mappable instance wherein the contingency/triggering condition is not met/true (like any horizontal or diagonal direction, or if the user input is just not carried out “via a directional key input”) would suffice to anticipate or teach these aspects. See “Contingent Limitations” in MPEP § 2111.04, subsection II and/or MPEP § 2143.03.
Claim Objections
Claims 11-13 are objected to because of the following informalities:
Claim 11:
Line 12 improperly reintroduce the limitation “a GUI element” (this same limitation was already recited in line 10 of the same claim).
Line 13 improperly reintroduces the limitation “sequential keyboard navigation” (antecedent basis for this limitation had already been established in lines 11-12 of the same claim).
Line 17 recites the limitation “the focused data chart,” which lacks proper antecedent basis (the amendments overcorrected both instances of the “focused data chart” limitation instead of introducing the first one with an “a” article and the second with a “the” article).
Lines 20-21 improperly reintroduce the limitation “a directional key value” (this same limitation was already recited in lines 15-16 of the same claim).
Line 22 improperly reintroduces the limitation “a GUI element” (this same limitation was already recited in line 10 of the same claim).
Line 23 improperly reintroduces the limitation “sequential keyboard navigation” (this same limitation was already recited in lines 11-12 of the same claim).
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 12 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. As of the latest amendments, parent claim 11 narrows the contingent scenarios of the user input to solely correspond to “a directional key input” (see lines 15-16 and 20-21 of claim 11). However, dependent claim 12 attempts to not only broaden the scope already narrowed in parent claim 11, but also attempts to allow the user inputs to be “voice instructions.” It is unclear how the user inputs can be both received via a physical “directional key” and also via “voice.”
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 11-13 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Page et al. (US Patent Application Pub. No. 2022/0121723, hereinafter “Page”).
As to independent claim 11, Page shows:
A computer-implemented method for enhancing navigability on a graphical user interface (GUI) [¶ 03] comprising GUI elements [“the first web page comprises a plurality of elements” (¶ 15)] to be provided on a display [¶ 318],
each GUI element having a tab index attribute for keyboard or voice sequential navigation [“{…} a test may determine if one or more tabbable elements on in web page have an ARIA hidden attribute.{…} one or more elements may be tabbable because they have a tabindex attribute. {…}” (¶ 162)];
the GUI elements comprising a plurality of data charts, each data chart comprising a plurality of data series GUI elements [the GUI elements may comprise a plurality of data charts/tables/grids, each data chart comprising a plurality of data series GUI elements (¶¶ 125, 157, & 269) | For even further examples of “tables or grids” as charts, see also ¶¶ 98, 176, 213-220, 228, 295-297, & 307.];
the method comprising carrying out, by a data processing device comprising a processor [¶ 313], the steps of:
loading for displaying on said display a received GUI data structure comprising said GUI elements [loading for displaying on said display “a hypertext markup language (HTML), document object model (DOM), wherein the DOM comprises one or more nodes, the one or more nodes organized into a DOM tree structure” (¶ 09) | See also ¶¶ 14-15 & 47-48.];
clearing or setting the tab index attribute of GUI elements, including button GUI elements [¶¶ 172-173 & 254], to a value corresponding to a GUI element being non-reachable via sequential keyboard navigation [“{…} a test may determine if one or more tabbable elements on in web page have an ARIA hidden attribute. In some embodiments, one or more elements may be tabbable because they are naturally tabbable. In some embodiments, one or more elements may be tabbable because they have a tabindex attribute. In some embodiments, one or more naturally tabbable element may be hidden at least in part from assistive technology by setting its tabindex to −1. In some embodiments, one or more element that is not naturally tabbable may be hidden from assistive technology at least in part by removing the tabindex attribute from the element.” (¶ 162) | See also ¶¶ 267-271, 285, & 306.];
setting the tab index attribute in each data chart to a value corresponding to a GUI element being reachable via sequential keyboard navigation [the tab index attribute in each data chart/table/grid (¶¶ 125, 157, & 269) may be set to a value corresponding to a GUI element being reachable via sequential keyboard navigation (¶ 286) | See also ¶¶ 267-271, 280, & 306.];
receiving one or more user inputs [¶¶ 255 & 318-319], and for each received user input: if the received user input corresponds to a downwards direction via a directional key input, then clearing any tab index attribute from the GUI elements, setting the tab index attribute for each data series GUI element comprised in the focused data chart if GUI user focus is on the focused data chart, and setting focus to a first data series GUI element of the focused data chart; if the received user input corresponds to an upwards direction via a directional key input, then clearing any tab index attribute from the data series GUI elements, setting the tab index attribute in each data chart to a value corresponding to a GUI element being reachable via sequential keyboard navigation, and setting the focus to the data chart of a previously focused data series GUI element [Page shows the operability to receive at least some inputs (¶¶ 255 & 318-319) that correspond to neither a “downwards direction” nor “an upwards direction.” Since this is a method claim where the conditions precedent (e.g. “if the received user input corresponds to a downwards direction” and/or “if the received user input corresponds to an upwards direction”) are not met, the limitations that are contingent (introduced within corresponding “then” clauses) are required neither to be performed nor be mapped to the prior art. See “Contingent Limitations” in MPEP § 2111.04, subsection II and/or MPEP § 2143.03.].
As to dependent claim 12, Page further shows:
wherein the user inputs are keystrokes or voice instructions [the user inputs may be keystrokes (¶¶ 255 & 318-319) or voice instructions (¶¶ 04-06, 18, & 319).].
As to dependent claim 13, Page further shows:
wherein the method is carried out by an assistive data processing device comprising a processor arranged to provide an accessible GUI or a data processing device comprising a processor arranged to provide a voice assistant [the method is carried out by an assistive data processing device comprising a processor arranged to provide an accessible GUI (¶ 03) or a data processing device comprising a processor arranged to provide a voice assistant (¶¶ 04-06, 18, & 319)].
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 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.
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 11-13 are rejected under 35 U.S.C. § 103 as being unpatentable over Page et al. (US Patent Application Pub. No. 2022/0121723, hereinafter “Page”) in view of "Developing a Keyboard Interface." Captured 06/01/2022. https://web.archive.org/web/20220601070114/https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/ (hereinafter “ARIA APG”).
As to independent claim 11, Page shows:
A computer-implemented method for enhancing navigability on a graphical user interface (GUI) [¶ 03] comprising GUI elements [“the first web page comprises a plurality of elements” (¶ 15)] to be provided on a display [¶ 318],
each GUI element having a tab index attribute for keyboard or voice sequential navigation [“{…} a test may determine if one or more tabbable elements on in web page have an ARIA hidden attribute.{…} one or more elements may be tabbable because they have a tabindex attribute. {…}” (¶ 162)];
the GUI elements comprising a plurality of data charts, each data chart comprising a plurality of data series GUI elements [the GUI elements may comprise a plurality of data charts/tables/grids, each data chart comprising a plurality of data series GUI elements (¶¶ 125, 157, & 269) | For even further examples of “tables or grids” as charts, see also ¶¶ 98, 176, 213-220, 228, 295-297, & 307.];
the method comprising carrying out, by a data processing device comprising a processor [¶ 313], the steps of:
loading for displaying on said display a received GUI data structure comprising said GUI elements [loading for displaying on said display “a hypertext markup language (HTML), document object model (DOM), wherein the DOM comprises one or more nodes, the one or more nodes organized into a DOM tree structure” (¶ 09) | See also ¶¶ 14-15 & 47-48.];
clearing or setting the tab index attribute of GUI elements, including button GUI elements [¶¶ 172-173 & 254], to a value corresponding to a GUI element being non-reachable via sequential keyboard navigation [“{…} a test may determine if one or more tabbable elements on in web page have an ARIA hidden attribute. In some embodiments, one or more elements may be tabbable because they are naturally tabbable. In some embodiments, one or more elements may be tabbable because they have a tabindex attribute. In some embodiments, one or more naturally tabbable element may be hidden at least in part from assistive technology by setting its tabindex to −1. In some embodiments, one or more element that is not naturally tabbable may be hidden from assistive technology at least in part by removing the tabindex attribute from the element.” (¶ 162) | See also ¶¶ 267-271, 285, & 306.];
setting the tab index attribute in each data chart to a value corresponding to a GUI element being reachable via sequential keyboard navigation [the tab index attribute in each data chart/table/grid (¶¶ 125, 157, & 269) may be set to a value corresponding to a GUI element being reachable via sequential keyboard navigation (¶ 286) | See also ¶¶ 267-271, 280, & 306.];
receiving one or more user inputs [¶¶ 255 & 318-319]{…}
Page further shows all of the functionalities below, albeit in a dispersed manner (meaning not in a single situation/use-case as described in the limitations below). For example, Page shows:
if the received user input corresponds to a downwards direction via a directional key input [e.g. determining if the user input corresponds to “onkeydown events” (¶ 116)],
{…} clearing any tab index attribute from the GUI elements [“{…} a test may determine if one or more tabbable elements on in web page have an ARIA hidden attribute. In some embodiments, one or more elements may be tabbable because they are naturally tabbable. In some embodiments, one or more elements may be tabbable because they have a tabindex attribute. In some embodiments, one or more naturally tabbable element may be hidden at least in part from assistive technology by setting its tabindex to −1. In some embodiments, one or more element that is not naturally tabbable may be hidden from assistive technology at least in part by removing the tabindex attribute from the element.” (¶ 162) | See also ¶¶ 267-271, 285, & 306.],
setting the tab index attribute for each data series GUI element comprised in the focused data chart if GUI user focus is on the focused data chart [the tab index attribute for each element in a focused chart/table/grid (¶¶ 125, 157, & 269) may be set (¶ 286) | See also ¶¶ 267-271, 280, & 306.], and
setting focus to a first data series GUI element of the focused data chart [e.g. being able to set focus to a first data series GUI element of the focused data chart (¶¶ 129, 178, 269-271, & 286)];
if the received user input corresponds to an upwards direction via a directional key input [e.g. determining if the user input corresponds to “onkeyup events” (¶ 116)],
{…} clearing any tab index attribute from the data series GUI elements [“{…} a test may determine if one or more tabbable elements on in web page have an ARIA hidden attribute. In some embodiments, one or more elements may be tabbable because they are naturally tabbable. In some embodiments, one or more elements may be tabbable because they have a tabindex attribute. In some embodiments, one or more naturally tabbable element may be hidden at least in part from assistive technology by setting its tabindex to −1. In some embodiments, one or more element that is not naturally tabbable may be hidden from assistive technology at least in part by removing the tabindex attribute from the element.” (¶ 162) | See also ¶¶ 267-271, 285, & 306.],
setting the tab index attribute in each data chart to a value corresponding to a GUI element being reachable via sequential keyboard navigation [the tab index attribute for each chart/table/grid (¶¶ 125, 157, & 269) may be set to a value corresponding to a GUI element being reachable via sequential keyboard navigation (¶ 286) | See also ¶¶ 267-271, 280, & 306.], and
setting the focus to the data chart of a previously focused data series GUI element [e.g. being able to set focus to the data chart of a previously focused data series GUI element (¶¶ 129, 178, 269-271, & 286)].
However, Page does not appear to describe a specific scenario where these functionalities happen to occur directly in response a “downwards” input or an “upwards” input. In an analogous art, Aria APG shows:
{…}for each received user input:
if the received user input corresponds to a downwards direction via a directional key input [a down “arrow key” input (pages 6-8)], then clearing any tab index attribute [removing/resetting/substituting the value (pages 6 & 7) of a “tabindex” attribute (page 5)] from the GUI elements, setting the tab index attribute for each data series GUI element comprised in the focused data chart if GUI user focus is on the focused data chart [setting the tabindex values of the child elements in a grid/chart composite element to a “focusable” value if the user has focused on a particular chart to navigate among its inner elements (pages 6 & 7)], and setting focus to a first data series GUI element of the focused data chart [setting focus to a first focusable child element inside the grid/chart composite element (pages 6-8)];
if the received user input corresponds to an upwards direction via a directional key input [an up “arrow key” input (pages 6-8)], then clearing any tab index attribute from the data series GUI elements [removing/resetting/substituting the value (pages 6 & 7) of a “tabindex” attribute (page 5)], setting the tab index attribute in each data chart to a value corresponding to a GUI element being reachable via sequential keyboard navigation, and setting the focus to the data chart of a previously focused data series GUI element [setting the tabindex values of the outer/parent grid/chart composite elements themselves (instead of their inner contents) to a “focusable” value when the user exits the inner navigational scope of a specific chart/grid and instead focuses on navigating among the charts/grids (pages 2 & 6-8)].
One of ordinary skill in the art, having the teachings of Page and Aria APG before them prior to the effective filing date of the claimed invention, would have been motivated to combine Page’s teachings (including its “onkeydown,” “onkeyup,” tabindex clearing, tabindex setting, and element focusing functionalities) with Aria APG’s best practices teachings to arrive at the contingent1 chart navigation scenarios as currently claimed. The rationale for doing so would have been that Page’s explicit goal was “identifying accessibility issues in web sites and for remediating website accessibility issues to thereby facilitate website navigation by people with diverse abilities” (Page: Abstract) and Aria APG would have aided Page to achieve that goal by providing “experiences to people who rely on a keyboard that are as efficient and enjoyable as the experiences available to others” (Aria APG: page 1). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Page and Aria APG (hereinafter, the “Page-Aria APG” combination) in order to obtain the invention as recited in claim 11.
As to dependent claim 12, Page-Aria APG further shows:
wherein the user inputs are keystrokes or voice instructions [the user inputs may be keystrokes (Page: ¶¶ 255 & 318-319) or voice instructions (Page: ¶¶ 04-06, 18, & 319).].
As to dependent claim 13, Page-Aria APG further shows:
wherein the method is carried out by an assistive data processing device comprising a processor arranged to provide an accessible GUI or a data processing device comprising a processor arranged to provide a voice assistant [the method is carried out by an assistive data processing device comprising a processor arranged to provide an accessible GUI (Page: ¶ 03) or a data processing device comprising a processor arranged to provide a voice assistant (Page: ¶¶ 04-06, 18, & 319)].
Response to Arguments
Applicant’s arguments have been fully considered but they are not persuasive. Applicant argues:
“Specifically, Applicant respectfully traverses the Examiner's objections to (i) "a value corresponding to a GUI element being non-reachable via sequential keyboard navigation" and (ii) "a value corresponding to a GUI element being reachable via sequential keyboard navigation," and the corresponding parallel instances later in the claim. The phrase "a value corresponding to a GUI element being non-reachable" and the phrase "a value corresponding to a GUI element being reachable" are not the same limitation: they describe two different values assigned to two categorically opposite element states.”
The Office maintains that the claims would have benefited from further specificity by way of assigning unique labels to each “value” instance (like a “first value” and a “second value,” respectively), but will withdraw the corresponding objection to this limitation given Applicant’s comments on record. Nonetheless, Applicant is respectfully advised to utilize the entirety of the language singling out each value when referring to them after their respective introductions because just mentioning “the value” would likely introduce indefiniteness concerns.
“{…} Similarly, "a GUI element" as used in each of these definitional phrases is used in a generic, categorical sense (describing a class of element state) and does not constitute a reintroduction of any particular GUI element previously recited in the claim. Applicant respectfully requests that these objections be withdrawn.”
The Office respectfully disagrees in this instance and respectfully asks that Applicant either properly refer to “the” (original) “GUI element” in subsequent recitations of the same limitation or otherwise differentiate in instance with a unique label (like “first,” “second,” etc.).
“{…} The Office Action relies on the "contingent limitations" doctrine under MPEP § 2111.04, subsection II, to note that these conditional steps need not be mapped to a prior art scenario where the conditions are triggered. Applicant respectfully submits that this approach fails to appreciate the fundamental architectural distinction of the present disclosure.”
The Office respectfully disagrees and invites Applicant to consider how they have claimed “the fundamental architectural distinction of the present disclosure,” which is via a method claim with contingent/“if” clauses. “The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. For example, assume a method claim requires step A if a first condition happens and step B if a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both steps A and B.” 2 Therefore, if the prior art shows any scenario wherein the received user input does not correspond to either a downwards direction or an upwards direction (like any horizontal or diagonal direction, or if the user input is just not carried out “via a directional key input”), then the conditions precedent are not met, and thus the “if/then” clauses as claimed need not necessarily be mapped to the prior art for purposes of prior art analysis.
“{…} Like the Grid, the Tree pattern does not clear tabindex attributes of elements outside the tree widget, and the "up/down" directional inputs serve only to traverse visible tree nodes, not to trigger a system-level depth-axis state transition across the entire GUI as recited in Claim 11.”
The Office respectfully disagrees and submits that despite Applicant’s allegation, “a system-level depth-axis state transition across the entire GUI” is not in fact recited in Claim 11.
“The citations of record, including Page (US 2022/0121723) and the ARIA APG patterns (Grid, Tree, and the general Roving Tabindex), operate exclusively within the boundaries of a single composite widget, moving focus laterally among elements within that widget without altering the focusability of any element outside it. Amended Claim 11, by contrast, uses directional key inputs not as lateral navigation commands but as triggers for a depth-axis state transition that restructures the navigability of the entire GUI, rendering all non-chart elements and all non-focused chart elements non-reachable while the user explores the data series of a focused chart, and then fully restoring the prior chart-level navigation state upon an upward directional key input. No combination of the citations of record teaches or suggests this GUI- scope enforcement mechanism, and the diagrams above make clear that the present disclosure occupies a distinct architectural category from anything disclosed or rendered obvious by the citations of record.”
The Office respectfully disagrees. First, the Office notes for the record that there are several aspects alleged in the above argument that are not explicitly recited, including “altering the focusability of any element outside it,” “a depth-axis state transition,” and “rendering all non-chart elements and all non-focused chart elements non-reachable while the user explores the data series of a focused chart, and then fully restoring the prior chart-level navigation state upon an upward directional key input.” Moreover, Page-Aria APG explicitly ponders navigating to an outside element (Aria APG: page 2, penultimate paragraph).
“Critically, Aria APG's roving tabindex pattern does not teach or suggest the system-level tab index sweep recited in Amended Claim 11. As described in the pending application at ¶ [0027], the presently claimed method clears or sets the tab index attribute of all GUI elements, including button GUI elements, rendering the entire GUI non-reachable via sequential keyboard navigation (except for the data charts). This is a qualitatively different operation from Aria APG's per-widget focus management: in the present disclosure, all non-chart elements across the entire interface, buttons, links, and other interactive controls, are cleared from the tab sequence when the user enters chart-exploration mode. Neither Aria APG nor Page teaches this GUI-scope enforcement architecture.”
The Office respectfully disagrees with their characterizations, submits that the claims vary significantly in scope and detail from the contentions in the above argument, and maintains that the cited prior art reasonably teaches what is currently actually claimed.
“Furthermore, in standard Aria APG patterns, widgets do not lose their tabindex or keyboard shortcut functionality when the user interacts with their child elements. For example, in the Aria APG Grid pattern, other grids on the page retain their tabindex="0" while the user navigates inside a given grid. In contrast, as described in the pending application at ¶ [0027], when the user presses a downwards directional input to enter a focused data chart, the present invention clears any tab index attribute from all GUI elements, including other charts, ensuring that only the data series elements of the focused chart are navigable. This ensures that the user cannot inadvertently navigate to another chart while exploring the data series of the current chart, which is a fundamental usability goal for screen reader accessibility. See also pending application at [0065] (Navigation function 215 governing this scope-management behavior).”
The Office respectfully disagrees. In response to Applicant’s arguments that the references fail to show certain features of Applicant’s invention, it is noted that the features upon which Applicant relies (like “child elements”, in addition to all the other unclaimed elements identified above) are not recited in the rejected claims. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 U.S.P.Q.2d 1057 (Fed. Cir. 1993).
“The Office Action's rationale for combining Page and Aria APG is that Page's goal was "identifying accessibility issues in web sites" and Aria APG provides best practices for "experiences to people who rely on a keyboard." See Page at Abstract; Aria APG at page 1. While the general field of web accessibility is shared, a generalized motivation to improve accessibility does not render obvious a specific, novel navigation architecture. The mere fact that Page addresses tabindex attributes in the context of accessibility remediation and Aria APG provides keyboard navigation patterns does not suggest combining them in the specific manner claimed, i.e., to create a system-level, directional-input-triggered, scope-managed chart navigation state machine that enforces hierarchical GUI depth transitions. The combination proposed by the Office Action would not result in the claimed invention because neither reference, individually or together, teaches clearing all GUI element tabindex attributes (including non-chart buttons) in response to a downwards directional input while simultaneously setting tabindex attributes for the data series elements of a focused chart.”
The Office respectfully disagrees. Both references show their own version of clearing/removing/resetting/substituting the value of a “tabindex” attribute (Page: ¶¶ 162, 267-271, 285, & 306 | Aria APG: pages 5-7), and the Office maintains that it would have been obvious to do so in response to a downwards directional input, which was also shown by both references (Page: ¶ 116 | Aria APG: pages 6-8).
“Applicant further notes that Amended Claim 11 additionally specifies that the directional inputs are "via a directional key input", which makes explicit that the depth-transition mechanism is triggered by a specific type of keyboard interaction, i.e., a directional (arrow) key, as opposed to, for example, a Tab key or other sequential navigation key. This amendment clarifies the distinction from Aria APG's roving tabindex pattern, which uses Tab and arrow keys for sequential navigation within widgets rather than depth-axis state transitions. Support for this amendment is found throughout the pending application, including at [0027] (reciting "downward direction" and "upward direction" inputs) and [0065] (Navigation function 215 responding to key pressed events).”
The Office notes for the record that Applicant themselves admit that Aria APG shows “arrow keys” for navigation, and also submits that Page too shows upwards/downwards “directional key input” key input teachings (Page: ¶ 116).
Therefore, the Office respectfully asserts that the cited art sufficiently teaches the limitations recited in the amended claims.
Conclusion
THIS ACTION IS MADE FINAL. Applicants are reminded of the extension of time policy as set forth in 37 C.F.R. § 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 C.F.R. § 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.
It is noted that any citation to specific pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. In re Heck, 699 F.2d 1331, 1332-33, 216 U.S.P.Q. 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 U.S.P.Q. 275, 277 (C.C.P.A. 1968)).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALVARO R CALDERON IV whose telephone number is (571) 272-1818. The examiner can normally be reached on Monday - Friday (8:30am - 5pm).
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, Kieu Vu can be reached on (571) 272-4057. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ALVARO R CALDERON IV/
Examiner, Art Unit 2171
/KIEU D VU/Supervisory Patent Examiner, Art Unit 2171
1 See “Contingent Limitations” in MPEP § 2111.04, subsection II and/or MPEP § 2143.03.
2 MPEP § 2111.04, subsection II.
Prosecution Insights