Ex Parte Martin et al

Board of Patent Appeals and Interferences

Sep 26, 2011

10630071 (B.P.A.I. Sep. 26, 2011)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________________

Ex parte TERRY M. MARTIN, JAY D. KNITTER, and
BLAINE R. SOUTHAM
____________________

Appeal 2009-012064
Application 10/630,071
Technology Center 2400
____________________

Before ERIC S. FRAHM, KALYAN K. DESHPANDE, and ERIC B.
CHEN, Administrative Patent Judges.

DESHPANDE, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2009-012064
Application 10/630,071

2

STATEMENT OF CASE
1

The Appellants seek review under 35 U.S.C. § 134(a) of a final
rejection of claims 1-4, 8-9, 11, 21, and 23-25, the only claims pending in
the application on appeal. Claims 5-7, 10, 12-20, 22, and 26-36 have been
cancelled. We have jurisdiction over the appeal pursuant to 35 U.S.C.
§ 6(b).
We AFFIRM.

The Appellants invented methods and systems for collecting data
regarding a messaging session. Specification 4:14-15.
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 collecting data regarding a messaging session, the
method comprising:
[1] intercepting an incoming message sent to a first network
service;
[2] writing a session identifier to a thread-local variable, the
session identifier identifying a messaging session to which the
incoming message relates;
[3] storing in a database in relation to the session identifier session
data relevant to the incoming message, the session data at least
including a message received time;
[4] providing the incoming message to the first network service;
sending an outgoing message from the network service to a second
network service or a client;
[5] intercepting the outgoing message sent by the first network
service;

1
Our decision will make reference to the Appellants’ Appeal Brief (“App.
Br.,” filed Oct. 30, 2008) and Reply Brief (“Reply Br.,” filed Mar. 26,
2009), and the Examiner’s Answer (“Ans.,” mailed Jan. 26, 2009), and Final
Rejection (“Final Rej.,” mailed Sep. 16, 2008).
Appeal 2009-012064
Application 10/630,071

3
[6] performing a thread-local variable lookup so as to retrieve the
session identifier written to the thread-local variable;
[7] storing in the database in relation to the session identifier
session data relevant to the outgoing message, the session data at least
including a message sent time; and
[8] providing the outgoing message to the second network service
or client.

REFERENCES
The Examiner relies on the following prior art:
Kennedy US 6,330,589 B1 Dec. 11, 2001
Karakashian et al. US 2004/0064503 Al Apr. 1 ,2004
Kaler et al. US 2004/0199586 Al Oct. 7, 2004

REJECTION
Claims 1-4, 8-9, 11, 21, and 23-25 stand rejected under 35 U.S.C.
§ 103(a) as unpatentable over Karakashian, Kaler, and Kennedy. Ans. 3-7.

ISSUE
The issue of whether the Examiner erred in rejecting claims 1-4, 8-9,
11, 21, and 23-25 under 35 U.S.C. § 103(a) as unpatentable over
Karakashian, Kaler, and Kennedy turns on whether the combination of
Karakashian, Kaler, and Kennedy teach or suggest limitations [2], [3], [6],
and [7] of claim 1.

FACTS PERTINENT TO THE ISSUE
The following enumerated Findings of Fact (FF) are supported by a
preponderance of the evidence.
Appeal 2009-012064
Application 10/630,071

4
Facts Related to the Prior Art
Karakashian
1. Karakashian is directed to a system for using an implementation
such as JAX-RPC for invoking a web service from a Java client
application. Karakashian ¶ 0004.
2. A message context is a representation of a web service
invocation flowing through a container. A protocol adapter is
responsible for processing incoming requests in a manner that
allows the web service container to process web service messages
in various formats. Karakashian ¶¶ 0034-0035.
3. An invocation context is an inheritable thread-local object that
can store arbitrary context data and can be used to implement the
protocol adapter functionality. Typical data stored are on the
context include a conversation ID, a message sequence number,
and a security token. An invocation handler can choose to make
the invocation context available to the target component. This
allows application code to read and write to the invocation
context. Karakashian ¶ 0038.
4. An invocation handler insulates the web service container from
the target object lifecycle assuming responsibility for a number of
tasks, including the responsibility for propagating any contextual
state, such as conversation ID, as may be needed. Karakashian
¶ 0044. A stateful session bean invocation handler maintains a
table of mappings between the conversation ID and handlers. If
Appeal 2009-012064
Application 10/630,071

5
no conversation ID is found, the stateful invocation handler
creates a new conversation ID. Karakashian ¶ 0055.
Kaler
5. Kaler is directed to using expressive session information to
represent communication sessions in a distributed system. Kaler
¶ 0002.
Kennedy
6. Kennedy is directed to managing conversation threads by using a
client-based database. Kennedy 1:7-10.
7. Message related information is stored in a database. During a
client-server session, message related information is retrieved
from the server. Based on message related information a
determination is made as to whether the message has been
previously downloaded from the server to the client. Message
related information includes a message identifier and a posted or
sent time. Kennedy 3:10-44.

ANALYSIS
Claims 1-4, 8-9, 11, 21, and 23-25 rejected under 35 U.S.C. § 103(a)
as unpatentable over Karakashian, Kaler, and Kennedy
The Appellants first contend that Karakashian fails to describe
“writing a session identifier to a thread-local variable, the session identifier
identifying a messaging session to which the incoming message relates,” as
required by limitation [2] of claim 1. App. Br. 9-10 and Reply Br. 2. The
Appellants agree that Karakashian describes an invocation context and a
Appeal 2009-012064
Application 10/630,071

6
conversation ID, but specifically argue that Karakashian fails to describe
writing the ID to a thread-local variable. App. Br. 9-10.
We disagree with the Appellants. Karakashian describes a system for
implementing web services. FF 1. The system uses a protocol adapter to
process incoming message requests. FF 2. The protocol adapter
functionality can be implemented using an invocation context. FF 3. The
invocation context is an inheritable thread-local object that can store
arbitrary context data. FF 3. Typical data stored on the thread-local object
include a conversation ID, a message sequence number, and a security
token. FF 3. Application code is enabled to read and write to the thread-
local object if the object is made available to the target component. FF 3.
As such, this issue turns on whether Karakashian’s description of
storing a conversation ID on a thread-local object such that other
components have read/write access to the conversation ID teaches or
suggests writing the conversation ID to the thread-local object. We find that
it does. Storing a session or conversation ID on an object requires that the
ID must have been written to the object in some manner. That is, a person
with ordinary skill in the art would have understood Karakashian’s
disclosure of storing a conversation ID on a thread-local object to encompass
writing the conversation ID to the thread-local object. The Appellants have
failed to present any evidence or rationale to distinguish the Examiner’s
finding that storing an ID from the claimed writing of the ID. As such, the
Appellants’ argument is not found to be persuasive.
The Appellants further contend that Karakashian fails to describe
“performing a thread-local variable lookup so as to retrieve the session
identifier written to the thread-local variable,” as required by limitation [6]
Appeal 2009-012064
Application 10/630,071

7
of claim 1. App. Br. 10-11 and Reply Br. 3. We disagree with the
Appellants. As discussed supra, the thread-local variable includes data such
as a conversation ID. The system further passes the conversation ID to
target objects. FF 4. An invocation handler performs the task of
propagating any contextual state, such as a conversation ID, as is needed by
the target component. FF 4. A stateful session bean invocation handler
maintains a table of mappings between a conversation ID and invocation
handlers. FF 4. If no conversation ID is found, the stateful session bean
invocation handler creates one. FF 4. That is, the handler performs a lookup
to determine whether a conversation ID exists in order to retrieve the
conversation ID, which is in turn, is passed to the target object. As such,
Karakashian describes performing a thread-local variable lookup. The
Appellants fail to present any further evidence or rationale to distinguish the
claimed limitations from the prior art.
The Appellants additionally contend that the combination of
Karakashian, Kaler, and Kennedy fails to describe “storing in a database in
relation to the session identifier session data relevant to the incoming
message, the session data at least including a message received time,” and
“storing in the database in relation to the session identifier session data
relevant to the outgoing message, the session data at least including a
message sent time,” as required by limitations [3] and [7] of claim 1
respectively. App. Br. 11-12 and Reply Br. 4-5.
We disagree with the Appellants. Kennedy describes a system for
managing conversation threads by using a client-based database. FF 6. The
system utilizes message related information in managing threads, where the
message related information includes a message identifier and a posted or
Appeal 2009-012064
Application 10/630,071

8
sent time. The posted time indicates the time that a message is posted to the
database. FF 7. That is, the post time is the time a message is received by
the database.
The Examiner found that the post time is the time a message is
received. Ans. 9. Although such a construction of the term “post time” may
be considered broad, the Appellants have failed to provide any evidence or
rationale to illustrate why the Examiner’s construction is either unreasonable
or inconsistent with the Specification. Absent any further evidence or
rationale, we find that the Examiner’s construction of a post time to
encompass a received time to be reasonable and consistent with the
Specification.
Kennedy further describes a sent time. FF 7. The Appellants argue
that although Kennedy describes a sent time, Kennedy fails to describe that
the sent time represents the time a message was sent from a first network
service to a second network service or client. App. Br. 11-12 and Reply Br.
5. However, Kennedy describes the sent time is the time that a client
submits a message to a server. FF 7. We find that this sent time is the time
a message is sent from one network device or service to a second network
device or service. The Appellants have failed to provide any further
rationale or evidence to distinguish the claimed invention from the prior art.
As such, the Appellants’ arguments are not found to be persuasive.

CONCLUSIONS OF LAW
The Examiner did not err in rejecting claims 1-4, 8-9, 11, 21, and 23-25
under 35 U.S.C. § 103(a) as unpatentable over Karakashian, Kaler, and
Kennedy.
Appeal 2009-012064
Application 10/630,071

9

DECISION
To summarize, our decision is as follows.
 The rejection of claims 1-4, 8-9, 11, 21, and 23-25 under 35 U.S.C.
§ 103(a) as unpatentable over Karakashian, Kaler, and Kennedy is
sustained.

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) (2010).

AFFIRMED

ELD