Ex Parte Cooper et al

Patent Trial and Appeal Board

May 24, 2018

14934496 (P.T.A.B. May. 24, 2018)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
14/934,496 11/06/2015
87334 7590 05/29/2018
IBM END IPLA W (GLF)
c/o Garg Law Firm, PLLC
4521 Copper Mountain Lane
Richardson, TX 75082
FIRST NAMED INVENTOR
Steven Cooper
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
ATTORNEY DOCKET NO. CONFIRMATION NO.
CA920 l 50096US 1 1024
EXAMINER
MITCHELL, JASON D
ART UNIT PAPER NUMBER
2199
NOTIFICATION DATE DELIVERY MODE
05/29/2018 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):
uspto@garglaw.com
dpandya@garglaw.com
garglaw@gmail.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte STEVEN COOPER and MICHAEL S. FULTON
Appeal2017-008188
Application 14/934,496
Technology Center 2100
Before DENISE M. POTHIER, JOHNNY A. KUMAR, and
JOHN D. HAMANN, Administrative Patent Judges.
POTHIER, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE
Appellants 1,2 appeal under 35 U.S.C. § 134(a) from the Examiner's
rejection of claims 1-20. App. Br. 4. We have jurisdiction under 35 U.S.C.
§ 6(b ). We affirm.
1 Throughout this opinion, we refer to the Final Action (Final Act.) mailed
July 15, 2016, the Appeal Brief (App. Br.) filed December 1, 2016, the
Examiner's Answer (Ans.) mailed March 10, 2017, and the Reply Brief
(Reply Br.) filed May 8, 2017.
2 The real party in interest is listed as International Business Machines
Corporation. App. Br. 2.
Appeal2017-008188
Application 14/934,496
Invention
Appellants' invention relates to code coverage analysis and, more
specifically, code coverage analysis that uses automatic breakpoints. See
Spec. ,r 1. Code coverage analysis determines which code portions are
executed during a run by using test cases designed to execute portions of
code. Id. ,r,r 2-3. As described, the process selects a code portion for
analysis based on a historical code analysis report ( e.g., identifies a
fine-grained portion that has escaped sufficient testing), inserts a breakpoint
at the code portion using a code coverage breakpoint instruction, and
analyzes only the selected code portion. Id. ,r,r 5, 35 and Abstract.
Claim 1 is reproduced below with emphasis:
1. A method comprising:
selecting, using a processor and a memory, from a code,
a portion for code coverage analysis, the portion being a single
line of the code such that the single line of the code is not
directly referenceable by another line of the code;
constructing an instruction to insert a code coverage
breakpoint at the portion such that the code coverage analysis
is performed only for the portion while omitting the code
coverage analysis of a remainder of the code;
causing, using the instruction, a code coverage analysis
tool to execute the code without performing the code coverage
analysis until the code coverage breakpoint;
further causing, responsive to the instruction, the code
coverage analysis tool to end the code coverage analysis after
the portion and resume executing the code without performing
the code coverage analysis; and
outputting a report of the code coverage analysis of the
portion.
2
Appeal2017-008188
Application 14/934,496
The Examiner relies on the following as evidence of unpatentability:
Plum
Kaneshiro
Farchi
us 5,758,061
us 5,950,003
US 2003/0093716 Al
The Rejections
May 26, 1998
Sept. 7, 1999
May 15, 2003
Claims 1, 2, 5-12, and 15-20 are rejected under 35 U.S.C. § 103 as
unpatentable over Farchi and Plum. Final Act. 5-10.
Claims 3, 4, 13, and 14 are rejected under 35 U.S.C. § 103 as
unpatentable over Farchi, Plum, and Kaneshiro. Id. at 10-12.
THE OBVIOUSNESS REJECTION OVER F ARCHI AND PLUM
Claims 1, 2, 5---8, 11, 12, and 15-20
Regarding representative claim 1, 3 the Examiner finds Farchi teaches
or suggests its limitations, including (a) constructing an instruction to insert
a code coverage breakpoint at a code portion and (b) using the instruction,
causing a code coverage analysis tool to execute the code without
performing the analysis until the code coverage point and only for the
portion while omitting a remainder of the code. Final Act. 6 (citing Farchi
,r,r 84, 86, 87 and steps 510/518 in Figure 5). The Examiner turns to Plum to
illustrate further that one skilled in the art would have known to perform
code coverage analysis on only a selected code portion and proposes to
include this teaching in Farchi' s process to improve and optimize testing.
Id. at 7-8 (citing Plum 3:28-36); see also Ans. 11.
3 Appellants argue claims 1, 2, 5-8, 11, 12, and 15-20 together. App. Br.
9-12. We select claim 1 as representative. See 37 C.F.R. § 4I.47(c)(l)(iv).
3
Appeal2017-008188
Application 14/934,496
ISSUES
We review the appealed rejections for error based upon the issues
identified by Appellants in their Appeal Brief, and in light of the arguments
and evidence produced thereon. Cf Ex parte Frye, 94 USPQ2d 1072, 107 5
(BPAI 2010) (precedential) (citing In re Oetiker, 977 F.2d 1443, 1445 (Fed.
Cir. 1992)). "Any arguments or authorities not included in the appeal brief
will be refused consideration by the Board for purposes of the present
appeal." 37 C.F.R. § 4I.37(c)(l)(vi).
Under§ 103, has the Examiner erred in rejecting claim 1 by finding
Farchi and Plum collectively would have taught or suggested
(I) "constructing an instruction to insert a code coverage breakpoint at
the [code] portion" for code coverage analysis and
(II) "causing ... a code coverage analysis tool to execute the code
without performing the code coverage analysis until the code coverage
breakpoint" using the instruction?
ANALYSIS
Based on the record before us, we are not persuaded of error in the
Examiner's rejection of claim 1.
I.
Appellants argue Farchi fails to teach the recited "instruction
constructed and operated in the manner of claim 1," namely an instruction to
insert a breakpoint as recited. App. Br. 11; Reply Br. 2-3. Appellants also
contend the combination fails to cure the purported deficiencies. App. Br.
12. We are not persuaded.
4
Appeal2017-008188
Application 14/934,496
Claim 1 recites, in relevant part, "constructing an instruction to insert
a code coverage breakpoint at the portion." Farchi teaches inserting
coverage points into a new/modified version of a program source code
corresponding to new/modified block. Farchi ,r 84 (step 510, Fig. 5), cited
in Final Act. 6. Although inserting coverage points (e.g., breakpoints) into
code does not explicitly teach "constructing an instruction to insert a code
coverage breakpoint" as recited, such a teaching suggests to an ordinarily
skilled artisan that some message or command (e.g., an instruction) was
issued in order for the disclosed insertion of coverage points to occur. See
Farchi ,r 84.
To elaborate, the Examiner cites an additional paragraph in Farchi,
explaining generating the exemplary PRINT statement ( e.g., an instruction)
"constitutes the claimed construction of an instruction." Ans. 10 ( citing
Farchi ,r 55 4). That is, the process of generating such a statement-not the
actual statement itself-amounts to constructing a message or command
(e.g., an instruction) to create the PRINT statement (e.g., a coverage point)
and insert the statement into the source code as a breakpoint. See Farchi
,r,r 55, 84. We thus disagree with Appellants that the Examiner has
misconstrued Farchi's teachings or has found Farchi's PRINT statement is
the "instruction" in claim 1. See Reply Br. 2.
The Examiner's position is further supported by Farchi, teaching that
an ordinary artisan "will recognize that insertion of the coverage points into
the program source code ... is done by conventional methods using an
existing code coverage tool or an instrumentor." See id. ,r 55. When
4 Farchi also teaches "a coverage point can be inserted as a C macro or a
function call before ... each coverage task." Farchi ,r 55.
5
Appeal2017-008188
Application 14/934,496
accounting for the inferences and creative steps that an ordinary artisans
would have employed, we determine one such known, conventional method
would have included issuing a command or message ( e.g., constructing an
instruction) to a code coverage tool or instrumentor to create the taught
statement, macro, or call (see id.), as a coverage points inserted into the
source code. See KSR Int 'l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007).
Farchi thus suggests the disputed step of "constructing an instruction
to insert a code coverage breakpoint at the portion" in claim 1.
II.
Appellants further assert Farchi does not teach that the generated
instruction "causes the code execution without coverage analysis until the
breakpoint" as claim 1 recites. App. Br. 11 (bolding omitted). Specifically,
Appellants contend Farchi's silence about how previously collected code
coverage data is preserved does not reasonably teach or suggest "whether the
preservation is done by not performing coverage analysis on the old data."
App. Br. 11 ( citing Farchi ,r,r 86-87). In the Reply Brief, Appellants also
argue the PRINT statement does not cause a code coverage analysis tool to
execute code without performing the code coverage analysis until the
breakpoint. Reply Br. 2-3.
As to the latter assertion, we noted above the Examiner has not found
the PRINT statement to be the instruction, but rather the statement inserted
into source code as a coverage point is generated based on an instruction.
Additionally, the recitation, "causing, using the instruction, a code coverage
analysis tool to execute the code without performing the code coverage
analysis until the code coverage breakpoint," does not require that the
instruction directly causes a code coverage analysis tool to execute the code.
6
Appeal2017-008188
Application 14/934,496
App. Br. 15 (Claims App'x). Rather, the instruction is used in some manner,
including indirectly, to cause the code coverage analysis tool to execute the
code as recited in claim 1.
Farchi teaches or suggests a conventional test coverage tool used to
execute a program with test cases and to collect code coverage data for the
new and modified coverage tasks. Farchi ,r 86 (step 518, Fig. 5). Farchi's
step 518 follows from steps 510-516, which involve inserting and
modifying coverage points in source code for new and modified coverage
tasks (step 510), compiling the modified source code into a program
executable (step 512), and identifying test cases to run on the new and
modified coverage tasks (step 514). Id. ,r,r 84--85, Fig. 5. Farchi would not
run the program executable with the test cases ( e.g., cause its test coverage
"tool to execute the code" as recited) as described at step 518 but for these
prior steps. Also, as previously explained, step 510 would not occur without
some command or instruction to insert coverage points into the source code
for the new and modified tasks. Thus, contrary to Appellants' contentions
(App. Br. 11), the operation in Farchi at steps 510 through 518 are "[the]
result of the instruction" (App. Br. 11) (bolding omitted), and Farchi teaches
or suggests "using the instruction" to cause "a code coverage analysis tool to
execute code" as broadly recited in claim 1.
As to Appellants' other assertions, we disagree that Farchi is silent
regarding how previously collected code coverage data is preserved. App.
Br. 11. Farchi suggests preservation is done without performing coverage
analysis on the old data. For example, when describing preserving "[t]he
previously collected code coverage data for all other not affected coverage
tasks," F arc hi states " [ t ]his eliminates the need to rerun the test cases for
7
Appeal2017-008188
Application 14/934,496
code that was not modified." Farchi ,r 81; see id. ,r,r 88-89 (indicating a test
subset is run on an executable saving time). Farchi further states old
columns ( e.g., 420, 422, 424, and 426) in the code coverage database table
are preserved and new columns ( e.g., 428, 430, and 432) contain no
coverage data "indicating the need for further code coverage data
collection." Id., Fig. 4. By teaching eliminating rerunning test cases on
unmodified code, Farchi reasonably suggests to one skilled in the art its code
coverage tool executes the program executable "without performing the code
coverage analysis until the code coverage breakpoints" and "omit[ s] the
code coverage analysis of a remainder of the code" (e.g., rerunning test cases
only on modified code) as recited. See id. ,r,r 81, 85-89; see also Ans. 11.
Even so, the rejection also cites to Plum to teach performing code
coverage analysis on a selected code portion is known in the art and
combining its teachings with Farchi would predictably result in the disputed
"causing" step in claim 1. Final Act. 7-8 (citing Plum 3:28-36). Appellants
do not challenge Plum or its teachings noted by Examiner in its brief. See
generally App. Br. 9-12.
For the first time in the Reply Brief, Appellants assert the Examiner
misinterprets Plum. Reply Br. 4--5. Such arguments are waived. See 37
C.F.R. § 4I.41(b)(2) (stating "[a]ny argument raised in the reply brief which
was not raised in the appeal brief, or is not responsive to an argument raised
in the examiner's answer ... will not be considered by the Board for
purposes of the present appeal, unless good cause is shown."). In any event,
the Examiner does not cite Plum to teach removing "the instruction" prior to
recompiling the code as asserted. Reply Br. 4. Rather, when combining
Plum's teaching with Farchi, the Examiner states one skilled in the art would
8
Appeal2017-008188
Application 14/934,496
have recognized removing breakpoints, which are distinct from the recited
"instruction" as explained above, related to old and unmodified code
coverage tasks from the program executable to improve and optimize
testing. See Ans. 11; see also Final Act. 7-8.
For the foregoing reasons, Appellants have not persuaded us of error
in the rejection of independent claim 1, and claims 2, 5-8, 11, 12, and 15-20
not separately argued.
Claims 9 and 10
Regarding dependent claim 9, Appellants argue "Li]ust as the
combination fails to teach or suggest the non-referenceable nature of the
(first) single line of code, the combination also fails to teach or suggest the
same nature of the second single line of code." App. Br. 12. As for
dependent claim 10, Appellants assert "[t]he combination is deficient in
teaching or suggesting the additional property as to the test case to be used
with the second portion or second single line." Id. at 13. Appellants merely
point out what claims 9 and 10 recite and then assert that the combination
fails to teach these limitations. Such contentions are not considered separate
arguments for patentabiHty. See In re Lovin, 652 F.3d 1349, 1357 (Fed. Cir.
2011); see also 37 C.F.R. § 4I.37(c)(l)(iv). In any event, to the extent these
discussions are considered patentability arguments, we adopt the Examiner's
findings as our own. Ans. 12-13; see also Final Act. 9-10. Accordingly,
Appellants have not persuaded us of error in the rejection of claims 9 and 10.
9
Appeal2017-008188
Application 14/934,496
THE REMAINING OBVIOUSNESS REJECTION
For this rejection, Appellants argue the additionally cited reference,
Kaneshiro, when combined with Farchi and Plum "fail[] to overcome the
above-described distinctions of claim 1." App. Br. 13. In addressing claim
1 above, we determined Farchi and Plum do not have the deficiencies
alleged. We thus are not persuaded of error and need not consider whether
Kaneshiro overcomes the purported distinctions. See id. Accordingly,
Appellants have not persuaded us of error in the rejection of claims 3, 4, 13,
and 14.
DECISION
We affirm the Examiner's rejections of claims 1-20 under§ 103.
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
10