Ex Parte Schofield et al

Patent Trial and Appeal Board

Jan 13, 2017

13453513 (P.T.A.B. Jan. 13, 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.
13/453,513 04/23/2012 Andrew J. Schofield GB920090003US2 8718
70748 7590
IBM Corp. (AUS/RCR)
c/o Rolnik Law Firm, P.C.
24 N. Main St.
Kingwood, TX 77339
EXAMINER
YUN, CARINA
ART UNIT PAPER NUMBER
2194
NOTIFICATION DATE DELIVERY MODE
01/18/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):
notices@rolnikiplaw.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte ANDREW J. SCHOFIELD and PHILIP B. WILLOUGHBY
Appeal 2016-0001351
Application 13/453,513
Technology Center 2100
Before JEAN R. HOMERE, JOHN A. EVANS, and
DANIEL J. GALLIGAN, Administrative Patent Judges.
Per Curiam.
DECISION ON APPEAL
STATEMENT OF THE CASE
Appellants seek our review under 35 U.S.C. § 134(a) of the
Examiner’s final rejection of claims 2, 4, and 6. App. Br. 7. We have
jurisdiction under 35 U.S.C. § 6(b). Claims 1, 3, and 5 have been canceled.
Claims Appx.
We affirm.
1 Appellants identify the real party in interest as International Business
Machines Corporation. App. Br. 2.
Appeal 2016-000135
Application 13/453,513
Appellants ’ Invention
Appellants’ invention is directed to a method of processing messages
in a cluster (10) of queue managers (QM1, QM2, QM3, QM4) with
instances such as (11) and (12), where messages with an affinity are
processed together in the same queue manager (QM2). See Spec. ]Hf 40-45,
Fig. 1.
Illustrative Claim
Independent claim 2 is illustrative, and reads as follows:
2. A method of processing messages, including affinity sets
of related messages, for use with a messaging and queuing
system of the type capable of supporting a cluster, the method
comprising:
in response to an application program command to a
messaging server, the messaging server opening a queue having
multiple instances of the queue on respective messaging servers
of the cluster, wherein the messaging server is among a plurality
of logically associated messaging servers for controlling and
hosting queues of messages, wherein the messaging server and
respective messaging servers are logically associated, and in
response, generating an object handle;
in response to application program commands to the
messaging server to put a plurality of messages on the queue,
distributing messages among the multiple instances of the queue
so as to balance a workload between at least two messaging
servers according to predetermined rules, wherein the at least two
messaging servers are among the plurality of logically associated
messaging servers wherein distributing messages among the
multiple instances of the queue on the respective messaging
servers of the cluster is specified by an option in an application
program command which causes selection of a queue instance to
be deferred until a command to
2
Appeal 2016-000135
Application 13/453,513
put messages on the queue is received, wherein distributing
messages further comprises:
using the object handle as the access information for
selecting the particular queue instance for a first message of a
plurality of messages;
in response to selecting the particular queue instance for
the first message, deriving access information from a message
attribute of the first message and the first message is a first
message of an affinity set;
obtaining and storing access information for a particular
queue instance to which the first message is put; and
in response to an application program command to the
messaging server to put a first further message to the queue,
wherein the first further message is part of the affinity set,
sending the first further message to the particular queue instance
using the access information.
Prior Art Relied Upon
Hickson et al. US 6,226,641 B1 May 1, 2001
(“Hickson”)
Piper et al. US 2008/0019351 Al Jan. 24, 2008
(“Piper”)
IBM, Queue Manager Clusters, MQ Series, Nov. 2000.
(“QMC”)
Rejections on Appeal
Appellants request review of the following Examiner’s rejections
Claims 2 and 4 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Piper and QMC. Ans. 3—5.
3
Appeal 2016-000135
Application 13/453,513
Claim 6 stands rejected under 35 U.S.C. § 103(a) as unpatentable over
Piper, QMC, and Hickson. Ans. 5—6.
ANALYSIS
We consider Appellants’ arguments seriatim, as they are presented in
the Appeal Brief, pages 8—13, and the Reply Brief, pages 1—5.2
Appellants first argue that QMC does not teach “access information,”
as recited in independent claim 2. App. Br. 8—9; Reply Br. 1—2. In
particular, Appellants argue the user ID in QMC is neither access
information nor a message attribute of the first message. App. Br. 9; Reply
Br. 2. This argument is not persuasive.
The Examiner finds QMC teaches authorization for putting messages
on queues. Ans. 6 (citing QMC 67). The Examiner explains the PUT
authority (PUTAUT) attribute in QMC specifies the authority to put a
message to a queue. Id. According to the Examiner, QMC teaches that the
options for PUTAUT attributes, DEF or CTX, are user IDs to permit putting
a message to a queue. Id. QMC teaches that the user ID of the receiving
queue manager is placed in the ReplyToQMgr field of the message
descriptor of the first message in a batch of messages in the message
2 Rather than reiterate the arguments of Appellants and the Examiner, we
refer to the Appeal Brief (filed June 8, 2015) (“App. Br.”), the Reply Brief
(filed September 24, 2015) (“Reply Br.”), the Answer (mailed August 20,
2015) (“Ans.”), and the Final Office Action (mailed March 23, 2015) (“Final
Act.”) for the respective details. We have considered in this Decision only
those arguments Appellants actually raised in the Briefs. Any other
arguments Appellants could have made but chose not to make in the Briefs
are deemed to be waived. See 37 C.F.R. § 41.37(c)(l)(iv) (2012).
4
Appeal 2016-000135
Application 13/453,513
affinity. QMC 47. When the sending queue manager in QMC obtains this
user ID in a reply from the receiving queue manager, the sending queue
manager places the user ID in all subsequent messages in the batch to be
directed to the same queue when received by the receiving queue manager.
QMC 48. This is an example of the CTX PUTAUT attribute derived from
the message channel agent user (MCAUSER), the program controlling the
receiving queue manager. See QMC 67, 131. We agree with the Examiner
that the name of the receiving queue manager as its user ID, placed in the
first message of the message affinity batch, constitutes access information
directing messages in the batch to the same queue. See Ans. 6; see Final
Act. 5.
Second, Appellants contend QMC does not teach “in response to
selecting the particular queue instance for the first message, deriving access
information from a message attribute of the first message and the first
message is a first message of an affinity set,” as recited in independent claim
2. App. Br. 9. In particular, Appellants argue QMC teaches stopping
unauthorized queue managers from sending messages to a queue manager.
App. Br. 9 (citing QMC 67). Appellants further assert QMC does not teach
a cause and effect relationship between the selecting and deriving steps in
the disputed limitation. App. Br. 10. These arguments are not persuasive.
The Examiner correctly finds QMC teaches selecting the destination
queue manager and deriving the access information. Ans. 6—7; Final Act. 5
(citing 49, 67). As discussed above, QMC teaches that when the destination
queue manager is selected and receives the first message of an affinity batch,
it places its name as the user ID in the ReplyToQMgr field of the first
5
Appeal 2016-000135
Application 13/453,513
message and responds to the sending queue manager with the first message.
See QMC 47.
[T]he queue manager that receives the first message in a batch
[returns] its name in its response. It does this using the ReplyToQMgr
field of the message descriptor. The queue manager at the sending
end can then extract this queue manager name and specify it on all
subsequent messages.
QMC 47-48. The Examiner explains, and we agree that the destination
queue manager’s name provides access to messages to the queue. Ans. 6—7.
QMC teaches that the destination queue manager’s name is extracted from
the first message in the batch in the destination queue manager’s response.
QMC 48. Therefore, we find no error in the Examiner’s finding that QMC
teaches that the selection of destination queue manager causes the derivation
of the access information from the first message in the response from the
destination queue manager to route the remaining messages in the affinity
set to the same destination queue manager. Ans. 6—7; QMC 47-48.
Third, Appellants argue that Piper does not teach “in response to an
application program command to the messaging server to put a first further
message to the queue, wherein the first further message is part of the affinity
set, sending the first further message to the particular queue instance using
the access information,” as recited in independent claim 2. App. Br. 10. In
particular, Appellants contend Piper teaches a domino failover technique
with no teaching of an application program command or putting of a first
further message to the queue. App. Br. 11 (citing Piper | 59). According to
Appellants, Piper does not teach a causal relationship between the MQPUT
6
Appeal 2016-000135
Application 13/453,513
call and recited sending step in the disputed limitation. App. Br. 11; Reply
Br. 4. These arguments are not persuasive.
The Examiner finds Piper teaches an MQPUT call as an application
program command to put messages on a cluster queue based on group IDs as
access information. Ans. 7. In particular, the Examiner finds Piper teaches
an application using an MQPUT call as a command to put a message on a
cluster queue. Ans. 7 (citing Piper 149). The Examiner further finds Piper
teaches a GroupID as access information to identify in which queue a
message is put. Ans. 7 (citing Piper || 51—53). We agree with the Examiner
that the GroupID allows the distributing queue manager to send all messages
of an affinity group to the same queue manager. See Piper || 51—56. A
message in an affinity group identified by the GroupID in Piper teaches the
recited first further message part of the affinity set. See id. We further agree
with the Examiner that in response to an MQPUT call to put a message on
the cluster queue Piper teaches sending a message in the affinity group as a
first further message to a particular queue in the cluster using the access
information. Final Act. 4 (citing Piper || 49, 51, 72); see Piper 172
(“[MJembers of a group with an identifier of ‘HAMPSHIRE’ . . . are sent to
QM2.”).
Fourth, Appellants assert QMC does not teach “the messaging server
opening a queue having multiple instances of the queue on respective
messaging servers of the cluster,” as recited in independent claim 2. App.
Br. 11. Appellants argue QMC teaches a user manually specifies the queue
manager name with the MQOPEN call. App. Br. 12 (citing QMC 47, 49).
This argument is not persuasive.
7
Appeal 2016-000135
Application 13/453,513
The Examiner correctly finds QMC teaches a queue-manager alias as a
messaging server to open a queue with multiple instances, one to a queue
manager specified in the MQOPEN call and another to another queue
manager. Ans. 7 (citing QMC 33). We disagree with Appellants because
QMC teaches that the queue-manager alias as a messaging server, not solely
the user, opens a queue with multiple instances in remapping the queue-
manager name. Id. It follows Appellants have not shown error in the
Examiner’s rejection of independent claim 2.
Regarding the rejection of claims 4 and 6, because Appellants have
either not presented separate patentability arguments or have reiterated
substantially the same arguments as those previously discussed for
patentability of claim 2 above (App. Br. 13; Reply Br. 5), claims 4 and 6 fall
therewith. See 37 C.F.R. § 41.37(c)(l)(iv) (2013).
DECISION
We affirm the Examiner’s rejections of claims 2, 4, and 6.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(l)(iv).
AFFIRMED
8