Ex Parte Gilfix et al

Patent Trial and Appeal Board

Aug 29, 2013

11553287 (P.T.A.B. Aug. 29, 2013)

UNITED STATES PATENT AND TRADEMARK OFFICE
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
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
11/553,287 10/26/2006 Michael A Gilfix AUS920060637US1 3520
50170 7590 08/29/2013
IBM CORP. (WIP)
c/o WALDER INTELLECTUAL PROPERTY LAW, P.C.
17330 PRESTON ROAD
SUITE 100B
DALLAS, TX 75252
EXAMINER
COLLINS, JOSHUA L
ART UNIT PAPER NUMBER
2491
MAIL DATE DELIVERY MODE
08/29/2013 PAPER
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.
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte MICHAEL A. GILFIX and RHYS D. ULERICH
____________

Appeal 2011-002766
Application 11/553,287
Technology Center 2400
____________

Before DENISE M. POTHIER, HUNG H. BUI, and MATTHEW R.
CLEMENTS, Administrative Patent Judges.

POTHIER, Administrative Patent Judge.

DECISION ON APPEAL
STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1, 3-6, 8-11, 13-16, and 18-24. Claims 2, 7, 12, and 17
have been canceled. App. Br. 2. We have jurisdiction under 35 U.S.C.
§ 6(b).
We affirm-in-part.
Invention
Appellants’ invention relates to an interface design tool that includes
traditional call flow design views (e.g., 804) and web service design
language (WSDL) interface design views (e.g., 802). The call flow design
Appeal 2011-002766
Application 11/553,287

2
view can group call flow into segments (e.g., Segments 1-3) and allow for
labeling of each message in a segment (e.g., “BYE” or “200 OK” in
Segment 3). Mappings (e.g., 806) between a WSDL operation (e.g.,
“endCall”) and a call flow step or message (e.g., step 10 in Segment 3) can
be created. See Abstract; ¶ 0096; Fig. 8.
Claim 1 is illustrative of Appellants’ invention and is reproduced
below with disputed limitations emphasized:
1. A method for merging session initiation protocol call flow with
Web services, the method comprising:
providing a user interface having a Web services design portion and a
session initiation protocol call flow design portion, wherein the Web
services design portion presents at least one Web services component and
wherein the session initiation protocol can flow design portion presents at
least one session initiation protocol call flow segment having a series of
session initiation protocol message steps;
receiving a graphical user interface component from a user, wherein
the graphical user interface component graphically connects a selected Web
services component with a selected session initiation protocol message step;
generating a mapping that associates the selected Web services
component and the selected session initiation protocol message step; and
binding the selected Web services component with the selected
session initiation protocol message step.

The Examiner relies on the following as evidence of unpatentability:
Mamou US 2005/0086360 A1 Apr. 21, 2005

Hong Cai et al., Session Initiation Protocol and Web Services for Next
Generation Multimedia Applications, 2002 Proc. of the IEEE Fourth Int’l
Sym. Multimedia Software Engineering 70-80 (2002) (“Cai”).

The Rejection
Claims 1, 3-6, 8-11, 13-16, and 18-24 are rejected under 35 U.S.C.
§ 103(a) as unpatentable over Mamou and Cai. Ans. 4-20.
Appeal 2011-002766
Application 11/553,287

3
THE CONTENTIONS
Regarding illustrative independent claim 1, Appellants argue: (1)
Mamou’s Figures 22, 34, and 61 and paragraphs 0189, 0231, and 0257 do
not mention a graphical user interface (GUI) component that graphically
connects a Web services component with a session initiation protocol (SIP)
message step but rather just an association between data integration jobs
(App. Br. 6-8, 11; Reply Br. 2-3, 7); (2) Mamou and Cai collectively would
not result in the recited combination (App. Br. 9-10; Reply Br. 4-5, 7); and
(3) the Examiner provides no explanation or technical reasoning as to how
one skilled in the art would use Cai to publish SIP call flow as Web services
in Mamou and relies on impermissible hindsight in formulating the rejection
(App. Br. 10; Reply Br. 4).

ISSUES
(1) Under § 103, has the Examiner erred in rejecting claim 1 by
finding that Mamou and Cai collectively would have taught or suggested
receiving a GUI component from a user, wherein the GUI component
graphically connects a selected Web services component with a selected SIP
message step?
(2) Regarding claim 1, is the Examiner’s reason to combine the
teachings of Mamou and Cai supported by articulated reasoning with some
rational underpinning to justify the Examiner’s obviousness conclusion?

ANALYSIS
Based on the record before us, we find no error in the Examiner’s
rejection of independent claim 1. Appellants argue that Mamou’s Figure 61
Appeal 2011-002766
Application 11/553,287

4
fails to teach a GUI component that graphically connects a Web services
component with a SIP message step. App. Br. 7-8. We are not persuaded.
First, as noted (Ans. 25-26), the Examiner relies on both Mamou and
Cai to meet the recited step of receiving a GUI component from a user,
wherein the GUI component graphically connects a selected Web services
component with a selected SIP message step. In particular, the Examiner
turns to Cai to teach the specific recitation to the SIP message step and to
combine this teaching with Mamou. Ans. 6-7. Thus, attacking Mamou
alone does not show nonobviousness.
Second, we disagree that Mamou “makes no mention whatsoever of a
graphical user interface component that graphically connects a Web services
component with a session initiation protocol [“SIP”] message step.” App.
Br. 8 (emphases omitted). Moreover, identity of terminology between
Mamou or Cai and claimed limitation is not required to teach the recited
step. See In re Bond, 910 F.2d 831, 832 (Fed. Cir. 1990). As such, even if
Mamou fails to state explicitly the germs “graphical user interface
component,” “graphically connects,” or “message step,” this does not
demonstrate the reference does not teach or suggest the disputed receiving
step.
Mamou discusses a GUI 2102 that allows a user to align icons or
representations (e.g., squares, octagons, lines, and arrows) of targets,
sources, and functions and to create associations or command structure
between the icons for a data integration job 2202. Ans. 5-6, 24 (citing Fig.
22, ¶ 0189); see also ¶ 0039. For example, element 2104 shows various
icons connected to each other with arrows. See Fig. 22. Similarly,
Appellants describe a GUI component called a “rubber-band component
Appeal 2011-002766
Application 11/553,287

5
806” that is an arrow connecting a Web service component to a message
step. See Spec. ¶ 0096; Fig. 8. The Examiner also finds that tools 2106 or
icons can represent databases, transformation tools, targets, and path
identifiers and maps these representations to web service components. See
Ans. 5 (citing Fig. 21; ¶ 0188). Additionally, Mamou teaches that a “data
source” or “data target” include data providers, websites, web browsers, and
message services or other web components. ¶ 0127. Thus, Mamou suggests
that a user can select from various icons, including a GUI component such
as an arrow, and graphically connect the GUI component with other icons,
which can represent web services components (e.g., databases, websites) as
well as message services and functions.
The Examiner’s position is further supported by cited Figure 34 in
Mamou. Ans. 5-6, 22-23. As explained (see Ans. 22-23), Mamou describes
and shows a GUI 3400 that allows a user to design a data integration job
(e.g., getCustomerInfo2) and specify parameters. See ¶¶ 0051, 0231; Fig.
34. Icons includes those that represent data integration tasks or steps (e.g.,
Get the SSN of the Customer 3408, Call an external Web Service 3410) and
are connected with connectors that represent data flow into and out of each
task (e.g., 3408, 3410) of job 3134. For example, Mamou shows task 3408
that gets a social security number (SSN) of a customer using CustomersDB
(e.g., a Web services component) and graphically connecting (e.g., using an
arrow) the database to a function (e.g., LookupMatched Customer). See id.
The Examiner further finds that a function such as
LookupMatchedCustomer typically involves querying or a call flow process
using a messaging service like SQL and SOAP (Simple Object Access
Protocol) messaging protocols. See Ans. 23 (citing ¶ 0195); see also ¶ 0197.
Appeal 2011-002766
Application 11/553,287

6
Specifically, Mamou states web services are invoked by sending a service
provider a SOAP message as described in the WSDL. See ¶ 0195; Fig. 24.
Appellants do not challenge these findings. See generally Reply Br.
Moreover, Mamou states that the icons can represent pulling data from a
messaging queue. ¶ 0231; see also Reply Br. 3 (citing ¶ 0231). Given that
Appellants describe SOAP as a message-based protocol (¶ 0007), we agree
with the Examiner that Mamou teaches and suggests a Web service
component (e.g., CustomersDB) graphically connected to a message step
(e.g., LookupMatchedCustomer). As another example, Mamou shows that
the CustomersDB is graphically connected indirectly to task 3410 (Call an
external Web Service) through DSLink8. See Ans. 5 (discussing this calling
step). Based on the Examiner’s findings that these functions require some
type of querying using a messaging service, we further find Mamou shows
numerous examples of a Web services component graphically connected to a
message step.
However, as the Examiner acknowledges Mamou does not
specifically teach graphically connecting a Web services component with a
selected SIP call flow or message step. See Ans. 6-7, 23-26. For this
missing feature, the Examiner turns to Cai. See id. Cai teaches that an
ordinarily skilled artisan would have recognized “standard ways” to
implement SIP components as Web Services by “publishing WSDL files to
UDDI.” Cai § 4.2. Moreover, Appellants admit that Mamou and Cai
suggest integrating a SIP component into a data integration job at a high
level. Reply Br. 4. Thus, when combined, the references teach and suggest
receiving a GUI component from a user, wherein the GUI component
Appeal 2011-002766
Application 11/553,287

7
graphically connects a Web services component with a selected SIP message
step as recited in claim 1.
Furthermore, we further agree with the Examiner (see Ans. 7, 37-38)
that such a combination is nothing more than a simple substitution of one
protocol (e.g., SIP messaging) for another known protocol (e.g., SOAP
messaging) in the field and yields a predictable result. See KSR Int’l Co. v.
Teleflex Inc., 550 U.S. 398, 416 (2007). Notably, while Appellants question
how one would integrate a GUI component as recited (see App. Br. 10),
“[t]he 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). As discussed above, Mamou and
Cai suggest the recited receiving step, teaching more than general concepts
as disputed by Appellants. See Reply Br. 4-5.
Appellants also contend the Examiner provides no explanation or
technical reasoning as to how one would use Cai to publish SIP call flow as
a Web service in Mamou. App. Br. 10; Reply Br. 4. We disagree. The
Examiner states one skilled in the art would have combined Cai’s messaging
protocol with Mamou to increase operability between protocols (Ans. 6-7)
and support the other web services as taught in Mamou (Ans. 31). We find
both explanations have a rational underpinning to support an obviousness
rejection. See Mamou ¶ 0197 (discussing “other web services clients” can
use the enterprise data integration method); see also Ans. 31. Thus, the
Appeal 2011-002766
Application 11/553,287

8
Examiner is not relying on impermissible hindsight in formulating the
obviousness rejection. App. Br. 9-10
1
; Reply Br. 4.
Appellants also assert that both Mamou and Cai fail to teach or
suggest various recited limitations (e.g., the generating and binding steps)
because neither teaches the receiving step. App. Br. 8-9; Reply Br. 5-6.
These arguments attack each reference individually and fail to show
nonobviousness. As stated above, we are not persuaded that Mamou and
Cai collectively fail to teach or suggest the receiving step. Additionally,
merely asserting without any further argument that Mamou (App. Br. 8) or
Cai (App. Br. 9) fail to teach the providing, generating and binding steps is
not considered a separate argument for patentability. See In re Lovin, 652
F.3d 1349, 1357 (Fed. Cir. 2011). Moreover, because claim 1 does not
recite merging SIP call flow with Web services (see App. Br. 8) or allowing
a user to select a particular SIP message step as a binding point using a GUI
component (Reply Br. 3), we find these arguments unpersuasive.
Finally, for the first time in Reply Brief, Appellants focus on the
recited language, “receiving a graphical user interface component from the
user,” and argues neither Mamou nor Cai teaches this feature. We disagree
for the above reasons. Appellants also contend for the first time in the Reply
Brief that neither Mamou nor Cai teaches a call flow design portion that
presents at least one call flow segment having a series of messaging steps.
Reply Br. 5. This argument is waived. See Ex parte Borden, 93 USPQ2d

1
Appellants argue the combination would require undue experimentation.
App. Br. 10. We find that this is not the test for obviousness but rather for
enablement. See In re Wright, 999 F.2d 1557, 1561 (Fed. Cir. 1993); see
also In re Wands, 858 F.2d 731, 737 (Fed. Cir. 1988).

Appeal 2011-002766
Application 11/553,287

9
1473, 1474 (BPAI 2010) (informative). Nonetheless, for purposes of
completeness, we remain unpersuaded by Appellants’ belated argument for
the reasons discussed above and in the Examiner’s Answer (see, e.g., Ans.
5).
For the foregoing reasons, Appellants have not persuaded us of error
in the rejection of independent claim 1 and claims 5, 6, 11, 15, 16, 20, and
22 not separately argued with particularity (App. Br. 11).

Claims 3, 4, 13, and 14
Regarding illustrative claim 3, Appellants argue that Mamou fails to
teach a SIP call flow and neither Mamou nor Cai teaches the disputed
receiving step in claim 1. App. Br. 11-12; Reply Br. 7-8. For this reason,
Appellants contend Mamou and Cai fail to teach the labeling step in claim 3.
App. Br. 12. We are not persuaded.
As discussed above, we disagree with Appellants’ contention that
Mamou and Cai fail to collectively teach and suggest the receiving step,
including the limitation to SIP call flow segment having messages steps.
Also, in arriving at our decision, we need not consider whether labeling with
a specific type is a matter of design choice and what is inherent in SIP
functionality. See Ans. 39. For the foregoing reasons, Appellants have not
persuaded us of error in the rejection of claim 3 and claims 4, 13, and 14 not
separately argued with particularity.

Claims 8, 21, and 23
Regarding illustrative claim 8, Appellants argue that the Examiner
provided no analysis or reasoning why Mamou teaches or suggests merging
Appeal 2011-002766
Application 11/553,287

10
extensible markup language description of a call flow segment with a WSDL
description of a Web services component. App. Br. 12; Reply Br. 8-9. We
disagree. The Examiner: (1) cites to Mamou (Fig. 43, #4302), where entries
in Wizard are recorded (e.g., merged) in WSDL for a real time integration
(RTI) service (see ¶ 0241), (2) finds Cai teaches SIP call flows, and (3)
concludes that Mamou and Cai collectively teach merging the extensible
markup language description of the SIP call flow segment with the WSDL
description so as to establish the new service (e.g., SIP call flow segment).
Ans. 9, 40-41. This illustrates that the Examiner has provided some
evidence for the recited merging step and an analysis for including such a
feature as claimed based on Mamou and Cai. In sum, Appellants have not
persuaded us of error in the rejection of claim 8 and claims 21 and 23 not
separately argued with particularity.

Claims 9, 18, and 24
The Examiner finds Mamou and Cai collectively teach the limitations
recited in illustrative claim 9. See Ans. 9, 41-42. Appellants argue that
Mamou does not teach a WSDL description may include a binding or
inserting a binding element to bind a Web services component and selected
SIP message step as recited. App. Br. 12-13; Reply Br. 9-10. Apart from
merely asserting that these limitations are not found in Mamou, Appellants
do not specifically address the Examiner’s positions articulated in the
Answer or explain why these positions are deficient. Merely pointing out
what a claim recites is not considered an argument for separate patentability
of the claim. 37 C.F.R. § 41.37(c)(1)(vii). In any event, such conclusory
Appeal 2011-002766
Application 11/553,287

11
statements fall well short of rebutting the Examiner’s prima facie case of
obviousness articulated in the rejection – a position that we find reasonable.
For the above reasons, Appellants have not persuaded us of error in
the rejection of claim 9 and claims 18 and 24 not separately argued with
particularity.

Claims 10 and 19
Lastly, claims 10 and 19 recite the SIP call flow segment comprises a
first SIP call flow segment with message steps and a second SIP call flow
segment with message steps, as well as receiving a second mapping within a
user interface associating a first SIP message step from within the first SIP
call flow segment with a second SIP message step within the second SIP call
flow segment and binding the first SIP message step with the second SIP
message step.
The Examiner finds Mamou teaches the first and second SIP call flow
segments at Figures 17 and 18 and paragraphs 0271-72 and 0189, the
receiving step at Figure 22 and paragraphs 0278-80, and the binding step at
paragraph 289. Ans. 10. According to the Examiner, the specific SIP call
flow segments limitations are taught by Cai. Ans. 11; see also Ans. 42-45.
Appellants argue that neither Mamou nor Cai teaches mapping a first
selected message step with a second selected message step and binding the
steps, as recited in claims 10 and 19. App. Br. 13; Reply Br. 10-11.
Appellants further assert that Cai does not teach the mapping limitation, but
only creating and instantiating Web services for SIP call flow. App. Br. 13.
While acknowledging the rejection is based on the collective teachings of
Appeal 2011-002766
Application 11/553,287

12
Mamou and Cai, we agree that these references as presented by the
Examiner fail to teach the disputed limitations.
Figures 17 and 18 show parallel execution of different processes. See
¶¶ 0184-85. Thus, Mamou teaches different call flow segments and when
combined with Cai suggest SIP call flow segments having SIP message
steps as discussed previously. However, this does not teach mapping a first
SIP message step with a second SIP message step and binding them. See id.
Additionally, cited paragraphs 0271 and 0272 (see Ans. 11) in Mamou
discuss Figure 77, which does not concern the parallel execution of different
processes or the limitations in claims 10 and 19.
Mamou teaches graphically connecting functions to teach other in
paragraph 0189 and Figure 22 and creating bindings that allow a service to
be invokes in paragraphs 0278-80. However, we agree with Appellants
(App. Br. 13) that the Examiner has not provided sufficient evidence that
these teachings demonstrates receiving the recited second mapping, which is
separate from the mapping in claim 1, within the user interface that
specifically associates a first SIP message step with a second SIP message
step and then binds the steps as recited.
For the foregoing reasons, Appellants have persuaded us of error in
the rejection of claims 10 and 19
2
.

2
Should prosecution continue, we leave it to the Examiner to determine
whether claims 11, 13-16, 18, and 19 are patent-eligible under 35 U.S.C.
§ 101. See In re Nuijten, 500 F.3d 1346, 1357 (Fed. Cir. 2007); see also
Spec. (describing “a computer program product” accessible from a
computer-usable or computer-readable medium that can be “any apparatus
that can . . . communicate, propagate, or transport the program for use by or
in connection with the instruction execution system, apparatus, or device”
(Spec. ¶ 0121) as well as “a propagation medium” (Spec. ¶ 0122)).
Appeal 2011-002766
Application 11/553,287

13
CONCLUSION
Under § 103, the Examiner did not err in rejecting claims 1, 3-6, 8, 9,
11, 13-16, 18, and 20-24 under § 103, but erred in rejecting claims 10 and
19.

DECISION
The Examiner’s decision rejecting claims 1, 3-6, 8-11, 13-16, and 18-
24 is affirmed.
The Examiner’s decision rejecting claims 10 and 19 is reversed.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv).

AFFIRMED-IN-PART

kis