DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This office action is in response to Applicant’s response filed 11/12/2025.
The instant application having application No. 17/159,803 filed on January 27, 2021, has no priority information.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/12/2025 has been entered.
Status of the Claims
Claims 1, 7, 13, 15, 16, and 20 are amended, claim 2 was previously canceled. Accordingly, claims 1, 3-21 are currently pending in the application.
Response to Amendment
Regarding art rejection: In regards to pending claims Applicant’s arguments are not persuasive; further, Applicant's amendments necessitated new grounds of rejections presented in the following art rejection.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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.
Claim Interpretation
Claim limitations in claim 1 have been interpreted not to invoke 35 U.S.C. 112(f)
or pre-AIA 35 U.S.C. 112, sixth paragraph, because “the test engine is configured to ….” when read in light of the specification connoted sufficient, definite structure to one of skill in the art, see e.g. Fig. 1, wherein processor and memory are well known hardware to one of ordinary skill in the art.
Claim limitations in claim 20 have been interpreted not to invoke 35 U.S.C. 112(f)
or pre-AIA 35 U.S.C. 112, sixth paragraph, because “the computer arrangement is configured to ….” when read in light of the specification connoted sufficient, definite structure to one of skill in the art, see e.g. para [0033], wherein microprocessor and storage device are well known hardware to one of ordinary skill in the art.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 3-6, 8-14, 19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Pandurangarao et al. (US 11055208 B1– hereinafter Pandurangarao) in view of VIGNESH (US 20190042397 A1 -- hereinafter VIGNESH), Randimbivololona (US 20110047529 A1 -- hereinafter Randimbivololona) and Goodwin et al. (US 12169794 B1 -- hereinafter Goodwin).
With respect to claim 1 (Currently Amended), Pandurangarao discloses An automated testing system (e.g. Fig. 1), comprising:
a server comprising a processor and a memory (e.g. Fig. 1, application server 101), [the memory containing an accessibility matrix, the accessibility matrix comprising a two-dimensional data structure]; and
a test engine in data communication with the server (e.g. Fig. 1, accessibility compliance testing system 110 in data communication with server 101), the test engine comprising a machine learning model (e.g. col 10, lines 45-60, wherein a supervised machine learning algorithm reads on a machine learning model),
wherein, upon receipt of a development application configured to implement one or more functions (e.g. Fig. 3, step 302, col 5, lines 1-35, “As each piece of the application (e.g., by base code or by module) is being developed, the accessibility compliance testing system 110
can test how well the piece is compliant with various accessibility standards. …”), the test engine is configured to:
execute the test script to generate a test result (e.g. Fig. 3, steps 308-312. Col 10, lines 21-44, “… It is contemplated that each of the one or more test tools may generate an individual assessment, grading, or evaluation (“test tool-specific score” or “test tool-specific accessibility compliance score”) that indicates how compliant the program
generated by the individual base code is to the accessibility provisions corresponding to and tested by the test tool. …”);
identify a change by comparing the test result to the accessibility matrix (e.g. col 11, lines 15-31, “… For example, if the test tool measures whether a specific audio file is able to deliver features called for in an accessibility provision (e.g., Guideline 1.4.2 of WCAG 2.0), and the test tool generates a low score, then the device may determine that the audio file of a specific program may need improvement.” Wherein improvement reads on the change), and
classify the change in at least one selected from the group of a category of an appearance change, [[and]] a category of a functionality change, a high impact change, and a low impact change (e.g. col 11, lines 43-55, “… the device may determine an alternate manifestation of the aspect of the program, for example, that would render the program accessibility compliant (e.g., as in step 322). Thus, if an audio file lacks features that allow a user to pause or stop the audio as per Guideline 1.4.2 of WCAG 2.0, an alternate manifestation of the program would have a pause and stop button or other user interface functionality. …” wherein determining an alternate manifestation of the aspect of the program reads on classifying the change, and an audio file reads on a functionality change category);
[responsive to classifying the change as the low impact change or responsive to receiving approval for the high impact change, the test engine is further configured to] implement the change to the development application based on the test result and the accessibility matrix (e.g. Fig. 3, steps 318-326, col 11, lines 15-31, “… identifying the accessibility provision tested by the test tool that provided the test tool-specific score, …” wherein the accessibility provision reads on accessibility matrix. Fig. 3, step 326, wherein modify individual base code reads on implement a change).
Pandurangarao does not appear to explicitly disclose
(a server comprising a processor and a memory), the memory containing an accessibility matrix, the accessibility matrix comprising a two-dimensional data structure;
generate a test script configured to test at least one of the one or more functions;
responsive to classifying the change as the functionality change and the high impact change, the test engine is further configured to request user approval prior to implementing the change: and
responsive to classifying the change as the low impact change or responsive to receiving approval for the high impact change, the test engine is further configured to (implement the change to the development application based on the test result and the accessibility matrix).
However, in analogous art, VIGNESH teaches
(a server comprising a processor and a memory), the memory containing an accessibility matrix, the accessibility matrix comprising a two-dimensional data structure (e.g. para [0021], “… The automation unit 110 generates the file and stores information such as UI element type, identifier (ID) of the UI element, accessibility rule and the
result of accessibility testing for that UI element. …” wherein the automation unit 110 reads on a server, accessibility rule reads on accessibility matrix, “stores” indicates that the accessibility rule is stored, which renders claim feature obvious. Fig. 5B shows an accessibility matrix with testing result, it is a two-dimensional data structure);
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 invention of Pandurangarao with the invention of VIGNESH because it integrates the accessibility testing with the development life cycle to facilitate developers to develop accessibility compliant code. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of integrating the accessibility testing with the development life cycle to facilitate developers to develop accessibility compliant code as suggested by VIGNESH (see [0003, 0017]).
Pandurangarao as modified by VIGNESH does not appear to explicitly teach generate a test script configured to test at least one of the one or more functions;
responsive to classifying the change as the functionality change and the high impact change, the test engine is further configured to request user approval prior to implementing the change: and
responsive to classifying the change as the low impact change or responsive to receiving approval for the high impact change, the test engine is further configured to (implement the change to the development application based on the test result and the accessibility matrix).
However, in analogous art, Randimbivololona discloses
generate a test script configured to test at least one of the one or more functions (e.g. para [0061], “Step 26 for generating the test script is performed automatically by a script generator. This script generator firstly analyses the controlled states of variables, which have been recorded after step 20 of identifying the valid test cases and, secondly generates a source code for the test script (step 27).”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Randimbivololona because it enables a developer to be able to automatically generate programs for testing series of logic instructions. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of enabling a developer to automatically generate programs for testing series of logic instructions as suggested by Randimbivololona (see [0004]).
Pandurangarao as modified by VIGNESH and Randimbivololona does not appear to explicitly teach
responsive to classifying the change as the functionality change and the high impact change, the test engine is further configured to request user approval prior to implementing the change: and
responsive to classifying the change as the low impact change or responsive to receiving approval for the high impact change, the test engine is further configured to (implement the change to the development application based on the test result and the accessibility matrix).
However, in analogous art, Goodwin discloses
responsive to classifying the change as the functionality change and the high impact change, the test engine is further configured to request user approval prior to implementing the change (e.g. col 11, lines 36-51, “… Before an application is changed, a change request may be created that conveys one or more changes to an application. The change request may indicate the parameters of the change and the effects of the change. For example, the change request may predict a number of users affected by the requested change. Further, the change request may indicate the upstream applications, downstream applications, servers, other applications affected by the changed application, and the like. Code snippets, the date the applications are to be changed, and other information may be contained in the change request.” Wherein parameters of the change reads on functionality change, and the effects of the change reads on high impact change): and
responsive to classifying the change as the low impact change or responsive to receiving approval for the high impact change, the test engine is further configured to (implement the change to the development application based on the test result and the accessibility matrix) (col 11, lines 52-56, “Upon approval of the change request (by system administrators, supervisors, and the like), the change request may be documented in the change log and the requested change may be applied to the one or more applications according to the change request.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Goodwin because it provides techniques with which applications with a high likelihood of causing a continuity disruption may be identified such that factors resulting in applications having a high likelihood of a continuity disruption can be proactively mitigated. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques with which applications with a high likelihood of causing a continuity disruption may be identified such that factors resulting in applications having a high likelihood of a continuity disruption can be proactively mitigated as suggested by Goodwin (see col 4, lines 1-11).
With respect to claim 3 (Previously Presented), Pandurangarao discloses wherein the appearance change comprises at least one selected from the group of a font size change, a font color change, and a color contrast change (e.g. col 5, lines 1-35, “… For example, a test tool such as the Color Contrast Analyzer may determine whether a specific piece of the application provides good color visibility, e.g., for a user that may have visual impairment. …”).
With respect to claim 4 (Original), Pandurangarao discloses wherein the appearance change is selected to address a type of color blindness (e.g. col 5, lines 1-35, “… For example, a test tool such as the Color Contrast Analyzer may determine whether a specific piece of the application provides good color visibility, e.g., for a user that may have visual impairment. …” wherein visual impairment suggests a type of color blindness).
With respect to claim 5 (Previously Presented), Pandurangarao discloses wherein the category of the functionality change comprises at least one selected from the group of adding a user interface element, removing a user interface element, increasing a spacing between a plurality of user interface elements, decreasing a spacing between a plurality of user interface elements, adding a feedback, and removing a feedback. (e.g. col 11, lines 43-55, “… Thus, if an audio file lacks features that allow a user to pause or stop the audio as per Guideline 1.4.2 of WCAG 2.0, an alternate manifestation of the program would have a pause and stop button or other user interface functionality. ...” Wherein a pause and stop button reads on adding a user interface element).
With respect to claim 6 (Original), Pandurangarao discloses wherein the feedback comprises at least one selected from the group of a visual notification, an audio notification, an animation notification, and a haptic notification (e.g. Fig. 3, step 332, wherein assessment report reads on a visual notification).
With respect to claim 8 (Original), Pandurangarao discloses wherein the machine learning model is trained on a dataset comprising a plurality of case studies (e.g. col 10, lines 45-60, “… The training data may comprise a domain and a range. The range may include the results of various test tools for programs having specific category tags and/or having a specific accessibility provision that is relevant to those programs. The domain may include an evaluation or response of how accurately each of the various test tools predicted accessibility compliance of the specific programs. …” wherein the results of various test tools read on a plurality of case studies).
With respect to claim 9 (Original), Pandurangarao discloses wherein the plurality of case studies comprise case study applications including one or more accessibility deficiencies and one or more accessibility deficiency corrections (e.g. col 11, lines 43-55, “… Thus, if an audio file lacks features that allow a user to pause or stop the audio as per Guideline 1.4.2 of WCAG 2.0, an alternate manifestation of the program would have a pause and stop button or other user interface functionality. ...”).
With respect to claim 10 (Original), Pandurangarao discloses wherein the one or more accessibility deficiencies and one or more accessibility deficiency corrections comply with the accessibility matrix (e.g. col 11, lines 43-55, “… Thus, if an audio file lacks features that allow a user to pause or stop the audio as per Guideline 1.4.2 of WCAG 2.0, an alternate manifestation of the program would have a pause and stop button or other user interface functionality. ...” wherein Guideline reads on the accessibility matrix).
With respect to claim 11 (Previously Presented), Pandurangarao discloses wherein the plurality of case studies comprises case study applications that comply with the accessibility matrix (e.g. col 11, lines 43-55, “… Thus, if an audio file lacks features that allow a user to pause or stop the audio as per Guideline 1.4.2 of WCAG 2.0, an alternate manifestation of the program would have a pause and stop button or other user interface functionality. ...” wherein Guideline reads on the accessibility matrix).
With respect to claim 12 (Previously Presented), Pandurangarao ad modified by VIGNESH, Randimbivololona and Goodwin discloses The automated testing system of claim 1, Randimbivololona further discloses wherein the memory contains a library configured to:
provide an accessibility matrix interface (e.g. para [0022], “… The knowledge repository may be integrated with the central processing unit 108 or may be accessed by the central processing unit 108. An existing knowledge repository may include the list of accessibility rules that have failed along with solutions to overcome the failed accessibility rules. …” wherein the knowledge repository reads on a library and it is integrated with the central processing unit 108 which suggests the repository is part of memory/storage, “accessed by the central processing unit” suggests an interface; the accessibility rules read on accessibility matrix. For motivation to combine, please refer to office action regarding claim 1), and
provide an evaluation report interface (e.g. para [0022], “… For example, for the UI element button that has failed the accessibility test, the existing knowledge repository may include a solution to overcome or fix that accessibility test. For example, a knowledge repository with various accessibility rules that may fail along with solution are shown in table B below:” this portion of the paragraph suggests an evaluation report interface. For motivation to combine, please refer to office action regarding claim 1); and
VIGNESH further discloses
wherein the accessibility matrix includes a plurality of rows, each row being associated with a user's interaction with the development application (e.g. Fig. 5B shows an accessibility matrix with resting result, para [0030], “… The report 500 shows various statistics associated with the accessibility testing such as UI element type ‘button’ 502, link to UI element 504, UI element ‘go’ 506 and result of the accessibility test ‘fail’ 508
as shown in row 510. …” For motivation to combine, please refer to office action regarding claim 1).
With respect to claim 13 (Currently Amended), Pandurangarao discloses An automated testing method, comprising:
providing a development application that implements a graphical user interface (GUI) (e.g. Fig. 3, step 302, col 5, lines 1-35, “As each piece of the application (e.g., by base code or by module) is being developed, the accessibility compliance testing system
110 can test how well the piece is compliant with various accessibility standards. …” Fig. 1 shows the update interface 132 which reads on a GUI);
[generating, by a test engine, a test script], wherein the test engine comprises a machine learning model (e.g. col 10, lines 45-60, wherein a supervised machine learning algorithm reads on a machine learning model. e.g. col 10, lines 45-60, “… The training data may comprise a domain and a range. The range may include the results of various test tools for
programs having specific category tags and/or having a specific accessibility provision
that is relevant to those programs. The domain may include an evaluation or response of how accurately each of the various test tools predicted accessibility compliance of the specific programs. …” wherein the results of various test tools read on a plurality of case studies);
generating, by the test engine executing the test script, a test result (e.g. Fig. 3, steps 308-312. Col 10, lines 21-44, “… It is contemplated that each of the one or more test tools may generate an individual assessment, grading, or evaluation (“test tool-specific score” or “test tool-specific accessibility compliance score”) that indicates how compliant the program
generated by the individual base code is to the accessibility provisions corresponding to and tested by the test tool. …” wherein assessment, grading, or evaluation reads on a test result);
identifying, by the test engine, a change to the development application by comparing the test result and accessibility matrix (e.g. Fig. 3, steps 318-326, col 11, lines 15-31, “… identifying the accessibility provision tested by the test tool that provided the test tool-specific score, …” wherein the accessibility provision reads on accessibility matrix. Step 318, identify an aspect of the program needing improvement reads on identifying by the test engine, a change);
classifying, by the test engine, the change in at least one selected from the group of an appearance change category, [[and]] a functionality change category, a high impact change, and a low impact change (e.g. col 11, lines 43-55, “… the device may determine an alternate manifestation of the aspect of the program, for example, that would render the program accessibility compliant (e.g., as in step 322). Thus, if an audio file lacks features that allow a user to pause or stop the audio as per Guideline 1.4.2 of WCAG 2.0, an alternate manifestation of the program would have a pause and stop button or other user interface functionality. …” wherein determining an alternate manifestation of the aspect of the program reads on classifying the change, and an audio file reads on a functionality change category);
[responsive to classifying the change as the low impact change or responsive to receiving approval for the high impact change], implementing, by the test engine, the change to the development application (e.g. Fig. 3, step 326, wherein modify individual base code reads on implement a change).
Pandurangarao does not appear to explicitly disclose
generating, by a test engine, a test script, (wherein the test engine comprises a machine learning model trained on a training dataset comprising a plurality of case studies);
…, the accessibility matrix comprising a two-dimensional data structure;
responsive to classifying the change as the functionality change and the high impact change, triggering a request for user approval prior to implementing the change; and
responsive to classifying the change as the low impact change or responsive to receiving approval for the high impact change, (implementing, by the test engine, the change to the development application).
However, in analogous art, VIGNESH teaches
…, the accessibility matrix comprising a two-dimensional data structure (e.g. Fig. 5B shows an accessibility matrix with resting result, it is a two-dimensional data structure);
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 invention of Pandurangarao with the invention of VIGNESH because it integrates the accessibility testing with the development life cycle to facilitate developers to develop accessibility compliant code. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of integrating the accessibility testing with the development life cycle to facilitate developers to develop accessibility compliant code as suggested by VIGNESH (see [0003, 0017]).
Pandurangarao as modified by VIGNESH does not appear to explicitly teach
generating, by a test engine, a test script, (wherein the test engine comprises a machine learning model trained on a training dataset comprising a plurality of case studies);
responsive to classifying the change as the functionality change and the high impact change, triggering a request for user approval prior to implementing the change; and
responsive to classifying the change as the low impact change or responsive to receiving approval for the high impact change, (implementing, by the test engine, the change to the development application).
However, in analogous art, Randimbivololona discloses
generating, by a test engine, a test script, (wherein the test engine comprises a machine learning model trained on a training dataset comprising a plurality of case studies) (e.g. para [0061], “Step 26 for generating the test script is performed automatically by a script generator. This script generator firstly analyses the controlled states of variables, which have been recorded after step 20 of identifying the valid test cases and, secondly generates a source code for the test script (step 27).”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Randimbivololona because it enables a developer to be able to automatically generate programs for testing series of logic instructions. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of enabling a developer to automatically generate programs for testing series of logic instructions as suggested by Randimbivololona (see [0004]).
Pandurangarao as modified by VIGNESH and Randimbivololona does not appear to explicitly teach
responsive to classifying the change as the functionality change and the high impact change, triggering a request for user approval prior to implementing the change; and
responsive to classifying the change as the low impact change or responsive to receiving approval for the high impact change, (implementing, by the test engine, the change to the development application).
However, in analogous art, Goodwin discloses
responsive to classifying the change as the functionality change and the high impact change, triggering a request for user approval prior to implementing the change (e.g. col 11, lines 36-51, “… Before an application is changed, a change request may be created that conveys one or more changes to an application. The change request may indicate the parameters of the change and the effects of the change. For example, the change request may predict a number of users affected by the requested change. Further, the change request may indicate the upstream applications, downstream applications, servers, other applications affected by the changed application, and the like. Code snippets, the date the applications are to be changed, and other information may be contained in the change request.” Wherein parameters of the change reads on functionality change, and the effects of the change reads on high impact change): and
responsive to classifying the change as the low impact change or responsive to receiving approval for the high impact change, (implementing, by the test engine, the change to the development application) (col 11, lines 52-56, “Upon approval of the change request (by system administrators, supervisors, and the like), the change request may be documented in the change log and the requested change may be applied to the one or more applications according to the change request.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Goodwin because it provides techniques with which applications with a high likelihood of causing a continuity disruption may be identified such that factors resulting in applications having a high likelihood of a continuity disruption can be proactively mitigated. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques with which applications with a high likelihood of causing a continuity disruption may be identified such that factors resulting in applications having a high likelihood of a continuity disruption can be proactively mitigated as suggested by Goodwin (see col 4, lines 1-11).
With respect to claim 14 (Original), Pandurangarao as modified by VIGNESH, Randimbivololona and Goodwin discloses The automated testing method of claim 13, Randimbivololona further discloses further comprising:
generating, by the test engine, an evaluation report interface (e.g. para [0059], “… In the event where the test is valid, a step 22 offers the developer a validation interface in order to record the valid tests by conserving all of the states of variables observed. …” wherein the validation interface reads on an evaluation interface. For motivation to combine, please refer to office action regarding claim 13); and
displaying, by the test engine, the test result within the evaluation report interface (e.g. para [0059], “… In the event where the test is valid, a step 22 offers the developer a validation interface in order to record the valid tests by conserving all of the states of variables observed. …” wherein the states of variables observed read on the test result. For motivation to combine, please refer to office action regarding claim 13).
With respect to claim 19 (Previously Presented), Pandurangarao as modified by VIGNESH, Randimbivololona and Goodwin discloses The automated testing method of claim 13, Pandurangarao further discloses wherein the machine learning model is trained on a dataset comprising a plurality of case studies (e.g. col 10, lines 45-60, wherein a supervised machine learning algorithm reads on a machine learning model, col 10, lines 45-60, “… The training data may comprise a domain and a range. The range may include the results of various test tools for programs having specific category tags and/or having a specific accessibility provision that is relevant to those programs. The domain may include an evaluation or response of how accurately each of the various test tools predicted accessibility compliance of the specific programs. …” wherein the results of various test tools read on a plurality of case studies);
wherein the plurality of case studies includes one or more case study applications that comply with the accessibility matrix (e.g. col 11, lines 43-55, “… Thus, if an audio file lacks features that allow a user to pause or stop the audio as per Guideline 1.4.2 of WCAG 2.0, an alternate manifestation of the program would have a pause and stop button or other user interface functionality. ...” wherein Guideline reads on the accessibility matrix).
VIGNESH further discloses
wherein the accessibility matrix includes a plurality of rows, each row being associated with a user's interaction with the development application (e.g. Fig. 5B shows an accessibility matrix with resting result, para [0030], “… The report 500 shows various statistics associated with the accessibility testing such as UI element type ‘button’ 502, link to UI element 504, UI element ‘go’ 506 and result of the accessibility test ‘fail’ 508
as shown in row 510. …” For motivation to combine, please refer to office action regarding claim 13).
With respect to claim 21 (Previously Presented), it recites same features as claim 8, and is rejected for the same reason.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Pandurangarao in view of VIGNESH, Randimbivololona and Goodwin as applied to claim 1, in further view of Smith et al. (US 20070124305 A1 -- hereinafter Smith) and Ricci et al. (US 20140310739 A1 -- hereinafter Ricci).
With respect to claim 7 (Currently Amended), Pandurangarao as modified by VIGNESH, Randimbivololona and Goodwin discloses The automated testing system of claim 1, but does not appear to explicitly teach
Wherein, the test script is associated with one or more features, the one or more features including pushing a desired button on the GUI, entry of input into one or more fields on the GUI, or pushing out an alert on the GUI of an accessibility matrix; and
wherein the request for user approval is generated to account for any number of disabilities or impairments associated with a user of the automated testing system.
However, in analogous art, Smith discloses
Wherein, the test script is associated with one or more features, the one or more features including pushing a desired button on the GUI, entry of input into one or more fields on the GUI, or pushing out an alert on the GUI of an accessibility matrix (e.g. para [0049], “… an automated script is set forth below that tests the administration software by executing operations on the computer 7, while exploring and verifying the content displayed and contained in the software user interface including data, menu options, buttons, and links. By exploring the user interface and performing operations, the script ensures that the interface buttons, menu, options, and links respond correctly when selected or clicked. ...”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Smith because it provides an automated script for testing operation of the administration software by automatically executing operations and verifying results of these operations. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing an automated script for testing operation of the administration software by automatically executing operations and verifying results of these operations as suggested by Smith (see Abstract).
Pandurangarao as modified by VIGNESH, Randimbivololona, Goodwin and Smith does not appear to explicitly discloses
wherein the request for user approval is generated to account for any number of disabilities or impairments associated with a user of the automated testing system.
However, this is taught in analogous art, Ricci (e.g. para [0844], “The type of assistance provided by the vehicle control system 204 depends on the particular impairment and/or disability involved. ... By way of illustration, information, commands, warnings, and requests provided by way of the driver's device or user interface 212, 248, user interface (s)/input interface(s) 324 and/or I/O module 312 to users with vision impairments can be one or more of the use of screen magnification, high contrast (e.g., between text and background colors such as white text on a black background, large font size and/or icon size (e.g., without changing screen resolution), color changes on the screen, a screen reader (or other text-to-speech program), speech recognition software (such as to operate the computer and/or software), enablement of a read mode, keyboard web page navigation, and the like. Information, commands, warnings, and requests provided by way of the driver's device or user interface 212, 248, user interface (s)/input interface(s) 324 and/or I/O module 312 to users with a hearing impairment can be one or more of the use of text or visual alternatives for sounds, high volume levels, changed computer sounds, sign language interpretation or translation (e.g., by image processing and acquisition based on visual images captured by one or more camera sensors), a text phone application, and the like. …..”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Ricci because it provides accessibility or assistive technology to assist user with impairment and/or disability. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing accessibility or assistive technology to assist user with impairment and/or disability as suggested by Ricci (see para [0843-0844]).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Pandurangarao in view of VIGNESH, Randimbivololona and Goodwin as applied to claim 13, in further view of Bridges et al (US 20180373578 A1 -- hereinafter Bridges).
With respect to claim 15 (Currently Amended), Pandurangarao as modified by VIGNESH, Randimbivololona and Goodwin discloses The automated testing method of claim 13, but does not appear to explicitly teach further comprising, prior to implementing the change:
classifying the change as a high impact change or a low impact change.
However, this is taught in analogous art, Bridges (e.g. Fig 3A, steps 304, wherein adverse cross impact is determined, and Yes indicates high impact change, and No indicate low impact change.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Bridges because it minimizes risk in implementing changes. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of reducing technology incident and minimizing risk in implementing changes as suggested by Bridges (see [0004, 0034]).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Pandurangarao in view of VIGNESH, Randimbivololona and Goodwin as applied to claim 13, in further view of Bridges et al (US 20180373578 A1 -- hereinafter Bridges), Smith et al. (US 20070124305 A1 -- hereinafter Smith) and Ricci et al. (US 20140310739 A1 -- hereinafter Ricci).
With respect to claim 16 (Currently Amended), Pandurangarao as modified by VIGNESH, Randimbivololona and Goodwin discloses The automated testing method of claim 13, but does not appear to explicitly teach further comprising, prior to implementing the change:
classifying the change as a high impact change or a low impact change; [[and]]
wherein the test script is associated with one or more features, the one or more features including pushing a desired button on the GUI, entry of input into one or more fields on the GUI, or pushing out an alert on the GUI of an accessibility matrix; and
wherein the request for user approval is generated to account for any number of disabilities or impairments associated with a user of the development application.
However, in analogous art, Bridges discloses further comprising, prior to implementing the change:
classifying the change as a high impact change or a low impact change; (e.g. Fig 3A, steps 304, wherein adverse cross impact is determined, and Yes indicates high impact change, and No indicate low impact change.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Bridges because it minimizes risk in implementing changes. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of reducing technology incident and minimizing risk in implementing changes as suggested by Bridges (see [0004, 0034]).
Pandurangarao as modified by VIGNESH, Randimbivololona, Goodwin and Bridges does not appear to explicitly disclose
wherein the test script is associated with one or more features, the one or more features including pushing a desired button on the GUI, entry of input into one or more fields on the GUI, or pushing out an alert on the GUI of an accessibility matrix; and
wherein the request for user approval is generated to account for any number of disabilities or impairments associated with a user of the development application.
However, in analogous art, Smith discloses
wherein the test script is associated with one or more features, the one or more features including pushing a desired button on the GUI, entry of input into one or more fields on the GUI, or pushing out an alert on the GUI of an accessibility matrix (e.g. para [0049], “… an automated script is set forth below that tests the administration software by executing operations on the computer 7, while exploring and verifying the content displayed and contained in the software user interface including data, menu options, buttons, and links. By exploring the user interface and performing operations, the script ensures that the interface buttons, menu, options, and links respond correctly when selected or clicked. ...”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Smith because it provides an automated script for testing operation of the administration software by automatically executing operations and verifying results of these operations. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing an automated script for testing operation of the administration software by automatically executing operations and verifying results of these operations as suggested by Smith (see Abstract).
Pandurangarao as modified by VIGNESH, Randimbivololona, Goodwin, Bridges and Smith does not appear to explicitly discloses
wherein the request for user approval is generated to account for any number of disabilities or impairments associated with a user of the development application.
However, this is taught in analogous art, Ricci (e.g. para [0844], “The type of assistance provided by the vehicle control system 204 depends on the particular impairment and/or disability involved. ... By way of illustration, information, commands, warnings, and requests provided by way of the driver's device or user interface 212, 248, user interface (s)/input interface(s) 324 and/or I/O module 312 to users with vision impairments can be one or more of the use of screen magnification, high contrast (e.g., between text and background colors such as white text on a black background, large font size and/or icon size (e.g., without changing screen resolution), color changes on the screen, a screen reader (or other text-to-speech program), speech recognition software (such as to operate the computer and/or software), enablement of a read mode, keyboard web page navigation, and the like. Information, commands, warnings, and requests provided by way of the driver's device or user interface 212, 248, user interface (s)/input interface(s) 324 and/or I/O module 312 to users with a hearing impairment can be one or more of the use of text or visual alternatives for sounds, high volume levels, changed computer sounds, sign language interpretation or translation (e.g., by image processing and acquisition based on visual images captured by one or more camera sensors), a text phone application, and the like. …..”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Ricci because it provides accessibility or assistive technology to assist user with impairment and/or disability. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing accessibility or assistive technology to assist user with impairment and/or disability as suggested by Ricci (see para [0843-0844]).
Claims 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Pandurangarao in view of VIGNESH, Randimbivololona and Goodwin as applied to claim 13, in further view of YOSHIDA et al (US 20170161182 A1 -- hereinafter YOSHIDA).
With respect to claim 17 (Original), Pandurangarao as modified by VIGNESH, Randimbivololona and Goodwin discloses The automated testing method of claim 13, but does not appear to explicitly teach further comprising assigning a score to the change. However, this is taught in analogous art, YOSHIDA (e.g. para [0037], “At block 308, a repair effectiveness indication may be determined with respect to the fault location. …” wherein the effectiveness indication reads on a score).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of YOSHIDA because it may improve the efficiency of software program testing and repair. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of better and more efficient repairs being made as suggested by YOSHIDA (see [0050]).
With respect to claim 18 (Original), Pandurangarao as modified by VIGNESH, Randimbivololona, Goodwin and YOSHIDA discloses The automated testing method of claim 17, YOSHIDA further discloses further comprising:
comparing the score to a threshold (e.g. para [0039], “… it may be determined based on whether a threshold associated with the repair effectiveness indication is satisfied. …” For motivation to combine, please refer to office action regarding claim 17); and
implementing the change if the score exceeds the threshold (e.g. para [0039], “…in response to the threshold being met, a prioritization of performing a potential repair at the fault location may be such that a repair at the fault location may be performed.” For motivation to combine, please refer to office action regarding claim 17).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Pandurangarao in view of VIGNESH, Randimbivololona, YOSHIDA and Goodwin.
With respect to claim 20 (Currently Amended), Pandurangarao discloses A non-transitory computer-accessible medium having stored thereon computer- executable instructions for automated testing, wherein, when a computer arrangement executes the instructions, the computer arrangement is configured to perform procedures comprising (e.g. Fig. 2):
executing the test script to generate a test result (e.g. Fig. 3, steps 308-312. Col 10, lines 21-44, “… It is contemplated that each of the one or more test tools may generate an individual assessment, grading, or evaluation (“test tool-specific score” or “test tool-specific accessibility compliance score”) that indicates how compliant the program
generated by the individual base code is to the accessibility provisions corresponding to and tested by the test tool. …” wherein test tools read on test script, and assessment, grading, or evaluation reads on a test result);
comparing the test result to an accessibility matrix (e.g. Fig. 3, steps 318-326, col 11, lines 15-31, “… identifying the accessibility provision tested by the test tool that provided the test tool-specific score, …” this paragraph suggests comparing the test result with an accessibility matrix, wherein the accessibility provision reads on accessibility matrix and the test tool-specific score reads on test result);
identifying a change to the development application based on the comparison (e.g. Fig. 3, steps 318-326, col 11, lines 15-31, “… identifying the accessibility provision
tested by the test tool that provided the test tool-specific score, …” this paragraph suggests comparing the test result with an accessibility matrix, wherein the accessibility provision reads on accessibility matrix and the test tool-specific score reads on test result. Step 318, identify an aspect of the program needing improvement reads on identifying by the test engine, a change);
classifying the change in at least one selected from the group of an appearance change category and a functionality change category, [[and]] a functionality change category, a high impact change, and a low impact change (e.g. col 11, lines 43-55, “… the device may determine an alternate manifestation of the aspect of the program, for example, that would render the program accessibility compliant (e.g., as in step 322). Thus, if an audio file lacks features that allow a user to pause or stop the audio as per Guideline 1.4.2 of WCAG 2.0, an alternate manifestation of the program would have a pause and stop button or other user interface functionality. …” wherein determining an alternate manifestation of the aspect of the program reads on classifying the change, and an audio file reads on a functionality change category);
Pandurangarao does not appear to explicitly disclose
generating a test script for a development application;
…, the accessibility matrix comprising a two-dimensional data structure;
assigning a score to the change;
comparing the score to a threshold; [[and]]
responsive to classifying the change as the functionality change and the high impact change, the computer arrangement is further configured to request user approval prior to implementing the change; and
[[upon]] responsive to determining that the score exceeds the threshold, to classifying the change as the low impact change or responsive to receiving approval for the high impact change, implementing the change to the development application.
However, in analogous art, VIGNESH teaches
…, the accessibility matrix comprising a two-dimensional data structure (e.g. Fig. 5B shows an accessibility matrix with resting result, it is a two-dimensional data structure);
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 invention of Pandurangarao with the invention of VIGNESH because it integrates the accessibility testing with the development life cycle to facilitate developers to develop accessibility compliant code. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of integrating the accessibility testing with the development life cycle to facilitate developers to develop accessibility compliant code as suggested by VIGNESH (see [0003, 0017]).
Pandurangarao as modified by VIGNESH does not appear to explicitly teach
generating a test script for a development application;
assigning a score to the change;
comparing the score to a threshold; [[and]]
responsive to classifying the change as the functionality change and the high impact change, the computer arrangement is further configured to request user approval prior to implementing the change; and
[[upon]] responsive to determining that the score exceeds the threshold, to classifying the change as the low impact change or responsive to receiving approval for the high impact change, implementing the change to the development application.
However, in analogous art, Randimbivololona discloses
generating a test script for a development application (e.g. para [0061], “Step 26 for generating the test script is performed automatically by a script generator. This script generator firstly analyses the controlled states of variables, which have been recorded after step 20 of identifying the valid test cases and, secondly generates a source code for the test script (step 27).”);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Randimbivololona because it enables a developer to be able to automatically generate programs for testing series of logic instructions. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of enabling a developer to automatically generate programs for testing series of logic instructions as suggested by Randimbivololona (see [0004]).
Pandurangarao as modified by VIGNESH and Randimbivololona does not appear to explicitly disclose
assigning a score to the change;
comparing the score to a threshold; [[and]]
responsive to classifying the change as the functionality change and the high impact change, the computer arrangement is further configured to request user approval prior to implementing the change; and
[[upon]] responsive to determining that the score exceeds the threshold, to classifying the change as the low impact change or responsive to receiving approval for the high impact change, implementing the change to the development application.
However, in analogous art, YOSHIDA discloses
assigning a score to the change (e.g. para [0037], “At block 308, a repair effectiveness indication may be determined with respect to the fault location. …” wherein the effectiveness indication reads on a score);
comparing the score to a threshold (e.g. para [0039], “… it may be determined based on whether a threshold associated with the repair effectiveness indication is satisfied. …”); and
responsive to determining that the score exceeds the threshold, [to classifying the change as the low impact change or responsive to receiving approval for the high impact change], implementing the change to the development application (e.g. para [0039], “…in response to the threshold being met, a prioritization of performing a potential repair at the fault location may be such that a repair at the fault location may be performed.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of YOSHIDA because it may improve the efficiency of software program testing and repair. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of better and more efficient repairs being made as suggested by YOSHIDA (see [0050]).
Pandurangarao as modified by VIGNESH, Randimbivololona and YOSHIDA does not appear to explicitly disclose
responsive to classifying the change as the functionality change and the high impact change, the computer arrangement is further configured to request user approval prior to implementing the change; and
[[upon]] responsive to (determining that the score exceeds the threshold), to classifying the change as the low impact change or responsive to receiving approval for the high impact change, implementing the change to the development application.
However, in analogous art, Goodwin discloses
responsive to classifying the change as the functionality change and the high impact change, the computer arrangement is further configured to request user approval prior to implementing the change (e.g. col 11, lines 36-51, “… Before an application is changed, a change request may be created that conveys one or more changes to an application. The change request may indicate the parameters of the change and the effects of the change. For example, the change request may predict a number of users affected by the requested change. Further, the change request may indicate the upstream applications, downstream applications, servers, other applications affected by the changed application, and the like. Code snippets, the date the applications are to be changed, and other information may be contained in the change request.” Wherein parameters of the change reads on functionality change, and the effects of the change reads on high impact change): and
responsive to (determining that the score exceeds the threshold), to classifying the change as the low impact change or responsive to receiving approval for the high impact change, implementing the change to the development application (col 11, lines 52-56, “Upon approval of the change request (by system administrators, supervisors, and the like), the change request may be documented in the change log and the requested change may be applied to the one or more applications according to the change request.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the invention of Goodwin because it provides techniques with which applications with a high likelihood of causing a continuity disruption may be identified such that factors resulting in applications having a high likelihood of a continuity disruption can be proactively mitigated. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques with which applications with a high likelihood of causing a continuity disruption may be identified such that factors resulting in applications having a high likelihood of a continuity disruption can be proactively mitigated as suggested by Goodwin (see col 4, lines 1-11).
Response to Arguments
Applicant's arguments regarding art rejections filed 11/12/2025 have been fully considered and are moot upon new grounds of rejections made in the office action above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zengpu Wei whose telephone number is 571-270-1302. The examiner can normally be reached on Monday to Friday from 8:00AM to 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets, can be reached on 571-272-3338. 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://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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.
/Zengpu Wei/
Examiner, Art Unit 2197