Ex Parte Klassen et alDownload PDFPatent Trial and Appeal BoardSep 18, 201411416193 (P.T.A.B. Sep. 18, 2014) Copy Citation UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ Ex parte GERHARD DIETRICH KLASSEN, CHRISTOPHER R. WORMALD, and ANDREEA MANOLESCU ____________ Appeal 2012-005544 Application 11/416,193 Technology Center 2400 ____________ Before JOHN A. JEFFERY, STEPHEN C. SIU, and ANDREW J. DILLON, Administrative Patent Judges. JEFFERY, Administrative Patent Judge. DECISION ON APPEAL Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s decision to reject claims 61–90. We have jurisdiction under 35 U.S.C. § 6(b). We reverse. STATEMENT OF THE CASE Appellants’ invention pertains to a protocol for instant message (IM) communications between a client device and a server. The protocol defines a server-maintained tag to identify the currency of a contact list for a client device. To this end, the server compares the tag with a value received from a client device to determine if a contact list update is required on the client Appeal 2012-005544 Application 11/416,193 2 device. See generally Abstract; Spec. ¶¶ 1, 76, 99–100; Figs. 4, 8A–8B. Claim 61 is illustrative: 61. A method of a server device managing a contact list for a client device, the method comprising: the server device defining a tag representing the currency of a contact list corresponding to the client device, the contact list comprising one or more groups of at least one contact associated with a plurality of IM services; the server device storing the tag; the server device updating the tag in response to updates to the contact list; the server device receiving from the client device, a value corresponding to a copy of the tag as previously stored by the client device; the server device comparing the value received from the client device to the tag stored by the server device to determine if a contact list update is required on the client device; for inbound IM communications, the server device: receiving an inbound data packet sent by said client device in accordance with a generic client to server protocol for said plurality of IM services; determining a configuration ID indicated in the inbound data packet, the configuration ID defining a specific IM server; and connecting said client device to said specific IM server; and for outbound IM communications, the server device: sending an outbound data packet according to the generic client to server protocol by including a corresponding configuration ID indicating from which of a plurality of different IM server types the outbound data packet is being sent to enable a recipient device to load a configuration file according to the configuration ID, the recipient device storing more than one such configuration file to address the plurality of different IM server types. Appeal 2012-005544 Application 11/416,193 3 THE REJECTIONS The Examiner rejected claims 61–65, 67–73, 75–80, 82–87, 89, and 90 under 35 U.S.C. § 103(a) as unpatentable over Chen (US 7,120,455 B1; iss. Oct. 10, 2006), Dickerman (US 2003/0177184 A1; pub. Sept. 18, 2003), and Zlateff (US 2006/0195532 A1; pub. Aug. 31, 2006). Ans. 5–14.1 The Examiner rejected claims 66, 74, 81, and 88 under 35 U.S.C. § 103(a) as unpatentable over Chen, Dickerman, Zlateff, and Mendiola (US 2002/0006803 A1; pub. Jan. 17, 2002). Ans. 14–16. THE REJECTION OVER CHEN, DICKERMAN, AND ZLATEFF The Examiner finds that Chen and Dickerman disclose collectively every recited element of independent claim 61 except for the server device (1) defining a tag representing currency of a client device contact list; (2) storing the tag; (3) updating the tag responsive to contact list updates; (4) receiving a value from the client device corresponding to a copy of the tag previously stored by the client device; and (5) comparing the received value to the tag stored by the server device to determine if a contact list update is required on the client device. Ans. 5–9. The Examiner, however, cites Zlateff’s presence document functionality and presence information change notifications as teaching these features in concluding that the claim would have been obvious. Ans. 9–12, 16–20. Appellants argue that the cited prior art does not teach or suggest using a tag to determine contact-list currency as claimed, let alone a server 1 Throughout this opinion, we refer to the Appeal Brief filed August 29, 2011 (“Br.”) and the Examiner’s Answer mailed November 25, 2011 (“Ans.”). Appeal 2012-005544 Application 11/416,193 4 device that compares a value received from a client device with the tag stored by the server device to determine if a contact list update is required on the client device as claimed. Br. 8–12. According to Appellants, the Examiner’s reliance on Zlateff is flawed because (1) presence information is updated between peers instead of using a server, and (2) Zlateff’s tags do not represent contact-list currency as claimed. Br. 11–12. Appellants add that the Examiner fails to articulate reasoning with some rational underpinning to combine the cited references as proposed. Br. 12. ISSUE Under § 103, has the Examiner erred in rejecting claim 61 by finding that Chen, Dickerman, and Zlateff collectively would have taught or suggested a server device (1) defining, storing, and updating a tag representing contact-list currency of a client device, and (2) comparing a value received from the client device to the tag stored by the server device to determine if a contact list update is required on the client device? ANALYSIS We begin by noting that the Examiner’s rejection cites Chen and Dickerman for teaching the server device’s performing the recited limitations associated with inbound and outbound IM communications, respectively. Ans. 5–8. Those limitations are not at issue here. Rather, this dispute turns on the Examiner’s reliance on Zlateff for teaching the server device’s performing the tag-based steps recited in the first five clauses of claim 61. See Ans. 9–12, 16 (noting that Chen is not relied on to disclose a tag for representing the currency of a contact list); 17–18, 20. Accord Br. 9 Appeal 2012-005544 Application 11/416,193 5 (acknowledging that Zlateff was cited to cure the deficiencies of Chen and Dickerman in connection with the first five clauses of claim 61). Accordingly, we confine our discussion to Zlateff. Because this dispute turns on the above-noted tag-based limitations, we first construe the recited tag. According to Appellants’ Specification, an “etag is treated as an opaque string identifier for the current state of the contact list 410 and 430. The etag is stored by the client and no semantic meaning is derived from it.” Spec. ¶ 76. That paragraph adds that “[t]he etag is updated with each response that changes the contents of the contact list and is reported to the IM server 304 on login . . . .” Id. Based on this description, we construe the recited tag as a string identifier representing the current state of a contact list corresponding to the client device. Turning to the rejection, although the Examiner does not squarely map the recited tag to a corresponding element in Zlateff, the Examiner nonetheless refers to Zlateff’s presence document and associated presence information in this regard. See, e.g., Ans. 17 (noting that because Zlateff’s presence document includes information regarding other contact buddies that are currently being instant messaged in paragraph 42, Zlateff’s tag represents a contact list comprising IM users); Ans. 18, 20 (same). To the extent that the Examiner intends to map the recited tag to the presence information within a presence document in Zlateff, we find such a mapping problematic. First, claim 61 recites explicitly that the server device defines, stores, and updates the tag, but also compares that stored tag to a value received from a client device. But Zlateff’s presence document (PD- C1 208) containing the relied-upon presence information resides at the client—not the server. See Zlateff ¶¶ 35–37; Fig. 2. Rather, the server 204 Appeal 2012-005544 Application 11/416,193 6 stores an identification of a client’s presence document—not the document itself. Zlateff ¶ 35 (noting that the identification of PD-C1 224 may be a name of the PD-C1 presence document, a reference or pointer to that document, the document’s location, etc.). So to the extent that the Examiner relies on information in Zlateff’s presence document itself as corresponding to the recited tag, such a tag is not stored at the server device, let alone updated or used as a basis for comparison by that device as claimed. To be sure, Zlateff’s server notifies clients on a dynamic reverse list (DRL) regarding changes in other clients’ presence information in phase 2 of the process shown in Figure 4. Zlateff ¶¶ 43–44. To this end, upon receiving a presence document notification message 402 from the client, the server (1) accesses the DRL that includes those clients that are currently monitoring the notifying client via IM architecture, and (2) sends a new presence document notification message 402 to those clients. Id. ¶¶ 26, 44. Then, in phases 3 and 4, the monitoring clients receive updated presence document information via a new presence document message 406 from the monitored client upon request. Id. ¶ 46. Although this latter data exchange and updating process is solely between peers, messages 404 and 406 can nonetheless be routed through server 204. Id. ¶ 47. Still, we fail to see how this server-based routing teaches that the server device defines, stores, and updates a tag (which has not been identified clearly in any event), but also compares that stored tag to a value received from a client device for contact list updating as claimed. At best, Zlateff’s server functions as an intermediary between clients in their sharing presence information: an intermediary role that falls short of performing the recited tag-based steps in the first five clauses of claim 61. Appeal 2012-005544 Application 11/416,193 7 We reach this conclusion despite Zlateff’s presence document notification message containing a client ID, associated presence document ID, and presence document deltas as shown in Figure 5. Although this data is sent from the server, we fail to see how the associated process corresponds to the recited tag-based steps. The Examiner’s reliance on the verification value computation and comparison in Zlateff’s Figure 6 (see Ans. 17–18, 20) is likewise unavailing, for this value is computed by a client—not a server. See Zlateff ¶ 59. As shown in Figure 6, the associated process occurs between two clients. Nevertheless, to the extent that the server is involved in this process, it merely functions as an intermediary as noted above. Nor will we speculate whether the Examiner intends to map the recited tag to Zlateff’s presence document deltas 506 in the new presence document notification message 402 that the server transmits to monitoring clients as shown in Figure 5. Although the Examiner refers to tags and deltas in connection with this message (Ans. 9–11, 17), it is unclear whether these deltas are, in fact, intended to be mapped to the recited tags. Nevertheless, the Examiner’s using the conjunctive term “and” in this regard weighs against their equivalency, for the Examiner’s language suggests that the tags are in addition to—and therefore different from—the deltas. In any event, the Examiner’s reference to Zlateff’s paragraph 39 in this regard only further undermines the Examiner’s position, for this paragraph does not pertain to the notification message sent by the server, but rather the presence document’s tag-based information located at the client—not the server. To be sure, the DRL stored on the server includes only those clients that are currently monitoring a particular client via IM architecture. See Appeal 2012-005544 Application 11/416,193 8 Zlateff ¶¶ 26, 45, 50. To the extent that the Examiner relies on the DRL and any tags associated with this list in connection with the recited tag-based steps has not been articulated clearly on this record. Nor will we speculate in that regard here in the first instance on appeal. What we can say, however, is that the Examiner’s articulated position is untenable on this record. Therefore, even if the cited references are combinable as the Examiner proposes, the Examiner has still not shown that they teach or suggest the server device’s performing the tag-based steps recited in the first five clauses of claim 61. Accordingly, we are persuaded that the Examiner erred in rejecting (1) independent claim 61; (2) independent claims 69, 77, and 84 that recite commensurate limitations; and (3) dependent claims 62– 65, 67, 68, 70–73, 75, 76, 78–80, 82, 83, 85–87, 89, and 90 for similar reasons. THE REMAINING OBVIOUSNESS REJECTION Because the Examiner has not shown that the additional cited prior art cures the foregoing deficiencies regarding the independent claims, we will not sustain the obviousness rejection of dependent claims 66, 74, 81, and 88 (Ans. 14–16) for similar reasons. CONCLUSION The Examiner erred in rejecting claims 61–90 under § 103. DECISION The Examiner’s decision rejecting claims 61–90 is reversed. Appeal 2012-005544 Application 11/416,193 9 REVERSED mls Copy with citationCopy as parenthetical citation