DETAILED ACTION
This action is in response to the claims filed November 26, 2025. Claims 1-20 are pending. Claims 1, 11, and 16 are independent claims.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 11 and 16 are objected to because of the following informalities:
- Claim 11 recites “transmitting het HID action messages” on line 13. This should likely read “transmitting the HID action messages”.
Claim 16 reads “type and software verison" on line 14. This should likely read “type and software version”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 4, 10, 11, 15, and 16 recite “native user interface”. There is insufficient support for “native user interface” in the specification. Claims 2-10, 12-15, and 17-20 are rejected in view of their dependency on claims 1, 11, and 16 respectively.
Claims 1, 11, and 16 recite “a timing parameter defining a pause interval after execution of the HID action”. There is insufficient support for “after execution of the HID action” in the specification. The specification provides support for “a pause between HID messages” (Paragraph [0030]). The specification does not support a time to pause after the action is executed. Claims 2-10, 12-15, and 17-20 are rejected in view of their dependency on claims 1, 11, and 16, respectively.
Claims 1 and 11 recite “input events at an operating system input layer to cause traversal of the native user interface without invoking any application-level automation framework”. There is insufficient support for this limitation in the specification. While paragraph [0032] discloses “As such, rather than having a user provide input (e.g., with a finger, stylus, etc.) to a user interface, the HID action messages allow for automatic user interface selections”, this does not specify an operating system input layer, nor any type of application-level automation framework. Claims 2-10, 12-15, and 17-20 are rejected in view of their dependency on claims 1, 11, and 16, respectively.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-15 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190095126 A1 (hereinafter “Torma”) in view of US 7055137 B2 (hereinafter “Mathews”), further in view of US 20170262130 A1 (hereinafter “Lloyd”).
Regarding claim 1, Torma discloses:
a memory device storing executable instructions (Paragraph [0070], “As shown in more detail in FIG. 1B, the test station 20 includes a processor 22, a memory 24, a transmitter/receiver 26 and a user interface 28… A host application 29 comprising computer-executable instructions is stored in the memory 24 which, when executed by the processor 22, cause the test station 20… [a memory device storing executable instructions]”); and
at least one processor communicatively coupled to the memory device, wherein the executable instructions when executed by the at least one processor cause the apparatus to (Paragraph [0070], “As shown in more detail in FIG. 1B, the test station 20 includes a processor 22, a memory 24, a transmitter/receiver 26 and a user interface 28… A host application 29 comprising computer-executable instructions is stored in the memory 24 which, when executed by the processor 22, cause the test station 20… [at least one processor communicatively coupled to the memory device, wherein the executable instructions when executed by the at least one processor cause the apparatus to]”):
- receive, from a remote database, workflow data for the device under test, …(Paragraph [0070], “… cause the test station 20 to retrieve workflow or action data from the server 40 and perform actions represented by the workflow or action data, for example, by the workflow illustrated in FIG. 2 [receive, from a database, workflow data for the device under test]”);
…
- cause the device under test to automatically perform configuration operations by transmitting the HID action messages to the device under test…(Paragraph [0070], “… cause the test station 20 to retrieve workflow or action data from the server 40 and perform actions represented by the workflow or action data, for example, by the workflow illustrated in FIG. 2 [cause the device under test to automatically perform configuration operations by transmitting the HID action messages to the device under test]”) [Examiner’s remarks: Actions represented by the workflow are performed upon transmission to the device].
Torma does not explicitly disclose:
An apparatus for automatically configuring a device under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the apparatus comprising:
…
- …the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to a detected device type and software version;
- generate a plurality of HID action messages based on the workflow data, each HID action message comprising:
- at least one screen coordinate corresponding to a location of a native user interface element of the device under test,
- a timing parameter defining a pause interval after execution of the HID action, wherein the HID action messages are interpreted by the device under test as physical touchscreen interactions or input events at an operating system input layer to cause traversal of the native user interface without invoking any application-level automation framework; and
- …, wherein the configuration operations are performed by navigating a native user interface of the device under test.
However, Mathews discloses:
An apparatus for automatically configuring a device under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the apparatus comprising (Column 4, lines 52-64, “Although WINRUNNER is primarily described, any software capable of providing an appropriate environment for automated software GUI testing may be used. WINRUNNER code permits automation of software GUI testing by allowing customized programs to be created to control the flow of information to and from the software GUI being tested, in other words, to simulate interactions with software GUI users. For example, software GUI tests may simulate keyboard strokes, mouse clicks, or other methods of providing input to the GUI, reading associated data from the GUI, and returning results of processing that data to the GUI [An apparatus for automatically configuring a device under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the apparatus comprising]”):
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mathews into the teachings of Torma to include “An apparatus for automatically configuring a device under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the apparatus comprising”. As stated in Mathews, “The GUI is often the principal or only mechanism by which a user can provide input to and receive output from the software application with which the GUI is associated. It is therefore essential that the GUI operate correctly and efficiently for the successful operation of the associated software application…” (Column 1, lines 14-19). Testing of user interfaces is essential for ensuring that users are able to properly interact with the associated software. However, human testing of user interfaces is inefficient and may be inconsistent. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with testing of user interfaces.
The combination of Torma and Mathews does not explicitly disclose:
- …the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to a detected device type and software version;
- generate a plurality of HID action messages based on the workflow data, each HID action message comprising:
- at least one screen coordinate corresponding to a location of a native user interface element of the device under test,
- a timing parameter defining a pause interval after execution of the HID action, wherein the HID action messages are interpreted by the device under test as physical touchscreen interactions or input events at an operating system input layer to cause traversal of the native user interface without invoking any application-level automation framework; and
- …, wherein the configuration operations are performed by navigating a native user interface of the device under test.
However, Lloyd discloses:
- … the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to a detected device type and software version (Paragraph [0006], “Further, different test scripts need to be written for different devices, for example due to different screen sizes, different versions of an operating system or application, or different arrangement of icons. Therefore, developing similar tests for a plurality of similar, but not identical devices, is very time intensive as each device requires a new test script to be written. Therefore, there is a need to simplify the process of creating a test script for a device so that it will be less time intensive for creating a single test script, as well as multiple similar test scripts for a plurality of different devices [the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to a detected device type and software version]”) [Examiner’s remarks: Different workflows comprising navigation commands are generated based on different device types and application/operating system versions.];
- generate a plurality of HID action messages based on the workflow data, each HID action message comprising (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”) [Examiner’s remarks: A plurality of HID actions are based on the workflow data.]:
- at least one screen coordinate corresponding to a location of a native user interface element of the device under test (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”) [Examiner’s remarks: Each coordinate represents a location on the given user interface of a touchscreen of the device under test.], and
- a timing parameter defining a pause interval after execution of the HID action, wherein the HID action messages are interpreted by the device under test as physical touchscreen interactions or input events at an operating system input layer to cause traversal of the native user interface without invoking any application-level automation framework (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”; Paragraph [0058], “In embodiments, when the test script is replayed the first touch event is simulated on the device under test, and the second touch event is simulated next with a time delay between the two events corresponding to the timestamps of the two events. As discussed above, in embodiments, the timestamps in the test script corresponding to an event may be relative to previous touch events, the initiation of the recording, or a conditional statement”) [Examiner’s remarks: Each HID message contains a timestamp indicating the time that should be waited for after each tap based on a screen recording. Each coordinate represents a location on a touchscreen.]; and
- …wherein the configuration operations are performed by navigating a native user interface of the device under test (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”) [Examiner’s Remarks: The actions are performed by navigating the interface of a device under test using pixel coordinates.]
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Lloyd into the combined teachings of Torma and Mathews to include “- …the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to a detected device type and software version”, “generate a plurality of HID action messages based on the workflow data, each HID action message comprising”, “at least one screen coordinate corresponding to a location of a native user interface element of the device under test”, “a timing parameter defining a pause interval after execution of the HID action, wherein the HID action messages are interpreted by the device under test as physical touchscreen interactions or input events at an operating system input layer to cause traversal of the native user interface without invoking any application-level automation framework”, and “…, wherein the configuration operations are performed by navigating a native user interface of the device under test. ”. As stated in Lloyd, “The method of recording touch events for later use as a test script is faster and requires less programming knowledge, compared to manually writing a test script. This is beneficial if a new test script is needed quickly because a technician can perform a desired touch sequence on a device recording the sequence and then distribute the recorded sequence to be played on a plurality of devices to be tested” (Abstract). Screen recording touchscreen events in the form of pixel coordinates based on device type allows for quick testing and development of devices under test, as well as easy test development for less experienced test developers, allowing for easy and natural testing with fewer errors. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with actions involving interaction with screen locations using HID messages based on device screen.
Regarding claim 2, the rejection of claim 1 is incorporated; and Torma further discloses:
wherein the executable instructions when executed by the at least on processor further cause the apparatus to:
- transmit a configuration request to the device under test (Paragraph [0087], “A user can base workflow direction on action or workflow element output, questions to operator or values gathered from the device under test, for example, serial number, model type operating system [transmit a configuration request to the device under test]”) [Examiner’s remarks: The apparatus transmits (gathers) a configuration request for the device under test.];
- receive configuration data from the device under test in response to the configuration request (Paragraph [0087], “A user can base workflow direction on action or workflow element output, questions to operator or values gathered from the device under test, for example, serial number, model type operating system [receive configuration data from the device under test in response to the configuration request]”) [Examiner’s remarks: The apparatus receives configuration information from the device under test.]; and
- determine the workflow data for the device under test based on the configuration data (Paragraph [0087], “A user can base workflow direction on action or workflow element output, questions to operator or values gathered from the device under test, for example, serial number, model type operating system [determine the workflow data for the device under test based on the configuration data]”) [Examiner’s remarks: The workflow data (workflow direction) is determined by the configuration data.].
Regarding claim 3, the rejection of claim 2 is incorporated; and Torma further discloses:
- wherein the configuration data comprises at least one of a device type, a model number, a software version, a hardware version, or a year of manufacturer (Paragraph [0087], “A user can base workflow direction on action or workflow element output, questions to operator or values gathered from the device under test, for example, serial number, model type operating system [wherein the configuration data comprises at least one of a device type, a model number, a software version, a hardware version, or a year of manufacture.]”).
Regarding claim 4, the rejection of claim 1 is incorporated; and the combination of Torma and Mathews does not explicitly disclose:
- wherein the plurality of HID action messages comprise a first HID action message to engage a location of a page of a native user interface displayed by the device under test.
However, Lloyd discloses:
- wherein the plurality of HID action messages comprise a first HID action message to engage a location of a page of a native user interface displayed by the device under test (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80” [wherein the plurality of HID action messages comprise a first HID action message to engage a location of a page of a native user interface displayed by the device under test.]”).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Lloyd into the combined teachings of Torma and Mathews to include “wherein the plurality of HID action messages comprise a first HID action message to engage a location of a page of a native user interface displayed by the device under test”. As stated in Lloyd, “The method of recording touch events for later use as a test script is faster and requires less programming knowledge, compared to manually writing a test script. This is beneficial if a new test script is needed quickly because a technician can perform a desired touch sequence on a device recording the sequence and then distribute the recorded sequence to be played on a plurality of devices to be tested” (Abstract). Screen recording touchscreen events in the form of pixel coordinates based on device type allows for quick testing and development of devices under test, as well as easy test development for less experienced test developers, allowing for easy and natural testing with fewer errors. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with actions involving interaction with screen locations using HID messages based on device screen.
Regarding claim 5, the rejection of claim 4 is incorporated; and the combination of Torma and Mathews does not explicitly disclose:
- wherein the first HID action message includes a pixel row location and a pixel column location corresponding to the location of the page.
However, Lloyd discloses:
- wherein the first HID action message includes a pixel row location and a pixel column location corresponding to the location of the page (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80” [wherein the first HID action message includes a pixel row location and a pixel column location corresponding to the location of the page]”).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Lloyd into the combined teachings of Torma and Mathews to include “wherein the first HID action message includes a pixel row location and a pixel column location corresponding to the location of the page”. As stated in Lloyd, “The method of recording touch events for later use as a test script is faster and requires less programming knowledge, compared to manually writing a test script. This is beneficial if a new test script is needed quickly because a technician can perform a desired touch sequence on a device recording the sequence and then distribute the recorded sequence to be played on a plurality of devices to be tested” (Abstract). Screen recording touchscreen events in the form of pixel coordinates based on device type allows for quick testing and development of devices under test, as well as easy test development for less experienced test developers, allowing for easy and natural testing with fewer errors. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with actions involving interaction with screen locations using HID messages based on device screen.
Regarding claim 6, the rejection of claim 5 is incorporated; and the combination of Torma and Mathews does not explicitly disclose:
- wherein the timing parameter defines a time to pause after transmitting the first HID action messages.
However, Lloyd discloses:
- wherein the timing parameter defines a time to pause after transmitting the first HID action messages (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”; Paragraph [0058], “In embodiments, when the test script is replayed the first touch event is simulated on the device under test, and the second touch event is simulated next with a time delay between the two events corresponding to the timestamps of the two events. As discussed above, in embodiments, the timestamps in the test script corresponding to an event may be relative to previous touch events, the initiation of the recording, or a conditional statement”) [Examiner’s remarks: The instructions include an timestamp that can be used to made a delay between actions.].
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Lloyd into the combined teachings of Torma and Mathews to include “wherein the timing parameter defines a time to pause after transmitting the first HID action messages”. As stated in Lloyd, “The method of recording touch events for later use as a test script is faster and requires less programming knowledge, compared to manually writing a test script. This is beneficial if a new test script is needed quickly because a technician can perform a desired touch sequence on a device recording the sequence and then distribute the recorded sequence to be played on a plurality of devices to be tested” (Abstract). Screen recording touchscreen events in the form of pixel coordinates based on device type allows for quick testing and development of devices under test, as well as easy test development for less experienced test developers, allowing for easy and natural testing with fewer errors. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with actions involving interaction with screen locations using HID messages based on device screen and delay time.
Regarding claim 7, the rejection of claim 1 is incorporated; and Torma does not explicitly disclose:
- transmit firmware update messages to the device under test, each firmware update message comprising a portion of executable instructions characterizing firmware ;
- determine the device under test has restarted; and
- transmit the plurality of HID actions to the device under test based on determining the device under test has restarted.
However, Mathews discloses:
- transmit firmware update messages to the device under test, each firmware update message comprising a portion of executable instructions characterizing firmware (Column 4, lines 21-26, “Each client controller 36 may also periodically install current software builds on its client system 32, periodically reboot its client system 32, and establish communication with test server engine 24 when its client system 32 boots up, as described below [transmit firmware update messages to the device under test, each firmware update message comprising a portion of executable instructions characterizing firmware]”);
- determine the device under test has restarted (Column 3, lines 7-19, “In certain embodiment, each client controller may carry out a reboot of its test execution computer at one or more appropriate times (e.g., twice a day) to help ensure that the test execution computer is less likely to “hang up” due to operating system instabilities…In certain embodiments, the client controller of each test execution computer is set up to automatically start software code that established communication with the test server engine when its test execution computer boots up [determine the device under test has restarted]”); and
- transmit the plurality of HID actions to the device under test based on determining the device under test has restarted (Column 3, lines 7-19, “In certain embodiment, each client controller may carry out a reboot of its test execution computer at one or more appropriate times (e.g., twice a day) to help ensure that the test execution computer is less likely to “hang up” due to operating system instabilities…In certain embodiments, the client controller of each test execution computer is set up to automatically start software code that established communication with the test server engine when its test execution computer boots up [transmit the plurality of HID actions to the device under test based on determining the device under test has restarted]”).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mathews into the teachings of Torma to include “transmit firmware update messages to the device under test, each firmware update message comprising a portion of executable instructions characterizing firmware”, “determine the device under test has restarted”, and “transmit the plurality of HID actions to the device under test based on determining the device under test has restarted”. As stated in Mathews, “The GUI is often the principal or only mechanism by which a user can provide input to and receive output from the software application with which the GUI is associated. It is therefore essential that the GUI operate correctly and efficiently for the successful operation of the associated software application…” (Column 1, lines 14-19). Testing of user interfaces is essential for ensuring that users are able to properly interact with the associated software. However, human testing of user interfaces is inefficient and may be inconsistent. Testing should be done one recent versions of software to ensure that software works Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with updating and restarting of devices.
Regarding claim 8, the rejection of claim 1 is incorporated; and Torma does not explicitly disclose:
- determine the device under test has restarted; and
- transmit debug messages to the device under test to install a testing application.
However, Mathews discloses:
- determine the device under test has restarted (Column 3, lines 7-19, “In certain embodiment, each client controller may carry out a reboot of its test execution computer at one or more appropriate times (e.g., twice a day) to help ensure that the test execution computer is less likely to “hang up” due to operating system instabilities…In certain embodiments, the client controller of each test execution computer is set up to automatically start software code that established communication with the test server engine when its test execution computer boots up [determine the device under test has restarted]”); and
- transmit debug messages to the device under test to install a testing application(Column 4, lines 21-26, “Each client controller 36 may also periodically install current software builds on its client system 32, periodically reboot its client system 32, and establish communication with test server engine 24 when its client system 32 boots up, as described below [transmit debug messages to the device under test to install a testing application]”).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mathews into the teachings of Torma to include “determine the device under test has restarted” and “transmit debug messages to the device under test to install a testing application”. As stated in Mathews, “The GUI is often the principal or only mechanism by which a user can provide input to and receive output from the software application with which the GUI is associated. It is therefore essential that the GUI operate correctly and efficiently for the successful operation of the associated software application…” (Column 1, lines 14-19). Testing of user interfaces is essential for ensuring that users are able to properly interact with the associated software. However, human testing of user interfaces is inefficient and may be inconsistent. Automatically installing applications once device restarts allows for automation with less human input. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with automatic application installation.
Regarding claim 9, the rejection of claim 1 is incorporated; and Torma further discloses:
- wherein the at least one processor is communicatively coupled to the device under test by one or more communication cables (Paragraph [0021], “The further apparatus may be connectable (e.g. via wired or wireless connection) to the device that is to be subject of the desired erasure procedure and/or the desired diagnostic procedure [wherein the at least one processor is communicatively coupled to the device under test by one or more communication cables.]”).
Regarding claim 10, the rejection of claim 1 is incorporated; and the combination of Torma and Mathews does not explicitly disclose:
- wherein the workflow data characterizes one or more engagements of one or more icons of one or more pages of a native user interface displayed by the device under test.
However, Lloyd discloses:
- wherein the workflow data characterizes one or more engagements of one or more icons of one or more pages of a native user interface displayed by the device under test (Paragraph [0050], “FIGS. 4A-C, illustrate an example of using a record application to record touch events and screen conditions which will be used to create a conditional statement in the test script created from the recording. In the example, a technician records a touch event to be used in a test script for answering an incoming telephone call [wherein the workflow data characterizes one or more engagements of one or more icons of one or more pages of a native user interface displayed by the device under test]”) [Examiner’s remarks: Commands may include interfacing with icons for example, a button to pick up the phone.].
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Lloyd into the combined teachings of Torma and Mathews to include “wherein the workflow data characterizes one or more engagements of one or more icons of one or more pages of a native user interface displayed by the device under test”. As stated in Lloyd, “The method of recording touch events for later use as a test script is faster and requires less programming knowledge, compared to manually writing a test script. This is beneficial if a new test script is needed quickly because a technician can perform a desired touch sequence on a device recording the sequence and then distribute the recorded sequence to be played on a plurality of devices to be tested” (Abstract). Screen recording touchscreen events in the form of pixel coordinates based on device type allows for quick testing and development of devices under test, as well as easy test development for less experienced test developers, allowing for easy and natural testing with fewer errors. Icon interaction is a major part of touchscreen use. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with actions involving interaction with screen locations with icon interaction.
Regarding claim 11, Torma discloses:
- receiving, from a remote database, workflow data for the device under test (Paragraph [0070], “… cause the test station 20 to retrieve workflow or action data from the server 40 and perform actions represented by the workflow or action data, for example, by the workflow illustrated in FIG. 2 [receiving, from a database, workflow data for the device under test]”)…,
- …
- transmitting het HID action messages over a physical communication interface (Paragraph [0021], “The further apparatus may be connectable (e.g. via wired or wireless connection) to the device that is to be subject of the desired erasure procedure and/or the desired diagnostic procedure [a testing computing device communicatively coupled to each of the devices under test, via a physical communication interface]”) [Examiner’s remarks: HID messages may be transmitted over physical communication interfaces (wired connection).] …
- …to cause the device under test to automatically perform configuration operations (Paragraph [0070], “… cause the test station 20 to retrieve workflow or action data from the server 40 and perform actions represented by the workflow or action data, for example, by the workflow illustrated in FIG. 2 [… cause the device under test to automatically perform configuration operations]”) [Examiner’s remarks: Actions represented by the workflow are performed upon transmission to the device]…
Torma does not explicitly disclose:
A method for automatically configuring a device under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the method comprising:
- …the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to a detected device type and software version;
- generating a plurality of HID action messages based on the workflow data, each HID action message comprising;
- at least one screen coordinate corresponding to a location of a native user interface element of the device under test and a timing parameter defining a pause interval after execution of the HID action;
- … to the device under test, wherein the HID action messages are interpreted by the device under test as physical touchscreen or input events at an operating system input layer to cause traversal of the native user interface without invoking any application level automation framework; and
- transmitting the HID action messages to the device under …by navigating a native user interface of the device under test.
However, Mathews discloses:
A method for automatically configuring a device under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the method comprising (Column 4, lines 52-64, “Although WINRUNNER is primarily described, any software capable of providing an appropriate environment for automated software GUI testing may be used. WINRUNNER code permits automation of software GUI testing by allowing customized programs to be created to control the flow of information to and from the software GUI being tested, in other words, to simulate interactions with software GUI users. For example, software GUI tests may simulate keyboard strokes, mouse clicks, or other methods of providing input to the GUI, reading associated data from the GUI, and returning results of processing that data to the GUI [A method for automatically configuring a device under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the method comprising]”):
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mathews into the teachings of Torma to include “A method for automatically configuring a device under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the method comprising”. As stated in Mathews, “The GUI is often the principal or only mechanism by which a user can provide input to and receive output from the software application with which the GUI is associated. It is therefore essential that the GUI operate correctly and efficiently for the successful operation of the associated software application…” (Column 1, lines 14-19). Testing of user interfaces is essential for ensuring that users are able to properly interact with the associated software. However, human testing of user interfaces is inefficient and may be inconsistent. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with testing of user interfaces.
The combination of Torma and Mathews does not explicitly disclose:
- …the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to a detected device type and software version;
- generating a plurality of HID action messages based on the workflow data, each HID action message comprising;
- at least one screen coordinate corresponding to a location of a native user interface element of the device under test and a timing parameter defining a pause interval after execution of the HID action;
- … to the device under test, wherein the HID action messages are interpreted by the device under test as physical touchscreen or input events at an operating system input layer to cause traversal of the native user interface without invoking any application level automation framework; and
- transmitting the HID action messages to the device under …by navigating a native user interface of the device under test.
However, Lloyd discloses:
- …the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to a detected device type and software version (Paragraph [0006], “Further, different test scripts need to be written for different devices, for example due to different screen sizes, different versions of an operating system or application, or different arrangement of icons. Therefore, developing similar tests for a plurality of similar, but not identical devices, is very time intensive as each device requires a new test script to be written. Therefore, there is a need to simplify the process of creating a test script for a device so that it will be less time intensive for creating a single test script, as well as multiple similar test scripts for a plurality of different devices [the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to a detected device type and software version]”) [Examiner’s remarks: Different workflows comprising navigation commands are generated based on different device types and application/operating system versions.];
- generating a plurality of HID action messages based on the workflow data, each HID action message comprising (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”) [Examiner’s remarks: A plurality of HID actions are based on the workflow data.];
- at least one screen coordinate corresponding to a location of a native user interface element of the device under test and a timing parameter defining a pause interval after execution of the HID action (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”; Paragraph [0058], “In embodiments, when the test script is replayed the first touch event is simulated on the device under test, and the second touch event is simulated next with a time delay between the two events corresponding to the timestamps of the two events. As discussed above, in embodiments, the timestamps in the test script corresponding to an event may be relative to previous touch events, the initiation of the recording, or a conditional statement”);
- transmitting het HID action messages over a physical communication interface to the device under test, wherein the HID action messages are interpreted by the device under test as physical touchscreen or input events at an operating system input layer to cause traversal of the native user interface without invoking any application level automation framework (Paragraph [0058], “In embodiments, when the test script is replayed the first touch event is simulated on the device under test, and the second touch event is simulated next with a time delay between the two events corresponding to the timestamps of the two events. As discussed above, in embodiments, the timestamps in the test script corresponding to an event may be relative to previous touch events, the initiation of the recording, or a conditional statement”); and
- transmitting the HID action messages to the device under test to cause the device under test … by navigating a native user interface of the device under test (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”) [Examiner’s remarks: Each coordinate represents a location on the given user interface of a touchscreen of the device under test which should be navigated according to the HID actions.].
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Lloyd into the combined teachings of Torma and Mathews to include “…the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to a detected device type and software version”, “generating a plurality of HID action messages based on the workflow data, each HID action message comprising”, “at least one screen coordinate corresponding to a location of a native user interface element of the device under test and a timing parameter defining a pause interval after execution of the HID action”, “… to the device under test, wherein the HID action messages are interpreted by the device under test as physical touchscreen or input events at an operating system input layer to cause traversal of the native user interface without invoking any application level automation framework” and “transmitting the HID action messages to the device under …by navigating a native user interface of the device under test”. As stated in Lloyd, “The method of recording touch events for later use as a test script is faster and requires less programming knowledge, compared to manually writing a test script. This is beneficial if a new test script is needed quickly because a technician can perform a desired touch sequence on a device recording the sequence and then distribute the recorded sequence to be played on a plurality of devices to be tested” (Abstract). Screen recording touchscreen events in the form of pixel coordinates based on device type allows for quick testing and development of devices under test, as well as easy test development for less experienced test developers, allowing for easy and natural testing with fewer errors. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with actions involving interaction with screen locations using HID messages based on device screen.
Regarding claim 12, the rejection of claim 11 is incorporated; and Torma further discloses:
- transmitting a configuration request to the device under test (Paragraph [0087], “A user can base workflow direction on action or workflow element output, questions to operator or values gathered from the device under test, for example, serial number, model type operating system [transmitting a configuration request to the device under test]”) [Examiner’s remarks: The apparatus transmits (gathers) a configuration request for the device under test.];
- receiving configuration data from the device under test in response to the configuration request (Paragraph [0087], “A user can base workflow direction on action or workflow element output, questions to operator or values gathered from the device under test, for example, serial number, model type operating system [receiving configuration data from the device under test in response to the configuration request]”) [Examiner’s remarks: The apparatus receives configuration information from the device under test.]; and
- determining the workflow data for the device under test based on the configuration data (Paragraph [0087], “A user can base workflow direction on action or workflow element output, questions to operator or values gathered from the device under test, for example, serial number, model type operating system [determine the workflow data for the device under test based on the configuration data]”) [Examiner’s remarks: The workflow data (workflow direction) is determined by the configuration data.].
Regarding claim 13, the rejection of claim 11 is incorporated; and Torma does not explicitly disclose:
- transmitting firmware update messages to the device under test, each firmware update message comprising a portion of executable instructions characterizing firmware;
- determining the device under test has restarted; and
- transmitting the plurality of HID actions to the device under test based on determining the device under test has restarted.
However, Mathews discloses:
- transmitting firmware update messages to the device under test, each firmware update message comprising a portion of executable instructions characterizing firmware (Column 4, lines 21-26, “Each client controller 36 may also periodically install current software builds on its client system 32, periodically reboot its client system 32, and establish communication with test server engine 24 when its client system 32 boots up, as described below [transmitting firmware update messages to the device under test, each firmware update message comprising a portion of executable instructions characterizing firmware]”);
- determining the device under test has restarted (Column 3, lines 7-19, “In certain embodiment, each client controller may carry out a reboot of its test execution computer at one or more appropriate times (e.g., twice a day) to help ensure that the test execution computer is less likely to “hang up” due to operating system instabilities…In certain embodiments, the client controller of each test execution computer is set up to automatically start software code that established communication with the test server engine when its test execution computer boots up [determining the device under test has restarted]”); and
- transmitting the plurality of HID actions to the device under test based on determining the device under test has restarted (Column 3, lines 7-19, “In certain embodiment, each client controller may carry out a reboot of its test execution computer at one or more appropriate times (e.g., twice a day) to help ensure that the test execution computer is less likely to “hang up” due to operating system instabilities…In certain embodiments, the client controller of each test execution computer is set up to automatically start software code that established communication with the test server engine when its test execution computer boots up [transmitting the plurality of HID actions to the device under test based on determining the device under test has restarted]”).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mathews into the teachings of Torma to include “transmitting firmware update messages to the device under test, each firmware update message comprising a portion of executable instructions characterizing firmware”, “determining the device under test has restarted”, and “transmitting the plurality of HID actions to the device under test based on determining the device under test has restarted”. As stated in Mathews, “The GUI is often the principal or only mechanism by which a user can provide input to and receive output from the software application with which the GUI is associated. It is therefore essential that the GUI operate correctly and efficiently for the successful operation of the associated software application…” (Column 1, lines 14-19). Testing of user interfaces is essential for ensuring that users are able to properly interact with the associated software. However, human testing of user interfaces is inefficient and may be inconsistent. Testing should be done one recent versions of software to ensure that software works Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with updating and restarting of devices.
Regarding claim 14, the rejection of claim 11 is incorporated; and Torma does not explicitly disclose:
- determining the device under test has restarted; and
- transmitting debug messages to the device under test to install a testing application.
However, Mathews discloses:
- determining the device under test has restarted (Column 3, lines 7-19, “In certain embodiment, each client controller may carry out a reboot of its test execution computer at one or more appropriate times (e.g., twice a day) to help ensure that the test execution computer is less likely to “hang up” due to operating system instabilities…In certain embodiments, the client controller of each test execution computer is set up to automatically start software code that established communication with the test server engine when its test execution computer boots up [determining the device under test has restarted]”); and
- transmitting debug messages to the device under test to install a testing application (Column 4, lines 21-26, “Each client controller 36 may also periodically install current software builds on its client system 32, periodically reboot its client system 32, and establish communication with test server engine 24 when its client system 32 boots up, as described below [transmitting debug messages to the device under test to install a testing application]”).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mathews into the teachings of Torma to include “determining the device under test has restarted” and “transmitting debug messages to the device under test to install a testing application”. As stated in Mathews, “The GUI is often the principal or only mechanism by which a user can provide input to and receive output from the software application with which the GUI is associated. It is therefore essential that the GUI operate correctly and efficiently for the successful operation of the associated software application…” (Column 1, lines 14-19). Testing of user interfaces is essential for ensuring that users are able to properly interact with the associated software. However, human testing of user interfaces is inefficient and may be inconsistent. Automatically installing applications once device restarts allows for automation with less human input. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with automatic application installation.
Regarding claim 15, the rejection of claim 11 is incorporated; and the combination of Torma and Mathews does not explicitly disclose:
- wherein the plurality of HID action messages comprise a first HID action message to engage a location of a page of a native user interface, and wherein the first HID action message includes a pixel row location, a pixel column location, and a time to pause after transmitting the first HID action message.
However, Lloyd discloses:
- wherein the plurality of HID action messages comprise a first HID action message to engage a location of a page of a native user interface, and wherein the first HID action message includes a pixel row location, a pixel column location, and a time to pause after transmitting the first HID action message (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”; Paragraph [0058], “In embodiments, when the test script is replayed the first touch event is simulated on the device under test, and the second touch event is simulated next with a time delay between the two events corresponding to the timestamps of the two events. As discussed above, in embodiments, the timestamps in the test script corresponding to an event may be relative to previous touch events, the initiation of the recording, or a conditional statement”) [Examiner’s remarks: Each HID message includes a pixel location to tap, as well as a timestamp which may be used to delay sending of the next command.].
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Lloyd into the combined teachings of Torma and Mathews to include “wherein the plurality of HID action messages comprise a first HID action message to engage a location of a page of a native user interface, and wherein the first HID action message includes a pixel row location, a pixel column location, and a time to pause after transmitting the first HID action message”. As stated in Lloyd, “The method of recording touch events for later use as a test script is faster and requires less programming knowledge, compared to manually writing a test script. This is beneficial if a new test script is needed quickly because a technician can perform a desired touch sequence on a device recording the sequence and then distribute the recorded sequence to be played on a plurality of devices to be tested” (Abstract). Screen recording touchscreen events in the form of pixel coordinates based on device type allows for quick testing and development of devices under test, as well as easy test development for less experienced test developers, allowing for easy and natural testing with fewer errors. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with actions involving interaction with screen locations using HID messages based on device screen.
Claims 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190095126 A1 (hereinafter “Torma”) in view of US 7055137 B2 (hereinafter “Mathews”), further in view of US 20170262130 A1 (hereinafter “Lloyd”), further in view of US 10158553 B2 (hereinafter “Tiwari”).
Regarding claim 16, Torma discloses:
a testing computing device communicatively coupled to each of the devices under test, via a physical communication interface (Paragraph [0021], “The further apparatus may be connectable (e.g. via wired or wireless connection) to the device that is to be subject of the desired erasure procedure and/or the desired diagnostic procedure [a testing computing device communicatively coupled to each of the devices under test, via a physical communication interface]”);
wherein the testing computing device is configured to:
- receive, from a remote database, workflow data for each of the devices under test (Paragraph [0070], “… cause the test station 20 to retrieve workflow or action data from the server 40 and perform actions represented by the workflow or action data, for example, by the workflow illustrated in FIG. 2 [receive, from a remote database, workflow data for the device under test]”)…
- transmit the corresponding plurality of HID action messages to each of the devices under test to cause each device under test to automatically perform configuration operations (Paragraph [0070], “… cause the test station 20 to retrieve workflow or action data from the server 40 and perform actions represented by the workflow or action data, for example, by the workflow illustrated in FIG. 2 [transmit the corresponding plurality of action messages to each of the devices under test to cause each device under test to automatically perform configuration operations]”) [Examiner’s remarks: Actions represented by the workflow are performed upon transmission to the device]…
Torma does not explicitly disclose:
A testing system for automatically configuring a plurality of devices under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the testing system comprising:
a testing frame comprising a plurality of isolated cabinets, each of the plurality of cabinets housing a respective device under test and associated communication hardware; and
…
- … the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to each detected device type and software verison;
- generate, for each of the devices under test, a plurality of HID action messages based on the corresponding workflow data, each HID action message comprising:
- at least one screen coordinate corresponding to a location of a native user interface element of the respective device under test, and
- a timing parameter defining a pause interval after execution of the HID action: and
- being configured to be interpreted by the corresponding device under test as a physical touchscreen or input device interaction; and
- …by navigating a native user interface of the respective device under test.
However, Mathews discloses:
A testing system for automatically configuring a plurality of devices under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the testing system comprising (Column 1, lines 41-50, “In one embodiment of the present invention, a method for distributed automated software graphical user interface (GUI) testing includes maintaining a centralized test queue, which stores multiple software GUI test instances to be executed by multiple distributed test execution computers. Each distributed test execution computer includes a client platform and is connected to one or more server platforms. The client platforms and server platforms collectively provide multiple client-server combinations against which the software GUI test instances may be executed”; Column 4, lines 52-64, “Although WINRUNNER is primarily described, any software capable of providing an appropriate environment for automated software GUI testing may be used. WINRUNNER code permits automation of software GUI testing by allowing customized programs to be created to control the flow of information to and from the software GUI being tested, in other words, to simulate interactions with software GUI users. For example, software GUI tests may simulate keyboard strokes, mouse clicks, or other methods of providing input to the GUI, reading associated data from the GUI, and returning results of processing that data to the GUI [A testing system for automatically configuring a plurality of devices under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the testing system comprising]”):
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mathews into the teachings of Torma to include “A testing system for automatically configuring a plurality of devices under test by transmitting human interface device (HID) actions that initiate user interface interactions without human input, the testing system comprising”. As stated in Mathews, “The GUI is often the principal or only mechanism by which a user can provide input to and receive output from the software application with which the GUI is associated. It is therefore essential that the GUI operate correctly and efficiently for the successful operation of the associated software application…” (Column 1, lines 14-19). Testing of user interfaces is essential for ensuring that users are able to properly interact with the associated software. However, human testing of user interfaces is inefficient and may be inconsistent. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with testing of user interfaces.
The combination of Torma and Mathews does not explicitly disclose:
a testing frame comprising a plurality of isolated cabinets, each of the plurality of cabinets housing a respective device under test and associated communication hardware; and
…
- … the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to each detected device type and software verison;
- generate, for each of the devices under test, a plurality of HID action messages based on the corresponding workflow data, each HID action message comprising:
- at least one screen coordinate corresponding to a location of a native user interface element of the respective device under test, and
- a timing parameter defining a pause interval after execution of the HID action: and
- being configured to be interpreted by the corresponding device under test as a physical touchscreen or input device interaction; and
- …by navigating a native user interface of the respective device under test.
However, Lloyd discloses:
- …the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to each detected device type and software version (Paragraph [0006], “Further, different test scripts need to be written for different devices, for example due to different screen sizes, different versions of an operating system or application, or different arrangement of icons. Therefore, developing similar tests for a plurality of similar, but not identical devices, is very time intensive as each device requires a new test script to be written. Therefore, there is a need to simplify the process of creating a test script for a device so that it will be less time intensive for creating a single test script, as well as multiple similar test scripts for a plurality of different devices [the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to each detected device type and software version]”) [Examiner’s remarks: Different workflows comprising navigation commands are generated based on different device types and application/operating system versions.];
- generate, for each of the devices under test, a plurality of HID action messages based on the corresponding workflow data, each HID action message comprising (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”) [Examiner’s remarks: A plurality of HID actions are based on the workflow data.]:
- at least one screen coordinate corresponding to a location of a native user interface element of the respective device under test (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”) [Examiner’s remarks: Each coordinate represents a location on the given user interface of a touchscreen of the device under test.], and
- a timing parameter defining a pause interval after execution of the HID action (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”; Paragraph [0058], “In embodiments, when the test script is replayed the first touch event is simulated on the device under test, and the second touch event is simulated next with a time delay between the two events corresponding to the timestamps of the two events. As discussed above, in embodiments, the timestamps in the test script corresponding to an event may be relative to previous touch events, the initiation of the recording, or a conditional statement”); and
- being configured to be interpreted by the corresponding device under test as a physical touchscreen or input device interaction (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”; Paragraph [0058], “In embodiments, when the test script is replayed the first touch event is simulated on the device under test, and the second touch event is simulated next with a time delay between the two events corresponding to the timestamps of the two events. As discussed above, in embodiments, the timestamps in the test script corresponding to an event may be relative to previous touch events, the initiation of the recording, or a conditional statement”) [Examiner’s remarks: Each HID message contains a timestamp indicating the time that should be waited for after each tap based on a screen recording. Each coordinate represents a location on a touchscreen.]; and
- …by navigating a native user interface of the respective device under test (Paragraphs [0041]-[0046], “In this example, the first coordinate is a pixel column and the second a pixel row, with the origin in the bottom left corner of the display. The coordinate system is selected for illustrative purposes, not based on any particular touchscreen.
1: Tap (100, 120); time 0:00.00
2: Tap (80, 426); time 0:01.50
3: Tap (118, 563); time 0:02.25
4: Tap (123, 560); time 0:02.45
5: Tap (310, 100); time 0:02.80”).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Lloyd into the combined teachings of Torma and Mathews to include “the workflow data comprising a predefined sequence of interface navigation commands formatted as HID action messages specific to each detected device type and software version”, “generate, for each of the devices under test, a plurality of HID action messages based on the corresponding workflow data, each HID action message comprising: at least one screen coordinate corresponding to a location of a native user interface element of the respective device under test, and a timing parameter defining a pause interval after execution of the HID action: and being configured to be interpreted by the corresponding device under test as a physical touchscreen or input device interaction”, and “… by navigating a native user interface of the respective device under test”. As stated in Lloyd, “The method of recording touch events for later use as a test script is faster and requires less programming knowledge, compared to manually writing a test script. This is beneficial if a new test script is needed quickly because a technician can perform a desired touch sequence on a device recording the sequence and then distribute the recorded sequence to be played on a plurality of devices to be tested” (Abstract). Screen recording touchscreen events in the form of pixel coordinates based on device type allows for quick testing and development of devices under test, as well as easy test development for less experienced test developers, allowing for easy and natural testing with fewer errors. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with actions involving interaction with screen locations using HID messages based on device screen.
The combination of Torma, Mathews, and Lloyd does not explicitly disclose:
a testing frame comprising a plurality of isolated cabinets, each of the plurality of cabinets housing a respective device under test and associated communication hardware; and
However, Tiwari discloses:
a testing frame comprising a plurality of isolated cabinets, each of the plurality of cabinets housing a respective device under test and associated communication hardware (Column 2, lines 2-17, “The system may include a master test system and a plurality of slave test systems coupled to the master test system and/or each other using Radio Frequency (RF) coaxial cables and/or other couplers. The system may include devices under tests (DUTs) (interchangeably referred to herein as units under test (UUTs)) stored in test slots and coupled to the master test system or specific slave test systems over Ethernet, coaxial, or other cables. Each test slot may be surrounded by a Faraday cage that shields the contents therein from electromagnetic signals outside the test slot”; Column 16, lines 45-49, “It will be appreciated that the master test system 752, the master-to-device interface 770, and the master test slots 756 may be mounted onto a single rack. Similarly, each slave test system 754, slave-to-device interface 772, and slave test slots 758 may be mounted on a single rack”); and
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Tiwari into the combined teachings of Torma, Mathews, and Lloyd to include “a testing frame comprising a plurality of isolated cabinets, each of the plurality of cabinets housing a respective device under test and associated communication hardware”. As stated in Tiwari, “As test procedures often require in-depth assessments and/or evaluations, it may be difficult to test several electronic devices at the same time” (Column 1, lines 61-63). Testing under a variety of conditions may be difficult. Having isolated cabinets with controlled conditions for a variety of devices allows for easier and more controlled testing. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with test cabinets.
Regarding claim 17, the rejection of claim 16 is incorporated and Torma further discloses:
- transmit a configuration request to…device under test (Paragraph [0087], “A user can base workflow direction on action or workflow element output, questions to operator or values gathered from the device under test, for example, serial number, model type operating system [transmit a configuration request to the device under test]”) [Examiner’s remarks: The apparatus transmits (gathers) a configuration request for the device under test.];
- receive configuration data from…device under test in response to the configuration request (Paragraph [0087], “A user can base workflow direction on action or workflow element output, questions to operator or values gathered from the device under test, for example, serial number, model type operating system [receive configuration data from the device under test in response to the configuration request]”) [Examiner’s remarks: The apparatus receives configuration information from the device under test.]; and
- determine the workflow data for … device under test based on the configuration data (Paragraph [0087], “A user can base workflow direction on action or workflow element output, questions to operator or values gathered from the device under test, for example, serial number, model type operating system [determine the workflow data for the device under test based on the configuration data]”) [Examiner’s remarks: The workflow data (workflow direction) is determined by the configuration data.].
Torma discloses the above limitations for a device under test. The combination of Torma, Mathews, and Lloyd does not explicitly disclose performing the above limitations for each device under test. However, Tiwari discloses each device under test (Column 2, lines 22-26, “the test systems may include test probe containers that virtualize the test probes and/or configure the test probes to execute portions of specific tests on DUTs. The test systems may test the DUTs using specific sequences of tests according to testing protocols relevant to those DUTs”) [Examiner’s remarks: Torma discloses performing the set of actions on one device under test. Tiwari discloses performing sequences of tests on multiple devices under test. One of ordinary skill in the art may extend the method performed on a single DUT with testing on multiple devices.].
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Tiwari into the combined teachings of Torma, Mathews, and Lloyd to include “each device under test”. As stated in Tiwari, “As test procedures often require in-depth assessments and/or evaluations, it may be difficult to test several electronic devices at the same time” (Column 1, lines 61-63). Testing under a variety of conditions may be difficult. Testing multiple devices in parallel allows for device testing to completed in shorter amounts to time, which speeds up the development cycle. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with simultaneous testing of multiple devices.
Regarding claim 18, the rejection of claim 16 is incorporated; and Torma does not explicitly disclose:
- wherein the testing computing device is configured to simultaneously communicate with each of the devices under test.
However, Mathews discloses:
- wherein the testing computing device is configured to simultaneously communicate with each of the devices under test (Column 3, lines 54-60, “In general, test server engine 24 receives requests for test instances from multiple distributed test execution computers, retrieves the requested test instances from test queue 28, submits the retrieves test instances for execution in parallel on multiple distributed test execution computers, receives test results… [wherein the testing computing device is configured to simultaneously communicate with each of the devices under test]”).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mathews into the teachings of Torma to include “wherein the testing computing device is configured to simultaneously communicate with each of the devices under test”. As stated in Mathews, “The GUI is often the principal or only mechanism by which a user can provide input to and receive output from the software application with which the GUI is associated. It is therefore essential that the GUI operate correctly and efficiently for the successful operation of the associated software application…” (Column 1, lines 14-19). Testing of user interfaces is essential for ensuring that users are able to properly interact with the associated software. However, human testing of user interfaces is inefficient and may be inconsistent, especially accounting for adequate code and platform coverage. Automating simultaneous testing across many devices allows for faster and more in-depth testing. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with simultaneous communication between multiple test devices.
Regarding claim 19, the rejection of claim 18 is incorporated; and Torma does not explicitly disclose:
- where each of the devices under test comprise a first device under test and a second device under test, wherein the first device under test is of a first device type, and the second device under test is of a second device type, the first device type different than the second device type.
However, Mathews discloses:
- where each of the devices under test comprise a first device under test and a second device under test, wherein the first device under test is of a first device type, and the second device under test is of a second device type, the first device type different than the second device type (Column 4, lines 29-39, “For example, suitable client platforms for software GUI testing might include, without limitation, WINDOWS NT, WINDOWS 2000, WINDOWS 98, WINDOWS ME, WINDOWS XP, UNIX, and DOS…Client systems 32 and the server systems 24 with which they are associated are preferably selected to provide a complete range of testing scenarios, across all appropriate client-server combinations, to help ensure thorough software GUI testing [where each of the devices under test comprise a first device under test and a second device under test, wherein the first device under test is of a first device type, and the second device under test is of a second device type, and the first device type is different than the second device type]”).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mathews into the teachings of Torma to include “where each of the devices under test comprise a first device under test and a second device under test, wherein the first device under test is of a first device type, and the second device under test is of a second device type, the first device type different than the second device type”. As stated in Mathews, “The GUI is often the principal or only mechanism by which a user can provide input to and receive output from the software application with which the GUI is associated. It is therefore essential that the GUI operate correctly and efficiently for the successful operation of the associated software application…” (Column 1, lines 14-19). Testing of user interfaces is essential for ensuring that users are able to properly interact with the associated software. However, human testing of user interfaces is inefficient and may be inconsistent, especially accounting for adequate code and platform coverage. Automating simultaneous testing across many devices allows for faster and more in-depth testing. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with simultaneous testing of multiple device types.
Regarding claim 20, the rejection of claim 16 is incorporated; and Torma does not explicitly disclose:
- wherein each of the devices under test perform the one or more configuration operations independently from each other.
However, Mathews discloses:
- wherein each of the devices under test perform the one or more configuration operations independently from each other (Column 3, lines 54-60, “In general, test server engine 24 receives requests for test instances from multiple distributed test execution computers, retrieves the requested test instances from test queue 28, submits the retrieves test instances for execution in parallel on multiple distributed test execution computers, receives test results… [wherein each of the devices under test perform the one or more configuration operations independently from each other]”).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Mathews into the teachings of Torma to include “wherein each of the devices under test perform the one or more configuration operations independently from each other”. As stated in Mathews, “The GUI is often the principal or only mechanism by which a user can provide input to and receive output from the software application with which the GUI is associated. It is therefore essential that the GUI operate correctly and efficiently for the successful operation of the associated software application…” (Column 1, lines 14-19). Testing of user interfaces is essential for ensuring that users are able to properly interact with the associated software. However, human testing of user interfaces is inefficient and may be inconsistent, especially accounting for adequate code and platform coverage. Automating simultaneous testing across many devices allows for faster and more in-depth testing. Thus, it would be obvious to one of ordinary skill in the art to combine automatic device testing with independent execution across different devices.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argues:
III. No Motivation to Combine the Cited References
The Office Action has not provided a sufficient rationale for combining the cited references. The proposed combination appears to be based on hindsight reconstruction rather than a teaching, suggestion, or motivation (TSM) found in the prior art.
Torma and Mathews operate in distinct domains-device diagnostics and distributed software testing, respectively. There is no indication that one of ordinary skill in the art would be motivated to combine these references to achieve the claimed HID-based configuration system.
Parker's GUI testing system is fundamentally different in scope and application. It does not address the problem solved by the claimed invention-automated configuration of physical DUTs via native UI traversal.
Tiwari adds further complexity without contributing any relevant teaching toward HID messaging or UI traversal.
Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), a proper obviousness rejection must be supported by a reasoned explanation of why one of ordinary skill would combine the references in the manner proposed. The Office Action fails to provide such an explanation, and the combination lacks the requisite motivation and reasonable expectation of success.
Examiner’s Response:
Examiner respectfully disagrees. In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
Torma and Mathews both provide pertinent art to the act of sending instructions to interact with a given device under test in the form of messages to perform certain actions. Parker has been replaced by Lloyd in the current 35 U.S.C. 103 rejection. Tiwari is used to teach the use of a testing frame with multiple isolated devices under test as is claimed in claim 16 and 17. It is used to teach a well known method for coordinating tests on multiple DUTs, and thus is reasonably pertinent to inventor’s problem and does not add an irrelevant teaching.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached 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, Wei Y Mui can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/V.W.D./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191