Ex Parte Mathur et al

Patent Trial and Appeal Board

Sep 7, 2017

13410965 (P.T.A.B. Sep. 7, 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.
13/410,965 03/02/2012 Ashish K. Mathur IN920100138US2 9144
37945 7590 09/11/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
09/11/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-004916
Application 13/410,9651
Technology Center 2100
Before KRISTEN L. DROESCH, CATHERINE SHIANG, and
JOHN D. HAMANN, Administrative Patent Judges.
HAMANN, 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—20. 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. 12. 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-004916
Application 13/410,965
1. A method for augmenting manual test script authoring
comprising:
determining of a software application associated with a
test script presented within a user interface of an automated
software testing system by an element selection assistant,
wherein said software application is written in a language based
upon an extensible markup language (XML) supporting use of
an XPATH query language;
receiving user-entered search data via an element
selection assistant interface associated with the element
selection assistant, wherein the user-entered search data is an
XPATH expression;
determining and providing suggestions to the user to
refine the user-entered search data;
querying at least one source code file associated with the
software application using the user-entered search data;
presenting within the element selection assistant interface
associated with a test script authoring graphical user interface,
results of the querying of the at least one source code file; and
providing within the element selection assistant interface
associated with the test script authoring graphical user interface,
an option of selecting an element listed in the results and list of
operations that can be performed upon a selected element of the
results.
REJECTIONS2 ON APPEAL
(1) The Examiner rejected claims 1,3,6, 8, 9, and 18—20 under
35 U.S.C. § 103(a) as being unpatentable over the combination of
2 The Examiner also provisionally rejected claims 1—8, 18, and 19 for
obviousness-type double patenting over claims 1—3, 6, 7, 16—21, and 28 of
copending Application No. 12/950,176. 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 Ex Parte Moncla, 95 USPQ2d 1884, 1885 (BPAI 2010)
(precedential).
2
Appeal 2016-004916
Application 13/410,965
(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 2 and 7 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 claims 4 and 5 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).
(4) The Examiner rejected claims 10-12, 14, and 17 under
35 U.S.C. § 103(a) as being unpatentable over the combination of Selenium,
oXygen, Ray, Whitman et al. (US 6,772,150 Bl; issued Aug. 3, 2004)
(hereinafter “Whitman”), and Sihem Amer-Yahia et al., Personalizing XML
Search in PIMENTO, 2007 IEEE, 906—15 (hereinafter “Amer-Yahia”).
(5) The Examiner rejected claim 13 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Selenium, oXygen, Ray,
Whitman, Abe, and Amer-Yahia.
(6) The Examiner rejected claims 15 and 16 under 35 U.S.C.
§ 103(a) as being unpatentable over the combination of Selenium, oXygen,
Ray, Whitman, Malcolm, Amer-Yahia, and Alexander Falk, XML Spy Tip:
3
Appeal 2016-004916
Application 13/410,965
Using theXPath analyzer to quickly find information in files, XML
Aficionado (Sept. 25, 2007),
(http://www.xmlaficionado.com/2007/09/xmlspy-tip-using-xpath-analyzer-
to.html).
ANALYSIS
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 12, 2015 Final Office Action (“Final Act.” 2—
38) and (2) January 21, 2016 Examiner’s Answer (“Ans.” 2—66). 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
for [its] intended purpose and/or that would change its principle of
operations, which is not permitted.” Br. 12—13. 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 12). Selenese’s commands
are well-defined (i.e., Actions, Assessors, and Assertions), and “consist of a
4
Appeal 2016-004916
Application 13/410,965
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. 34—35. 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. 35 (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. 35. To the
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
5
Appeal 2016-004916
Application 13/410,965
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 KSRInt’l 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) Results
Appellants argue the combination, and Selenium in particular, fails to
teach or suggest “presenting . . . results of the querying of the at least one
source code file,” as recited in claim 1, and recited in commensurate scope
in claims 10 and 18. See Br. 14—16. 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. 14—16 (citing Selenium
18 (§ 4.3), 26 (§ 4.8.3)); see also Br. 15 (citing Selenium 26 (§ 4.8.4)
6
Appeal 2016-004916
Application 13/410,965
(arguing Firefox’s text search function is taught for Selenium code)); Br. 16
(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. 16.
The Examiner finds, and we agree, that the combination teaches the
disputed limitation. See Ans. 35—36. 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. 36 (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. 37 (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
teaching or suggesting presenting the results of the querying of the at least
one source code file, including by displaying the results of a XPATH query
in a window with the XPath query. Id.
Our above reasoning and findings also apply to Appellants’ similar
arguments made with respect to claims 5 and 12.
(3) Combining Selenium, lumlger, and Fu
Appellants argue combining Selenium, Foulger, and Fu is improper
because the Examiner identifies insufficient motivation to combine these
references. See Br. 17—19. Appellants argue the improper combination
7
Appeal 2016-004916
Application 13/410,965
applies to all of the rejections on appeal — each rejection combines at least
these three references. Br. 19.
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. 18. 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. 17 (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. 19. As to Fu, Appellants argue it teaches locating
dynamic Web content and “refining an XPATH expression in a step-by step
fashion.” Br. 17—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
(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. 18—19.
Appellants also argue that applying XPATH queries to Foulger’s teachings
would change Foulger’s principle of operation. Br. 17.
8
Appeal 2016-004916
Application 13/410,965
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 to
determine and provide suggestions to the user to refine the user-
entered search data as similarly taught by Foulger and Fu 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. 14; see also Ans. 40. 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. 40
(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
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. 19) and (ii) applying XPATH queries to Foulger
would change Foulger’s principle of operation (Br. 17) 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.”).
9
Appeal 2016-004916
Application 13/410,965
(4) Whether Foulser is non-analogous art
Appellants argue Foulger is non-analogous art to Selenium and Fu.
Br. 19 (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. 19.
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. 40-41; Br.
39 (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. 41; see also Foulger col. 3,11. 12—25.
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. 41.
“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).
10
Appeal 2016-004916
Application 13/410,965
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] LOG
pane at the same time it executes the Selenium command.” Br. 22.
Appellants also argue the LOG pane “is related to the command for which
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, UI-Element, Rollup). Ans. 44^45 (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
11
Appeal 2016-004916
Application 13/410,965
Results’ would not be a significant restriction 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. 20—21
(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.” Br. 21. 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. 21—22 (citing Fig. 2 (items 260,
265, 270) (disclosing that selecting the object shows the equivalent GUI
element)); see also Br. 39 (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. 42-43. 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. 42; see also Ray ^fl[ 42, 53—55; oXygen 1. We agree
12
Appeal 2016-004916
Application 13/410,965
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.
42; 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. 42-43 (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:
receiving another user-entered search data, wherein the
data type is of a text string data type;
converting the another user-entered search data to the
XPATH expression data type, wherein an XPATH expression
representing the converted search data is in accordance with a
syntax utilized by the XML-based language in which the
software application is written,
as recited in dependent claim 2.3 Br. 24. Specifically, Appellants argue
Selenium and Abe’s teachings fail to teach or suggest the disputed
limitations. Br. 23. As to Selenium, Appellants argue it instead teaches
inputting an XPATH expression and “locating elements using a target field,”
3 Appellants make reference to a “search engine” limitation. Br. 23.
However, no such limitation is present in the claims as presented in the
Claim Appendix. Br. 39-44.
13
Appeal 2016-004916
Application 13/410,965
which does not teach “executing searches of GUI elements.” Id. 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. 45—47. 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. 46 (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
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. at
47 (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., ^fl[ 1—2). The Examiner, thus, finds, and we agree, that the
combined teachings of Selenium and Abe teach, or at least suggest, the
disputed limitations.
14
Appeal 2016-004916
Application 13/410,965
Our above reasoning and findings also apply to Appellants’ similar
arguments made with respect to claims 7 and 13.
(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. 23.
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. 23. Appellants also
argue “there would be no need to generate an XPATH expression . . . when
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. 45 46. The Examiner finds, and we agree, modifying
Selenium’s teachings with Abe’s teachings provides “alternative ways of
entering XPATH expression[s] instead of manual creation, via text.” Id. at
45. 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
15
Appeal 2016-004916
Application 13/410,965
more easily enter the XPATH expression.” Id. at 46. 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. at 45;
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) Interpreting source code
Appellants argue the combination of Selenium, Foulger, Fu, Ray,
oXygen, and Malcolm fails to teach or suggest “interpreting the at least one
source code file,” in accordance with dependent claim 4. Br. 24. 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. 24 (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” file.” Br. 24.
The Examiner finds, and we agree, the combination teaches or
suggests the disputed limitation. Ans. 48 49; Final Act. 24. 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., HTMF)[)].” Ans. 48 (citing Selenium 26 (§§ 4.8.3—
4.8.4) (finding “the webpage is the application user interface, and the page
source (e.g., HTMF) is the source code from which the webpage is
generated”)). The Examiner also finds Selenium teaches or suggests that
16
Appeal 2016-004916
Application 13/410,965
“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. at 48-49 (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. at 49.
Our above reasoning and findings also apply to Appellants’ similar
arguments made with respect to claim 15.
(10) Whether Malcolm is non-analosous 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. 25.
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).
(11) Combining Malcolm
Appellants argue that the Examiner fails to provide sufficient
motivation to combine Malcolm with the other cited references in the
combination. Br. 25. 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
17
Appeal 2016-004916
Application 13/410,965
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. 24. The Examiner
finds, and we agree, it would have been obvious to one of ordinary skill in
the art “that Selenium is operable to interpret the at least one source code file
as taught by Malcolm because Selenium teaches a browser displaying web
pages based on source code . . . and it is well known in the art that a web
browser generates web pages by interpreting an XML based source code
document.” Id. (citing Selenium 26—27 (§§ 4.8.2, 4.8.3); Malcolm col. 4,11.
18-22).
(12) Suggesting to broaden or narrow
Appellants argue the combination of Selenium, Foulger, Fu, Ray, and
oXygen fails to teach or suggest “suggesting via the element selection
assistant interface to broaden or narrow the XPATH expression based on the
results,” as recited in claim 8. Br. 26. More specifically, Appellants argue
that there are “no explicit/inherent/implicit teachings to broaden or narrow
an XPATH expression,” and that although “one could suggest a different
XPATH expression, which would[ not] broaden or narrow an original
expression, it would just change it.” Id.
The Examiner finds, and we agree, the combination teaches the
disputed limitation. See Ans. 51; Final Act. 13. For example, the Examiner
finds, and we agree, “Foulger teaches determining and providing suggestions
to the user to refine user-entered search data (i.e., executable suggestions are
presented that enable a user to further narrow or broaden a search, when a
18
Appeal 2016-004916
Application 13/410,965
search returns too many or too few results[)].” Final Act. 13 (citing Foulger
col. 3,11. 12—25; col. 6,11. 47—55; col. 18,11. 30-39). We also agree with the
Examiner in finding “Fu teaches if an element is not found with [] an XPath
expression, then tags are removed from the XPath expression,” which “is a
way of broadening an XPath expression.” Ans. 51 (citing Fu 145).
(13) Change in accentuation of a GUI element
Appellants argue the combination of Selenium, Foulger, Fu, Ray, and
oXygen fails to teach or suggest “providing within the element selection
assistant interface a user with an ability to select element listed in the results,
wherein the selection of an element in the results precipitate a change in
accentuation of a GUI element linked to the selection,” as recited in claim 9.
Br. 26—27. More specifically, Appellants argue oXygen’s teachings provide
for “[n]o change in accentuation results from a selection of results.” Br. 26.
Appellants also argue the Examiner’s motivation to combine the references
is insufficient (i.e., “Selenium lacks teachings for presenting results of an
XPATH expression,” and thus, the motivation of having a “better”
presentation is flawed). Br. 27. Appellants also argue the Examiner fails to
provide evidence that “‘it is well known that an XPATH expression can
match more than one result, so it is advantageous to allow the user to select
one of the found matches and to visually indicate that selection to further
view or process the match.” Id. Lastly, Appellants argue there is no
teaching as to how Selenium would function if there are multiple results. Id.
The Examiner finds, and we agree, the combination teaches the
disputed limitation. Ans. 52—53. More specifically, the Examiner finds, and
we agree, oXygen teaches or suggests:
19
Appeal 2016-004916
Application 13/410,965
“The results of an XPath query are shown as a list in the results
panel. . . Clicking on a result line will highlight the
corresponding part from the document.” In the figure shown in
this section, the bottom panel shows the results of the XPath
query. This second result in the list,
“/site[l]/chapter/linksection[l]/section[5] - id=“validat” is
selected, as shown by the highlight of the result. In the panel
above, the line “” is highlighted. This
shows that clicking on the second result (i.e., selection of an
element in the results) in the list highlights the corresponding
line in an XML document (i.e., precipitate a change in
accentuation of a GUI element linked to the selection).
Ans. 52 (citing oXygen, Presentation of the XPath Results).
Furthermore, we are unpersuaded by Appellants’ argument (Br. 27)
that the Examiner failed to provide sufficient motivation, including
because Selenium teaches or suggests presenting results, contrary to
Appellants’ premise. See supra § 2. We also are unpersuaded by
Appellants’ remaining arguments, including because (i) oXygen
teaches or suggests multiple results and (ii) one of ordinary skill can
apply their knowledge and experience to the combination’s teachings
to incorporate multiple results. See oXygen, Presentation of the
XPath Results; KSR, 550 U.S. at 420 (“[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.”); Keller, 642 F.2d at 425
(“Combining the teachings of references does not involve an ability to
combine their specific structures.”).
Our above reasoning and findings also apply to Appellants’ similar
arguments made with respect to claims 15, 16, and 18.
20
Appeal 2016-004916
Application 13/410,965
(14) Responsive
Appellants argue the combination of Selenium, Whitman,
Amer-Yahia, Ray, and oXygen fails to teach or suggest, inter alia,
“responsive to a first set of results being more than a threshold,
providing suggestions to narrow the user-entered search data” and
“responsive to a user selection of at least one suggestion, presenting
within the element selection assistant interface associated with a test
script authoring graphical user interface, a second set of results of the
querying of the at least one source code file,” as recited in claim 10.
Br. 27—34. The disputed limitations are conditional steps. During
examination, claims are given their broadest reasonable interpretation
consistent with the specification. See In re Am. Acad, of Sci. Tech
Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004). The broadest reasonable
interpretation encompasses instances in which the prerequisite
condition for the disputed limitation is not met (e.g., a first set of
results is not more than a threshold). Conditional steps employed in a
method claim need not be found in the prior art if, under the broadest
reasonable interpretation, the method need not invoke those steps. See
Ex parte Schulhauser, No. 2013- 007847, 2016 WL 6277792, at *4
(PTAB Apr. 28, 2016) (precedential) (holding “[t]he Examiner did not
need to present evidence of the obviousness of the remaining method
steps of claim 1 that are not required to be performed under a broadest
reasonable interpretation of the claim”); see also Ex parte Katz, No.
2010-006083, 2011 WL 514314, at *^N5 (BPAI Jan. 27, 2011)
(distinguishing conditional limitations in non-method claims).
21
Appeal 2016-004916
Application 13/410,965
CONCLUSION
Based on our findings and reasoning above, we sustain the
Examiner’s rejection of claim(s) (i) 1, 3, 6, 8, 9, and 18—20; (ii) 2 and 7;
(iii) 4 and 5; (iv) 10—12, 14, and 17; (v) 13; and (vi) 15 and 16, as Appellants
fail to provide persuasive arguments for these claims or rely on their
arguments made with respect to other claims.
DECISION
We affirm the Examiner’s decision rejecting claims 1—20.
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
22