CA2824514A1 - Sales recording module compatible pos system - Google Patents

Abstract

In various service-oriented sectors, particularly dining and retail, fraudulent schemes frequently referred to as skimming are encountered. The mandatory deployment of a government-authorized sales recording module (SRM) to counteract the effects of sales suppression devices bridges the legislative and enforcement challenges of tax compatibility. Coercing a switch to SRM-compatible checkout systems might be fiscally advantageous, but is logistically and commercially onerous to owners and checkout systems developers. The overlapping and occasionally divergent interests of the public, government tax authorities, merchants, and checkout systems providers must be more carefully considered. Various embodiments of the present invention, implemented as middleware, achieve this by proposing an SRM-compatible solution that is as easy to apply to existing solutions as it is rapid to deploy.

Description

Anglehart et at. ¨ Patent Agents / Agents de brevets SALES RECORDING MODULE COMPATIBLE POS SYSTEM
Technical Field [001] The present invention relates to the fields of POS (point-of-sales) systems and the printing of sales receipts. It particularly applies to jurisdictions having instituted programs aimed at preventing fiscal fraud by way of a technological approach.
Background [002] The deliberate dissimulation of sales records by business owners is a known practice. Although it is illegal to engage in this practice to evade tax responsibilities, it is nonetheless engaged in by numerous merchants. In service-oriented sectors, including but not limited to hospitality, retail, wholesale and any business that receives cash payments (excluding financial institutions), such fraudulent schemes are frequently referred to as skimming. In recent times, an entire underground class of sales suppression devices 300 (known as zappers 302 or phantom ware 301), all belonging to a varied group of tax avoidance technologies, has emerged. Although the precise composition and layout of such technology can vary both in time and by jurisdiction, its purpose remains invariably the same throughout.

[003] The corresponding loss in tax revenue undermines jurisdictions' fiscal capacities. Accordingly, combating tax evasion and recovering revenues from underground economic activity has invited closer scrutiny among policymakers.
Typical solutions to improve the integrity of a tax system typically propose a combination of enhanced administration and enforcement activity. The latter includes improving audits, collections processes, and, increasingly, deploying robust tools to detect or dissuade from engaging in underground economic activity altogether.

Anglehart et al. - Patent Agents / Agents de brevets [004] At the heart of most sales suppression and tax evasion schemes in the service sector is the motivation to undermine the authenticity of the information contained on a legal receipt (that is, whenever tax compliance is not altogether compromised by the absence of the receipt itself). The mandatory deployment in various sectors of a government-authorized sales recording module (SRM) 200 to counteract the effects of sales suppression devices 300 is one solution that bridges the legislative and enforcement challenges of tax compliance [Quebec's Sales Recording Module (SRM): Fighting the Zapper, Phantomware, and Tax Fraud with Technology, by Richard Thompson Ainsworth and Urs Hengartner https://www.ctf.ca/ctfweb/Documents/PDF/2009ctj/09ctj4-ainsworth.pdf>].

[005] The SRM device 220 is a secured microcomputer, typically contained in a tamperproof enclosure, which connects to a point-of-sale (POS) system, typically either 216 an electronic cash register (ECR) 211 or more broadly 215 a computer dedicated to POS tasks 210 and a receipt printer 230. During each transaction, the SRM
device obtains in its secure memory all relevant invoice and sales data (including but not limited to date, time, sale amounts, subtotals, merchant tax identifiers, and tax amount(s) to be remitted for that transaction). The SRM device then transmits 225 to the receipt printer 230 the information required to print 235 a bill or receipt 240 which contains not only the requisite list of goods obtained, and may also include a barcode and/or a unique digital signature 241 which indicates that bill's authenticity.

[006] Subsequent periodic or ad-hoc inspection and information gathering by government authorities could further be automated and facilitated using a handheld computer which scans the barcodes and digital signatures 241 produced on the receipts 240 mentioned above [The Resto Project. Mandatory Billing in the Restaurant Sector. <
http://www.ipac.ca/documents/RevenuQuebec.pdf >]. In addition to printing this digital signature 240 on each receipt, the information for each transaction is stored by the SRM

Anglehart et at. - Patent Agents / Agents de brevets 220 for the purposes of generating various sales summaries or reports (also called a periodic sales summary) when requested by the appropriate tax authority and/or with a frequency as mandated by law. Such reports and/or summaries may be produced electronically (e.g. extracted from the SRM and copied onto a USB key or uploaded to the appropriate agency via a network connection) or printed by a receipt printer 230 on paper [SRM User Guide. Mandatory Billing in the Restaurant Sector. IN-577-V
(2010-09) < http://www.revenuquebec.ca/documents/en/publications/in/IN-577-V(2010-09).pdf >1.

[007] Communication between the SRM microcomputer device 220 and the compatible POS system 210 and invoice printer 230 to which it connects is typically done via the SRM's 220 input and output serial ports, respectively, present and configured for this purpose. A similar topology is implemented when a compatible ECR
211 is substituted for a compatible POS system 210. Tax agencies typically specify the precise SRM microcomputer 220 device model(s) that merchants can deploy.
However, obtaining the government-selected microcomputer device often represents only a portion of all measures required to achieve technical compatibility with the SRM. In addition to the SRM microcomputer itself, a merchant must also obtain and deploy an SRM-compatible (electronic) cash register 211 or point-of-sale system 210 as well as an SRM-compatible receipt printer 230. Furthermore, the entire setup is configured by a government-registered party (known as an SRM installer) authorized to purchase SRM
microcomputer devices as well as install and activate SRMs in target businesses.

[008] The SRM compatibility and certification process requires significant collaboration between ECR, POS system, and printer developers and government SRM
certifying authorities. This collaboration represents a significant cost and time investment for developers, as it often involves iterative communication between developers and the relevant SRM authorities. Moreover, each time a modification (even Anglehart et al. ¨ Patent Agents / Agents de brevets a minor one, such as a bug fix or a trivial feature enhancement) is made to a hardware or software product by a developer, the modified variant may require undergoing SRM
certification anew, or accept the ramifications of SRM non-compatibility.

[009] Coercing entire segments of an economy to switch to an SRM-compatible checkout system might indeed be fiscally advantageous. But despite the tax benefits to society overall, compelling business owners to change their existing and functioning systems is commercially onerous in two important respects. On one hand, it represents an unwanted expense to business owners compelled to adjust to new legislation (this is especially the case absent any incentivizing credit or government program). On the other, the number and possible combinations of SRM-compatible hardware and software options available 200 to merchants is greatly reduced from its previously unrestricted pool 100. Additionally, to device suppliers and manufacturers, the latter point is as much an impediment as it is a potential prejudice. However willing they might be, many particularly smaller developers are unable to expend the resources to achieve the compatibility their products must have to remain viable solutions. In other cases, the fiscal jurisdiction in question might conversely represent too small a market segment to justify developers' costs to ensure their products' SRM compatibility.

[0010] In light of the situation laid out above, the overlapping and occasionally divergent interests of the public, government tax authorities, merchants, and checkout systems providers must be more carefully considered. In particular, such consideration would both favor and result in an SRM-compatible solution that is as easy to apply to existing solutions as it is rapid to deploy. Implemented ideally as middleware, such a solution could neutralize any alleged prejudice both to merchants and checkout systems providers by requiring that they modify little to nothing in their existing software and hardware.

[0011] Such is an object of the invention described herewith.

Anglehart et al. - Patent Agents / Agents de brevets Summary [0012] To avoid subjecting merchants and checkout solutions developers to onerous SRM certification exercises, embodiments of the present invention can be deployed in many existing traditional checkout systems, either in POS system-based (Fig.
4a) or ECR-based (Fig. 4b) configurations. Such an existing configuration typically consists of three key components: (a) a software-based POS system 110 or ECR 111 on which an embodiment of the present invention is deployed as middleware 700 or printer interface module 700', (b) a receipt printer 130, and (c) a government-approved SRM
microcomputer 220 to which both (a) 750 (or 750') and (b) 226 connect. While it may be possible to continue to use any number of receipt printers 130 already deployed as in the configuration described above, only a subset of such printers 230 may be compatible with the SRM microcomputer specified for use within a given jurisdiction.

[0013] In its capacity as middleware 700 deployed on a functional POS
system-based configuration (Fig. 6), some embodiments of the present invention confer full technical compatibility and fiscal compliance with all SRM directives mandated by tax authorities. Through the function of said middleware 700, compatibility is extended to POS systems 110 that are not certified as being SRM-compatible. The ease and speed with which SRM compatibility is achieved using various embodiments of the present invention is intended to facilitate deployment of otherwise non-SRM-compatible POS
systems 110 or ECRs 111 in jurisdictions where said compatibility is required by law.
Moreover, as a result of the flexibility and cost-effectiveness afforded by their role as middleware, embodiments of the present invention are an attractive solution for new deployments and existing ones alike.

Anglehart et al. ¨ Patent Agents / Agents de brevets [0014] POS system-based configurations are accentuated in the present discussion.
However, it will be appreciated that when integrating an embodiment of the present invention in an ECR configuration instead, the middleware 700 described above (Fig. 6) is substituted by an external printer interface module 700' (Fig. 6b). With the sole exception of its realization as a hardware component, this external module provides the same functionality described above in an ECR configuration as its software counterpart does in a POS system configuration.

[0015] The various embodiments of the present invention accomplish the functions required for SRM compatibility by way of five operational manipulations:
1. Rather than printing directly to the driver provided by the receipt printer manufacturer 115 (Fig. 4a, Fig. 4b), the POS system 110 or ECR 111 is made to use an embodiment of the present invention's own virtual printer interface device 700 or printer interface 700' to print receipts (Fig. 6, Fig. 6b).
2. Some embodiments of the present invention store the binary format of the receipt in a temporary file on the hard drive or in the system's cache memory, depending on the hardware limitations/performance of the POS system.
3. Some embodiments of the present invention query 730 and fetch data for all the fields required by the SRM from the POS or ECR data source(s) 600, 600'.
4. Using data containing print and non-print commands, some embodiments of the present invention send the information queried and fetched in step (3) 750, to the SRM microcomputer 220 in a format that it demands so that the SRM
microcomputer 220 can generate the requisite barcode 241 for the transaction in progress.
5. The SRM microcomputer outputs the information received in (3) in addition to the code generated in (4) directly 226 to the receipt printer 130, which outputs an SRM-compatible receipt 240.

Anglehart et al. ¨ Patent Agents / Agents de brevets [0016]
Several embodiments of the present invention also include optimization capabilities that allow said embodiments' operation to be tailored by integration or installation personnel to run more fittingly on the target hardware and software on which it has been deployed. As a non-limiting example, such optimizations may include methods of improving performance by overcoming the hardware limitations of the ECR
or of the computer on which the POS system is running, or more effectively dealing with processing constraints resulting from the latency associated with accessing one or more of the data sources to which the POS system or ECR is connected. Additionally, such capabilities might also optimize for space and/or CPU utilization when storage capacity or processing capabilities are limited, or in cases where the deployment and/or overall operation of the application is complex.
Brief Description of the Drawings [0017]
The invention will be better understood by way of the following detailed description of embodiments of the invention with reference to the appended drawings, in which:

[0018]
Figure 1 shows a traditional checkout system consisting of either a point of sale (POS) system or an electronic cash register (ECR) connected to a receipt printer, which is shown to output a receipt (without barcode);

[0019]
Figure 2 shows a point of sale system, whose detailed view depicts the typical interconnections between the various modules (POS software, POS data source(s), and POS hardware) contained within said point of sale system, in addition to the possible data paths taken by the main sales suppression devices when introduced into said point of sale system;

[0020]
Figure 2b shows an electronic cash register (ECR) system, whose detailed view depicts the typical interconnections between the various modules (ECR
firmware, Anglehart et al. ¨ Patent Agents / Agents de brevets POS data source(s), and POS hardware) contained within said electronic cash register, in addition to the possible data paths taken by the main sales suppression device when introduced into said electronic cash register;

[0021] Figure 3 shows a checkout system consisting of components approved for use with an SRM microcomputer within a given jurisdiction (POS system or ECR, receipt printer), as well as a receipt containing a barcode;

[0022] Figure 4a is a distinct view of traditional checkout system consisting of a point of sale (POS) system connected to a receipt printer, which is shown to output a receipt (without barcode);

[0023] Figure 4b is a distinct view of traditional checkout system consisting of an electronic cash register (ECR) connected to a receipt printer, which is shown to output a receipt (without barcode);

[0024] Figure 5 shows the data flow from transaction to receipt printing using an SRM-compatible POS system connected to an SRM microcomputer that is connected to a POS printer, and which features an example of a receipt containing a barcode produced by the SRM and printed by the receipt printer;

[0025] Figure 6 shows the data flow for a transaction originating in a traditional point of sale system and ending with the printing of an receipt containing a barcode after transiting through a virtual printer driver and the SRM microcomputer, created in accordance with an embodiment of the present invention;

[0026] Figure 6b shows the data flow for a transaction originating in an electronic cash register and ending with the printing of an receipt containing a barcode after transiting through a printer interface module and the SRM microcomputer, created in accordance with an embodiment of the present invention;

[0027] Figure 7 shows an example of a receipt with barcode printed in accordance with an embodiment of the present invention;

Anglehart et al. - Patent Agents / Agents de brevets [0028] Figure 8 shows an example of a receipt with barcode printed in accordance with an embodiment of the present invention wherein data transits through a printer driver OCR component the POS computer;

[0029] Figure 9 shows a database query construction in progress using a GUI
solution that is supplied with an embodiment of the present invention;

[0030] Figure 10a shows a POS system configured in an alternative non-sequential topology in which data is exchanged between a POS computer and an SRM
microcomputer separately from data exchanged between said POS computer and a potential multiplicity of receipt printers, the latter of which may be SRM-compatible or not;

[0031] Figure 10b shows an ECR system configured in an alternative non-sequential topology in which data is exchanged between an ECR and printer interface combination and an SRM microcomputer separately from data exchanged between said ECR and printer interface combination and a potential multiplicity of receipt printers, the latter of which may be SRM-compatible or not;

[0032] Figure 11 shows another alternative topology in which a multiplicity of POS
computers and a multiplicity of ECR and printer interface combinations may be connected to a sharing interface that allows data to be exchanged within the non-sequential topology described in Figures 10a and 10b.
Detailed Description [0033] Various embodiments of the present invention provide a technological and commercial solution to allow a merchant's checkout system (Fig. 4a, Fig. 4b) to achieve compliance with SRM legislation.

[0034] A checkout system 101 generally consists of a point of sale (POS) system 110 or an electronic cash register (ECR) 111 and a receipt printer 130. A POS
system Anglehart et al. ¨ Patent Agents / Agents de brevets 110 is composed of computer hardware 400 and software 500 required to complete a sales transaction. An ECR 111 likewise carries out similar functions despite a larger proportion of its components being traditionally implemented and housed in hardware.

[0035] POS and ECR hardware 400 may include, without limitation, a barcode scanner, an RFID scanner, a keyboard, or another device such as a digital scale etc., all of which serve to identify, enumerate, or otherwise input information pertaining to the items purchased for a transaction to the point of sale system 110. Additional hardware to process transactions, such as a credit or debit card reader, PIN pad, till, and cash drawer is also typically present. The POS hardware typically interfaces 425 with POS
software, which runs on any of several popular computer operating systems or their variants customized for use in POS system environments. In a similar manner, such hardware typically interfaces to an ECR.

[0036] POS software 500 interfaces with a merchant's POS data source(s) containing a complete enumeration of all product or service items offered for sale by said merchant 610, as well as the corresponding pricing information for each item.
Optionally, the product data source may consist entirely of ¨ or alternatively integrate with ¨ more advanced inventory management software and in at least one embodiment may consist of multiple interconnected data sources. Said data source(s) may or may not reside in the local hardware. In another embodiment, the POS software 500 and/or its data source(s) 600 may run on any one or more mobile device(s) or physical local computer(s). In other embodiments, the point of sale system 110 may be implemented and/or run on one or more computer(s) or virtual machine(s), configured physically or virtually, locally or on remote computers, configured as servers or clients, or configured in the cloud, and/or accessed through a desktop virtualization service (including but not limited to a VDI environment).

Anglehart et al. - Patent Agents / Agents de brevets [0037] In addition to the POS system hardware or ECR hardware described above, a checkout system frequently includes a receipt printer 130 which produces a printed record of a transaction. The printed receipt produced typically identifies relevant details of a transaction. Such details include, without limitation, merchant identification, items purchased, amount paid for each other, total amount of the transaction, amount of tax paid, method of payment, and when the transaction occurred.

[0038] In service-industry businesses, a transaction typically consists of a specific contract of sale whereby a merchant transfers ownership of property to and/or carries out a particular service for a customer for a price in money, which the customer agrees to pay. The transaction formally begins when the customer selects one or more items for purchase from the merchant. The merchant then provides the item(s) to the customer, with the transaction being formally coordinated via the POS system 110. A
printed record of the transaction is then produced by directing the POS system or ECR
to send all the relevant transaction details to the receipt printer 130.
Duplicates of such records are typically produced, one copy of which is provided to the customer, and the other copy retained by the merchant. The transaction is completed once the customer pays the total amount indicated on the receipt, which includes amounts for all goods or services rendered by the merchant, in addition to any and all required tax(es).
Consistent with existing legislation, the merchant subsequently declares all revenues obtained from all individual transactions completed thusly and remits all tax amounts collected to the appropriate tax agency under whose jurisdiction the merchant operates.

[0039] The sequence just described enumerates the actions that must essentially be carried out for a transaction to be concluded in the proper form. However, the sequence above can be perverted in such manner as to unjustly and illegitimately profit a merchant. Such enrichment is achieved through the deliberate misrepresentation of some or all of the details surrounding one or more transactions. This scheme is Anglehart et al. - Patent Agents / Agents de brevets rendered technically feasible through the introduction of an unlawful automated sales suppression device 300 (a type of which is commonly referred to as a "zapper"
302) to the existing POS system 110 or ECR 111.

[0040] Through a combination of technological manipulation 325, 350, 350' and sleight of hand, the full amount of money for all goods or services rendered by the merchant will first be collected from the customer. However, when the final receipt is supplied by the merchant to the customer, it will only include a fraction of all the items truly part of the entire transaction. This removal of goods and services from the transaction record is achieved when the automated sales suppression device 300 is directed, typically by a human POS system operator employed by the merchant, to erase one or more items from a single transaction. Since only a portion of the real transaction is thus recorded, it follows that only a portion of all tax amounts collected for the transaction are recorded as well. However, the full amounts both for goods/services and tax for the transaction have indeed been collected and pocketed by the merchant.
This scheme constitutes tax fraud in that the merchant evades remitting to the relevant tax authorities all the monies that said merchant is obligated to transfer.

[0041] Tax authorities have instituted measures, using a combination of technological means and legislation, to counteract and ideally prevent fiscal fraud perpetrated in the manner described above. The countermeasures implemented apply an essentially two-pronged approach. Firstly, they compel merchants to issue a receipt 140, 240 for all transactions, and secondly, they seek to ensure the data integrity of all POS or ECR transactions. The latter measure is achieved by independently archiving key transaction details in a secured space accessible to tax authorities in order to guarantee that the printed receipts represent a true record of the transactions completed. Transaction details include, without limitation, the time of each transaction, the amount paid for all items purchased, the amount collected in tax, and the total Anglehart et al. ¨ Patent Agents / Agents de brevets amount of the receipt. These details are archived by means of and within a government-approved microcomputer, in some jurisdictions known as a sales recording module (SRM) 220. In at least one jurisdiction (Quebec, Canada), this microcomputer is also commonly referred to as MEV (for module d'enregistrement des ventes).

[0042] The SRM microcomputer 220 requires that the POS system 210 or ECR 211 as well as receipt printer 230 to which the SRM 220 respectively 215, 216, 225 connects be compatible both with SRM legal requirements and technical operation specifications. Key components of SRM compatibility include the legal requirement that the POS system 210 or ECR 211 provide the SRM microcomputer with direct and untannpered access to the POS transaction data.

[0043] The SRM microcomputer 220 obtains the details for the transaction in progress and usually generates, depending on the legislative jurisdiction and without limitation, a digitally signed barcode 241. In an embodiment, said barcode may be one or more QR code(s) or, more generally, any of several other types of code. The SRM
microcomputer 220 then passes the receipt data 215, 216 received from the POS
system 210 or ECR 211 in addition to the barcode 241 that was generated in the previous step by the SRM 220 to the SRM-compatible receipt printer 230 for printout 235. In addition, the SRM microcomputer 220 can log data for the production of sales summaries, which can be transferred to the tax authorities at specified intervals or as required by government legislation. Said transfer may be implemented, without limitation, by way of a network connection, through the production of a summary by way of a bulk printout of required data, through export to an external storage source (such as a USB key or other portable device), or via any other method. The data to transfer is prepared and provided to the appropriate authority, irrespective of implementation method.

Anglehart et al. - Patent Agents / Agents de brevets [0044] The integration of an SRM microcomputer module into an existing checkout system 100 represents a logistical, financial, and technical challenge to merchants and POS system manufacturers and publishers alike. Considering that the SRM
microcomputer 220 also requires a compatible POS system 210 or a compatible ECR
211 as well as a compatible receipt printer 230 to operate, such a government-mandated counter-fraud initiative inevitably involves the replacement of a merchant's entire checkout system 100. Not only does such a complete replacement represent a significant expense to the merchant, SRM compatibility requirements typically shrink the available pool of approved checkout system components 210, 211, 220, 230 to choose from.

[0045] Various embodiments of the present invention seek to implement SRM
compatibility without the attendant costs; on the one hand, to a merchant who would otherwise need to deploy a new checkout system, and on the other, to a POS
system manufacturer or publisher who would otherwise need to go to significant and complicated efforts to ensure said compatibility both commercially and technically. It accomplishes this by providing a software solution to interface directly with 725 any existing POS system 100. In their capacity as middleware, some embodiments of the present invention satisfy SRM compatibility requirements otherwise expected of an approved POS system.

[0046] In one embodiment, the present invention is introduced onto an existing (and non-SRM-compatible) POS computer by way of a standard computer installation program. The installation program is configured to adapt some embodiments of the present invention to the existing POS system through a standard installation wizard. In another embodiment, the present invention can be deployed as an embedded component or package featured or otherwise bundled within a broader POS
software installation kit. In yet another embodiment, the invention can be deployed via an Anglehart et al. ¨ Patent Agents / Agents de brevets automated and/or silent installation that in an embodiment may periodically connect to an approved network location and obtain or upgrade components when needed. In another embodiment, the invention may be deployed through the physical introduction of some external hardware device or medium (such as a USB key or other dongle), wherein said hardware device may need to be present only once (for example, during deployment), or running permanently thereafter in whole or in part from said external hardware device. Note that the above-mentioned embodiments are non-limiting and other embodiments are possible. The purpose of the installation is to load onto the POS
computer all of the components required for certain embodiments of the present invention to be configured to function as SRM-compatibility-rendering middleware.

[0047] Merchants whose activities are potentially susceptible to SRM
legislation may operate any of a wide array of contemporary checkout systems. Most contemporary checkout systems fall under one of two broad categories, namely POS systems 110, discussed above, and ECRs (electronic cash registers) 111. As a result of the software-based nature of their deployment and implementation, it will be appreciated that the scope of various embodiments of the present invention are limited to POS
systems alone 110.

[0048] Recall that in a traditional SRM compatibility paradigm 200, the receipt printer selected must itself be SRM-compatible 230. However, some embodiments of the present invention deviate considerably from the traditional SRM paradigm.
Instead of requiring an SRM-compatible receipt printer, the middleware requires only a printer driver to emulate the target receipt printer 700, provided that the SRM
microcomputer, which must also have an enabled internal printer emulation function, imposes no limitations itself on such functionality and allows an embodiment of the present invention to thusly ensure such compatibility. The function of the printer driver 700 is to direct an embodiment of the present invention to correctly format the layout of the receipt, before Anglehart et al. ¨ Patent Agents / Agents de brevets transmitting its contents to the receipt printer 230. A library of all available SRM-compatible printer drivers thusly emulated and with which an embodiment of the present invention can integrate is available from the above-mentioned installation media. In a topology involving an embodiment of the present invention and in which the SRM

lies between the POS computer 110 and the receipt printer 130, it may be necessary to deploy only an approved SRM-compatible printer 230 if the SRM microcomputer 220 is configured by the relevant authority to deliberately impede transmission of any data to a non-compatible receipt printer 130.

[0049] The next configuration step consists of integrating an embodiment of the present invention with the checkout system's existing POS data source 600.
Various embodiments of the present invention implement SRM compatibility vis-a-vis the POS
transaction data source 600 in the embodiments' configurable capacity as middleware to interface 725 with the multitude of different POS systems in existence. In addition, the SRM compatibility implemented by the various embodiments of the present invention must be appreciated as varying with the regulations governing the specific formats, data collection, and overall SRM compatibility rules laid out by a given fiscal jurisdiction.

[0050] In one embodiment, the invention can be configured in such manner as to both obtain guaranteed access to the POS data source 600 and to retrieve all necessary transaction details from said data source 620. The purpose of such access and retrieval functionality is to ensure that this aspect of configuration of an embodiment of the invention is complete for subsequent sections as well as to comply with SRM
legislation.

[0051] The support, by various embodiments of the invention, for several industry standard database implementations (such as Microsoft's Access or SQL) and database interfacing mechanisms (such as ODBC) facilitates the configuration and interoperation of the present invention with an existing POS system's transaction data source(s) 620.

Anglehart et al. ¨ Patent Agents / Agents de brevets Alternatively, some embodiments of the invention can also interface with transaction data sources whose records are stored in SRM-compatible XML or CSV file formats and at a location accessible to said embodiment of the invention. In another embodiment, the invention may also interact with a web service possessing push or fetch options.

[0052] Next, a data source query 730 must be configured whereby an enumeration of all the data fields within the existing POS data source to retrieve is specified to an embodiment of the present invention. The data source query is vital to the function of numerous embodiments of the present invention because it enables the request, retrieval, and conveyance of POS transaction data 620 to the SRM microcomputer 220, which, it will be recalled, is an important aspect of SRM compatibility. Some embodiments of the present invention support data source queries configured either via a GUI (Fig. 9) or via a configuration file. A checkout system's basic configuration is typically carried out once (or at most a handful of times) and its operation remains fixed for comparatively long intervals. As a result, data source queries need only seldom be configured or otherwise modified. Such modifications, when required, are carried out by individuals or entities possessing administrative privileges (as opposed to persons or groups having standard or otherwise limited user privileges). Such restrictions allow for the establishment and enforcement of a strictly controlled environment. In another embodiment, additional logging and detection functionalities can be activated to determine and report whether any modification or tampering attempts have occurred.

[0053] Traditionally, when the command to print a receipt is issued 500, a POS
system autonomously collects all the data pertaining to a transaction 620 (such as an enumeration of all items purchased) as well as other relevant data previously configured and stored in the POS system (such as merchant identifier and tax rates) 610, which will populate all the fields of the receipt. The information, as well as its precise eventual layout, is typically communicated to the printer driver with which the POS
system is Anglehart et al. ¨ Patent Agents / Agents de brevets interfaced. The printer driver subsequently issues all necessary commands to direct the receipt printer 130, 230 to produce a physical printout of the transaction. In another embodiment, and where permitted by SRM compatibility regulations, a soft or electronic copy of the receipt may also be generated and provided to the customer through various means, including, but not limited, to a file attached to an email sent to the customer, or made available to said customer within a designated area or secured account within a merchant's online portal, or otherwise available from any other location accessible by the customer.

[0054] To guarantee compatibility with SRM, various embodiments of the present invention alter this traditional sequence somewhat. Rather than issue all information to the receipt printer's native printer driver as above, transaction details for the transaction in progress (including related print and non-print commands) are issued to a virtual printer driver 700 supplied with and belonging to an embodiment of the present invention instead. Thus, a virtual image of the receipt that would traditionally be printed is temporarily stored in the embodiment of the present invention's virtual driver.

[0055] During this time, the bidirectional link between the embodiment of the present invention and the POS data source to which it has been integrated 725 is utilized to obtain any additional transaction information (both in the form of print and non-print commands) required for SRM compatibility. This additional information, together with the virtual image of the receipt described above, is bundled by an embodiment of the invention to form the complete virtual transaction data.

[0056] The POS application 500 is thus directed to output its regular receipt print data 725 via the virtual printer driver of an embodiment of the present invention 700.
However, the present invention is also configured for use with the device driver of the receipt printer 230 deployed for a given checkout system.

Anglehart et at. - Patent Agents / Agents de brevets [0057]
It will also be appreciated that in several other embodiments, particularly those in which an ECR is deployed rather than a POS system (Fig. 6b), the above-mentioned virtual printer driver may be substituted with a printer interface module 700'.
Without limitation, embodiments of said printer interface module may be controlled by way of a microprocessor, circuit, and/or firmware. Embodiments thusly operated may be configured to properly extract, manage, and format the virtual transaction data described above from the equivalent data source(s) to which the ECR connects.
Such tasks include the formulation of print and non-print commands 750' to be sent to the SRM microcomputer 220.

[0058]
In one embodiment, the invention performs optical character recognition (OCR) on the virtual image of the receipt produced and described above. During this process, the data present in the different fields of the receipt are converted by some embodiments of the invention 710 and the unaltered data thusly recognized from the virtual image of the receipt is sent directly to the SRM microcomputer by an embodiment of the invention 750. This OCR step is performed only for the transaction in progress. It takes place immediately preceding the step wherein an embodiment of the invention communicates the virtual image of the receipt to the SRM
microcomputer along with any other required non-print commands for the mandatory barcode generation. This embodiment allows an otherwise non-compatible POS system or ECR
to achieve SRM compatibility by allowing the SRM device to receive transaction data 725, 725' from the POS or ECR. Whenever SRM compatibility regulations do not prohibit it, an embodiment of the present invention may also combine both a recognition of the virtual image of parts of the receipt with data received from the POS
system described earlier.

[0059]
Irrespective of the embodiment of the present invention, the SRM
microcomputer 220 receives as an input the complete virtual transaction data and Anglehart et al. - Patent Agents / Agents de brevets affixes to it the requisite barcode. The result is then output 236 to the printer driver, via the SRM microcomputer's output serial port, to produce the physical record of the transaction 240.

[0060] While the SRM microcomputer 220 is described above as receiving and transmitting both print and non-print data via a serial port, it should not be construed that, for all SRM microcomputers deployed in all jurisdictions, such data communication involving said hardware must take place via this hardware interface and related data protocol alone. Accordingly, it wit! be appreciated that such communication may also be realized using other interfaces, including, without limitation, parallel port, USB port, Ethernet port, optic fiber, Wi-Fi, or through an add-on dongle of any interface, including but not limited to those just enumerated.

[0061] Although a standalone POS application or ECR with a simple topology involving a single and dedicated SRM microcomputer sequentially connected to a single and dedicated receipt printer has been largely discussed herein, it will be appreciated that additional topologies involving other permutations of these components are possible for embodiments of the present invention. This is particularly the case in jurisdictions where a direct connection between the SRM microcomputer and a receipt printer ¨ and a corresponding sequential layout of said components ¨ is not imperative.
In such cases, embodiments of the invention may exist (as in Figs. 10a, 10b), in which both print and non-print data may be variously and concurrently transmitted to the SRM
module and receipt printer. In some embodiments of the invention, such transmission need not be concurrent; for example, data may be first sent to the SRM module, which generates a barcode or other anti-fraud record or signature to indicate a bill's authenticity. In some such embodiments, required print and/or non-print data may subsequently be routed to the POS computer/ECR, in whole or in part, after which the print data required to print the receipt ¨ as and if required ¨ is sent to the receipt printer.

Anglehart et al. - Patent Agents / Agents de brevets [0062] As a non-limiting example, one non-sequential topology may consist of a number of POS computers and/or ECRs all connected to a single common printer.
Another topology (Fig. 11) may involve a pool of POS computers and/or ECRs interfaced with a pool of printers in which the POS computer or ECR used to process a particular transaction connects to the first available receipt printer in the pool either prior to, concurrent with, or following any interaction with SRM device as required by compliance regulations. In such embodiments, the task of correctly routing the print and non-print data traffic may be handled by a switching module or other sharing interface known in the art at present or in the future, which may also provide load balancing and flow control functionalities as required. It will be appreciated that the purpose of such switching functionality is to admit, and not exclude, a more expansive and flexible set of possible topologies for a given embodiment of the present invention.

Claims (29)

What is claimed is:

1. A point-of-sale (POS) system for use with a Sales Recording Module (SRM), the system comprising:
a non-SRM-compatible POS application configured to generate printed sales receipts using a printer interface device; and a printer interface device configured to collect data required by the SRM and to transmit to a printer printable data in a format compatible for a POS printer and non-printable data compatible with the SRM.

2. The system as defined in claim 1, wherein the POS application is connected to a POS data source and is configured to generate printed sales receipt data having insufficient information for the SRM, and the printer interface device is configured to query the POS data source to obtain data concerning a current transaction that is not present in the printed sales receipt data.

3. The system as defined in claim 2, wherein the printer interface device comprises a configuration interface permitting specification of parameters to be queried from the POS data source.

4. The system as defined in claim 1, wherein the POS application is configured to generate printed sales receipt data having sufficient information for the SRM, and the printer interface device is configured to extract from the printed sales receipt data and to prepare therefrom the non-printable data compatible with the SRM.

5. The system as defined in claim 4, wherein the printer interface device comprises an OCR component to extract data from images contained in the printed sales receipt data.

6. The system as defined in any one of claims 1 to 5, wherein the printer interface device removes some of the printed sales receipt data provided by the POS
application for the purposes of the SRM.

7. The system as defined in any one of claims 1 to 6, wherein the POS
system comprises a general purpose computer having a printer device driver configured to transmit to a printer printable data in a format compatible for a POS printer.

8. The system as defined in claim 7, wherein the POS application is run locally on said computer.

9. The system as defined in claim 7, wherein the POS application is remotely hosted.

10. The system as defined in any one of claims 1 to 6, wherein the POS
system comprises an electronic cash register.

11. The system as defined in claim 10, wherein the printer interface device is a hardware module connected to a printer bus of the electronic cash register and connectable to an SRM.

12. The system as defined in any one of claims 1 to 10, wherein the printer interface device comprises an SRM printer driver installed separately from said POS
application, wherein said POS application is configured to select the SRM printer driver as its print output destination.

13. The system as defined in claim 12, wherein the SRM printer driver is connected to a printer device driver configured to transmit to a printer printable data in a format compatible for a POS printer.

14. The system as defined in claim 13, wherein the SRM printer driver has an interface permitting selection of available one or more printer device drivers to which to connect.

15. A printer interface device for use with a point-of-sale (POS) system comprising a Sales Recording Module (SRM) and a non-SRM compatible POS application, the printer interface device configured to collect data required by the SRM to generate printed sales receipts and to transmit to a printer printable data in a format compatible for a POS printer and non-printable data compatible with the SRM.

16. The printer interface device as defined in claim 15, wherein the POS
application is connected to a POS data source and is configured to generate printed sales receipt data having insufficient information for the SRM, and the printer interface device is configured to query the POS data source to obtain data concerning a current transaction that is not present in the printed sales receipt data.

17. The printer interface device as defined in claim 16, wherein said printer interface device comprises a configuration interface permitting specification of parameters to be queried from the POS data source.

18. The printer interface device as defined in claim 15, wherein the POS
application is configured to generate printed sales receipt data having sufficient information for the SRM, and the printer interface device is configured to extract from the printed sales receipt data and to prepare therefrom the non-printable data compatible with the SRM.

19. The printer interface device as defined in claim 18, further comprising an OCR
component to extract data from images contained in the printed sales receipt data.

20. The printer interface device as defined in any one of claims 15 to 19, wherein said printer interface device removes some of the printed sales receipt data provided by the POS application for the purposes of the SRM.

21. The printer interface device as defined in any one of claims 15 to 20, wherein the POS system comprises a general purpose computer having a printer device driver configured to transmit to a printer printable data in a format compatible for a POS
printer.

22. The printer interface device as defined in claim 21, wherein the POS
application is run locally on said computer.

23. The printer interface device as defined in claim 21, wherein the POS
application is remotely hosted.

24. The printer interface device as defined in any one of claims 15 to 20, wherein the POS system comprises an electronic cash register.

25. The printer interface device as defined in claim 24, wherein said printer interface device is a hardware module connected to a printer bus of the electronic cash register and connectable to an SRM.

26. The printer interface device as defined in any one of claims 15 to 24, wherein said printer interface device comprises an SRM printer driver installed separately from said POS application, wherein said POS application is configured to select the SRM
printer driver as its print output destination.

27. The printer interface device as defined in claim 26, wherein the SRM
printer driver is connected to said printer device driver configured to transmit to a printer printable data in a format compatible for a POS printer.

28. The printer interface device as defined in claim 27, wherein the SRM
printer driver has an interface permitting selection of available one or more printer device drivers to which to connect.

29. The system as defined in any of claims 1 through 28, wherein the primary configuration of the SRM is one in which said SRM is directly connected to the receipt printer and to the POS computer or ECR, and the POS computer or ECR sends print data to the receipt printer via the SRM.