DETAILED ACTION
Status of the Claims
1. This action is in reply to the application field on September 9, 2024.
2. Claims 1-20 are currently pending and have been examined.
3. The instant application is the parent application of Application 18/937,717, filed on November 5, 2024, which was considered earlier than the parent application due to the Applicant’s filing of a Track One Request in that application. Applicant has also filed a divisional application of Application 18/937,717, Application 19/047,395 on February 2, 2025 subsequent to the allowance of Application 18/937,717 on January 29, 2025.
Notice of Pre-AIA or AIA Status
4. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Drawings
5. The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description:
- Regarding Figure 2, the drawing refers to reference character #50. There is no mention of reference character #50 in the specification. Rather, it appears that Applicant has referred to this step as “step 20” in paragraph 46 of the specification. This appears to be a typographical error as reference character 20 otherwise refers to the event notification service in the specification.
- Regarding Figure 3, the drawing refers to reference characters #64, #74, and #78, however none of these reference characters are disclosed in the specification.
- Regarding Figure 5A, the drawing refers to reference characters #140 and #150, however this reference character is not disclosed in the specification.
- Regarding Figure 5C, the drawing refers to reference character #206, however this reference character is not disclosed in the specification.
Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Terminal Disclaimer
6. Examiner asserts that a Terminal Disclaimer is warranted due to the instant application, 18/828,819 and US Patent 12,254,475 (formerly Application 18/937,717) and Application (19/047,395 ) sharing the same inventive entity and claim language which would otherwise result in a double patenting rejection.
Claim Objections
7. Claim 11 is objected to because of the following informalities:
- Claim 11 recites “wherein the event notification service is further configured to send a message to at least one subscribed user via short message short message service (SMS) or email. It appears that this is typographical error and should more properly read “…via short message service (SMS)…” and will be interpreted in this manner for purposes of examination, however appropriate correction is required.
Claim Interpretation – Broadest Reasonable Interpretation
8. In determining patentability of an invention over the prior art, all claim limitations have been considered and interpreted using the “broadest reasonable interpretation consistent with the specification during the examination of a patent application since the applicant may then amend his claims.” See In re Prater and Wei, 162 USPQ 541, 550 (CCPA 1969); MPEP § 2111. Applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. See In re Prater, 162 USPQ 541, 550-51 (CCPA 1969); MPEP § 2111. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 26 USPQ2d 1057 (Fed. Cir. 1993). See also MPEP 2173.05(q) All claim limitations have been considered. Additionally, all words in the claims have been considered in judging the patentability of the claims against the prior art. See MPEP 2143.03.
Claim limitations that contain statement(s) such as “if, may, might, can, could”, are treated as containing optional language. As matter of linguistic precision, optional claim elements do not narrow claim limitations, since they can always be omitted.
Claim limitations that contain statement(s) such as “wherein, whereby”, that fail to further define the steps or acts to be performed in method claims or the discrete physical structure required of system claims.
Similarly, a method step exercised or triggered upon the satisfaction of a condition, where there remains the possibility that the condition was not satisfied under the broadest reasonable interpretation, is an optional claim limitation. see MPEP § 2103(I)(C); In re Johnson, 77 USPQ2d 1788 (Fed Cir 2006). As the Applicant does not address what happens should the optional claim limitations fail, Examiner assumes that nothing happens (i.e. the method stops). An alternate interpretation is that merely the claim limitations based upon the condition are not triggered or performed.
The subject matter of a properly construed claim is defined by the terms that limit its scope. It is this subject matter that must be examined.
As a general matter, grammar and the plain meaning of terms as understood by one having ordinary skill in the art used in a claim will dictate whether, and to what extent, the language limits the claim scope. see MPEP §2013(I)(C). Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. see MPEP §2013(I)(C).
Claim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure. In addition, when a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See, e.g., Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 1298 (Fed. Cir. 2009). See MPEP 2111.04, 2143.03.
Language in a method or system claim that states only the intended use or intended result, but does not result in a manipulative difference in the steps of the method claim nor a structural difference between the system claim and the prior art, fails to distinguish the claims from the prior art. In other words, if the prior art structure is capable of performing the intended use, then it meets the claim.
The following types of claim language may raise a question as to its limiting effect (this list is not exhaustive):
Statements of intended use or field of use, including statements of purpose or intended use in the preamble (MPEP 2111.02);
Clauses such as “adapted to”, “adapted for”, “wherein”, and “whereby” (MPEP 2111.04)
Contingent limitations (MPEP 2111.04)
Printed matter (MPEP 2111.05) and
Functional language associated with a claim term (MPEP 2181)
Examiner notes that during examination, “claims … are to be given their broadest reasonable interpretation consistent with the specification, and … claim language should be read in light of the specification as it would be interpreted by one of ordinary skill in the art.” See In re Bond, 15 USPQ 1566, 1568 (Fed. Cir. 1990), citing In re Sneed, 218 USPQ 385, 388 (Fed. Cir. 1983). However, "in examining the specification for proper context, [the examiner] will not at any time import limitations from the specification into the claims". See CollegeNet, Inc. v. ApplyYourself, Inc., 75 USPQ2d 1733, 1738 (Fed. Cir. 2005). Construing claims broadly during prosecution is not unfair to the applicant, because the applicant has the opportunity to amend the claims to obtain more precise claim coverage. See In re Yamamoto, 222 USPQ 934, 936 (Fed. Cir. 1984), citing In re Prater, 162 USPQ 541, 550 (CCPA 1969).
As such, while all claim limitations have been considered and all words in the claims have been considered in judging the patentability of the claimed invention, the following language is interpreted as not further limiting the scope of the claimed invention.
The preamble of the instant claim 12 recites "[a] method for preventing check fraud, the method comprising the steps of:” In general, a preamble limits the invention if it recites essential structure or steps, or if it is "necessary to give life, meaning, and vitality" to the claims. Pitney Bowes, Inc. v. Hewlett-Packard Co. 51 USPQ2d 1161 (Fed. Cir. 1999), Catalina Marketing International Inc. v. Coolsavings.com Inc., 62 USPQ2d 1781 (Fed. Cir. 2002). Conversely, where a patentee defines a structurally complete invention in the claim body and uses the preamble only to state a purpose or an intended use for the invention, the preamble is not a claim limitation given patentable weight. Rowe v. Dror, 42 USPQ2d 1550 (Fed. Cir. 1997); Catalina Marketing International Inc. v. Coolsavings.com Inc., 62 USPQ2d 1781 (Fed. Cir. 2002); Bell Communications Research, Inc. v. Vitalink Communications Corp., 34 USPQ2d 1816 (Fed. Cir. 1995) If a prior art structure is capable of performing the intended use as recited in the preamble, then it meets the claim. See, e.g., In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed. Cir. 1997) See MPEP 2111.02
In the instant case, “for preventing check fraud” as recited in the preamble only states a purpose and/or the intended use of the invention and accordingly is not being assigned any patentable weight.
Similarly, in the instant case, the following italicized limitations are expressing the intended result of a process step positively recited and are not accorded additional weight:
As in Claim 1:
an image processor in communication with the GCR, wherein the image processor is configured to read check data from a digital image of a presented check by defining a region of interest (ROI) on the digital image of the presented check where payee information is expected to reside, wherein the ROI is smaller than an entire region of the digital image of a presented check, and further wherein the image processor is configured to extract a found payee name from the ROI;
an event notification service in communication with the check comparison engine configured to generate and manage events based on the check validation result and to send messages concerning the check validation result; and
a client portal in communication with the event notification service, wherein the client portal comprises a user interface and the client portal is configured to present reports from the check comparison engine at the user interface and to allow responses to events through the user interface.
As in Claim 12:
at an image processor, extracting check data from the digital image of a presented check, wherein the extracted check data comprises a payee name extracted from a region of interest (ROI) in the digital image of a presented check corresponding to an expected check area for the payee name to appear, wherein the ROI is smaller than an entire region of the digital image of a check;
validating the check data from a digital image of a presented check against a global check register (GCR) in communication with the image processor to produce a validation result; and
As in Claim 2:
wherein the digital image of a presented check is read from an image cash letter (ICL) X9 file for the presented check.
As in Claim 4:
wherein the known check data in the GCR comprises a hashed account number.
As in Claim 9:
wherein the check comparison engine is further configured to score the match between the found payee name and the target payee name by populating an array with bits indicative of a match between a found string created from the found payee name and a target string from a target payee name, removing noise from the array, shifting the array, and calculating a dispersion score and an adjusted dispersion score from the array.
As in Claim 10:
wherein the image processor is further configured to remove any horizontal lines from the ROI and to blur the ROI after removing the any horizontal lines from the ROI whereby white space created by the removal of the any horizontal lines is filled in.
As in Claim 15:
further comprising the step of analyzing the digital image of the presented check at a vision AI module to extract and validate payee information if a payee match is not made at the image processor.
As in Claim 17:
wherein the step of scoring the match between the found payee name and the target payee name comprises the steps of populating an array with bits indicative of a match between each character in a found string created from the found payee name and a target string from the target payee name.
As in Claim 18:
further comprising the step of removing noise from the array and shifting each of a plurality of columns in the array upward by an amount equal to the ordinal of each of the corresponding plurality of columns to produce a shifted array.
As in Claim 19:
further comprising the step of calculating a dispersion score and an adjusted dispersion score from the shifted array.
As in Claim 20:
further comprising the step of removing any horizontal lines from the ROI and blurring the ROI after removing the any horizontal lines from the ROI whereby any white space created by removal of the any horizontal lines is filled in.
Applicant also uses the following terminology in their claims:
Image processor:
Applicant’s specification discloses the image processor as follows:
“Image processor 16 is a module that decodes check data and images from the Image Cash Letter (X9) files (described more fully below) received from banks, including payor bank 4. Image processor 16 analyzes check images using Optical Character Recognition (OCR) and, optionally vision AI 32 to extract and validate payee information.” (See Applicant Spec para 19)
“When payor bank 4 receives the check information in the X9 file 30, a copy of X9 file 30 is transmitted to the fraud detection system 10 at step 13, and is then queued for processing at step 15. Image processor 16 decodes the check data using OCR and check images from the file at step 17. Each of the checks contained in the file are compared against check information contained in GCR 14.” (See Applicant Spec para 24)
“The X9 file 30 is queued for processing by the fraud detection system 10. Image processing occurs on all checks found in the X9 file 30 at image processor (i.e., OCR system) 16, which is a part of process management server 12 of fraud detection system 10. Optionally, an external vision AI service 21 may also be used to provide image processing to provide additional data such as in the case when image processor 16 returns a result that there is no match.” (See Applicant Spec para 39)
The further disclosures are do not provide any direct connection that discloses the image processor to be a hardware component, or anything other than a module as defined by the specification. As such, the image processor will be interpreted, consistent with the specification, as a module for purposes of examination.
Region of Interest (ROI):
As Applicant is entitled to be their own lexicographer and as such, the specification indicates a designation of ROI as region of interest, as opposed to the more common definition of return on investment when referring to ROI. Applicant discloses the region of interest (ROI) as follows:
“The comparison process first validates the amount on the presented check to the amount stored in GCR 14 at step 19. If the amounts are equal, then the process continues and validation of the payee information begins. The payee validation begins with defining a region of interest on the image where the payee information resides and creating a payee image. (This process is described in more detail below with reference to Fig. 4). After performing additional image manipulations, the image is read by image processor 16 to see if the known payee from the GCR is found in the image.” (See Applicant Spec para 25)
“A region of interest (ROI) is defined at step 94, based on data stored in the database for the account from which the check is drawn. The region of interest is an area, in some embodiments being a rectangular area, that is cropped from the overall check image. This step improves the accuracy of the analysis. For example, suppose that a person was attempting to alter a check’s payee information in an attempt to commit fraud. The original payee information may be placed on the memo line of the check with the payee information changed to a fraudulent payee name. In this scenario, OCR or AI tools would likely find the payee information on the overall check image and consider the check to be valid if the entire check is viewed. By limiting the analysis to the ROI surrounding the area of the check that contains the payee, the risk of encountering a false negative is greatly reduced.” (See Applicant Spec para 53)
“Many times, the payee area of a check contains a horizontal line. After the ROI area has been cropped from the original check image, the cropped ROI image must be examined for horizontal lines and these lines must be removed at step 96 in order to increase the overall accuracy of the text extraction. In some cases, one or more letter of the payee text may cross the horizontal line. In this case, when the line is removed from the letter crossing the line will contain white space where the line crossed. To correct this, the image is blurred at step 96, which causes the pixels on either side of the white space to bleed out towards each other. This bleeding of the pixels results in the OCR (image processor 16) and optionally vision AI 32 recognizing the letter as if the white space did not exist. This manipulation of the cropped ROI image results in significantly higher accuracy.” (See Applicant Spec para 54)
“As step 98, the manipulated ROI image is analyzed by the image processor 16 to determine the text value of the payee name contained in the image.” (See Applicant Spec para 55)
“At step 112, the image is now submitted to the vision AI engine 32 to determine the value contained within the check’s payee ROI. If the observed value does not match the known payee data at query step 114, then the system will submit the observed value and the known payee value to the comparative text scoring function at step 118 to create a match score and update the resolution object to indicate a vision AI mis-match at step 116. The system then returns the resolution object to image processor 16 at step 122.” (See Applicant Spec para 58)
The disclosures indicate that ROI only refers to region of interest as the area cropped from the overall check image where the payee information resides. The ROI will be interpreted in this manner, consistent with the disclosures of the specification, for purposes of examination.
Global Check Register (GCR):
Applicant’s specification discloses the following:
“In an embodiment, a system to detect check fraud comprises a number of key components as depicted in Fig. 1A, which perform operations as generally shown in the swim lane diagram of FIG. 1B. Global Check Register (GCR) 14 is a database that is a part of the fraud detection system 10. It stores known check data, including data written, check number, payee, amount, ABA routing number, and a hashed account number. Image processor 16 is a module that decodes check data and images from the Image Cash Letter (X9) files (described more fully below) received from banks, including payor bank 4. Image processor 16 analyzes check images using Optical Character Recognition (OCR) and, optionally, vision 32 to extract and validate payee information. In one implementation, vision AI 32 is a third-party product such as Azure AI Vision from Microsoft Corporation, or Claude 3.5 from Anthropic, but the invention is not limited to these examples. A check comparison engine 18 compares the data from the presented check against the known check data in GCR 14. An event notification service 20 generates and manages events based on the results of the check validation process, notifying relevant parties via short message service (SMS, i.e., text) or email. A client portal is a web-based interface for financial institution employees to view reports, receive alerts, and respond to events.” (See Applicant Spec para 19)
“The following check details are collected and stored in GCR 14: date written, check number, payee, amount, ABA routing number, and account number. Check writer 2 may create an accounts payable (AP) file for third-party check processing at step 7.” (See Applicant Spec para 20)
“If the check is created by accounting software at step 1, that software may optionally be integrated with fraud detection system 10 such that it pulls check data from the accounting software directly at step 33. In that case, GCR 14 is then updated at step 35, and payor bank 4 may send a corresponding pay data file to GCR 14 at step 39.” (See Applicant Spec para 21)
“The fraud detection system 10, in certain embodiments, requires data from check writers to populate the global check register (GCR) 14 and X9 files 30 containing check data from banks attempting to clear checks. Both types of data may be received by either secure file transfer protocol (SFTP) transmission or via a web service application programming interface (API).” (See Applicant Spec para 34)
“GCR data can be sent directly from the bank or the bank’s individual clients via an integration with the bank’s client accounting system. This data is stored in GCR 14 and is used to validate the check data presented in the X9 file 30. The data collected for GCR 14 in certain embodiments consists of the check number, date written, payee, and amount.” (See Applicant Spec para 35)
“Next, at step 63, check information is extracted from the X9 file 30 stream. The system iterates through each check item within the X9 file 30. For each check item, the system queries the Global Check Register (GCR) database 14 to retrieve associated check data at step 66. If the check is found in GCR 14 at query step 68, the system proceeds with the next steps. If not, an alert is created for the unknown check at step 70. The alert is handled by event notification service 20 as described above with respect to Fig. 2.” (See Applicant Spec para 48)
The Global Check Register (GCR) is disclosed to be a database in the specification. There is no disclosure of any hardware associated with the database in the specification. For purposes of examination, Examiner will interpret the GCR as a database that under a BRI could be entirely a software construct.
Check comparison engine:
Applicant’s specification discloses the following:
“A check comparison engine 18 compares the data from the presented check against known check data in GCR 14. An event notification service 20 generates and manages events based on the results of the check validation process, notifying relevant parties via short message service (SMS, i.e., text) or email.” (See Applicant Spec para 19)
This is the only mention of a check comparison engine in the specification. There is no disclosure of any hardware that is the check comparison engine. For purposes of examination, Examiner will interpret “check comparison engine” as some sort of software construct that compares data from the presented check against the known check data in the GCR for purposes of examination.
Event notification service:
Applicant’s specification discloses the following:
“An event notification service 20 generates and manages events based on the results of the check validation process, notifying relevant parties via short message service (SMS, i.e., text) or email.” (See Applicant Spec para 19)
“Based on the results of the analysis, fraud detection system 10 will update its internal logs and create the appropriate notification events within the event notification service 20 at step 31. For accepted checks, the payor bank 4 updates processing logs and archives data files, the check is paid, and funds are debited from the check writer’s account at step 29. For rejected or referred checks, the check writer 2 receives a notice of validation failure at step 21, and the check may be manually reviewed by the payor bank 4 at step 27. If determined to be fraudulent, the check is returned to the payee bank 28 at step 23. At the payee bank 28, the returned check may then be processed accordingly in a normal fashion.” (See Applicant Spec para 41)
“Referring now to the flow chart of Fig.2, the process flow within event notification service 20 may be described in greater detail. When anomalies are detected between the known data points within the GCR 14 (shown in Fig. 1) and the data obtained from the X9 30 check data, it is imperative the bank be alerted as soon as possible in order to prevent payment of the presented check and avoid financial losses that may arise. To facilitate this, fraud detection system 10 implements a robust event management system, as implement and shown in Fig. 1 as event notification service 20.” (See Applicant Spec para 43)
“For each event, the next step is to determine the Event Type and Account Information from the event data and initiate tracking at step 44. Then at step 46 the event notification service 20 retrieves of list of users that are subscribed to the Event Type for the specific company related to the check that caused the event at step 46. At step 48, the event notification service 20 determines the messaging type (SMS, email, or both) that the user has selected for its default notification method. Then, also at step 48, it constructs the messages to be delivered to the user based on the findings related to the event. Details may include a hypertext transfer protocol (HTTP) link that allows the user to view the event details immediately.” (See Applicant Spec para 45)
“Next, at step 63, check information is extracted from the X9 file 30 stream. The system iterates through each check item within the X9 file 30. For each check item, the system queries the Global Check Register (GCR) database 14 to retrieve associated check data at step 66. If not, an alert is created for the unknown check at step 70. The alert is handled by event notification service 20 as described above with respect to Fig. 2) (See Applicant para 48)
The event notification service appears to be potentially be a software construct the communicates results of the check validation process, however is not defined as software or hardware in the specification. For purposes of examination, Examiner will interpret the term as software based on the disclosure.
Client portal:
Applicant discloses the client portal as follows:
“An event notification service 20 generates and manages events based on the results of the check validation process, notifying relevant parties via short message service (SMS, i.e., text) or email. A client portal is a web-based interface for financial institution employees to view reports, receive alerts, and respond to events.” (See Applicant Spec para 19)
“In the event of a “reject” or “refer” determination, the system creates an event. Various individuals, both at the payor bank 4 and at the provider of the fraud detection system 10, can subscribe to various events through the client portal. When a user subscribes to an event, that user is notified immediately of the event via either SMS text message or email, based on saved preferences.” (See Applicant Spec para 28)
In the user setup phase, once the bank has been set up in the system, a bank employee is defined as the company administrator for the bank. The company administrator, operating from a networked computer at the bank, creates the individual user accounts in the client portal, individual user accounts allow users to view reports, receive alerts, and respond to alerts within the client portal.” (See Applicant Spec para 31)
Event configuration describes the process by which bank users may subscribe to be shown events through the client portal. Several potential events may be raised to the system, each of which may be subscribed to by bank users. This allows each user to automatically receive messages when various events are created. For example, when a check is presented on an account and the amount of the check does not match the know[n] amount, an event may be created. Any user subscribed to this event would receive an immediate notification.” (See Applicant Spec para 32)
The client portal appears to be a web-based interface that allows users to subscribe to view reports and receive alerts, however it is driven by the user subscribing to the service and requesting certain information be sent to the requesting user. The client portal will be viewed as disclosed by the specification for purposes of examination.
Vision AI Module:
Applicant also uses the term vision AI and vision AI module in the claims. Applicant’s specification discloses the following:
“Image processor 16 analyzes check images using Optical Character Recognition (OCR) and, optionally, vision 32 to extract and validate payee information. In one implementation, vision AI 32 is a third-party product such as Azure AI Vision from Microsoft Corporation, or Claude 3.5 from Anthropic, but the invention is not limited to these examples.” (See Applicant Spec para 19)
“After the OCR analysis is completed, the payee image is then optionally submitted to the vision AI service 32 to see if the payee matches the known payee in the GCR 14. Both the OCR and vision AI results are scored. Based on the results of the comparisons and the related scores, the system determines to either accept the check, reject the check, or refer the check for manual review, at step 19. Scoring is described in more detail below with reference to Figs. 5A, 5B, and 5C.” (See Applicant Spec para 26)
“The X9 file 30 is queued for processing by fraud detection system 10. Image processing occurs on all checks found in the X9 file 30 at image processor (i.e., OCR system) 16, which is a part of process management service 12 of fraud detection system 10. Optionally, an external vision AI service 32 may also be used to provide image processing to provide additional data, such as in the case when image processor 16 returns a result that there is no match.” (See Applicant Spec para 39)
“Many times, the payee area of a check contains a horizontal line. After the ROI area has been cropped from the original check image, the cropped ROI image must be examined for horizontal lines and these lines must be removed at step 96 in order to increase the overall accuracy of the text extraction. In some cases, one or more letter of the payee text may cross the horizontal line. In this case, when the line is removed from the letter crossing the line will contain white space where the line crossed. To correct this, the image is blurred at step 96, which causes the pixels on either side of the white space to bleed out towards each other. This bleeding of the pixels results in the OCR (image processor 16) and optionally vision AI 32 recognizing the letter as if the white space did not exist. This manipulation of the cropped ROI image results in significantly higher accuracy.” (See Applicant Spec para 54)
“At step 112, the image is now submitted to the vision AI engine 32 to determine the value contained within the check’s payee ROI. If the observed value does not match the known payee data at query step 114, then the system will submit the observed value and the known payee value to the comparative text scoring function at step 118 to create a match score and update the resolution object to indicate a vision AI mis-match at step 116. The system then returns the resolution object to image processor 16 at step 122.” (See Applicant spec para 58)
The vision AI module appears to be a service external to the system that Applicant is sending data to be analyzed. For purposes of examination, Examiner will be interpreting the term as a module that is operating outside of the system that Applicant has invented.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
9. Claims 8-9 and 16-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding Claims 8-9, Applicant claims the following:
As in Claim 8: “wherein the check comparison engine is further configured to score a match between a found payee name on the digital image of a presented check and a target payee name from the GCR.”
As in Claim 9: “wherein the check comparison engine is further configured to score the match between the found payee name and the target payee name by populating an array with bits indicative of a match between a found string created from the found payee name and a target string from a target payee name, removing noise from the array, shifting the array, and calculating a dispersion score and an adjusted dispersion score from the array.”
In the case of Claims 8 and 9, neither of the claims have sufficient support in the specification for the functions that the system is alleged configured to perform with the check comparison engine.
Applicant’s specification discloses the following:
“A check comparison engine 18 compares the data from the presented check against known check data in GCR 14. An event notification service 20 generates and manages events based on the results of the check validation process, notifying relevant parties via short message service (SMS, i.e., text) or email.” (See Applicant Spec para 19)
This is the only mention of a check comparison engine in the specification. There is no disclosure of any hardware that is the check comparison engine. Further, there is no disclosure of the check comparison engine performing the functions that Applicant is attempting to ascribe to the check comparison engine. Applicant is requested to correct the claims to reflect the disclosure of the specification.
Regarding Claims 16-20, Applicant claims the following:
As in Claim 16: “further comprising the step of scoring a match between a found payee name on the digital image of a presented check and a target payee name from the GCR.”
As in Claim 17: “wherein the step of scoring the match between the found payee name and the target payee name comprises the steps of populating an array with bits indicative of a match between each character in a found string created from the found payee name and a target string from the target payee name.”
As in Claim 18: “further comprising the step of removing noise from the array and shifting each of a plurality of columns in the array upward by an amount equal to the ordinal of each of the corresponding plurality of columns to produce a shifted array.”
As in Claim 19: “further comprising the step of calculating a dispersion score and an adjusted dispersion score from the shifted array.”
As in Claim 20: “further comprising the step of removing any horizontal lines from the ROI and blurring the ROI after removing the any horizontal lines from the ROI whereby any white space created by removal of the any horizontal lines is filled in.”
Claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. See MPEP 2161.01.
Specifically, for software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. See MPEP §§ 2163.02 and 2181, subsection IV. It is not enough that one skilled in the art could write a program to achieve the claimed function, because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See MPEP 2161.01 (citing Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683 (Fed. Cir. 2015)).
However, the specification lacks sufficient support in the disclosure for what computer components and algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed functions, i.e., what components or processors actually performs the scoring of the match, removes noise, calculating of the dispersion score, blurring the ROI and creation of white space ”, in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing.
Instead, the specification merely discloses that the observed value and the known payee data values are compared to create a score based on the similarity of the two values. (See Applicant Spec para 57) Further, while there is a process for comparative text scoring presented at a high level, it does not function by the scoring populating the found payee name and the target payee name and populating the array directly – rather there is a score of similarity decided, then string values are converted and a two dimensional array is created prior to an array being populated based on a bit-wise comparison of the strings by comparing each string character in the X row and Y column involving checking the matrix size and determining if the strings match. (See Applicant Spec paras 62-64) The specification does not simply remove noise from the array and shift each of the plurality of columns upward – rather there is disclosure of creation of a clone matrix and iterating through each x value and y value to process the entirety of the matrix, then simply setting the sum to 0 to remove noise. (See Applicant Spec 66-69) It is not until the matrix has been shifted that the system may even begin the process of scoring the results, which begins with adding the values of each row to be stored in an array, iterating and resetting the values before a dispersion score is calculated. (See Applicant Spec paras 69-72) Then there is an adjusted dispersion score calculated, however the components of the equations are not clearly presented as to the methodology used to arrive at the values to be used to arrive at the components that could be utilized by the dispersion scoring equations. As to the blurring and creation of white space created by removal of any horizontal lines, the disclosure is high level and does not indicate how the blurring occurs or by what mechanism. (See Applicant Spec 54)
The claims are presented at a high level without disclosing the systemization nor the steps that would be required to accomplish the intended result as currently claimed.
The steps claimed result in the claimed functional result amounts to a block box. As such Claims 16-20 are rejected under 112(a) for failing to comply with the written description requirement.
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.
10. Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
ANALYSIS:
STEP 1:
Does the claimed invention fall within one of the four statutory categories of invention (process, machine, manufacture or composition matter?
Claim 1 recites a system. Claim 12 recites a method. Currently, the system and method are both subject to separate rejections as being non-statutory (as shown below) however Examiner assumes that Applicant will rectify the claims to properly claim the invention as within statutory categories.
STEP 2A:
Prong One: Does the Claim Recite A Judicial Exception (An Abstract Idea, Law of Nature or Natural Phenomenon)? (If Yes, Proceed to Prong Two, If No, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material)
Claim 1 recites the abstract idea of check fraud detection. The idea is described by the following limitations:
a global check register comprising known check data for a plurality of checks;
read check data from an image of a presented check by defining a region of interest (ROI) on the image of the presented check where payee information is expected to reside, wherein the ROI is smaller than an entire region of the image of the presented check and extract a found payee name from the ROI;
compare data from a presented check against known check data in the GCR and return a check validation result;
generate and manage events based on the check validation result and to send messages concerning the check validation result;
present reports and allow responses to events
Claim 12 recites the abstract idea of check fraud prevention. The idea is described by the following limitations:
receiving an image of a check from a payor bank;
extracting check data from the image of a presented check, wherein the extracted check data comprises a payee name extracted from a region of interest (ROI) in the image of a presented check corresponding to an expected check area for the payee name to appear, wherein the ROI is smaller than an entire region of the image of a check;
validating the check data from an image of a presented check against a global check register (GCR) to produce a validation result; and
raising an event based on the validation result, wherein the event comprises one of an accept, a reject, and a refer.
Under a broadest reasonable interpretation, the system and method describe no more than an existing process for comparing known check data to a presented check image, returning a check validation result and presenting reports or raising an event based on the validation.
As a result, the abstract idea describes certain methods of organizing human activity.
As to certain methods of organizing human activity, the steps involve fundamental economic principles or practices (mitigating fraud risk); commercial interactions or legal interactions (including legal obligations, business relations) and/or managing personal behavior or relationships or interactions between people (including following rules or instructions) (Step 2A, Prong 1: Yes, the claims are abstract)
Prong Two: Does the Claim Recite Additional Elements That Integrate The Judicial Exception Into A Practical Application of the Exception? (If Yes, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material. If No, Proceed to Step 2B)
The claims do not include additional elements that integrate the judicial exception into a practical application of the exception because the claims do not provide improvements to another technology or technical field, improvements to the functioning of the computer itself, are not applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, are not applying the judicial exception with, or by use of a particular machine, are not effecting a transformation or reduction of a particular article to a different state or thing, and are not applying the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Further, the method outlined in Claim 12 does not sufficiently tie the method steps to a particular machine within the body of the claim. As such, the recitations are further failing to integrate the judicial exception into a practical application on this basis.
Claim 1 recites a global check register (GCR) database, an image processor in communication with the GCR, a check comparison engine, an event notification service, and a client portal that comprises a user interface.
Claim 12 recites an image processor in communication with a global check register (GCR), and an event notification service.
In particular, the claims only recite global check register (GCR) database, an image processor in communication with the GCR database, a check comparison engine, an event notification service, an image processor in communication with a GCR and a client portal that comprises a user interface
which are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using a generic computer component. The recited GCR database, image processor in communication with the GCR database, a check comparison engine, an event notification service, an image process in communication with a GCR and a client portal that comprises a user interface all appear to be software constructs.
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. Therefore, Claims 1 and 12 are directed to an abstract idea without a practical application. (Step 2A – Prong 2: No, the additional claimed elements are not integrated into a practical application)
STEP 2B: If there is an exception, determine if the claim as a whole recites significantly more than the judicial exception itself.
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: i) receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); ii) performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); iii) electronic recordkeeping, Alice Corp., 134 S. Ct. at 2359, 110 USPQ2d at 1984 (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv) storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; v) electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (