Patent ID: 12254475

DETAILED DESCRIPTION OF THE INVENTION

Before the present invention is described in further detail, it should be understood that the invention is not limited to the particular embodiments described, and that the terms used in describing the particular embodiments are for the purpose of describing those particular embodiments only, and are not intended to be limiting, since the scope of the present invention will be limited only by the claims.

In an embodiment, a system to detect check fraud comprises a number of key components as depicted inFIG.1A, which perform operations as generally shown in the swim lane diagram ofFIG.1B. Global Check Register (GCR)14is a database that is a part of the fraud detection system10. It stores known check data, including date written, check number, payee, amount, ABA routing number, and a hashed account number. Image processor16is a module that decodes check data and images from the Image Cash Letter (X9) files (described more fully below) received from banks, including payor bank4. Image processor16analyzes check images using Optical Character Recognition (OCR) and, optionally, vision AI32to extract and validate payee information. In one implementation, vision AI32is 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 engine18compares the data from the presented check against the known check data in GCR14. An event notification service20generates 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.

In an embodiment, a process using the key components of the system shown inFIG.1Amay be described in overview, with reference particularly toFIG.1B. Such system works directly with financial institutions (e.g., banks) to validate checks presented for payment against known data points on the checks. When a check is written by check writer2at step1, in some cases by being created by accounting software, the check is sent to check payee6at step3. The following check details are collected and stored in GCR14: date written, check number, payee, amount, ABA routing number, and account number. Check writer2may create an accounts payable (AP) file for third-party check processing at step7.

If the check is created by accounting software at step1, that software may optionally be integrated with fraud detection system10such that it pulls check data from the accounting software directly at step33. In that case, GCR14is then updated at step35, and payor bank4may send a corresponding pay data file to GCR14at step39.

For security purposes, the account number is hashed in GCR14in such a way it is impossible to re-construct the account number from the information stored in GCR14. This information can be collected via the bank's current positive pay system at step39or via integration with third-party check-writing services.

The check payee6receives the check and deposits it to payee bank28at step5. Once the check payee6deposits the check with payee bank28at step9, it scans the check at the point of deposit. The check data is then added, along with its image, to an Image Cash Letter (ICL) file30, commonly referred to within the financial services industry as an X9 file, at step11. X9 files are the means by which banks transmit check data to other banks.

When payor bank4receives the check information in the X9 file30, a copy of X9 file30is transmitted to the fraud detection system10at step13, and is then queued for processing at step15. Image processor16decodes the check data using OCR and check images from the file at step17. Each of the checks contained in the file are compared against the check information contained in GCR14.

The comparison process first validates the amount on the presented check to the amount stored in GCR14at step19. 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 toFIG.4.) After performing additional image manipulations, the image is read by image processor16to see if the known payee from the GCR is found in the image.

After the OCR analysis is completed, the payee image is then optionally submitted to the vision AI service32to see if the payee matches the known payee in the GCR14. 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 step19. Scoring is described in more detail below with reference toFIGS.5A,5B, and5C.

In the event of an “accept” determination, the check is paid by payor bank4and funds are debited from the account of check writer2, at step29. The fraud detection system10then updates its logs, and archives data files at step31.

In the event of a “reject” or “refer” determination, the system creates an event. Various individuals, both at the payor bank4and at the provider of the fraud detection system10, 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. Due to the time-sensitive nature of these events, status monitoring on the events will send reminder notices based on pre-determined time intervals.

When the bank receives an event notice that a check has been presented that does not match the information in GCR14, the bank can return the item unpaid and alert the bank customer. The check writer2may receive a notification of the rejection at step21. The check may also be returned to payee bank4at step23, and then the returned check may be processed by payee bank28at step25. If at step19the determination is made to refer the check for manually processing, then the check is manually reviewed by an agent of payor bank4at step27.

When a bank becomes a client of the fraud detection system10provider in certain embodiments, an implementation project is first created that defines all the required setup and processes required. To minimize project risk and streamline the implementation, requirements for the bank are minimal. The primary tasks that must be completed are user setup, event configuration, and connectivity for transmission of data files from the bank to the provider at fraud detection system10.

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.

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 by 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 amount, an event may be created. Any user subscribed to this event would receive an immediate notification.

Prior to processing an X9 file30, the file will be sent to the system for analysis. This data file can be sent via a web service, or the bank may use secure file transfer protocol (SFTP) to send the file. For security reasons, the SFTP location will be protected by firewall settings that only allow certain whitelisted IP addresses to access the SFTP location. In some cases a virtual private network (VPN) connection may be required by the bank for enhanced security as well.

The fraud detection system10, in certain embodiments, requires data from check writers to populate the global check register (GCR)14, and X9 files30containing 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).

GCR data can be sent directly from the bank or the bank's individual clients via an integration with the bank client's accounting system. This data is stored in GCR14and is used to validate the check data presented in the X9 file30. The data collected for GCR14in certain embodiments consists of the check number, date written, payee, and amount.

An X9 file30, as described above and also known as an Image Cash Letter (ICL) file, is a standardized file format used in the banking industry for the electronic exchange of check images and associated information. This format is defined by the ANSI X9.100-187 standard, which specifies the layout for electronic files containing check images to be sent to and processed by banks. The X9 file30enables banks to handle check deposits electronically rather than dealing with physical checks, thus facilitating faster and more efficient check processing. As banks are processing X9 check files30for clearing, a copy of the X9 file30will be sent to the fraud detection system10to compare the data on the checks contained within the file to the data within GCR14.

With this background, and continuing with reference toFIGS.1A and1B, a process for utilizing fraud detection system10may now be described. The process begins with check creation and distribution. A check writer2(i.e., the party issuing the check) generates a check within its accounting software at step1. The check is then sent to the payee (i.e., the party receiving the check) at step3. Parallel to this, an accounts payable (AP) file is created at step7for third-party check creation processing at accounting function22. The check payee6receives the check and deposits it at their bank, known as the payee bank28, at step9. Accounting function22may interact with the fraud detection system10by sending data through system FTP24or system API26.

To process the check, the payee bank4creates an Image Cash Letter (X9) file30, which contains the digital image of the check. This is sent to the payor bank (the bank of the check writer), shown as bank28inFIG.1. The payor bank4then sends X9 file30to fraud detection system10for analysis, using either system FTP24or system API26, as desired by payor bank4.

The X9 file30is queued for processing by fraud detection system10. Image processing occurs on all checks found in the X9 file30at image processor (i.e., OCR system)16, which is a part of process management service12of fraud detection system10. Optionally, an external vision AI service32may also be used to provide image processing to provide additional data, such as in the case when image processor16returns a result that there is no match.

The image processor16returns a result object that contains the full result set of the analysis. Based on the validation result, fraud detection system10will recommend to payee bank28that it accept the check if it matches known data; that it reject the check if discrepancies are found, indicating potential fraud; or refer the check for manual review if it requires further investigation, at step19. In addition to recommending an action for the check, the result object contains data points related to confidence scoring of the analysis and various other data points.

Based on the results of the analysis, fraud detection system10will update its internal logs and create the appropriate notification events within the event notification service20at step31. For accepted checks, the payor bank4updates processing logs and archives data files, the check is paid, and funds are debited from the check writer's account at step29. For rejected or referred checks, the check writer2receives a notice of validation failure at step21, and the check may be manually reviewed by the payor bank4at step27. If determined to be fraudulent, the check is returned to the payee bank28at step23. At the payee bank28, the returned check may then be processed accordingly in a normal fashion.

This process flow ensures that from the moment a check is issued up until the final point of completion, fraud detection system10provides a rigorous security measure, vetting every transaction and acting as a shield against check fraud. It highlights the fraud detection system10's role in real-time analysis and fraud prevention, demonstrating a systematic approach to protecting both check writers and payees in financial transactions.

Referring now to the flow chart ofFIG.2, the process flow within event notification service20may be described in greater detail. When anomalies are detected between the known data points within the GCR14(shown inFIG.1) and the data obtained from the X930check 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 system10implements a robust event management system, as implement and shown inFIG.1as event notification service20.

When an event is created at step40ofFIG.2, the details including the Event Message, Event Type Identifier, Check Identifier and Action Type, are stored in the Event Queue at step42. A separate process executes to process all events pended in the queue. This process first fetches any pending events from the queue, and then loops through the events performing the same steps for each.

For each event, the next step is to determine the Event Type and Account Information from the event data and initiate tracking at step44. Then at step46the event notification service20retrieves a list of users that are subscribed to the Event Type for the specific company related to the check that caused the event at step46. At step48, the event notification service20determines the messaging type (SMS, email, or both) that the user has selected for its default notification method. Then, also at step48, 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.

At step20, the system queries whether the message was successfully sent to the user. If the message fails, then the system creates a system administrator alert at step52so that appropriate actions may be immediately taken, and the error is shown in Update Event tracking status at step56. If the message is sent successfully, then processing proceeds to Update Event tracking status to show a successful send at step54.

The flow chart ofFIG.3provides additional detail concerning the operating of image processor16. The process begins with the initialization of the system responsible for processing checks at step60. The system fetches an item from the X9 file30to process at step62. This file contains one or more check images and associated data.

Next, at step63, check information is extracted from the X9 file30stream. The system iterates through each check item within the X9 file30. For each check item, the system queries the Global Check Register (GCR) database14to retrieve associated check data at step66. If the check is found in GCR14at query step68, the system proceeds with the next steps. If not, an alert is created for the unknown check at step70. The alert is handled by event notification service20as described above with respect toFIG.2.

Each check that is recognized by GCR14is submitted to the check reader18at step72. (Note that the processing steps of check reader18will be described more fully below with respect toFIG.4.) Check reader18returns a Resolution Object, which contains the results of the check analysis. The results from check reader18are then recorded in GCR14.

At query step76, the system evaluates whether the result is acceptable. If the result is not acceptable, it continues to check if the result suggests rejection or referral at step82. If the result is to reject the check, the system creates a Rejection Event at step80. If the result does not warrant rejection, but the check does not meet the criteria for acceptance, the system creates a Referral Event, indicating that the check requires further review, at step82. If the result is acceptable, the system updates the logs at step84to reflect the successful processing of the check.

After handling the current check, the system reads the next check in the X9 file30stream, and the process repeats back at step66.

Check reader18processing, using image processor16, may be more fully described with reference to the flow chart ofFIG.4. The check image is submitted to check reader18at step90, along with the monetary amount of the check as reported in the X9 data file30received from the bank after extraction at step92.

A region of interest (ROI) is defined at step94, 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.

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 step96in 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 step96, 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 processor16) and optionally vision AI32recognizing the letter as if the white space did not exist. This manipulation of the cropped ROI image results in significantly higher accuracy.

At step98, the manipulated ROI image is analyzed by the image processor16to determine the text value of the payee name contained in the image. The resolution object is created and the results of the OCR analysis are added to the resolution object. This data consists of the data observed in the payee region and the confidence score of the observation.

At query step100, the observed value from the OCR analysis is compared to the known payee data from GCR14. If the observed value matches the known payee, the resolution object is updated to indicate an OCR match at step106. If the configuration settings for the analysis indicates that processing is to stop upon OCR match at query step108, then then the resolution object's Vision property is set to false at step110(due to the fact the vision AI32service did not analyze the image) and the resolution object is returned to image processor16at step122.

If the observed value does not match the known payee data at query step100, then the resolution object is updated to reflect an OCR mis-match at step102. The observed value and the known payee data values are compared at step104to create a score based on the similarity of the two values. (Scoring will be described in more detail below with reference toFIGS.5A,5B, and5C.) The resolution object is updated to contain the comparative text score.

At step112, the image is now submitted to the vision AI engine32to determine the value contained within the check's payee ROI. If the observed value does not match the known payee data at query step114, then the system will submit the observed value and the known payee value to the comparative text scoring function at step118to create a match score and update the resolution object to indicate a vision AI mis-match at step116. The system then returns the resolution object to image processor16at step122.

If the observed value matches the known payee data at query step114, then check reader18updates the resolution object to indicate a payee match at step120, and returns the resolution object to image processor16at step122.

With reference now to the flow chart ofFIGS.5A,5B, and5C, the process for comparative text scoring within process management service12may be described in more detail. When an exact match is not found between the known payee text value (target) and the payee text extracted from the check image (found), this score is computed to determine a degree of similarity between the found text and the target text.

At step130, the comparative text score function accepts two string values, referred to herein as strTarget and strFound, corresponding to the expected text string and the one actually read from the check, respectively. All spaces and special characters are removed from the string values and the values are converted to lower case at step132. If the lengths of the strings are not equal as determined at query step134, then the shorter string value is right padded with spaces at step136. This ensures both values have the same length.

A two-dimensional array is created, referred to herein as bCompare, to store integer values at step138. The array size is based on the size of the input strings. For example, assume the strings “Somethingofinterest” and “Somewhereofinterests” are being compared, then the calculation of the array size would be as follows, using the length of the longer string:

strFound=somethingofintereststrTarget=somewhereofinterestsbCompare=array⁢of⁢integers⁢with⁢size⁢20×20

Next, the array is populated based on a bit-wise comparison of the strings. In each cell within the matrix, the system compares the string character in the X row (expected) to the string character in the Y column (found). If the values are equal, then the system store the binary value “1” in the matrix, otherwise, the system store a “0”. Specifically, the system at query step142, checks whether the x value has exceeded the matrix row size. If not, then at query step144the system checks whether the y value has exceeded the matrix column size. If yes, then processing returns to query step142and the x value is incremented by 1. If no, then at query step146the system determines whether these two characters match in the target and found strings. If not, the binary “0” is stored in the matrix at step152, and if so then the binary “1” is stored in the matrix at step148. In either case, the y value is incremented by 1 at step154, and processing returns to query step144. In an example, this results in a bCompare matrix as shown inFIG.6A(wherein the corresponding strings are “someonenice” and someoneniece”).

It is noteworthy that when two strings are exactly equal, the cells on the diagonal from (0,0) through (11,11) will all be “1” and all other cells will be “0”. Additionally, if a series of characters don't match two or more sequential values, then result will be values of “1” that are surrounded by “0”s. These results are considered “noise” for purposes herein. These noise results are removed from the matrix by replacing the “1” with “0”. This noise removal process ignores all cells on the diagonal from cell (0,0) to cell (11,11), leaving them unchanged since they are the data of interest.

To perform noise removal, processing begins at step156with the creation of a clone matrix of bCompare, called herein bCompareClean. All x, y, and iSum (explained below) values for bCompareClean are initially set to zero at step158. The process iterates through each x value (query step160) and y value (query step162), incrementing for each subsequent x value at step168and each y value at step178in order to process over the entirety of each matrix.

At query step164, the system determines if the x and y values are both zero, or if the value in question is along the diagonal from (0,0) to (n,n). If either of these conditions is true, then the corresponding element of bCompareClean is set to be the same as the value in the corresponding cell of bCompare at step166. This step keeps the diagonal portion of bCompareClean the same as the value in bCompare, and also keeps the cells intact that do not contain noise. If neither of these conditions are true, however, then at step170the iSum is set to “0” to remove noise. Then the element in the array that is to the upper left of the current cell is examined, and this element's value is added to the iSum at step172.

After this, the element that is to the lower right of the current cell is examined, and this element's value is also added to the running iSum at step174. The bCompare matrix is updated with the iSum value at step176. After this process is iterated over each y value, so that there is an iSum value for each row, and at the end of the complete iterative process the noise is removed from the matrix as described above.

Next, the matrix must be shifted such that all values in column one are shifted up by 1 position, all values in column 2 are shifted up 2 positions, etc. with values wrapping from the top to the bottom of the matrix, performed at step180, and duplicate values are removed at step182. After performing noise removal and the shift transformation on the matrix ofFIG.6A, the values now are arranged as shown inFIG.6B.

After shifting the matrix as shown inFIG.6B, the system may begin the process of scoring the results. The scoring process is predicated on several fundamental principles. First, a perfect match is represented by a single row of “1” values in the top row. Second, phrases that are similar will result in one or more fragments of strings that match. Fragmentation is represented by shorter sequences of “1”s and dispersion of the sequences throughout the matrix. Third, string fragments that are close to each other will be represented closer to the top of the matrix, and fragments that are not close to each other will be appear lower in the matrix.

Scoring begins with adding the values of each row. These values are stored in an array, rowSum( ) as shown inFIG.6C. RowPctOfSize is computed as the row sum divided by the number of values in the row, referred to herein as iSize. The row sum iX is initially set to zero at step184.

At steps186and188, the system iterates over iX and iY, respectively, incrementing iX at step190. So long as both iX and iY are not greater than iSize, then the shiftedMatrix operation is performed at step192. When iY becomes equal to iSize, then if rowSum(iX) is greater than 0 at step194, the rowsMatched value is incremented at196. Then iY is reset to a value of 0 and iX is incremented by one at step198.

At step200, the DispersionScore is calculated. In the example provided inFIGS.6A,6B, and6C, there is very little dispersion. All match sequences appear on rows 1 and 2. This indicates the sequences not only matched, but the fragments were very close to one another. The dispersion score is calculated as follows:
DispersionScore=((RowLength−RowsMatched)+1)/(RowLength)
Therefore, in the example data, the DispersionScore=((12−2)+1)/(12)=91.667%.

The RowWeight calculation at step202determines the significance of the rowSum values based on the row in which the value resides. Values in the upper rows are better matches than values from lower rows. RowWeight is determined by assigning 100% to row 0. Then each RowWeight for subsequent rows is reduced by a value of (1/(number of rows)) at step202. Finally, the RowScore is computed by multiplying the RowPctOfSize value by the RowWeight value at step204, as shown in the results ofFIG.6C.

The row score is now used to create an adjusted score based on the dispersion of the matches throughout the matrix. The DispersionScore is used to magnify the row score if it is larger than the row score, or diminish the row score if it is smaller than the row score. In the example data, the row score is 77.778%. The DispersionScore is 91.667%, which indicates that while the data values don't match exactly, the fragments are very close to each other. Therefore the adjusted score is modified to be higher than the initial row score. Specifically:
DispersionAdjustedScore=(DispersionScore−RowScore)/2+RowScore

Therefore, in this example, DispersionAdjustedScore=(0.91667−0.7778)/2+0.77778=84.0277%. To perform this calculation, iX is set to a value of zero at step208. As long as iX remains less than or equal to iSize, Score is recalculated at step210as the sum of the current Score value plus the product of the rowPctOfSize for iX and the rowWeight for ix. At step212the system iterates to the next iX value. Once iX exceeds iSize (in other words, the entire row has been processed), the DiversionAdjScore (adjusted diversion score) is calculated at step214.

Finally, at step216, the system returns a result object that contains the following properties:Value1 (“someonenice”)Value2 (“someoneniece”)RawScore (76.3888%)DispersionScore (91.667%)DispersionAdjustedScore (84.0277%)

The systems and methods described herein may in various embodiments be implemented by any combination of hardware and software. For example, in one embodiment, the methods may be implemented by a plurality of computer systems (e.g., each of which being a computer system as inFIG.7) or a collection of computer systems, each of which includes one or more hardware processors executing program instructions stored on a computer-readable physical storage medium coupled to the hardware processors.

The program instructions may implement the functionality described herein (e.g., the functionality of various hardware servers and other components that implement the network-based cloud and non-cloud computing resources described herein). The various methods as illustrated in the figures and described herein represent example implementations. The order of any method may be changed, and various elements may be added, modified, or omitted.

FIG.7is a block diagram illustrating an example computer hardware system, according to various embodiments. Computer system240may implement a hardware portion of a cloud computing system or non-cloud computing system, as forming parts of the various implementations of the present invention. Computer system240may be any of various types of hardware devices, including, but not limited to, a commodity server, personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, handheld computer, workstation, network computer, a consumer device, application server, physical storage device, telephone, mobile telephone, or in general any type of computing node, compute node, compute device, and/or hardware computing device.

Computer system240includes one or more hardware processors241a,241b. . .241n(any of which may include multiple processing cores, which may be single or multi-threaded) coupled to a physical system memory242via an input/output (I/O) interface244. Computer system240further may include a network interface246coupled to I/O interface244. In various embodiments, computer system240may be a single processor system including one hardware processor241a, or a multiprocessor system including multiple hardware processors241a,241b. . .241nas illustrated inFIG.7.

Processors241a, etc. may be any suitable processors capable of executing computing instructions. For example, in various embodiments, processors241a, etc. may be general-purpose or embedded processors implementing any of a variety of instruction set architectures. In multiprocessor systems, each of processors241a, etc. may commonly, but not necessarily, implement the same instruction set.

The computer system240also includes one or more hardware network communication devices (e.g., network interface246) for communicating with other systems and/or components over a communications network, such as a local area network, wide area network, or the Internet. For example, a client application executing on system240may use network interface246to communicate with a server application executing on a single hardware server or on a cluster of hardware servers that implement one or more of the components of the systems described herein in a cloud computing or non-cloud computing environment as implemented in various sub-systems. In another example, an instance of a server application executing on computer system240may use network interface246to communicate with other instances of an application that may be implemented on other computer systems.

In the illustrated embodiment, computer system240also includes one or more physical persistent storage devices248and/or one or more I/O devices250. In various embodiments, persistent storage devices248may correspond to disk drives, tape drives, solid-state memory or drives, other mass storage devices, or any other persistent storage devices.

Computer system240(or a distributed application or operating system operating thereon) may store instructions and/or data in persistent storage devices248, as desired, and may retrieve the stored instructions and/or data as needed. For example, in some embodiments, computer system240may implement one or more nodes of a control plane or control system, and persistent storage248may include the solid-state drives (SSDs) attached to that server node. Multiple computer systems240may share the same persistent storage devices248or may share a pool of persistent storage devices, with the devices in the pool representing the same or different storage technologies, including such technologies as described above.

Computer system240includes one or more physical system memories242that may store code/instructions243and data245accessible by processor(s)241a, etc. The system memories242may include multiple levels of memory and memory caches in a system designed to swap information in memories based on access speed, for example. The interleaving and swapping may extend to persistent storage devices248in a virtual memory implementation, where memory space is mapped onto the persistent storage devices248. The technologies used to implement the system memories242may include, by way of example, static random-access memory (RAM), dynamic RAM, read-only memory (ROM), non-volatile memory, solid-state memory, or flash-type memory. As with persistent storage devices248, multiple computer systems240may share the same system memories242or may share a pool of system memories242. System memory or memories242may contain program instructions243that are executable by processor(s)241a, etc. to implement the routines described herein.

In various embodiments, program instructions243may be encoded in binary, Assembly language, any interpreted language such as Java, compiled languages such as C/C++, or in any combination thereof; the particular languages given here are only examples. In some embodiments, program instructions243may implement multiple separate clients, server nodes, and/or other components.

In some implementations, program instructions243may include instructions executable to implement an operating system (not shown), which may be any of various operating systems, such as UNIX, LINUX, Solaris™, MacOS™, or Microsoft Windows™. Any or all of program instructions243may be provided as a computer program product, or software, that may include a non-transitory computer-readable storage medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to various implementations.

A non-transitory computer-readable storage medium may include any mechanism for storing information in a form (e.g., software or processing application) readable by a machine (e.g., a physical computer). Generally speaking, a non-transitory computer-accessible medium may include computer-readable storage media or memory media such as magnetic or optical media, e.g., disk or DVD/CD-ROM, coupled to or in communication with computer system240via I/O interface244. A non-transitory computer-readable storage medium may also include any volatile or non-volatile media such as RAM or ROM that may be included in some embodiments of computer system240as system memory242or another type of memory. In other implementations, program instructions may be communicated using optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.) conveyed via a communication medium such as a network and/or a wired or wireless link, such as may be implemented via network interface246. Network interface246may be used to interface with other devices252, which may include other computer systems or any type of external electronic device.

In some embodiments, system memory242may include data store245, as described herein. In general, system memory242and persistent storage248may be accessible on other devices252through a network and may store data blocks, replicas of data blocks, metadata associated with data blocks, and/or their state, database configuration information, and/or any other information usable in implementing the routines described herein.

In one embodiment, I/O interface244may coordinate I/O traffic between processors241a, etc., system memory242, and any peripheral devices in the system, including through network interface246or other peripheral interfaces. In some embodiments, I/O interface244may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory242) into a format suitable for use by another component (e.g., processors241a, etc.).

In some embodiments, I/O interface244may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, as examples. Also, in some embodiments, some or all of the functionality of I/O interface244, such as an interface to system memory242, may be incorporated directly into processor(s)241a, etc.

Network interface246may allow data to be exchanged between computer system240and other devices attached to a network, such as other computer systems (which may implement one or more storage system server nodes, primary nodes, read-only node nodes, and/or clients of the database systems described herein), for example. In addition, I/O interface244may allow communication between computer system240and various I/O devices250and/or remote storage248.

Input/output devices250may, in some embodiments, include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for entering or retrieving data by one or more computer systems240. These may connect directly to a particular computer system240or generally connect to multiple computer systems240in a cloud computing environment, grid computing environment, or other system involving multiple computer systems240.

Multiple input/output devices250may be present in communication with computer system240or may be distributed on various nodes of a distributed system that includes computer system240. In some embodiments, similar input/output devices may be separate from computer system240and may interact with one or more nodes of a distributed system that includes computer system240through a wired or wireless connection, such as over network interface246.

Network interface246may commonly support one or more wireless networking protocols (e.g., Wi-Fi/IEEE 802.11, or another wireless networking standard). Network interface246may support communication via any suitable wired or wireless general data networks, such as other types of Ethernet networks, for example. Additionally, network interface246may support communication via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks, via storage area networks such as Fibre Channel SANs, or via any other suitable type of network and/or protocol. In various embodiments, computer system240may include more, fewer, or different components than those illustrated inFIG.7(e.g., displays, video cards, audio cards, peripheral devices, or an Ethernet interface).

Any of the distributed system embodiments described herein, or any of their components, may be implemented as one or more network-based services in the cloud computing environment. For example, a read-write node and/or read-only nodes within the database tier of a hardware database system may present database services and/or other types of physical data storage services that employ the distributed storage systems described herein to clients as network-based services.

In some embodiments, a network-based service may be implemented by a software and/or hardware system designed to support interoperable machine-to-machine interaction over a network. A web service may have an interface described in a machine-processable format. Other systems may interact with the network-based service in a manner prescribed by the description of the network-based service's interface. For example, the network-based service may define various operations that other systems may invoke, and may define a particular application programming interface (API) to which other systems may be expected to conform when requesting the various operations.

In various embodiments, a network-based service may be requested or invoked through the use of a message that includes parameters and/or data associated with the network-based services request. Such a message may be formatted according to a particular markup language such as Extensible Markup Language (XML), and/or may be encapsulated using a protocol. To perform a network-based services request, a network-based services client may assemble a message including the request and convey the message to an addressable endpoint (e.g., a Uniform Resource Locator (URL)) corresponding to the web service, using an Internet-based application layer transfer protocol such as Hypertext Transfer Protocol (HTTP).

In some embodiments, network-based services may be implemented using Representational State Transfer (REST) techniques rather than message-based techniques. For example, a network-based service implemented according to a REST technique may be invoked through parameters included within an HTTP method such as PUT, GET, or DELETE.

Unless otherwise stated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, a limited number of the exemplary methods and materials are described herein. It will be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concepts herein.

All terms used herein should be interpreted in the broadest possible manner consistent with the context. In particular, the terms “comprises” and “comprising” should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps may be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced.

When a grouping is used herein, all individual members of the group and all combinations and subcombinations possible of the group are intended to be individually included.

When a range is stated herein, the range is intended to include all sub-ranges within the range, as well as all individual points within the range.

When “about,” “approximately,” or like terms are used herein, they are intended to include amounts, measurements, or the like that do not depart significantly from the expressly stated amount, measurement, or the like, such that the stated purpose of the apparatus or process is not lost.

All references cited herein are hereby incorporated by reference to the extent that there is no inconsistency with the disclosure of this specification.

The present invention has been described with reference to certain preferred and alternative embodiments that are intended to be exemplary only and not limiting to the full scope of the present invention, as set forth in the appended claims.