DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 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.
This action is in reply to Application 18/982,638 filed on 16 December 2024
Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
The Information Disclosure Statement filed 18 March 2025 has been considered. An initialed copy of the Form 1449 is enclosed herewith.
Claim Objection
Claims 1-20 are objected to for the following informalities:
The phrase “funds shares” should be corrected to instead recite “fund’s shares” or “funds’ shares” in order to indicate proper possession of the shares by said fund and/or funds.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. In the instant case, representative method claim 1 is directed towards facilitating payment allocation based on collected participant expenses in an automatic manner. Claim 1 is directed to the abstract idea of utilizing rules and/or instructions for performing the existing commercial practice (e.g., managing commercial/economic interactions between people) in an automatic manner, which is grouped under the certain methods of organizing human activity – fundamental economic principles, practices or concepts; sales activity; following set of instructions; commercial interactions; managing interactions between people (including social activities, teachings, following rules or instructions) grouping, in prong one of step 2A.
Claim 1 recites:
“acquiring payment information of a funds sharing service provisioned for a specific payment intention, wherein the payment information is obtained after order payment is made by using the funds sharing service as a payment mode;
if an allocation instruction for target participating members of the funds sharing service is detected, performing funds allocation based on a quantity of members of the target participating members and a payment amount comprised in the payment information, to obtain funds shares of the target participating members; and
performing deduction from balance amounts of the target participating members in the funds sharing service based on the funds shares”
Based on the underlined elements above, abstract ideas and/or concepts are identified. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A
When analyzed under step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claims merely describe the concept of utilizing rules and/or instructions for performing the existing commercial practice (e.g., managing commercial/economic interactions between people) in an automatic manner using computer computer-related technology and/or devices that merely perform as designed to function. Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Hence, claim 1 is not patent eligible.
Independent claim 19 recites substantially the same limitations as claim 1 above and is ineligible for the same reasons. The subject matter of claim 19 corresponds to the subject matter of claim 1 in terms of a funds processing method (e.g., process). Therefore the reasoning provided for claim 1 applies to claim 19 accordingly.
Additionally, regarding method claims 1 and 19, no computer processor device is recited to carry out the recited functionality of the invention. In this instance, it is not clear whether any of the instructions are in executable form and therefore there is no practical application.
As such, the claim is non-statutory because the body of the claim does not contain any limitations indicating the structure of the device and does not recite any machine or transformation (insufficient recitation of a machine or transformation either express or inherent) – no specific computer or processing device recited to carry out the claimed steps or execute computer code instructions is recited. See Interim Guidance for Determining Subject Matter Eligibility for Process Claims in View of Bilski v. Kappos (Federal Register / Vol. 75, No. 143 / Tuesday, July 27, 2010 / Notices).
Independent claim 20 recites substantially the same limitations as claim 1 above and is ineligible for the same reasons. The subject matter of claim 20 corresponds to the subject matter of claim 1 in terms of a funds processing device (e.g., manufacture). Therefore the reasoning provided for claim 1 applies to claim 20 accordingly.
Dependent claims 2-18 add further details and contain limitations that narrow the scope of the invention. However, these details do not result in significantly more than the abstract idea itself. As explained in the December 16, 2014 Interim Eligibility Guidance from the USPTO (in reference to the BuySAFE, Inc. v. Google, Inc. decision), further narrowing the details of an abstract idea does not change the § 101 analysis since a more narrow abstract idea does not make it any less abstract.
The step(s) recited are a further refinement of methods of organizing human activity – – fundamental economic principles, practices or concepts; sales activity; following set of instructions; commercial or legal interactions (agreements in the form of contracts; business relations); managing interactions between people (including social activities, teachings, following rules or instructions), because it merely describes intermediate steps and/or rules/instructions of the process.
Viewed individually and in combination, these additional elements do not provide meaningful limitations to transform the abstract idea such that the claims amount to significantly more than the abstraction itself.
Accordingly, the present pending claims are not patent eligible and are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections – 35 USC § 103
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 may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Tosmur, US 2022/0180345 A1 (“Tosmur”), in view of Li et al., US 2017 /0352019 A1 (“Li”).
Re Claim 1: Tosmur discloses a funds processing method, comprising:
acquiring payment information of a funds sharing service provisioned for a specific payment intention, wherein the payment information is obtained after order payment is made by using the funds sharing service as a payment mode; ([0011] “payment processing unit (i.e., a server) upon receiving the split payment option and the split payment definition, stores the split payment definition and an identity of the user, notifies each of the one or more participants about the split payment definition, and assigns to each of the one or more participants a status as "waiting" … the payment processing unit upon receiving an approve notification from a participant, updates the status of the participant to approving participant, and updates the split payment definition based on the status of each of the one or more participants”; [0008] “during performing the purchase transaction using the split payment, the PPU deduces the amount to be charged associated with each of the one or more participants from an account associated with each of the one or more participant”; [0064] “A purchase transaction can be transmitted from various channel such as a terminal, payment network, web portal, an API (Application Programming Interface)”)
if an allocation instruction for target participating members of the funds sharing service is detected, performing funds allocation based on a quantity of members of the target participating members and a payment amount comprised in the payment information, to obtain funds shares of the target participating members; ([0008] “during performing the purchase transaction using the split payment, the PPU deduces the amount to be charged associated with each of the one or more participants from an account associated with each of the one or more participant”; [0013] “payment processing unit receives a split payment definition request from a user device. The split payment definition request includes one or more participants, an amount to be charged associated with each of the one or more participants, an amount of a purchase transaction, and a unique/special password or PIN assigned to the split payment”)
Regarding the limitation comprising:
performing deduction from balance amounts of the target participating members in the funds sharing service based on the funds shares.
Li, however, makes this teaching in a related endeavor ([0040] “In at least one embodiment, the multi-push funds transaction may include information pertaining to multiple pull funds transactions”; [0041] “As a non-limiting example, a processing network computer may provide one or more
application programming interfaces ( e.g., APIs for providing push funds transactions, pull funds transactions, multi-push funds transactions, multi-pull funds transactions, and the like)”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Li to the invention of Tosmur as described above for the motivation of efficient shared transaction processing.
Re Claim 2: Tosmur in view of Li discloses the funds processing method according to claim 1. Tosmur further discloses:
wherein a total amount of the balance amounts of the participating members of the funds sharing service is a total funds amount of the funds sharing service; and
after the participating members perform funds transfer-in to the funds sharing service, transferring corresponding transfer-in funds to a fund account of a creating member of the funds sharing service and locking the fund account, and updating, based on the transfer-in funds, the total funds amount and the balance amounts of the participating members that perform the funds transfer-in.
([0008] “during performing the purchase transaction using the split payment, the PPU deduces the amount to be charged associated with each of the one or more participants from an account associated with each of the one or more participant”; [0013] “payment processing unit receives a split payment definition request from a user device. The split payment definition request includes one or more participants, an amount to be charged associated with each of the one or more participants, an amount of a purchase transaction, and a unique/special password or PIN assigned to the split payment”; [0100] “FIG. 11 illustrates an example sequence diagram for updating parameters & restrictions of a pre-defined split payment”; [0109] “FIG. 14 illustrates an example sequence diagram for updating a participant amount of an existing pre-defined split payment”)
Re Claim 3: Tosmur in view of Li discloses the funds processing method according to claim 1. Tosmur further discloses:
performing the funds allocation based on the quantity of members corresponding to member identifiers that are comprised in the allocation instruction and the payment amount, to obtain the funds shares of the target participating members;
calculating allocation shares based on the payment amount and the quantity of members; and
determining the allocation shares as the funds shares of the target participating members.
([0008] “during performing the purchase transaction using the split payment, the PPU deduces the amount to be charged associated with each of the one or more participants from an account associated with each of the one or more participant”; [0013] “payment processing unit receives a split payment definition request from a user device. The split payment definition request includes one or more participants, an amount to be charged associated with each of the one or more participants, an amount of a purchase transaction, and a unique/special password or PIN assigned to the split payment”; [0016] “parameters may include at least one of: a note, a category of purchase transaction, a date, a time, a merchant, a merchant category, a location, an expiration date for the split payment definition, and a restriction to share the amount of the one or more participants is charged”).
Re Claim 4: Tosmur in view of Li discloses the funds processing method according to claim 1. Tosmur further discloses:
wherein after acquiring the payment information of the funds sharing service provisioned for the specific payment intention, the method further comprises: if a payment participation instruction for a participating member in a payment factor of the funds sharing service is obtained, and configuration information for funds to be allocated in the payment factor is obtained, performing deduction from a balance amount of the payment participating member in the funds sharing service based on a funds share of the payment participating member corresponding to the payment participation instruction in the configuration information.
([0008] “during performing the purchase transaction using the split payment, the PPU deduces the amount to be charged associated with each of the one or more participants from an account associated with each of the one or more participant”; [0013] “payment processing unit receives a split payment definition request from a user device. The split payment definition request includes one or more participants, an amount to be charged associated with each of the one or more participants, an amount of a purchase transaction, and a unique/special password or PIN assigned to the split payment”)
Re Claim 5: Tosmur in view of Li discloses the funds processing method according to claim 1. Tosmur further discloses:
calculating funds allocation shares based on the quantity of members of the participating members of the funds sharing service and the payment amount; and
performing deduction from balance amounts of the participating members in the funds sharing service based on the funds allocation shares, and generating an allocation share list of the payment amount based on the funds allocation shares and member identifiers of the participating members.
([0023] “The payment processing unit upon a determination that the split payment definition is active, determines whether there are any restrictions or rules that prevent performing the
purchase transaction, determines whether each approving participant has sufficient funds to pay the amount to be charged associated with the participant, calculates a first calculated amount equal to an available balance in user's account added to a total amount to be charged associated with the approving participants (first amount), and calculates a second calculated amount equal to the available balance in the user's account subtracted from the amount of the purchase transaction” ([0008] “during performing the purchase transaction using the split payment, the PPU deduces the amount to be charged associated with each of the one or more participants from an account associated with each of the one or more participant”)
Re Claim 6: Tosmur in view of Li discloses the funds processing method according to claim 1. Tosmur further discloses:
generating a payment bill of the funds sharing service based on the payment information;
generating an allocation result of the payment bill based on the funds shares of the target participating members, and associating the allocation result with the payment bill; and
updating a service bill list of the funds sharing service based on the payment bill and the allocation result.
([0008] “during performing the purchase transaction using the split payment, the PPU deduces the amount to be charged associated with each of the one or more participants from an account associated with each of the one or more participant”; [0013] “payment processing unit receives a split payment definition request from a user device. The split payment definition request includes one or more participants, an amount to be charged associated with each of the one or more participants, an amount of a purchase transaction, and a unique/special password or PIN assigned to the split payment”; [0100] “FIG. 11 illustrates an example sequence diagram for updating parameters & restrictions of a pre-defined split payment”; [0109] “FIG. 14 illustrates an example sequence diagram for updating a participant amount of an existing pre-defined split payment”; [0013] “In some embodiments, payment processing unit receives a split payment definition request from a user device. The split payment definition request includes one or more participants, an amount to be charged associated with each of the one or more participants, an amount of a purchase transaction”)
Re Claim 7: Tosmur in view of Li discloses the funds processing method according to claim 6. Tosmur further discloses:
generating bill keywords of the target participating members for the payment bill based on the allocation result of the target participating members for the payment amount; or
generating a bill keyword of a participating member other than the target participating members in the participating members of the funds sharing service for the payment bill based on the allocation result of the payment amount.
([0012] “… payment processing unit transfers the approved amounts to the user's account from the approved participant's checked accounts and confirms the purchase transaction”)
Re Claim 8: Tosmur in view of Li discloses the funds processing method according to claim 1. Tosmur further discloses:
wherein after performing the deduction from the balance amounts of the target participating members in the funds sharing service based on the funds shares, the method further comprises:
determining balance statuses of the target participating members in the funds sharing service based on balance amounts of the target participating member obtained after the deduction; and
updating a member funds list of the funds sharing service based on the balance amounts and the balance statuses of the target participating members after the deduction.
([0057] “owner of the split payment can track the participant status on a split payment”; [0100] “FIG. 11 illustrates an example sequence diagram for updating parameters & restrictions of a pre-defined split payment”; [0109] “FIG. 14 illustrates an example sequence diagram for updating a participant amount of an existing pre-defined split payment”)
Re Claim 9: Tosmur in view of Li discloses the funds processing method according to claim 8. Tosmur further discloses:
if a recharging instruction for a balance amount from any participating member having a balance status being a first state is detected, transferring funds corresponding to a transfer-in amount in a member account of the any participating member to a fund account of a creating member of the funds sharing service and locking the fund account;
updating a balance amount of the any participating member and a total funds amount of the funds sharing service based on the transfer-in amount; and
updating the member funds list based on the balance amount, the total funds amount, and the balance status corresponding to the balance amount.
([0057] “owner of the split payment can track the participant status on a split payment”; [0100] “FIG. 11 illustrates an example sequence diagram for updating parameters & restrictions of a pre-defined split payment”; [0109] “FIG. 14 illustrates an example sequence diagram for updating a participant amount of an existing pre-defined split payment”; [013] “Participants with insufficient funds are not included in the next step calculation. In the second calculation, balances determined to be sufficient on the participants' accounts in the previous step is added the available balance of the pre-defined split payment owner”)
Re Claim 10: Tosmur in view of Li discloses the funds processing method according to claim 8. Tosmur further discloses:
if an apportioning instruction for a total funds amount of the funds sharing service is detected, acquiring an apportioning member identifier comprised and apportioning configuration information of an apportioning funds amount; and
transferring apportioning funds corresponding to the apportioning funds amount in a fund account of a creating member of the funds sharing service to a member account of an apportioning member corresponding to the apportioning member identifier.
([0062] “user enters participant's information with a unique identifier such as a mobile number, an account number. Alternatively, the user selects participant(s) from a contact list directly”; [0013] “balances determined to be sufficient on the participants' accounts in the previous step is added the available balance of the pre-defined split payment owner”)
Re Claim 11: Tosmur in view of Li discloses the funds processing method according to claim 1. Tosmur further discloses:
wherein before acquiring the payment information of the funds sharing service provisioned for the specific payment intention, the method further comprises:
when it is detected that a user triggers a predetermined interface, generating the funds sharing service that uses the user as a creating member;
determining, as a participating member of the funds sharing service, a user invited by the creating member;
if a management member configuration instruction of the creating member is detected, determining, as a management member of the funds sharing service, a participating member corresponding to a member identifier comprised in the management member configuration instruction.
([0062] “user enters participant's information with a unique identifier such as a mobile number, an account number. Alternatively, the user selects participant(s) from a contact list directly”; [0013] “balances determined to be sufficient on the participants' accounts in the previous step is added the available balance of the pre-defined split payment owner”)
Re Claim 12: Tosmur in view of Li discloses the funds processing method according to claim 1. Tosmur further discloses:
wherein before acquiring the payment information of the funds sharing service provisioned for the specific payment intention, the method further comprises:
querying a funds sharing service set that a participating member corresponding to the payment information participates in, and reading an available-funds amount of the participating member in each funds sharing service in the funds sharing service set;
determining a payment tag of each funds sharing service based on the available-funds amount of the participating member in the funds sharing service and the payment amount; and
generating a payment mode list that comprises a service identifier and the payment tag of the funds sharing service.
([0024] “payment processing unit determines whether each approving participant has sufficient funds to pay the amount to be charged associated with the participant, calculates a first calculated amount equal to an available balance in user's account added to a total amount to be charged associated with the approving participants ( first total), calculates a second calculated amount equal to the available balance in user's account subtracted from the amount of the purchase transaction, upon determinations that the first calculated amount is equal to or greater than the amount of the purchase transaction, and that the second calculated amount is equal to or less than user's pre-defined maximum participation amount, transfers the amounts to be charged associated with the approving participants to the user's account, and transfers the amount of purchase transaction from the user's account”)
Re Claim 13: Tosmur in view of Li discloses the funds processing method according to claim 12. Tosmur further discloses:
wherein the determining a payment tag of each funds sharing service based on the available-funds amount of the participating member in the funds sharing service and the payment amount comprises:
calculating a difference between the available-funds amount of the participating member in the funds sharing service and the payment amount; and
determining that a payment tag of a funds sharing service with the difference greater than or equal to a predetermined threshold is an available-funds amount of the participating member in the funds sharing service, and determining that a payment tag of a funds sharing service with the difference less than the predetermined threshold is a non-payment tag.
([0024] “payment processing unit determines whether each approving participant has sufficient funds to pay the amount to be charged associated with the participant, calculates a first calculated amount equal to an available balance in user's account added to a total amount to be charged associated with the approving participants ( first total), calculates a second calculated amount equal to the available balance in user's account subtracted from the amount of the purchase transaction, upon determinations that the first calculated amount is equal to or greater than the amount of the purchase transaction, and that the second calculated amount is equal to or less than user's pre-defined maximum participation amount, transfers the amounts to be charged associated with the approving participants to the user's account, and transfers the amount of purchase transaction from the user's account”)
Re Claim 14: Tosmur in view of Li discloses the funds processing method according to claim 1. Tosmur further discloses:
wherein a balance amount of each participating member in the funds sharing service is determined based on a transfer-in amount of the participating member to the funds sharing service and funds shares for funds allocation; and
an available-funds amount of the participating member is configured for the funds sharing service, and the available-funds amount is determined based on an available-funds strategy of the funds sharing service and an expenditure of the participating member for funds payment.
([0024] “payment processing unit determines whether each approving participant has sufficient funds to pay the amount to be charged associated with the participant, calculates a first calculated amount equal to an available balance in user's account added to a total amount to be charged associated with the approving participants ( first total), calculates a second calculated amount equal to the available balance in user's account subtracted from the amount of the purchase transaction, upon determinations that the first calculated amount is equal to or greater than the amount of the purchase transaction, and that the second calculated amount is equal to or less than user's pre-defined maximum participation amount, transfers the amounts to be charged associated with the approving participants to the user's account, and transfers the amount of purchase transaction from the user's account”)
Re Claim 15: Tosmur in view of Li discloses the funds processing method according to claim 14. Tosmur further discloses:
wherein the available-funds strategy is configured in the following manner:
acquiring strategy configuration information submitted by a creating member or a management member of the funds sharing service, and sending, to the management member or the creating member, a strategy configuration prompt that comprises the strategy configuration information; and
if a confirmation instruction of the management member or the creating member for the strategy configuration prompt is detected, generating the available-funds strategy of the funds sharing service based on the strategy configuration information.
([0068] “Acquirer 0608 represents a financial institution's system that processes payment instrument payments on behalf of a merchant and then settles the transaction with the payment instrument's issuer directly or via a payment scheme”)
Re Claim 16: Tosmur in view of Li discloses the funds processing method according to claim 1. Tosmur further discloses:
after funds transfer-in information that is based on a collection identifier of the funds sharing service is detected, reading key information in the funds transfer-in information;
generating a funds transfer-in bill based on the key information and updating a service bill list of the funds sharing service, and updating dynamic information of the funds sharing service based on the key information.
([0011] “payment processing unit (i.e., a server) upon receiving the split payment option and the split payment definition, stores the split payment definition and an identity of the user, notifies each of the one or more participants about the split payment definition, and assigns to each of the one or more participants a status as "waiting" … the payment processing unit upon receiving an approve notification from a participant, updates the status of the participant to approving participant, and updates the split payment definition based on the status of each of the one or more participants”; [0008] “during performing the purchase transaction using the split payment, the PPU deduces the amount to be charged associated with each of the one or more participants from an account associated with each of the one or more participant”; [0064] “A purchase transaction can be transmitted from various channel such as a terminal, payment network, web portal, an API (Application Programming Interface)”; [0024] “upon determinations that the first calculated amount is equal to or greater than the amount of the purchase transaction, and that the second calculated amount is equal to or less than user's pre-defined maximum participation amount, transfers the amounts to be charged associated with the approving participants to the user's account, and transfers the amount of purchase transaction from the user's account”)
Re Claim 17: Tosmur in view of Li discloses the funds processing method according to claim 16. Tosmur further discloses:
wherein updating the dynamic information of the funds sharing service based on the key information comprises:
if a transfer-in user identifier in the key information does not match a member identifier of a participating member of the funds sharing service, desensitizing the transfer-in user identifier;
generating dynamic information based on at least one of the desensitized user identifier and a member identifier of an access member of the collection identifier, a transfer-in amount, or an identified collection channel in the key information, and adding the dynamic information to a dynamic information list of the funds sharing service.
([0011] “payment processing unit further upon receiving a deny notification from a participant, removes the participant from the split payment definition and updates the status of the participant to denying participant and notifies the user about the deny notification and identity of the denying participant. In some embodiments, the payment processing unit upon receiving an approve notification from a participant, updates the status of the participant to approving participant, and updates the split payment definition based on the status of each of the one or more participants; [0010] “user selects one or more participants from a plurality of participants from a contact list directory, or alternatively by entering a unique identifier associated with each of the one or more participants. The unique identifier is at least one of:
a phone number, an account number, and a participant's email address”)
Re Claim 18: Tosmur in view of Li discloses the funds processing method according to claim 17. Tosmur further discloses:
sending, to a user that the transfer-in user identifier belongs to, a participating invitation message for the funds sharing service based on a member invitation tag configured based on the collection identifier; and
if it is detected that the user submits a confirmation instruction for the participating invitation message, determining the user as a participating member of the funds sharing service based on at least one of a participating confirmation instruction of a creating member or a management member of the funds sharing service.
([0011] “payment processing unit further upon receiving a deny notification from a participant, removes the participant from the split payment definition and updates the status of the participant to denying participant and notifies the user about the deny notification and identity of the denying participant. In some embodiments, the payment processing unit upon receiving an approve notification from a participant, updates the status of the participant to approving participant, and updates the split payment definition based on the status of each of the one or more participants; [0010] “user selects one or more participants from a plurality of participants from a contact list directory, or alternatively by entering a unique identifier associated with each of the one or more participants. The unique identifier is at least one of:
a phone number, an account number, and a participant's email address”)
Re Claim 19: Tosmur discloses a funds processing method, comprising:
acquiring and displaying a member list of a funds sharing service, wherein the member list is displayed after payment information is obtained by performing order payment based on the funds sharing service;
([0011] “payment processing unit further upon receiving a deny notification from a participant, removes the participant from the split payment definition and updates the status of the participant to denying participant and notifies the user about the deny notification and identity of the denying participant. In some embodiments, the payment processing unit upon receiving an approve notification from a participant, updates the status of the participant to approving participant, and updates the split payment definition based on the status of each of the one or more participants; [0010] “user selects one or more participants from a plurality of participants from a contact list directory, or alternatively by entering a unique identifier associated with each of the one or more participants. The unique identifier is at least one of:
a phone number, an account number, and a participant's email address”)
receiving an allocation instruction submitted for target participating members of the funds sharing service, to perform funds allocation based on a quantity of members of the target participating members and a payment amount comprised in the payment information; and
([0008] “during performing the purchase transaction using the split payment, the PPU deduces the amount to be charged associated with each of the one or more participants from an account associated with each of the one or more participant”; [0013] “payment processing unit receives a split payment definition request from a user device. The split payment definition request includes one or more participants, an amount to be charged associated with each of the one or more participants, an amount of a purchase transaction, and a unique/special password or PIN assigned to the split payment”)
Regarding the limitation comprising:
receiving an allocation confirmation instruction submitted for funds shares of the target participating members obtained for funds allocation, to perform deduction from balance amounts of the target participating members in the funds sharing service based on the funds shares.
Li, however, makes this teaching in a related endeavor ([0040] “In at least one embodiment, the multi-push funds transaction may include information pertaining to multiple pull funds transactions”; [0041] “As a non-limiting example, a processing network computer may provide one or more
application programming interfaces ( e.g., APIs for providing push funds transactions, pull funds transactions, multi-push funds transactions, multi-pull funds transactions, and the like)”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Li to the invention of Tosmur as described above for the motivation of efficient shared transaction processing.
Re Claim 20: Claim 20, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 1. Accordingly, claim 20 is rejected in the same or substantially the same manner as claim 1.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Ham (US 10,282,713 B2) discloses a bill splitting and payment system and method. The present subject matter discloses systems and methods in which a mobile application integrates with a restaurant's point of sale (POS) system such that, by providing a table identifier, users may split and pay an itemized bill, without the need of servers or restaurant staff.
Melby et al. (US 2012/0173396 A1) discloses bill division and group payment systems and methods. Systems and methods for dividing a group bill among users, collecting funds from the users, and paying a third party with the collected funds using a group billing system. Users may have individual accounts associated with the group billing system. The individual accounts may be associated with a
prepaid credit or debit card, or other payment vehicle.
Claims 1-20 are rejected.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Clifford Madamba whose telephone number is 571-270-1239. The examiner can normally be reached on Mon-Thu 7:30-5:00 EST Alternate Fridays.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Donlon, can be reached at 571-272-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CLIFFORD B MADAMBA/Primary Examiner, Art Unit 3692