Ex Parte Hiir et al

Patent Trial and Appeal Board

Feb 27, 2017

11937069 (P.T.A.B. Feb. 27, 2017)

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/937,069 11/08/2007 Tanel Hiir 335377-US-NP 1992
69316 7590 03/01/2017
MICROSOFT CORPORATION
ONE MICROSOFT WAY
REDMOND, WA 98052
EXAMINER
TANG, KAREN C
ART UNIT PAPER NUMBER
2447
NOTIFICATION DATE DELIVERY MODE
03/01/2017 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):
u sdocket @ micro soft .com
chriochs @microsoft.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte TANEL HIIR, KAIDO KARNER,
PRIIT KASESALU, MATIKOSEMAE, AARNE LAUR,
MIHKEL KARU, and SVEN SUURSOHO
Appeal 2015-006031
Application 11/937,069
Technology Center 2400
Before CARL W. WHITEHEAD JR., KEVIN C. TROCK, and
AARON W. MOORE, Administrative Patent Judges.
MOORE, Administrative Patent Judge.
DECISION ON APPEAL
Appeal 2015-006031
Application 11/937,069
STATEMENT OF THE CASE
Appellants1 appeal under 35 U.S.C. § 134(a) from a Final Rejection of
claims 1—25, which are all of the pending claims. We have jurisdiction
under 35 U.S.C. § 6(b).
We reverse.
THE INVENTION
The application is directed to “a method of delivering messages to a
user of a user terminal executing a communication client and connected to a
packet-based communication network.” (Abstract.) Claim 1, reproduced
below with the disputed claim language in italics, is representative:
1. A method comprising:
receiving a message at a user terminal from a communication
network, the message comprising a content portion and a control
portion, the content portion comprising information for display
at the user terminal, the control portion comprising data defining
a condition and a trigger event that causes the condition to be
checked when the trigger event occurs at the user terminal to
determine if the condition is satisfied, and the information in the
content portion configured to be displayed when the trigger event
occurs if the condition is satisfied;
storing the message in a data store at the user terminal;
reading the control portion of the message and extracting the
trigger event and the condition, the trigger event being dependent
upon at least one of a chat, a call, a video feed, a contact list
change, or an input detected through a user interface of a
communication client executing at the user terminal, the
condition being dependent upon a property within the
communication client executing at the user terminal;
1 Appellants identify “Skype” as the real party in interest. (See App. Br. 3.)
2
Appeal 2015-006031
Application 11/937,069
monitoring the communication client to detect occurrence of
the trigger event;
responsive to detecting the occurrence of the trigger event,
determining whether the condition is satisfied within the
communication client; and
responsive to determining that the condition is satisfied,
displaying the information in the content portion of the message
in the user interface of the communication client.
THE REFERENCES AND THE REJECTION
Claims 1—25 stand rejected under 35 U.S.C. § 103(a) as unpatentable
over Lichtenfeld et al. (WO 2006/086353 A2; published Aug. 17, 2006),
Kheradpir et al. (US 7,903,796 Bl; issued Mar. 8, 2011), and Papulov (US
2005/0227679 Al; published Oct. 13, 2005). (See Final Act. 3—9.)
ANALYSIS
Each of independent claims 1,14, and 15 requires “receiving a
message . . . the message comprising a content portion and a control portion
. . . the control portion comprising data defining ... a trigger event that
causes the condition to be checked.”
The Examiner finds the “data defining ... a trigger event that causes
the condition to be checked” in Lichtenfeld. (See Final Act. 3^4; Ans. 6—7.)
Specifically, in the Final Action, the Examiner found that the “data defining
a . . . trigger event” is shown in the “act of the device received the message.”
(Final Act. at 4.) Later in the Final Action, the Examiner found that
Lichtenfeld monitors to detect the occurrence of the trigger event in that the
“device monitors for events that the message is being received.” (Id. at 4.)
3
Appeal 2015-006031
Application 11/937,069
In the Answer, the Examiner further finds that:
Lichtenfeld’s metadata contains trigger event (i.e., act of execute
the metadata is the event, defined in the metadata, and executed
by the client application in the client device: for example, an
incoming SMS message is received, caused the client application
to execute the metadata, the metadata realize its being executed,
check to see if a condition being satisfied.
(Ans. 7.)
Appellants argue the cited portions of the reference would not have
taught or suggested the “message comprising a content portion and a control
portion . . . the control portion comprising data defining ... a trigger event
that causes the condition to be checked.” (See Ans. 14.) We agree.
Lichtenfeld teaches a system that includes an application installed on
a device. “[W]hen device 504 is idle and an incoming call or incoming SMS
is alerted in step 701 of process 70 in Figure 7, then the application installed
in device 109 loops through the playlist items (step 702), retrieves (step 703)
the appropriate item from device 109 memory for display and 25 displays
(step 704) resource or image.” (Lichtenfeld 10:21—25.) Thus, software on
the device watches for a trigger event in the form of an SMS being received
and then displays the content identified in the playlist.
The independent claims require (a) a message with (i) content and (ii)
data defining a trigger event and a condition, as well as (b) the occurrence of
a separate event (which can be receipt of a different message) that is the
trigger event. The Examiner’s finding that “an incoming SMS message is
received, causing] the client application to execute the metadata, the
metadata [to] realize [it is] being executed, [and] checking] to see if a
condition being satisfied” (Ans. 7), fails to identity which message includes
the “data defining ... a trigger event” and does not otherwise adequately
4
Appeal 2015-006031
Application 11/937,069
explain how that limitation is taught or suggested in the combination. The
fact that the device received a message after receiving the metadata message
does not show that the metadata message, the subsequent message, or the
combination of the two included the claimed data defining a trigger event.
As Appellants observe (see App. Br. 17), a system cannot extract a trigger
event from a message, as claimed, in order to monitor for occurrence of that
event, as claimed, before receiving that message.
Because we find the Examiner has not shown a “message comprising
a content portion and a control portion . . . the control portion comprising
data defining ... a trigger event that causes the condition to be checked,” we
do not sustain the Section 103(a) rejections of claims 1—25, all of which
include that limitation. Because this issue is dispositive, we do not reach
Appellants’ other arguments.
DECISION
The rejections of claims 1—25 are reversed.
REVERSED
5