Ex Parte Ewe

Patent Trials and Appeals Board

May 24, 2019

13925166 - (D) (P.T.A.B. May. 24, 2019)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR
13/925, 166 06/24/2013 Thomas Ewe
27189 7590 05/29/2019
PROCOPIO, CORY, HARGREAVES & SAVITCH LLP
525 B STREET
SUITE 2200
SAN DIEGO, CA 92101
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
ATTORNEY DOCKET NO. CONFIRMATION NO.
116099-001 CT3 5062
EXAMINER
MIRZA, ADNAN M
ART UNIT PAPER NUMBER
2443
NOTIFICATION DATE DELIVERY MODE
05/29/2019 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):
docketing@procopio.com
PTONotifications@procopio.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte THOMAS EWE
Appeal2018-004312
Application 13/925,166
Technology Center 2400
Before JUSTIN BUSCH, STACEY G. WHITE, and
CARLL. SILVERMAN, Administrative Patent Judges.
BUSCH, Administrative Patent Judge.
DECISION ON APPEAL
Pursuant to 35 U.S.C. § 134(a), Appellant appeals from the
Examiner's decision to reject claims 1-30, which constitute all the claims
pending in this application. We have jurisdiction over the pending claims
under 35 U.S.C. § 6(b).
We reverse.
CLAIMED SUBJECT MATTER
Appellant's invention generally relates to "client-server
communications and is more specifically related to simplifying user
interaction with a SAP server and extending SAP functionality to mobile and
intermittently connected devices." Spec. ,-J 3. More specifically, Appellant's
claimed invention relates to receiving a communication sent from an SAP
Appeal2018-004312
Application 13/925,166
server, parsing the communication into requests, identifying which of the
requests require a response to maintain a session between a client device and
the SAP server, and sending a simulated response to the SAP server for each
request that requires such a response. Appeal Br. 20-25 (Claims App.); see
Spec. ,i,i 70-80 ( describing a process for maintaining a session between a
"GUIXT client" and an "SAP R3 server"). Claims 1, 11, and 21 are
independent claims. Claim 21 is reproduced below:
21. A method for a client mobile device, comprising:
parsing a communication from a SAP server with a
processor into one or more requests;
determining if each of the one or more requests requires a
response to maintain a session between the client mobile device
and the SAP server; and
sending a simulated response to the SAP server in
response to each of the determined ones of the one or more
requests that require the response to maintain the sess10n
between the client mobile device and the SAP server.
REJECTION
Claims 1-30 stand rejected under 35 U.S.C. § 103 as obvious in view
of Keller (US 2007/0253435 Al; Nov. 1, 2007) and Sen (US 6,845,389 Bl;
Jan. 18, 2005). Final Act. 2-5.
ANALYSIS
The Examiner initially finds (1) Keller teaches or suggests the parsing
and determining steps recited in claim 21, (2) Sen teaches or suggests the
sending step recited in claim 21, and (3) a person of ordinary skill in the art
would have combined Sen's and Keller's teachings. Final Act. 2-3 (citing
Keller ,i,i 19-21; Sen 4:46-5:2). Although independent claim 11 is a system,
claim 11 recites a processor configured to perform steps similar to the steps
recited in claim 21. Compare Appeal Br. 22 with Appeal Br. 24-25.
2
Appeal2018-004312
Application 13/925,166
Independent claim 1 recites nearly identical steps to the steps recited in
claim 21, but adds a step of receiving a communication; additionally, claim
l's preamble states the method is a "computer-implemented method for
facilitating communications between a client mobile device and a SAP
server," whereas claim 21 's preamble recites the method is "for a client
mobile device." Compare Appeal Br. 20 with Appeal Br. 24-25.
Among other arguments, Appellant argues Keller fails to teach or
suggest the determining step recited in claims 1, 11, and 21. Appeal Br. 8-9.
In particular, Appellant argues Keller's cited portions (i.e., paragraphs 19
through 21) merely disclose using Session Announcement Protocol "to
announce multicast based conferences, wherein, for instance, multimedia
files (usually audio and video streams) are sent to multiple users at the same
time." Appeal Br. 8 ( quoting Keller ,i 20) ( emphasis omitted). Appellant
asserts Keller's announcements, which are used in conjunction with a
session that was established using Session Initiation Protocol ("SIP"), do not
require responses to maintain sessions between the client and server once the
Session Announcement Protocol is established. Appellant argues that,
because Keller does not need to respond to messages to maintain an already
established session, Keller fails to disclose any mechanism for determining
whether any requests require such a response, and, therefore, Keller does not
teach or suggest the determining step recited in claim 21.
In response to Appellant's argument that Keller fails to teach the
determining step, the Examiner quotes the same portion of Sen that the
Examiner finds teaches or suggests the sending step. Ans. 3-4 ( quoting Sen
4:46-5:2).
3
Appeal2018-004312
Application 13/925,166
Appellant notes the Examiner appears to alter the rejection-i.e., the
Examiner now finds Sen (rather than Keller) teaches or suggests the
determining limitation. Reply Br. 3 ( citing Ans. 3-4). Appellant then
argues Sen also fails to teach or suggest the determining limitation. Reply
Br. 3-4. Specifically, Appellant argues Sen relates to including quality of
service (QoS) requirements in a SIP request message to reserve the
necessary resources when initiating a session. Appeal Br. 10-11; Reply
Br. 3-4. Appellant asserts "Sen is not directed to generating a response to a
request to maintain a session," and Sen does not need to maintain a session.
Appeal Br. 10-11; see Reply Br. 3-4 ( asserting Sen "has no disclosure
regarding the maintaining of a session between the client device and the
SAP server.").
Appellant's arguments persuade us the Examiner erred in determining
the combination of Keller and Sen renders independent claims 1, 11, and 21
obvious. We do not see anything in Keller or Sen that teaches or suggests
"determining if each of the one or more requests requires a response to
maintain a session between the client mobile device and the" server, as
recited in independent claims 1, 11, and 21. Keller and Sen clearly disclose
establishing sessions and at least suggest maintaining a session (sessions
must be maintained at least for some amount of time in order to provide
communication between two endpoints). Keller ,-J,-J 19-21; Sen 4:46-5:2,
7:50-65. Keller and Sen also disclose ending a session. Keller ,-J,-J 51-57;
Sen 8:46-50. However, Keller and Sen fail to teach or suggest determining
that a request from a server requires a response in order to maintain the
session, as recited in the claims.
4
Appeal2018-004312
Application 13/925,166
Keller discloses a method that "combines traditional SIP setup
mechanisms with a session announcement mechanism to provide reliable
session setup and consistent session state among all components." Keller
,i 19. Keller describes an intermediary server between two endpoints-a
session initiator and a session target. See Keller ,i,i 19-22, 44-46. Keller's
server receives an SIP INVITE request from the initiator and sends a new
SIP INVITE request to the target. Keller ,i 44. If the target receives the SIP
INVITE message, it sends an SIP OK (i.e., a response to the SIP INVITE
message) back to the server. Keller ,i 44. Upon receiving the SIP OK
message from the target, the server sends a new SIP OK message to the
initiator. Keller ,i 44. Keller's server may send an additional SIP INVITE
request if it does not receive an SIP OK from the target. Keller ,i 44.
In some embodiments, Keller includes an SIP INVITE request
timeout period and, if the server does not receive an SIP OK from the target
before the timeout period expires, Keller begins sending session
announcement protocol messages (i.e., "announcements"). Keller ,i 45. The
server periodically sends announcements to the initiator and target. Keller
,i 45. If the target never received an SIP INVITE message, it will start a
session upon receiving an announcement. Keller ,i 45. Other embodiments
may not use a timeout period but may simply begin sending announcements
to the target and initiator at some point in the process. See Keller ,i,i 45-48.
Keller also describes ending a session and the associated call cleanup when
one endpoint wishes to terminate the communication session, see Keller
,i,i 51-57, but does not describe what is necessary in order to maintain a
sess10n.
5
Appeal2018-004312
Application 13/925,166
Sen describes a "system and method of setting up a multi-user
communication session over a global computer network." Sen Abstract.
Sen discloses that session announcement protocol may be used to announce
ongoing gaming sessions to new players. Sen 4:30-40, 7:51-55. Sen
explains that session information for a gaming session may be registered
with a local Session Announcement Protocol server when a player initiates a
communication or gaming session. Sen 7:58-60. The server then
periodically multicasts announcements of the session to a known multicast
IP address and port at which new players may listen for such
announcements. Sen 7:56-67.
Sen describes a process for a new player to join an existing session.
Sen 4:30-5:2, 7:51-8:50. Sen explains that a first player who wishes to join
a multi-player gaming session may send a session participation request
message ( e.g., a SIP INVITE message) to a local game server or directly to a
second player already participating in a multi-player session. Sen 4:46-51,
8:11-16, 8:27-32. The session participation request message may include
the first player's bandwidth and QoS requirements and the first player's
computer capabilities. Sen 4:51-58, 8:16-20. Sen discloses that the
"session setup protocol can use an extended SIP and SDP [(Session
Description Protocol)] message set," and the "SIP can be extended to
support QoS for different classes of games." Sen 4: 5 8-61; see Sen 4: 61-5 :2
( describing exemplary classes and QoS requirements).
If the first player sends the participation request message to the local
server, the server multicasts the request message to all players currently
participating in the communication or gaming session. Sen 8:23-25. If a
second player (i.e., one of the current players) replies with a SIP OK
6
Appeal2018-004312
Application 13/925,166
message, which includes the second player's QoS requirements, the server
communicates with a policy server to verify resource availability and
forwards the SIP OK to the first player. Sen 8:25-27, 8:32-40. The first
player then sends an ACK (i.e., acknowledgement) message back to the
server, which multicasts the ACK message to all current players, and the
game host server adds the first player to the game. Sen 8:40-46. Sen
discloses all players then continue their gaming session "using multicast
messages without any server involvement" and the "game session may be
terminated using a SIP BYE message, which is sent via the local game
servers." Sen 8:46-50. Notably, nothing in Sen describes any protocol for
maintaining an existing session, let alone that one session participant
determines a request message requires a response in order to maintain the
session. In fact, Sen suggests that the session is maintained until a SIP BYE
message is received. Sen 8:48-50.
Accordingly, Keller teaches using a combination of SIP and session
announcement protocol to set up a session, Keller ,i,i 44-48, or terminate a
session, Keller,i,i 51-57 (describing ending a communication session). Sen
teaches using session announcement protocol to multicast gaming session
information, Sen 7:51-67, and adding bandwidth and QoS requirements to
SIP messages when requesting to join a gaming session, Sen 4:46-5:2, 8:11-
50. Neither Keller nor Sen, however, describes any steps necessary to
maintain a session or otherwise suggests evaluating any message sent from
one session endpoint ( e.g., the initiator/first player) to the other session
endpoint (e.g., the target/second player(s)) to determine whether the message
requires a response in order to maintain the existing session.
7
Appeal2018-004312
Application 13/925,166
For these reasons, we are persuaded the Examiner erred in finding
Keller, Sen, or some combination of Keller and Sen teaches or suggests the
determining step recited in independent claims 1, 11, and 21. Accordingly,
we do not sustain the Examiner's rejection of claims 1, 11, and 21 as
obvious in view of Keller and Sen. Nor do we sustain the Examiner's
rejection of claims 2-10, 12-20, and 22-30 as obvious in view of Keller and
Sen because claims 2-10, 12-20, and 22-30 ultimately depend from, and
incorporate the limitations of, claims 1, 11, and 21, respectively.
DECISION
We reverse the Examiner's decision to reject claims 1-30.
REVERSED
8