Ex Parte Benchikha et al

Patent Trial and Appeal Board

Oct 30, 2012

11764985 (P.T.A.B. Oct. 30, 2012)

UNITED STATES PATENT AND TRADEMARK OFFICE 1
___________ 2
3
BEFORE THE PATENT TRIAL AND APPEAL BOARD 4
___________ 5
6
Ex parte HACENE BENCHIKHA, 7
GERALD W. SMITH, 8
and JOSEPH M. LUNA 9
___________ 10
11
Appeal 2011-010179 12
Application 11/764,985 13
Technology Center 3600 14
___________ 15
16
17
Before MURRIEL E. CRAWFORD, HUBERT C. LORIN, and 18
ANTON W. FETTING, Administrative Patent Judges. 19
20
FETTING, Administrative Patent Judge. 21
22
23
DECISION ON APPEAL24
Appeal 2011-010179
Application 11/764,985

2

STATEMENT OF THE CASE1 1
Hacene Benchikha, Gerald W. Smith, and Joseph M. Luna 2
(Appellants) seek review under 35 U.S.C. § 134 of a final rejection of claims 3
1-4, 6, 7, 13-18, and 20-27, the only claims pending in the application on 4
appeal. Oral arguments were presented on October 16, 2012. We have 5
jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b). 6
The Appellants invented a way of managing activities (Spec. 1:2). 7
An understanding of the invention can be derived from a reading of 8
exemplary claim 1, which is reproduced below [bracketed matter and some 9
paragraphing added]. 10
1. A computer-implemented method, comprising: 11
[1] creating 12
an operations instance 13
in an operations environment, 14
wherein the operations instance includes one or more 15
activities; 16
[2] creating, 17
by a user, 18
an activity item related to the operations instance, 19
wherein the activity item is associated with one of the 20
activities; 21
[3] assigning 22
an operation level 23
for the user 24
as an initialization level 25
for an escalation parameter 26
associated with the activity item, 27
wherein the operation level 28
is one of a plurality of predefined, hierarchical 29
operation levels 30

1 Our decision will make reference to the Appellants’ Appeal Brief (“App.
Br.,” filed April 19, 2011) and Reply Brief (“Reply Br.,” filed May 23,
2011), and the Examiner’s Answer (“Ans.,” mailed May 18, 2011).
Appeal 2011-010179
Application 11/764,985

3

associated with the operations instance; 1
[4] receiving, 2
from a different user, 3
a change request 4
to change the escalation parameter associated with 5
the activity item; 6
[5] determining, 7
from the change request, 8
that the operation level 9
of the different user 10
is equal to or greater than 11
the initialization level; 12
[6] updating, 13
in response to determining 14
that that the operation level of the different 15
user 16
is equal to or greater than the initialization 17
level, 18
the escalation parameter; 19
[7] notifying, 20
in response to the updating, 21
other users 22
whose respective operation levels 23
are equal to or greater than 24
the initialization level 25
about the updating of the escalation 26
parameter; 27
[8] generating 28
an escalation report 29
based on the updated escalation parameter; 30
and 31
[9] distributing 32
the escalation report 33
based on the operation level 34
associated with the updated escalation parameter. 35
36
37
Appeal 2011-010179
Application 11/764,985

4

The Examiner relies upon the following prior art: 1
Parr US 2003/0135401 Al Jul. 17, 2003
Kalantar US 6,954,737 B2 Oct. 11, 2005
Claims 1-4, 6-7, 13-18, 20-27 stand rejected under 35 U.S.C. § 103(a) 2
as unpatentable over Parr and Kalantar. 3
ISSUES 4
The issues of obviousness turn primarily on whether Kalantar’s usage 5
of user access and status indicators reads on the claimed usage of operation 6
levels and escalation parameters. 7
FACTS PERTINENT TO THE ISSUES 8
The following enumerated Findings of Fact (FF) are believed to be 9
supported by a preponderance of the evidence. 10
Facts Related to Appellants’ Disclosure 11
01. An initialization level for the activity item is identified and one or 12
more parameters associated with the activity item are initialized 13
based on the initialization level, wherein one of the parameters 14
comprises an escalation parameter. Spec. 1:17-19. 15
Facts Related to the Prior Art 16
Parr 17
02. Parr is directed to a construction project management system to 18
monitor the activities, process, and steps required to ensure 19
success from the owner's perspective. Parr ¶ 0001. 20
03. Parr places the knowledge into a database and via a graphical user 21
interface enables the owner's representative to set up a project and 22
Appeal 2011-010179
Application 11/764,985

5

track progress and completion. Typically, in prior system, the 1
user creates project specific information by entering activities or 2
tasks to be completed in a given sequence. This hierarchical 3
information also includes the timing of the activity and the 4
designation of the responsible party. Multi-user systems 5
sometimes allow for coordination and communication between 6
key participants. Such systems are used extensively in 7
construction projects, but are most valuable during the phase of 8
the life-cycle of a project when the actual construction begins. 9
However, that the structure and process developed for managing, 10
as an owner's representative, was not amenable to simply plugging 11
in to standard project management software such as Project by 12
Microsoft. Parr ¶ 0009. 13
04. Process flow diagrams showing a general organization of Parr’s 14
project management system are shown in Figures 1-5. From the 15
initial project selection display, the owner's representative is 16
capable of creating a new project, modifying an existing project, 17
selecting particular activities, reviewing existing projects, 18
searching for a project, or performing various administrative 19
activities. Parr ¶ 0033. 20
Kalantar 21
05. Kalantar is directed to managing facilities using client devices at 22
each facility that communicate with a central management server 23
through a network. Kalantar 1:8-12. 24
Appeal 2011-010179
Application 11/764,985

6

06. The ACCESS list for this customer lists the users that have access 1
to the customer's data. This permits a hierarchy of access to be 2
provided to different users. Kalantar 11:6-33. 3
07. Task status identifiers to mark task records may indicate a variety 4
of states. For example, status indicator values may include a task 5
pending approval identifier, a new task request approved 6
identifier, a new task request rejected identifier, a task 7
unscheduled identifier, a task scheduled identifier, a task due 8
identifier, a task not completed identifier, a task completed 9
identifier, a task closed identifier, a task rescheduled identifier, a 10
task cancelled identifier, a task approved identifier, a task rejected 11
identifier, or a task forcefully approved identifier. The central 12
management server tags each newly created task record with a 13
task unscheduled identifier and/or a task pending approval 14
identifier. If a task is tagged with a task pending approval 15
identifier, a higher hierarchy user has to approve the task. The 16
central management server determines whether a task record 17
should be tagged with a task pending approval identifier based on 18
facility records for which the task record is created. For example, 19
facility records may include a number of templates defining which 20
tasks should be automatically approved by the central 21
management server. If a user associated with a predetermined 22
hierarchy (access) level places a work order request, the central 23
management server may automatically tag task records generated 24
for tasks specified in the work order request with a task approved 25
Appeal 2011-010179
Application 11/764,985

7

identifier as well as a task unscheduled identifier. Kalantar 12:57 1
– 13:18. 2
08. A user having a predetermined access level may approve tasks, 3
thus, triggering the central management server to change a task 4
pending approval identifier to a task approved identifier in each 5
user-approved task record. Alternatively, the user may reject a 6
task, thus, triggering the central management server to change a 7
task pending approval identifier to a task rejected identifier in a 8
task record. The central management server may automatically 9
approve a task if no instructions to the contrary are received in a 10
predetermined time period from a supervisory user. Kalantar 11
13:28-38. 12
09. The supervisory user may change a status for each task in the 13
status report. For example, the supervisory user may change a 14
status for each task from "Done" to "Not Done," which may 15
constitute a disapproval or rejection of the task approval, and vice 16
versa. Responsive to detecting the change in the task status, the 17
EMI unit incorporates the changed status for the selected tasks 18
into a task update message and the central management server 19
updates the status for each task in the database. If a user 20
completes a task and updates a task's status to "Done" and, further, 21
if a user's supervisor does not change a task status to "Not Done," 22
the central management server updates a STATUS field, shown in 23
Figures 3 and 4, in a task record 206 stored in the database 140 to 24
a task completed state. Alternatively, the central management 25
server may update a task status indicator to a "task not completed" 26
Appeal 2011-010179
Application 11/764,985

8

state that may subsequently trigger the central management server 1
to reschedule or close the task. Kalantar 25:56 – 26:24. 2
ANALYSIS 3
The Examiner applied Parr for the conventional aspects of project 4
planning, and as such, the findings as to Parr are uncontested. The Examiner 5
applied Kalantar for the specific assignments and operations recited in the 6
independent claims. We are not persuaded by the Appellants’ argument that 7
"task status" or "task state" is not the same as an "operation 8
level for a user." Accordingly, Kalantar does not teach or 9
disclose "assigning an operation level for the user as an 10
initialization level for an escalation parameter associated with 11
the activity item," as claimed. 12
Because a task status or task state is not associated with a 13
user, it follows that Kalantar also does not teach or disclose the 14
operation level is one of a plurality of predefined, hierarchical 15
operation levels associated with the operations instance as 16
recited by the independent claims. Even if the status indicator 17
values of Kalantar taught the recited operation levels, Kalantar 18
does not teach or disclose the status indicator values as a 19
plurality of predefined, hierarchical operation levels. In 20
addition, nowhere does Kalantar teach or disclose the operation 21
level is one of a plurality of predefined, hierarchical operation 22
levels associated with the operations instance. 23
Appeal Br. 6. The Examiner maps Kalantar’s hierarchy of user access to the 24
claimed hierarchy of predefined operation levels and Kalantar’s status 25
indicator values to the claimed escalation parameter. Thus, the argument 26
that task status is not an operation level simply misapprehends the 27
Examiner’s mapping. It is uncontested that only users having a certain 28
hierarchical level can direct Kalantar’s status to be changed. It is also 29
uncontested that the status may indicate whether a task is to proceed, and 30
thus acts as an escalation parameter. 31
Appeal 2011-010179
Application 11/764,985

9

We do note that limitation [3], assigning an operation level for the 1
user as an initialization level for an escalation parameter associated with the 2
activity item, is somewhat ambiguous as to the meaning of how the 3
initialization level relates to the escalation parameter. However, 4
Specification page 1, lines 17-19 informs that the phrase “as an initialization 5
level for an escalation parameter” simply means the parameter is “based on 6
the initialization level.” Clearly Kalantar’s initial status setting as 7
unscheduled is based on the user’s authorization level being not high enough 8
to alter to schedule. 9
Separately argued claims 18 and 20 generate an audit log with dates 10
and categorize activities according to business function. As the Examiner 11
found, Parr describes providing an audit trail of changes. Any audit trail is a 12
form of a log. The word “audit” implies sufficient information to verify the 13
changes, such as dates. It is unclear that any patentable weight should be 14
given to the categories of activities, as these are non-functional attributes 15
interpretable only by the human mind. The Examiner nevertheless cited Parr 16
Figure 14 which portrays a list for selecting among categories of activities. 17
Each of the categories refers to a business function. 18
CONCLUSIONS OF LAW 19
The rejection of claims 1-4, 6-7, 13-18, 20-27 under 35 U.S.C. § 20
103(a) as unpatentable over Parr and Kalantar is proper. 21
DECISION 22
The rejection of claims 1-4, 6, 7, 1 3-18, and 20-27 is affirmed. 23
Appeal 2011-010179
Application 11/764,985

10

No time period for taking any subsequent action in connection with 1
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 2
§ 1.136(a)(1)(iv) (2011). 3
AFFIRMED 4
5
6
MP 7