Cloud service for receipt management

Abstract

Methods and apparatus for receipt management. A digital receipt is received in response to a transaction occurring. The digital receipt describes the transaction. Based on data in the digital receipt, a card among several cards is identified, which card was used when completing the transaction. The identification is based on one or more transactional parameters. The digital receipt is stored together with an identifier of the card. The digital receipt is processed in accordance with a set of rules defined for the card. Receipt management systems and computer readable storage media for receipt management are also described.

Description

[0001] CLOUD SERVICE FOR RECEIPT MANAGEMENT

[0002] BACKGROUND

[0003] The present invention relates to the field of financial management systems, and in particular digital receipt management systems and methods.

[0004] The advent of digital transactions has brought about an array of benefits, such as convenience and speed. However, with these advancements come new challenges associated with the management and organization of transaction data. Especially in situations where a user has multiple cards that are used for various transactions, for example, one or more personal cards and one or more business cards, tracing past purchases or understanding transaction trends becomes a complex task.

[0005] There is a recognized need for effective ways to manage digital receipts that detail individual transactions. These receipts serve as immediate proof of purchase and are often crucial for returns or warranty claims. More broadly, they form an essential part of financial management, being utilized for expense tracking, budgeting, or tax purposes, both in the personal and in the business realm. However, the sheer volume of these digital documents can prove overwhelming and difficult to manage effectively. The same reasoning also applies to situations when there are physical copies of the receipts.

[0006] One critical aspect revolves around identifying which card was used in completing a particular transaction based on information contained in the digital receipt. While this might seem straightforward when dealing with a single card, the complexity increases substantially when multiple cards — each potentially coming with their own set of rules — are involved in daily transactions.

[0007] Difficulties also arise when storing these receipts. Proper storage not only involves keeping these documents safe but also organizing them in a way that ensures their easy retrieval when needed, for example during the tax filing season. An additional complication arises from the fact that different cards might have distinct rules defined for receipt processing and storage, further complicating this task. Furthermore, while some existing solutions may forward the processed receipt to a repository for storage — thus ensuring its availability — their methods often lack efficiency or simplicity, making it difficult for users to retrieve specific receipts quickly when needed.

[0008] Moreover, current methods fail to accommodate variations such as physical and virtual cards stored on electronic devices adequately. Similarly, they often fall short in processing parameters like transaction time or place efficiently or identifying specifics such as parts of card numbers or card types included in the transaction details.

[0009] In light of this situation — an intricate landscape characterized by an increasing number of transactions being conducted through diverse means — it is evident that existing receipt management methods cannot fully address these challenges due to their inherent limitations and lack specificity towards managing various transactional parameters implied by different kinds of cards.

[0010] SUMMARY

[0011] In some aspects, a receipt management method for a computing device, includes: in response to a transaction occurring, receiving a digital receipt describing the transaction, identifying, based on data in the digital receipt, a card among a plurality of cards that was used when completing the transaction, where the identification is based on one or more transactional parameters, and storing the digital receipt together with an identifier of the card. The receipt management method also includes processing the digital receipt in accordance with a set of rules defined for the card.

[0012] The transaction can be a checkout at a purchase terminal. The card can be a physical card, or a virtual card stored in an electronic device. The transactional parameters include a time when the transaction was conducted, a place where the transaction was conducted, a portion of the card number, a transaction value, a card type, and / or a card issuer. The digital receipt can be forwarded to a dedicated system or software that manages financial record-keeping and accounts processing. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

[0013] The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In the following, the invention will be described in detail, with reference to exemplifying embodiments of the invention and to the enclosed drawings, wherein:

[0015] FIG. 1 is a flowchart showing a receipt management method, in accordance with some embodiments.

[0016] FIG. 2 is a block diagram showing a computing device, in accordance with some embodiments.

[0017] FIG. 3 shows a receipt management system, in accordance with some embodiments

[0018] FIG. 4 shows a receipt management system, separating system functionalities into different individual entities, in accordance with some embodiments.

[0019] FIG. 5 shows a communication configuration within a receipt management system with separated entities, in accordance with some embodiments.

[0020] FIG. 6 is a sequence chart showing a receipt management method, in accordance with some embodiments.

[0021] Like reference symbols in the various drawings indicate like elements.

[0022] DETAILED DESCRIPTION

[0023] The various embodiments of the invention pertain to techniques for effectively organizing and processing digital receipts based on the specific card used in a transaction. The various embodiments find applications in financial management systems, digital wallets, and other systems where tracking and managing transaction receipts are necessary, for example, to facilitate accounting, bookkeeping, and tax filing operations, just to mention a few. These techniques initiate in response to a digital receipt having been generated for a transaction. Based on data contained within this digital receipt, it is possible to identify which card among multiple cards was utilized to complete the transaction. This identification process relies on one or more transactional parameters, such as a time when the transaction was conducted, a location where the transaction took place, a portion of the card number, a value of the transaction, a type of card (e.g., credit or debit) and an issuer of the card. Issuer in this context can refer to the manufacturer of the card, such as, Master Card, Visa, American Express, etc., just to mention a few common examples, or to the issuing bank or financial institution from which the user orders the card. Once identified, the digital receipt is stored along with an identifier of the card used. Subsequently, this digital receipt undergoes processing according to a set of rules, specifically defined for that card. These techniques provide detailed insights into each transaction facilitating accurate identification and subsequent management of receipts.

[0024] A significant aspect of this method is that different cards among multiple options can have unique associated rules. This allows for personalized management and processing of receipts based on individual card preferences or requirements.

[0025] The aforementioned transaction can be a checkout at a purchase terminal, but the techniques described herein also work for online transactions (e.g., purchases on various websites), as will be described in further detail below. This broadens the scope of application for this method as it can cater to various commercial transactions, enhancing its utility and adaptability.

[0026] The term 'card' as used herein can refer to either physical cards or virtual cards stored within an electronic device. By catering to both physical and virtual modes, this method ensures comprehensive coverage and flexibility in managing receipts across various platforms.

[0027] In some embodiments, an initialization phase of the methods described herein includes setting up a user account and storing, for each card in a collection of cards, partial card information including one or more of: the name of the cardholder, the card type, the card issuer, and a portion of the card number. In some embodiments, the user account can be given permission to obtain account information corresponding to each of the stored cards.

[0028] The methods described herein also extend to forwarding these processed digital receipts to a repository for storage. This feature enables centralized storage and easy retrieval of all processed receipts thereby enhancing overall efficiency in receipt management.

[0029] Various embodiments will now be described in further detail by way of example and with reference to the drawings.

[0030] As shown in FIG. 1, the receipt management method 100 in accordance with one embodiment starts by receiving a digital receipt describing a transaction, step 102. A transaction, as used herein, typically represents a purchase or exchange of one or more items. The transaction process can occur either in a physical retail store or through online channels. In the case of an in-store transaction, a customer physically visits the store, selects the desired items from the available inventory, and proceeds to make the purchase by interacting with a cashier or a selfcheckout system. This process may involve scanning the items, entering payment information, and completing the transaction through a payment terminal or other suitable means. Alternatively, an online transaction occurs when a customer utilizes an electronic device such as a computer, smartphone, or tablet to browse and select items from a digital platform or website. The customer then adds the chosen items to a virtual shopping cart and proceeds to a checkout process. During online checkout, the customer typically provides payment information, such as credit card details or other electronic payment methods, to complete the purchase electronically. It should be noted that the transaction process can also include ancillary activities such as order confirmation, order tracking, and delivery arrangements, which may vary depending on the specific implementation or business model employed by the entity facilitating the transaction. Additionally, the transaction can involve interactions between various stakeholders, such as customers, retailers, distributors, payment processors, and shipping providers, each performing specific roles to enable the completion of the transaction. In summary, the transaction, within the context of the invention, encompasses both in-store and online purchase processes, enabling customers to acquire one or more items through a variety of channels and methods.

[0031] A digital receipt, as used herein, refers to an electronic document that provides a record of the transaction between the buyer and a seller. Unlike traditional paper-based receipts, a digital receipt is generated and delivered in a digital format, typically through email, mobile applications, or online platforms. Digital receipts can contain various information, including but not limited to:

[0032] Transaction details: This encompasses key information related to the purchase, such as the date and time of the transaction, the name or description of the item(s) or service(s) purchased, their corresponding prices or fees, and any applicable taxes or discounts.

[0033] Seller information: Digital receipts often include the name, address, or other identifying details of the seller or the business from which the purchase was made. This information can help the buyer identify the source of the transaction.

[0034] Payment method: Digital receipts may also include the payment method used for the transaction, such as credit card details, digital wallets, or other forms of electronic payment. Unique identifiers: To ensure traceability and authenticity, digital receipts often include unique identifiers, such as transaction numbers, order numbers, or QR codes, which can be used for verification or return purposes.

[0035] Additional information: Depending on the specifics of the transaction or the business involved, digital receipts can include supplementary information, such as product descriptions, warranties, return policies, or customer support contact details.

[0036] It should be noted that all this information could be provided with different levels of granularity. For example, in some cases, it may be sufficient to provide only the date of the transaction and not the time of day (e.g., where only a few products are sold every day such as in a car dealership in a small town), whereas in other cases, it may be necessary to provide the time both in terms of day, hour, minute, and second (e.g., in a grocery store in a large city, with large numbers of transactions and amounts in the same general price range). Such implementation details can be easily determined by people having ordinary skill in the art, based on the particular circumstances at hand.

[0037] It should further be noted that in the event of digital wallets, there may be different identifiers associated with different devices, even though the devices may be connected to the same credit / debit cards. For example, a user may have stored a digital representation of the same card in a digital wallet on his mobile phone, and in a digital wallet on his smartwatch. When the user pays with his credit card using his mobile phone, a different payment method identifier may be sent to the purchase terminal, compared to when the user pays with the same credit card but instead uses his smartwatch. Thus, even though two different payment method identifiers are used, it is still possible to conclude which credit card was used to complete the transaction.

[0038] Digital receipts provide several advantages over traditional paper receipts. They are more easily stored and organized, reducing the need for physical clutter, and facilitating quick retrieval when required. Digital receipts can also be easily shared or forwarded to others, making them convenient for expense tracking, reimbursement purposes, or warranty claims. Additionally, digital receipts contribute to sustainability efforts by reducing paper waste associated with traditional receipts. In summary, a digital receipt within the context of the different embodiments described herein is an electronic document that captures and provides essential details of a transaction, offering convenience, organization, and environmental benefits to both buyers and sellers. However, it should be realized that the techniques described herein can also be used in conjunction with paper receipts that subsequently digitized, for example, by a user scanning or taking a photo of the paper receipt with a device, such as a cell phone or tablet, etc., so the various embodiments described herein are not limited exclusively to receipts that are issued in a digital format.

[0039] Next, the card that was used in the transaction is identified, based on one or more transactional parameters, step 104. The card referred to herein can be a physical card, similar to a regular credit card, which is typically made out of plastic or another durable material. This physical card generally carries features such as the cardholder's name, a card number, an expiration date, and a security code. The physical card can be swiped, inserted, tapped, or held close to a card reader device to initiate a transaction. Alternatively, the card can also be represented as a virtual card, stored electronically within an electronic device. One common example is the usage of an electronic wallet on a mobile phone, wherein the virtual card's information is securely stored and accessed through the electronic wallet application. The virtual card is associated with the user's account and can be used for contactless payments, online purchases, or other forms of electronic transactions. The virtual card typically leverages near-field communication (NFC) technology or other secure methods to transmit the necessary card information to a compatible payment terminal or device. This allows the user to make transactions by simply bringing their mobile device close to the payment terminal, without the need to physically present a physical card. The virtual card can be protected by additional security measures, such as biometric authentication (e.g., fingerprint, handprint, facial recognition, etc.) or a unique passcode, adding an extra layer of security to the transaction process. It should be noted that the virtual card's information is securely stored within the electronic wallet and can be easily updated or managed by the user. Users can add, remove, or temporarily disable virtual cards, providing flexibility and convenience in managing their payment methods. The electronic wallet may also offer additional features, such as transaction history tracking, spending limits, loyalty program integration, or other functionalities related to digital payments. Overall, the card in the context of the invention can be a physical card resembling a regular credit card, or it can be a virtual card stored within an electronic device like an electronic wallet. This versatility offers users the flexibility to choose their preferred method of payment while ensuring secure and convenient transactions both in-person and online. Often a user may have several cards, for example, one or more cards that are used for personal purchases and one or more cards that are used for purchases on behalf of their employer, or their business if they are business owners. There may be different rules or guidelines for how the receipts should be managed based on which card is used. For example, a user may be more flexible and not quite as careful about saving receipts for personal purchases, compared to receipts for business purposes, where more strict accounting rules apply. Thus, different receipt management processes can be set up for different cards, and these can be triggered in response to successful identification of what card was used in the transaction, as will be described in further detail below. Thus, having the ability to identify which card that was used in the transaction in a simple and efficient manner is an important feature of the overall process. In addition, being able to do so without requiring significant modifications of existing systems.

[0040] In the various embodiments disclosed herein, the identification of the card used in a transaction relies on transactional parameters, which can be derived from the receipt itself and / or the general time and place of purchase. These transactional parameters play a crucial role in accurately determining the specific card that was used. Some examples of transactional parameters include:

[0041] Transaction amount: The monetary value and currency of the transaction is an essential transactional parameter that can help in identifying the card used. By comparing the transaction amount recorded in the receipt or transaction data with the known transaction history associated with each card, the system can accurately match the transaction with the correct card.

[0042] Merchant or vendor information: The identification of the merchant or vendor where the purchase was made is another vital transactional parameter. Each card transaction is typically associated with specific merchants, and by comparing the merchant information from the receipt with the known transaction history associated with each card, the correct card can be identified.

[0043] Transaction date and time: The date and time of the transaction provide valuable transactional parameters for identifying the card used. By cross-referencing the date and time of the transaction with the known transaction history, the system can identify the most likely card used for that particular transaction. Location or geolocation data: The general location or geolocation where the purchase occurred is a useful transactional parameter for identifying the card used. By comparing the location information from the receipt or transaction data with the known transaction history associated with each card, the system can narrow down the potential cards used for the transaction.

[0044] Unique transaction identifiers: The presence of unique identifiers associated with the transaction, such as transaction numbers, authorization codes, or reference numbers, can serve as transactional parameters. These unique identifiers can be used to match the transaction data with the corresponding card's transaction history, ensuring accurate identification.

[0045] It should be noted that the above examples are not exhaustive, and other transactional parameters specific to the invention may be considered. The system used in the various embodiments leverages these transactional parameters to accurately identify the card used in a given transaction. By analyzing and matching the transactional parameters with the known information associated with each card, the system can provide a reliable and accurate identification of the specific card used for a particular transaction. In summary, the embodiments described herein use transactional parameters derived from the receipt and / or general time and place of purchase to identify the card used. These transactional parameters encompass various factors such as transaction amount, merchant information, transaction date and time, location, and unique transaction identifiers, among others, to precisely determine the specific card associated with a given transaction. By using one or more of these parameters, which are readily available without making modifications to the existing checkout systems, the various embodiments described herein can be easily implemented in conjunction with any type of existing checkout systems, which eases the adaptability of the system. Once the card has been successfully identified in the process as described, the digital receipt generated from the transaction is stored along with an identifier of the card, step 106. This association between the digital receipt and the card serves to link the transactional information to the specific card used. The storage of this information can take place either locally on a user's computing device or remotely in a cloud-based storage system. In the case of local storage, the user's computing device, such as a cell phone or any other electronic device capable of storing data, acts as the repository for the digital receipts and associated card identifiers. This local storage option provides the advantage of having the data readily accessible and available to the user without requiring an internet connection. The digital receipts and card identifiers are typically saved in a designated folder or within a dedicated application specifically designed for managing transactional data. On the other hand, remote storage in the cloud refers to storing the digital receipts and card identifiers in an online-based storage system. Cloud storage offers the advantage of centralized and secure storage accessible from any device with an internet connection. The digital receipts can be securely uploaded to a cloud service provider's servers, where they are associated with the corresponding card identifier. This allows users to access and manage their digital receipts from multiple devices, provides easy backup and recovery options, and supports synchronization across various platforms. The choice between local and remote storage relies on factors like user preference, storage capacity of the computing device, availability of internet connectivity, and data privacy concerns. Some users may prefer local storage to maintain full control over their data, while others may elect cloud storage for its convenience and accessibility from anywhere. Regardless of the storage location, the association between the digital receipts and card identifiers allows for efficient retrieval, organization, and analysis of transactional data. By linking the digital receipts to the specific card used in each transaction, users can easily reference past transactions, track expenses, reconcile accounts, or even generate reports for financial purposes.

[0046] In some embodiments, steps 102-106 of the management method 100 can be described separating functionalities of the system to different entities, as will now be described with reference to FIGs. 4 and 5. Before the method starts, an initiation phase may be carried out that includes setting up a user account and storing, for each card in a collection of cards, partial card information including one or more of: the name of the cardholder, the card type, the card issuer, and a portion of the card number. In some embodiments, the user account can be given permission to obtain account information from a banking system 406 corresponding to each of the stored cards. Further, the account information can be stored together with the corresponding card information, linking the card to the account. After permission has been successfully granted, the method of this embodiment starts by obtaining information from a banking system 406 that a transaction with one of the cards has been carried out. The information obtained may contain transaction data of the transaction together with information about which account has been used. This information could be an account ID, an International Bank Account Number, (IBAN) or something similar to identify the account corresponding to the card used for the transaction. When the account information and transaction data have been obtained, they can be sorted and stored under corresponding stored card by matching the account information with the stored account information.

[0047] Further, in some embodiments, the card information together with the transaction data stored with its corresponding card can be sent to a third-party system for receipt management 402. The third-party system 402 may have, upon the aforementioned transaction being made, created a digital receipt 306 describing the transaction. The receipt 306 can be stored in the third-party system 402 among several other receipts 306 from other transactions. The third-party system 402 can match the received transaction data and the card information with the stored receipts 306 and may find the receipt 306 corresponding to the transaction being made. Upon a successful matching, linking a card and transaction to a receipt among the receipts 306, information about the matched receipt 306 and the associated card can be received from the third-party system 402. The received information about the matched receipt and card can be sorted and stored under corresponding stored card by matching the corresponding account information with the stored account information.

[0048] In some embodiments of the described method, one or several of the steps described above can be carried out with encrypted information. Encrypting information before sending and decrypting information after receiving further enhances confidentiality and integrity of user information. In one embodiment, when information regarding a card together with transaction data is sent to a third-party system 402 for matching with a receipt 306, encrypted account information can be attached without decrypting the account information in the third-party system 402. After the matching procedure has been carried out, the third-party system 402 can encrypt a matched receipt. In this case, when receiving the encrypted matched receipt and card information from the third-party system, only the user account with the corresponding stored card information is able to decrypt the encrypted matched receipt. Further, since the associated account information is embedded encrypted from the third-party system 402, the associated stored card can easily be found. In this way, sensitive personal information does not have to be exposed to any external system.

[0049] Finally, after associating the digital receipt with the card identifier in step 106, the digital receipt is processed according to a set of predefined rules that have been established for the card, step 108. This processing typically occurs automatically and without manual user intervention and can involve various actions and procedures that facilitate efficient management and organization of the digital receipt. The processing of the digital receipt can range from simple tasks like saving the receipt in a specific location to more complex actions such as transmitting the receipt to a business accounting system for further processing or approval processes before being securely stored for future retrieval. One straightforward processing action is to save the digital receipt in a designated location. This can involve storing the receipt on the user's device or in a specific folder within an application designed for managing digital receipts. By saving the digital receipt in a predetermined location, users can easily locate and access the receipts whenever needed. Alternatively, more sophisticated processing actions can be executed, such as transmitting the digital receipt to a business accounting system. In this case, the digital receipt is forwarded to a dedicated system or software that manages financial record-keeping and accounts processing. The receipt might undergo various processes such as validation, reconciliation, or approval workflows before being officially stored in a central repository or integrated with the business's accounting infrastructure. This facilitates proper bookkeeping, financial analysis, or compliance requirements.

[0050] The set of rules defined for the card can encompass a wide range of criteria and conditions. These rules can dictate the specific actions to be taken, depending on factors like the nature of the transaction, merchant category, transaction amount thresholds, or specific user preferences. For instance, certain rules may instruct the system to categorize receipts based on spending categories, allocate transactions to different budgets, or flag transactions that require additional approval. These rules help customize the processing of digital receipts to suit the specific needs and preferences of the user. The more complex processing actions, such as transmitting the receipts to a business accounting system, enable seamless integration of transactional data into broader financial management workflows. This integration may involve further analysis, reporting, or archiving processes to ensure compliance with regulatory requirements or to facilitate future auditing or retrieval purposes. Many such processes can be defined by those having ordinary skill in the art.

[0051] It should be noted that in some embodiments, the system does not necessitate registering full card information, but instead, uses only a limited set of card details to maintain enhanced confidentiality and integrity of user information. This restricted set of card details can include, for example, the name of the cardholder, the card type, the card issuer, and only the last four digits of the card number. By omitting sensitive information like the full card number, expiration date, or security code, the risks associated with potential security breaches are minimized, ensuring greater protection for the user. The decision to limit the card details stored in the system aims to prioritize user privacy and security. By only storing partial card information, the system minimizes the potential impact of a security breach. Even if unauthorized access were to occur, the sensitive card information required for fraudulent activities or unauthorized transactions would be significantly restricted, mitigating potential harm to the user.

[0052] Keeping the user's personal and financial data confidential is crucial for maintaining trust and complying with privacy regulations. By adhering to privacy principles and implementing a data minimization approach, the system ensures that only the necessary information is collected and stored, reducing the potential attack surface for malicious actors. Furthermore, storing limited card details aligns with the principle of least privilege, granting only the essential information needed to perform operations such as transaction identification and processing. It reinforces the notion that sensitive data should be strictly limited to those who require access, enhancing security on both the user's side and within the system infrastructure. While alternative embodiments may allow for the retention of additional card details based on user preferences or the specific requirements of the application, the practice of storing minimal card information is often adopted as a security best practice and privacy-conscious approach. By employing anonymity and pseudonymity measures in the storage of card details, the system ensures secure and confidential handling of user data. In summary, some embodiments of the system prioritize user privacy and security by restricting the storage of full card details. This practice limits the information to the cardholder's name, card issuer, and only a portion of the card number, such as the last four digits. By minimizing sensitive information, potential risks resulting from security breaches are reduced, ensuring enhanced confidentiality and integrity for users, and mitigating potential harm in the event of unauthorized access or data breaches. Further, it also enhances the adoptability of the system among users, as it can be combined with a variety of existing checkout systems.

[0053] Distinct types of computers can be used to perform the above-described functionality. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. As used herein, a “computer” can include a server computer, a client computer, a personal computer, embedded programmable circuitry, or a special purpose logic circuitry. FIG. 2 is a schematic diagram of a data processing system including a data processing apparatus 202, which represents an implementation of the computer 102. The data processing apparatus 202 can be connected with one or more computers through a network.

[0054] The data processing apparatus 202 can include various software modules, which can be distributed between an applications layer and an operating system. These can include executable and / or interpretable software programs or libraries, including a receipt management program 204. The number of software modules used can vary from one implementation to another. Also, in some cases, the receipt management program 204 can be implemented in embedded firmware, and in other cases, the receipt management program 204 can be implemented as software modules that are distributed on one or more data processing apparatus connected by one or more computer networks or other suitable communication networks.

[0055] The data processing apparatus 202 can include hardware or firmware devices including one or more hardware processor(s) 206, one or more additional device(s) 208, a non-transitory computer readable medium 210, a communication interface 212, and one or more user interface device(s) 214. The processor(s) 206 is capable of processing instructions for execution within the data processing apparatus 202, such as instructions (e.g., of the receipt management program 204) stored on the non-transitory computer readable medium 210, which can include a storage device such as one of the additional device(s) 208.

[0056] In some implementations, the processor(s) 206 is a single or multicore processor, or two or more central processing units (CPUs). The data processing apparatus 202 uses its communication interface 212 to communicate with one or more computer(s) 218, for example, over the network 216. Thus, in various implementations, the processes described can be run in parallel, concurrently, or serially, on a single or multi-core computing machine, and / or on a computer cluster / cloud, etc.

[0057] Examples of user interface device(s) 214 include a display, a touchscreen display, a speaker, a microphone, a tactile feedback device, a keyboard, a mouse, and a headset or heads-up display of a virtual reality or augmented reality environment system. Moreover, the user interface device(s) need not be local device(s) but can be remote from the data processing apparatus 202, e.g., user interface device(s) 214 accessible via one or more communication networks 216. For example, the user interface device(s) 214 can be a smartphone or a tablet computer of the user, e.g., for an augmented reality implementation. The data processing apparatus 202 can store instructions that implement operations as described in this document, for example, on the non- transitory computer readable medium 210, which can include one or more additional device(s) 208, for example, one or more of a floppy disk device, a hard disk device, an optical disk device, a tape device, and a solid-state memory device (e.g., a RAM drive).

[0058] Moreover, the instructions that implement the operations described in this document can be downloaded to the non-transitory computer readable medium 210 over the network 216 from one or more computer(s) 218 (e.g., from the cloud). In some implementations, the data processing apparatus 202 is a smartphone or a tablet computer. In some implementations, the RAM drive is a volatile memory device to which the instructions are downloaded each time the computer is turned on.

[0059] FIG. 3 shows a system 302 in accordance with one embodiment, in which various embodiments of the above-mentioned receipt management method 100 can be implemented. The system includes purchase terminal 304 and an accounting system 308. The accounting system 308 communicates over a network 310 with one or more computing devices 312, which contain a receipt management program 204 that performs the above-mentioned operations, in conjunction with a card collection 314, to determine how the receipts 306 should be managed by the computing device 312. As noted above, in some embodiments, the purchase terminal 304 and accounting system 308 are part of the system 302, whereas in other embodiments, the purchase terminal 304 and accounting system 308 are free-standing components that communicate with the system 302 through a suitable API. Similarly, while the card collection 314 is shown as being integrated in the computing device 312 as virtual cards, it should also be realized that the card collection 314 in some embodiments can be a collection of physical cards.

[0060] As was described above and can be seen in FIG. 3, a user purchases one or more items at the purchase terminal 304, which generates a receipt 306. The receipt 306 is sent to the user's computing device 312, where a receipt management program 204 matches the receipt with a card in a card collection 314 stored in the computing device 312, as described above. In some embodiments, the receipt 306 is initially stored within a receipt management system for the merchant, and then retrieved by the receipt management program 204 on the user's computing device 312. These are merely minor implementation differences, and in both cases, the receipt management program 204 eventually obtains a copy of the receipt 306. The receipt management program 204 processes the receipt 306 according to the particular set of rules associated with the identified card. As was noted above, the processing can vary a lot, but in the embodiment illustrated in FIG. 3, the receipt 306 is transmitted over a network 310 to a cloud-based accounting system 308, where the receipt is further processed. It should be noted that while only one accounting system 308 is illustrated in FIG. 3 for the sake of simplicity, in a real-world scenario, there may be several different accounting systems 308 and / or other repositories adapted for storing and processing receipts 306.

[0061] Another embodiment of the system 302, where the system method 100 may be described separating functionalities of the system to different entities is illustrated in FIG. 4. In this example, a purchase terminal 304 can be in contact, through a wired or wireless network 310 (or a combination thereof), with an external third-party system for receipt management 402 and a banking system 406. The third-party system 320 in this example may be designed to create and store receipts from transactions being made in a purchase terminal 304. The third-party system can be an accounting system 308, a cash register 404 or something similar that can keep track of receipts describing transactions in purchase terminals 304. Further, the banking system 406 can receive transaction data from a purchase terminal 304 through the network 310 whenever a transaction has been carried out in a purchase terminal 304. The banking system 404 can be a bank, or a bank in operational contact with a distributor of transaction data such as an open banking system 408. A computing device 312 can be in contact with the banking system 408 and the third-party system 402 through the network 310.

[0062] FIG 5. shows an embodiment the system 302, where third-party system 402 is a cash register 404, and the banking system 406 is an open banking system 408. This embodiment shows how communication is configured between the separate entities. The purchase terminal 304 can be in communication with the cash register 404 and the open banking system 408. The cash register 404 receives information about transactions being made in the purchase terminal 304 together with information about the used card and creates receipts describing the transactions. The open banking system 408 receives transaction data from transactions being made in the purchase terminal. Further, the open banking system 408 can share transaction data together with account information with a computing device 312. The computing device 312 can also be communicatively coupled to the cash register 404. The computing device 312 and the cash register 404 can exchange information, where the computing device 312 can share transaction data from a transaction together with information regarding a card associated with said account information. The cash register 404 can perform a matching of transaction data and card information with receipts 306 stored in the cash register 404. Upon a successful match of a receipt 306 with a corresponding transaction data, the information regarding the match can be sent to the computing device 312 for further storing and handling.

[0063] FIG. 6 shows a flowchart of how the steps 102-106 of FIG. 1 can be implemented, where a digital receipt 306 describing a transaction is matched with the card used for the transaction. Information describing a transaction and corresponding used card are sent to a cash register 404 from a purchase terminal 304 in step 602. A digital receipt 306 is then created in the cash register 404, in step 603. In accordance with the same transaction, in step 604, transaction data is sent from the purchase terminal 304 to an open banking system 408. The open banking system 408 shares information about an account corresponding to the transaction data together with the received transaction data to a computing device 312 in step 606. The computing device 312 uses the information about the account to identify which card was used in the transaction. Once the card used in the aforementioned transaction has been identified, the computing device 312 sends transaction data together with information about the account and the specific card, to the cash register 404 in step 608. Step 610 is a matching step, where the cash register matches the transaction data and the card information with the receipts 306 stored in the cash register 404. When the transaction data and the card information have been successfully matched with a unique receipt 306, the receipt 306, transaction data, account information and the card information are sent back to the computing device 312 in step 612 for further storing and handling according to a set of rules.

[0064] The embodiments of the present invention described herein also relate to a computer software function for receipt management, according to what has been described above. Such a computer software function is then arranged to, when executing, perform the above-described operations, which are also recited in the claims. The computer software function is arranged to execute on physical or virtual hardware of the data processing apparatus 202, as described above.

[0065] Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented using one or more modules of computer program instructions encoded on a non-transitory computer-readable medium for execution by, or to control the operation of, data processing apparatus. The computer-readable medium can be a manufactured product, such as hard drive in a computer system or an optical disc sold through retail channels, or an embedded system. The computer-readable medium can be acquired separately and later encoded with the one or more modules of computer program instructions, such as by delivery of the one or more modules of computer program instructions over a wired or wireless network. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, or a combination of one or more of them.

[0066] The term “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a runtime environment, or a combination of one or more of them. In addition, the apparatus can employ various computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0067] A computer program (also known as a program, software, software application, script, or code) can be written in any suitable form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any suitable form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0068] The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0069] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and one or more processors of any suitable digital computer. Generally, a processor will receive instructions and data from a read-only memory (ROM) or a random-access memory (RAM), or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including by way of example semiconductor memory devices, e.g., EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory), and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; CD-ROM and DVDROM disks; network attached storage; and various forms of cloud storage. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0070] To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., LCD (liquid crystal display), OLED (organic light emitting diode), or other monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in various forms, including acoustic, speech, or tactile input.

[0071] The computing system can include clients and servers. A client and server are generally remote from each other and interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any suitable combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any suitable form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an internetwork (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0072] While this specification contains many implementation details, these should not be construed as limitations on the scope of the invention or of what may be claimed, but as descriptions of features specific to implementations of the invention. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination. Thus, unless explicitly stated otherwise, or unless the knowledge of one of ordinary skill in the art clearly indicates otherwise, any of the features of the embodiment described above can be combined with any of the other features of the embodiment described above. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and / or parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments. The described program components and systems can be integrated into a single software product or packaged into multiple software products.

[0073] Thus, embodiments of the invention have been described. Other embodiments are within the scope of the following claims. For example, some embodiments may include additional card management functionality, for example, allowing the use of corporate cards to be restricted to certain users, amounts, time periods, etc., and to define rules for where the digital receipts for purchases made by certain users of the corporate card should be sent, etc. Many such variations can be envisioned by those having ordinary skill in the art.

[0074] Some embodiments may include functionality for how to manage the unlikely occurrence in which a user thinks he or she may have received a digital receipt by error, for example, by providing an alert function that may provide further transaction details to be verified by the user, or to alert another user or customer support staff for the system. Thus, many variations to the above examples lie well within the scope of the attached claims and within the capabilities of a person having ordinary skill in the art.

Claims

CLAIMS1. A receipt management method for a computing device, comprising: storing, for each card in a plurality of cards, partial card information including one or more of: the name of the cardholder, the card type, the card issuer, and a portion of the card number; in response to a transaction occurring, receiving a digital receipt describing the transaction; matching, solely based on transactional parameters present in the digital receipt and transaction histories for the cards in the plurality of cards, the received digital receipt with a card that was used to conduct the transaction; in response to successfully matching the digital receipt and the card that was used to conduct the transaction, storing the digital receipt together with an identifier of the card; and processing the digital receipt in accordance with a set of predefined rules for the card that was used to conduct the transaction.

2. The receipt management method of claim 1, wherein different cards among the plurality of cards have different predefined rules.

3. The receipt management method of claim 1 or 2, wherein the transaction is a checkout at a purchase terminal.

4. The receipt management method of any one of claims 1-3, wherein the card is one of: a physical card, and a virtual card stored in an electronic device.

5. The receipt management method of any one of claims 1-4, wherein the transactional parameters include one or more of: a time when the transaction was conducted, a place where the transaction was conducted, a portion of the card number, a transaction value, a card type, and a card issuer.

6. The receipt management method of any one of claims 1-5, wherein processing the digital receipt includes forwarding the digital receipt to a dedicated system or software that manages financial record-keeping and accounts processing.

7. The receipt management method of any one of claims 1-6, wherein the method is performed by a system that comprises a plurality of external entities, the plurality of external entities including one or more third-party systems for receipt management and one or more banking systems, and wherein the one or more third-party systems performs the matching of the digital receipt and the card that was used in conducting the transaction.

8. The receipt management method of any one of claims 1-7, wherein at least some of the storing, receiving, matching, and processing steps are performed using encrypted information.

9. A receipt management system, comprising: a memory; and a processor, wherein the memory contains instructions that, when executed by the processor perform a method in accordance with any one of claims 1-8.

10. A non-transitory, computer-readable storage medium containing instructions that when executed by a computing device cause the computing device to perform a method in accordance with any one of claims 1-8.

Images