AU2013100299B4 - Computer implemented frameworks and methodologies for enabling the categorisation and management of transaction data - Google Patents

Abstract

Abstract A computer implemented method for capturing an image, the method including: receiving an instruction to commence capture of a physical object; optimising configuration parameters of an image capture device based in a predefined set of pre-capture image optimisation rules, wherein the rules are optimised based on one or more characteristics of the object and one or more characteristics of a data extraction process; capturing an image including a target thereby to define captured image data; processing the captured image data based on a predefined set of post-capture image optimisation rules thereby to define optimised captured image data, wherein the rules are optimised based on one or more characteristics of the object and one or more characteristics of a data extraction process; and performing the data extraction process in respect of the optimised captured image data thereby to define extracted data, wherein the extracted data includes alphanumeric data.

Description

1 COMPUTER IMPLEMENTED FRAMEWORKS AND METHODOLOGIES FOR ENABLING THE CATEGORISATION AND MANAGEMENT OF TRANSACTION DATA FIELD OF THE INVENTION [0001] The present invention relates to computer implemented frameworks and methodologies for enabling the categorisation and management of transaction data. Embodiments of the invention have been particularly developed for enabling a user to conveniently manage and categorize receipts, for example receipts in paper and/or electronic formats While some embodiments will be described herein with particular reference to that application, it will be appreciated that the invention is not limited to such a field of use, and is applicable in broader contexts. BACKGROUND [0002] Any discussion of the background art throughout the specification should in no way be considered as an admission that such art is widely known or forms part of common general knowledge in the field. [0003] Receipt management is a significant challenge for many consumers. Receipts issue in a number of different forms, both physical and electronic, and stem from a wide range of issuers. There is a need in the art for improved frameworks and methodologies for enabling the categorisation and management of transaction data. SUMMARY OF THE INVENTION [0004] It is an object of the present invention to overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative. [0005] One embodiment provides a computer implemented method for capturing an image, the method including: [0006] receiving an instruction to commence capture of a physical object; 2 [0007] optimising configuration parameters of an image capture device based in a predefined set of pre-capture image optimisation rules, wherein the rules are optimised based on one or more characteristics of the object and one or more characteristics of a data extraction process; [0008] capturing an image including a target thereby to define captured image data; [0009] processing the captured image data based on a predefined set of post-capture image optimisation rules thereby to define optimised captured image data, wherein the rules are optimised based on one or more characteristics of the object and one or more characteristics of a data extraction process; and [0010] performing the data extraction process in respect of the optimised captured image data thereby to define extracted data, wherein the extracted data includes alphanumeric data. [0011] One embodiment provides a computer implemented method for transaction data management, the method including: [0012] receiving an instruction to commence capture of a physical transaction record; [0013] optimising configuration parameters of an image capture device based in a predefined set of pre-capture image optimisation rules; [0014] capturing an image including the physical transaction record thereby to define captured image data; [0015] processing the captured image data based on a predefined set of post-capture image optimisation rules thereby to define optimised captured image data; and [0016] performing a data extraction process in respect of the optimised captured image data thereby to define extracted data, wherein the extracted data includes alphanumeric data. [0017] One embodiment provides a computer implemented method for transaction data management, the method including: 3 [0018] receiving data indicative of captured transaction records, wherein the captured transaction records include at least one transaction record captured via an image capture device and at least one transaction record captured from email data; [0019] maintaining a data store of captured transaction records awaiting categorisation; and [0020] providing a categorisation module configured to enable a user to categorise transaction records in the data store. [0021] One embodiment provides a computer implemented method for transaction data management, the method including: [0022] receiving data indicative of a transaction record; [0023] identifying data fields in the transaction record; [0024] applying a predictive categorization algorithm thereby to assign predicted categories to one or more of the identified data fields; [0025] providing a categorisation interface thereby to enable a user to review the predicted categories and selectively, for each data field, to approve a data field, thereby to define an approved data field, wherein the approving includes: [0026] (i) approving the predicted category for that data field; or [0027] (ii) manually assigning a category to the data field; [0028] based on the approved data fields, updating a database of transaction values. [0028a] One embodiment provides a computer implemented method for transaction data management, the method including: [0028b] receiving data indicative of a transaction record; [0028c] identifying data fields in the transaction record; 3a [0028d] applying a predictive categorization algorithm thereby to assign predicted categories to one or more of the identified data fields; [0028e] operating a categorisation interface thereby to enable a user to review the predicted categories and selectively, for each data field, to approve a data field, thereby to define an approved data field, wherein the approving includes: [0028f] (i) approving the predicted category for that data field; or [0028g] (ii) manually assigning a category to the data field; [0028h] based on the approved data fields, updating a database of transaction values; [0028i] wherein applying the predictive categorisation algorithm includes: [0028j] determining whether the transaction record corresponds to a local template defined based on a local learning process; and [0028k] in the case that the transaction record does not correspond to a local template, submitting a query to a remote server thereby to determine whether the transaction record corresponds to a global template defined based on a global learning process. [0029] One embodiment provides any combination of subject matter described herein. [0030] One embodiment provides a computer program product for performing a method as described herein.

4 [0031] One embodiment provides a non-transitive carrier medium for carrying computer executable code that, when executed on a processor, causes the processor to perform a method as described herein. [0032] One embodiment provides a system configured for performing a method as described herein. [0033] Reference throughout this specification to "one embodiment", "some embodiments" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases "in one embodiment", "in some embodiments" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, but may. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments. [0034] As used herein, unless otherwise specified the use of the ordinal adjectives "first", "second", "third", etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner. [0035] In the claims below and the description herein, any one of the terms comprising, comprised of or which comprises is an open term that means including at least the elements/features that follow, but not excluding others. Thus, the term comprising, when used in the claims, should not be interpreted as being limitative to the means or elements or steps listed thereafter. For example, the scope of the expression a device comprising A and B should not be limited to devices consisting only of elements A and B. Any one of the terms including or which includes or that includes as used herein is also an open term that also means including at least the elements/features that follow the term, but not excluding others. Thus, including is synonymous with and means comprising. [0036] As used herein, the term "exemplary" is used in the sense of providing examples, as opposed to indicating quality. That is, an "exemplary embodiment" is an 5 embodiment provided as an example, as opposed to necessarily being an embodiment of exemplary quality. BRIEF DESCRIPTION OF THE DRAWINGS [0037] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: [0038] FIG. 1A schematically illustrates a framework according to one embodiment. [0039] FIG. 1B schematically illustrates a framework according to one embodiment. [0040] FIG. 2A illustrates a method according to one embodiment. [0041] FIG. 2B illustrates a method according to one embodiment. [0042] FIG. 2C illustrates a method according to one embodiment. [0043] FIG. 2D illustrates a method according to one embodiment. [0044] FIG. 3 illustrates an exemplary client-server arrangement. [0045] FIG. 4A illustrates exemplary user interface screenshots. [0046] FIG. 4B illustrates an exemplary process flow. [0047] FIG. 4C illustrates an exemplary user interface screenshot. [0048] FIG. 4D illustrates an exemplary process flow. DETAILED DESCRIPTION [0049] Described herein are computer implemented frameworks and methodologies for enabling the categorisation and management of transaction data, and in some cases other data. Embodiments of the invention have been particularly developed for enabling a user to conveniently manage and categorize receipts, for example receipts in paper and/or electronic formats While some embodiments will be described herein with 6 particular reference to that application, it will be appreciated that the invention is not limited to such a field of use, and is applicable in broader contexts. [0050] As used herein, the terms "transaction record" and "receipt" are used interchangeably to describe a set of information, stored on hard-copy media or in an electronic format, which provides details of a transaction. In this regard, a transaction record or recept inherently includes a plurality of "data fields" (for examples discrete portions of data) which each have meanings. In the present disclosure, "categories" are used to describe these meanings. For example, assigning a data field to a category of "total purchase amount" results in the data within that data field (which is likely to be numerical data in this example) is categorised as a "total purchase amount". Exemplary Framework [0051] FIG. 1A illustrates an exemplary framework according to one embodiment, including various hardware/software components configured to provide functionality for various embodiments. It should be noted that, although FIG. 1 illustrates a number of exemplary components, modules and functionalities, it is by no means necessary that all functionalities be present in a given embodiment. Rather, for the sake of efficient explanation, a number of optional features and functionalities are grouped together into the embodiment of FIG. 1A. It should additionally be appreciated that any client-side software component could be wholly or partially provided as a server-side software component, and vice versa. For example, in a further embodiment the client-side functionalities are provided via a browser-based arrangement, and all substantive processing functionalities are preformed at the server-side. However, in the context of FIG. 1, an arrangement is described whereby a proprietary application executes on a client device 100. [0052] Client device 100 may be embodied by a smartphone, tablet, PDA, PC, or substantially any device with functionality to provide a user interface and communicate with a central server. Device 100 includes a processor 101 coupled to a memory module 102. This memory module provides software instructions (i.e. computer executable code), including software instructions for a client application ("client app") 110. Device 100 additionally includes input modules 104 (such as a touchscreen, buttons, or the like), and a display 105 which allows rendering of a user interface 106 defined by software instructions 104. A communications module 107 (which may provide functionality such as 7 GPRS, WiFi, Bluetooth, or substantially any other communications standard). A camera module 108 allows for image capture (for example via optical components coupled to a CMOS sensor, or another digital camera arrangement). [0053] Client app 110 includes a variety of software modules, which may include some or all of those illustrated in FIG. 1A (or FIG. 1B). These are discussed below [0054] User interface modules 111. These include code for permitting the rendering of user interface 106. The manner by which user interface modules are coded varies between embodiments. It will be appreciated that there may be overlap between user interface modules 111 and other modules discussed below. [0055] A receipt capture module 112. This module is configured to coordinate receipt capture functionalities, which discussed further below. In overview, receipt data is obtained from a receipt, which may be a hard copy receipt (in which case image capture may be used) or an electronic receipt (which ay, for example, have been received by email). This receipt data is then classified by categorization of data fields identified within the receipt (for example classifying one field as "purchase amount", another as "vendor" and so on)). In some embodiments there is an additional step of receipt purpose categorisation, whereby a receipt is associated with a particular purpose category (for example "rent", "transport", "food", "communications", and so one). In some cases a user is enabled to define custom purpose categories based on their own needs. In some cases a given receipt total is able to be apportioned between multiple purpose categories. [0056] A camera control module 113. This is configured to control configuration parameters and image capture via camera module 108. For example, app 110 is configured to enable capturing of image data containing a hard copy receipt, thereby to enable the extraction of receipt data from the captured image data. Module 113 is configured to enable control of the camera for such purposes, including providing image capture instructions, and control over camera/capture parameters (such as white balance and the like). [0057] An image processing module 114, configured to perform analysis on captured images (for example via OCR and/or other techniques). Preferably the image processing module is enabled to apply a plurality of processing techniques, including at least one 8 graphical extraction technique (such as OCR) and one file-analysis based extraction technique (such extracting portions of text from a text-enabled PDF file). [0058] A local template module 115. This module maintains a set of templates for transaction records (receipts), for example based on a schema which associates the location of data fields with categorization information for those data fields. For example, these templates may be defined based on a local learning algorithm (receipt templates are learned from a user's manual categorisation of receipts) and/or downloaded from a server (for example where the server maintains a set of templates, which are optionally defined based on local learning by a plurality of distributed users of app 110). [0059] A prediction module 116 is configured to perform predictive categorisation of data fields. For example, this module uses locally stored or remotely accessible receipt templates thereby to assist in classifying observed data fields. [0060] A learning module 117 is responsive to manual interactions with the app in the contest of data field classifications thereby to improve subsequent performance of the prediction module (for example by updating a set of prediction rules and/or templates). [0061] A server interaction module 118, which coordinates the communication of data between app 110 and one or more remote servers. In this embodiment, the servers include a transaction data management system 120. For example, in some cases a query is selectively placed to the server where a local template cannot be identified for a given receipt, thereby to determine whether there is a global template available. The global template is then downloaded, and in some cases modified following the user's categorisation of the invoice (for example purpose categorisation is in some cases heavily dependent on local user preferences). [0062] Transaction data management system 120 may be defined by a single server, or by a plurality of separate (and optionally distributed) server devices. System 120 includes hardware 121, including a processor 122, memory module 123, and network modules 124, in addition to software modules 125. The software modules include: A client interface module 126, configured to enable communication with a plurality of client devices that execute app 110 or another compatible application, such as device 100.

9 * A global template module, configured to manage a set of global templates. These may include purpose defined templates (for example for known common transaction record formats, such as those from major retailers) and a collection of templates collected from distributed users. In this manner, prediction module 116 is able to operate based on both local and global templates. * A global learning module 128, which is configured to update the global templates module based on interaction between users and their respective apps 100, such as at a secondary client device 150. For example, in some cases the global template module is updated each time a user categorises an invoice for which a local or global template could not be identified. * An email monitoring module 129, configured to monitor email accounts of users, for example an email server 160, (based on instructions provided by those users, thereby to identify emails containing electronic receipts (or suspected to contain electronic receipts) and push those to the app 100 of the relevant user for categorisation. * A third party server integration module 130, for receiving transaction record data directly from third party servers 170 (for example PayPal or the like), and communicating that to user devices for categorisation. * A banking integration module 131, for enabling communication with banking data sources 180. This may leverage services such as Yodlee or the like thereby to streamline delivery of banking data to client devices via app 110. [0063] System 120 operates in conjunction with a database 140 (or multiple such databases). Database 140 maintains user data, including data indicative of transaction records, categorised data from transaction records, eWallet data, and so on. Functionalities of various components shown in FIG. 1A will be discussed in more detail further below, by reference to various exemplary methods. Capture of Hard-Copy Transaction Records [0064] As foreshadowed above, device 100 is used to capture hard copy receipts via camera module 108. An exemplary camera-based input method 201 according to one 10 embodiment is disclosed in the context of method 200 of FIG. 2. It should be appreciated that method 201 is not limited to the task of capturing receipts, and it may be applied in the context of various other image capture applications. [0065] Functional block 202 represents a process including commencing an image capture process, for example subject to receiving, for example via user interface of device 100, an instruction to commence capture of a physical object. [0066] The method additionally includes, at 203, optimising configuration parameters of an image capture device based in a predefined set of pre-capture image optimisation rules, wherein the rules are optimised based on one or more characteristics of the object and one or more characteristics of a data extraction process. For example, based on characteristics of the data extraction process (e.g. nature of information to be extracted, environment of extraction, background colour, etc) settings such as white balance and other camera configuration parameters are optimised. In some cases pre-capture optimisation is influenced by one or more aspects of data received via the image capture device (for example amount of available light, colour of receipt substrate, colour of receipt text, and so on). [0067] Following this, an image is captured at 204 (including the physical transaction or other physical item) record thereby to define captured image data. It should be appreciated that, in this context, the term "capture" is used to describe a process whereby image data received via the image capture device is stored in memory as a capture object. A video capture device typically provides image/video data continuously during operation, although this is not "captured" in the sense of being stored in memory. In some cases the image capture process includes displaying on-screen guide objects (for example a grid, arrows to encourage movement, and/or other such guide objects) thereby to indicate a position at which a receipt should be positioned relative to the camera device. In some such cases capture occurs automatically upon identification by the underlying software that the receipt has been appropriately positioned. [0068] The method then includes, at 205, processing the captured image data based on a predefined set of post-capture image optimisation rules thereby to define optimised captured image data. These rules are optimised based on one or more characteristics of the object and one or more characteristics of a data extraction process. The post-capture rules are again defined based on, for example, the physical context of data to be 11 extracted, for example by adjusting exposure, contrast, and other image parameters. For example, this may be used to render black printed material clearer on a substantially white receipt substrate, thereby to increase the likelihood of effective OCR at a later stage. [0069] A data extraction process is then performed, at 206, in respect of the optimised captured image data. This results in the defining of extracted data, the extracted data including alphanumeric data (and optionally other data). For example, this may include performing an OCR -type processing technique to identify and extract alphanumeric data from the image data. Preferably spatially-based delimiters are identified thereby to separate the alphanumeric data into individual data fields, or otherwise enable logical separation of data aspects present within the captured receipt. [0070] Following step 206, receipt data is ready for categorisation at 208. Receipt categorisation is discussed in more detail further below; FIG. 2A provides one of a plurality of exemplary approaches for deriving receipt data for categorisation. [0071] A modified method 210 is shown in FIG. 2B, this being conducted in respect of an image (containing receipt data) from a source other than the camera module, for example via an imported image, PDF, or other data file. This may be received via email, from a photo album, or from substantially any other source. Image import method 211 of FIG. 2B commences with an image selection process 212, which may for example be triggered by a user instruction to commence categorisation of a receipt received via email or the like. The image is then imported at 213, which includes loading the image (or file containing the image data) into RAM, thereby to enable optional post capture optimisation at 205, and more importantly image processing at 206. The image processing in this case might use technologies other than OCR, for example where the image is defined in a file that inherently enables direct extraction of alphanumeric data (for example certain PDF files, CSV files, and so on). Again, following step 206, receipt data is ready for categorisation at 208. Collection of Transaction Records from Emails [0072] In the context of email, FIG. 2C illustrates a method 220, including a method 221 for preparing an email-based receipt for categorisation. In overview, a process executes in respect of a user's email account (either at device 100, server 120, or at another server associated with email) thereby to monitor incoming mail for receipts (or 12 suspected receipts). Where a receipt is found, it is extracted from the email (as an image for OCR processing or the like, or directly as alphanumeric data), and made available for categorisation. Data indicative of the emailed receipt (for example a PDF file, HTML data, text data, or the like) is received at 222. Receipt data is then extracted, either using image processing (if the receipt is image based) or direct data extraction (of the receipt is in a format wherein alphanumeric data is directly extractable, such as in an HTML-based email receipt). Receipt data is then ready for categorisation at 208. Collection of Transaction Records from Multiple Sources [0073] One embodiment includes a method of receiving data indicative of captured transaction records, wherein the captured transaction records include at least one transaction record captured via an image capture device and at least one transaction record captured from email data, maintaining a data store of captured transaction records awaiting categorisation, and providing a categorisation module configured to enable a user to categorise transaction records in the data store. FIG. 2D illustrates a method 230 relating to such an embodiment, showing a method for transaction data management that pools together transaction data from multiple sources. The illustrated sources are: * Camera-based input method 201, which uses a capture device on a smartphone (or other device) thereby to capture receipt data from a hard copy receipt. * Image import method 211, which imports receipt data from an electronic file selected by a user (or otherwise identified). * Email-based import method 211, which imports receipt data extracted from emails that are sent to an account associated with the user (in some embodiments being automatically identified subject to a monitoring process). * A third party notification method 231, whereby receipt data is directly delivered for processing subject to a purpose-designed receipt delivery mechanism. * A manual import method 241, for example a method whereby a user is enabled to manually input receipt (or transaction) data via a data entry process. This may, for example, be necessary in the case of handwritten receipts for which OCR extraction methods are not suitable.

13 [0074] It should be appreciated that these are not an exclusive selection. Following any of methods 201, 211, 221, 231 and 241, receipt data is ready for categorization at 208. Exemplary Transaction Record Categorisation Process [0075] One embodiment provides a computer implemented method for transaction data management, relating to the categorisation of a receipt/transaction record (in respect of which data is received in device 100 by any one of a variety of means; functional block 208 in FIG. 2A to FIG. 2D). The method includes receiving data indicative of a transaction record, and then identifying data fields in the transaction record. The identification of data fields is preferably achieved by either or both of the following techniques: * Determining whether the receipt is comparable to an existing receipt template (either locally or centrally stored), and applying a schema of that template thereby to determine data field locations. * Using a graphical analyse technique thereby to identify portions of data that are likely to represent individual fields. [0076] The method then includes applying a predictive categorization algorithm thereby to assign predicted categories to one or more of the identified data fields. This may be based upon the templates (for example where a template includes both data field locations and categories). It may also be based upon other factors, such as algorithms applicable to predict, based on the nature of a value in a data field, a likely categorisation. For example, it will be appreciated that a date-format value is likely to belong to a category "transaction date", and so on. [0077] The method then includes providing a categorisation interface thereby to enable a user to review the predicted categories and selectively, for each data field, to approve a data field, thereby to define an approved data field. The approving includes, for a given data field, one of the following: * Approving the predicted category for that data field.

14 Manually assigning a category to the data field (for example correcting a prediction, or manual assignment where no prediction was made. [0078] Based on the approved data fields, a database of transaction values is updated. There is preferably also a process of receipt categorisation, for example to categorise a purpose for the associated purchase (personal, work, transport, groceries, etc). This allows the database to be updated such that the values extracted from a receipt are both categorised in terms of their meaning (e.g. transaction price, tax amount, etc) purpose. Various other actions may then be taken in the context of receipt management, for example maintaining an accounting software package thereby to monitor spending, budgeting, and so on. In some embodiments receipt purpose categorisation is extendible thereby to enable purpose categorisation for individual line-items in a given receipt (or otherwise enable apportionment of a receipt total between multiple purposes. For example a receipt for food and petrol may be partially categorised to "food" and partially to "transport"). [0079] In some embodiments the predictive categorisation algorithm operates on the basis of a set of prediction rules, and the categorisation method includes updating the prediction rules based on the approved data fields. In this manner, a learning algorithm is applied, such that manual user input serves as a basis to improve future predictions. [0080] In some embodiments the method includes maintaining access to a repository of receipt templates which are accessed by the predictive categorisation algorithm. The repository of receipt templates preferably includes one or more receipt templates defined based on defining of approved data fields by the user, and one or more receipt templates defined at a central location. The one or more receipt templates defined at the central location preferably include receipt templates defined based on approval of data fields by distributed users (i.e. centralized learning via manual interactions of other users at other devices like device 100). [0081] The categorization interface implements an overlay-based graphical arrangement. Some exemplary screenshots are shown in FIG. 4A. These show a physical receipt ready for image capture, a captured mage, data fields with overlays, a final categorisation screen, and a summary screen showing collated transaction data from a plurality of receipts organised in a user selected manner (in this case by purchase, and then by vendor, shown in more detail in FIG. 4C).

15 [0082] FIG. 4B and FIG. 4D illustrates further process flows according to various embodiments. Integration with eWallet functionalities [0083] In some embodiments, for example as shown in FIG. 1B, receipt management is integrated with eWallet functionalities, thereby to allow reconciliation of receipts with bank account data, and optionally additionally provide a payment platform. Exemplary Client-Server Arrangement [0084] In some embodiments, methods and functionalities considered herein are implemented by client-server arrangement, as illustrated in FIG. 3. In overview, a web server 302 provides a web interface 303. This web interface is accessed by the parties by way of client terminals 304. In overview, users access interface 303 over the Internet by way of client terminals 304, which in various embodiments include the likes of personal computers, PDAs, cellular telephones, gaming consoles, and other Internet enabled devices. [0085] Server 303 includes a processor 305 coupled to a memory module 306 and a communications interface 307, such as an Internet connection, modem, Ethernet port, wireless network card, serial port, or the like. In other embodiments distributed resources are used. For example, in one embodiment server 302 includes a plurality of distributed servers having respective storage, processing and communications resources. Memory module 306 includes software instructions 308, which are executable on processor 305. [0086] Server 302 is coupled to a database 310. In further embodiments the database leverages memory module 306. [0087] In some embodiments web interface 303 includes a website. The term "website" should be read broadly to cover substantially any source of information accessible over the Internet or another communications network (such as WAN, LAN or WLAN) via a browser application running on a client terminal. In some embodiments, a website is a source of information made available by a server and accessible over the Internet by a web-browser application running on a client terminal. The web-browser application downloads code, such as HTML code, from the server. This code is executable through the web-browser on the client terminal for providing a graphical and 16 often interactive representation of the website on the client terminal. By way of the web browser application, a user of the client terminal is able to navigate between and throughout various web pages provided by the website, and access various functionalities that are provided. [0088] Although some embodiments make use of a website/browser-based implementation, in other embodiments proprietary software methods are implemented as an alternative. For example, in such embodiments client terminals 304 maintain software instructions for a computer program product that essentially provides access to a portal via which framework 100 is accessed (for instance via an iPhone app or the like). [0089] In general terms, each terminal 304 includes a processor 311 coupled to a memory module 313 and a communications interface 312, such as an internet connection, modem, Ethernet port, serial port, or the like. Memory module 313 includes software instructions 314, which are executable on processor 311. These software instructions allow terminal 304 to execute a software application, such as a proprietary application or web browser application and thereby render on-screen a user interface and allow communication with server 302. This user interface allows for the creation, viewing and administration of profiles, access to the internal communications interface, and various other functionalities. Conclusions and Interpretation [0090] It will be appreciated that the disclosure above provides various significant systems and methods for .... [0091] Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "processing," "computing," "calculating," "determining", analyzing" or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities into other data similarly represented as physical quantities. [0092] In a similar manner, the term "processor" may refer to any device or portion of a device that processes electronic data, e.g., from registers and/or memory to transform that electronic data into other electronic data that, e.g., may be stored in registers and/or 17 memory. A "computer" or a "computing machine" or a "computing platform" may include one or more processors. [0093] The methodologies described herein are, in one embodiment, performable by one or more processors that accept computer-readable (also called machine-readable) code containing a set of instructions that when executed by one or more of the processors carry out at least one of the methods described herein. Any processor capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken are included. Thus, one example is a typical processing system that includes one or more processors. Each processor may include one or more of a CPU, a graphics processing unit, and a programmable DSP unit. The processing system further may include a memory subsystem including main RAM and/or a static RAM, and/or ROM. A bus subsystem may be included for communicating between the components. The processing system further may be a distributed processing system with processors coupled by a network. If the processing system requires a display, such a display may be included, e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT) display. If manual data entry is required, the processing system also includes an input device such as one or more of an alphanumeric input unit such as a keyboard, a pointing control device such as a mouse, and so forth. The term memory unit as used herein, if clear from the context and unless explicitly stated otherwise, also encompasses a storage system such as a disk drive unit. The processing system in some configurations may include a sound output device, and a network interface device. The memory subsystem thus includes a computer-readable carrier medium that carries computer-readable code (e.g., software) including a set of instructions to cause performing, when executed by one or more processors, one of more of the methods described herein. Note that when the method includes several elements, e.g., several steps, no ordering of such elements is implied, unless specifically stated. The software may reside in the hard disk, or may also reside, completely or at least partially, within the RAM and/or within the processor during execution thereof by the computer system. Thus, the memory and the processor also constitute computer-readable carrier medium carrying computer-readable code. [0094] Furthermore, a computer-readable carrier medium may form, or be included in a computer program product. [0095] In alternative embodiments, the one or more processors operate as a standalone device or may be connected, e.g., networked to other processor(s), in a 18 networked deployment, the one or more processors may operate in the capacity of a server or a user machine in server-user network environment, or as a peer machine in a peer-to-peer or distributed network environment. The one or more processors may form a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. [0096] Note that while diagrams only show a single processor and a single memory that carries the computer-readable code, those in the art will understand that many of the components described above are included, but not explicitly shown or described in order not to obscure the inventive aspect. For example, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. [0097] Thus, one embodiment of each of the methods described herein is in the form of a computer-readable carrier medium carrying a set of instructions, e.g., a computer program that is for execution on one or more processors, e.g., one or more processors that are part of web server arrangement. Thus, as will be appreciated by those skilled in the art, embodiments of the present invention may be embodied as a method, an apparatus such as a special purpose apparatus, an apparatus such as a data processing system, or a computer-readable carrier medium, e.g., a computer program product. The computer-readable carrier medium carries computer readable code including a set of instructions that when executed on one or more processors cause the processor or processors to implement a method. Accordingly, aspects of the present invention may take the form of a method, an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of carrier medium (e.g., a computer program product on a computer-readable storage medium) carrying computer-readable program code embodied in the medium. [0098] The software may further be transmitted or received over a network via a network interface device. While the carrier medium is shown in an exemplary embodiment to be a single medium, the term "carrier medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or 19 associated caches and servers) that store the one or more sets of instructions. The term "carrier medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by one or more of the processors and that cause the one or more processors to perform any one or more of the methodologies of the present invention. A carrier medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical, magnetic disks, and magneto-optical disks. Volatile media includes dynamic memory, such as main memory. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise a bus subsystem. Transmission media also may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications. For example, the term "carrier medium" shall accordingly be taken to included, but not be limited to, solid-state memories, a computer product embodied in optical and magnetic media; a medium bearing a propagated signal detectable by at least one processor of one or more processors and representing a set of instructions that, when executed, implement a method; and a transmission medium in a network bearing a propagated signal detectable by at least one processor of the one or more processors and representing the set of instructions. [0099] It will be understood that the steps of methods discussed are performed in one embodiment by an appropriate processor (or processors) of a processing (i.e., computer) system executing instructions (computer-readable code) stored in storage. It will also be understood that the invention is not limited to any particular implementation or programming technique and that the invention may be implemented using any appropriate techniques for implementing the functionality described herein. The invention is not limited to any particular programming language or operating system. [00100] It should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, FIG., or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following 20 the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention. [00101] Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination. [00102] Furthermore, some of the embodiments are described herein as a method or combination of elements of a method that can be implemented by a processor of a computer system or by other means of carrying out the function. Thus, a processor with the necessary instructions for carrying out such a method or element of a method forms a means for carrying out the method or element of a method. Furthermore, an element described herein of an apparatus embodiment is an example of a means for carrying out the function performed by the element for the purpose of carrying out the invention. [00103] In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description. [00104] Similarly, it is to be noticed that the term coupled, when used in the claims, should not be interpreted as being limited to direct connections only. The terms "coupled" and "connected," along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Thus, the scope of the expression a device A coupled to a device B should not be limited to devices or systems wherein an output of device A is directly connected to an input of device B. It means that there exists a path between an output of A and an input of B which may be a path including other devices or means. "Coupled" may mean that two or more elements are either in direct physical or electrical contact, or that two or more elements are not in direct contact with each other but yet still co-operate or interact with each other. [00105] Thus, while there has been described what are believed to be the preferred embodiments of the invention, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it 21 is intended to claim all such changes and modifications as falling within the scope of the invention. For example, any formulas given above are merely representative of procedures that may be used. Functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.

Claims (5)

1. A computer implemented method for transaction data management, the method including: receiving data indicative of a transaction record; identifying data fields in the transaction record; applying a predictive categorization algorithm thereby to assign predicted categories to one or more of the identified data fields; operating a categorisation interface thereby to enable a user to review the predicted categories and selectively, for each data field, to approve a data field, thereby to define an approved data field, wherein the approving includes: (i) approving the predicted category for that data field; or (ii) manually assigning a category to the data field; based on the approved data fields, updating a database of transaction values; wherein applying the predictive categorisation algorithm includes: determining whether the transaction record corresponds to a local template defined based on a local learning process; and in the case that the transaction record does not correspond to a local template, submitting a query to a remote server thereby to determine whether the transaction record corresponds to a global template defined based on a global learning process.

2. A method according to claim 1 wherein the predictive categorisation algorithm operates on the basis of a set of prediction rules, and wherein the method includes updating the prediction rules based on the approved data fields.

3. A method according to claim 1 including maintaining access to a repository of receipt templates which are accessed by the predictive categorisation algorithm. 23

4. A method according to claim 3 wherein the repository of receipt templates includes one or more receipt templates defined based on defining of approved data fields by the user, and one or more receipt templates defined at a central location.

5. A method according to any preceding claim wherein the global learning process includes operating, at a server device, a global learning module configured to update a set of global templates module based on interaction between a plurality of categorisation interfaces.