Ex Parte Greene

Board of Patent Appeals and Interferences

Jul 7, 2011

10113213 (B.P.A.I. Jul. 7, 2011)

UNITED STATES PATENT AND TRADEMARK OFFICE 1
___________ 2
3
BEFORE THE BOARD OF PATENT APPEALS 4
AND INTERFERENCES 5
___________ 6
7
Ex parte WILLIAM S. GREENE 8
___________ 9
10
Appeal 2010-003664 11
Application 10/113,213 12
Technology Center 3600 13
___________ 14
15
16
Before ANTON W. FETTING, JOSEPH A. FISCHETTI, and 17
BIBHU R. MOHANTY, Administrative Patent Judges. 18
FETTING, Administrative Patent Judge. 19
DECISION ON APPEAL 20
STATEMENT OF THE CASE1 21

1 Our decision will make reference to the Appellant’s Appeal Brief (“Appeal
Br.,” filed September 9, 2009) and the Examiner’s Answer (“Ans.,” mailed
October 20, 2009).
Appeal 2010-003664
Application 10/113,213

2
William S. Greene (Appellant) seeks review under 35 U.S.C. § 134 1
(2002) of a final rejection of claims 1-8, 10-14, 16-38, 40-44, and 46-60, the 2
only claims pending in the application on appeal. We have jurisdiction over 3
the appeal pursuant to 35 U.S.C. § 6(b) (2002). 4
The Appellant invented a way of providing ubiquitous access to data 5
resources even where such data resources are maintained in separate stores 6
and by entirely separate processes (Specification 4:3-5). 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 data processing system implemented method, performed 11
by a server, for implementing a Management Operations Center 12
(MOC) in an enterprise, the method comprising: 13
[1] receiving, at the server, an event, where the event is related 14
to one of a state change or a problem within the enterprise 15
associated with at least one of an operation, function, policy, 16
process or a component thereof related to the enterprise; 17
[2] accessing, by the server, the event by type of event; 18
[3] aggregating, by the server, the event by: 19
[4] correlating, by the server, the event to rules for 20
processing the event, 21
where correlation is based on the type of event, 22
where correlating the event to rules for processing the 23
event comprises: 24
[5] selecting, by the server, a rules agent based on 25
the event; 26
[6] accessing, by the server, configuration 27
information for the rules agent, where the 28
configuration information includes an address of a 29
rules server; 30
Appeal 2010-003664
Application 10/113,213

3
[7] sending, by the server, a request to the address 1
of the rules server requesting rules for processing 2
the event; 3
and 4
[8] receiving, by the server, the rules; 5
[9] binding, by the server, the event to one of a plurality 6
of items based on the rules; 7
and 8
[10] binding, by the server, other information related to 9
an event to the one of a plurality of items based on the 10
rules; 11
and 12
[11] dispatching, by the server, an invitation to a contact, 13
where the contact is identified in the other information 14
and 15
the invitation invites the contact to participate in one of a 16
plurality of items based on the rules. 17
The Examiner relies upon the following prior art: 18
Beck US 6,381,640 B1 Apr. 30, 2002
Claims 1-8, 10-14, 16-38, 40-44, and 46-60 stand rejected under 35 19
U.S.C. § 103(a) as unpatentable over Beck and Official Notice. 20
ISSUES 21
The issue of obviousness as to the independent claims turns largely on 22
whether Beck describes correlating an event to rules for processing the event 23
in claim 1 limitations [4]-[8]. As to the dependent claims, the issue 24
generally remains the same, save for claims 4, 16, 20, 34, 46, and 50 25
separately argued based on their added limitations. 26
Appeal 2010-003664
Application 10/113,213

4
FACTS PERTINENT TO THE ISSUES 1
The following enumerated Findings of Fact (FF) are believed to be 2
supported by a preponderance of the evidence. 3
Facts Related to the Prior Art - Beck 4
01. Beck is directed to a multimedia communication center ((MMCC) 5
system for structuring workload for agents. This includes an 6
outward-facing communication interface for accepting 7
communications from clients; an inward-facing interface for 8
communicating with agents, including log-on procedures for 9
agents; and an operating system (OS) for managing operations of 10
the MMCC. The OS, upon agent log-on, activates an agent-11
specific software model that checks agent parameters, enterprise 12
rules, and work-in-progress, and prepares work assignments for 13
the agents. Beck 5:21-31. 14
02. Incoming DNT (data network telephony) calls, and other 15
communication events such as e-mail, file transfers and the like, 16
arrive at a routing node in a WAN (wide area network) and are 17
passed on over a digital connection to a routing server within the 18
communication center. Once calls arrive at the server, they are 19
routed directly according to existing routing rules to personal 20
computer/video display units. Beck 7:50-58. 21
03. A customer-interaction network operating system (CINOS), is 22
adapted to support all planned communication mediums such as 23
multimedia DNT applications including e-mail, video mail, file 24
transfers, chat sessions, IP calls, and CTI (computer-telephony 25
Appeal 2010-003664
Application 10/113,213

5
integration) COST (connection oriented switched telephony) 1
transactions such as voice calls, voice mails, faxes. Beck 8:48-53. 2
04. CINOS has a multi-tiered architecture with an external media 3
layer for interfacing with the customer or business contact, a 4
workflow layer for making routing decisions, organizing 5
automated responses, recording transactions, and so on, and an 6
internal media later for interfacing and presenting interactions to 7
an agent or knowledge worker. Beck 9:16-22. 8
05. Once a call or other communication event registers at either a 9
switch or a routing server, CINOS immediately identifies the 10
media type associated with the call and begins its processes 11
depending on enterprise rules. Beck 9:39-42. 12
06. All interactions with live external media, including actual text-13
based events whether live or not, are recorded and stored in an 14
MIS (multimedia server) with an associated text version of the 15
media stored as well, and becoming part of an overall threaded 16
contact history. This is accomplished in varying ways according to 17
existing parameters such as media type, whether the event is a live 18
call, and so on. For example, CINOS may execute a command 19
directing an IVR (interactive voice response unit) to digitally 20
record an incoming COST call during customer interaction and 21
then store the voice recording of the transaction in an MIS. A text 22
version of the recording either created simultaneously from the 23
voice recording via voice-to-text techniques (known in the art), or 24
Appeal 2010-003664
Application 10/113,213

6
created by a live attendant via manual annotation may be sent to 1
and stored in a database. Beck 9:64-10:10. 2
07. The purpose of the text version of an incoming data (email or 3
other) event is twofold. Firstly, a complete text-based transaction 4
history may be compiled and reserved for later access and audit. 5
Secondly, an agent or knowledge worker may, in some instances, 6
see the text version of the event at the same time that he receives 7
routed notification of the event. In this way, an agent may begin 8
mental preparation before taking a call. The text version of an 9
event must be machine-readable and human -readable at times 10
displayed. Interactive media-independent viewers, part of the 11
agent's client application, may be used to disseminate information 12
which may initially not be human readable. Beck 10:17-28. 13
08. The text version of Beck’s extracted knowledge of the transaction 14
is in machine-operable code, allowing search and cross-15
referencing functions. Beck 10:64-67. 16
09. After incoming events are analyzed and processed with regards to 17
queuing, recording, storing, etc. CINOS decides the disposition 18
paths of each event. E-mails are either routed to next available 19
agents using a push technology, or simply stored where they may 20
be retrieved by agents after receiving notification. By the use of 21
routing and routing notification events, any media may be routed 22
to an appropriate agent based on skill, or any other rule-based 23
routing method. Beck 11:1-13. 24
Appeal 2010-003664
Application 10/113,213

7
10. Beck’s workflow layer has 3 basic function categories. Content 1
analysis category is where textual analysis, voice analysis, IVR 2
interaction, recording and storing takes place. Context resolution 3
involves customer identification, business process binding, 4
preparation for routing, and so on. Interaction routing contains 5
various processes associated with the presentation of the 6
interaction to agents, service persons, and all transaction partners, 7
and covers queuing, skill-based routing, automated treatment, 8
workflow models, and so on. Beck 12:58-13:2. 9
11. A controlled interface window controls routing and interaction 10
right from the beginning of customer contact. This window acts as 11
a portal through which existing and potential clients may be 12
screened, categorized and routed according to enterprise rules. 13
Through the linking and reporting to other CINOS functions, and 14
repositories, much real-time personalization of the window 15
according to enterprise rules and customer parameters may be 16
made automatically. For example, if a client's history indicates a 17
propensity toward frequent buying, an I-phone option may be 18
presented in a customer service section immediately after such a 19
determination so that he may get direct customer service at all 20
times. Beck 18:4-28. 21
12. Beck describes two actions in parallel, tasks 1 and 2a in Fig. 14, 22
whose processing merges to allow continuation into task 2b. Beck 23
37:32-46. 24
Appeal 2010-003664
Application 10/113,213

8
ANALYSIS 1
We are unpersuaded by the Appellant’s argument that Beck fails to 2
describe the correlating steps in limitations [4]-[8]. Appeal Br. 13-21. 3
As the Examiner found at Answer 4-5 and 16-18, Beck selects rules 4
based on an event such as receipt of an email, and accesses configuration 5
information for implementing the rules. Those rules are then executed, 6
which necessarily requires sending the instructions to execute the rules and 7
receiving the rules for execution. The correlation of the rules is also 8
necessarily dependent on the event, such as correlating email routing rules 9
for an email receipt event. FF 02, 04, 05, 06, 09, and 11. 10
We are unpersuaded by the Appellant’s argument that Beck’s routing 11
server is not a rules server (Appeal Br. 14) because, as the Examiner found 12
at Answer 16, the Appellant do not define a rules server. Any server 13
implementing rules would then fit within the plain meaning of the term. This 14
leads to the confusing discussion regarding the rules server address at 15
Appeal Br. 16. 16
Here, the Examiner both found the necessity for an address to 17
communicate anything regarding rules made such an address inherent, and 18
further took official notice of the notoriety of using such an address. We 19
agree that the use of some address to get any information anywhere in a 20
computer is both inherent and notoriously well known.2 The Appellant’s 21
arguments regarding both the rules server and address appear to have some 22

2 In computers, an address is simply the label of the location at which
information is stored. Since information that is not stored does not exist, all
information in a computer have assigned addresses and such addresses are
necessary to locate the information for storage or retrieval.
Appeal 2010-003664
Application 10/113,213

9
particular implementation in mind, but the claims are completely open ended 1
as to implementation. As to the address being that of a server, as the 2
Examiner found, the use of a server for client-server activities such as those 3
in Beck is notoriously well known, and again, any information directed to a 4
location on such a server would necessarily require the address of the server 5
itself. Even though there are conventions for allowing such an address to be 6
omitted physically at higher levels of communication, that is only because 7
the conventions acknowledge the address implicitly, and thus the address is 8
still provided by the underlying system. 9
We also find that the claim does not narrow the nature of the rules agent 10
or the configuration information. Clearly, Beck necessarily selects a rule 11
using its system based on an event and accesses the system for executing the 12
rule. This implies that software executes the rules, and is thus a rules agent, 13
and that the system retrieves information about where to find the rules, and 14
such information would be configuration information. 15
We are also unpersuaded by the Appellant’s argument that Beck’s 16
enterprise rules are not available from the routing server. Appeal Br. 17-18. 17
As the Examiner found at Answer 18, the routing server uses the rules to 18
route the calls, so the rules must be accessible. The claim does not specify 19
the nature or manner of access. 20
We are unpersuaded by the Appellant’s argument that Beck fails to 21
describe rendezvousing one of the plurality of items with another of the 22
plurality of items, resulting in a single item as in claim 4. Appeal Br. 22-23. 23
As the Examiner found at Answer 7 and 18-19, the claim merely requires 24
that plural items along parallel processing tracks merge into a single item 25
Appeal 2010-003664
Application 10/113,213

10
track. Beck describes two actions in parallel, tasks 1 and 2a in Fig. 14, 1
whose processing merges to allow continuation into task 2b. FF 12. 2
We are persuaded by the Appellant’s arguments that Beck fails to 3
describe detecting a milestone for an event and firing rules based on 4
milestone occurrence of claim 16. Appeal Br. 24-25. The Examiner found 5
that Beck fired rules in order to achieve a prospective milestone. Ans. 9. 6
The claim requires that the rules be fired as a result of detecting that a 7
milestone has occurred, not as a step in subsequently achieving a milestone. 8
We are persuaded by the Appellant’s arguments that Beck fails to 9
describe deploying an avatar service as in claim 20. Appeal Br. 25-28. The 10
Examiner found that Beck deployed the presence of a person fielding calls. 11
Ans. 20. The claim requires an actual avatar service that is able to register 12
an avatar and lease that avatar. A person fielding a call is not an avatar. 13
Beck does not describe creating an avatar for such a person. 14
The arguments for the remaining claims either depend on or are 15
repetitions of the arguments in support of claims 1, 4, 16, and 20. Thus, we 16
find the arguments for these claims unpersuasive for the reasons we stated 17
supra, except for the arguments in support of claims 46 and 50, which are 18
similar to claims 16 and 20. 19
CONCLUSIONS OF LAW 20
The rejection of claims 1-8, 10-14, 17-19, 21-38, 40-44, 47-49, and 51-21
60 under 35 U.S.C. § 103(a) as unpatentable over Beck and Official Notice 22
is proper. 23
The rejection of claims 16, 20, 46, and 50 under 35 U.S.C. § 103(a) as 24
unpatentable over Beck and Official Notice is improper. 25
Appeal 2010-003664
Application 10/113,213

11
DECISION 1
To summarize, our decision is as follows. 2
 The rejection of claims 1-8, 10-14, 17-19, 21-38, 40-44, 47-49, and 3
51-60 under 35 U.S.C. § 103(a) as unpatentable over Beck and 4
Official Notice is sustained. 5
 The rejection of claims 16, 20, 46, and 50 under 35 U.S.C. § 103(a) as 6
unpatentable over Beck and Official Notice is not sustained. 7
No time period for taking any subsequent action in connection with this 8
appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 9
§ 1.136(a)(1)(iv) (2007). 10
11
AFFIRMED-IN-PART 12
13
14
15
erc 16