Ex Parte MATHUR et al

Patent Trial and Appeal Board

Mar 31, 2017

12950176 (P.T.A.B. Mar. 31, 2017)

United States Patent and Trademark Office
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O.Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
12/950,176 11/19/2010 AS HIS H K. MATHUR IN920100138US1 7226
37945 7590 04/04/2017
DTTKFW YFF
EXAMINER
YEE AND ASSOCIATES, P.C. LOUIE, JUE WANG
P.O. BOX 802333
DALLAS, TX 75380 ART UNIT PAPER NUMBER
2193
NOTIFICATION DATE DELIVERY MODE
04/04/2017 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address(es):
ptonotifs @yeeiplaw.com
mgamez @ yeeiplaw. com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte ASHISH K. MATHUR and ASWANI KUMAR THUNGA
Appeal 2016-004065
Application 12/950,1761
Technology Center 2100
Before KRISTEN L. DROESCH, CATHERINE SHIANG, and
JOHN D. HAMANN, Administrative Patent Judges.
HAM ANN, Administrative Patent Judge.
DECISION ON APPEAL
Appellants file this appeal under 35 U.S.C. § 134(a) from the
Examiner’s Final Rejection of claims 1—7 and 16—28. We have jurisdiction
under 35 U.S.C. § 6(b). We affirm.
THE CLAIMED INVENTION
Appellants’ claimed invention relates to software testing, including
“the XPATH-based selection assistance of GUI elements during manual test
script authoring for XML-based applications.” Spec. 11. Claim 1 is
illustrative of the subject matter of the appeal and is reproduced below.
1 According to Appellants, the real party in interest is International Business
Machines Corporation. Br. 3.
Appeal 2016-004065
Application 12/950,176
1. An automated software testing system comprising:
one or more processors;
one or more storage mediums storing computer usable
code executable by the one or more processors;
a test script authoring graphical user interface generated
by at least one of the processors executing at least a portion of
the computer usable code, wherein said test script authoring
graphical user interface is for manual test script authoring of an
XML-based software application formed from one or more
XML based source code documents;
a search section of the test script authoring graphical user
interface within which a user is permitted to input at least one
of an XPATH expression and a text string;
an element selection assistant for searching the XML-
based code documents for graphical user interface elements
using a search XPATH expression, wherein said search
XPATH expression is one of the XPATH expression input into
the search section and a generated XPATH expression
automatically generated from the text string; and
a result section of the test script authoring graphical user
interface configured to present results from the element
selection assistant, wherein said results comprise all graphical
user interface elements in the searched XML-based code
documents matching criteria of the search XPATH expression,
wherein the element selection assistant provides suggestions to
assist the user to refine the input based on the results, wherein
the result section is a part of an element selection assistant
interface associated with the test script authoring graphical user
interface, wherein the element selection assistant interface
provides a user an option of selecting an element listed in the
results and operations that can be performed upon a selected
element of the results.
2
Appeal 2016-004065
Application 12/950,176
REJECTIONS2 ON APPEAL
(1) The Examiner rejected claims 1,2, 5, 16, 18, 21, and 28 under
35 U.S.C. § 103(a) as being unpatentable over the combination of
(i) Selenium Project, Selenium Documentation: Release 1.0, (Feb. 24, 2010)
1—158 (hereinafter “Selenium”), (ii) Foulger et al. (US 6,578,022 Bl; issued
June 10, 2003) (hereinafter “Foulger”), (iii) Fu et al. (US 2009/0300056 Al;
published Dec. 3, 2009) (hereinafter “Fu”), (iv) Ray et al. (US
2007/0214119 Al; published Sept. 13, 2007) (hereinafter “Ray”), and
(v) oXygen, oXygen XML Editor XPath Support (Sept. 6, 2014)
(hereinafter “oXygen”).
(2) The Examiner rejected claims 3 and 17 under 35 U.S.C.
§ 103(a) as being unpatentable over the combination of Selenium, Foulger,
Fu, Ray, oXygen, and Mari Abe et al., Robust Pointing by XPath Language:
Authoring Support and Empirical Evaluation, Proceedings of the 2003
Symposium on Applications and the Internet (hereinafter “Abe”).
(3) The Examiner rejected claim 4 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Selenium, Foulger, Fu, Ray,
oXygen, and Sarwono et al. (US 2007/0112831 Al; published May 17,
2007) (hereinafter “Sarwono ’831”).
2 The Examiner also provisionally rejected claims 16—21 for obviousness-
type double patenting over claims 1, 2, 4, 5, and 8 of copending Application
No. 13/410,965. No patent has issued yet from that copending Application,
nor do Appellants present arguments traversing this provisional rejection.
We find it is premature to address this provisional rejection. See In re
Moncla, 95 USPQ2d 1884, 1885 (BPAI 2010) (precedential).
3
Appeal 2016-004065
Application 12/950,176
(4) The Examiner rejected claims 6, 7, 19, and 20 under 35 U.S.C.
§ 103(a) as being unpatentable over the combination of Selenium, Foulger,
Fu, Ray, oXygen, and Malcom (US 6,950,980 Bl; issued Sept. 27, 2005).
(5) The Examiner rejected claims 22—25 under 35 U.S.C. § 103(a)
as being unpatentable over the combination of Selenium, Foulger, Fu, Ray,
oXygen, and Sarwono et al. (US 2007/0168493 Al; published July 19,
2007) (hereinafter “Sarwono ’493”).
(6) The Examiner rejected claims 26 and 27 under 35 U.S.C.
§ 103(a) as being unpatentable over the combination of Selenium, Foulger,
Fu, Ray, oXygen, Sarwono ’493, and Malcolm.
ANAFYSIS
We have reviewed the Examiner’s rejections in light of Appellants’
contentions that the Examiner erred. In reaching our decision, we consider
all evidence presented and all arguments made by Appellants.
We disagree with Appellants’ arguments and we incorporate herein
and adopt as our own the findings, conclusions, and reasons set forth by the
Examiner in the (1) February 27, 2015 Final Office Action (“Final Act.” 2—
40) and (2) November 25, 2015 Examiner’s Answer (“Ans.” 2—50). We
highlight and address, however, specific findings and arguments below for
emphasis.
(1) Whether modifying Selenium is improper
Selenium is a prior art reference common to each of the rejections on
appeal. Appellants argue “any modification of Selenium [] would make it
more challenging or impossible to implement the Selenese language . . .
[and, thus,] would be a modification that would render Selenium unsuitable
4
Appeal 2016-004065
Application 12/950,176
for [its] intended purpose and/or that would change its principle of
operations, which is not permitted.” Br. 14. More specifically, Appellants
argue Selenium’s intended use is to provide a novel testing language (i.e.,
Selenese) that relies upon commands to maximize flexibility at the expense
of simplicity. Id. (citing Selenium 11—12). Selenese’s commands are well-
defined (i.e., Actions, Assessors, and Assertions), and “consist of a
command and two parameters ([i.e.,] target and value),” which vary per
command. Id. (citing Selenium 12). Furthermore, Appellants argue
Selenium teaches using a required interface for entering Selenese commands
to fulfill Selenium’s principle of operation and “to serve its intended
function (of executing the proprietary Selenese language).” Id.
Accordingly, Appellants contend that “[t]he required structure of the
Selenese language and interface . . . would not lend itself to the [claimed]
three section GUI.” Id.
The Examiner finds that modifying Selenium’s teachings to reflect the
teachings of the other cited references in the combinations would not render
Selenium unsuitable for its intended purpose or change its principle of
operations. Ans. 31—32. As to Selenium, the Examiner finds it teaches or
suggests using XPATH “as part of the Selenese language to specify a
parameter of a command,” and teaches “that its XPATH mechanism can be
assisted with additional tools (i.e., Firefox Add-ons that can assist in
discovering the XPATH of an element[)].” Ans. 33 (citing Selenium 40).
The Examiner, thus, finds modifying “Selenium to expand on existing
mechanisms of inputting [an] XPATH expression, [and] displaying and
processing XPATH results will not render Selenium unsuitable for its
intended purpose or change its principle operation.” Ans. 33. To the
5
Appeal 2016-004065
Application 12/950,176
contrary, the Examiner finds modifying Selenium would “expand on the
capabilities] of Selenium, allowing more ways to enter the XPATH
expression as part of the Selenium commands, and more ways to display and
process XPATH results.” Id.
Appellants have not persuaded us that combining Selenium with the
other cited references changes the principle of operation of Selenium or
renders Selenium unsatisfactory for its intended purpose. We agree with the
Examiner that rather than changing its intended purpose or principle of
operation, Selenium itself teaches expanding mechanisms for inputting
command expressions and displaying results via add-ons. See, e.g.,
Selenium 40 (teaching using Add-ons with XPATH). Appellants too
narrowly focus on specific command structures and Selenium’s interface
rather than focusing on Selenium’s teachings (e.g., Add-ons) and how one of
ordinary skill in the art would have combined these teachings with the
teachings of the other cited references. See In re Keller, 642 F.2d 413, 425
(CCPA 1981) (“Combining the teachings of references does not involve an
ability to combine their specific structures.”); In re Nievelt, 482 F.2d 965,
968 (CCPA 1973); see also KSR Inti Co. v. Teleflex Inc., 550 U.S. 398, 420
(2007) (“[I]n many cases a person of ordinary skill will be able to fit the
teachings of multiple patents together like pieces of a puzzle.”); In re Preda,
401 F.2d 825, 826 (CCPA 1968) (“[I]t is proper to take into account not only
specific teachings of the references but also the inferences which one skilled
in the art would reasonably be expected to draw therefrom.”).
(2) Result section
Appellants argue the combination, and Selenium in particular, fails to
teach or suggest “a result section of the test script authoring graphical user
6
Appeal 2016-004065
Application 12/950,176
interface configured to present results from the element selection assistant,
wherein said results comprise all graphical user interface elements in the
searched XML-based code documents matching criteria of the search
XPATH expression,” as recited in claim 1, and similarly recited in
independent claims 16 and 22. See Br. 15—17. Appellants argue Selenium
instead teaches (i) entering Selenese commands in a GUI, with the resulting
output being shown via a log, and (ii) using the find button “to see which UI
is currently selected for the Selenium command.” Br. 15—16 (citing
Selenium 18 (§ 4.3), 26 (§ 4.8.3)); see also Br. 16 (citing Selenium 26
(§ 4.8.4) (arguing Firefox’s text search function is taught for Selenium
code)); Br. 17 (citing Selenium 39 (§ 5.2.5) (arguing that a text search
function for an Add-on is taught)). Appellants contend Selenium fails to
teach or suggest a “result pane (equivalent to the result section of the test
script authoring GUI).” Br. 17.
The Examiner finds, and we agree, that the combination teaches the
disputed limitation. See Ans. 33—35. As to Selenium, the Examiner finds,
and we agree, it teaches or suggests displaying results from an XPath query
using a find button to locate targeted UI elements (i.e., an XPATH
expression is entered into a Target field of a command), which are shown
enclosed within a bright green rectangle on a webpage displayed in a Firefox
browser. See Ans. 34 (citing Selenium 26 (§§ 4.8.3, 4.8.5); 39 (§ 5.2.5)).
As to oXygen, the Examiner finds, and we agree, it teaches or suggests
“presenting XPath query results within an interface that also presents the
XPath query.” Ans. 35 (citing oXygen, “Presentation of the XPath Results”
section). We agree with the Examiner that the combined teachings of
Selenium and oXygen teach or suggest the disputed limitation, including
7
Appeal 2016-004065
Application 12/950,176
teaching or suggesting displaying the results of a XPATH query in a window
with the XPath query. Id.
(3) Combining Selenium, Foulger, and Fu
Appellants argue combining Selenium, Foulger, and Fu is improper
because the Examiner identifies insufficient motivation to combine these
references. See Br. 18—19. Appellants argue the improper combination
applies to all of the rejections on appeal — each rejection combines at least
these three references. Br. 20.
Appellants argue the references are very different (e.g., having
dissimilar core elements), and because of the “fundamental differences
between these references (dynamic verse static content; AI Web searching
verses local repository GUI element searching; etc.) . . . one of ordinary
skill would never” combine them. Br. 19. For example, Appellants argue
Foulger teaches suggesting tips in “a semantic search of Web content, which
utilizes relationships semantically represented as tuples within a topic map
type of ontology.” Br. 18 (citing Foulger col. 3,11. 12—25; col. 6,11. 47—55;
col. 18,11. 30-39). Appellants also contend Foulger’s systems “are very
computing resource intensive and results in delays” that are “not justified for
small domains (GUI elements of a test tool) as is known to one of ordinary
skill in the art.” Br. 20. As to Fu, Appellants argue it teaches locating
dynamic Web content and “refining an XPATH expression in a step-by step
fashion.” Br. 18 (citing Fu 145).
Furthermore, Appellants argue the Examiner provided motivation is
incorrect or insufficient because (i) Foulger requires semantic logic not
applicable to XPath queries, (ii) Foulger and Selenium use techniques to
refine XPath queries that are dissimilar to what is well known in the art, and
8
Appeal 2016-004065
Application 12/950,176
(iii) the references do not teach or suggest that it is desirable to apply the
technique of Fu to XPATH queries such that a user can direct a search to the
right information more quickly and effectively, and (iv) ‘“quickly and
effectively’ is a nonce motivation that could apply to anything.” Br. 19—20.
Appellants also argue that applying XPATH queries to Foulger’s teachings
would change Foulger’s principle of operation. Br. 18.
The Examiner finds, and we agree, that Selenium, Foulger, and Fu are
properly combined because:
It would have been obvious to one of ordinary skill in the art at
the time of the invention to have modified Selenium such that
the element selection assistant provides suggestions to assist the
user to refine the input based on the results as similarly taught
by Foulger [(col. 3, 11. 12—25; col. 6, 11. 47—55; col. 18, 11. 30-
39)] and Fu because the technique of Foulger is applicable to
XPATH queries since it is well known in the art that a XPATH
query expression can be refined (see at least [0045] of Fu) and
it is desirable to apply the technique of Fu to XPATH queries
such that a user can direct a search to the right information
more quickly and effectively (see at least column 3, lines 12-23
of Foulger).
Final Act. 9; see also Ans. 36. Accordingly, we find the Examiner provides
“articulated reasoning with some rational underpinning to support the legal
conclusion of obviousness.” In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006).
We also agree with the Examiner that rather than being a “nonce
motivation,” Foulger teaches “the motivation of allowing a user to direct a
search to the right information more quickly and effectively.” Ans. 37—38
(citing Foulger col. 3,11. 12—23); see also KSR, 550 U.S. at 417 (“[I]f a
technique has been used to improve one device, and a person of ordinary
skill in the art would recognize that it would improve similar devices in the
9
Appeal 2016-004065
Application 12/950,176
same way, using the technique is obvious unless its actual application is
beyond his or her skill.”).
Additionally, we find Appellants’ arguments that (i) Foulger’s
systems are computing intensive and not justified for analyzing GUI
elements of a test tool (Br. 20) and (ii) applying XPATH queries to Foulger
would change Foulger’s principle of operation (Br. 18) unpersuasive,
including because such arguments are conclusory and unsupported by record
evidence. See In re Pearson, 494 F.2d 1399, 1405 (CCPA 1974)
(“Attorney’s argument in a brief cannot take the place of evidence.”).
(4) Whether Foulger is non-analogous art
Appellants argue Foulger is non-analogous art to Selenium and Fu.
Br. 20-21 (arguing each rejection on appeal has Foulger in common).
Specifically, Appellants argue Foulger (i) is in a USPTO search category
that relates to a different field than Selenium and Fu, (ii) relates to “artificial
intelligence in searching (lacking XPATH teachings),” rather than being
directed to the specific problem addressed by the claims, (iii) teaches a type
of search adverse to Fu’s teachings, and (iv) relates to artificial intelligence
searching which is not reasonably pertinent to Selenium. Br. 20—21.
The Examiner finds Foulger is analogous art because it is reasonably
pertinent to the particular problem with which the inventor is involved (i.e.,
using XPATH to search for graphical elements in an application under test,
and to provide suggestions to refine XPATH query results). Ans. 38; App.
Br. 31 (reciting claim 1). The Examiner also finds “Foulger teaches that it is
desirable to provide suggestions to a user on search criteria to narrow or
broaden search results.” Ans. 38; see also Foulger col. 3,11. 12—25.
10
Appeal 2016-004065
Application 12/950,176
Additionally, the Examiner finds Foulger is in the same field of endeavor as
the claimed invention because one of ordinary skill in the art would “look to
other search result processing techniques in the art (such as those taught by
Foulger) and to apply those techniques to XPATH query results.” Ans. 38—
39.
“Two separate tests define the scope of analogous prior art: (1)
whether the art is from the same field of endeavor, regardless of the problem
addressed and, (2) if the reference is not within the field of the inventor’s
endeavor, whether the reference still is reasonably pertinent to the particular
problem with which the inventor is involved.” In re Klein, 647 F.3d 1343,
1348 (Fed. Cir. 2011) (citations omitted) (emphases added).
We find Foulger is reasonably pertinent to the particular problem with
which the inventor is involved (i.e., using XPATH to search for graphical
elements in an application under test, and to provide suggestions to refine
XPATH query results). See Foulger col. 3,11. 12—25; col. 6,11. 47—55; col.
18,11. 30-39. We also find Foulger is in the same field of endeavor (e.g.,
search result processing techniques) as the claimed invention. Id. We note
that the scope of analogous art is to be construed broadly. See Wyers v.
Master Lock Co., 616 F.3d 1231, 1238 (Fed. Cir. 2010) (“The Supreme
Court’s decision in KSR International Co. v. Teleflex, Inc., 550 U.S. 398 . . .
(2007), directs us to construe the scope of analogous art broadly.”).
(5) Motivation to combine oXvgen
Appellants argue the Examiner’s cited motivation to combine oXygen
with Selenium “is flawed, as the user [already] can view [Selenium’s] FOG
pane at the same time it executes the Selenium command.” Br. 21.
Appellants also argue the FOG pane “is related to the command for which
11
Appeal 2016-004065
Application 12/950,176
the location was a target. Therefore, a significant restricting of the purpose
of Selenium would be required, which would de-focus from the Selenese
command to permit a change for a specific (one of three) type of location-
specific target.” Id.
The Examiner finds, and we agree, that oXygen is properly combined
with Selenium. Ans. 40. The Examiner finds, and we agree, Selenium
teaches a section having different panes to present different information
(e.g., Log, Reference, DI-Element, Rollup). Ans. 40 (citing Selenium 18
(§ 4.3); 20-21 (§ 4.4.4)). We agree with the Examiner that “adding another
pane in this section to display the XPATH query results, as shown in the
bottom section of the interface in oXygen ‘Presentation of the XPath
Results’ would not be a significant restricting of the purpose of Selenium.”
Id. Rather, “[i]t would provide additional functionality to Selenium,
allowing results of an XPath query to be listed concurrently with the XPath
query that generated the results.” Id.', see also oXygen 1 (teaching a GUI
displaying results of an XPATH query concurrently with the XPATH query
that generated the results).
(6) Motivation to combine Ray
Appellants argue the Examiner cites insufficient motivation to
combine Ray with the other references of the combinations. Br. 23 (arguing
each rejection on appeal has Ray in common). Specifically, Appellants
argue “Selenium does [not] present any results to XPath queries within a
GUI. The only reference that does (Oxygen) enables you to print results
without modification.” Id. Appellants further contend that Ray’s “save” and
“print” options would not “make sense” in the context of the claims to one
of ordinary skill in the art. Br. 23 (citing Fig. 2 (items 260, 265, 270)
12
Appeal 2016-004065
Application 12/950,176
(disclosing that selecting the object shows the equivalent GUI element)); see
also Br. 31 (reciting for claim 1, in relevant part, “wherein the element
selection assistant interface provides a user an option of selecting an element
listed in the results and operations that can be performed upon a selected
element of the results”).
The Examiner finds, and we agree, Ray is properly combined with
Selenium and oXygen. Ans. 41. The Examiner finds, and we agree,
Selenium’s test script authoring GUI can be modified in light of oXygen’s
and Ray’s teachings “to provide an option of selecting an element listed in
results and list of operations that can be performed upon a selected element
of the results.” Ans. 41; see also Ray Tflf 42, 53—55; oXygen 1. We agree
with the Examiner “that this modification would have been obvious to one
of ordinary skill in the art because it is the use of a well-known graphical
user interface feature in the context of XPATH search query results.” Ans.
41; KSR, 550 U.S. at 417 (“[I]f a technique has been used to improve one
device, and a person of ordinary skill in the art would recognize that it would
improve similar devices in the same way, using the technique is obvious
unless its actual application is beyond his or her skill.”). We also agree with
the Examiner “that the claims merely recite ‘operations that can be
performed upon a selected element of the results,’ and do[] not recite the
specific operations that can be performed” — thus, Ray’s “save” and “print”
options are not precluded. See Ans. 41—42 (citing oXygen 1).
(7) Generating XPATH expression from text string
Appellants argue the combination of Selenium, Foulger, Fu, Ray,
oXygen, and Abe fails to teach or suggest:
13
Appeal 2016-004065
Application 12/950,176
wherein said search section of the graphical user
interface is a section for which the user is prompted to input a
text string, wherein the generated XPATH expression is
automatically generated from the text string input into the
search section, wherein the search XPATH expression is the
generated XPATH expression,
as recited in dependent claim 3.3 Br. 24. Specifically, Appellants argue
Selenium and Abe’s teachings fail to teach or suggest the disputed
limitation. Id. As to Selenium, Appellants argue it instead teaches inputting
an XPATH expression and “locating elements using a target field,” which
does not teach “executing searches of GUI elements.” Id. at 25. As to Abe,
Appellants argue it instead teaches a user selecting an element in source
code, and in response to the selection, providing an XPATH expression
corresponding to the element. Id. Appellants contend Abe fails to teach or
suggest “inputting a text string and then automatically generating an
XPATH expression from the text string input for executing searches of GUI
elements.” Id.
The Examiner finds, and we agree, the combination, particularly the
combined teachings of Selenium and Abe, teaches or suggests the disputed
limitation. Ans. 44-45. As to Selenium, the Examiner finds, and we agree,
it teaches “entering [an] XPath expression into a target field to locate UI
elements in XML documents, where the XPath [expression] is entered in a
tool that is used to build test cases.” Ans. 44 (citing Selenium 6; 15 (§ 4.1);
26—27 (§§ 4.8.3^4.8.5); 37; 39-40 (§ 5.2.5)). We agree with the Examiner
that “the use of XPath expression in Selenium to locate UI elements in XML
3 Appellants make reference to a “search engine” limitation. Br. 24.
However, no such limitation is present in the claims as presented in the
Claim Appendix. Br. 31—37.
14
Appeal 2016-004065
Application 12/950,176
documents is searching of the XML documents for nodes using the XPath
expression.” Id.
As to Abe, the Examiner finds, and we agree, it teaches or suggests
“automatically generating XPATH expressions from text strings.” See id.
(citing Abe 4, rt. col., 13 (finding Abe teaches “[a] user can select text
content and choose the ‘by text string’ and its submenu items to create
XPath expressions containing the text content)); see also Abe 2, rt. col., last
para.; 3, It. col., Tflf 1—2). The Examiner, thus, finds, and we agree, that the
combined teachings of Selenium and Abe teach, or at least suggest, inputting
text into a field, generating an XPATH expression from the text, and using
the generated XPATH expression as the search XPATH expression for
searching XML documents for UIs.
(8) Motivation to combine Abe
Appellants argue that the Examiner’s cited motivation to combine
(i.e., “to allow a user an option of more easily generating an XPath
expression instead of manual creation”) Abe’s teachings with the teachings
of the cited combination (e.g., Selenium’s teachings) is “flawed.” Br. 24.
Appellants argue Selenium already provides alternatives for text searching
(i.e., locating by identifier, locating elements by ID, locating elements by
name), which do not generate an XPATH expression. Id. (citing Selenium
37—38 (§§ 5.2.2—5.2.4)); see also id. (citing Selenium 40 (teaching “selection
by FIREFOX plugin to create X-Path”)). Appellants contend, thus, “[o]ne
would not be motivated to modify the explicit teachings of Selenium that
perform a given function to perform it i[n] a manner not contemplated,
which is less efficient (in context of Selenium).” Br. 24. Appellants also
argue “there would be no need to generate an XPATH expression . . . when
15
Appeal 2016-004065
Application 12/950,176
entering a location by identity, which will even be populated with a pull
down.” Id. (citing Selenium 26—27 (§ 4.8.5)).
The Examiner finds, and we agree, that Abe is properly combined
with Selenium. Ans. 43. The Examiner finds, and we agree, modifying
Selenium’s teachings with Abe’s teachings provides “alternative ways of
inputting XPATH expressions, via text.” Id. The Examiner further reasons,
and we agree, “[w]hen the task of manually entering an XPATH expression
is tedious or more time consuming, providing some logic to generate a
XPATH expression from text (such as taught by Abe), would be desirable.
This would allow a user to more easily enter the XPATH expression.” Id.
The Examiner finds this would provide an additional alternative for
inputting XPATH expressions — providing additional “alternative ways of
entering [an] XPATH expression instead of manual creation [is not] flawed.”
Id.', see also KSR, 550 U.S. at 417 (“[I]f a technique has been used to
improve one device, and a person of ordinary skill in the art would recognize
that it would improve similar devices in the same way, using the technique is
obvious unless its actual application is beyond his or her skill.”).
(9) Two different user input sections
Appellants argue the combination of Selenium, Foulger, Fu, Ray,
oXygen, and Sarwono ’831 fails to teach or suggest:
wherein said search section comprises at least two
different user input sections, comprising an XPATH input
section and a text input section, wherein a user inputs the search
XPATH expression in the XPATH input section and wherein
the user inputs the text string from which the generated XPATH
expression is automatically generated using the text input
section,
16
Appeal 2016-004065
Application 12/950,176
as recited in dependent claim 4. Br. 25. Appellants argue “Selenium does
not disclose any such search section for searching GUI elements.” Id. As to
Sarwono ’831, Appellants argue it instead teaches “a display page of a user
interface which includes few areas. Such display page is not a part of a
search engine associated with a test script authoring GUI for searching GUI
elements.” Id.
The Examiner finds, and we agree, the combination, particularly the
combined teachings of Selenium and Sarwono ’831, teaches or suggests the
disputed limitation. Ans. 45 46. As to Selenium, the Examiner finds, and
we agree, it teaches or suggests “a search section which searches GUI
elements using a search engine associated with a test script authoring GUI.”
Id. at 45. Selenium also teaches or suggests “entering [an] XPath expression
into a target field to locate UI elements in XML documents,. . . [which] is
searching of the XML documents for UI elements using the XPath
expression.” Id. at 45 46. As to Sarwono ’831, the Examiner finds, and we
agree, it teaches or suggests “two different user input sections, an XPath
input section (i.e., an advanced query expression area that allows a user to
specify the query as an arbitrarily complex XPath expression . . ., and a text
input section (i.e., a text box allows the user to enter an arbitrary
expression).” Id. at 46 (citing Sarwono ’831 Fig. 8B, 138). The Examiner
finds, and we agree, that the combination’s teachings, including the
combined teachings of Selenium and Sarwono ’831, teach, or at least
suggest, the disputed limitation, including “using XPATH expressions in a
test script authoring GUI to search for GUI elements” and “hav[ing] two
different user input[s] for inputting the XPATH expression used to search
17
Appeal 2016-004065
Application 12/950,176
for GUI elements, the two different user input areas would be an XPath
input section and a text input section, as similarly taught by Sarwono.” Id.
(10) Combining Sarwono ’831
As to combining Sarwono ’831 with the other cited references in the
combination, Appellants argue (i) Sarwono ’831 “is non-analogous art to
Selenium, Foulger, Fu, Oxygen, and/or Ray,” (ii) the Examiner cites
insufficient motivation to combine, and (iii) combining with Sarwono ’831
would negatively impact Selenium’s principle of operation. Br. 26. More
specifically, Appellants argue (i) Sarwono ’831 is non-analogous art because
it “is for a user interface for a designed configuration monitor (DCM),”
(ii) the Examiner finds the combination “‘might be desirable,”’ but provides
no sound, articulated reasoning, and (iii) “the Selenese command requires a
single target (which is already an overloaded variable for entry),” and thus,
the combination “would disrupt the intended functioning of Selenese, for no
good reason.” Id.
The Examiner finds, and we agree, Sarwono ’831 is properly
combined with the cited references of the combination, including Selenium.
Ans. 47. The Examiner finds, and we agree, Selenium and Sarwono ’831
are analogous art because they are reasonably pertinent to the particular
problem with which the inventor is involved (i.e., how to enter an XPATH
expression). Id. The Examiner finds “Selenium shows a field where an
XPATH expression is entered.” Id. As to Sarwono ’831, the Examiner
finds it “teaches additional ways of inputting an XPATH expression by
providing two different fields, one field for entering text from which
XPATH is generated, or another field for entering XPATH.” Id. The
Examiner finds, and we agree, one of ordinary skill in the art would have
18
Appeal 2016-004065
Application 12/950,176
combined these teachings “to allow the user to more easily construct the
XPATH expression.” Final Act. 21—22. The Examiner also finds, and we
agree, modifying “Selenium to include an additional way of inputting the
XPATH expression, i.e., via text, would not disrupt the intended functioning
of Selenese,. . . [but rjather, this modification would expand on existing
XPATH input mechanism[s].” Ans. 47.
(11) Search tool
Appellants argue the combination of Selenium, Foulger, Fu, Ray, and
oXygen fails to teach or suggest “wherein the search section is a part of a
search tool associated with the test script authoring graphical user interface
to enable a user to search the XML-based code documents for graphical user
interface elements in an application under test,” as recited in dependent
claim 5. Br. 26—28. Appellants argue “[S]elenium does not provide any
search tool for the tester to search for elements in the application.” Br. 27.
According to Appellants, Selenium’s “target field merely indicates a
position for providing element location expression. The target field is not
any search engine through which the user can search for the graphical user
interface elements for identifying a location of the element.” Id. (citing
Selenium 26 (§ 4.8.3)). Appellants also argue Selenium teaches that “the
target field and result are not part of a Firefox browser (they are Web
content rendered within a browser)” and “text rending of a source (shown
when you select a source tab of Selenium and otherwise disappears)” fails to
teach the disputed limitation. Br. 28 (citing Selenium 15 (§ 4.1), 26
(§§ 4.8.3 4.8.5). 39(§ 5.2.5)).
The Examiner finds, and we agree, the combination, and Selenium in
particular, teaches or suggests the disputed limitation. Ans. 48; Final Act.
19
Appeal 2016-004065
Application 12/950,176
11—12. The Examiner finds, and we agree, Selenium teaches a “search tool
associated with the test script authoring graphical user interface to enable a
user to search the XML-based code documents for graphical user interface
elements in an application under test (i.e., the XPath expression entered into
a target field is used to locate UI elements in XML documents).” Final Act.
12 (citing Selenium 6, 15 (§ 4.1), 26-27 (§§ 4.8.3^.8.5), 37, 39^10
(§ 5.2.5)). The Examiner also finds, and we agree, Selenium teaches or
suggests that the graphical user interface having the search section and the
result section is part of the test script authoring graphical user interface. See
Final Act. 12 (citing Selenium 15 (§ 4.1), 26—27 (§§ 4.8.3, 4.8.5)); see also
Ans. 48 (finding claim 5 “recites only searching using an XPath expression
and does not provide any further details on how that searching is
performed”).
(12) XML-based software application
Appellants argue the combination of Selenium, Foulger, Fu, Ray,
oXygen, and Malcolm fails to teach or suggests “that the XML based
software application results from interpreting the one or more XML based
source code documents,” in accordance with dependent claim 6. Br. 28—29.
Appellants argue Malcolm instead teaches “a conventional technique of
generating web pages . . . generated by [a] browser application when a user
requests to display a web page on screen.” Br. 28 (citing Malcolm col. 4,11.
18—22). Appellants argue “[generating web pages using a conventional
technique has nothing to do with interpreting a searched source code
document presented on an element selection assistant interface of a software
testing system.” Br. 29.
20
Appeal 2016-004065
Application 12/950,176
The Examiner finds, and we agree, the combination teaches or
suggests the disputed limitation. Ans. 49; Final Act. 22—26. The Examiner
finds claim 6 requires that “the results of searching the source code file is
presented in the results section of an element selection assistance interface.”
Id. The Examiner finds, and we agree, “Selenium teaches presenting an
application user interface generated from at least one source code file within
a screen (i.e., displaying a webpage within a browser, where the webpage is
generated from page source (e.g., HTML).” Id. (citing Selenium 26
(§§ 4.8.3^4.8.4) (finding “the webpage is the application user interface, and
the page source (e.g., HTML) is the source code from which the webpage is
generated”)). The Examiner also finds Selenium teaches or suggests that
“the page source is the source code file that is being queried using the
XPATH expression.” Id. (citing Selenium 26—27 (§§ 4.8.3^4.8.5)). As to
Malcolm, the Examiner finds, and we agree, it teaches or suggests “that a
browser interprets XML based source code documents] to generate web
pages.” Id. (citing Malcolm col. 4,11. 18—22). We agree with the Examiner
and conclude it would have been obvious to one of ordinary skill in the art
“that the web page generated in Selenium from the page source that is being
queried using the XPATH expression is generated through an interpretation
of the page source.” Id.
(13) Whether Malcolm is non-analogous art
Appellants argue Malcolm is non-analogous art because it is (i) “in a
different field from any of the five references [(Selenium, Foulger, Fu, Ray,
Oxygen)] with which it is being combined” and (ii) “not directed to solving
a problem with XPATH or with text script development GUIs.” Br. 29.
21
Appeal 2016-004065
Application 12/950,176
The Examiner finds, and we agree, Malcolm is analogous art because
it is in the same field of endeavor as the claimed invention, including as it
relates to web page generation from a source code file (e.g., XML). Ans. 49
(citing Malcolm col. 4,11. 18—22).
(14) Combining Malcolm
Appellants argue that the Examiner fails to provide sufficient
motivation to combine Malcolm with the other cited references in the
combination. Br. 29. Specifically, Appellants argue that the Examiner’s
reasoning that “it is well known that a web browser generates web pages by
interpreting an XML based source document” is insufficient. Id. Appellants
also argue “[a] server generates web pages, not a browser. A browser
renders pages written in many different languages. XML is not the proper
language for all types of content.” Id.
The Examiner finds, and we agree, Malcom is properly combined
with the cited references in the combination. Final Act. 22—23. The
Examiner finds, and we agree, it would have been obvious to one of ordinary
skill in the art “that the XML based software application of Selenium results
from interpreting the one or more XML based source code documents as
taught by Malcolm because Selenium teaches a browser displaying web
pages based on source code.” Id. (citing Selenium 26—27 (§§ 4.8.2, 4.8.3);
Malcolm col. 4,11. 18—22 (finding, as is well known in the art, Malcolm
teaches a web browser generates web pages by interpreting an XML based
source code document)).
22
Appeal 2016-004065
Application 12/950,176
CONCLUSION
Based on our findings above, we sustain the Examiner’s rejections of
claims 1, 3—6, 16, and 22, as well as the remaining claims on appeal as
Appellants either do not provide separate arguments for their patentability or
rely on their arguments made with respect to claims 1 and 3—6.
DECISION
We affirm the Examiner’s decision rejecting claims 1—7 and 16—28.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(l)(iv).
AFFIRMED
23