Appeal No. 2006-1128
Application No. 10/215,877
We note that a FIFO queuing discipline is (1) a notoriously well known
management tool, and (2) is the typical workflow control in claim handling
systems, such as that of Bissonette, as evidenced by Zhao, p. 187, right
hand column, bottom paragraph.
The appellants argue that neither reference describes a second queue of cases with
a case identifier. [See Brief at p. 11 and Reply Brief pp. 2-5]. The examiner responds
that a case identifier is non-functional descriptive material and therefore given no
weight. [See Answer at p. 21]. This set of arguments by the appellants and examiner is
moot given that Lynn describes moving transactions from a first to a second queue and
assigning a case identifier.
When an event is detected, as indicated by Event Trigger 120, the
Events Processor determines how the work item(s) 122 associated with
the event should be started through the workflow and what data to start in
the workflow. The workflow dictates the work step 124. The Queue
Assignment module then determines to which work division 126 the
work item(s) 122 should be assigned. [See Fig. 5 and col. 12 lines 22-
29]
The Case table (BL CASE) is the main processing table. It stores a
record for each case per work type in the system. It is accessed by
BLCase 64. There can be multiple case tables in the system. The table
structure is always modified for each system implementation. Below is one
example.
BL_CASE (SCASEID VARCHAR2(16) not null, SWORKTYPE
VARCHAR2(16) not null, SSTATUS VARCHAR2(16) not null, SOWNERID
VARCHAR2(16) null, DCREATED DATE not null,
SLASTUPDATEUSERID VARCHAR2(16) null, DLASTUPDATED DATE
null, SACCOUNTNUM VARCHAR2(32) null, ) [See col. 12 lines 37-54]
The appellants also argue that at least two cases in the second queue are not
described. Lynn shows prefetching a second case in a queue, thus describing at least
two cases in a queue.
5
Page: Previous 1 2 3 4 5 6 7 8 9 10 11 12 13 Next
Last modified: November 3, 2007