Ex Parte Martin et alDownload PDFBoard of Patent Appeals and InterferencesSep 26, 201110630071 (B.P.A.I. Sep. 26, 2011) Copy Citation 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 Copy with citationCopy as parenthetical citation