Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. This office action has been issued in response to a reply filed on 06/19/2026. Claim 15 has been amended. Claims 16-20 have been added.
Applicants' arguments on 103 rejection on claims 1-15 have been carefully and respectfully considered and found not persuasive. Accordingly, this action has been made FINAL
New claims 16-20 have been rejected with a new prior art.
Status of Claims
3. Claims 1-20 are pending, of which claims, of which claim 1, 14 and 15 are in independent form.
The Office's Note:
4. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
5. Claims 1-15 are rejected under 35 U.S.C. 103 as being unpatentable over Konyshev (US 20200242017– hereinafter Konyshev), in view of Jakubiak (US 20210311862– hereinafter Jakubiak) and further in view of Holmes (“Practical UI Test Automation – Locators and Asynchronous Loading – hereinafter Holmes – IDS of records).
Claim 1 rejected, Konyshev teaches a computer-implemented method for maintaining an object repository file for use in automation testing of a web application, the object repository file containing object locators for elements of the web application, the method comprising (Konyshev, US 20200242017, abstract and summary):
generating a current instance of an identifier and a current instance of an object locator, for an element of the web application, based on a current version of the web application (Konyshev, fig. 2 and para [0037], The system 200 can correspond to the system 100 of FIG. 1, or other suitable software testing system. In particular, the system 200 includes an automation engine 202, a testing tool 204 configured to execute a test script 206 to validate proper operation of a test application 208. The testing tool 204 can locate a test element of the application based at least in part on a first element request specified in the test script 206. The first element request can include a suitable locator for the test element. The testing tool 204 can locate the test element from the application 208 based at least in part on the first element request, and can perform any suitable testing operations on the test element as specified in the test script 206. Such testing operations can be associated with a first (initial) test pass. The testing tool can further provide data indicative of the test element to the automation engine 202. The automation engine 202 can generate a signature for the test element (e.g. test element signature). In particular, the test element signature can include attributes descriptive of the test element. In some implementations, the attributes can be different than the attribute used in the initial locator for the test element. In some implementations, the attributes can be attributes that are unlikely to change in response to an update of the application 208. In this manner, the test element signature can include attributes descriptive of the test element, such as a location attribute, address attribute, style attribute, size attribute, name attribute, or ID attribute, and/or other suitable attributes. The test element signature can be stored as signature data 116, for instance, in a suitable memory associated with the automation engine 102.) ;
locating the current instance of the object locator in historical data generated based on a historical version of the web application, the historical data comprising historical instances of object locators and historical instances of identifiers, for the elements of the web application (Konyshev, fig. 2 and para [0039-0040], A second test pass can be implemented after the performance of the testing operations associated with the first test pass. In some implementations, the second test pass can be a subsequent iteration of the first test pass, and can include the same testing operations to be performed on the test element. In this manner, the test script can include a second element request. The second locate element request can be a request for the test element, and can use the same locator as used in the first element request. However, it will be appreciated that the second locate element request can use a different locator than the first locate element request. In some implementations, the automation engine 202 can generate an updated locator to identify the test element based at least in part on the test element signature. In particular, the updated locator can include data indicative of various suitable attributes as specified in the test element signature, and can be compatible with the testing tool 204 and application 208. Upon generating the updated locator, the automation engine 202 can provide the updated locator to the testing tool 204. The testing tool 204 can locate and identify one or more candidate elements from the application 208 based at least in part on the updated locator.);
if the current instance of the object locator is not found in the historical data, locating the current instance of the identifier in the historical data (Konyshev, fig. 4 and para [0057], at (404), the method (400) can include identifying candidate elements in the software application. The candidate elements can include at least a subset of the elements of the software application. For instance, in some implementations, identifying the candidate elements can include identifying each candidate element in the software application, such that each element is a candidate element. In some implementations, identifying the candidate elements can include identifying candidates based at least in part on the attributes of the elements of the software application. For instance, in such implementations, as will be described in greater detail with respect to FIG. 6, identifying the candidate elements can include assigning an element having the same DOM tree address as the test element as a candidate element, and/or assigning an element having the same ID as the test element as a candidate element. As another example, identifying the candidate element(s) can include assigning each element of the same type as the test element (e.g. text field, button, etc.) as a candidate element. In this manner, candidate element(s) can be identified based at least in part on the test element signature, and can be located in the application using suitable locators that specify the appropriate attributes.); and
if the current instance of the identifier is found in the historical data,
updating historical attributes data of the element with current attributes data of the element extracted from the current version of the web application; generating a new instance of the object locator for the element based on the updated attributes data of the element; and updating the object repository file using the new instance of the object locator for the element (Konyshev, para [0039-0041], Upon identifying the candidate elements, the automation engine 202 can compare the candidate elements to the test element to determine which candidate element matches the test element. In some implementations, the automation engine 202 can generate signatures for the candidate elements (candidate element signature(s)). The candidate element signatures can be generated in the same manner as the test element signature (e.g. based at least in part on the HTML representation), and can include the same or similar attributes as the test element. The candidate element signatures can be stored as signature data 116. As will be described in more detail below with respect to FIGS. 5-8, the automation engine 202 can perform the comparison between the candidate elements and the test element using various suitable comparison techniques. The automation engine 202 can perform the comparison based on various suitable attributes of the test element and the candidate elements. In some implementations, the automation engine 202 can compare the candidate element signature(s) to the test element signature. In some implementations, the automation engine 202 can determine an exact match between the test element signature and a candidate element signature based on the comparison. In some implementations, the automation engine 202 can determine a transformation distance between the test element signature and the candidate element signature(s) based on the comparison. The transformation distance can specify a difference in the attributes between the test element signatures and a candidate element signature. In some implementations, the comparison can be performed using a neural network or other machine learning model. For instance, the comparison can be performed by providing data indicative of the test element signature and the candidate element signatures (or other suitable data indicative of the test element and candidate elements) as input to the neural network that is configured to output a match result indicating whether a candidate element matches the test element. Fig. 5 and para [0058-0059], Para [0058], At (406), the method (400) can include generating signatures for each candidate element. The signatures can be generated in the same manner as the test element signature, and can include the same attributes as the test element signature, such that the candidate element signature(s) can be compared to the test element signature. In some implementations, a second HTML representation can be generated prior to generating the candidate element signature(s), such that the second HTML representation reflects any updates to the software application and/or the elements of the software application.).
The Office would like to use prior art Jakubiak to back up Konyshev to further teach limitation
generating a new instance of the object locator for the element based on the updated attributes data of the element(Jakubiak, US 20210311862, fig. 4 and para [0068-0069], For a given command 402, for example a findElement command, within a test being analyzed, the DOM Element Search Engine 406 finds the page element within the DOM that was stored when the command was executed in the test run under analysis. This page element is referred to as the candidate element, or identified DOM element 408. Once the candidate element is identified, the Locator Creation Engine 412 creates a set of locators by analyzing the page element and the associated DOM structure of the page wherein it exists. It creates a new set of locators that would successfully locate the element within the given DOM structure. Locator Creation Engine 412 also calculates a score for each locator that was created to produce a scored list of locators 414. This score can be used by a human, a machine learning engine, or the self-healing capabilities of the disclosure to determine the best locator to use in place of an existing locator.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Jakubiak into Konyshev to reduce the amount of time spent on maintaining failing tests and increases the accuracy of the tests by capturing data about the steps taken by the test and the state of the application at each step and utilizing historical data and the current state of application to determine new element locators that may be used in the test. as suggested by Jakubiak (See abstract and summary).
The Office would like to use prior art Holmes to back up Konyshev and Jakubiak to further teach limitation
generating a current instance of an identifier and a current instance of an object locator, for an element of the web application, based on a current version of the web application(Holmes, page 9, section Combining Strategies, In this case I can use that element’s ID and a short XPath to nail down the element I need.)
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Holmes into Konyshev and Jakubiak to start building smart, robust test harnesses as suggested by Holmes (See abstract and summary).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Konyshev, Jakubiak and Holmes teach the computer-implemented method of claim 1, wherein the identifier is configured to provide an invariant reference of a position of the element in a source code of the web application (Konyshev, fig. 9 and para [0087], At (726), the method (720) can include generating a signature for the user interface element based at least in part on the HTML representation. The signature can be generated in accordance with example aspects of the present disclosure. For instance, the signature can include a current position or address of the user interface element as displayed in the user interface of the application. The current position or address can be specified in the HTML and/or CSS representation.).
Claim 3 is rejected for the reasons set forth hereinabove for claim 1, Konyshev, Jakubiak and Holmes teach the computer-implemented method of any of claim 1, wherein the object locator for the element provides a pointer for uniquely locating the element in a source code of the web application (Jakubiak, para [0034-0035], In the example above, the username and password fields are located using the “name” location strategy (By.name(“username”) and By.name(“password”)), the first button is located using the “CSS selector” location strategy (By.cssSelector(“.button:nth-child(1)”)), and the log out button is located using the “Link text” location strategy (By.linkText(“Log Out”)). The combination of location strategy and value for which to search is often called an “element locator”. The element locator is used in conjunction with the commands of UI automation applications, for example, the Selenium™ command driver findElement (by) to locate the elements. See, for instance, https://blog.thedigitalgroup.com/locator-strategies-in-selenium-webdriver, for examples of different common strategies for locating elements. Para [0036-0037]. Para [0061-0063], An absolute XPath to the page element that was found using the element locator within the DOM structure of the page. Para [0093-0094].).
Claim 4 is rejected for the reasons set forth hereinabove for claim 1, Konyshev, Jakubiak and Holmes teach the computer-implemented method of any of claim 1,further comprising, if the current instance of the object locator is found in the historical data: comparing the current instance of the identifier with a historical instance of the identifier in the historical data; and if different, replacing, in the historical data, the historical instance of the identifier with the current instance of the identifier(Jakubiak, para [0024-0025], Embodiments solve this problem by identifying elements to be tested as specified by a software test script after the software application is updated in a manner that changes an element attribute used to locate the corresponding test element. For instance, a signature can be generated for an element of an application upon which testing operations are to be performed. The signature can include one or more attributes descriptive of the element. The application may be updated, changing the element and its attributes. After the update, elements in the updated application can be selected as candidates to match elements in the prior version of the application. New signatures can be generated for the candidate elements in the updated application. Each candidate element signature can include attributes descriptive of the candidate element. The candidate element signatures can be compared to the initial element signature to determine whether the element matches the candidate element. By comparing the signatures in this way, the element can be identified after the update of the application. This enables further testing operations to be performed on the element of the updated application using the preexisting test script.).
Claim 5 is rejected for the reasons set forth hereinabove for claim 1, Konyshev, Jakubiak and Holmes teach the computer-implemented method of claim 1,further comprising, if the current instance of the object locator and the current instance of the identifier are both not found in the historical data: identifying the element associated with the object locator and the identifier as a new element of the web application; and storing the current instance of the object locator and the current instance of the identifier, in the historical data, in association with the new element (Jakubiak, para [0024-0025], Embodiments solve this problem by identifying elements to be tested as specified by a software test script after the software application is updated in a manner that changes an element attribute used to locate the corresponding test element. For instance, a signature can be generated for an element of an application upon which testing operations are to be performed. The signature can include one or more attributes descriptive of the element. The application may be updated, changing the element and its attributes. After the update, elements in the updated application can be selected as candidates to match elements in the prior version of the application. New signatures can be generated for the candidate elements in the updated application. Each candidate element signature can include attributes descriptive of the candidate element. The candidate element signatures can be compared to the initial element signature to determine whether the element matches the candidate element. By comparing the signatures in this way, the element can be identified after the update of the application. This enables further testing operations to be performed on the element of the updated application using the preexisting test script.) .
Claim 6 is rejected for the reasons set forth hereinabove for claim 1, Konyshev, Jakubiak and Holmes teach the computer-implemented method ofclaim 1,further comprising:
opening a uniform resource identifier for the current version of the web application in a web browser (Jakubiak, para [0046], a web application and UI application);
parsing a source code of the current version of the web application into a Document Object Model (DOM) tree structure (Jakubiak, para [0046], Although, a web application is used here as an example, one skilled in the art would recognize that the present disclosure applies to all types of UI applications, as long as a Document Object Model (DOM) representation of a UI can be captured and a test framework exists that uses locators based on that UI representation.); and
extracting the current attributes data of the element from the DOM tree structure (Jakubiak, fig. 6 and fig. 7 and para [0080-0085], FIG. 6 illustrates an exemplary process flow for a DOM matching process, according to some embodiments of the disclosed invention. As shown in block 602, the DOM element search engine first builds a model for the DOM structures associated with the findElement command in the historical test run and the findElement command in the current test run under analysis. In some embodiments, the model contains a node for each element in the DOM, and each node in the model contains relevant properties of the DOM element including its name and all attributes associated with it. ).
Claim 7 is rejected for the reasons set forth hereinabove for claim 6, Konyshev, Jakubiak and Holmes teach the computer-implemented method of claim 6, wherein the current attributes data of the element includes attribute-value pairs carried by the element in the source code of the current version of the web application, wherein generating the current instance of the object locator for the element comprises: whether a particular attribute-value pair from among the attribute-value pairs carried by the element provides uniqueness for the element in the source code of the current version of the web application; and if a particular attribute-value pair from among the attribute-value pairs carried by the element is determined to provide uniqueness for the element, forming the current instance of the object locator using the determined particular attribute-value pair (Jakubiak, para [0093-0095], In some embodiments, the locator creation engine creates a set of locators based on a given page element in a recorded DOM structure. Each locator produced by the locator creation engine is a different way of uniquely identifying that page element within its DOM. The locator creation engine contains locator creators that each attempt to create a specific type of locator, based on the type of the page element and properties contained by the element. Some examples include a locator creator that creates locators that search for links based on the text of the link, or a locator creator that creates locators that search for an element in a table cell based on the name of the column in which it resides and values in adjacent table cells. Some locator creators may produce more than one locator, each of which differs based on its location strategy (id, css selector, xpath, etc.) and/or whether it uses the entire value or partial value of a relevant element property on which it depends. However, a given locator creator may not always be able to create a locator for a given page element, since the locators it attempts to create may require properties that the page element or neighboring elements do not currently contain. Fig. 6 and para [0080-0081].).
Claim 8 is rejected for the reasons set forth hereinabove for claim 7, Konyshev, Jakubiak and Holmes teach the computer-implemented method of claim 7, wherein said determining further comprises: applying the current attributes data of the element to a classification model trained to predict, based on a tag name of the element, whether an attribute-value pair, from among the attribute-value pairs carried by the element, provides uniqueness for the element(Jakubiak, para [0093-0095]. Fig. 6 and para [0080-0081], FIG. 6 illustrates an exemplary process flow for a DOM matching process, according to some embodiments of the disclosed invention. As shown in block 602, the DOM element search engine first builds a model for the DOM structures associated with the findElement command in the historical test run and the findElement command in the current test run under analysis. In some embodiments, the model contains a node for each element in the DOM, and each node in the model contains relevant properties of the DOM element including its name and all attributes associated with it. The DOM element search engine then uses a model comparison process as shown in block 604, for example the open source Eclipse Modeling Framework™ (EMF) Compare library, to match nodes between the two models, by computing a similarity between nodes in each model based on their properties, and outputs the result as a match model where nodes are matched if their similarity score exceeds a certain threshold. In some embodiments, the DOM element search engine uses the open source EMF Compare library as the generic model comparison engine to define the models and compute the match model. As known in the art, the Eclipse Modeling Framework™ includes a generic comparison engine with the ability to export differences in a model patch.) .
Claim 9 is rejected for the reasons set forth hereinabove for claim 8, Konyshev, Jakubiak and Holmes teach the computer-implemented method of claim 8, wherein said determining further comprises: if the classification model successfully identifies an attribute-value pair that provides uniqueness for the element, verifying that the identified attribute-value pair provides uniqueness for the element by searching for the identified attribute-value pair in the source code of the current version of the web application(Jakubiak, para [0093-0095]. Fig. 6 and para [0080-0081], There are some cases where DOM elements are different enough that they do not get matched to each other by the model comparison process, however logically the DOM elements should be matched because all other DOM elements in their vicinity in the model are matched. In these cases, the DOM element search engine adjusts the match model to create matches between nodes in block 606.).
Claim 10 is rejected for the reasons set forth hereinabove for claim 7, Konyshev, Jakubiak and Holmes teach the computer-implemented method of claim 7,further comprising, if no attribute-value pair from among the attribute-value pairs carried by the element is determined to provide uniqueness for the element: determining whether a particular attribute-value pair from among the attribute-value pairs carried by a parent of the element in the DOM tree structure provides uniqueness for the parent of the element in the source code of the current version of the web application; and if a particular attribute-value pair from among the attribute-value pairs carried by the parent of the element is determined to provide uniqueness for the parent of the element, forming the current instance of the object locator using the determined particular attribute-value pair of the parent and the relative path from the parent of the element to the element in the DOM tree structure(Jakubiak, para [0093-0095]. Fig. 6 and para [0080-0081], There are some cases where DOM elements are different enough that they do not get matched to each other by the model comparison process, however logically the DOM elements should be matched because all other DOM elements in their vicinity in the model are matched. In these cases, the DOM element search engine adjusts the match model to create matches between nodes in block 606.).
Claim 11 is rejected for the reasons set forth hereinabove for claim 6, Konyshev, Jakubiak and Holmes teach the computer-implemented method of claim 6,wherein generating the current instance of the identifier for the element comprises forming a single string representation, based on the DOM tree structure, comprising: - a count of siblings of the element; - a tag name of the parent of the element; - an identifier attribute value of the parent of the element; - a name attribute value of the parent of the element; - a class attribute value of the parent of the element; - a count of siblings of the parent of the element; and - a count representing the order of the element in the DOM tree structure among elements having the same tag name (Jakubiak, para [0093-0095], A given locator creator may use different location strategies in the different locators that it produces. For example, the “id” locator creator may produce locators that use either the id, css selector, or xpath location strategies to locate an element by its id property. For each location strategy for which it produces locators, the locator creator creates a locator for the page element that it is given, using the exact value of one or more properties of that element and/or neighboring elements in the DOM structure. For the same location strategy some locator creators may in addition attempt to create optimized locators that use a unique substring of the properties on which the locator creator depends, based on values of those properties throughout the history of the test runs. For example, an element's id property may have values that differ for each test run, like this: “id_123”, “id_245”, “id_356”, etc. A locator based on id will not consistently find the element when it searches for the specific id “id_356”. But an optimized locator that searches for an id that starts with the text “id_” will consistently find the element regardless of the value of the id property. Fig. 6 and para [0080-0081], There are some cases where DOM elements are different enough that they do not get matched to each other by the model comparison process, however logically the DOM elements should be matched because all other DOM elements in their vicinity in the model are matched. In these cases, the DOM element search engine adjusts the match model to create matches between nodes in block 606.).
Claim 12 is rejected for the reasons set forth hereinabove for claim 1, Konyshev, Jakubiak and Holmes teach the computer-implemented method of claim 1,wherein comparing the current instance of the identifier with the historical instance of the identifier in the historical data comprises: generating a first word embedding based on the historical instance of the identifier; generating a second word embedding based on the current instance of the identifier; and calculating a cosine similarity between the first word embedding and the second word embedding (Jakubiak, para [0090], The command matching engine then uses a generic model comparison engine to match nodes between the two models by computing a similarity between nodes in each model based on the properties of the node. In block 806, the command matching engine outputs the result as a match model where nodes are matched when their similarity score exceeds a certain threshold. In some embodiments, the command matching engine uses the open-source EMF Compare library as the generic model comparison engine to define the models and compute the match model..
Claim 13 is rejected for the reasons set forth hereinabove for claim 1, Konyshev, Jakubiak and Holmes teach the computer-implemented method of claim 1,wherein updating the historical attributes data of the element with the current attributes data of the element comprises mapping the historical attributes data with the current attributes data to determine any modification, addition, or deletion of attributes of the element (Jakubiak, fig. 6 and fig. 7 and para [0080-0085], FIG. 6 illustrates an exemplary process flow for a DOM matching process, according to some embodiments of the disclosed invention. As shown in block 602, the DOM element search engine first builds a model for the DOM structures associated with the findElement command in the historical test run and the findElement command in the current test run under analysis. In some embodiments, the model contains a node for each element in the DOM, and each node in the model contains relevant properties of the DOM element including its name and all attributes associated with it. Para [0036], Once an element is found, the desired interaction is performed on it. In the example above, the sendKeys( ) and click( ) calls are the Selenium™ commands that perform the interactions of typing into a text field and clicking a button, respectively. In many cases, when the property or location of a page element changes, the tester determines how to update the element locator in the test to find the element based on the new state of the page element. But, when the property of a page element is dynamic in nature, the tester determines how to update the element locator to use static but uniquely identifying attributes of the element. Moreover, when wait conditions fail, the tester needs to identify how to modify the wait condition by changing the condition for which it is waiting, or by increasing the timeout. Fig. 5 and Para [0072], The DOM element search engine attempts to locate the element in the updated version of the page, to construct a different locator with which to find the element. ).
As per claim 14, this is the system claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 15, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above.
6. Claims 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Konyshev (US 20200242017– hereinafter Konyshev), in view of Jakubiak (US 20210311862– hereinafter Jakubiak), in view of Holmes (“Practical UI Test Automation – Locators and Asynchronous Loading – hereinafter Holmes – IDS of records) and further in view of Kumar (US 20210049234– hereinafter Kumar).
With respect to claim 16, Konyshev, Jakubiak and Holmes do not explicitly teach limitation of claim 16.
However, Kumar teaches
Claim 16 is rejected for the reasons set forth hereinabove for claim 1, Konyshev, Jakubiak, Holmes and Kumar teach the computer-implemented method of claim 1, wherein generating the current instance of the identifier comprises forming a representation based on a position of the element in a Document Object Model (DOM) tree structure of the web application (Kumar, US 20210049234, fig. 3B and para [0065-0066], In some embodiments, the web element rediscovery system comprises a CSS selector generating function 45, shown in FIG. 3B, configured to generate a CSS selector string capable of identifying the target element uniquely in the html page source code 101. The CSS selector generating function 45 traverses 35 a DOM tree corresponding to the html code, such as Dom tree 102 explained below. For each node or element within the DOM tree 102 the CSS selector generating function considers whether the target element has an ID that uniquely identifies the target element in the page source code 101. If so, it uses that ID as the CSS selector and returns at step 47. If not, then the function 45 considers, at 39, whether the target element has a class or tag value that uniquely identifies the target element in the page source code 101. If so, the function 45 uses that class or tag value as the CSS selector and returns at step 47. If not, then the function 45, considers, at 39 whether the target element has a class or tag value that uniquely identifies the current node/element' under its parent element, that is among the sibling nodes under the parent. For example, nodes 130, 132, 134, 136, 138, and 140 are all children of parent node 128 and siblings of each other. If there is a the target element has a class or tag value that uniquely identifies the current node/element under its parent element, then that tag or call value will be used to identify the target under its parent node, and another selector will be used to identify the parent node within the page source code 101, in the same manner as describe above. Else, an nth-child node selector can be used to select the n.sup.th child node of a given parent, where n is the number, such as a non-negative non-zero integer, that represents the position of the child relative to other sibling nodes under the parent node. For example, node 130 is the first node and would be the 1.sup.st-child under parent node 128. Node 132 is the second node under parent node 128 and would be the 2.sup.nd-child under parent node 128. The function 45 continues to build up a selector string via 37, 39, 41, and 43, until the css selector string is able to uniquely return the target element. This css selector string is returned at step 47 and stored in the css selector field 76 corresponding to the target element.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Kumar into Konyshev, Jakubiak and Holmes to identify element within target web page as changed web element as suggested by Kumar (See abstract and summary).
Claim 17 is rejected for the reasons set forth hereinabove for claim 17, Konyshev, Jakubiak, Holmes and Kumar teach the computer-implemented method of claim 16, wherein the representation includes at least one of: a count of siblings of the element, a tag name of a parent of the element, an attribute value of the parent of the element, or an order of the element among elements having a same tag name (Kumar, para [0065-0066], In some embodiments, the web element rediscovery system comprises a CSS selector generating function 45, shown in FIG. 3B, configured to generate a CSS selector string capable of identifying the target element uniquely in the html page source code 101. The CSS selector generating function 45 traverses 35 a DOM tree corresponding to the html code, such as Dom tree 102 explained below. For each node or element within the DOM tree 102 the CSS selector generating function considers whether the target element has an ID that uniquely identifies the target element in the page source code 101. If so, it uses that ID as the CSS selector and returns at step 47. If not, then the function 45 considers, at 39, whether the target element has a class or tag value that uniquely identifies the target element in the page source code 101. If so, the function 45 uses that class or tag value as the CSS selector and returns at step 47. If not, then the function 45, considers, at 39 whether the target element has a class or tag value that uniquely identifies the current node/element' under its parent element, that is among the sibling nodes under the parent. For example, nodes 130, 132, 134, 136, 138, and 140 are all children of parent node 128 and siblings of each other. If there is a the target element has a class or tag value that uniquely identifies the current node/element under its parent element, then that tag or call value will be used to identify the target under its parent node, and another selector will be used to identify the parent node within the page source code 101, in the same manner as describe above. Else, an nth-child node selector can be used to select the n.sup.th child node of a given parent, where n is the number, such as a non-negative non-zero integer, that represents the position of the child relative to other sibling nodes under the parent node. For example, node 130 is the first node and would be the 1.sup.st-child under parent node 128. Node 132 is the second node under parent node 128 and would be the 2.sup.nd-child under parent node 128. The function 45 continues to build up a selector string via 37, 39, 41, and 43, until the css selector string is able to uniquely return the target element. This css selector string is returned at step 47 and stored in the css selector field 76 corresponding to the target element.).
Claim 18 is rejected for the reasons set forth hereinabove for claim 16, Konyshev, Jakubiak, Holmes and Kumar teach the computer-implemented method of claim 16, wherein the identifier is an invariant identifier based on a structural position of the element in the Document Object Model (DOM) tree structure, such that the identifier remains unchanged upon modification of attribute values of the element (Kumar, para [0065-0066], In some embodiments, the web element rediscovery system comprises a CSS selector generating function 45, shown in FIG. 3B, configured to generate a CSS selector string capable of identifying the target element uniquely in the html page source code 101. The CSS selector generating function 45 traverses 35 a DOM tree corresponding to the html code, such as Dom tree 102 explained below. For each node or element within the DOM tree 102 the CSS selector generating function considers whether the target element has an ID that uniquely identifies the target element in the page source code 101. If so, it uses that ID as the CSS selector and returns at step 47. If not, then the function 45 considers, at 39, whether the target element has a class or tag value that uniquely identifies the target element in the page source code 101. If so, the function 45 uses that class or tag value as the CSS selector and returns at step 47. If not, then the function 45, considers, at 39 whether the target element has a class or tag value that uniquely identifies the current node/element' under its parent element, that is among the sibling nodes under the parent. For example, nodes 130, 132, 134, 136, 138, and 140 are all children of parent node 128 and siblings of each other. If there is a the target element has a class or tag value that uniquely identifies the current node/element under its parent element, then that tag or call value will be used to identify the target under its parent node, and another selector will be used to identify the parent node within the page source code 101, in the same manner as describe above. Else, an nth-child node selector can be used to select the n.sup.th child node of a given parent, where n is the number, such as a non-negative non-zero integer, that represents the position of the child relative to other sibling nodes under the parent node. For example, node 130 is the first node and would be the 1.sup.st-child under parent node 128. Node 132 is the second node under parent node 128 and would be the 2.sup.nd-child under parent node 128. The function 45 continues to build up a selector string via 37, 39, 41, and 43, until the css selector string is able to uniquely return the target element. This css selector string is returned at step 47 and stored in the css selector field 76 corresponding to the target element.).
Claim 19 is rejected for the reasons set forth hereinabove for claim 8, Konyshev, Jakubiak, Holmes and Kumar teach the computer-implemented method of claim 8, wherein generating the current instance of the object locator further comprises verifying that a selected attribute-value pair provides uniqueness for the element by searching for the selected attribute-value pair in a source code of the web application (Kumar, para [0049], In some embodiments, in Hypertext Markup Language (HTML), the name attribute identifies the name of the web element, the class attribute identifies the class associated with the web element and is often used with CSS (Cascading Style Sheets) to style elements with common properties, the ID attribute identifies a unique id for the HTML element, link text is the text displayed for a URL (Uniform Resource Locator) of a linked resource; xpath is a query language for selecting nodes from an XML document; and, a CSS selector is a pattern used to select the element(s) to be styled. HTML is a computer code or markup language for web pages, which may be displayed in a web browser. Para [0065-0066]. Para [0076-0079].).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Kumar into Konyshev, Jakubiak and Holmes to identify element within target web page as changed web element as suggested by Kumar (See abstract and summary).
Claim 20 is rejected for the reasons set forth hereinabove for claim 7, Konyshev, Jakubiak, Holmes and Kumar teach the computer-implemented method of claim 7, wherein, if no attribute-value pair of the element provides uniqueness, generating the current instance of the object locator comprises using an attribute-value pair of a parent element in the Document Object Model (DOM) tree structure together with a relative path from the parent element to the element (Kumar, para [0076-0079], The related locator based element rediscovery function 25 attempts to identify the sought web element that corresponds to the missing web element locator. The missing web element locator is “login100-form-btn” in this example, which corresponds to the login button at 59, 160. The function 25 will fir look other locators previously associated with the missing web element locator. In this case, those other locators are the locators saved in fields 62, 64, 66, 68, 70, 72, 74, 76, and 78. Therefore, if for example, the absolute Xpath of /html[1]/body[1]/div[1]/div[1]/div[1]/form[1]/div[3]/button[1] uniquely identifies the sought web element within the source code of the changed target web page, then the system will use /html[1]/body[1]/div[1]/div[1]/div[1]/form[1]/div[3]/button[1] as the new web element locator and will return that locator at steps 26 and 27 and 18. In some embodiments, rather than or in addition to returning the new web element locator, the function may also return the location in the target web page containing the sought web element.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Kumar into Konyshev, Jakubiak and Holmes to identify element within target web page as changed web element as suggested by Kumar (See abstract and summary).
Response to Argument
7A> On page 15-16, with respect to 101 rejection for claim 15 to add limitation “non-transitory”, claim 15 has been amended to overcome 101 rejection. Therefore, the 101 rejection for claim 15 has been withdrawn.
7B> On page 15-16, with respect to 101 rejection, abstract ideas, applicant arguments are persuasive. Therefore, the 101 rejection, abstract ideas, for claims 1-15 have been withdrawn.
7C> On page 15-16, with respect to independent claims 1, 14 and 15, applicant argued that “There is no teaching that would lead a person skilled in the art to check for a locator string in a database and, upon failure, check for an identifier string to trigger a repository update.”
The Office respectfully disagreed. On para [0009-0010], Jakubiak teaches “ a method for element locator recommendations for testing a User Interface (UI) application software by a test tool. The method includes: executing a plurality of tests by the test tool; monitoring tests as they are executed and observing which commands of the test tool are called by each test being executed to generate monitored data, wherein the monitored data includes which tests were executed, element locators that were used in the tests, relevant commands that were called by each test and related to the element locators that were used in the tests, and information about the UI application software during the test execution; storing the monitored data in a recorded data repository; analyzing the monitored data stored in the recorded data repository; producing a set of recommended element locators to be used by the test tool in place of previously used element locators for which the elements were not found during the execution of the tests; and utilizing the set of recommended element locators to complete the testing of the UI application software.” The Office notes that “storing the monitored data in a recorded data repository; analyzing the monitored data stored in the recorded data repository; producing a set of recommended element locators to be used by the test tool in place of previously used element locators for which the elements were not found during the execution of the tests; and utilizing the set of recommended element locators to complete the testing of the UI application software” which means “check for a locator string in a database and, upon failure, check for an identifier string to trigger a repository update.” Furthermore, Jakubiak teaches on para [0074], “ When the given findElement command in a test run under analysis is not successful, no page element was found using the element locator specified by the test. In this case, the DOM element search engine will attempt to use data stored in a recorded data repository to identify an element on the page that appears to be a modified form of the element the test was attempting to find, so that it can pass that element to the locator creation engine to create an alternate set of locators that will find the element.”, and on para [0076], Jakubiak teaches “When a recorded data repository contains stored data from a previous run of the same test, the DOM element search engine analyzes the stored data for the most recent run of the same test, as shown in block 506. The DOM element search engine uses a command matching engine to identify a findElement command in the test run that it selected that most closely matches the failing findElement command in the original test run being analyzed, as shown in block 508. In block 510, the DOM element search engine identifies whether the command matching engine was able to find a matching command. When it is unsuccessful, the DOM element search engine proceeds to determine whether the recorded data repository contains stored data for additional runs of the same test (block 504), and if so, it selects the next most recent run of the test for analysis (block 506) and the process repeats. The process repeats until a matching command is found in block 510, or there are no further test runs stored in the recorded data repository to analyze (block 514).” which means check for a locator string in a database and, upon failure, check for an identifier string to trigger a repository update.”
In conclusion, Konyshev, Jakubiak and Holmes teach all limitations of independent claims 1, 14 and 15.
7D> On page 17, with respect to independent claims 1, 14 and 15, applicant argued that “This is a fundamentally different algorithm for data management and repository maintenance, distinct from the live failure- recovery mechanisms of the cited prior art.”
In response to applicant's argument that the references fail to show certain features of applicant’s invention, it is noted that the features upon which applicant relies (i.e., “data management and repository maintenance”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
In conclusion, Konyshev, Jakubiak and Holmes teach all limitations of independent claims 1, 14 and 15.
Inquiry
8. THIS ACTION IS MADE FINAL. 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 DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached M-F 8 to 5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached on 5712723759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199
Prosecution Insights