DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant filed a preliminary amendment on December 9, 2024.
Applicant amended claim 1.
Applicant added claims 2-17.
Claims 1-17 are pending and have been examined.
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-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite the abstract idea which may be summarized as processing a check cashing transaction.
Step 1 Analysis
Applicants claims are directed to a process (claims 7-12), machine (claims 1-6), and manufacture/product (claims 13-17).
Step 2A, Prong 1 Analysis
Claims 1, 7 and 13 recite the abstract idea/limitations of:
generating personalized… documents,
verifying user identity for financial services transaction,
and autonomously authorizing transactions,
receiving user identification data and check information,
the check information including an account number, a routing number, and a check cashing amount extracted from an image of a check;
transmitting an approval notification,
the notification including a machine-readable code;
storing the check information with the machine-readable code;
scanning the machine-readable code transmitted in the notification and displayed;
retrieving the check information associated with the user identification data, including the check cashing amount; and
initiating automatic processing of a check cashing transaction based on the check information.
As drafted these limitations are a process that falls within the “Certain Methods of Organizing Human Activity grouping of abstract ideas; but for the recitation of generic computer components. If a claim limitation, under its broadest reasonable interpretation, recites performance of the limitation as commercial/legal interactions, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. By reciting/claiming a certain method of organizing human activity, Applicant’s claims recite an abstract idea.
Step 2A, Prong 2 Analysis
This judicial exception is not integrated into a practical application because the claims only recites system components for implementing the abstract idea and extra-solution activity. The claims recite the additional limitations of a user identification module, a broker computing system, a network, an application, a mobile electronic device, electronic documents, a database, a machine-readable code reader, a computing device, a user check-in module, a non-transitory machine readable medium, instructions, a processing device; and they are recited at a high level of generality. These system components amount to no more than mere instructions to apply the exception using a generic computer. These limitations generally link the use of the judicial exception to a technological environment and are not indicative of integration into a practical application. The limitations of:
receiving user identification data and check information,
transmitting an approval notification,
storing the check information with the machine-readable code;
retrieving the check information associated with the user identification data, including the check cashing amount; and
as drafted are insignificant extra-solution activity. These steps are mere data gathering and storing of information and do not qualify as a practical application of the judicial exception. See MPEP 2106.05(g). These additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims as a whole do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea without a practical application.
Step 2B Analysis
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a user identification module, a broker computing system, a network, an application, a mobile electronic device, electronic documents, a database, a machine-readable code reader, a computing device, a user check-in module, a non-transitory machine readable medium, instructions, a processing device; amount to no more than mere components to implement the judicial exception using a generic computer components. For the same reason these elements are not sufficient to provide an inventive concept. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The limitations of:
receiving user identification data and check information,
transmitting an approval notification,
storing the check information with the machine-readable code;
retrieving the check information associated with the user identification data, including the check cashing amount; and
as drafted are insignificant extra-solution activity. These steps are mere data gathering and storing and do not qualify as significantly more than the judicial exception as they are well-understood, routine, and conventional activity when clamed in a merely generic manner (as it is here). See MPEP 2106.05(g). See Applicant’s specification paragraphs [0036-0048] about implementation of the abstract idea using general purpose or special purpose computing devices; and MPEP 2106.05(f) where applying a computer as a tool is not indicative of significantly more. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Thus Applicant’s claims are not patent eligible.
Dependent Claims Analysis
As for dependent claims 2, 5, 6, 8, 11, 12, 14, and 17 these claims recite limitations that further define the same abstract idea noted in independent claims 1, 7 and 13. Therefore, claims 2, 5, 6, 8, 11, 12, 14, and 17 are considered ineligible subject matter for the reasons given above.
As for dependent claims 3, 4, 9, 10, 15, and 16 these claims recite limitations that further define the same abstract idea noted in independent claims 1, 7 and 13. In addition, the recite the additional elements of
receives the user identification data;
receives the check information;
receive the user identification data associated with the machine-readable code;
This is considered insignificant extra-solution activity, because as drafted the limitations are mere data gathering and storing of information. These limitations do not qualify as a practical application of the judicial exception or significantly more. See MPEP 2106.05(g). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself. Therefore, claims 3, 4, 9, 10, 15, and 16 are considered ineligible subject matter.
Thus, the dependent claims 2-6, 8-12, and 14-17 are not patent-eligible either.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 USC 112(a) or 35 USC 112 first paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-17 are rejected under 35 U.S.C. 103 as being unpatentable over Liberty, US Patent Application Publication No., 2014/0054369 in view of Lin, US P Patent Application Publication No., 20100078471..
Regarding claims 1, 7, and 13;
(Claim 1) A system for generating personalized electronic documents, verifying user identity for financial services transactions, and autonomously authorizing transactions, the system comprising:
(i) a broker computing system configured to communicate with a mobile electronic device over a network and execute a user identification module that when executed:
See Liberty [0035] The telephone, smartphone, tablet or other computing system that interacts with the mobile payment system typically includes a camera, image sensor, image scanner or other hardware that allows a user to scan or capture an image. For instance, as shown in environment 200 of FIG. 2, computer system 201 may include a camera 202. The computer system 201 may include a telephone, smartphone, tablet or other type of mobile computing system. The user of the phone 201 (i.e. user/customer 205) may thus point the camera 202 or other hardware at an object such as a can of soup and either take a picture of the object, or allow software to scan the image using the camera. Software on the phone or tablet 201 then performs a local search or consults a database (e.g. over the internet) to retrieve information related to that item or product including coupons or price discounts.
[0036] In addition to receiving product information and discounts, the user 205 may also use their phone 201 or other device to pay for the items they wish to buy. In one embodiment, a customer may be at a retail location 225 shopping for various items 228. Once the customer 205 has finished shopping, he or she proceeds to the checkout area. The checkout area includes a point of sale 226 with a checkout register 227 that typically accepts cash, debit or credit cards as payment. The checkout register 227 may also be configured to allow users to pay using a mobile wallet. Accordingly, the customer may use a mobile wallet application 210 on a smartphone (e.g. 201), tablet or other computer system to pay for the items.
(a) receives from an application executing on the mobile electronic device and via the network, user identification data and [payment] information;
See Liberty [0034] The components depicted in FIG. 1 can interoperate to provide a number of financial and other services including but not limited to… depositing funds in a mobile wallet, withdrawing funds from a mobile wallet, paying bills from a mobile wallet, topping up a prepaid mobile account through a mobile wallet, transferring funds through a mobile wallet (nationally or internationally), making in-store purchases using a mobile wallet, and various other tasks as described herein below.
[0047] In Method 300, a mobile computer system receives input indicating that a user has initiated a payment for one or more items sold by a provider of goods or services (310).
[0005] In another embodiment, a computer system processes a payment using a debit network selected according to information embedded in a QR code. The computer system receives a QR code that includes portions of embedded payment information. The embedded payment information includes at least the following: a total payment amount that is to be paid by a user, debit account information for the user, and an indication of which debit network is to be used to process the payment. The computer system determines which debit network is to be used to process the payment based on the indication provided in the embedded payment information in the received QR code, sends the payment amount and the user's debit account information to the determined debit network and, after the payment has been processed, receives an indication that the payment was processed by the determined debit network.
[0019] Transmission media can include a network and/or data links which can be used to carry program code in the form of computer-executable instructions or data structures, and which can be accessed by a general-purpose or special-purpose computer system. A "network" is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer system, the computer system may view the connection as transmission media. Combinations of the above should also be included within the scope of computer-readable media.
(b) transmits, via the network, an approval notification to the mobile electronic device, the notification including a machine-readable code;
See Liberty [0042] “Thus, in this manner, based on customer information… the user's mobile wallet application may determine which debit network is to be used to route the user's transaction. Once it has been determined which debit network is going to be used, a QR code may be generated by module with the debit network selection embedded therein…. The QR code has each of the necessary transaction details embedded therein, and also indicates on which debit network the transaction is to take place. In some cases, the QR code may link directly to the selected debit network (as indicated by the dotted arrow lines to debit networks 230A and 230B). In such cases, the user may route their payment for merchandise directly to the debit network using their mobile wallet.”
See also [0049]
(c) stores the [payment] information with the machine-readable code in a database of the broker computing system; and
See Liberty [0031] Database 108 is configured to manage customer accounts (e.g., storing customer accounts and properties), manage company accounts (e.g., storing company accounts and properties), manage transaction histories (e.g., storing financial transaction details), store customer profiles, storing dictionaries used by the mobile wallet platform, such as, for example, countries, currencies, etc., and managing money containers. Rules engine 109 is configured to gather financial transaction statistics and uses the statistics to provide transaction properties, such as, for example, fees and bonuses. Rules engine 109 is also configured to enforce business constraints, such as, for example, transactions and platform license constraints.
[0022] Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations… The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. As such, in a distributed system environment, a computer system may include a plurality of constituent computer systems. In a distributed system environment, program modules may be located in both local and remote memory storage devices.
(ii) a computing device located in proximity to a machine--readable code reader, the computing device configured to execute a user check-in module that when executed:
See Liberty [0043] “The QR code is a secure, tokenized QR code that fully represents the details of the user's purchase, along with an indication of which debit network has been specified for that transaction. This QR code is scannable by the checkout register and, as a result of the scan, provides a debit network selection (e.g. debit network 230A, 230B or some other debit network) through which the transaction is to be processed.”
(a) scans, via the machine--readable code reader, the machine- readable code transmitted in the notification and displayed on the mobile electronic device;
See Liberty [0043] “The QR code is a secure, tokenized QR code that fully represents the details of the user's purchase, along with an indication of which debit network has been specified for that transaction. This QR code is scannable by the checkout register and, as a result of the scan, provides a debit network selection (e.g. debit network 230A, 230B or some other debit network) through which the transaction is to be processed.”
(b) retrieves the check information associated with the user identification data, including the check cashing amount from the database of the broker computing system; and
See Liberty [0052]” As such, the payment processing system may receive the QR code, and route the debit transaction to the proper debit network (e.g. 230A or 230B)… Still further, the user may send the QR code directly to the specified debit network, which will then decrypt the embedded information and process the debit transaction.”
[0055] “Method includes receiving a QR code with one or more portions of embedded payment information, where the embedded payment information includes a total payment amount that is to be paid by a user, debit account information for the user, and/or an indication of which debit network is to be used to process the payment.”
See also Figure 4
(c) initiates automatic processing of a check cashing transaction based on the check information.
See Liberty [0052]” decrypt the embedded information and process the debit transaction.”
[0055] “debit network is to be used to process the payment.”
See also Figure 4
Liberty does not teach:
(a) receives from an application executing on the mobile electronic device and via the network, user identification data and check information, wherein the check information includes-an account number, a routing number, and a check cashing amount extracted from an image of a check;
Lin teaches
(a) receives from an application executing on the mobile electronic device and via the network, user identification data and check information, wherein the check information includes-an account number, a routing number, and a check cashing amount extracted from an image of a check;
See Lin [0290] “Once the image is received by the payee device, the check image may be processed… to extract certain information from the check image, such as the name or identity of the payor, a routing number corresponding to the payor's banking provider, the account number corresponding to the payor's bank account, as well as an identification number corresponding to the payor's check. … Thereafter, the information extracted from the check image 974, the selected crediting account, as well as the amount of the requested payment…”
Figure 25A
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the payment processing of the primary reference, the ability to process a check as taught by Lin since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes processing checks increases the useability of the system.
Regarding claims 2, 8, and 14;
Liberty does not teach the claim.
Lin teaches:
(Claim 2) The system of claim 1, wherein the broker computing system is further configured to:
validate the check using the check information extracted from the image of the check.
See Lin [0291] The financial server 380 may initiate one or more of the authorization actions discussed above, which may include transmitting the payor's check information, such as the check information extracted during the image processing step 976, to a check verification service, depicted here by the reference numeral 984, by way of the network 420. As will be appreciated, a check verification service may perform one or more of various functions relating to the validation or verification of checks. For example, a check verification service may offer this service to banking providers, vendors, and retailers, by way of a subscription based service, which may be accessed by either using a telephone, or by one or more of the networks generally described above. In some instances, the check verification services described herein may be offered or provided by the banking provider itself. In general, check verification services, such as the check verification service 984, may perform several functions, which may include verifying a payor's identity, as well as determining whether the payor has a history of providing bounced checks. Based on these records, the check verification service 984, may determine whether or not the check information 982 provided may be verified and thus authorized to satisfy the requested payment. This verification process is represented here by the reference numeral 986.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the payment processing of the primary reference, the ability to validate a check as taught by Lin since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes processing checks increases the useability of the system.
Regarding claims 3, 9, and 15;
(Claim 3) The system of claim 1, further comprising:
a server configured to execute a personalized order generation module that when executed:
(a) receives the user identification data over the network from the application executing on the mobile electronic device associated with a user; and
See Liberty See Liberty [0034], “provide a number of financial and other services including enrolling a customer for a mobile wallet, adding a stored value account (either hosted by a mobile wallet platform or a third party), adding a bank or credit union account to a mobile wallet, adding a debit or credit card account to a mobile wallet”
[0031] “Database 108 is configured to manage customer accounts (e.g., storing customer accounts and properties), manage company accounts (e.g., storing company accounts and properties)”
(b) receives the check information, wherein the check information indicates the check is payable to the user.
See Liberty [0034] The components depicted in FIG. 1 can interoperate to provide a number of financial and other services including but not limited to… depositing funds in a mobile wallet, withdrawing funds from a mobile wallet, paying bills from a mobile wallet, topping up a prepaid mobile account through a mobile wallet, transferring funds through a mobile wallet (nationally or internationally), making in-store purchases using a mobile wallet, and various other tasks as described herein below.
[0047] In Method 300, a mobile computer system receives input indicating that a user has initiated a payment for one or more items sold by a provider of goods or services (310).
[0005] In another embodiment, a computer system processes a payment using a debit network selected according to information embedded in a QR code. The computer system receives a QR code that includes portions of embedded payment information. The embedded payment information includes at least the following: a total payment amount that is to be paid by a user, debit account information for the user, and an indication of which debit network is to be used to process the payment. The computer system determines which debit network is to be used to process the payment based on the indication provided in the embedded payment information in the received QR code, sends the payment amount and the user's debit account information to the determined debit network and, after the payment has been processed, receives an indication that the payment was processed by the determined debit network.
[0019] Transmission media can include a network and/or data links which can be used to carry program code in the form of computer-executable instructions or data structures, and which can be accessed by a general-purpose or special-purpose computer system. A "network" is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer system, the computer system may view the connection as transmission media. Combinations of the above should also be included within the scope of computer-readable media.
Regarding claims 4, 10, and 16;
(Claim ) The system of claim 1, wherein the computing device is further configured to:
receive the user identification data associated with the machine-readable code from the user identification module.
See Liberty [0052]” As such, the payment processing system may receive the QR code, and route the debit transaction to the proper debit network (e.g. 230A or 230B)… Still further, the user may send the QR code directly to the specified debit network, which will then decrypt the embedded information and process the debit transaction.”
[0055] “Method includes receiving a QR code with one or more portions of embedded payment information, where the embedded payment information includes a total payment amount that is to be paid by a user, debit account information for the user, and/or an indication of which debit network is to be used to process the payment.”
See also Figure 4
Regarding claims 5, 11, and 17;
Liberty does not teach the claim.
Lin teaches:
(Claim 5) The system of claim 1, wherein the machine-readable code is linked to a validation of the check information indicating that a user is eligible to receive cash according to the check cashing amount.
See Lin [0291] The financial server 380 may initiate one or more of the authorization actions discussed above, which may include transmitting the payor's check information, such as the check information extracted during the image processing step 976, to a check verification service, depicted here by the reference numeral 984, by way of the network 420. As will be appreciated, a check verification service may perform one or more of various functions relating to the validation or verification of checks. For example, a check verification service may offer this service to banking providers, vendors, and retailers, by way of a subscription based based service, which may be accessed by either using a telephone, or by one or more of the networks generally described above. In some instances, the check verification services described herein may be offered or provided by the banking provider itself. In general, check verification services, such as the check verification service 984, may perform several functions, which may include verifying a payor's identity, as well as determining whether the payor has a history of providing bounced checks. Based on these records, the check verification service 984, may determine whether or not the check information 982 provided may be verified and thus authorized to satisfy the requested payment. This verification process is represented here by the reference numeral 986.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the payment processing of the primary reference, the ability to validate a check as taught by Lin since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes processing checks increases the useability of the system.
Regarding claims 6 and 12;
Liberty does not teach the claim.
Lin teaches:
(Claim 6) The system of claim 1, wherein the broker computing system is further configured to:
validate the check information with an issuer, wherein the issuer is a drafter of the check.
See Lin [0291] The financial server 380 may initiate one or more of the authorization actions discussed above, which may include transmitting the payor's check information, such as the check information extracted during the image processing step 976, to a check verification service, depicted here by the reference numeral 984, by way of the network 420. As will be appreciated, a check verification service may perform one or more of various functions relating to the validation or verification of checks. For example, a check verification service may offer this service to banking providers, vendors, and retailers, by way of a subscription based based service, which may be accessed by either using a telephone, or by one or more of the networks generally described above. In some instances, the check verification services described herein may be offered or provided by the banking provider itself. In general, check verification services, such as the check verification service 984, may perform several functions, which may include verifying a payor's identity, as well as determining whether the payor has a history of providing bounced checks. Based on these records, the check verification service 984, may determine whether or not the check information 982 provided may be verified and thus authorized to satisfy the requested payment. This verification process is represented here by the reference numeral 986.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the payment processing of the primary reference, the ability to validate a check as taught by Lin since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes processing checks increases the useability of the system.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 USC 112(a) or 35 USC 112 first paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-17 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,159,268. Although the claims at issue are not identical, they are not patentably distinct from each other because the claim sets are obvious variations of each other. Claims 1, 7, and 13 of the current application correspond to claims 1, 8, and 15 of the ‘268 patent. The claims in the ‘268 are narrower than the present claims. The ‘268 claims recite the process of capturing an image of a check and extracting check information from that image as well as validating the check. It is an obvious modification to not perform these actions; the present claims merely recite having the underlying information (with no limitations as to how that check information is obtained) and later recite the validation process. As such the present claims in the application are obvious variations of the patented claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J WARDEN whose telephone number is (571)272-9602. The examiner can normally be reached M-F; 9-6 CDT.
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, Bennett M Sigmond can be reached at 303-297-4411. 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.
/MICHAEL J. WARDEN/
Examiner
Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights