Ex Parte Clemm et al

Patent Trial and Appeal Board

Oct 23, 2013

11616571 (P.T.A.B. Oct. 23, 2013)

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.
11/616,571 12/27/2006 Geoffrey M. Clemm CAM920060156US1 (032) 2754
46321 7590 10/24/2013
CAREY, RODRIGUEZ, GREENBERG & O''''KEEFE, LLP
STEVEN M. GREENBERG
7900 Glades Road
SUITE 520
BOCA RATON, FL 33434
EXAMINER
VAUGHN, GREGORY J
ART UNIT PAPER NUMBER
2178
MAIL DATE DELIVERY MODE
10/24/2013 PAPER
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.
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte GEOFFREY M. CLEMM, MUHTAR B. AKBULUT,
AAMER KHAN, and SEAN P. CUDMORE
____________

Appeal 2011-009939
Application 11/616,571
Technology Center 2100
____________

Before TONI R. SCHEINER, ERICA A. FRANKLIN, and ZHENYU
YANG, Administrative Patent Judges.

YANG, Administrative Patent Judge

DECISION ON APPEAL

This is an appeal1 under 35 U.S.C. § 134 involving claims to a
method, system and computer program for managing requirements planning
of requirements for a software system. The Examiner rejected the claims as
anticipated and as obvious. We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.

1 Appellants identify International Business Machines Corporation as the
Real Party in Interest (App. Br. 2).
Appeal 2011-009939
Application 11/616,571

2
STATEMENT OF THE CASE

Claims 1-13 are rejected and on appeal. (App. Br. 2.) Claims 1, 6,
and 9 are independent claims, directed to a requirements planning
management method, data processing system, and computer program,
respectively. (Id. at 3-5.)
Claim 1 is representative of the subject matter on appeal. It reads:
1. A requirements planning management method comprising:
identifying in a requirements planning system executing in
memory of a host computing platform, each approving
stakeholder for a version of a requirement in a requirements
plan of requirements for a software system;
creating traceability links between each approving stakeholder
and the version of the requirement; and,
notifying each approving stakeholder having a traceability link
to the version of the requirement whenever a new version of the
requirement is proposed by a stakeholder.
The Examiner rejected claims 1 and 6-9 under 35 U.S.C. § 102(e) as
anticipated by Peretz.2 The Examiner also rejected claims 2-5 and 10-13
under 35 U.S.C. § 103(a) as obvious over Peretz in view of Livshits.3

FINDINGS OF FACT

1. The Specification explains that “[r]equirements planning relates to the
planning of requirements for a software system. Generally, the

2 Peretz et al., U.S. 2008/0127089 A1, published on May 29, 2008.
3 Livshits, U.S. 2004/0230896 A1, published on November 18, 2004.
Appeal 2011-009939
Application 11/616,571

3
‘requirements’ for a software system refer to a set of artifacts such as
files, records in a database and the like that define the software
system . . . .” (Spec. ¶ [0002].)
2. Each independent claim (claims 1, 6, and 9) recites “a requirements plan
of requirements for a software system.” (App. Br. 12, 14, and 15.)
3. Peretz relates to managing all stages of software life cycle. (Peretz
¶¶ [0001], [0003].) “A life cycle begins with an idea or a need that can
be satisfied wholly or partly by software . . . .” (Id. at ¶ [0002].) One of
the primary processes in a life cycle involves the acquisition, during
which “system requirements are defined, typically by the user or the
client.” (Id.)
4. Peretz teaches:
Broadly stated, the lifecycle support process comprises the
steps of: prompting the participant to identify the interrelations
between software project entities and a set of actions that need
to be performed if one of the objects related to the entities is
changed; a software project entity can be described as any
digital document related to the software developed, such as a
software requirement . . . prompting the participant with a pre-
defined online action if any change made to one of the relevant
items is described; running a pre-defined batch action whenever
a relevant change made to any of the software project entities,
such as . . . sending a notification.
(Id. at ¶ [0008].)
5. Peretz “provides version management of said software project entities,
such as requirement . . . that empower the user ability to distinguish
Appeal 2011-009939
Application 11/616,571

4
between one change to another on the course of the product life cycle.”
(Id. at ¶ [0015].)
6. Peretz “stores dynamic relations between software project items using
interactive traceability matrix thereby improving life cycle control and
management and supporting software project documentation.” (Peretz
¶ [0019].)
7. In Peretz, “[t]he product end-user can automatically inform the support
team of problems in the deployed system.” (Id. at ¶ [0010]). It discloses
“[t]racking changes made by any of the users and informing all other
relevant stakeholders about the changes and changes impact” to “enable[]
real-time software project status monitoring for identifying authority,
accountability and responsibility for each of the changes performed
within the project entities.” (Id.)
8. In Peretz,
FIG. 3 is a schematic diagram that exemplifies a scenario when
an action is set to a requirement document (301), which is a part
of the acquisition process. The Acquisition Process (101)
defines the activities and tasks of the acquirer, which
contractually acquires software product or service. Events
defined for this stage will fire process actions to notify all
stakeholder of changed request. As soon as the requirement
documents were completed (301), project manager, or any other
individual designated for this job, identifies the actions that
must take place in the future, when any part of said documents
should be changed. If, for example, the project manager wants
to be notified whenever such a change is made, he will attach a
new event (302) to the specified requirement. Once the
Appeal 2011-009939
Application 11/616,571

5
requirement is changed (303), action is commenced and an
online alert (305) is sent to all the attendee.
(Id. at ¶ [0031].)

ANALYSIS

I. Claims 1 and 6-9
Anticipation is a question of fact. In re Schreiber, 128 F.3d 1473,
1477 (Fed. Cir. 1997). A prior art reference anticipates a claim only if it
discloses each and every limitation, explicitly or inherently. In re Gleave,
560 F.3d 1331, 1334 (Fed. Cir. 2009).
Appellants appear to argue that Peretz does not disclose a
“requirements plan,” which Appellants assert is “an integral part” of claim 1.
(App. Br. 7-9.) According to Appellants, the Examiner misconstrued the
claim term “requirements plan” to mean “software project.” (Id. at 8.)
Instead, the term should enjoy “an industrially understood meaning of ‘a
plan of requirements for a project.’”4 (Id.) Acknowledging that “Peretz
mentions that the software project entity can be a software requirement,”
Appellants contend that “a software requirement is just part of a
REQUIREMENTS PLAN, not the REQUIREMENTS PLAN itself.” (Id. at
9.)

4 Appellants pointed to S.E. Slack, BUILDING AN EFFECTIVE
REQUIREMENTS PLAN, IBM Developerworks (September 2008) to
demonstrate the industrially understood meaning of the term “requirements
plan.” (App. Br. 9.)
Appeal 2011-009939
Application 11/616,571

6
We find Appellants’ argument unpersuasive. The Examiner agreed
with Appellants’ proposed construction that a “requirements plan” can be “a
plan of requirements for a project.” (Final Rej. 8.) As the Examiner
correctly noted, however, all claims on appeal call for “a requirements plan
of requirements for a software system.” (Ans. 8.) In other words, the
“requirements plan” in this application refers to a plan of requirements for a
software project. Peretz discloses the management of all stages of a
software lifecycle, starting from the acquisition process, during which the
requirements for a software system are defined. (FFs 3 and 4.) (See also FF
8 (“The Acquisition Process (101) defines the activities and tasks of the
acquirer, which contractually acquires software product or service.”).) “The
examiner is equating the claimed ‘requirements plan of requirements for a
software system’ with ‘system requirements are defined’” in Peretz. (Ans.
9.) (See also Final Rej. 8) Thus, contrary to Appellants’ contention, Peretz
discloses the “requirements plan of requirements for a software system”
recited in claim 1.
Appellants also argue that Peretz does not disclose “the creation of
traceability links between each approving stakeholder and the version of the
requirement.” (App. Br. 10.) Citing paragraph [0014] of the present
application, Appellants argue that in their invention,
[V]ersion-aware traceability links to different requirements in a
requirements plan can be established for different stakeholders
to indicate required approval by the different stakeholders.
Each traceability link can track different approval status values
Appeal 2011-009939
Application 11/616,571

7
for different versions of a corresponding requirement.
Additionally, information from the traceability links can be
used to filter and annotate corresponding requirements as well
as to trigger notifications to the stakeholders.
(Id.)
Peretz teaches providing version management of software
requirements (FF 5), and using an interactive traceability matrix to improve
life cycle control and management as well as support software project
documentation (FF 6). As the Examiner correctly noted, in Peretz, “[t]he
product end-user can automatically inform the support team of problems in
the deployed system.” (App. Br. 9 (quoting Final Rej. 8); see also FF 7.)
Specifically, Peretz discloses “[t]racking changes made by any of the users
and informing all other relevant stakeholders about the changes and changes
impact.” (FF 7.) This “enables real-time software project status monitoring
for identifying authority, accountability and responsibility for each of the
changes performed within the project entities.”5 (Id.) In doing so, Peretz
teaches “creating traceability links between each approving stakeholder and
the version of the requirement” recited in claim 1.6
Appellants point out that “in Peretz, the system allows the generation
of periodic reports and summary reports, whenever a specific action is

5 Peretz explains that a software project entity can be any digital document
related to the software developed, such as a software requirement. (FF 4.)
6 We agree with the Examiner that the features Applicants list on page 10 of
the Appeal Brief (reproduced on pages 6-7 of this Opinion) are not recited in
claim 1. (See Ans. 10.) Therefore, we do not consider them in this analysis.
Appeal 2011-009939
Application 11/616,571

8
initiated.” (Id.) Such “periodic reports and summary reports,” however, are
not the same as the “notification” limitation claim 1 requires because the
reports “are not necessarily sent to each approving stakeholder, and
especially not based on traceability link whenever a new version of the
requirement is proposed by a stakeholder.” (Id. at 10-11.)
This argument is not persuasive, as Peretz discloses an additional
embodiment wherein during the acquisition process, when software
requirements change, the system will “notify all stakeholder of changed
request.” (FF 8.) (See also FF 4 (“sending a notification” “whenever a
relevant change made to any of the software project entities”); FF 7
(“[t]racking changes made by any of the users and informing all other
relevant stakeholders about the changes and changes impact”).) Thus,
Peretz teaches “notifying each approving stakeholder having a traceability
link to the version of the requirement whenever a new version of the
requirement is proposed by a stakeholder” as recited in claim 1. Because we
find that Peretz discloses each and every limitation of claim 1, we affirm the
rejection of claim 1.
Appellants state that claims 7-8 stand or fall together with claim 6.
(App. Br. 11.) In addition, Appellants do not argue claims 1, 6, and 9
separately. (See id. at 7-11.) Therefore, claims 6-9 fall with claim 1. See 37
C.F.R. §41.37(c)(1)(vii).

Appeal 2011-009939
Application 11/616,571

9
II. Claims 2-5 and 10-13
Appellants state that claims 2-5 stand or fall together with claim 1,
and claims 10-13 stand or fall together with claim 9. (App. Br. 11.) Thus,
we affirm the rejections of claims 2-5 and 10-13 for the same reasons as
discussed regarding the rejection of claim 1.

SUMMARY

We affirm the rejections on appeal.

TIME PERIOD FOR RESPONSE

No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a).

AFFIRMED

lp