DETAILED ACTION
This action is in reply to the request for continued examination filed on 03/10/2026.
Claims 1, 4-6, 8, 11-13, 15, and 17-19 have been amended.
Claims 3 and 10 have been canceled.
Claims 2, 9, and 16 were canceled.
Claims 1, 4-8, 11-15, and 17-20 are pending.
Claims 1, 4-8, 11-15, and 17-20 have been examined.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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. Applicant's submission filed on 03/10/2026 has been entered.
Response to Arguments
With regard to the Double Patenting rejection, the claims have been amended. However, the amended claims are still similar in scope with those of previously issued patents.
With regard to the 101 rejection, the arguments have been considered and they are persuasive. The applicant asserted that “the claims are not directed to any abstract idea, incorporate any alleged abstract idea into a practical thereof, and include additional features amount to significantly more than any abstract idea.” The claim, in fact, integrated these additional features into a judicial exception in an ordered combination. And therefore, the claim is patent eligible.
Claims 8 and 11-14 have been rejected under 35 U.S.C. 101 software per se because claim 8 is a system claim but did not recite any hardware structures or components.
With regard to the 103 rejection, the arguments have been considered but they are moot over new ground(s) of rejections. The claim has been amended and the scope is further narrow. In light of the amendment, the art search has been performed and the claim is reconsidered. Please refer to the rejection below for further details.
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 §§ 706.02(l)(1) - 706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claim 1, 4-8, 11-15, and 17-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 3-6, 8, 10-13, 15, 17-19 of Patent No. 12014340 (parent), claims 1-20 of Patent No. 11704638 (grandparent case). The claims are not patentably distinct from each other because they are both directed to methods for completing transactions via lockboxes. The claims from the current application are anticipated by the claims of the Patent Nos. 12014340, 11704638.
Current Application 18/669108
Patent No. 12014340
1. (Currently Amended) A method comprising: receiving, by a provider computing system of a provider, a credential and a lockbox transaction order associated with an account of the provider from a user device, the lockbox transaction order including a requested transaction and a desired transaction location; determining, by the provider computing system, an authorization level of the user device based on the credential, the authorization level being one of multiple tiered authorization levels, each tiered authorization level of the multiple tiered authorization levels corresponding to a threshold transaction dollar amount for transactions that the user device is authorized to perform; verifying, by the provider computing system, that a transaction amount an attribute of the lockbox transaction order conforms to the authorization level; determining, by the provider computing system, that the requested transaction cannot be completed at the desired transaction location; determining, by the provider computing system, a physical lockbox from a plurality of physical lockboxes as an alternative lockbox transaction location; transmitting, by the provider computing system, an indication to a user device indicating that the requested transaction can be completed at the alternative lockbox transaction location; [[and]] authenticating, by the provider computing system, a user at the physical lockbox; and unlocking, by the provider computing system, a door of the physical lockbox based on, wherein authenticating the user at the physical lockbox enables the physical lockbox to unlock and become accessible by the user.
2. (Canceled)
3. (Canceled)
4. (Currently Amended) The method of claim 1, further comprising verifying, by the provider computing system, that wherein the attribute comprises a lockbox location conforms to the authorization level.
5. (Currently Amended) The method of claim 1, further comprising verifying, by the provider computing system, that wherein the attribute comprises a transaction type conforms to the authorization level.
6. (Currently Amended) The method of claim 1, further comprising assigning, by the provider computing system, an employee to complete the lockbox transaction order based on the transaction amount attribute.
7. (Original) The method of claim 1, further comprising causing, by the provider computing system, a camera to record activity associated with the physical lockbox upon authentication.
8. (Currently Amended) A provider computing system structured to perform operations, the operations comprising: receiving a credential and a lockbox transaction order associated with an account of a_[[the ]]provider from a user device, the lockbox transaction order including a requested transaction and a desired transaction location; determining an authorization level of the user device based on the credential, the authorization level being one of multiple tiered authorization levels, each tiered authorization level of the multiple tiered authorization levels corresponding to a threshold transaction dollar amount for transactions that the user device is authorized to perform; verifying that a transaction amount an attribute of the lockbox transaction order conforms to the authorization level; determining that the requested transaction cannot be completed at the desired transaction location; determining a physical lockbox from a plurality of physical lockboxes as an alternative lockbox transaction location; transmitting an indication to a user device indicating that the requested transaction can be completed at the alternative lockbox transaction location; [[and]] authenticating a user at the physical lockbox; and unlocking a door of the physical lockbox based on, wherein authenticating the user at the physical lockbox enables the physical lockbox to unlock and become accessible by the user.
9. (Canceled)
10. (Canceled)
11. (Currently Amended) The provider computing system of claim 8, the operations further comprising verifying that a wherein the attribute comprises a lockbox location conforms to the authorization level.
12. (Currently Amended) The provider computing system of claim 8, the operations further comprising verifying that a wherein the attribute comprises a transaction type conforms to the authorization level.
13. (Currently Amended) The provider computing system of claim 8, the operations further comprising: assigning an employee to complete the lockbox transaction order based on the transaction amount attribute.
14. (Original) The provider computing system of claim 8, the operations further comprising: causing a camera to record activity associated with the physical lockbox upon authentication.
15. (Currently Amended) One or more non-transitory computer-readable media comprising instructions stored thereon that, when executed by a processing circuit of a provider computing system, cause the processing circuit to: receive a credential and a lockbox transaction order associated with an account of a_[[the ]]provider from a user device, the lockbox transaction order including a requested transaction and a desired transaction location; determine an authorization level of the user device based on the credential, the authorization level being one of multiple tiered authorization levels, each tiered authorization level of the multiple tiered authorization levels corresponding to a threshold transaction dollar amount for transactions that the user device is authorized to perform; verify that a transaction amount an attribute of the lockbox transaction order conforms to the authorization level; determine that the requested transaction cannot be completed at the desired transaction location; determine a physical lockbox from a plurality of physical lockboxes as an alternative lockbox transaction location; transmit an indication to a user device indicating that the requested transaction can be completed at the alternative lockbox transaction location; [[and]] authenticate a user at the physical lockbox; and unlock a door of the physical lockbox based on, wherein authenticating the user at the physical lockbox enables the physical lockbox to unlock and become accessible by the user.
16. (Cancelled)
17. (Currently Amended) The media of claim 15, wherein instructions further cause the processing circuit to verify that the attribute comprises at least one of a transaction type conforms to the authorization level and a transaction amount.
18. (Currently Amended) The media of claim 15, wherein instructions further cause the processing circuit to verify that the attribute comprises a lockbox location conforms to the authorization level.
19. (Currently Amended) The media of claim 15, wherein the instructions, when executed, further cause the processing circuit to: assign an employee to complete the lockbox transaction order based on the transaction amount attribute.
20. (Previously Presented) The media of claim 15, wherein the instructions, when executed, further cause the processing circuit to: cause a camera to record activity associated with the physical lockbox upon authentication.
1. (Currently Amended) A method comprising:
receiving, by a provider computing system of a provider, a first lockbox transaction order associated with an account of the provider from a first user device, the first lockbox transaction order including a first requested transaction and a desired transaction location;
validating, by the provider computing system, whether the first requested transaction can be completed at the desired transaction location;
determining, by the provider computing system based on determining that the first lockbox transaction order cannot be completed at the desired transaction location, a physical lockbox associated with the provider from a plurality of physical lockboxes at an alternative lockbox transaction location;
transmitting, by the provider computing system, an indication to [[a]] the first user device indicating that the first requested transaction can be completed at the alternative lockbox transaction location;
preparing the physical lockbox for the first requested transaction; and
authenticating, by the provider computing system, a first user at the physical lockbox, wherein the first user is a first account holder of the provider, wherein authenticating the first user at the physical lockbox enables the physical lockbox to unlock and become accessible by the first user;
receiving, by the provider computing system, a second lockbox transaction order from a second user device associated with a second account holder of the provider, the second lockbox transaction order including a second requested transaction;
determining, by the provider computing system, a second authorization level of at least one of the second user device and the second lockbox transaction order, the second authorization level being different from a first authorization level associated with at least one of the first user device and the first account holder;
verifying, by the provider computing system, that an attribute of the second lockbox transaction order conforms to the second authorization level;
preparing the physical lockbox for the second requested transaction;
authenticating, by the provider computing system, the second user at the physical lockbox, wherein authenticating the second user at the physical lockbox enables the physical lockbox to unlock and become accessible by the second user; and
causing, by the provider computing system, a camera to record activity associated with the physical lockbox upon at least one of authenticating the first user at the physical lockbox or authenticating the second user at the physical lockbox.
2. (Canceled)
3. (Currently Amended) The method of claim [[2]] 1, wherein the attribute comprises a transaction amount threshold.
4. (Currently Amended) The method of claim [[2]] 1, wherein the attribute comprises a lockbox location.
5. (Currently Amended) The method of claim [[2]] 1, wherein the attribute comprises a transaction type.
6. (Currently Amended) The method of claim [[2]] 1, further comprising assigning, by the provider computing system, an employee to complete the second lockbox transaction order based on the attribute.
7. (Canceled)
8. (Currently Amended) A provider computing system structured to perform operations comprising:
receiving a first lockbox transaction order associated with an account of the provider from a first user device, the first lockbox transaction order including a first requested transaction and a desired transaction location;
validating whether the first requested transaction can be completed at the desired transaction location;
determining, based on determining that the first lockbox transaction order cannot be completed at the desired transaction location, a physical lockbox associated with the provider from a plurality of physical lockboxes at an alternative lockbox transaction location;
transmitting an indication to [[a]] the first user device indicating that the first requested transaction can be completed at the alternative lockbox transaction location;
preparing the physical lockbox for the first requested transaction; and
authenticating a first user at the physical lockbox, wherein the first user is a first account holder of the provider, wherein authenticating the first user at the physical lockbox enables the physical lockbox to unlock and become accessible by the first user;
receiving a second lockbox transaction order from a second user device associated with a second account holder of the provider, the second lockbox transaction order including a second requested transaction;
determining a second authorization level of at least one of the second user device and the second lockbox transaction order, the second authorization level being different from a first authorization level associated with at least one of the first user device and the first account holder;
verifying that an attribute of the second lockbox transaction order conforms to the second authorization level;
preparing the physical lockbox for the second requested transaction;
authenticating the second user at the physical lockbox, wherein authenticating the second user at the physical lockbox enables the physical lockbox to unlock and become accessible by the second user; and
causing a camera to record activity associated with the physical lockbox upon at least one of authenticating the first user at the physical lockbox or authenticating the second user at the physical lockbox.
9. (Canceled)
10. (Currently Amended) The provider computing system of claim [[9]] 8, wherein the attribute comprises a transaction amount threshold.
11. (Currently Amended) The provider computing system of claim [[9]] 8, wherein the attribute comprises a lockbox location.
12. (Currently Amended) The provider computing system of claim [[9]] 8, wherein the attribute comprises a transaction type.
13. (Currently Amended) The provider computing system of claim [[9]] 8, the operations further comprising:
assigning an employee to complete the second lockbox transaction order based on the attribute.
14. (Canceled)
15. (Currently Amended) One or more non-transitory computer-readable media comprising instructions stored thereon that, when executed by one or more processors of a provider computing system, cause the one or more processors to:
receive a first lockbox transaction order associated with an account of the provider from a first user device, the first lockbox transaction order including a first requested transaction and a desired transaction location;
validate whether the first requested transaction can be completed at the desired transaction location;
determine, based on determining that the first lockbox transaction order cannot be completed at the desired transaction location, a physical lockbox associated with the provider from a plurality of physical lockboxes at an alternative lockbox transaction location;
transmit an indication to [[a]] the first user device indicating that the first requested transaction can be completed at the alternative lockbox transaction location;
prepare the physical lockbox for the first requested transaction; and
authenticate a first user at the physical lockbox, wherein the first user is a first account holder of the provider, wherein authenticating the first user at the physical lockbox enables the physical lockbox to unlock and become accessible by the first user;
receive a second lockbox transaction order from a second user device associated with a second account holder of the provider, the second lockbox transaction order including a second requested transaction;
determine a second authorization level of at least one of the second user device and the second lockbox transaction order, the second authorization level being different from a first authorization level associated with at least one of the first user device and the first account holder;
verify that an attribute of the second lockbox transaction order conforms to the second authorization level;
prepare the physical lockbox for the second requested transaction;
authenticate the second user at the physical lockbox, wherein authenticating the second user at the physical lockbox enables the physical lockbox to unlock and become accessible by the second user; and
cause a camera to record activity associated with the physical lockbox upon at least one of authenticating the first user at the physical lockbox or authenticating the second user at the physical lockbox.
16. (Canceled)
17. (Currently Amended) The media of claim [[16]] 15, wherein the attribute comprises at least one of a transaction type and a transaction amount threshold.
18. (Currently Amended) The media of claim [[16]] 15, wherein the attribute comprises a lockbox location.
19. (Currently Amended) The media of claim [[16]] 15, wherein the instructions, when executed, further cause the one or more processors to:
assign an employee to complete the second lockbox transaction order based on the attribute.
20. (Canceled)
Current Application 18/669108
Patent No. 11704638
1. (Currently Amended) A method comprising: receiving, by a provider computing system of a provider, a credential and a lockbox transaction order associated with an account of the provider from a user device, the lockbox transaction order including a requested transaction and a desired transaction location; determining, by the provider computing system, an authorization level of the user device based on the credential, the authorization level being one of multiple tiered authorization levels, each tiered authorization level of the multiple tiered authorization levels corresponding to a threshold transaction dollar amount for transactions that the user device is authorized to perform; verifying, by the provider computing system, that a transaction amount an attribute of the lockbox transaction order conforms to the authorization level; determining, by the provider computing system, that the requested transaction cannot be completed at the desired transaction location; determining, by the provider computing system, a physical lockbox from a plurality of physical lockboxes as an alternative lockbox transaction location; transmitting, by the provider computing system, an indication to a user device indicating that the requested transaction can be completed at the alternative lockbox transaction location; [[and]] authenticating, by the provider computing system, a user at the physical lockbox; and unlocking, by the provider computing system, a door of the physical lockbox based on, wherein authenticating the user at the physical lockbox enables the physical lockbox to unlock and become accessible by the user.
2. (Canceled)
3. (Canceled)
4. (Currently Amended) The method of claim 1, further comprising verifying, by the provider computing system, that wherein the attribute comprises a lockbox location conforms to the authorization level.
5. (Currently Amended) The method of claim 1, further comprising verifying, by the provider computing system, that wherein the attribute comprises a transaction type conforms to the authorization level.
6. (Currently Amended) The method of claim 1, further comprising assigning, by the provider computing system, an employee to complete the lockbox transaction order based on the transaction amount attribute.
7. (Original) The method of claim 1, further comprising causing, by the provider computing system, a camera to record activity associated with the physical lockbox upon authentication.
8. (Currently Amended) A provider computing system structured to perform operations, the operations comprising: receiving a credential and a lockbox transaction order associated with an account of a_[[the ]]provider from a user device, the lockbox transaction order including a requested transaction and a desired transaction location; determining an authorization level of the user device based on the credential, the authorization level being one of multiple tiered authorization levels, each tiered authorization level of the multiple tiered authorization levels corresponding to a threshold transaction dollar amount for transactions that the user device is authorized to perform; verifying that a transaction amount an attribute of the lockbox transaction order conforms to the authorization level; determining that the requested transaction cannot be completed at the desired transaction location; determining a physical lockbox from a plurality of physical lockboxes as an alternative lockbox transaction location; transmitting an indication to a user device indicating that the requested transaction can be completed at the alternative lockbox transaction location; [[and]] authenticating a user at the physical lockbox; and unlocking a door of the physical lockbox based on, wherein authenticating the user at the physical lockbox enables the physical lockbox to unlock and become accessible by the user.
9. (Canceled)
10. (Canceled)
11. (Currently Amended) The provider computing system of claim 8, the operations further comprising verifying that a wherein the attribute comprises a lockbox location conforms to the authorization level.
12. (Currently Amended) The provider computing system of claim 8, the operations further comprising verifying that a wherein the attribute comprises a transaction type conforms to the authorization level.
13. (Currently Amended) The provider computing system of claim 8, the operations further comprising: assigning an employee to complete the lockbox transaction order based on the transaction amount attribute.
14. (Original) The provider computing system of claim 8, the operations further comprising: causing a camera to record activity associated with the physical lockbox upon authentication.
15. (Currently Amended) One or more non-transitory computer-readable media comprising instructions stored thereon that, when executed by a processing circuit of a provider computing system, cause the processing circuit to: receive a credential and a lockbox transaction order associated with an account of a_[[the ]]provider from a user device, the lockbox transaction order including a requested transaction and a desired transaction location; determine an authorization level of the user device based on the credential, the authorization level being one of multiple tiered authorization levels, each tiered authorization level of the multiple tiered authorization levels corresponding to a threshold transaction dollar amount for transactions that the user device is authorized to perform; verify that a transaction amount an attribute of the lockbox transaction order conforms to the authorization level; determine that the requested transaction cannot be completed at the desired transaction location; determine a physical lockbox from a plurality of physical lockboxes as an alternative lockbox transaction location; transmit an indication to a user device indicating that the requested transaction can be completed at the alternative lockbox transaction location; [[and]] authenticate a user at the physical lockbox; and unlock a door of the physical lockbox based on, wherein authenticating the user at the physical lockbox enables the physical lockbox to unlock and become accessible by the user.
16. (Cancelled)
17. (Currently Amended) The media of claim 15, wherein instructions further cause the processing circuit to verify that the attribute comprises at least one of a transaction type conforms to the authorization level and a transaction amount.
18. (Currently Amended) The media of claim 15, wherein instructions further cause the processing circuit to verify that the attribute comprises a lockbox location conforms to the authorization level.
19. (Currently Amended) The media of claim 15, wherein the instructions, when executed, further cause the processing circuit to: assign an employee to complete the lockbox transaction order based on the transaction amount attribute.
20. (Previously Presented) The media of claim 15, wherein the instructions, when executed, further cause the processing circuit to: cause a camera to record activity associated with the physical lockbox upon authentication.
1. (Currently Amended) A method comprising: receiving, by a provider computing system of a provider, a lockbox transaction order from a user device associated with an account holder of the provider, the lockbox transaction order including a requested transaction and a desired transaction location; validating, by the provider computing system in real-time, whether the requested transaction can be completed at the desired transaction location; locating, by the provider computing system based on determining that the lockbox transaction order cannot be completed at the desired transaction location, a physical lockbox associated with the provider from a plurality of physical lockboxes at an alternative lockbox transaction location, the physical lockbox being available for the requested transaction; transmitting, by the provider computing system, an indication to the user device indicating that the requested transaction can be completed at the alternative lockbox transaction location; transmitting, by the provider computing system, a lock request to the alternative lockbox transaction location, the lock request including the requested transaction and an identifier associated with the physical lockbox, wherein the physical lockbox associated with the identifier is prepared according to the requested transaction; and authenticating, by the provider computing system, the account holder at the physical lockbox associated with the user device, wherein authenticating the account holder at the physical lockbox enables the physical lockbox to unlock and become accessible by the account holder.
2. (Currently Amended) The method of claim 1, wherein the user device is a first user device, the account holder is a first account holder, the lockbox transaction order is a first lockbox transaction order, the method further comprising: receiving, by the provider computing system of the provider, a second lockbox transaction order from a second user device associated with a second account holder of the provider; determining, by the provider computing system, a second authorization level of at least one of the second user device and the second lockbox transaction order, the second authorization level being different from a first authorization level associated with at least one of the first user device and the first account holder; verifying, by the provider computing system, that an attribute of the second lockbox transaction order conforms to the second authorization level; and authenticating, by the provider computing system, the at least one of the second user device and the second account holder at the physical lockbox.
3. (Original) The method of claim 2, wherein the attribute comprises a transaction amount threshold.
4. (Original) The method of claim 2, wherein the attribute comprises a lockbox location.
5. (Original) The method of claim 2, wherein the attribute comprises a transaction type.
6. (Currently Amended) The method of claim 2, further comprising assigning, by the provider computing system, an employee to complete the second lockbox transaction order based on the attribute.
7. (Original) The method of claim 1, further comprising causing, by the provider computing system, a camera to record activity associated with the physical lockbox upon authentication.
8. (Currently Amended) A provider computing system associated with a provider of financial services, the system structured to perform operations comprising: receive a lockbox transaction order from a user device associated with an account holder of the provider, the lockbox transaction order including a requested transaction and a desired transaction location; validate, in real-time, whether the requested transaction can be completed at the desired transaction location; locate, based on determining that the lockbox transaction order cannot be completed at the desired transaction location, a physical lockbox associated with the provider from a plurality of physical lockboxes at an alternative lockbox transaction location, the physical lockbox being available for the requested transaction; transmit an indication to the user device indicating that the requested transaction can be completed at the alternative lockbox transaction location; transmit a lock request to the alternative lockbox transaction location, the lock request including the requested transaction and an identifier associated with the physical lockbox, wherein the physical lockbox associated with the identifier is prepared according to the requested transaction; and authenticate the account holder at the physical lockbox associated with the user device, wherein authenticating the account holder at the physical lockbox enables the physical lockbox to unlock and become accessible by the account holder.
9. (Currently Amended) The provider computing system of claim 8, wherein the user device is a first user device, the account holder is a first account holder, the lockbox transaction order is a first lockbox transaction order, the operations further comprising: receive a second lockbox transaction order from a second user device associated with a second account holder of the provider; determine a second authorization level of at least one of the second user device and the second lockbox transaction order, the second authorization level being different from a first authorization level associated with at least one of the first user device and the first account holder; verify that an attribute of the second lockbox transaction order conforms to the second authorization level; and authenticate the at least one of the second user device and the second account holder at the physical lockbox.
10. (Original) The provider computing system of claim 9, wherein the attribute comprises a transaction amount threshold.
11. (Original) The provider computing system of claim 9, wherein the attribute comprises a lockbox location.
12. (Original) The provider computing system of claim 9, wherein the attribute comprises a transaction type.
13. (Currently Amended) The provider computing system of claim 9, the operations further comprising: assign employee to complete the second lockbox transaction order based on the attribute.
14. (Original) The provider computing system of claim 8, the operations further comprising: cause a camera to record activity associated with the physical lockbox upon authentication.
15. (Currently Amended) One or more non-transitory computer-readable media comprising instructions stored thereon, the instructions, when executed by at least one processor of a provider computing system associated with a provider of financial services, structured to perform operations comprising: receive a lockbox transaction order from a user device associated with an account holder of the provider, the lockbox transaction order including a requested transaction and a desired transaction location; validate, in real-time, whether the requested transaction can be completed at the desired transaction location; locate, based on determining that the lockbox transaction order cannot be completed at the desired transaction location, a physical lockbox associated with the provider from a plurality of physical lockboxes at an alternative lockbox transaction location, the physical lockbox being available for the requested transaction; transmit an indication to the user device indicating that the requested transaction can be completed at the alternative lockbox transaction location; transmit a lock request to the desired transaction location, the lock request including the requested transaction and an identifier associated with the physical lockbox, wherein the physical lockbox associated with the identifier is prepared according to the requested transaction; and authenticate the account holder at the physical lockbox associated with the user device, wherein authenticating the account holder at the physical lockbox enables the physical lockbox to unlock and become accessible by the account holder.
16. (Currently Amended) The media of claim 15, wherein the user device is a first user device, the account holder is a first account holder, the lockbox transaction order is a first lockbox transaction order, the operations further comprising: receive a second lockbox transaction order from a second user device associated with a second account holder of the provider; determine a second authorization level of at least one of the second user device and the second lockbox transaction order, the second authorization level being different from a first authorization level associated with at least one of the first user device and the first account holder; verify that an attribute of the second lockbox transaction order conforms to the second authorization level; and authenticate the at least one of the second user device and the second account holder at the physical lockbox.
17. (Original) The media of claim 16, wherein the attribute comprises at least one of a transaction type and a transaction amount threshold.
18. (Original) The media of claim 16, wherein the attribute comprises a lockbox location.
19. (Currently Amended) The media of claim 16, the operations further comprising: assign employee to complete the second lockbox transaction order based on the attribute.
20. (Original) The media of claim 16, the operations further comprising: cause a camera to record activity associated with the physical lockbox upon authentication.
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 8, 11-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to software per se.
Claim 8 recites elements for a provider computing system structured to perform operations, the operations comprising: receiving a credential and a lockbox transaction order associated with an account of a on comprising the steps of: determining authorization level. These recited elements are broadly interpreted to correspond to software components (not tangible hardware components) without showing an ability to realize functionality of the recited elements (i.e. functional descriptive material per se) and therefore are rendered inoperative and hence lacking any utility. There is no hardware structure positively recited in the claims. Hence the claim is drawn to computer programs per se. A claim of software per se is ineligible subject matter under 35 U.S.C. 101 because it does not fall within one of the statutory categories (See Gottschalk v. Benson, 409 U.S. at 72, 175 USPQ at 676-77). Claim 8 is a system claim but does not recite any hardware components or structures. Dependent claims 11-14 are rejected by similar reasoning and also by virtue of dependency on a rejected claim.
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 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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.
Claims 1, 4-5, 8, 11-12, 15, 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Hanson (US 2016/0014552 A1) in view of Lloyd et al. (US 2017/0091764 A1) in further view of Burdick (US 9,558,636 B1).
Regarding claims 1, 8, and 15, Hanson discloses: A method comprising:
determining, by the provider computing system, a physical lockbox (see at least par. [0083] “. . . The notification transmitted to the user may include a code, password, or the like, to access the secure location or container. For instance, the item may be held in a secure lockbox with a keypad entry system”) from a plurality of physical lockboxes as an alternative lockbox transaction location (Hanson, par. [0088] & see at least par. [0095] “. . . in some arrangements, the personal computing device may be configured to determine the location of the beacon, and thus, the location of the personal computing device, based on the received signal (e.g. by matching a signal that may be unique to the beacon with a stored list of beacons and associated locations . . . ) The system determines a lockbox (or alternative) among a plurality of locations;
transmitting, by the provider computing system, an indication to a user device indicating that the requested transaction can be completed at the alternative lockbox transaction location (Hanson, see at least par. [0061] “. . . In some examples, identifying the one or more transactions may include identifying one or more transactions that have been initiated by the user or for completion by the user. The identified transactions may also be sorted by location, such that a user may have initiated multiple transactions for completion at one or more different banking centers. Accordingly, in some examples, the system may identify initiated transactions designated for completion or processing at the location at which the personal computing device of the user detected the location beacon signal.”) The provider system transmits a signal to a user device letting the user know that the transaction can be completed at the location;
and authenticating, by the provider computing system, a user at the physical lockbox, (Hanson, see at least par. [0083] “. . . The notification transmitted to the user may include a code, password, or the like, to access the secure location or container. For instance, the item may be held in a secure lockbox with a keypad entry system. The user may enter the code 862 received in the notification into the keypad and the lockbox may open, permitting the user to remove the item . . .”).
and unlocking, by the provider computing system, a door of the physical lockbox based on authenticating the user at the physical lockbox(Hanson, see at least par. [0083] “. . . The notification transmitted to the user may include a code, password, or the like, to access the secure location or container. For instance, the item may be held in a secure lockbox with a keypad entry system. The user may enter the code 862 received in the notification into the keypad and the lockbox may open, permitting the user to remove the item . . .”)..
Hanson does not disclose the following; however, Lloyd teaches:
receiving, by a provider computing system of a provider, a credential and a lockbox transaction order associated with an account of the provider from a user device, the lockbox transaction order including a requested transaction and a desired transaction location (Lloyd, see at least par. [0093] “. . . For example, the system may determine the transaction location based on the location of the point of transaction terminal at which the user executes a transaction. In this regard the merchant may have multiple locations, each location having one or more transaction terminals, therefore, the system may compare a received transaction terminal identifier against a merchant database of point of transaction terminals and identify the merchant location. The database may be searchable and retrievable database comprising transaction terminal identifiers and the corresponding merchant facility location, type of transactions allowed (for example, credit card transactions, debit card transactions, digital wallet payments, token or payment credentials, card providers accepted and the like) and other parameters . . .”) the lockbox is determined based on location and identifier;
determining, by the provider computing system, an authorization level of the user device based on the credential, the authorization level being one of multiple tiered authorization levels, each tiered authorization level of the multiple tiered authorization levels corresponding to a threshold transaction dollar amount for transactions that the user device is authorized to perform (Lloyd et al. (US 2017/0091764 A1), see at least par. [0117] “ Next, as illustrated by block 940, the system determines a desired level of authorization associated with the transaction, based on at least the transaction information. In this regard, the system may analyze the transaction information, the user profile comprising customer information (for example, contact information) and financial information of the user and/or the transaction history of the user to determine the desired level of authorization required to permit and/or process the transaction, based on one or more factors, singularly or in combination. For example, the system may determine that the transaction amount is above a predetermined threshold value, and hence determine a higher level of desired authorization . . .”) The cited portion discloses multi-tiered authorization level;
verifying, by the provider computing system, that a transaction amount the lockbox transaction order conforms to the authorization level (Lloyd, par. [0117] “. . . For example, the system may determine that the transaction amount is above a predetermined threshold value, and hence determine a higher level of desired authorization . . .”)
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of multi-tiered authorization for device using lockbox as taught by Lloyd with the invention disclosed by Hanson to determine the validity of one or more transactions (abstract). Therefore, the combination is obvious.
Hanson in view of Lloyd, however, does not disclose the following. Burdick teaches:
determining, by the provider computing system, that the requested transaction cannot be completed at the desired transaction location (Burdick, Col. 1 ln 49-67) Interpretation: the ATM at the first location has insufficient cash, and hence, the user cannot complete the transaction at the first location. The system will provide an alternate location to the user for transaction.
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of determining the first location of lockbox does not work as taught by Burdick with the invention disclosed by Hanson in view of Lloyd to make it convenient for users to perform a pre-staged transaction at an alternated location (Summary). Therefore, the combination is obvious.
Dependent claim 17 is disclosed: Hanson in view of Lloyd in further view of Burdick teaches: a method of claim 1. Hanson, further teaches: wherein the attribute comprises a transaction amount (Hanson, see at least par. [0050] “. . . The notification may include balance information, amount of the transaction, date of the transaction, and the like. . . .”) and a transaction type (Hanson, par. [0043]) the cited portion discloses a type of transaction.
Dependent claims 4, 11 and 18 are grouped together. Claim 1, for instance, is disclosed: Hanson in view of Lloyd in further view of Burdick teaches: a method of claim 1. Hanson, further teaches: wherein the attribute comprises a lockbox location (Hanson, par. [0088] & see at least par. [0095] “. . . in some arrangements, the personal computing device may be configured to determine the location of the beacon, and thus, the location of the personal computing device, based on the received signal (e.g. by matching a signal that may be unique to the beacon with a stored list of beacons and associated locations . . . “).
Dependent claims 5 and 12 are grouped together. Claim 1, for instance, is disclosed: Hanson in view of Lloyd in further view of Burdick teaches: a method of claim 1. Hanson, further teaches: wherein the attribute comprises a transaction type (Hanson, par. [0043]) the cited portion discloses a type of transaction.
Claims 6, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hanson (US 2016/0014552 A1) in view of Lloyd et al. (US 2017/0091764 A1) in further view of Burdick (US 9,558,636 B1) in further view of Jackson (US 8,793,776).
Dependent claims 6, 13 and 19 are grouped together. Claim 1, for instance, is disclosed: Hanson in view of Lloyd in further view of Burdick teaches: a method of claim 1. However, Jackson, further teaches: further comprising assigning, by the provider computing system, an employee to complete the lockbox transaction order based on the attribute (Col. 12 ln 47-53, “. . . In this example the third-party application 118 includes the ATM or the point-of-sale financial transaction, but instead of logging-in to a website, the third-party application 118 requests authentication from the authentication application 103 in response to the user making a purchase or a withdrawal and providing user information to the ATM, a bank teller, a sales associate, etc. . . .”).
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of assigning to a bank employee as taught by Jackson with the invention disclosed by Hanson in view of Lloyd in further view of Burdick to make it convenient for users to perform a pre-staged transaction. Therefore, the combination is obvious.
Claims 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hanson (US 2016/0014552 A1) in view of Lloyd et al. (US 2017/0091764 A1) in further view of Burdick (US 9,558,636 B1) in further view of Batchu Krishnaiah et al. (US 2017/0169128 A1).
Dependent claims 7, 14 and 20 are grouped together. Claim 1, for instance, is disclosed: Hanson in view of Lloyd in further view of Burdick teaches: a method of claim 1. However, Batchu, further teaches: further comprising causing, by the provider computing system, a camera to record activity associated with the physical lockbox upon authentication(Batchu Krishnaiah et al. (US 2017/0169128 A1), see at least par. [0191] “In one embodiment, multiple media recorders, for example, CCTV cameras (to capture various views of a location) could have their clocks synchronized with one or more external systems in the vicinity programmed to perform certain transactions or sense an event, such as ATM-cash withdrawals . . .”).
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of using a camera as taught by Batchu with the invention disclosed by Hanson in view of Lloyd in further view of Burdick to better enhance the security at the kiosk. Therefore, the combination is obvious.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TOAN DUC BUI whose telephone number is (571)272-0833. The examiner can normally be reached M-F 8-5:00 PM.
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, Mike W. Anderson can be reached at (571) 270-0508. 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.
/TOAN DUC BUI/Examiner, Art Unit 3693
/ELIZABETH H ROSEN/Primary Examiner, Art Unit 3693
Prosecution Insights