DETAILED ACTION
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 .
Response to Amendment/Arguments
Applicant’s amendments/arguments filed on May 5, 2026 have been considered.
Applicant’s arguments with respect to claims 1, 11, and 19 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.
Claim 9 is amended to depend on 1.
Claims 14, and 22 are cancelled.
Claims 24, and 25 are new.
Claim Objections
Claim 25 is objected to because of the following informalities:
The step of “detecting, by the system, loading of dynamic interface elements based” because it is unclear where the detecting is based on. Appropriate correction is required.
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 7-12, 16-19, 23, and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Nagamalla et al. (US 20150363304 A1, hereinafter “Nagamalla”) in view of Patnaik (US 11436130 B1, hereinafter “Patnaik”) and Bell et al. (US 11182273 B1, hereinafter “Bell”).
In light of the specification, the examiner interprets a “heatmap generation tool” according to applicant’s specification ¶ 19, to be “one or more existing heatmap generation tools (e.g., Google Analytics™, Microsoft Clarity™, and similar heatmap generation tools)”.
Regarding claim 1, Nagamalla teaches:
a system comprising:
at least one memory that stores computer-executable components (Nagamalla: ¶197: memory)(Nagamalla: ¶ 197, “The memory 1230 may include a main memory 1232, a static memory 1234, and a storage unit 1236 accessible to the processors 1210 via the bus 1202. The storage unit 1236 may include a machine-readable medium 1238 on which is stored the instructions 1216 embodying any one or more of the methodologies or functions described herein. . .”);
and at least one processor that executes the computer-executable components stored in the at least one memory (Nagamalla: ¶198, one or more processors)(Nagamalla: ¶ 198, “. . . such that the instructions, when executed by one or more processors of the machine 1200 (e.g., processors 1210), cause the machine 1200 to perform any one or more of the methodologies described herein”),
wherein the computer-executable components comprise:
a heatmap component (Nagamalla: ¶53, user behavior tracking system) that executes a heatmap generation tool (Nagamalla: ¶53, Google analytics), during execution of an automated user interface test program on the application (Nagamalla: ¶ 53, "The user behavior tracking system 143 may track user activity using a variety of site tracking mechanisms. . . the user's clicks are recorded . . .the data warehouse 142 and the user behavior tracking system 143 may be partially or fully implemented, using Google Analytics, a service offered by Google, for providing a website statistics service . . ."; Nagamalla: ¶55, “. . . During testing of the system under test, the declarative testing tool 140 may test one or more user experiences . . .; Nagamalla: ¶66, “. . . using the declarative testing tool 140 to test the system under test 210 (e.g., a software application residing on application server(s) 118, the declarative testing tool 140 may be able to re-create the user experience . . . the user experience is tracked by the user behavior tracking system 143. . .”; NOTE: Paragraph 36 describes that the user experience refers to a set of actions that a user may perform on a site such as clicking, typing. Paragraph 86 describes that the user experience is a simulation that is being tested during testing of system under test. The application is the system under test. The automated user interface test program is the declarative testing tool 140. Declarative testing tool re-creates the user experience as a simulation during testing of system under test >> user experience is tracked by the user behavior tracking system during testing as described in paragraph 66. The heatmap component is the user behavior tracking system. The heatmap generation tool used by the user behavior tracking system 143 is Google Analytics. Since the user experience is tracked during testing by the user behavior tracking tool 143 which is implemented using a heatmap generation tool, therefore, the heatmap generation tool is executed during testing or execution of an automated user interface test program.)
-to track executed interface elements (Nagamalla: ¶52, “. . .The user behavior tracking system 143 tracks user activity on a site. . .user activity. . .user clicks”; Nagamalla: ¶66, “. . . the user experience is tracked by the user behavior tracking system 143. . .”; NOTE: when a click is registered, then it executes an interface element. As discussed above referencing paragraph 66, the user behavior tracking system tracks user’s experience during testing. The user experience being the simulated clicks and actions on a web application under test.)
that were executed by the automated user interface test program (Nagamalla: ¶66-71, “. . . By using the declarative testing tool 140 to test the system under test 210 (e.g., a software application residing on application server(s) 118, the declarative testing tool 140 may be able to re-create the user experience. . . Selenium-WebDriver”; Selenium is a tool for automating web application testing, which is also a tool that is disclosed by the applicant specification ¶2) (Nagamalla: ¶68, “A WebDriver refers to a tool for automating web application testing, and in particular to verify that they work as expected”; Nagamalla: ¶70, “a WebDriver framework 270 may be one framework used to test a UI. . .”; Nagamalla: ¶71, “. . .the WebDriver framework 270 may be a Selenium-WebDriver. . .”; NOTE: Referencing Nagamalla Fig. 2, the Webdriver Framework is a part of the Declarative testing tool 140. Paragraph 66 describes that the declarative testing tool re-creates user experience and paragraph 86 describes that the user experience recreated during the automated testing is a simulation. Therefore the clicks that executes interface elements were executed by the automated user interface test program)
and a reporting component (Nagamalla: ¶74, GEI 260)
that generates test coverage report data for the automated user interface test program (Nagamalla: ¶74: generate steps HTML report) (Nagamalla: ¶74, “For various embodiments, the GEI 260 may include one or more of the following features or functions. The framework may categorize the error when a user experience fails and propagate appropriate exception to denote infrastructure test or a software under test issue; enable various users to build automation of user experiences to easily test; provide maven archetype to create test projects including all the dependencies like WebDriver, test ng, and the like; provide HTML reporter to generate steps HTML report; and provide Jenkins job configuration to easily create and schedule jobs; Nagamalla: ¶93, “. . .to generate test results. . .”)
that identifies the executed interface elements (Nagamalla: ¶134, “A step may be an action (like a click, typing, mouse over etc.) or an assert (assert element presence, attribute presence or text contains, etc.)”)(NOTE: as referenced above, Nagamalla’s GEI 260 provides HTML reporter to generate “steps” HTML report. A step may be an action like a click as described in Nagamalla: ¶134. When a user interface element is clicked, or interacted with, that user interface element is executed. Since Nagamalla’s GEI 260 provides HTML reporter to generate “steps” HTML report, therefore the report generates test coverage data regarding the executed interface elements. Also, a person having ordinary skill in the art would have recognized to include the data from the user behavior tracking 143 that uses “Google Analytics” in the test coverage report data for further analysis of the conducted test. A PHOSITA also would have recognized that it is illogical to employ such data collection tool and not use the data it generates.).
However, Nagamalla fails to teach an extraction component that determines testable interface elements of a user interface of an application, wherein the testable interface elements comprise elements configured to trigger an execution event in response to user interaction (NOTE: Nagamalla’s testing system only tracks executed interface elements but not the set of testable interface elements.);
Nagamalla also fails to teach correlating tracked execution events to corresponding ones of the testable interface elements;
Nagamalla also fails to teach and a reporting component compares the executed interface elements to the testable interface elements to determine one or more non-executed elements of the testable interface elements that were not executed by the automated user interface test program based on the executed interface elements excluding the one or more non-executed elements, and generates test coverage report data for the automated user interface test program that identifies the testable interface elements, and the one or more non executed elements.
The analogous art Patnaik teaches.
Patnaik teaches:
an extraction component that determines testable interface elements of a user interface of an application; (Patnaik: col 4 lines 57-64: “. . .a web scraper 204. . . that scrapes an application to be tested to identify elements of the application. . .then stores, in. . . an application element repository 206. . .an indication of the elements of the application identified from the scraping. . .”; Patnaik: col 2 lines 14-15, “. . . The scraping may enable all elements of the application to be identified”; Patnaik: col 2 lines 21-29, “. . the elements of the application may be visual elements of the application, such as input fields of the application (e.g. included in the web pages) that are utilized for receiving user input during execution of the application.);
(NOTE: Patnaik’s invention is also directed to an automated test on an application as described in col 1 lines 24-30. The extraction component is the web scraper. Patnaik’s web scraper 204 is part of the testing platform 202 that can determine and distinguish visual elements of the application that are utilized for receiving user input. The visual elements that are utilized for receiving user input are testable interface elements. Therefore, Patnaik’s testing tool that uses a web scraper determines testable interface elements.)
wherein the testable interface elements comprise elements configured to trigger an execution event in response to user interaction (NOTE: As discussed and referenced above, Patnaik’s web scraper acting as the extraction component that extracts testable elements of an application. These testable elements include elements such as input fields where the user to input information such as login credentials. The input fields triggers an execution event in response to user interaction by receiving user input such as a log-in event. Also, Nagamalla, as discussed above in the rejection of claim 1, teaches tracking of user clicks on a link (a link is a testable interface tested by Nagamalla) and actions “to trigger transitions from page-to-page; for example, starting at page 1, an action on page 1 transitions to the next page, and an action on the next page transitions to another page” as described in Nagamalla paragraph 36. )
It would have been obvious to a PHOSITA to combine Nagamalla and Patnaik and modify Nagamalla’s heatmap component and incorporate Patnaik’s method of using a web scraper an extraction component that determines testable interface elements of a user interface of an application, wherein the testable interface elements comprise elements configured to trigger an execution event in response to user interaction. A predictable result from the combination results in: a heatmap component that tracks executed interface elements (tracked by Nagamalla’s user behavior system) among the testable interface elements (identified by Patnaik’s web scraper) that were executed by the automated user interface test program.
The reason for doing so is to scrape the application after each change made to the application in order to ensure that the application element repository 206 remains up-to-date with current elements included in the application (Patnaik: col 5 lines 1-7).
However still, the combination of Nagamalla and Patnaik still fails to teach: correlating tracked execution events to corresponding ones of the testable interface elements; and a reporting component compares the executed interface elements to the testable interface elements to determine one or more non-executed elements of the testable interface elements that were not executed by the automated user interface test program based on the executed interface elements excluding the one or more non-executed elements, and generates test coverage report data for the automated user interface test program that identifies the testable interface elements, and the one or more non executed elements.
The analogous art Bell teaches executing a runner component (NOTE: runner 626 Fig.6):
to track executed interface elements among the testable interface elements that were executed by the automated user interface test program by correlating tracked execution events to corresponding ones of the testable interface elements (Bell: col 1 lines 47-49, “. . . embodiments provide a method for automating testing of applications. . .”; col 3 lines 6-7, “. . . The testing utility includes a runner used to execute the test. . .”; Claim 1, “. . . determining, by the runner during execution of the first test, a first coverage metric of the first test, wherein the first coverage metric is based on a fraction of the pages accessed and a fraction of the UI elements accessed during execution of the first test. . .”; col 7 lines 22-40, “. . . While executing a test, a runner may track the number of UI elements entered on each page and produce a test report including the total number of UI elements. . . As shown in coverage report 420, pages 1-3 include a total of sixteen UI elements and the test as executed identified and entered eleven UI elements total for a total coverage of 68.7%; NOTE: Bell’s runner component tracked and identified 11 UI elements that are entered/executed among the 16 total number of UI elements. They are correlated because the system calculates and reports the executed elements as 68.7% among the 16 total testable UI elements during the execution of the test. 11/16 = 68.7%.)
Bell further teaches that a coverage report 628 as shown in Fig.6 component is executed as a:
a reporting component that compares the executed interface elements to the testable interface elements to determine one or more non-executed elements of the testable interface elements that were not executed by the automated user interface test program based on the executed interface elements excluding the one or more non-executed elements (Bell: col 9 lines 17-34, “. . . further include generating a report of the coverage metric of the test. As discussed above with respect to FIG. 4, coverage may be calculated by the testing utility by comparing a test report generated by the runner to the application data . . . When calculating coverage, method 500 may further include determining, based on the coverage metric, . . . the report of the coverage metric includes the number of pages, buttons and fields of the application that were missed by the test. . .”; NOTE: The reporting component is the coverage report 628 component as shown in Fig. 6. The non-executed interface elements are the elements of the application that were missed by the test. The non-executed elements are determined based on the coverage metric of the test where the runner identified 11/16 UI elements executed. A comparison is inherent when calculating the non-executed elements. These non-executed interface elements are also included in the generated coverage test report. Since the elements are missed during the test, therefore, they are not executed by the automated user interface test program. In order to determine the value of the non-executed elements, it must be excluded from the calculation because it is the set that is being determined and the unknown variable.),
and generates test coverage report data for the automated user interface test program that identifies the testable interface elements, the executed interface elements, and the one or more non-executed elements (NOTE: As discussed and referenced above, Bell generates a coverage report data including for example, the metric from the runner with 11 UI elements executed among 16 total UI elements identified, and further including in the report, the non-executed UI elements that were missed during the execution of the test.)
It would also have been an obvious design choice among a finite number of solutions to a PHOSITA before the effective filing date of the claimed invention to combine Nagamalla, Patnaik, and Bell and include: a heatmap component that executes a heatmap generation tool, during execution of an automated user interface test program on the application, to track executed interface elements among the testable interface elements that were executed by the automated user interface test program by correlating tracked execution events to corresponding ones of the testable interface elements; and a reporting component that compares the executed interface elements to the testable interface elements to determine one or more non-executed elements of the testable interface elements that were not executed by the automated user interface test program based on the executed interface elements excluding the one or more non-executed elements, and generates test coverage report data for the automated user interface test program that identifies the testable interface elements, the executed interface elements, and the one or more non-executed elements. (NOTE: Nagamalla’s automated test employing google analytics to track executed elements during testing, Patnaik’s web scraper method to extract all testable user interface elements, and Bell’s coverage report generation including executed UI elements, total number of UI elements, and non-executed elements.)
The reason for doing so is “to facilitate automation of software testing that can generate test cases and calculate coverage of the test cases when executed” (Bell: col 1 lines 41-42)
Regarding claim 2, depending on 1,
The combination of Nagamalla, Patnaik, and Bell teaches:
The system of claim 1, wherein the heatmap component employs the heatmap generation tool to generate heatmap data for the executed interface elements, and wherein the test coverage report data comprises the heatmap data. (note: the heatmap data are user behavior data such as clicks (or steps as described Nagamalla: ¶134) tracked by Nagamalla’s user behavior tracking 143 during testing)(Nagamalla: ¶74, “. . . provide HTML reporter to generate steps HTML report. . .”; Nagamalla: ¶134, “A step may be an action (like a click, typing, mouse over etc.) or an assert (assert element presence, attribute presence or text contains, etc.)
Regarding claim 3, depending on 2,
The combination of Nagamalla, Patnaik, and Bell teaches:
The system of claim 2, wherein the computer-executable components further comprise: a rendering component (Nagamalla: ¶80, user interface module 320) that renders the test coverage report data via a display device. (Nagamalla: ¶80, “. . .the user interface module 320 may be used to display the results of the tests performed. . .”).
Regarding claim 7, depending on claim 1,
The combination of Nagamalla, Patnaik, and Bell teaches:
The system of claim 1, wherein the extraction component determines the total amount of testable user interface elements using a web-scraping tool (Patnaik: col 4 lines 57-64: “. . .a web scraper 204. . . that scrapes an application to be tested to identify elements of the application. . .then stores, in. . . an application element repository 206. . .an indication of the elements of the application identified from the scraping. . .”; Patnaik: col 2 lines 14-15, “. . . The scraping may enable all elements of the application to be identified. . .”; NOTE: As discussed in the rejection of claim 1, Patnaik’s web scraper 204 is capable of determining testable user interface elements (visual elements that are utilized for receiving user input) which are elements of the application. Also, Patnaik discloses that all elements of the application (Patnaik: col 2 lines 21-29, “For example, the elements of the application may be visual elements. . .that are utilized for receiving user input. . .”). Therefore, all testable interface elements are determined. It would have been obvious to a PHOSITA to implement a counter function into the extraction component (web scraper 204 as taught by Patnaik) to determine the total amount of testable user interface elements. A PHOSITA would immediately understand that a counter implementation is common and a routine practice in programming to track events.
Regarding claim 8, depending on claim 1,
The combination of Nagamalla, Patnaik, and Bell teaches:
The system of claim 1, wherein the computer-executable components further comprise:
a testing component (Nagamalla: ¶64, declarative testing tool 140)
that controls the execution of the automated user interface test program (Nagamalla: ¶64, the declarative testing tool 140 is used to test a system under test. . .may include an automated test software user interface 250. . .and a WebDriver framework 270)
on the user interface-based application (Nagamalla: ¶64, site. . .system under test. . publication system. . .payment system. . .)
(Nagamalla: ¶64, “FIG. 2 illustrates a block diagram of a system for declarative testing according to an example embodiment. In one embodiment, the system 200 and, in particular, the declarative testing tool 140 may represent the automated testing system 123 of FIG. 1 (or a portion of the automated testing system 123). In further embodiments, the declarative testing tool 140, may be located completely or partially outside the networked system 102 (shown in FIG. 1A) or the networked system 102a (shown in FIG. 1B). The declarative testing tool 140 is used to test a system under test 210. The system under test 210 may be one or more components of the publication system(s) 120 or the payment system(s) 122 shown in FIG. 1A or FIG. 1C. In an example embodiment, the declarative testing tool 140 may include an automated test software user interface 250, a generic experience infrastructure (GEI) 260, and a WebDriver framework 270”),
Regarding claim 9, depending on claim 1,
The combination of Nagamalla, Patnaik, and Bell teaches:
The system of claim 1,
wherein the extraction component extracts information identifying testable interface elements (see rejection of claim 1)
during the execution (Patnaik: col 2 line 26, “. . . during execution of the application. . .”) of the automated user interface test program (Patnaik: col 2 line 46, “. . .testing platform. . .”) on the application (Patnaik: col 2 lines 3-30, “. . .web-based application. . .”)
(Patnaik: col 2 lines 3-30, “FIG. 1 illustrates a method 100 for automating manually written test cases, in accordance with one embodiment. The method 100 may be carried out by any system that includes at least one processor. For example, the method 100 may be carried using the computer system described below with reference to FIG. 5.
As shown in operation 102, a web scraper is used to scrape an application to be tested, wherein the scraping identifies elements of the application. The application is any computer code that performs one or more functions. Thus, the code of the application may be scraped to identify the elements of the application. The scraping may enable all elements of the application to be identified.
In one embodiment, the application may be a web-based application. To this end, the application may include one or more web pages. In this embodiment, the web pages of the application may be scraped for the elements of the application.
The elements of the application may be any components, building blocks, etc. of the application. For example, the elements of the application may be visual elements of the application, such as input fields of the application (e.g. included in the web pages) that are utilized for receiving user input during execution of the application, tables output by the application, etc. As another example, the elements of the application may include data structures created and used during execution of the application”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to have: the extraction component extracts information identifying testable interface elements during the execution of the automated user interface test program via the application. It would have been obvious to a PHOSITA that web applications are highly dynamic. For example, a simulated click during the test on a link may result in a change of a webpage and may also result for user interface elements to change (e.g. position, size, visibility etc.), a PHOSITA would recognize that extraction of interface elements during the automated testing must be done every time the UI elements change due to the execution of interface elements during testing. The reason for doing so is to scrape the application periodically after each change made to the application, in order to ensure that the application element repository remains up-to-date with current elements included in the application (Patnaik: col 5 lines 1-7).
Regarding claim 10, depending on claim 9,
The combination of Nagamalla, Patnaik, and Bell teaches:
The system of claim 9, wherein the computer-executable components further comprise:
a monitoring component (Nagamalla: Fig. 3 GEI 300; note: the GEI 300 has a monitoring sub-module 350) that monitors the execution of the automated user interface program on the application (Nagamalla: ¶79, “In various embodiments, a monitoring module 350 may be configured to monitor the user experiences and flows of a software application (e.g., the system under test 210). An example flow diagram of monitoring a software application is shown in FIG. 6”)
and detects loading of dynamic interface elements (Nagamalla: ¶68, “. . .The Selenium-WebDriver may integrate the WebDriver API with Selenium 2.0 and may be used to better support dynamic web pages where elements of a page may change without the page itself being reloaded. . .Nagamalla: ¶69, “The GEI 260 (with the monitoring module as a sub-module) may leverage the WebDriver framework 270 (Selenium-WebDriver) or some other framework depending on the capabilities needed by the declarative testing tool 140”).
(note: As disclosed by Nagamalla, the GEI leverages the WebDriver framework (note: means working directly together), A PHOSITA would have found it as an obvious design choice to integrate both GEI and the WebDriver framework as a single monitoring component).
However, Nagamalla fails to teach: and wherein the extraction component extracts at least some of the information identifying the testable user interface elements in response to detection of the loading of the dynamic interface elements by the monitoring component.
Patnaik further teaches:
and wherein the extraction component extracts at least some of the information identifying the testable user interface elements in response to detection of the loading of the dynamic interface elements by the monitoring component (Patnaik col 4 lines 57-57 to col 5 lines 1-7, “The testing platform 202 includes a web scraper 204 (e.g. written in Python) that scrapes an application to be tested to identify elements of the application. The testing platform 202 then stores, in an application element repository 206 (e.g. written in Selenium), an indication of the elements of the application identified from the scraping. . . . the web scraper 204 may be prompted to scrape the application periodically, to update the application element repository 206 with any changes made to elements included in the application. As another option, the web scraper 204 may be prompted to scrape the application after each change made to the application (e.g. as detected by a monitoring module of the testing platform 202 or a component separate from the testing platform 202), in order to ensure that the application element repository 206 remains up-to-date with current elements included in the application. . .”; Patnaik: col 2 lines 32-37, “. . . The indication may include any other information associated with each element. For example, for each element, the repository may store a name of the element, a type of the element, a functionality of the element, a web page on which the element was identified. . .”; NOTE: As referenced above, Patnaik dynamically scrapes the application and stores indication of elements identified from the scraping.).
It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to combine Nagamalla, Patnaik, and Bell and include: detecting, by the system, loading of dynamic interface elements based; and extracting, by the system, at least some of the information identifying the testable user interface elements in response to the detecting as taught by Patnaik.
The reason for doing so is “to ensure that the application element repository 206 remains up-to-date with current elements included in the application” (Patnaik: col 5 lines 1-7)
Regarding claim 11,
Method claim 11 is drawn to the method corresponding to the computer-executable components of using same as claimed in apparatus claim 1. Therefore, method claim 11 corresponds to the to the computer-executable components in the apparatus of claim 1, and is rejected for the same reasons of obviousness as used above.
Regarding claims 12, and 16-18, and 25
Method claims 12, 16-18, and 25 are drawn to the methods corresponding to the computer-executable components of using same as claimed in apparatus claims 2, and 7-10 respectively. Therefore, methods claims 12, 16-18, and 25 correspond to the computer-executable components in the apparatus of claims 2, and 7-10 respectively and are rejected for the same reasons of obviousness as used above.
Regarding claim 19,
CRM claim 19 is drawn to the CRM corresponding to the method of using same as claimed in method claim 11. Therefore, CRM claim 11 corresponds to the method of claim 11, and is rejected for the same reasons of obviousness as used above.
Regarding claim 23,
CRM claim 23 is drawn to the CRM corresponding to the configuration of the extraction component claimed in apparatus of claim 7. Therefore, CRM claim 23 corresponds to the configuration of the extraction component claimed in apparatus of claim 7, and is rejected for the same reasons of obviousness as used above.
Claims 4, 13, and 20-21, 24 are rejected under 35 U.S.C. 103 as being unpatentable over Nagamalla in view of Patnaik, and Bell further in view of Cordasco (US 20130091417 A1, hereinafter “Cordasco”)
Regarding claim 4, depending on 3,
The combination of Nagamalla, Patnaik, and Bell teaches:
The system of claim 3, wherein the heatmap data comprises graphical heatmap elements for the executed interface elements.
However the combination of Nagamalla, Patnaik, and Bell fails to teach the analogous art Cordasco teaches.
Cordasco teaches:
wherein the rendering component (Cordasco: ¶28, proxy object generator 190) displays, via a display device the user interface and the graphical heatmap elements (Cordasco: ¶23, usage clusters 150) at positions relative to the executed interface elements as included in the user interface.
(Cordasco: Fig. 2, ¶ 23, " FIG. 2 depicts an example of an overlay 124 displayed over webpage 100. In one example, a heatmap is displayed within overlay 124. Usage clusters 150 represent places on webpage 100 where users performed mouse clicks, selections, entered data, etc. In one example, usage clusters 150 become darker as more events are detected in the same general area"; ¶ 28, "Analytics obtained from previously monitored web sessions may be generated and displayed as usage clusters 150 within a heatmap displayed over webpage 100. A proxy object generator 190 may generate an overlay 124 that contains the heatmap or may display overlay 124 over the heatmap. To enable operator interaction with webpage objects 128, proxy object generator 190 generates proxy objects 204 on Z-index layers above webpage 100 and overlay 124. Proxy objects 204 may be configured to act as proxies for detecting and reacting to events associated with underlying webpage objects 128. For example, proxy objects 204 can be configured to detect mouseovers and initiate actions, such as displaying pop-up windows associated with underlying webpage objects 128. Thus, proxy objects 204 convert previously static heatmaps into interactive overlays that can now detect and respond to operator initiated events"; ¶ 6, “The usage clusters may be aligned with associated webpage objects within the underlying webpage”).
It would have been obvious to a person having ordinary skill in the art (PHOSITA) before
the effective filing date of the claimed invention to combine Nagamalla, Patnaik, Bell and Cordasco and implement Cordasco’s teachings wherein the rendering component displays, via a display device the user interface and the graphical heatmap elements at positions relative to the executed interface elements as included in the user interface to “allow a user to visually associate the information provided by the usage clusters with associated underlying webpage objects” (Cordasco: ¶ 6).
Regarding claim 13, depending on claim 12,
The combination of Nagamalla, Patnaik, Bell, and Cordasco teaches:
The method of claim 12, wherein the heatmap data comprises graphical heatmap elements for the executed interface elements, and wherein the method further comprises: embedding, by the system, the graphical heatmap elements within the user interface interface-based application at positions relative to the executed interface elements,(note: this limitation is drawn to the method corresponding to the computer-executable components of using same as claimed in apparatus claim 4. Therefore, this limitation correspond to the computer-executable components in the apparatus of claim 4 and is rejected for the same reasons of obviousness as used above)
resulting in a marked-up version of the user interface; and rendering, by the system, the marked-up version via a display (Cordasco: Fig. 2, heatmap displayed within the overlay) (Cordasco: ¶23, FIG. 2 depicts an example of an overlay 124 displayed over webpage 100. In one example, a heatmap is displayed within overlay 124. Usage clusters 150 represent places on webpage 100 where users performed mouse clicks, selections, entered data, etc. In one example, usage clusters 150 become darker as more events are detected in the same general area. Displaying overlay 124 over webpage 100 and displaying a heatmap within overlay 124 is described in co-pending U.S. patent application Ser. Nos. 13/401,725 and 12/750,607 which have both been incorporated by reference in their entirety).
It would have been obvious to a person having ordinary skill in the art (PHOSITA) before
the effective filing date of the claimed invention to combine Nagamalla, Patnaik and Cordasco and implement Cordasco’s teachings wherein the heatmap data comprises graphical heatmap elements for the executed interface elements, and wherein the method further comprises: embedding, by the system, the graphical heatmap elements within the user interface interface-based application at positions relative to the executed interface elements, resulting in a marked-up version of the user interface; and rendering, by the system, the marked-up version via a display to “allow a user to visually associate the information provided by the usage clusters with associated underlying webpage objects” (Cordasco: ¶ 6).
Regarding claim 20, depending on 19,
The combination of Nagamalla, Patnaik, and Cordasco teaches:
The non-transitory machine-readable storage medium of claim 19, wherein the operations further comprise:
generating heatmap data for the executed interface elements using the heatmap generation tool (note: this limitation is drawn to the CRM corresponding to the computer-executable components of using same as claimed in apparatus claim 2. Therefore, this limitation correspond to the computer-executable components in the apparatus of claim 2 and is rejected for the same reasons of obviousness as used above);
wherein the heatmap data comprises graphical heatmap elements for the executed interface elements; and embedding the graphical heatmap elements within the user interface at positions relative to the interface elements, resulting in a marked-up version of the user interface (note: this limitation is drawn to the CRM corresponding to the method of using same as claimed in method 13. Therefore, this limitation correspond to the method claim 13 and is rejected for the same reasons of obviousness as used above).
Regarding claim 21, depending on 20,
The combination of Nagamalla, Patnaik, Bell, and Cordasco teaches:
The non-transitory machine-readable storage medium of claim 20, wherein the operations further comprise: rendering the marked-up version via a display (note: this limitation is drawn to the CRM corresponding to the method “rendering, by the system, the marked-up version via a display” of using same as claimed in method claim 13. Therefore, this limitation correspond to the method “rendering, by the system, the marked-up version via a display” of claim 13 and is rejected for the same reasons of obviousness as used above).
Regarding claim 24, depending on 20,
CRM claim 24 is drawn to the CRM corresponding to the configuration of the extraction component claimed in apparatus of claim 9. Therefore, CRM claim 24 corresponds to the configuration of the extraction component claimed in apparatus of claim 9, and is rejected for the same reasons of obviousness as used above.
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 PATRICK GALERA whose telephone number is (571)272-5070. The examiner can normally be reached Mon-Fri 0800-1700 ET.
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, King Poon can be reached on 571-270-0728. 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.
/PATRICK P GALERA/
Examiner, Art Unit 2617
/KING Y POON/ Supervisory Patent Examiner, Art Unit 2617
Prosecution Insights