Ex Parte Kaplinger et al

Patent Trial and Appeal Board

Dec 18, 2018

14486880 (P.T.A.B. Dec. 18, 2018)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
14/486,880
58139 7590
IBM CORP. (WSM)
c/o WINSTEAD P.C.
P.O. BOX 131851
DALLAS, TX 75313
09/15/2014
12/20/2018
FIRST NAMED INVENTOR
Todd E. Kaplinger
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.
RSW920130156US2 4232
EXAMINER
MAI, THIENT
ART UNIT PAPER NUMBER
2887
NOTIFICATION DATE DELIVERY MODE
12/20/2018 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):
patdocket@winstead.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte TODD E. KAPLINGER, GAL SHACHOR, and
GREGORY L. TRUTY
Appeal2018-001417
Application 14/486,880
Technology Center 2800
Before BEYERL YA. FRANKLIN, DONNA M. PRAISS, and
BRIAND. RANGE, Administrative Patent Judges.
RANGE, Administrative Patent Judge.
DECISION ON APPEAL
SUMMARY
Appellant1 appeals under 35 U.S.C. § 134(a) from the Examiner's
decision rejecting claims 1-8. We have jurisdiction. 35 U.S.C. § 6(b ).
We AFFIRM.
1 Appellant is the Applicant, International Business Machines Corporation,
which, according to the Appeal Brief, is also the real party in interest.
Appeal Br. 1.
Appeal 2018-001417
Application 14/486,880
STATEMENT OF THE CASE2
Appellant describes the invention as relating to "integrating a mobile
payment application with other mobile applications while prevent security
exposures." Spec. ,r,r 1, 17. In particular, the Specification explains that, in
existing systems, a mobile payment application (such as Apple Passbook®)
stores gift cards, generic cards, or other forms of mobile payment as a "pass"
or "payment token." Id. ,r 2. Passes are separate from other applications
(such as a Starbucks® mobile application) that may have generated the
card/gift card. Id. ,r 3. When the mobile application creates a gift card, a
corresponding pass has to be created in order for the mobile payment
application to be able to use the gift card. Id. Thus, "there is a period of
time in which the mobile payment application does not have access to the
gift card information." Id. Also, the gift card number of the pass, especially
when referenced outside of the mobile payment application, may be
represented by a bar code or Quick Response code that is not entirely
encrypted, and this is a security risk. Id. ,r 5.
The Specification describes a system that improves upon past
technology by "integrating a mobile payment application with other mobile
applications." Spec. ,r 7. The improvement involves first receiving an
indication that a pass was created by the mobile payment application. Id.
The method then involves "generating, by a processor, a view of a set of
application programming interfaces exposed to leverage the created pass."
Id. Once the view of "application program interfaces" is displayed, the
2 In this Decision, we refer to the Final Office Action dated March 7, 201 7
("Final Act."), the Appeal Brief filed June 5, 2017 ("Appeal Br."), the
Examiner's Answer dated October 2, 2017 ("Ans."), and the Reply Brief
filed November 27, 2017 ("Reply Br.").
2
Appeal 2018-001417
Application 14/486,880
method involves "receiving a selection of one or more of the set of
application programming interfaces to interact with the created pass." Id.
For example, a user may create a new Apple Passbook® mobile
payment application pass. In response to receiving an indication that this
pass was created, "a set of application programming interfaces of the mobile
applications that may possibly be utilized by a pass .... is generated." Id. ,r
1 7. The user may select from among the generated application
programming interfaces the Starbucks® application. Selecting the
Starbucks® application interface programs the Starbucks® application as
being affiliated with the Apple Passbook® mobile payment application's
pass. In this way, the "existing mobile applications are seamlessly
integrated with the features of the passes." Id. A virtual container is also
created at this point "for the created pass and the selected application
programming interfaces to interface with the created pass." Id. For
example, if the user "selects a favorite store location in the Starbucks®
application, such information will automatically be accessible by the
pass .... " Id. ,r 43.
Claim 1, reproduced below with emphasis added to certain key
recitations, is illustrative of the claimed subject matter and reflects much of
the process described above:
1. A method for integrating a mobile payment application
with other mobile applications while preventing security
exposures, the method comprising:
receiving an indication that a pass was created by said
mobile payment application, wherein said pass corresponds to a
form of mobile payment;
generating a view of a set of application programming
interfaces exposed to leverage said created pass;
3
Appeal 2018-001417
Application 14/486,880
rece1vmg a selection of one or more of said set of
application programming interfaces to interact with said created
pass thereby allowing one or more existing mobile applications
to seamlessly be integrated with features of said created pass; and
creating, by a processor, a virtual container for said created
pass and said one or more of said set of application programming
interfaces selected to interact with said created pass in order to
control data to be exposed to an application layer.
Appeal Br. 67 (Claims App.) ( emphasis added).
We note that Appeal 2018-0001460 involves a related patent
application (Patent Application Number 14/154,376) and has claims similar
to those at issue in this appeal.
REFERENCES
The Examiner relies upon the prior art below in rejecting the claims
on appeal:
Ortiz et al.
("Ortiz")
Sartor
US 2015/0235212 Al
US 2015/0302374 Al
REJECTIONS
Aug. 20, 2015
Oct. 22, 2015
The Examiner maintains the following rejections on appeal:
Rejection 1. Claims 1-8 under 35 U.S.C. § 101 because the claimed
invention is directed to a judicial exception without significantly more.
Final Act. 2.
Rejection 2. Provisionally, claims 1-8 on the ground of nonstatutory
obviousness-type double patenting as being unpatentable over claims 9-16
of co-pending Application No. 14/154,376. Id. at 5.
Rejection 3. Claims 1, 7, and 8 under 35 U.S.C. § 102 as anticipated
by Sartor. Id. at 6.
4
Appeal 2018-001417
Application 14/486,880
Rejection 4. Claims 2-6 under 35 U.S.C. § 103 as unpatentable over
Sartor in view of Ortiz. Id. at 7.
ANALYSIS
Claim construction. The Examiner's rejections under 35 U.S.C.
§ § 101, 102, and 103 depend, at least in part, on claim construction. Claim 1
recites "generating a view of a set of application programming interfaces
exposed to leverage said created pass." Appeal Br. 67 (Claims App.). The
Examiner does not provide an interpretation of this recitation, but, instead,
states, "[i]t is respectfully submitted that the current claim does not define
what the ... application programming interfaces are. The interpretation of
the claim limitations [are] a broad interpretation in the same field of
endeavor." Ans. 9.
Given the context of Appellant's method, as the Specification
describes and as we summarize above, claim 1 's recitation of "application
programming interfaces" does not refer merely to interfaces that allow
selection of options within one application. Rather, the "application
programming interfaces" are interfaces that allow a user to program what
application should be associated with (i.e., be able to leverage, be leveraged
by, and/or interact with) a particular pass. See, e.g., Spec. ,r 42. Claim 1
supports this construction because the recited "application programming
interfaces to interact with said created pass" are the selection that is
received. This selection ultimately allows claim 1 's pass features and
existing mobile applications "to seamlessly be integrated."
We address the Examiner's rejections in view of this claim
construction.
5
Appeal 2018-001417
Application 14/486,880
Rejection 1, Section 101. The Examiner rejects claims 1-8 under 35
U.S.C. § 101 because the claimed invention is directed to a judicial
exception without significantly more. Final Act. 2. In particular, the
Examiner focuses, for example, on the claims' process "including gathering,
storing, organizing data, and transmit[ing] data relating to commercial
practices." Final Act. 2. The Examiner also emphasizes that the concept of
a virtual container for storing a payment pass and interface is similar to the
concept of an actual (i.e., a physical) wallet for storing payment cards and
coupons. Id. at 2-3. The Examiner thus compares claim 1 to, for example,
the claims that our reviewing court held were directed to an unpatentable
abstract idea in Elec. Power Grp., LLC, Alstom S.A., 830 F.3d 1350 (Fed.
Cir. 2016). Ans. 5. Appellant argues that the claims are not directed to
unpatentable subject matter because the claimed invention improves "an
existing technological process, namely, seamlessly integrating the features
of passes with other mobile applications while preventing security
exposures." Appeal Br. 5. Appellant emphasizes, for example, our
reviewing court's analysis in Enfzsh, LLC v. Microsoft Corp., 822 F.3d 1327
(Fed. Cir. 2016). Id.
On the present record, Appellant's arguments persuade us of
Examiner error. The Examiner bears the initial burden of presenting a prima
facie case ofunpatentability. In re Oetiker, 977 F.2d 1443, 1445 (Fed. Cir.
1992). To determine whether an invention claims ineligible subject matter
requires the application of the two-step test first introduced in Mayo
Collaborative Servs. v. Prometheus Labs., Inc., 132 S. Ct. 1289, 1293 (2012)
and further explained in Alice Corp. Pty. Ltd. v. CLS Bank Int 'l, 134 S. Ct.
2347, 2354 (2014). The first step requires a determination as to whether the
6
Appeal 2018-001417
Application 14/486,880
claims at issue are directed to a patent-ineligible concept such as an abstract
idea. See Alice Corp. Pty. Ltd., 134 S. Ct. at 2355. The second step requires
examination of "the elements of the claim to determine whether it contains
an 'inventive concept' sufficient to 'transform' the claimed abstract idea into
a patent-eligible application." Id. at 2357 (quoting Mayo 132 S. Ct. at 1294,
1298).
For the first step, the Examiner indicates the claims are directed to
receiving, generating a view, receiving a selection, creating a
virtual container for the created pass and interface( s) are
directed a scheme in which a created payment pass and a
selectable programming interface to leverage the pass are
collected and a virtual container is generated for a created
payment pass and selectable interface that can leverage the
created virtual pass.
Final Act. 2. The Examiner, however, does not expressly find that this
combination of steps is merely an abstract idea. Rather, the Examiner
focuses on the "virtual container" and states that the concept is "similar to
the commercial practices found to be abstract by the courts." Id. at 3.
The Examiner's characterization of the claimed invention errs by
failing to adequately consider, for example, claim 1 's recitations requiring
"generating a view of a set of application programming interfaces exposed to
leverage said created pass," "receiving a selection of one or more of said set
of application programming interfaces," and "thereby allowing one or more
existing mobile applications to seamlessly be integrated with features of said
created pass." Appeal Br. 15. The Examiner has not adequately explained
why the recited process allowing two previously independent applications
"to seamlessly be integrated" is an abstract idea rather than a specific
asserted improvement in computer capabilities. See Enfzsh, LLC, 822 F.3d
7
Appeal 2018-001417
Application 14/486,880
at 1335 ("Software can make non-abstract improvements to computer
technology just as hardware improvements can, and sometimes the
improvements can be accomplished through either route."); DDR Holdings,
LLC v. Hotels.com, L.P., 773 F.3d 1245, 1257 (Fed. Cir. 2014) (holding
claims patent eligible where they were "necessarily rooted in computer
technology in order to overcome a problem specifically arising in the realm
of computer networks"); Alice Corp. Pty. Ltd., 134 S. Ct. at 2355, n.3 (2014)
("patent claims must be considered as a whole") (internal quotation marks
and citation omitted). Therefore, we do not sustain the Examiner's rejection
of claims 1-8 under 35 U.S.C. § 101.
Rejection 2, double patenting. The Examiner provisionally rejects
claims 1-8 on the ground of nonstatutory obviousness-type double patenting
as being unpatentable over claims 9-16 of co-pending Application No.
14/154,376. Final Act. 5. We summarily sustain this provisional rejection
because Appellant does not dispute it.
Rejection 3, anticipation. The Examiner rejects claims 1, 7, and 8
under 35 U.S.C. § 102 as anticipated by Sartor. Final Act. 6. The Examiner
finds that Sartor teaches each recitation of claim 1. Id. at 6-7. Most
relevant here, the Examiner addresses claim 1 's recitation "generating a
view of a set of application programming interfaces exposed to leverage said
created pass" by citing Sartor at "Fig. 9A, lOA, 1 lA: Flashpay, Internet,
Advertisement; paragraphs 230-231: celling limits, frequency, balance
threshold." Id. at 6. The Examiner elaborates on this position in the Answer
by stating:
It is respectfully submitted that the current claim does not
define what the virtual container and application programming
interfaces are. The interpretation of the claim limitations a
8
Appeal 2018-001417
Application 14/486,880
broad interpretation in the same field of endeavor. . . . In this
case, Fig. 1 OA shows application programming interfaces
including "Flash Pay" and "Internet" being generated for the
user to select. The "Flash Pay" programming interface makes
"the purchase transaction application work according to a
lighter" procedure ( as compared to the "standard" one described
above), that is, the purchase transaction application foregoes the
verification phase with the transaction network 4 ( although a
"light" verification phase is performed, as described below) and
is ready to perform the payment phase[] (paragraph 266). The
"Internet" programming interface is utilized "when the user 10
is performing a purchase transaction at a Virtual Point-of-Sale
(VPOS) (i.e., virtual check-out web-page), that is, the user 10 is
performing a purchase transaction from an on-line store using
the smartphone 2 ( or, alternatively, a tablet, a tablet PC and
even a personal computer) (paragraph 278).
Ans. 9.
Appellant argues that Sartor does not disclose "generating a view of a
set of application programming interfaces exposed to leverage said created
pass" as recited in claim 1. Appeal Br. 42--44; Reply Br. 26-27. We agree
with Appellant that, on this record, the Examiner has not adequately
explained how Sartor teaches this recitation. The portions of Sartor that the
Examiner relies on are interface components of Sartor's purchase transaction
application. See, e.g., Sartor ,r,r 266 (referring to a user enabling "Flash Pay"
as they log in to the purchase transaction application), 278 (referring to
"[t]he Internet feature of the purchase transaction application"), 321
( referring to direct advertising being generated by the purchase transaction
application). The Examiner does not adequately explain where Sartor
teaches displaying applications as interfaces that allow a user to program
what applications should be associated with, for example, Sartor' s purchase
transaction application.
9
Appeal 2018-001417
Application 14/486,880
We thus do not sustain the Examiner's rejection of claim 1. We also
do not sustain the Examiner's rejection of claims 7 and 8 because each of
those claims depend from claim 1.
Rejection 4, obviousness. The Examiner rejects claims 2-6 under 35
U.S.C. § 103 as unpatentable over Sartor in view of Ortiz. Final Act. 7.
Each of claims 2-6 directly or indirectly depends from claim 1, and the
Examiner's use of Ortiz does not cure the error regarding Sartor that we
address above. Id. We therefore do not sustain this rejection.
DECISION
For the above reasons, we affirm the Examiner's provisional rejection
of claims 1-8 on the ground of nonstatutory obviousness-type double
patenting. We reverse the Examiner's rejection (a) of claims 1-8 under 35
U.S.C. § 101, (b) claims 1, 7, and 8 under 35 U.S.C. § 102, and (c) claims 2-
6 under 35 U.S.C. § 103.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a).
AFFIRMED
10