METHODOLOGIES FOR ENABLING THE CATEGORISATION AND MANAGEMENT OF TRANSACTION DATA AND/OR PROVIDING FINANCIAL MANAGEMENT AND PAYMENT SOLUTIONS VIA MOBILE AND OTHER COMPUTING DEVICES

FIELD OF THE INVENTION

[0001] The present invention relates to computer implemented frameworks and methodologies for enabling the categorisation and management of transaction data and/or providing financial management and payment solutions via mobile and other computing devices. Some 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, and/or for providing additional functionalities relevant in the context of such an arrangement. 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.

SUM MARY 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;

[0007] optimising configuration parameters of an image capture device based on 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:

[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. [0029] One embodiment provides a computer implemented method for managing financial data, the method being performed based on software instructions executing at a mobile device, the method including:

[0030] providing a transaction record categorisation interface configured to enable the categorisation and extraction of transaction data from image data indicative of transaction records;

[0031] providing an electronic banking integration module that is configured to download transaction detail data from a user-specified bank account; and

[0032] providing a reconciliation interface configured to display, on a screen of the mobile device, extracted and categorised transaction data from one or more transaction records alongside at least a portion of the downloaded transaction detail data.

[0033] One embodiment provides a computer implemented method for managing financial data, the method being performed based on software instructions executing at a mobile device, the method including:

[0034] providing an interface thereby to enable transaction record data to be collected and categorised from imported transaction records, including at least one transaction record imported via image capture hardware provided by the mobile device;

[0035] providing an interface thereby to enable a input details for one or more banking account with respective financial institution;

[0036] for each of the one or more bank accounts, downloading from a remote server data indicative of transaction details; and

[0037] providing an interface for enabling reconciliation between the transaction record data and the downloaded transaction details.

[0038] One embodiment provides a computer implemented method for managing reimbursement data, including: [0039] receiving data indicative of one or more items for reimbursement, wherein the items are derived from data extracted from respective transaction records, wherein each item is associated with a user and a reimbursing party;

[0040] providing an interface thereby to enable a reimbursing party to view and selectively approve one or more items associated with that reimbursing party; and

[0041] in response to approval of an item, updating an item status of the item, wherein the item status is viewable by the user.

[0042] 16. A method according to claim 15 wherein the item data is received from users' mobile apps, wherein each mobile app is configured to enable extraction and categorisation of data from transaction records.

[0043] One embodiment provides a computer implemented method for managing financial data, the method being performed based on software instructions executing at a mobile device, the method including:

[0044] operating a transaction record categorisation interface that is configured to enable, via operation of a graphical interface by a user, the categorisation and extraction of transaction data from image data, wherein the image data is indicative of one or more transaction records, wherein the image data includes at least one image of a transaction record captured via a camera module of the mobile device;

[0045] operating an electronic banking integration module that is configured to download, from a remote server, transaction detail data from a user-specified bank account; and

[0046] providing a reconciliation interface configured to display, on a screen of the mobile device:

[0047] (iii) extracted and categorised transaction data derived from the operation of the transaction record categorisation interface from one or more transaction records; and

[0048] (iv) the downloaded transaction detail data; [0049] providing a graphical indication of correspondence between entries in the extracted and categorised transaction data and entries in the downloaded transaction detail data, thereby to assist a user in performing a reconciliation.

[0050] One embodiment provides a computer implemented method for managing financial data, the method being performed based on software instructions executing at a mobile device, the method including:

[0051] operating an interface thereby to categorise transaction record data from imported transaction records, including at least one transaction record imported via image capture hardware provided by the mobile device;

[0052] providing an interface thereby to enable a user to input details for one or more banking account with respective financial institution;

[0053] processing inputted details for each of the one or more banking accounts, thereby to automatically download, from a remote server, data indicative of transaction details; and

[0054] operating the device thereby to provide, in a graphical user interface, a graphical indication of correspondence between (i) entries in transaction record data and (ii) entries in the downloaded transaction detail data, thereby to assist a user in performing a reconciliation.

[0055] One embodiment provides a computer implemented method for transaction data management, the method including:

[0056] receiving data indicative of a transaction record;

[0057] identifying data fields in the transaction record;

[0058] applying a predictive categorization algorithm thereby to assign predicted categories to one or more of the identified data fields; [0059] 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:

[0060] (v) approving the predicted category for that data field; or

[0061] (vi) manually assigning a category to the data field;

[0062] based on the approved data fields, updating a database of transaction values;

[0063] wherein applying the predictive categorisation algorithm includes:

[0064] determining whether the transaction record corresponds to a local template defined based on a local learning process; and

[0065] 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.

[0066] One embodiment provides any combination of subject matter described herein.

[0067] One embodiment provides a computer program product for performing a method as described herein.

[0068] 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.

[0069] One embodiment provides a system configured for performing a method as described herein.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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 embodiment provided as an example, as opposed to necessarily being an embodiment of exemplary quality.

BRIEF DESCRIPTION OF THE DRAWINGS

[0074] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

[0075] FIG. 1A schematically illustrates a framework according to one embodiment. [0076] FIG. 1 B schematically illustrates a framework according to one embodiment. [0077] FIG. 2A illustrates a method according to one embodiment. [0078] FIG. 2B illustrates a method according to one embodiment.

[0079] FIG. 2C illustrates a method according to one embodiment.

[0080] FIG. 2D illustrates a method according to one embodiment.

[0081] FIG. 3 illustrates an exemplary client-server arrangement.

[0082] FIG. 4A illustrates exemplary user interface screenshots.

[0083] FIG. 4B illustrates an exemplary process flow.

[0084] FIG. 4C illustrates an exemplary user interface screenshot.

[0085] FIG. 4D illustrates an exemplary process flow.

[0086] FIG. 4E illustrates an exemplary process flow.

[0087] FIG. 4F illustrates exemplary user interface screenshots.

[0088] FIG. 5A schematically illustrates hybrid local/global learning.

[0089] FIG. 5B schematically illustrates reimbursement functionality.

DETAILED DESCRIPTION

[0090] 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 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. For example, other embodiments relate to functionalities provide din the contest of a receipt categorisation framework, relating to the likes of payment solutions, bank data reconciliation, and expense reimbursements. [0091] 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

[0092] 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.

[0093] 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 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). [0094] Client app 1 10 includes a variety of software modules, which may include some or all of those illustrated in FIG. 1A (or FIG. 1 B). These are discussed below

[0095] User interface modules 11 1. 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 1 11 and other modules discussed below.

[0096] A receipt capture module 1 12. 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.

[0097] A camera control module 1 13. 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).

[0098] 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 graphical extraction technique (such as OCR) and one file-analysis based extraction technique (such extracting portions of text from a text-enabled PDF file).

[0099] A local template module 1 15. 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). In some embodiments some or all templates (including templates defined based on learning from user interaction with device 100) are maintained by system 120 or another remote location, thereby to implement a "cloud-based" approach to template management.

[00100] A prediction module 1 16 is configured to perform predictive categorisation of data fields (and/or invoice purpose). For example, this module uses locally stored or remotely accessible receipt templates thereby to assist in classifying observed data fields. This includes determining, for example based on OCR extraction, a meaning for each extracted data portions (such as "vendor name", "total", "tax amount" and so on), and in some embodiments extends to predicting transaction purposes (for example "travel" "automotive", "food and beverage", "entertainment" and so on).

[00101] A learning module 117 is responsive to manual interactions with the app in the context 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).

[00102] A server interaction module 1 18, which coordinates the communication of data between app 1 10 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).

[00103] 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.

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 (for example in the context of a hybrid local/global learning method as discussed further below). In this manner, prediction module 1 16 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 1 10. In some embodiments banking integration module 131 operates in conjunction with a data processing module (optionally being a third party data processing module) that is configured to clean, format, and/or provide additional analysis in relation to raw data extracted from banking data services. [00104] 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

[00105] 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 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.

[00106] 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.

[00107] 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).

[00108] 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.

[00109] 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 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.

[00110] 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.

[0011 1] 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.

[00112] 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

[00113] 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 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

[00114] 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.

[00115] It should be appreciated that these are not an exclusive selection.

[00116] Following any of methods 201 , 211 , 221 , 231 and 241 , receipt data is ready for categorization at 208.

Exemplary Transaction Record Categorisation Process

[00117] 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.

[00118] Other approaches may be used, for example approaches that analysis extracted alphanumeric data without reference to positional information. [00119] 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.

[00120] 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.

• Manually assigning a category to the data field (for example correcting a prediction, or manual assignment where no prediction was made.

[00121] 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").

[00122] 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. [00123] 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).

[00124] 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).

[00125] FIG. 4B and FIG. 4D illustrates further process flows according to various embodiments.

Hybrid Local/Global Learning Methods

[00126] Preferably, a hybrid local/global learning method is implemented. The term "hybrid local/global learning method" refers to an approach whereby predictive categorisation is based upon both (i) local learning based on a user's interaction with their own device in the context of classification; and (ii) global learning based on the collective interaction of a plurality of users with their respective devices in the context of classification (optionally in addition with purpose-defined global templates defined directly rather than via learning). Global learning may be achieved by operating an algorithm that compares results of multiple users' local learning (for example based on templates defined based on local learning) and, where there is a threshold level of correlation, for instance "X" number of users defining a common template based on their own local interactions, that template is defined as a global template such that it becomes available to all users.

[00127] FIG. 5A illustrates an exemplary framework for a hybrid local/global learning method. A plurality of client devices 501 a-501 n are operated for the purposes of receipt categorisation (for example mobile devices running software as described further above). Each device performs a learning algorithm which learns templates based on the local user's categorisation. For example, these templates enable identification from image data portions of a receipt that define a vendor name, total amount, tax amount, and so on. Client devices 501a-501 n have respective local templates 502a-502n. Local templates may be stored either at a client device, and/or or cloud hosted.

[00128] Templates 502a-502n are used by the respective devices for future categorisations; if a vendor name associated with a local template is identified, then that local template may be used to extract data with predictive categorisation. In the event that a local template is not available (for example analysis of data extracted from a receipt does not reveal a vendor name for which a local template is available) then a query may be conducted to identify a global template from global templates 504. Global templates 504 are defined based, at least in part, on global learning derived from local learning via a local template analysis module 503. Module 502 analyses templates 502a0502n and, in the case that a threshold level of commonality is identified for a given template (for example a threshold number of users have an identical local template) that local template is selectively added to global templates 504. Global templates may also be defined via a custom template definition module, which is used to define templates based on a manual process thereby to shortcut the learning process.

[00129] When a receipt is processed at a local device, a predictive categorisation first determines whether there is a potentially suitable local template (for example based on an identified vendor name). If available, that template is used for predictive categorisation. In the case that there is no potentially suitable local template, it is determined whether a potentially suitable global template exists, and if available that is used for predictive categorisation.

[00130] In the event that a user modifies predictions made based on a global template, that may result in the defining of a new local template (for example individual users may have nuances in how they wish to categorise receipts from a common vendor). This results in another aspect of hybrid local/global learning, whereby a global template (which may be defined by means other than learning, such as via module 505) is enhanced via local learning. [00131] It will be appreciated that hybrid local/global learning methods provide a powerful tool for receipt categorisation, in the sense that a large number of receipt formats from a large number of vendors are able to be learned quickly and efficiently across a collective of users. Via the approach described above, users are able to take advantage of both local incremental customisation and global knowledge.

Online/Offline Modes

[00132] In some embodiments receipt categorisation is able to be performed in a online mode, whereby categorised data is sent and stored at a central cloud-based location, and an offline mode, whereby categorised data is stored at a local device (for example temporarily awaiting re-establishment of online mode or the like). Preferably user interface components are configured such that, for categorised receipt data, a user is able to visually identify whether that data is maintained only locally, or whether it has been synchronised with the user's cloud data.

The use of a cloud-based data arrangement is useful in the context of providing access to data via multiple portals, for example via a mobile device app and via a web-based interface accessible via a laptop or desktop computer that executes a web browser application.

Integration with eWallet functionalities

[00133] In some embodiments, for example as shown in FIG. 1 B, receipt management is integrated with eWallet functionalities, thereby to allow reconciliation of receipts with bank account data, and optionally additionally provide a payment platform.

[00134] System 1 10 of FIG. 1 B illustrates the following software modules relevant to eWallet functionalities:

• A card management module 191 , configured to maintain data indicative of payment cards a user has registered against app 1 10. An exemplary method for registering a card is discussed further below.

• A payment management module 192, configured to enable payments using cards registered to card management module 191. • A banking interface module 193, which enables app 1 10 to procure from a third party banking server data indicative of a user's accounts and transaction details for those accounts. For example, this may leverage a service such as Yodlee thereby to facilitate access to that data and streamline the configuration of account access.

• A reconciliation module 194, which is configured to compare receipt data with banking data, thereby to reconcile receipts against bank records.

[00135] Exemplary methods preformed by thee modules are discussed further below.

[00136] One embodiment provides a computer implemented method for managing financial data at a mobile device, the method including providing an interface thereby to enable transaction record data to be collected and categorised from imported transaction records (for example as described further above). The method additionally includes maintaining access to account transaction details for one or more banking accounts. In some embodiments a service such as Yodlee may be used to obtain transaction details for banking accounts. Yodlee's API and Yodlee Aggregation Engine may be used to provide app 1 10 with access to tens of thousands of financial institutions and portals through a mix of direct feeds and gathering directly from source sites. Using the Yodlee API, app 100 may implement an institution-independent process by which information may be obtained from a user thereby to configure accessing of banking details via Yodlee.

[00137] In some embodiments, app 100 is configured to provide an interface that enables simultaneous viewing of transaction data available via transaction records imported from a financial institution with transaction data extracted from categorisation of a transaction record. For example, this may be used for enabling reconciliation, such as reconciling a given entry in the account transaction details (for example an entry defined by an amount and a date) to a corresponding transaction record (having the same amount and date). An automated process may be used to identify correspondence between entries in bank account data and categorised receipt data.

[00138] One embodiment includes a method of identifying "missing" receipts based on reconciliation as discussed above. For example, the method includes a step of identifying one or more entries in the account transaction details for which there is no corresponding transaction record, and preferably raising an alarm in respect of an entry in the account transaction details for which there is no corresponding transaction record. This is particularly useful in the context of ensuring copies of all receipts are maintained for hte purpose of audits, taxation, and so on.

[00139] A method according to claim 1 wherein the transaction record is collected from a plurality of sources, including capture of hard copy transaction records and import of emailed electronic format transaction records.

[00140] A method according to claim 1 including providing a user interface for displaying the transaction details for the one or more banking accounts, wherein the accounts are each visually identifiable based on graphical representations of a respective associated payment card.

[00141] Some embodiments include methods, performable at a mobile device, for defining a virtual payment card. According to one embodiment, one such method includes operating an image capture device thereby to capture a digital image of a physical payment card. The method then includes processing the digital image thereby to determine: a card type; a card user name; and a card identification number (typically referred to as a "credit card number"), for example using a combination of graphical comparison techniques, feature extraction, and/or OCR. Other features, such as expiry dates and the like, may also be extracted The method then includes obtaining, from a repository of card images for a plurality of card types, a card image for the determined card type. This should have a similar appearance to the physical card, but be a native digital representation, as opposed to a captured image. The obtained card image is then modified thereby to display the card user name and the card identification number. In this manner, the mobile device is able to display a digital version of the physical card. This is optionally additional modified to include a readable identifier, such as an OCR code, thereby to enable payments using the mobile device. That is, the method includes defining a payment identifier readable from a display of the mobile device thereby to define a virtual payment card that is operable to make payments based on reading of the payment identifier.

[00142] In some embodiments the method includes, based on at least the card user name and card identification details, defining an interface for accessing data for a banking account associated with the physical payment card. For example, this may leverage a service such as Yodlee, and in most cases requires input of additional data by a user. [00143] FIG. 4E illustrates exemplary eWallet process flows. FIG. 4F illustrates exemplary user interface screenshots relevant to eWallet functionalities.

Reimbursement Functionality

[00144] In some embodiments receipt capture and data categorisation is performed in conjunction with a reimbursement management protocol. This is illustrated schematically in FIG. 5B, and attention is also drawn to FIG. 6A, FIG. 6B and FIG. 7.

[00145] In overview, a user of a client device 510 performs receipt categorisation (for example as described further above). A receipt, or an item in a receipt, is selectively marked by the user as being a "reimbursement expense" being an item for which reimbursement is sought from a "reimbursing party" (for example from an employer company or the like). For example, FIG. 7 shows exemplary screenshots where single and multiple items from a captured recept are marked for reimbursement. The user is also informed as to a status of the reimbursement, for example "pending" or "approved".

[00146] Each reimbursement item is associated with a reimbursing party (for example an employer). This may be a manual assignment by the user, or an automated assignment based upon association of a user with a specific reimbursing party. Data indicative of items marked for reimbursement are communicated to a reimbursement management module 511 , which operates within or in conjunction with a server component. Reimbursing parties register to participate in the reimbursement framework, and use a company terminal 512 (which may be substantially any computing device) executing a web browser application to access data made available by module 51 1 (in some embodiments an app-based approach may be used). The reimbursing party logs into a specified website, and is presented with an interface showing reimbursement items awaiting approval. This provides details of the user who submitted the item, and information regarding the item (optionally including image data for a receipt from which item data is derived). The reimbursing party then selectively approves or rejects the reimbursement. In the case of approval, the client device is informed (either via a push notification or by a subsequent pull of data based on a query submitted via client device 510).

[00147] In some embodiments payment of reimbursements is automated such that, upon approval, a process is initiated thereby to transfer funds to an account associated with the relevant user and deduct funds from an account associated with the reimbursing party. In some embodiments such transactions are batched together for efficiency. It will be appreciated that various payment solutions may be implemented in this regard, such that approval of a reimbursement item by a reimbursing party initiates an automated payment of the reimbursement item to the user.

[00148] FIG. 6A provides a flowchart illustrating a reimbursement process according to one embodiment. It will be appreciated that various aspects of this process may be leveraged by other embodiments described herein. The process commences at 601 , and receipt image data is captured for a given receipt at 602 by a user of a mobile device that executes an appropriate app. The receipt image data is subjected to OCR at 603, and data categorisation performed at 604 (for example based on predictive categorisation and user approval). The user is provided with an opportunity to mark one or more items for reimbursement at 605, and a reimbursement total is thereby optionally defined at 606. The receipt and related data is saved at 607, and synched with a cloud-based storage system at 608. A push or pull process is performed at 609 to import reimbursement related data to a reimbursement management module. That module processes the reimbursement at 610, and approval occurs at 611 or 612. There is then a push/pull of approval status at 613 and payment status at 614, and the status of the reimbursement is then updated at 615 such that it is viewable at the mobile device. The method completes at 616.

[00149] FIG. 6B shows another process flow for reimbursement. This shows a pathway through submission, approval, payment and closure (with an optional resubmission loop). FIG. 7 shows multiple exemplary sceenshots, including an option to mark an item for reimbursement, interfaces for marking single and multiple items for reimbursement, and an interface that displays reimbursement status.

Data Warehousing

[00150] It will be appreciated that the above methodologies allow a wide range of transaction information to be collected, including the likes of spending habits, patterns, and so on. These are preferably used in the context of a data warehousing implementation, thereby to put that data to commercial use. For example, this may aid in targeted marketing, understanding of consumer behaviour, and so on. Exemplary Client-Server Arrangement

[00151] 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.

[00152] 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.

[00153] Server 302 is coupled to a database 310. In further embodiments the database leverages memory module 306.

[00154] 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 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.

[00155] 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).

[00156] In general terms, each terminal 304 includes a processor 31 1 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

[00157] It will be appreciated that the disclosure above provides various significant computer implemented frameworks and methodologies for enabling the categorisation and management of transaction data and/or providing financial management and payment solutions via mobile and other computing devices.

[00158] 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.

[00159] 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 memory. A "computer" or a "computing machine" or a "computing platform" may include one or more processors.

[00160] 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.

[00161] Furthermore, a computer-readable carrier medium may form, or be included in a computer program product.

[00162] 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 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. [00163] 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.

[00164] 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.

[00165] 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 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.

[00166] 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.

[00167] 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 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.

[00168] 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. [00169] 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.

[00170] 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.

[00171] 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.

[00172] 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 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.