DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is a non-final office action in response to the applicant’s amendment received on 07/08/2026 (hereinafter “Amendment”).
Claims 1, 2, 8, 9, and 11-12 have been amended, claim 10 previously canceled, and claims 14-20 are newly presented. Claims 1-9 and 11-20 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. The Amendment has been entered.
Continuation
This application is a divisional application of U.S. application no. 17/364,225 filed on June 30, 2017, which is a continuation application of U.S. Application no. 16/126,957, filed September 10, 2018 ("Parent Application"). See MPEP §201.07. In accordance with MPEP §609.02 A. 2 and MPEP §2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also in accordance with MPEP §2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicant(s) desire the information to be printed on a patent issuing from this application. See MPEP §609.02 A. 2.
Claim Objection
Per claim 7, the recited “a mobile application stored on the user device” should be amended to “the mobile application on the user device” as claim 1 recites “a mobile application on a user device”.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-9 and 11-17 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Per claims 1 and 14, the claim recites in part “receive, from the mobile application on the user device of the secondary user, an itinerary associated with the digital secondary account”. While the current application show support for “itinerary” throughout the Specification, the Specification does not show support for the application server receiving from the mobile application one the user device of the secondary user, an itinerary associated with the digital secondary account.
Dependent claims 2-9, 11-13, and 15-17 are rejected as they depend on claims above.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 3 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Per claim 3, the claim is rejected as the claim subject matter fails to further limit the claim 2 which claim 3 depends as the claimed limitation(s) in claim 3 is recited in claim 2.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-9 and 11-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
MPEP 2106 provides step(s) in determining eligibility under 35 U.S.C. § 101. Specifically, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any additional elements in the claim must integrate the judicial exception into a practical application. If not, the inquiry continues to see whether any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself. Examples of abstract ideas include mathematical concepts, mental processes, and certain methods of organizing human activities.
Under Step 1, claims 1-9 and 11-13 (group I), claims 14-17 (group II), and claims 18-20 (group III) are directed to a to a processor-based system/server. Thus, the claimed inventions are directed towards one of the four statutory categories under 35 USC § 101. Nevertheless, the claims also fall within the judicial exception of an abstract idea without significantly more.
Step 2A, 1st prong:
Claim 1 recites: A system comprising:
an application server device comprising one or more processors, and a memory including instructions that, when executed by the one or more processors, cause the application server device to:
a) manage a mobile application on a user device of a secondary user;
b) receive, from a processing server computer, a digital token for a digital secondary account linked to a primary account of a primary user, wherein the digital secondary account is associated with a plurality of protocols indicating transactions that can be authorized at a particular status associated with the digital secondary account;
c) provision the digital token for the digital secondary account to be stored on the user device;
d) receive, from the mobile application on the user device of the secondary user, an itinerary associated with the digital secondary account;
e) transmit the itinerary associated with the digital secondary account to the processing server computer, wherein the itinerary indicates a plurality of statuses associated with the digital secondary account during specified periods of time;
f) receive, from the mobile application on the user device of the secondary user, the digital token for the digital secondary account;
g) provide the digital token for the digital secondary account to a recipient for conducting a transaction having a transaction amount;
h) receive, from the processing server computer, a message indicating that the digital token for the digital secondary account is invalid for a first portion of the transaction amount based on the itinerary associated with the digital secondary account, wherein the first portion exceeds a threshold associated with the digital secondary account;
i) transmit a request to adjust at least one of the plurality of protocols to a user device of the primary user, wherein the plurality of protocols is adjustable by the primary user on the application server device; and
j) complete the transaction by providing payment credentials comprised of the digital token, wherein the transaction is processed using at least a personal account of the secondary user and the primary account of the primary user pursuant to at least one adjusted protocol.
(Emphasis added on the additional element(s))
Under the broadest reasonable interpretation, the claim recites managing of transaction processing remotely, particularly completing of a payment transaction to be processed by using two accounts, i.e., personal account of a secondary user (i.e., employee) and a primary account of a primary user (employer), by providing payment credentials that is comprised of identifier of a secondary account that is linked to a primary account. The Specification describes this payment/business process in paragraphs [0046] and [0049]: “This enables a user of a primary account to create a limited secondary account for an employee (e.g., a contractor) or other dependent while controlling how that secondary account can be used … the primary user may indicate a type of project or specific protocols to be associated with the secondary user. Once the secondary account has been established, an identifier for the secondary account (e.g., a token) may be provided to the secondary user via the indicated communication channel. In some embodiments, the primary user and/or the secondary user may then provide an itinerary which may be associated with the project or the secondary user. Additionally, the primary user may select one or more protocols to be applicated to the secondary account”.
The claim achieves this by b) receiving from a processing entity a token (identifier for the secondary account, see [0049] in the specification) for secondary account linked to a primary account of a primary user, wherein the secondary account is associated with a plurality of protocols (i.e., setting or instructions that indicates an authorization rule to be applied under a set of circumstances, see [0023] Specification, in other words rules) indicating transaction that can be authorized at a particular status associated with the secondary account; c) provisioning the token for storage; d) receiving from the secondary user an itinerary (status of the secondary account during specified periods of time) associated with the secondary account; e) transmitting the itinerary associated with the secondary account to the processing entity; f) providing the token to a recipient for conducting a transaction having a transaction amount; g) receiving from the processing entity a message indicating that the token is invalid for a first portion of the transaction amount based on the itinerary (wherein the first portion exceeds a threshold associated with the secondary account)(see [0068] of Specification, e.g., an amount associated with the transaction may exceed some limit indicated in a protocol); transmitting a request to a primary user (i.e., supervisor) to adjust at least one of the plurality protocols (i.e., setting or instructions of authorization rule), and completing the transaction by providing payment credentials comprised of the token. In this way, the transaction is processed by the transaction entities using at least a personal account of the secondary user and the primary account of the primary user. The examiner submits that the processing of the transaction using at least a personal account of the secondary user and the primary account of the primary user pursuant to at least one adjusted protocol is not function(s) of the system comprising: an application server device. As such, the processing of the transaction using at least a personal account of the secondary user and the primary account of the primary user pursuant to at least one adjusted protocol does not have patentable weight in the claim.
In other word, the claim allows an employer to create a custodian payment account linked to the employer account and allows the employer to establish and adjust rules on the use of the custodian payment account that is to be used by an employee (i.e., expense related to a project). The claim further allows split transaction to occur using the primary account of the secondary user (employee) and the primary account of the primary user (employer) on a transaction that exceed amount which has been set by the employer. Instant specification also describes the claimed invention in [0068] “For example, if a transaction is requested for $75.00 which is associated with a $50.00 maximum limit, then the service provider, upon determining that the transaction is over the limit, the service provider 110 may generate a second authorization request message for $50.00 to be transmitted to the primary authorization entity server 108(A) [e.g., the primary account of the primary user] and may generate a third authorization request for the remaining balance of the transaction ($25.00) to be transmitted to the secondary authorization entity server 108(B) [e.g., personal account of the secondary user].” The instant specification also describes the use of the token that allows employer to create a secondary payment account that can be used by a temporary employee and also associate the secondary account with a particular project or protocols (rules) (see [0049]). The Specification also describes this split payment concept in paragraph [0095] “Completing the transaction using the primary account and a second primary account may further involve generating a first authorization request message for a first portion of the transaction to be routed to a first authorization entity associated with the primary account, and generating a second authorization request message for a remaining portion of the transaction to be routed to a second authorization entity associated with the second primary account. In these embodiments, the second primary account may be a primary account belonging to a secondary user, which is a user of the client device associated with the secondary account”.
Accordingly, the claim recites a certain method of organizing human activity, i.e., fundamental economic principles or practices, commercial activities, and/or managing personal behavior or relationships or interactions between people using rules, resulting in recitation of abstract idea.
Claim 14 is significantly similar to claim 1, representing scope that is broader than claim 1 in removal of the recitation of “wherein the first portion exceeds a threshold associated with the digital secondary account” and “wherein the transaction is processed using at least a personal account of the secondary user”. As such, claim 14 also recites abstract idea.
Claim 18 is significantly similar to claim 1, representing scope that is broader than claim 1 in removal of functions related to itinerary, i.e., receiving and transmitting of the itinerary, and “wherein the transaction is processed using at least a personal account of the secondary user”. As such, claim 18 also recites abstract idea.
Under the Step 2A (prong 2), this judicial exception is not integrated into a practical application. Specifically, the additional elements in the claim(s), i.e., a system comprising an application server device comprising one or more processors, and a memory including instructions, an application server comprising one or more processors, a memory including instructions, a remote application server comprising one or more processors, mobile application, device(s), processing server computer, and digital, amount to no more than mere instructions to implement the abstract idea and/or merely uses a computer as a tool to perform an abstract idea – see MPEP 2106.05(f). There is no indication that the claim improves upon the recited system/server or its component(s) individually or in combination individually or in combination.
The examiner further submits that the additional elements of the application server managing application (i.e., mobile application) on a user device in performing processing on behalf of the application, i.e., receive, transmit/provide, etc., are mere client/server. This additional element amounts to no more than mere instructions to implement the abstract idea and/or merely uses a computer as a tool to perform the abstract idea. There is no indication that the claim improves upon the client/server.
Under Step 2B, examiners should evaluate additional elements individually and in combination to determine whether they provide an inventive concept (i.e. whether the additional elements amount to significantly more than the exception itself). Here, the claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Specifically, the claim(s) as a whole, taken individually and in combination, do not provide an inventive concept. As explained above with respect to the integration of the abstract idea into a practical application, the additional elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea and/or merely uses a computer as a tool to perform an abstract idea. Mere instructions to implement the abstract idea on a computer, or merely using the computer as a tool to perform an abstract idea to apply the exception using a generic computer component cannot provide an inventive concept. Looking at the limitations as a combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of the elements improves the functioning of the recited computer component(s).
Dependent claims 2, 3, and 15 further expands on the abstract idea of associating of accounts to project(s) without further additional element(s).
Dependent claim 4-6 further expands on the abstract idea in description of accounts and the rule without recitation of further additional element(s).
Dependent claim 7’s additional element in recitation that the recipient is an electronic device amounts to no more than mere instructions to implement the abstract idea and/or merely uses a computer as a tool to perform an abstract idea – see MPEP 2106.05(f). The claim does not include inventive concept.
Dependent claims 8 and 16 expand on the abstract idea as described above without recitation of further additional element.
Dependent claims 9, 11, 17, 19, and 20 further expand on the abstract idea as described above. The additional elements of user interface(s)/GUI in the claims are recited at a high-level generality and under BRI representing no more than computer or instructions to implement the abstract idea or use of the computer to perform the abstract. There is no indication that the claim improves upon the computer system. These additional elements individually and in combination does not provide inventive concept.
Dependent claims 12 and 13 further expand on the abstract idea above without recitation of further additional element.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20180025353 A1 (“Collinge”) in view of US 20130018792 A1 (“Casey”).
Per claim 18, Collinge discloses a remote application server (application server/management server) comprising: one or more processors; and a memory including instructions that, when executed by the one or more processors, cause the one or more processors to ([0066]-[0068]):
manage a mobile application on a user device of a secondary user ([0017], cloud-based payment system; [0023]-[0024], payment application installed on mobile device managed by the mobile application server; [0027]);
receive, from a processing server computer, a digital token for a digital secondary account linked to a primary account of a primary user, wherein the digital secondary account is associated with a plurality of protocols indicating transactions that can be authorized at a status associated with the digital secondary account ([0025], the user may store tokenized payment account information of one or more payment cards, the payment cards are necessarily associated with an account that is associated with a plurality of protocols indicating transactions that can be authorized at a status associated with the digital account, i.e., stolen, active, non-active, etc.);
provision the digital token for the digital secondary account to be stored on the user device ([0025], the user may store tokenized payment account information of one or more payment cards, the payment cards are necessarily associated with an account that is associated with a plurality of protocols indicating transactions that can be authorized at a status associated with the digital account, i.e., stolen, active, non-active, etc.);
receive, from the mobile application on the user device of the secondary user, the digital token for the digital secondary account ([0029]; [0030], payment data includes tokenized payment information);
provide the digital token for the digital secondary account to a recipient for conducting a transaction having a transaction amount ([0025], the user may store tokenized payment account information of one or more payment cards, the payment cards are necessarily associated with an account that is associated with a plurality of protocols indicating transactions that can be authorized at a status associated with the digital account, i.e., stolen, active, non-active, etc.);
complete the transaction by providing payment credentials comprised of the digital token ([0029]; [0030]).
Collinge does not particularly teach receive, from the processing server computer, a message indicating that the digital token for the digital secondary account is invalid for a first portion of the transaction amount based on the status associated with the digital secondary account at a time of the transaction, wherein the first portion exceeds a threshold associated with the digital secondary account as indicated by the status of the digital secondary account and transmit a request to adjust at least one of the plurality of protocols to a user device of the primary user, wherein the plurality of protocols is adjustable by the primary user on the application server device, wherein the transaction is processed using at least the primary account of the primary user pursuant to at least one adjusted protocol.
Casey teaches receive, from the processing server computer, a message indicating that the digital token for the digital secondary account is invalid for a first portion of the transaction amount based on the status associated with the digital secondary account at a time of the transaction, wherein the first portion exceeds a threshold associated with the digital secondary account as indicated by the status of the digital secondary account and transmit a request to adjust at least one of the plurality of protocols to a user device of the primary user, wherein the plurality of protocols is adjustable by the primary user on the application server device wherein the transaction is processed using at least the primary account of the primary user pursuant to at least one adjusted protocol ([0007], lined to or associated with a primary account held by the parent; [0011], requesting authorization from the primary account holder before the subsidiary transaction is approved; [0012]; [0066]; [0074]; [0090]; [0092]).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to combine Casey to Collinge for the purpose of establishing financial transaction rules to control one or more subsidiary financial accounts (see [0007]).
The applicant is reminded that the claimed expression of “wherein the transaction is processed …” does not move to distinguish over prior art as the claim is directed to remote application server and its functions.
As per claim 19, Collinge/Casey further teaches one of more processors to: retrieve a spending limit associated with the digital secondary account; provide the spending limit associated with the digital secondary account to the secondary user; transmit, to the mobile application, a user interface for requesting a spending limit increase from the primary user, wherein the mobile application displays user interface on the user device; and transmit a message to the user device of the primary user requesting the spending limit increase (see Casey: Fig. 7A; Fig. 10; Fig. 11A; Fig. 12).
As per claim 20, Collinge/Casey further teaches one or more processors, cause the one or more processors to: transmit, to the mobile application, a first graphical user interface indicating that the first portion of the transaction amount is to be processed using the personal account of the secondary user, wherein the first graphical user interface is displayed on the user device; transmit, to the mobile application, a second graphical user interface for generating a request to adjust at least one of the plurality of protocols, wherein the second graphical user interface is displayed on the user device; and receive, from the mobile application via the second graphical user interface, a request with a numeric value for an increase to the threshold associated with the digital secondary account and a text input providing context for the request (see Casey: Fig. 7A; Fig. 10; Fig. 11A; Fig. 12).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-9 and 11-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-6, 8, and 10-12 of U.S. Patent No. US 12112334 B2 in view of “Karpenko”.
Per claim 1:
Instant Claim
US 12112334 B2
1. A system comprising:
Claim 1: A method comprising:
an application server device comprising one or more processors, and a memory including instructions that, when executed by the one or more processors, cause the application server device to:
receive, from a processing server computer, a digital token for a digital secondary account linked to a primary account of a primary user, wherein the digital secondary account is associated with a plurality of protocols indicating transactions that can be authorized at a particular status associated with the digital secondary account;
receiving, at a transaction application stored on a user device of a secondary user from a server computer, a digital token for a digital secondary account linked to a primary account of a primary user, wherein the digital secondary account is associated with a number of protocols indicating transactions that can be authorized at a particular status associated with the digital secondary account, wherein the transaction application is managed by a remote application server;
provision, at the transaction application, the digital token for the digital secondary account to be stored on the user device;
provisioning, at the transaction application, the digital token for the digital secondary account to be stored on the user device;
transmit the itinerary associated with the digital secondary account via the application server device to the processing server computer via the application server device, wherein the itinerary indicates a plurality of statuses associated with the digital secondary account during specified periods of time;
transmitting, by the transaction application, an itinerary associated with the digital secondary account to the server computer, wherein the itinerary indicates a plurality of statuses associated with the digital secondary account during specified periods of time;
receive, from the mobile application on the user device of the secondary user, the digital token for the digital secondary account;
by providing payment credentials comprised of the digital token
provide the digital token for the digital secondary account to a recipient for conducting a transaction having a transaction amount;
providing, by the transaction application, the digital token for the digital secondary account to a recipient for conducting a transaction having a transaction amount;
receive, from the processing server computer, a message indicating that the digital token for the digital secondary account is invalid for a first portion of the transaction amount based on the itinerary associated with the digital secondary account, wherein the first portion exceeds a threshold associated with the digital secondary account; and
receiving, by the transaction application from the server computer, a message indicating that the digital token for the digital secondary account is invalid for a first portion of the transaction amount based on the itinerary associated with the digital secondary account, wherein the first portion exceeds a threshold associated with the digital secondary account;
transmit a request to adjust at least one of the plurality of protocols to a user device of the primary user, wherein the plurality of protocols is adjustable by the primary user on the application server device; and
transmitting, by the transaction application via the remote application server managing the transaction application, the request to adjust the at least one of the number of protocols to a user device of the primary user, wherein the number of protocols is adjustable by the primary user on the remote application server;
complete the transaction by providing payment credentials comprised of the digital token, wherein the transaction is processed using at least a personal account of the secondary user and the primary account of the primary user pursuant to at least one adjusted protocol.
completing, by the transaction application, the transaction by providing payment credentials comprised of the digital token, wherein the transaction is processed using multiple accounts associated with multiple people including the personal account of the secondary user and the primary account of the primary user.
‘334 does not teach an application server device comprising one or more processors, and a memory including instructions that, when executed by the one or more processors, cause the application server device to manage a mobile application on a user device of a secondary user, wherein the application server device performs processing on behalf of the mobile application. However, Collinge discloses an application server device comprising one or more processors, and a memory including instructions that, when executed by the one or more processors, cause the application server device to manage a mobile application on a user device of a secondary user, wherein the application server device performs processing on behalf of the mobile application (see [0023]-[0024], mobile application servers … a cloud-based payment system; [0027]). It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to include the server device as described in Collinge to ‘334 as the combination provides cloud-based application that may offload processing to the server-side.
‘334/Collinge does not particularly teach receive, from the mobile application on the user device of the secondary user, an itinerary associated with the digital secondary account. However, as the claim is directed to the function(s) of the application server device and as Collinge teaches cloud based payment system including mobile application and the mobile application server, the mobile application server is capable of receiving from the mobile application on the user device of the user any known information and therefore is sufficient in terms of art.
Instant Claim
US 12112334 B2/Collinge
2. The system of claim 1, wherein the instructions, when executed by the one or more processors, cause the application server device to:
transmit a plurality of accounts associated with the secondary user to the mobile application to be displayed on the user device, the plurality of accounts including the digital secondary account, wherein the digital secondary account is associated with a first project, wherein at least one of the plurality of accounts is associated with a second project;
displaying, by the transaction application, a plurality of accounts associated with the secondary user, the plurality of accounts including the digital secondary account (claim 2), wherein the digital secondary account is associated with a first project, wherein at least one of the plurality of accounts is associated with a second project (claim 3)
receive, from the mobile application, a selection of the digital secondary account;
receiving, by the transaction application, a user input selecting the digital secondary account (claim 2); and
transmit the digital token to the recipient after receiving the selection of the digital secondary account
providing, by the transaction application, the digital token for the digital secondary account to the recipient after receiving the selection of the digital secondary account (claim 2).
3. The system of claim 2, wherein the digital secondary account is associated with a first project, wherein at least one of the plurality of accounts is associated with a second project.
3. The method of claim 2, wherein the digital secondary account is associated with a first project, wherein at least one of the plurality of accounts is associated with a second project.
4. The system of claim 2, wherein the at least one of the plurality of accounts is associated with the primary account of the primary user.
4. The method of claim 3, wherein the at least one of the plurality of accounts is associated with the primary account of the primary user.
5. The system of claim 2, wherein the at least one of the plurality of accounts is associated with a primary account of a different primary user.
5. The method of claim 3, wherein the at least one of the plurality of accounts is associated with a primary account of a different primary user.
6. The system of claim 1, wherein the digital secondary account is invalid outside the specified periods of time as indicated in the itinerary.
6. The method of claim 1, wherein the primary account is valid and the digital secondary account is invalid outside the specified periods of time as indicated in the itinerary.
7. The system of claim 1, wherein the recipient is one of a mobile application stored on the user device, or an electronic device.
8. The method of claim 1, wherein the recipient is a mobile application stored on the user device. 9. The method of claim 1, wherein the recipient is an electronic device.
8. The system of claim 1, wherein the instructions, when executed by the one or more processors, cause the application server device to: receive, from the mobile application, a request to display attributes associated with a project assigned to the digital secondary account, wherein the attributes include limits associated with the digital secondary account, policies associated with the digital secondary account, a balance of the digital secondary account; and transmit the attributes associated with the project assigned to the digital secondary account to the mobile application for displaying on the user device.
10. The method of claim 1, further comprising: receiving, by the transaction application, a user input to display one or more attributes associated with a project assigned to the digital secondary account. 11. The method of claim 10, wherein the one or more attributes include one or more of limits associated with the digital secondary account, policies associated with the digital secondary account, a balance of the digital secondary account.
9. The system of claim 1, wherein the instructions, when executed by the one or more processors, cause the application server device to:
12. The method of claim 1, further comprising:
retrieve a spending limit associated with the digital secondary account;
displaying, by the transaction application, a user interface for requesting a spending limit increase from the primary user; and
provide the spending limit associated with the digital secondary account to the secondary user;
displaying, by the transaction application, a user interface for requesting a spending limit increase from the primary user; and
transmit, to the mobile application, a user interface for requesting a spending limit increase from the primary user, wherein the mobile application displays the user interface on the user device; and
displaying, by the transaction application, a user interface for requesting a spending limit increase from the primary user; and
transmit a message to the user device of the primary user requesting the spending limit increase.
transmitting, by the transaction application, a message to the user device of the primary user requesting the spending limit increase.
11. The system of claim 10, wherein the instructions, when executed by the one or more processors, cause the application server device to:
Claim 1:
transmit, to the mobile application, a first graphical user interface indicating that the first portion of the transaction amount is to be processed using the personal account of the secondary user, wherein the first graphical user interface is displayed on the user device;
displaying, by the transaction application, a first graphical user interface indicating that the first portion of the transaction amount is to be processed using a personal account of the secondary user
transmit, to the mobile application, a second graphical user interface for generating a request to adjust at least one of the plurality of protocols, wherein the second graphical user interface is displayed on the user device;
displaying, by the transaction application, a second graphical user interface for generating a request to adjust at least one of the number of protocols;
receive, from the mobile application via the second graphical user interface, a request with a numeric value for an increase to the threshold associated with the digital secondary account and a text input providing context for the request.
receiving, by the transaction application via the second graphical user interface, a numeric input for an increase to the threshold associated with the digital secondary account and a text input providing context for the request;
12. The system of claim 1, wherein the instructions, when executed by the one or more processors, cause the application server device to:
transmit one of a first message to the processing server computer to process the first portion of the transaction amount using a personal account of the secondary user, or a second message to a user device of the primary user to request authorization for using the digital secondary account to process the first portion of the transaction.
completing, by the transaction application, the transaction by providing payment credentials comprised of the digital token, wherein the transaction is processed using multiple accounts associated with multiple people including the personal account of the secondary user and the primary account of the primary user (claim 1)
13. The system of claim 1, further comprising the user device of the secondary user.
receiving, at a transaction application stored on a user device of a secondary user from a server computer (claim 1)
The newly added claims 14-20 are significantly similar to claim(s) above. As such, the claims are also rejected.
Response to the Argument(s)
112
The claim necessitates 112(a) rejection as described above.
101
The applicant asserts that the claim integrates judicial exception into a practical application since it improves the functioning of a computer or other technology. The applicant points to [0105]-[0106] of the published specification. These paragraphs, however, merely describes business centric problems. In other words, the improvement is on the business problems, i.e., implementation of rules for payment processing. The processing of the transaction using at least a personal account of the secondary user and the primary account of the primary user pursuant to at least one adjusted protocol (i.e., adjustment made based rules) is a concept that is found in a certain method of organizing human activity, i.e., fundamental economic principle/practice. The implementation of this particular judicial exception in a system that comprises an application server device does not improve upon the application server device nor its components. The additional elements amount no more than instructions to implement the abstract idea or uses computer to implement the abstract idea.
Double Patenting Rejections
The claims remain rejected on the ground of non-statutory double patenting.
For these reasons, the examiner maintains the rejections.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 10445739 B1 discloses a mobile wallet system allows for a master wallet associated with a primary account holder to provide limited access to an account of the primary account holder to secondary users. The primary account holder can limit a secondary user's level of access to the funds in the account by establishing spending rules and limits for each secondary user. The rules and limits restrict the secondary users' abilities to spend funds in the account. The rule and limit types include spending limits, types of goods and services restrictions, store specific restrictions, purpose of purchase rules, purchase timing rules, geographic restrictions, group purchase rules;
US 8401904 B1 discloses features to be used in a proxy card payment system include a real-time request to override a declined transaction or to select a different financial account and the insertion of user identification information into the transaction approval message sent to the merchant. A payment request is forwarded to the payment system, which maintains the proxy card account and determines whether the transaction violates a user-defined rule. If the transaction is declined by the issuer that maintains the financial account, or the payment system for violation of a user-defined rule, the payment system sends a real-time message to the user. The user is prompted to override the rule causing the transaction to be declined or to select a new account to process the transaction. Once the payment system receives authorization for the transaction, it inserts the user identification information in an approval message before transmitting the approval to the merchant.
The prior art of record does not particularly teach the interaction involving itinerary, the use of the itinerary, and wherein the transaction is processed using at least a personal account of the secondary user and the primary account of the primary user pursuant to at least one adjusted protocol recited in the claim(s).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN S KIM whose telephone number is (571)270-5287. The examiner can normally be reached Monday -Friday: 7:00 - 3:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached on 571-272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights