Ex Parte Devarakonda et al

Patent Trial and Appeal Board

Feb 8, 2016

11773985 (P.T.A.B. Feb. 8, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR
111773,985 0710612007
48233 7590 02/10/2016
SCULLY, SCOTT, MURPHY & PRESSER, P.C.
400 GARDEN CITY PLAZA
SUITE 300
GARDEN CITY, NY 11530
Murthy V. Devarakonda
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
ATTORNEY DOCKET NO. CONFIRMATION NO.
YOR920070221US1
(21131)
2366
EXAMINER
JASMIN, LYNDA C
ART UNIT PAPER NUMBER
3629
NOTIFICATION DATE DELIVERY MODE
02/10/2016 ELECTRONIC
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.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address( es):
IBMPAIRENotify@ssmp.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte MURTHY V. DEV ARAKONDA,
HUI LEI,
SOUMITRA SARKAR,
and AXEL TANNER
Appeal2013---004544
Application 11/773,985
Technology Center 3600
Before HUBERT C. LORIN, ANTON W. PETTING, and
NINA L. MEDLOCK, Administrative Patent Judges.
PETTING, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE 1
Murthy V. Devarakonda, Hui Lei, Somnitra Sarkar, and Axel Tanner
(Appellants) seek review under 35 U.S.C. § 134 of a final rejection of
claims 1-5, 9-13, and 15-20, the only claims pending in the application on
appeal. We have jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b ).
1 Our decision will make reference to the Appellants' Appeal Brief ("App.
Br.," filed October 15, 2012) and Reply Brief ("Reply Br.," filed
February 12, 2013), and the Examiner's Answer ("Ans.," mailed December
12, 2012), and Final Action ("Final Act.," mailed May 1, 2012).
Appeal2013-004544
Application 11/773,985
The Appellants invented a way of creating a technical solution definition
for delivering IT outsourcing services. Specification para. 1.
An understanding of the invention can be derived from a reading of
exemplary claim 1, which is reproduced below (bracketed matter and some
paragraphing added).
1. A method for providing automated assistance to a service
provider for creating a technical solution definition for a project
for delivering Information Technology (IT) outsourcing
services to a customer, the method comprising the steps of:
[ 1] providing, in machine processable form,
a definition of a taxonomy of a set of services offered by
the service provider;
[2] providing, in machine processable form,
a repository of service designs,
each of the service designs describing a set of IT
architecture components to deliver a service
associated with a service element, according to a
specified best practice rule;
[3] providing, in machine processable form,
a collection of policies
which determine when a specific service design
can be used,
said policies including a plurality of tool selection
policies,
each of the tool selection policies specifying, when
a capability can be determined by a plurality of
alternative tools, which one of the alternative tools
is to be selected for delivering the capability, and
wherein said each tool selection policy selects said
one of the alternative tools based on defined
customer requirements and environment
considerations;
2
Appeal2013-004544
Application 11/773,985
and
[ 4] using a computer system, implementing a design tool
program,
and
to define a scope of the project,
to navigate through said taxonomy,
and
to select a group of service elements for defining a
solution for delivering said IT outsourcing services,
wherein said scope is defined by mapping identified
customer requirements to services in the taxonomy, and
including using said tool to identify semantics of the
policies and of architectural descriptions and to utilize
said architectural descriptions to provide automated
support for technical solution design;
[ 5] wherein the using step includes the step of providing the
computer implemented design tool with a plurality of execution
engines for interpreting the different types of metadata to
provide customized assistance during technical solution design;
and
[ 6] wherein the plurality of execution engines includes
a policy execution engine to evaluate predicates
associated with design selection, tool selection and global
policies,
and
an architecture composition engine
to combine the architecture components associated
with each service design
and
to create a consolidated view of the target IT
architecture
and
3
Appeal2013-004544
Application 11/773,985
to identify duplication and opportunities for
consolidation of software, middleware and
hardware components.
The Examiner relies upon the following prior art:
Carpenter US 6,199,068 Bl Mar. 6, 2001
Dangelo US 6,216,252 B 1 Apr. 10, 2001
Ruffin US 6,249,769 Bl June 19, 2001
Goiffon US 6,427,230 Bl July 30, 2002
Benny US 2002/0188493 Al Dec. 12, 2002
Claims 1-3, 9-11, 15-17, and 20 stand rejected under 35 U.S.C.
§ 103(a) as unpatentable over Benny, Goiffon, Dangelo, and Ruffin.
Claims 4, 5, 12, 13, 18, and 19 stand rejected under 35 U.S.C. § 103(a)
as unpatentable over Benny, Goiffon, Dangelo, Ruffin, and Carpenter.
ISSUES
The issues of obviousness tum primarily on whether Benny describes
some form of consolidated view of an IT architecture, and whether Dangelo
is evidence of the general use of design languages for design automation.
FACTS PERTINENT TO THE ISSUES
The following enumerated Findings of Fact (FF) are believed to be
supported by a preponderance of the evidence.
4
Appeal2013-004544
Application 11/773,985
Facts Related to the Prior Art
Benny
01. Benny is directed to using an enterprise service delivery
technical architecture to design a technical delivery framework for
a customer. Benny para. 5.
02. Benny provides an Enterprise Systems Delivery ("ESD")
Technical Architecture ("ESDTA"), which includes a Technical
Model, and a Technical Delivery Framework. Benny para. 10.
03. The ESDTA contains two major components, the ESD
Technical Model and the ESD Technical Delivery Framework.
The ESDT A describes the structure of the complete set of
technical components (models, frameworks, definitions,
architectural building blocks, etc.) that an information technology
outsourcer requires to deliver services. The ESDT A Vision is to
enable the rigorous and consistent management of information
technology services provided in a seamless manner across all
platforms, leveraging resources and delivering business value
while driving toward computing as a utility. The ESDTA Scope is
the architectural foundation supporting service design. The
ESDTA provides guidance for the conversion of the customer's
tool set into the agreed standard. Benny para. 105.
04. Principles are underlying, general rules that are durable and
have wide applicability across the architecture, such as that the
architecture will enable a standard end-to-end scalable, integrated
solution applicable to all customers. Principles 307 must map to
5
Appeal2013-004544
Application 11/773,985
the Requirements 306, stand the test of time, and be seen to be
true for all solutions; as such they must stand up to any challenge.
As the architecture evolves, Principles must always hold true and
cannot be compromised. Benny para. 107.
05. Within the ESD Technical Model, each of the critical technical
capabilities required to create ESM solutions is defined as an
Architectural Building Block ("ABB"). ABBs are components of
the architecture that are sufficiently modular and bounded to be
described as self-contained entities. ABBs are used to construct
logical views of the Technical Architecture. Each ABB is
independent of the underlying physical implementation and does
not imply, or exclude, a specific physical architecture. Each ABB
is defined to encapsulate a function and to document its
relationships to other ABBs. Criteria for tool selection are derived
from the ABB and its relationships. Each high-level ABB 308 has
been decomposed into lower level ABBs which individually
identify all capabilities or functions required to provide ESM
solutions. These ABBs 308 have been decomposed to the lowest
level of uniqueness of function. Benny para. 108.
06. There are four levels of ABBs within the Technical Model. The
highest level of abstraction is the conceptual level or level 0. All
the major components described within level 0, and the
relationships between them, are depicted in the logical level 0
conceptual model illustrated in Figure 4. The architecture was
designed to provide enterprise-wide, end-to-end services. Benny
describes an organized and consistent set of policies, standards,
6
Appeal2013-004544
Application 11/773,985
protocols, and published interfaces to select technical components
that support the Enterprise Systems Management processes. The
user interface is the technology that renders information to and
from the user into the format needed for views and for the
applications. Views encompass the rendering of information in
the way that the recipient can use, based on the requirements of
his or her role. Access is the technology that provides common,
standard, and open means for providing paths to data and IT
resources in a secure, controlled way. Integration is the
requirements placed on the Technical Architecture to support data
and application integration necessary for the interaction across
functional entities. Data is the technology that supports the
actions performed against the Enterprise Data Repository (EDR).
The EDR contains the information required for the delivery of
ESMA services. The logical structure and contents of the EDR
are described by the ESMA Information Architecture.
Management enablement are the requirements placed on
technology to enable the application components defined within
the process architecture so that global IT resources can be
supported in a common, standard, and open means and managed
from a business process perspective. Global IT resources are the
objects being managed. Benny para. 109.
07. Design Objects are the basic foundation for all tool selection
and design within each Technical Framework. Design Objects are
defined based on the Specific Solution Scope for each technical
delivery and may be unique for each Technical Delivery
7
Appeal2013-004544
Application 11/773,985
Framework. An individual uesign Object is a collection of
"qualified" lowest level ABBs with "attributes" added based on
the specific solution being developed. Benny para. 112.
08. ABBs are selected for inclusion in a Design Object based on
commonality of either platform (where the actual ABB's
associated systems management capability would execute) or
function (a change management design object). Design Objects
might be defined that mapped one function to one tool (e.g., a
Design Object describing the complete set of capabilities
regarding problem management would map to one, complete
problem management tool). Benny para. 113.
09. The activities required to deliver specific services are used to
select and "qualify" each ABB required to deliver that service.
ABBs are qualified by adding "attributes" that indicate how and/or
against what component that the capability is being applied.
These ABBs are then grouped, based on commonality (of platform
or function) to identify Design Objects. Defining design objects
in this way is a unique approach to designing ESM solutions.
Tools (software) are then selected to satisfy the requirements in
relationships identified within and between these design objects.
Gaps between requirements for tools and actual tools are
identified to be filled with either skills, processes or integration.
Benny para. 114.
10. With the defined Tool Selection Criteria, all the specific tools
(including hardware and software) were selected, and based on the
8
Appeal2013-004544
Application 11/773,985
Specific Solution Requirements, and Solution Scope, a uetailed
Technical Design for the systems management environment was
developed. Benny para. 128.
11. Benny shows a view of a complete list of design objects over a
global network. Benny Fig. 1 7.
Goiffon
12. Goiffon is directed to an improved object management system
for tracking, cataloging, and managing data and code modules;
and, more specifically, to an object management system and
method for using objects storing meta-data to model a reusable
group of code of data modules, and to further model the external
interfaces presented by the group of code and data modules, the
system being used to manage and to analyze the reusable group of
code and data modules prior to performing renovation or
migration operations on any of the code or data modules included
in the group. Goiffon 1:26-37.
13. Goiffon describes allowing a user to identify packages of
software constructs that are associated with a predetermined task.
The packages are created to take into account all
interdependencies between the included software constructs. That
is, a given package includes all of the code and data modules that
are necessary and sufficient to perform a given task. Goiffon
4:15-21.
14. Goiffon describes allowing a user to identify one or more
software constructs that will form the starting point for the
9
Appeal2013-004544
Application 11/773,985
package definition. The objects for modeling this initially-
identified set of software constructs are displayed via the user
interface, along with any relationships between this set of objects
and other objects. These relationships between objects are
indicative of interdependencies existing between ones of the
initially-identified set of software constructs and other software
constructs. These relationships are used to identify a second set of
software constructs that must be added to the package so that all
necessary interdependencies are taken into account. The user may
recursively add software constructs to a package of software
constructs in a manner that allows all interdependencies between
code and data modules to be readily taken into account. When the
user has completed the package definition process, all software
constructs that are needed to perform a particular task will be
included in the package. Goiffon 4:27--48.
Dangelo
15. Dangelo is directed to computer-aided design tools and
techniques for the design and implementation of complex circuits
and systems, particularly digital devices. Dangelo 1 :43--45.
16. Dangelo describes the automated design process as using a
design description written in a formal, high-level language. The
description is analyzed (parsed) to form a parse tree. In the parse
tree, semantic rules are attached to each node. Each syntactic rule
for the formal (high-level) language is associated with one or
more semantic rules. Each rule has a semantic and a syntactic
10
Appeal2013-004544
Application 11/773,985
part. After a successful parse of the given description, each node
in the parse tree thus formed is associated with the attributes as
specified in the DCTG rules of the language. The computation of
an attribute attached to a node can be a recursive transversal of
sub-trees associated with the node. For semantic analysis, one
semantic attribute verifies whether any semantics of the language
is violated. Thus the analysis of the description ensures that it
conforms to the syntax and semantics of the HDL description, and
leads to the construction of a valid hierarchical knowledge base.
Dangelo 17:53-18:18.
1 7. Dangelo describes a specification language as being predicated
on semantics for analysis. Dangelo 20: 18-30.
Ruffin
18. Ruffin is directed to business solutions development, and in
particular to evaluating particular aspects of a business enterprise
and business-related requirements of the enterprise which may, for
example, include information technology (IT) requirements, and
efficiently developing a business solution deliverables such as an
IT system proposal based upon an articulated set of those
requirements. Ruffin is further directed to modifying an existing
business environment (such as an existing IT infrastructure) to
more closely coincide with articulated business requirements or to
developing a new business system (such as a new IT
infrastructure) coincident with those requirements. Ruffin 1: 8-21.
11
Appeal2013-004544
Application 11/773,985
19. Ruffin describes the successive logical generation of a set of
information processing requirements as well as the determination,
based upon the generated set of processing requirements of IT
solutions optimized to best match the generated set of
requirements. Ruffin 3 :29-4 3.
20. Ruffin describes data gathering facilities used to identify
"islands" or partitions, of a plurality of elements of an existing IT
environment which are grouped together by virtue of one or more
common features among these elements. For each partition,
information regarding the current state of each partition and any
problems that have been identified for the partition, as well as the
future information processing objectives for each partition are
entered. A profile assessment logic tool scores each partition
based upon the profile-based input. Partitions are then ranked in
accordance these logical scores and indications. For each ranked
partition a correction logic device provides an assessment of
whether the partitions have been properly identified. For example,
the correction logic will determine whether the amount of work to
be done to address the objectives and problems in an identified
partition is too great in scope, such that the partition should be
further divided into smaller or different partitions. In this iterative
manner the partitioning process is continually refined. Ruffin
3:44--4:25.
21. Ruffin describes attacking these "islands" or partitions, of a
plurality of elements of an existing IT environment with plural
processes in a divide and conquer approach. Ruffin 7:36-54.
12
Appeal2013-004544
Application 11/773,985
ANALYSIS
Appellants argue claim 1 only. Claim 1 recites a method predicated on
providing data in the form of a set of services, a repository of service
designs, and a collection of policies (steps 1-3) to implement a design tool
to define project scope, select service elements, and navigate the services
(step 4). The implementation provides the design tool with plural execution
engines to interpret plural types of metadata (step 5) and these execution
engines include a policy execution engine to evaluate predicates and an
architecture composition engine to somehow create a consolidated view of
the architecture and identify duplication and opportunities for consolidation
(step 6).
Much of claim 1 is taken up by the components and their
interrelationships, which are not at issue as Benny generally describes these.
The two issues Appellants argue are whether the art describes the step 6
architecture composition engine (App. Br. 22-24) and whether the art
describes using the tool to identify semantics of the policies and of
architectural description and using architectural descriptions to provide
automated support for technical solution design (id. at 24--28). Associated
with this second issue is whether it is proper to combine the references to
show this. Id.
As to the first issue, we are not persuaded by the Appellants' argument
that Benny only describes combining design objects, and does not describe
"combining components of each service design to create a consolidated view
of the target IT architecture." Id. at 23. As the Examiner found, claim 1
does not recite actually combining components of each service design to
13
Appeal2013-004544
Application 11/773,985
create a consolidated view of the target IT architecture, but only providing
an architecture composition engine that can be somehow used to do so.
Benny describes a view of a complete list of design objects over a global
network. FF. 11. As the view covers the entire global network, it is
inherently consolidated across the globe. Appellants admit that Benny
para. 128 describes combining design objects (App. Br. 23), but do not say
why this is not within the scope of combining architecture components. The
objects listed on Benny Figure 17, including various pieces of equipment,
are parts of the entire architecture and therefore are components of the
architecture. Appellants go on to argue that Ruffin does not cure Benny
(App. Br. 20), but Ruffin was only applied to show it was known to
apportion an implementation across plural processes according to differing
requirements in a divide and conquer approach (FF. 21 ).
As to the second issue, we are not persuaded by the Appellants'
argument regarding identifying semantics in claim 1 that
the Examiner merely finds the same or similar words or terms
in Dangelo et al. and then alleges that Dangelo et al. teaches or
suggests the above-identified claimed feature without
considering the subject matter in claim 1 as whole. Although
Dangelo et al. recites similar words as those used in claim 1,
Dangelo et al. does not teach or suggest the above-identified
claimed feature.
App. Br. 25. As the Examiner found, Dangelo describes "using a tool to
identify semantics of the policies and of architectural descriptions and to
utilize said architectural descriptions to provide automated support for
technical solution design." Final Act. 5---6. Appellants argue that because
Dangelo does so for circuit design, Dangelo is non-analogous and does not
describe applying such analysis to IT services. App. Br. 28.
14
Appeal2013-004544
Application 11/773,985
"The test for obviousness is not whether the features of a secondary
reference may be bodily incorporated into the structure of the primary
reference .... Rather, the test is what the combined teachings of [those]
references would have suggested to those of ordinary skill in the art." In re
Keller, 642 F.2d 413, 425, (CCPA 1981); see also In re Sneed, 710 F.2d
1544, 1550, (Fed. Cir. 1983) ("[I]t is not necessary that the inventions of the
references be physically combinable to render obvious the invention under
review."); In re Nievelt, 482 F.2d 965, 968 (CCPA 1973) ("Combining the
teachings of references does not involve an ability to combine their specific
structures.").
As the Examiner further found,
not only is Dangelo in the field of the Appellant's endeavor as
it is concerned with using tools to provide design solutions, but
it is also reasonably pertinent to the particular problem of
identifying semantics of policies and descriptions in order to
provide support for a technical solution design which is what
the Appellant seeks to do.
Ans. 6-7. The Examiner applied Dangelo only to show that as designs are
inherently documentary in nature, some form of data parsing and semantic
analysis is required to interpret and act upon design documents. Dangelo
shows it was known to create a design analysis language for doing so, and
the implementation of any language requires both syntactic and semantic
analysis and synthesis. Thus it was predictable to apply the use of semantic
identification in a design language for implementing the design services of
Benny.
15
Appeal2013-004544
Application 11/773,985
CONCLUSIONS OF LAW
The rejection of claims 1-3, 9-11, 15-17, and 20 under 35 U.S.C.
§ 103(a) as unpatentable over Benny, Goiffon, Dangelo, and Ruffin is
proper.
The rejection of claims 4, 5, 12, 13, 18, and 19 under 35 U.S.C. § 103(a)
as unpatentable over Benny, Goiffon, Dangelo, Ruffin, and Carpenter is
proper.
DECISION
The rejections of claims 1-5, 9-13, and 15-20 are affirmed.
No time period for taking any subsequent action in connection with this
appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R.
§ 1.136(a)(l)(iv) (2011).
AFFIRMED
16