Ex Parte Levi

Patent Trial and Appeal Board

Nov 18, 2016

13450788 (P.T.A.B. Nov. 18, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR
13/450,788 04/19/2012 DORONLEVI
56436 7590 11/22/2016
Hewlett Packard Enterprise
3404 E. Harmony Road
Mail Stop 79
Fort Collins, CO 80528
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.
82963818 3532
EXAMINER
MILLER, VIV AL
ART UNIT PAPER NUMBER
2197
NOTIFICATION DATE DELIVERY MODE
11/22/2016 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):
hpe.ip.mail@hpe.com
mkraft@hpe.com
chris.mania@hpe.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte DORON LEVI
Appeal2015-006820
Application 13/450,788 1
Technology Center 2100
Before JEAN R. HOMERE, JOHN A. EV ANS, and
DANIEL J. GALLIGAN, Administrative Patent Judges.
Per Curiam.
DECISION ON APPEAL 2
Appellant seeks our review under 35 U.S.C. § 134(a) of the
Examiner's final rejection of claims 1-15. We have jurisdiction under
35 U.S.C. § 6(b).
We affirm.
1 The Appeal Brief identifies as the real party in interest Hewlett-Packard
Development Company, LP, a wholly-owned affiliate of Hewlett-Packard
Company, having HPQ Holdings, LLC, as its general or managing partner.
App. Br. 3.
2 Our Decision refers to Appellant's Appeal Brief filed March 4, 2015
("App. Br."); Appellant's Reply Brief filed July 16, 2016 ("Reply Br.");
Examiner's Answer mailed May 21, 2015 ("Ans."); and original
Specification filed April 19, 2012 ("Spec.").
Appeal2015-006820
Application 13/450,788
STATEMENT OF THE CASE
Claims on Appeal
Claims 1, 5, and 15 are independent claims. Claim 1 is reproduced
below (with disputed limitations in italics):
1. A testing system for an integrated software system comprising:
a mock object implemented as machine executable instructions
on a first non-transitory computer readable medium, the mock object
implemented as a stateless proxy associated with a corresponding real
object in the integrated software system; and
a scenario, implemented as machine executable instructions on
one of the first non-transitory computer readable medium and a
second non-transitory computer readable medium, to store
configuration data for the mock object representing methods
associated with the real object.
Li et al.
Kinnucan et al.
i\tkin et al.
References
US 2007/0277158 Al
US 2008/0092111 Al
us 2008/0256517 i\J
Examiner's Rejections
Nov. 29, 2007
Apr. 17, 2008
Oct. 16, 2008
Claims 1-9 and 11-15 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Atkin and Li. Ans. 3-13.
Claim 10 stands rejected under 35 U.S.C. § 103(a) as unpatentable
over Atkin, Li, and Kinnucan. Ans. 13-14.
ANALYSIS
Claim 1
Appellant contends the Examiner erred in finding Li teaches a "mock
object implemented as a stateless proxy," as recited in independent claim 1
and similarly recited in claims 5 and 15. App. Br. 7, 11, 12. In particular,
2
Appeal2015-006820
Application 13/450,788
Appellant argues that the characteristic of a partner stub calling the mock
object does not indicate whether the mock object is stateless or stateful. Id.
Appellant asserts that Li teaches that "the [partner] stub can call a method
from the mock [object] without reference to an external data source." App.
Br. 8 (citing Li i-f 39). Appellant asserts Appellant's Specification describes
that, because the mock object is stateless, its behavior can only be changed
by changing the scenario and that the mock object cannot be configured.
App. Br. 9 (citing Spec. i-f 22). Appellant contends that a mock object
reacting to input without any external reference indicates that the mock
object is stateful having locally stored behaviors. Reply Br. 5.
The Examiner interprets Appellant's Specification to describe a
"mock object implemented as a stateless proxy" to include a mock object
whose behavior can be changed. Ans. 16 (citing Spec. i-f 22). The Examiner
finds Li teaches that the behavior of the mock object can be changed using
the test cases such that the mock object conforms to the description in
Appellant's Specification of the mock object as a stateless proxy. Ans. 16-
1 7 (citing Li i-f 77). We agree with the Examiner. Li explains how the test
cases change the behavior of the mock object:
Test behavior support: MockObjects may provide some
flexible behavior description and verification mechanism. For
example, EasyMock has three types of MockControl. The
normal one will not check the order of expected method calls.
Another strict one will check the order of expected method
calls. For these two types, an unexpected method call on the
mock object will lead to an Assertion-FailedError. The
remaining nice one is a more loose version of the normal one, it
will not check the order of expected method calls, and an
unexpected method call will return an empty value (0, null,
false).
3
Appeal2015-006820
Application 13/450,788
Li il 79. Li teaches types of MockControl that output values to which the
MockObjects respond. See id. For some types ofMockControls, an
Assertion-FailedError output prevents the MockObject from being invoked
for an out-of-order or unexpected method call; for other types, an empty
value output does not prevent the MockObject from being invoked. See id.
This teaching mirrors Appellant's Specification's description of changing
the behavior of a mock object by replacing the scenario with a new scenario.
App. Br. 9 (citing Spec. i-f 22); Ans. 16 (citing Spec. i-f 22). Thus, the
MockControl in Li teaches the claimed scenario. See Spec. i-f 11.
The scenario 22 can include a programmed collection of steps for
each unique method signature associated with the mocked real object
to model its behavior in response to invocation of the mock object.
For example, the programmed behaviors can include return values,
output and reference parameter values, exception throwing, event
raising, callback execution, and similar behaviors. During execution,
the mock object 12 refers to the scenario 22 to determine how it
should proceed when an associated method is invoked.
Spec. i-f 11. In Li, the MockControl outputs, in response to a method call, a
return value, an Assertion-FailedError or an empty value, to which the
MockObject refers. See Li i-f 79. Li teaches that a MockObject with no
apparent locally stored behaviors reacts to input with the external reference
of the MockControl. See Li i-f 79. This indicates that the mock object is
stateless. See Reply Br. 5. Thus, we find the evidence supports the
Examiner's finding that Li teaches or suggests a mock object implemented
as a stateless proxy. In view of the foregoing, we sustain the rejection of
claim 1. Appellant does not present additional persuasive arguments
regarding dependent claims 2--4, and, therefore, we sustain the rejection of
these claims.
4
Appeal2015-006820
Application 13/450,788
Claims 5 and 15
Appellant argues Atkin does not teach "generating a scenario as a
hierarchical data object in which configuration parameters for each of a
plurality of methods associated with a mock object are related to an
associated method signature," as recited in claims 5 and 15. App. Br. 11, 12.
Specifically, Appellant contends Atkin teaches "the use of a captor code to
record methods for the creation of the mock objects themselves, not the
recited scenario." App. Br. 11 (citing Atkin i-f 84); Reply Br. 6-7. The
Examiner finds Atkin teaches the captor code monitors the previous
execution to determine how the mock object reacts to certain method calls
used to generate unit test cases. Ans. 20-21 (citing Atkin i-f 84 ).
The Examiner finds the unit test cases in Atkin act as the recited
scenario. Ans. 21. We agree with the Examiner's findings, which are
consistent with how the claimed subject matter is described in Appellant's
Specification. For example, Appellant cites paragraph 19 of Appellant's
Specification as support for the claimed subject matter. App. Br. 5 (citing
Spec. i-f 19). Paragraph 19 provides, in part: "[A] recording component can
be used to capture the desired behavior of the mock object and store it in the
scenario, which is a complex data structure called that relates the
configuration uniquely to type and method signatures associated with the
mock object." The Examiner finds the captor code in Atkins teaches the
recording component described in Appellant's Specification which is used in
the generation of unit test cases. See Ans. 20-21 (citing Atkin i-f 84). As
Appellant notes, Atkin teaches the mock objects are generated before the
unit test cases. Reply Br. 7 (citing Atkin i-fi-143, 84). Similarly, Appellant's
5
Appeal2015-006820
Application 13/450,788
Specification describes that the mock object exists before the scenario. See
Spec. ,-r 19.
As such, we are not persuaded of error in the Examiner's rejection of
claims 5 and 15, and we sustain the rejection of claims 5 and 15. Appellant
does not present additional persuasive arguments regarding dependent
claims 6-14 which depend from claim 5 (App. Br. 11-12), and, therefore,
we sustain the rejections of these claims.
DECISION
We affirm the Examiner's rejection of claims 1-15.
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
6