Ex Parte Sadiq

Board of Patent Appeals and Interferences

Jun 7, 2012

11022683 (B.P.A.I. Jun. 7, 2012)

UNITED STATES PATENT AND TRADEMARK OFFICE 1
___________ 2
3
BEFORE THE BOARD OF PATENT APPEALS 4
AND INTERFERENCES 5
___________ 6
7
Ex parte WASIM SADIQ 8
___________ 9
10
Appeal 2011-000744 11
Application 11/022,683 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
Appeal 2011-000744
Application 11/022,683

2
STATEMENT OF THE CASE1 1

1 Our decision will make reference to the Appellant’s Appeal Brief (“App.
Br.,” filed May 6, 2010) and Reply Brief (“Reply Br.,” filed September 21,
2010), and the Examiner’s Answer (“Ans.,” mailed July 23, 2010).
Wasim Sadiq (Appellant) seeks review under 35 U.S.C. § 134 (2002) of 2
a final rejection of claims 21-40, the only claims pending in the application 3
on appeal. We have jurisdiction over the appeal pursuant to 4
35 U.S.C. § 6(b) (2002). 5
Workflow systems allow enterprises to formalize the processes by which 6
the enterprises achieve their business objectives. Such workflow systems 7
provide step-by step descriptions of tasks which must or should be 8
performed as part of the workflow, so that individuals or groups within the 9
enterprise can be assigned individual (or groups of) tasks. In using such 10
business process models, it may be problematic for one enterprise or 11
organization to interact with another enterprise or organization. 12
The Appellant invented a design tool that is operable to display a first 13
process model and a second process model, each including a progression of 14
task nodes, coordinator nodes that coordinate the progression of the task 15
nodes, and event-flow activities that transfer control between the first 16
process model and the second process model, and a control flow assignment 17
system that is operable to merge the first process model and the second 18
process model to obtain a merged process model, and further operable to 19
insert control flow coordinators within the merged process model, based on 20
Appeal 2011-000744
Application 11/022,683

3
locations of the event-flow activities within the merged process model 1
(Specification 2-3). 2
An understanding of the invention can be derived from a reading of 3
exemplary claim 21, which is reproduced below [bracketed matter and some 4
paragraphing added]. 5
21. A system comprising: 6
[0.1] one or more computers; 7
and 8
[0.2] a computer-readable medium coupled to the one or more 9
computers having instructions stored thereon which, when 10
executed by the one or more computers, cause the one or more 11
computers to perform operations comprising: 12
[1] displaying 13
a first process model that is executed by a first 14
entity 15
and 16
a second process model that is executed by a 17
second entity, 18
each process model 19
being predefined 20
and 21
including 22
a progression of task nodes, 23
and 24
coordinator nodes 25
that coordinate the progression 26
of the task nodes; 27
[2] inserting a sender task into the first process model 28
to provide a modified first process model, 29
Appeal 2011-000744
Application 11/022,683

4
the sender task including 1
an event identifier, 2
a first entity identifier 3
and 4
a second entity identifier; 5
[3] inserting a receiver task into the second process 6
model 7
to provide a modified second process model, 8
the receiver task 9
corresponding to the sender task of the first 10
process model, 11
and 12
including 13
the event identifier, 14
the first entity identifier 15
and 16
the second entity identifier, 17
the sender and receiver tasks 18
transferring control between the first entity 19
and the second entity; 20
[4] generating an intermediate process model 21
based on the modified first process model and the 22
modified second process model; 23
and 24
[5] inserting control flow coordinators within the 25
intermediate process model 26
based on locations of the sender and receiver tasks 27
to provide a merged process model. 28
29
Appeal 2011-000744
Application 11/022,683

5
The Examiner relies upon the following prior art: 1
Ouchi US 2003/0061266 A1 Mar. 27, 2003
Budhiraja US 2003/0084127 A1 May 1, 2003
Kim US 2004/0153350 A1 Aug. 5, 2004
Flaxer US 2004/0162741 A1 Aug. 19, 2004
Meng, Jie, Achieving Dynamic Inter-Organizational Workflow 2
Management by Integrating Business Processes, E-Services, Events, and 3
Rules, PhD. Dissertation, University of Florida (2002) (hereafter 4
“Meng”). 5
Claims 21, 22, 26, 28, 29, 30, 34, 36, and 37 stand rejected under 35 6
U.S.C. § 103(a) as unpatentable over Flaxer and Budhiraja. 7
Claims 23-25, 31-33, 38, and 39 stand rejected under 35 U.S.C. § 103(a) 8
as unpatentable over Flaxer, Budhiraja, and Meng. 9
Claims 25 and 39 stand rejected under 35 U.S.C. § 103(a) as 10
unpatentable over Flaxer, Budhiraja, and Kim. 11
Claims 27, 35, and 40 stand rejected under 35 U.S.C. § 103(a) as 12
unpatentable over Flaxer, Budhiraja, and Ouchi. 13
ISSUES 14
The issues of obviousness turn primarily on whether the claims are 15
sufficiently broad to encompass building up a model from sub-models 16
within a single environment. 17
FACTS PERTINENT TO THE ISSUES 18
The following enumerated Findings of Fact (FF) are believed to be 19
supported by a preponderance of the evidence. 20
Appeal 2011-000744
Application 11/022,683

6
Facts Related to the Prior Art 1
Flaxer 2
01. Flaxer is directed to adapting workflow management to rapidly 3
changing business environments, and to product lifecycle 4
management of projects composed of services provided in 5
distributed environments such as the Internet. Flaxer ¶ 0002. 6
02. Flaxer describes Product Lifecycle Management (PLM) as 7
software, services, and consulting to help companies manage and 8
integrate product information and business interaction across a 9
wide range of business processes. Flaxer ¶ 0004. 10
03. Flaxer acknowledges the existence of predefined workflow 11
schemas, but suggests they may become increasingly 12
impracticable for many enterprises because of their lack of 13
flexible mechanisms to adequately cope with ever-changing 14
environments. Flaxer ¶ 0010. 15
04. Flaxer describes how many enterprises and organizations have 16
moved towards the automation of their business processes using 17
Workflow Management Systems (WFMSs). One of the 18
fundamental assumptions in current WFMSs is that workflow 19
schemas (i.e., tasks, control flow and data flow) are predefined. In 20
order to automate business processes workflow designers need to 21
understand business processes and use workflow modeling tools 22
to define workflow schemas. When an end user wants to execute 23
a business process, they create a workflow instance by selecting a 24
workflow schema and providing the necessary input data. WFMS 25
Appeal 2011-000744
Application 11/022,683

7
executes the workflow instance and returns the results to the end 1
user. Flaxer ¶ 0009. 2
05. Flaxer provides a system and method for supporting Product 3
Lifecycle Management over a distributed service network 4
topology. The topology connects a hierarchy of functional 5
domains, each domain having a service ontology and one or more 6
service composition schemas defined by the service ontology. 7
Each service composition schema models a business process in its 8
domain. Flaxer makes use of an event messaging protocol that 9
enables service collaboration and ad-hoc workflow composition. 10
Each business process is implemented by an ad-hoc workflow 11
comprised of one or more tasks connected by one or more 12
business rules. The business flow manager is able to stop 13
execution of the workflow and regenerate a workflow for 14
remaining tasks in response to events received over the network 15
from service providers and in response to conflicts detected in the 16
workflow. Flaxer ¶ 0042. 17
06. The PLM-flow Manager concurrently supports multiple ad-hoc 18
workflow instances, treating each one distinctly and in isolation. 19
Flaxer ¶ 0293. 20
Budhiraja 21
07. Budhiraja is directed to a graphical object oriented business 22
process modeling environment and more specifically to such an 23
environment in which interacting components representing 24
Appeal 2011-000744
Application 11/022,683

8
business processes can be created, manipulated, tested, deployed, 1
and executed in a flexible manner. Budhiraja ¶ 0001. 2
08. Budhiraja introduced the “integration model” that is used to 3
provide a graphical end to end, or global, view of an integration 4
application. The integration model shows how the various 5
business process models in the corresponding integration 6
application are connected to one another and communicate with 7
one another. The application designer can work at the integration 8
model level to model connectivity and the data flow between 9
various business process models and, when desired, can “drill 10
down” into the business process model to create or modify the 11
details of the individual business processes. Budhiraja ¶ 0037. 12
09. Budhiraja developed a graphical modeling environment in 13
which business process logic of components is separated from the 14
communications aspects of a model to permit abstraction of a 15
complete integration scenario without regards to physical 16
deployment of the model. Budhiraja ¶ 0038. 17
10. Business process systems, such as an ERP system, CRM 18
system, order processing system, trading partner system and 19
inventory system control associated business processes and are 20
coupled to an integration server over a network or other 21
communication channel. Budhiraja ¶ 0039. 22
11. A development server has a graphical modeling module, which 23
provides the modeling environment for configuring business 24
process models and integration models. The integration server 25
Appeal 2011-000744
Application 11/022,683

9
includes an execution engine for executing an integration model 1
after deployment by directing the flow of information among the 2
underlying internal and external systems. Budhiraja ¶ 0040. 3
12. Ports define a standard way to represent the external interface 4
of components and thus provide communication between 5
components. At runtime, a port defines the communication 6
protocol, such as CORBA, RMI, or the like, used for 7
communication. In particular, when a component is created, code 8
is automatically generated in correspondence to the port properties 9
of the component for looking up, i.e. invoking, connection 10
information for each port of the component, including the port to 11
which it is connected, the type of the port, and how to connect to 12
other ports. At runtime, this code serves to identify and bind the 13
proper communication protocols. Ports can be directly bound to 14
synchronous protocols, such as Hypertext Transfer Protocol 15
(HTTP), WSDL, or Simple Object Access Protocol (SOAP). 16
Channels are connector components that model asynchronous 17
communication mechanisms and which can be inserted into the 18
integration model as components between ports. Budhiraja ¶ 19
0048. 20
ANALYSIS 21
We are not persuaded by the Appellant’s argument that 22
Flaxer fails to disclose a first process model that is executed by 23
a first entity and a second process model that is executed by a 24
second entity, providing modified first and second process 25
models, generating an intermediate process model based on the 26
Appeal 2011-000744
Application 11/022,683

10
modified first process model and the modified second process 1
model, and providing a merged process model based on the 2
intermediate process model. Instead, and as discussed in detail 3
above, Flaxer is directed to the original composition of a 4
business workflow based on an end objective and business 5
rules, and only selects a service provider in hindsight (i.e., after 6
the business workflow is composed) based on selection rules. 7
Further, where multiple workflows have been so composed, 8
Flaxer treats each distinctly and in isolation. 9
Appeal Br. 14. As the Examiner found, both Flaxer and Budhiraja describe 10
constructing larger process models from more primitive elements. This is 11
hardly surprising, as Appellant’s Specification 1-2 admits that such 12
modeling has been available in the prior art. The claims set forth a 13
procedure in so modeling that first sets up two disconnected parts of the 14
model and then connects them. The Examiner found that Flaxer does so and 15
Budhiraja simply makes explicit that which is implied by Flaxer. We agree 16
with the Examiner’s findings and adopt the Examiner’s findings and analysis 17
from Answer 3-20 and reach similar legal conclusions. 18
We understand Appellant to be arguing that the initial models are in 19
completely independent environments prior to being connected. We find 20
this argument to be not commensurate with the scope of the claim. While 21
limitation [1] does recite that each model is executed by a separate entity, 22
the claim does not narrow the scope of such entities. Thus, the normal data 23
structures that are required to execute any model portions, are both distinct 24
from each other for different portions of a model, and are part of the objects 25
used for such execution. Appellant has not made any arguments that point 26
out how the claims would not read on just such building up of a model in a 27
single environment such as those in Flaxer and Budhiraja. 28
Appeal 2011-000744
Application 11/022,683

11
We are not persuaded by the Appellant’s argument that Flaxer teaches 1
away from predefined models. Appeal Br. 15. Flaxer acknowledges the 2
existence of predefined workflow schemas, but suggests they may become 3
increasingly impracticable for many enterprises because of their lack of 4
flexible mechanisms to adequately cope with ever-changing environments. 5
FF 03. However, Flaxer refers to schemas from which models are derived. 6
Modifying a schema prior to forming a model does not diminish the 7
constancy of the definition of the model. Also, simply acknowledging that 8
an input is evolving does not teach away from using that input. 9
CONCLUSIONS OF LAW 10
The rejection of claims 21, 22, 26, 28, 29, 30, 34, 36, and 37 under 35 11
U.S.C. § 103(a) as unpatentable over Flaxer and Budhiraja is proper. 12
The rejection of claims 23-25, 31-33, 38, and 39 under 35 U.S.C. § 13
103(a) as unpatentable over Flaxer, Budhiraja, and Meng is proper. 14
The rejection of claims 25 and 39 under 35 U.S.C. § 103(a) as 15
unpatentable over Flaxer, Budhiraja, and Kim is proper. 16
The rejection of claims 27, 35, and 40 under 35 U.S.C. § 103(a) as 17
unpatentable over Flaxer, Budhiraja, and Ouchi is proper. 18
DECISION 19
The rejection of claims 21-40 is affirmed. 20
Appeal 2011-000744
Application 11/022,683

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