DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, 18/972,603, filed 12/06/2024, is a Continuation of 16/822,615, filed 03/18/2020, now U.S. Patent 12,198,111, wherein 16/822,615 is a Divisional of 13/752,010, filed 01/28/2013, now U.S. Patent 10,643,191, wherein 13/752,010 claims domestic priority from U.S. Provisional Application 61/591,707, filed 01/27/2012.
The effective filing date is before the AIA date of March 16, 2013, and so the application is being examined under the “first inventor to invent” law prior to the AIA .
In the event the determination of the status of the application 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.
Status of the Application
This Non-Final Office Action is in response to Applicant’s communication of 12/06/2024.
Claims 1-20 are pending, of which claims 1 and 11 are independent.
All pending claims have been examined on the merits.
Information Disclosure Statement
The Information Disclosure Statement (IDS) submitted on 12/06/2024 has been considered.
Double Patenting
The non-statutory 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 non-statutory 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 non-statutory 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.
Claims 1 and 11 are rejected on the ground of obviousness-type non-statutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,198,111 B2.
Independent claims 1 and 11 of the present application are obvious variations of independent claims 1 of U.S. Patent No. 12,198,111 B2, respectively. Although the independent claims at issue are not identical, the present claims are obvious variations of the co-pending application(s), due to shared claim language.
“A generic claim cannot be allowed to an applicant if the prior art discloses a species falling within the claimed genus.” The species in that case will anticipate the genus. In re Slayter, 276 F.2d 408, 411, 125 USPQ 345, 347 (CCPA 1960). See also MPEP § 2131.02.
The table below underlines and bolds phrases that are different between a claim in the pending application and its respective claim (in another patent application).
U.S. Application No. 18/972,603
(Present Application)
U.S. Patent No. 12,198,111 B2
1. A method of performing a remote deposit using a mobile device, the method comprising:
1. A method of performing a remote deposit using a mobile device, the method comprising:
storing, on the mobile device of a user, a unique personal account identifier associated with a mobile account of the user;
storing, on a mobile device of a user, a unique personal account identifier associated with a mobile account of the user;
displaying, by the mobile device, a top menu on a graphical user interface (GUI) via a mobile application stored on the mobile device, wherein the mobile application is managed by a processing server;
obtaining, by the mobile device via a mobile application executing on the mobile device, one or more user accounts of the user associated with the unique personal account identifier,
obtaining, by the mobile device via the mobile application, a plurality of user accounts of the user associated with the unique personal account identifier,
wherein the unique personal account identifier is linked with the one or more user accounts to enable payment to any of the one or more user accounts with the mobile device based on the unique personal account identifier;
wherein the unique personal account identifier is linked with the plurality of user accounts to enable payment to any of the plurality of user accounts with the mobile device based on the unique personal account identifier,
wherein at least two of the plurality of user accounts are associated with different financial institutions other than the processing server,
wherein the processing server managing the mobile application on the mobile device supports the remote deposit in real-time with the different financial institutions;
displaying, on the top menu, a plurality of transaction types and the plurality of user accounts of the user associated with the unique personal account identifier;
receiving, by the mobile device via the mobile application, a selection of the remote deposit as a transaction type and a first user account;
receiving, from the user on the top menu of the GUI, a selection of a remote deposit as a transaction type among the plurality of transaction types and a first account among the plurality of user accounts,
wherein the first account is associated with a first financial institution, wherein a set of user accounts are associated with the first financial institution;
communicating in a first message format the selection of the remote deposit and the first user account associated to a processing server;
communicating in a first message format the selection of the remote deposit and the first account associated with the first financial institution to the processing server;
receiving, by the mobile device, a list of one or more sub-accounts associated with the first financial institution based on the unique personal account identifier;
displaying, by the mobile device, a sub-menu on the GUI;
displaying, on the sub-menu, the list of one or more sub-accounts associated with the first financial institution based on the selection of the first account on the top menu of the GUI, wherein the one or more sub-accounts associated with the first financial institution are compatible with the remote deposit as selected transaction type;
receiving a selection from the user of a first sub-account among the one or more sub-accounts managed by the first financial institution, the first sub-account to be used in processing the remote deposit;
communicating the selection of the first sub-account to the processing server;
receiving, by the mobile device from the processing server, a prompt to capture an image of a check based on determining that the first user account is capable of being used in processing the remote deposit;
receiving, by the mobile device from the processing server, a prompt to capture an image of a check based on determining that the first sub-account is capable of being used in processing the remote deposit;
capturing the image of the check on the mobile device;
capturing an image of the check on the mobile device;
verifying, using an image module of the mobile device, that an image quality of the image conforms to a predefined image quality standard for processing the remote deposit;
verifying, using an image module of the mobile device, that an image quality of the image conforms to a predefined image quality standard for processing the remote deposit;
generating an image capture element from the image based on verifying the image quality,
generating an image capture element from the captured image based on verifying the image quality,
wherein the image capture element includes a verification status of the image;
wherein the image capture element includes a verification status of the captured image; and
communicating the captured image and the image capture element in a transaction request message to the processing server, wherein:
the processing server processes the remote deposit in real-time to the first sub-account managed by the first financial institution based on the captured image and the image capture element;
generating, by the mobile device, a transaction request message that incorporates the image and the image capture element; and
the processing server generates an authorization request message in a second message format that includes an identifier for the first sub-account and data retrieved from the captured image; and
transmitting the transaction request message to the processing server, wherein the remote deposit is processed in real-time to the first user account managed by a financial institution based on the image and the image capture element.
the processing server transmits the authorization request message to the first financial institution in real-time.
Moreover, some of the features that appear in the claims of the present application but not in the respective claims of the issued patent do not add any new patentable features.
Moreover, independent claim 11 in the present application is rejected on the same grounds as independent claim 1.
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 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-4, 7-14, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2012/0179609 A1 to Agarwal et al. (“Agarwal”. Filed on Jan. 12, 2011. Published on Jul. 12, 2012) in view of US 9,779,452 B1 to Medina et al. (“Medina”. Eff. Filed on Dec. 30, 2010), and further in view of US 2011/0320357 A1 to Gilson (Filed on April 28, 2011. Published Dec. 29, 2011).
In regards to claim 1,
1. A method of performing a remote deposit using a mobile device, the method comprising:
storing, on the mobile device of a user, a unique personal account identifier associated with a mobile account of the user;
(See Agarwal, para. [0081]: “As represented by the block 605, the user of the remote capture device 601 initiates a mobile deposit application on the mobile phone and is authenticated. For example, in some embodiments, the mobile phone 601 is an iPhone®, and the mobile deposit application is an “app” that executes on the iPhone® for initiating, executing, completing, and/or otherwise facilitating a deposit transaction involving the mobile phone 601. In some embodiments, the mobile banking application requires the user to identify and/or authenticate himself. For example, in some embodiments, the user must provide a username/password, personal identification number (PIN), smart card, token (e.g., USB token, etc.), biometric information, and/or some other information, device, and/or credential to the remote capture device prior to that device granting the user access to the application.”)
obtaining, by the mobile device via a mobile application executing on the mobile device, one or more user accounts of the user associated with the unique personal account identifier, wherein the unique personal account identifier is linked with the one or more user accounts to enable payment to any of the one or more user accounts with the mobile device based on the unique personal account identifier;
(See Agarwal, para. [0026]: “In the United States, the standards for the MICR line are developed and mandated by the American National Standards Institute (ANSI). In many instances, the characters in the MICR line include a routing number and an account number that can be used to identify the payor bank and the payor's bank account at the payor bank from which the funds will be drawn.”)
(See Agarwal, para. [0033]: “As another example, in some embodiments, after the image is captured by the remote capture device, the remote capture device automatically sends and/or posts the captured image to an electronic banking service (e.g., online banking, mobile banking, SMS banking, etc.), where the electronic banking service is associated with an account held by the remote capture device user. As still another example, in some embodiments, after the image is captured by the remote capture device, the remote capture device is configured to automatically store the image in a predetermined folder of images (e.g., a folder entitled “Captured Images”) on the remote capture device.”)
capturing the image of the check on the mobile device;
verifying, using an image module of the mobile device, that an image quality of the image conforms to a predefined image quality standard for processing the remote deposit;
(See Agarwal, para. [0083]: “In addition to displaying the video to the user, the mobile phone 601 automatically adjusts the focus of the digital camera as the mobile phone is being held over the check, as represented by block 630. Also while the user is holding the mobile phone 601 over the check, the mobile phone 601 automatically determines that an image of the check from the video is satisfactory (e.g., for reading information associated with the check), as represented by block 635. Further while the user is holding the mobile phone 601 over the check, and as a result of the determining that the image is satisfactory, the mobile phone 601 automatically captures the image of the check, as represented by block 640.”)
generating an image capture element from the image based on verifying the image quality, wherein the image capture element includes a verification status of the image;
(See Agarwal, para. [0083]: “In addition to displaying the video to the user, the mobile phone 601 automatically adjusts the focus of the digital camera as the mobile phone is being held over the check, as represented by block 630. Also while the user is holding the mobile phone 601 over the check, the mobile phone 601 automatically determines that an image of the check from the video is satisfactory (e.g., for reading information associated with the check), as represented by block 635. Further while the user is holding the mobile phone 601 over the check, and as a result of the determining that the image is satisfactory, the mobile phone 601 automatically captures the image of the check, as represented by block 640. Thereafter, as represented by block 645, the mobile phone 601 sends the captured image of the check to the deposit server 603 for completing the deposit transaction. In some embodiments, the mobile phone and/or the mobile banking application automatically sends the captured image to the deposit server 603, but in other embodiments, the mobile phone and/or the mobile banking application automatically prompt the user to send the captured image. In still other embodiments, the user sends the captured image of the check to the deposit server 603 without being prompted at all.”)
(See Agarwal, para. [0084]: “After receiving the captured image of the check, the deposit server 603 is configured to read the information associated with the check from the image. For example, in some embodiments, the deposit server 603 is configured to read the payee name, the payor financial institution, one or more MICR lines, and/or the written and/or numerical check amount from the image of the check. Thereafter, as represented by block 655, the deposit server 603 is configured to credit an account (e.g., a checking account held by the user, etc.) based at least partially on the check information read from the image. For example, in some embodiments where the check amount shown in the captured image is $65, the deposit server 603 is configured to deposit $65 into a checking account (e.g., that is held by the payee identified in the captured image).”)
generating, by the mobile device, a transaction request message that incorporates the image and the image capture element; and
transmitting the transaction request message to the processing server,
(See Agarwal, para. [0033]: “In addition to the predetermined actions represented by block 140A-C, the remote capture device can be configured to automatically perform one or more other predetermined actions based at least partially on the remote capture device determining that the image is satisfactory, as represented by block 140D. For example, in some embodiments, in addition to automatically capturing the image, the remote capture device is configured to automatically send (and/or prompt the user to send) the captured image to a deposit server for completing a deposit transaction
(See Agarwal, para. [0050]: “Also, it will be understood that the remote capture device having the process flow 100 (and/or the process flows 400 and/or 600) can be configured to automatically analyze and/or capture the front of a deposit item and/or the back of a deposit item. Specifically, in some embodiments, the remote capture device having the process flow 100 is configured to perform the process flow 100 once for the front of a deposit item and then a second time for the back of the deposit item. For example, in some embodiments, the remote capture device is configured to generate an image of the front of a check, determine that the image is satisfactory for reading check information therefrom, automatically capture the image of the front of the check, prompt the user of the remote capture device to flip the check over, generate an image of the back of the check, determine that the image is satisfactory for reading check information therefrom, automatically capture the image of the back of the check, and then send both the image of the front of the check and the image of the back of the check to a deposit server for completing a deposit transaction.”)
Moreover, Agarwal also teaches the following:
(See Agarwal, para. [0013]: “If the remote capture device having the process flow 100 determines that the image is satisfactory, then the remote capture device automatically performs a predetermined action, as represented by block 140 shown in FIG. 2. More specifically, the remote capture device may: (a) automatically capture the image of the deposit item, as represented by block 140A; (b) automatically prompt a user of the remote capture device to capture the image by using the remote capture device (e.g., one or more user inputs of the remote capture device, etc.), as represented by block 140B; (c) automatically indicate to the user that the image is satisfactory, as represented by block 140C; and/or (d) automatically perform one or more other predetermined actions, as represented by block 140D.”)
However, under a conservative interpretation of Agarwal, it could be argued that Agarwal does not explicitly teach the italicized portions below, which are taught by Medina:
receiving, by the mobile device via the mobile application, a selection of the remote deposit as a transaction type and a first user account;
communicating in a first message format the selection of the remote deposit and the first user account associated to a processing server;
(See Medina, col.15, line 62 to col.16, line 9: “In one implementation, if the cash is qualified, the third party agent may verify the calculated cash amount with the user 4173 to confirm the consistency in deposit amount. If the user agrees the deposit amount is correct 4174, the third party agent may send deposit information 4175 to the RDC-Detection platform. For example, the deposit information may include, but not limited to the user's RDC-Detection membership information, deposit account information, deposit amount, and/or the like. In one implementation, the user may be prompted to select an available account for cash deposit in a similar way to that in check deposit as discussed in one implementation in FIG. 3G. In another implementation, if the calculated amount is inconsistent with the user specified amount, the third party agent may cancel the deposit 4180.”)
(See Medina, col.18, lines 41-58: “In one embodiment, in response to the user request, the RDC-Detection platform may initialize a remote deposit component 302. For example, in one implementation, the RDC-Detection may retrieve and load a user interface page for remote deposit. In one embodiment, the RDC-Detection may instruct the user to capture and submit an image or video streaming of the check 305-306, as will be further illustrated in FIGS. 4A-C and 5B-C. In one implementation, the initialized remote deposit component may authenticate the user by prompting the user to login a remote deposit system with a user name and password if the user is an existing member of the RDC-Detection. For example, in one implementation, a remote depositor may access a remote deposit service website, and submit a request by clicking on a “deposit” button on the webpage. The RDC-Detection may then lead to a login webpage, prompting the depositor to login to the remote deposit service with a user name and password.”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the method for automatic cheque image analysis and capture, as taught by Agarwal above, with the method for remote check deposit capture with enhanced image detection, as further taught by Medina above, because Agarwal discloses the check image processing that is performed in the mobile device, while Medina discloses both the check image processing that is performed in the mobile device and also enhanced check image detection.
Moreover, under a conservative interpretation of Agarwal in view of Medina, it could be argued that Agarwal in view of Medina does not explicitly teach the italicized portions below, which are taught by Gilson:
receiving, by the mobile device from the processing server, a prompt to capture an image of a check based on determining that the first user account is capable of being used in processing the remote deposit;
(See Gilson, para. [0052]: “FIG. 3 is a flowchart illustrating an example method 300 for performing real-time, straight-through processing and real-time presentment of a check or other payment item from the perspective of a receiving (payor/endpoint) bank or financial institution (RFI) associated with a check or payment item received at a BOFD. Method 300 may be performed by any suitable system, but for clarity of presentation, the description that follows uses system 100 of FIG. 1 as a particular example for describing the method steps. However, another suitable system or combination of systems may be used to perform method 300 in alternative implementations.
(See Gilson, para. [0053]: “At 305, the RFI receives an image file (and, in some cases, metadata or other information associated with the image file). Generally, the RFI receives the image file from an associated middle tier system associated with a BOFD (or another financial institution from which payment items can be received for processing). The image file is generally received at the RFI's corresponding middle tier system via a network or other communication means over which information is shared or exchanged between the financial institutions. The image file will generally include a unique identifier that can be used to later connect or associate additional information and transaction data with the received image file. In general, the image file may include an image of the front and/or back of a check or other payment item, as well as an image or other information associated with the MICR line of the payment item. In some instances, the received image file can be stored in a local image repository until additional information is received from the BOFD. At 310, the RFI's middle tier can review the image file and any associated metadata received with the image file to confirm that the image file is associated with and meant for the RFI. At 315, the middle tier determines whether the image file is associated with the RFI. If the image file has incorrectly been sent to the RFI, method 300 continues at 320, where the RFI can return a notification to the originating financial institution (here, the BOFD) to notify that institution of the error. Alternatively, the RFI can ignore and disregard the image file. In most cases, incorrect image files will not receive additional data, as the in-depth processing at the originating financial institution will generally identify the error before additional information is transmitted to the RFI. If additional information is received for an image file that is not associated with the RFI, the RFI may then provide an error or other notification to the originating financial institution.
wherein the remote deposit is processed in real-time to the first user account managed by a financial institution based on the image and the image capture element.
(See Gilson, para. [0011]: “The present disclosure describes systems and methods for performing real-time, straight-through processing and real-time presentment of checks and other electronic payment items at a bank of first deposit (BOFD), as well as real-time, straight-through processing and presentment of checks and payment items at receiving (payor/endpoint) banks. Generally, the present disclosure describes systems and methods wherein checks and/or other payment items (e.g., a loan document, a direct deposit account entry, etc.) are presented to a BOFD through an initial deposit point including teller or teller-related application (including ATMs, customer-based web applications, merchant applications, automated clearing house (ACH), etc.), and subsequently immediately processed and finalized in real-time by a middle tier architecture associated with the BOFD. In other words, the processing of the check or payment item is performed immediately and in a straight-through manner, avoiding current check processing systems' requirements of significant and time-consuming back-end processing performed apart from and outside of the bank's middle tier architecture, which in turn adds significant delay to finalizing and completing transactions.”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the method for automatic cheque image analysis and capture, as taught by Agarwal above, with the method for remote check deposit capture with enhanced image detection, as further taught by Medina above, because Agarwal discloses the check image processing that is performed in the mobile device, while Medina discloses both the check image processing that is performed in the mobile device and also enhanced check image detection and further with the method for real-time straight through processing and real-time presentment of cheques, as further taught by Gilson above, because Agarwal discloses the check image processing that is performed in the mobile device, while Gilson discloses both the check image processing that is performed in the mobile device and also the check deposit processing that is performed in the financial institution.
In regards to claim 2,
2. The method of claim 1, wherein the processing server processes the remote deposit in real-time to the first user account managed by the financial institution based on the image and the image capture element;
(See Gilson, para. [0011]: “The present disclosure describes systems and methods for performing real-time, straight-through processing and real-time presentment of checks and other electronic payment items at a bank of first deposit (BOFD), as well as real-time, straight-through processing and presentment of checks and payment items at receiving (payor/endpoint) banks. Generally, the present disclosure describes systems and methods wherein checks and/or other payment items (e.g., a loan document, a direct deposit account entry, etc.) are presented to a BOFD through an initial deposit point including teller or teller-related application (including ATMs, customer-based web applications, merchant applications, automated clearing house (ACH), etc.), and subsequently immediately processed and finalized in real-time by a middle tier architecture associated with the BOFD. In other words, the processing of the check or payment item is performed immediately and in a straight-through manner, avoiding current check processing systems' requirements of significant and time-consuming back-end processing performed apart from and outside of the bank's middle tier architecture, which in turn adds significant delay to finalizing and completing transactions.”)
the processing server generates an authorization request message in a second message format that includes an identifier for the first user account and data retrieved from the image; and
the processing server transmits the authorization request message to the financial institution in real-time.
(See Medina, col.28, lines 40-54: “In one embodiment, the RDC-Detection may display a user interface for account selection 385, e.g., a dropdown list, a click-and-choose list, etc., and the user may submit a selection of account 386. The RDC-Detection may then determine whether the RDC-Detection is granted permission to access the selected account 387. For example, in one implementation, as discussed above, if the RDC-Detection is associated with a first payee's bank, but the selected account is associated with a different payee's bank, then the first bank needs to be granted permission by the account owner to access the account at the different bank in order to proceed with check deposit. For another example, if the RDC-Detection is a remote deposit service agency, then the RDC-Detection may only access an account at a payee's bank only with authorization of the account owner.”)
In regards to claim 3,
3. The method of claim 1, wherein at least two of the user accounts are associated with different financial institutions, and
wherein the processing server managing the mobile application on the mobile device supports the remote deposit in real-time with the different financial institutions.
(See Medina, col.8, lines 22-35: “In one embodiment, the RDC-Detection database 119 may be one or more online database connected to a variety of vendors and financial institutions, such as hardware vendors (e.g., Apple Inc., Nokia, Sony Ericsson, etc.), deposit banks (e.g., Bank of America, Wells Fargo, etc.), service vendors (e.g., clearinghouse banks, etc.) and/or the like, and obtain updated hardware driver information, software updates from such vendors. In one embodiment, the RDC-Detection platform 120 may constantly, intermittently, and/or periodically download updates, such as updated user profile, updated software programs, updated command instructions, and/or the like, from the RDC-Detection database 119 via a variety of connection protocols, such as Telnet FTP, HTTP transfer, P2P transmission and/or the like.”)
In regards to claim 4,
4. The method of claim 1, further comprising:
generating a second message once the remote deposit has been authorized, the second message including a representation of the image of the check to be sent to an image processing service.
(See Agarwal, para. [0083]: “In addition to displaying the video to the user, the mobile phone 601 automatically adjusts the focus of the digital camera as the mobile phone is being held over the check, as represented by block 630. Also while the user is holding the mobile phone 601 over the check, the mobile phone 601 automatically determines that an image of the check from the video is satisfactory (e.g., for reading information associated with the check), as represented by block 635. Further while the user is holding the mobile phone 601 over the check, and as a result of the determining that the image is satisfactory, the mobile phone 601 automatically captures the image of the check, as represented by block 640. Thereafter, as represented by block 645, the mobile phone 601 sends the captured image of the check to the deposit server 603 for completing the deposit transaction.”)
In regards to claim 7,
7. The method of claim 1, further comprising:
capturing images of multiple checks with the mobile device, wherein the multiple checks are aggregated for processing in a single transaction.
(See Agarwal, para. [0020]: “Further regarding block 110, the phrase “deposit item,” as used herein, generally refers to one or more checks (e.g., personal checks, business checks, cashier's checks, credit card convenience checks, etc.), money orders, deposit slips, and/or the like. In some embodiments, the “deposit item” refers to two or more deposit items and/or to two or more different types of deposit items. Although many of the embodiments described herein are directed to automatically analyzing and/or capturing images of deposit items for use in deposit transactions, it will be understood that some embodiments of the present invention can be implemented to automatically analyze and/or capture images of other items (e.g., barcodes, receipts, official records, etc.) for other purposes (e.g., price checks, online banking, opening accounts, user authentication and/or identification, etc.).”)
In regards to claim 8,
8. The method of claim 1, wherein the transaction request message further includes one or more of a first data element identifying an amount of the remote deposit, a second data element identifying an account identifier of the check or a third data element including supplemental information about the user.
(See Agarwal, para. [0065]: “For example, in some embodiments, the remote capture application 527 is executable to receive and/or generate an image (e.g., the image 507, etc.) that shows a deposit item (e.g., the check 501, etc.). In some embodiments, the remote capture application 527 is executable to determine, automatically or otherwise, whether an image (e.g., the image 507, etc.) is satisfactory for reading deposit item information from the image (e.g., the deposit amount 511 of $25, etc.).”)
In regards to claim 9,
9. The method of claim 1, further comprising:
displaying, by the mobile device via the mobile application, a graphical user interface to display a plurality of transaction types and the one or more user accounts of the user associated with the unique personal account identifier,
wherein the selection of the remote deposit and the first user account is received on the graphical user interface.
(See Medina, col. 15, line 62 to col. 16, line 9: “In one implementation, if the cash is qualified, the third party agent may verify the calculated cash amount with the user 4173 to confirm the consistency in deposit amount. If the user agrees the deposit amount is correct 4174, the third party agent may send deposit information 4175 to the RDC-Detection platform. For example, the deposit information may include, but not limited to the user's RDC-Detection membership information, deposit account information, deposit amount, and/or the like. In one implementation, the user may be prompted to select an available account for cash deposit in a similar way to that in check deposit as discussed in one implementation in FIG. 3G. In another implementation, if the calculated amount is inconsistent with the user specified amount, the third party agent may cancel the deposit 4180.”)
In regards to claim 10,
10. The method of claim 1, wherein the transaction request message generated by the mobile device complies with an industry standard message format predefined for transaction request messages and includes the image as an image file.
(See Gilson, para. [0039]: “Once the transaction is finalized, and the middle tier A 112 a receives confirmation from the corresponding host system A 130 a, one or more transit items associated with the transaction are generated by middle tier A 112 a comprising the set of transaction information and data associated with the received (and now processed) check or payment item. The transit items are generated and sent to be associated with the image files previously sent to the destination middle tier associated with the receiving financial institution (payor/endpoint), and which are to be provided to the receiving financial institution for presentment via the corresponding middle tier. Each check or payment item may be associated with its own transit item, allowing processed check or payment items to be sent to the receiving financial institution as soon as the middle tier and host system processing is complete. In general, both the transit item and the previously-sent image file may be associated with a common identifier, allowing the middle tier of the receiving financial institution (payor/endpoint) to immediately associate the newly received transit item data with the stored image file and begin processing the corresponding item through its middle tier and host. In some instances, the transit items generated by middle tiers may be generated in a common format unique to and/or consistent with the transactions performed between the various middle tiers illustrated in FIG. 1. In some instances, the transit items may be sent using an industry standard format, such as X9.37 files, to transmit the appropriate data between middle tier systems.”)
In regards to claims 11-20, they are rejected on the same grounds as claims 1-10, respectively.
Claims 5, 6, 15, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Agarwal in view of Medina and Gilson, and further in view of US 7,389,912 B2 to Carlson et al.(“Carlson”. Filed on Aug. 16, 2005. Published June 24, 2008).
In regards to claim 5, under a conservative interpretation of Agarwal in view of Medina and Gilson, it could be argued that Agarwal in view of Medina and Gilson does not explicitly teach the italicized portions below, which are taught by Carlson:
5. The method of claim 1, wherein the first user account is a first sub-account, the method further comprising:
receiving, by the mobile device based on the unique personal account identifier, a list of one or more sub-accounts associated with one of the one or more user accounts;
displaying the list of one or more sub-accounts based on the selection of the one of the one or more user accounts;
receiving a selection of the first sub-account among the one or more sub-accounts managed by the financial institution, the first sub-account to be used in processing the remote deposit as the first user account; and
communicating the selection of the first sub-account to the processing server.
(See Carlson, col. 2, lines 14-16: “FIG. 3 is an illustrative diagram of an interactive display interface used for the electronic presentation of transaction information of the present invention”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the method for automatic cheque image analysis and capture, as taught by Agarwal above, with the method for remote check deposit capture with enhanced image detection, as further taught by Medina above, because Agarwal discloses the check image processing that is performed in the mobile device, while Medina discloses both the check image processing that is performed in the mobile device and also enhanced check image detectionand further with the method for real-time straight through processing and real-time presentment of cheques, as further taught by Gilson above, because Agarwal discloses the check image processing that is performed in the mobile device, while Gilson discloses both the check image processing that is performed in the mobile device and also the check deposit processing that is performed in the financial institution.
Moreover, it would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the method for automatic cheque image analysis and capture, as taught by Agarwal in view of Medina and Gilson above, with a method and system for creating banking sub-accounts, as taught by Carlson, because doing so “allow[s] an account holder or user to consolidate transactions for an account and its associated sub-accounts.” (See Carlson, col. 1, lines 6-9).
In regards to claim 6, under a conservative interpretation of Agarwal in view of Medina and Gilson, it could be argued that Agarwal in view of Medina and Gilson does not explicitly teach the italicized portions below, which are taught by Carlson:
6. The method of claim 5, wherein the one or more sub-accounts associated with one of the one or more user accounts are compatible with the remote deposit as selected transaction type.
(See Carlson, col. 4, lines 32-49: “The example in FIG. 3 is simplified to illustrate the account and sub-account limits, available credit, and transaction history for the month. In practice, a statement showing more detailed account information, such as each transaction for the account and each sub-account, would appear on the account information presented to the account holder. The account holder can place limitations on transactions attempted by the sub-account holders. For example, in FIG. 3, the account holder placed a limitation on transactions made by sub-account holders for the purchase of alcoholic beverages. As shown in the message 35 of FIG. 3, Sub-account holder “C” attempted to pay for a pitcher of beer at College Bar on May 19, 2005 with the sub-account credit card and the transaction was denied. A separate message 35 alert could be sent to account holder immediately after Sub-account holder C's attempt to violate the restriction of the transaction limitation informing account holder of the attempted transaction.”)
It would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the method for automatic cheque image analysis and capture, as taught by Agarwal above, with the method for remote check deposit capture with enhanced image detection, as further taught by Medina above, because Agarwal discloses the check image processing that is performed in the mobile device, while Medina discloses both the check image processing that is performed in the mobile device and also enhanced check image detectionand further with the method for real-time straight through processing and real-time presentment of cheques, as further taught by Gilson above, because Agarwal discloses the check image processing that is performed in the mobile device, while Gilson discloses both the check image processing that is performed in the mobile device and also the check deposit processing that is performed in the financial institution.
Moreover, it would have been obvious to a person having ordinary skill in the art (PHOSITA), before the effective filing date of the claimed invention, to include in the method for automatic cheque image analysis and capture, as taught by Agarwal in view of Medina and Gilson above, with a method and system for creating banking sub-accounts, as taught by Carlson, because doing so “allow[s] an account holder or user to consolidate transactions for an account and its associated sub-accounts.” (See Carlson, col. 1, lines 6-9).
Conclusion
Applicants are invited to contact the Office to schedule an in-person interview to discuss and resolve the issues set forth in this Office Action. Although an interview is not required, the Office believes that an interview can be of use to resolve any issues related to a patent application in an efficient and prompt manner.
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.
Any inquiry concerning this communication or earlier communications should be directed to Examiner Ayal Sharon, whose telephone number is (571) 272-5614, and fax number is (571) 273-1794. The Examiner can normally be reached from Monday to Friday between 9 AM and 6 PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SPE Christine Behncke can be reached at (571) 272-8103 or at christine.behncke@uspto.gov. The fax 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.
Sincerely,
/Ayal I. Sharon/
Examiner, Art Unit 3695
January 31, 2026