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 the remarks/arguments for Application 18/982,638 filed on 18 May 2026.
Claims 11 and 19 have been canceled.
Claims 1- 3, 6, 8, 14, and 20 have been amended.
Claims 1-10, 12-18, and 20 are currently pending and have been examined.
Response to Arguments
A. Claim Objections:
Claims 1-20 stand objected to for various informalities.
In response, Applicant’s amendments to the pending set of claims in order to address the issue have been considered and are persuasive. Accordingly, the objection to the claims is withdrawn.
B. Claim Rejections - 35 USC § 101:
Claims 1-20 stand rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
1. Applicant argues that the claims are not directed to an abstract idea.
Examiner respectfully disagrees. 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 recites 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:
“in response to detecting a predetermined interface on a terminal device being triggered by a user, generating a funds sharing service that uses the user as a creating member and displaying on the terminal device a service access page for the funds sharing service;
in response to detecting a member invitation control on the service access page being triggered, determining, as a participating member of the funds sharing service, a user invited via the member invitation control;
in response to detecting a management member configuration instruction received on the terminal device, 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;
in response to detecting a collection control on the service access page being triggered, acquiring payment information of the 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;
displaying on the terminal device an allocation share display page to detect an allocation instruction for target participating members of the funds sharing service wherein funds allocation is performed based on a quantity of members of the target participating members and a payment amount comprised in the payment information, to obtain fund shares of the target participating members; and
in response to detecting an allocation control on the funds share display page being triggered, executing an allocation confirmation instruction for performing deduction from balance amounts of the target participating members in the funds sharing service based on the fund shares”.
Based on the underlined elements above, abstract ideas and/or concepts are identified. Accordingly, the claim recites an abstract idea. Applicant’s argument is therefore unpersuasive.
2. Applicant further argues that the present claims do not fall within the Method of Organizing Human Activity as the steps recited cannot be performed by a human mentally or with pen and paper; nor a Mathematical Concept, nor a Mental Process.
Examiner respectfully disagrees. The basis of the rejection is not directed to a mental process covering performance in the mind, nor to a mathematical concept but rather the invention is directed towards an abstract idea (without significantly more) of facilitating payment allocation based on collected participant expenses in an automatic manner while merely 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. Applicant’s argument is therefore unpersuasive.
3. Applicant further argues that the present claims are patent eligible at Prong Two, because the claims as a whole integrate the recited judicial exception into a practical application of that exception – e.g., efficient and automatic processing of transfer and pay services using Internet technologies.
Examiner respectfully disagrees. The judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A, the additional elements of the claim such as a “processor”, “interface”, “terminal device”, represent the use of a computer-related device as a tool (intermediary) to perform an abstract idea and/or does no more than generally apply the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e. automate) implement the acts of utilizing rules and/or instructions for performing the existing commercial practice (e.g., managing commercial/economic interactions between people) in an automatic manner.
In the instant application, there is no actual improvement made to the operations or physical structure of the additional elements claimed. There are no actual improvements to another technology or technical field (e.g., Internet), no improvements to the functioning of the computer itself, and there are no meaningful limitations beyond generally applying the use of the abstract idea to a particular technological environment evident in the claims. Applicant’s argument is therefore unpersuasive.
4. Applicant further argues that even if the claims Are directed to an abstract idea, the present claims amount to significantly more than an abstract idea.
Examiner respectfully disagrees. 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, the present claims are not patent eligible. Applicant’s argument is therefore unpersuasive.
The rejection is therefore maintained.
C. Claim Rejections - 35 USC § 103:
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”).
The Office has given consideration to the remarks and/or amendments made to the pending set of claims, but are considered moot in light of the grounds of rejection, provided below, for the current listing of amended claims.
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-10, 12-18, and 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 recites 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:
“in response to detecting a predetermined interface on a terminal device being triggered by a user, generating a funds sharing service that uses the user as a creating member and displaying on the terminal device a service access page for the funds sharing service;
in response to detecting a member invitation control on the service access page being triggered, determining, as a participating member of the funds sharing service, a user invited via the member invitation control;
in response to detecting a management member configuration instruction received on the terminal device, 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;
in response to detecting a collection control on the service access page being triggered, acquiring payment information of the 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;
displaying on the terminal device an allocation share display page to detect an allocation instruction for target participating members of the funds sharing service wherein funds allocation is performed based on a quantity of members of the target participating members and a payment amount comprised in the payment information, to obtain fund shares of the target participating members; and
in response to detecting an allocation control on the funds share display page being triggered, executing an allocation confirmation instruction for performing deduction from balance amounts of the target participating members in the funds sharing service based on the fund 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, the additional elements of the claim such as a “processor”, “interface”, “terminal device”, represent the use of a computer-related device as a tool (intermediary) to perform an abstract idea and/or does no more than generally apply the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e. automate) implement the acts of utilizing rules and/or instructions for performing the existing commercial practice (e.g., managing commercial/economic interactions between people) in an automatic manner.
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 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-10 and 12-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-10, 12-18, and 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: (Currently Amended) Tosmur discloses a funds processing method, comprising:
in response to detecting a predetermined interface on a terminal device being triggered by a user, generating a funds sharing service that uses the user as a creating member and displaying on the terminal device a service access page for the funds sharing service;
([0006] “invention also provides a real time authorization mechanism that allows to split the payment amount between the stakeholders”; [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”; [0048] “FIG. 33 illustrates an example graphical user interface (GUI) for defining general parameters of a pre-defined split payment.”; [0058] “The present application discloses a split payment method in which before initiating the split payment process, a software application in mobile devices, or in any kind of computing device, is executed. The software application software defines, registers, and allows participation of all the users of the split payment users”)
in response to detecting a member invitation control on the service access page being triggered, determining, as a participating member of the funds sharing service, a user invited via the member invitation control;
([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.”)
in response to detecting a management member configuration instruction received on the terminal device, 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;
([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.”)
in response to detecting a collection control on the service access page being triggered, acquiring payment information of the 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;
([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)”)
displaying on the terminal device an allocation share display page to detect an allocation instruction for target participating members of the funds sharing service wherein funds allocation is performed based on a quantity of members of the target participating members and a payment amount comprised in the payment information, to obtain fund 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 …”; [0048] “FIG. 33 illustrates an example graphical user interface (GUI) for defining general parameters of a pre-defined split payment.”)
Regarding the limitation comprising:
in response to detecting an allocation control on the funds share display page being triggered, executing an allocation confirmation instruction for performing deduction from balance amounts of the target participating members in the funds sharing service based on the fund 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)”; [0076] “… registration module 212 may receive user account information from a user. Such user account information may be collected by an interface provided by a component of the computer readable medium 210 (e.g., display manager module 222)”). 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: (Currently Amended) 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]] the 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: (Currently Amended) 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]] fund 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]] fund 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: (Original) 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: (Original) 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: (Currently Amended) 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]] fund shares of the target participating members, and associating the allocation result with the payment bill;
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: (Original) 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: (Currently Amended) 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]] fund 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: (Original) 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: (Original) 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: (Canceled)
Re Claim 12: (Original) 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: (Original) 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: (Currently Amended) 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]] fund shares for funds allocation;
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: (Original) 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: (Original) 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: (Original) 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: (Original) 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: (Canceled)
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-10, 12-18, and 20 are rejected.
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
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
Prosecution Insights