ON ELECTRONIC DOCUMENTS

CROSS-REFERENCE TO RELATED APPLICATIONS

[001] This application claims the benefit of U.S. Provisional Application No. 62/261 ,355 filed on December 1 , 2015. This application also claims the benefit of US Provisional Patent Application No. 62/260,553 filed on November 29, 2015. The contents of the above- referenced applications are hereby incorporated by reference.

TECHNICAL FIELD

[002] The present disclosure relates generally to data analysis, and more particularly to generating reports using image-based electronic documents.

BACKGROUND

[003] As businesses increasingly rely on technology to manage data related to operations, suitable systems for properly managing and validating data have become crucial to success. Particularly for large businesses, the amount of data utilized daily by businesses can be overwhelming. Accordingly, manual review and validation of such data is impractical, at best. In addition to normal sales data, businesses in countries where value- added taxes (VATs) are applied collect and utilize even more data, thereby raising additional potential points of failure.

[004] The challenges facing customers seeking a refund and, in particular, seeking VAT refunds, may result in customers becoming discouraged and failing to follow through on obtaining their refunds. This issue is further compounded when the customer is an employee of an enterprise because the customer is not directly benefiting from the refund. Moreover, employees may submit irrelevant or duplicate information that is unnecessary for seeking refunds. Filtering through such unnecessary information may be time- consuming, costly, and subject to a large degree of human error.

[005] Additionally, many existing solutions for validating based on data face challenges in obtaining the data required for validation. Specifically, existing solutions typically require either structured data or data that otherwise adheres to particular format requirements (e.g., a required size of a scanned image, markings indicating validation-related information, etc.) in order to identify and utilize the data. Such existing solutions face challenges when appropriately formatted data cannot be obtained. In particular, such existing solutions may be unable to complete validation or may return inaccurate results (e.g., false positives and false negatives) when required data cannot be properly identified. Such issues may occur when, for example, data is unstructured or semi- structured, or when data is at least partially structured but in an unrecognizable format so as to effectively render the data unstructured for analysis purposes. These issues are compounded when multiple sets of data requirements (e.g., requirements for VAT refunds and for RCM validation) must be met. Manual checking to account for these issues is inefficient and introduces new potential sources of error.

[006] Further, when information used for validation is contained in, for example, receipts or other physical documents, electronic documents associated with that information typically include images. Such image-based electronic documents require more storage than text- based documents, and utilize more computing resources to transmit.

[007] It would therefore be advantageous to provide a solution that would overcome the challenges noted above.

SUMMARY

[008] A summary of several example embodiments of the disclosure follows. This summary is provided for the convenience of the reader to provide a basic understanding of such embodiments and does not wholly define the breadth of the disclosure. This summary is not an extensive overview of all contemplated embodiments, and is intended to neither identify key or critical elements of all embodiments nor to delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description that is presented later. For convenience, the term "some embodiments" may be used herein to refer to a single embodiment or multiple embodiments of the disclosure.

[009] Certain embodiments disclosed herein include a method for automatically generating reports. The method includes: retrieving reporting requirements for an enterprise; obtaining, based on the retrieved reporting requirements, at least partially unstructured data; creating, based on the obtained at least partially unstructured data, at least one template, wherein each template is a structured dataset; and generating, based on the created at least one template and the retrieved reporting requirements, at least one report.

[0010] Certain embodiments disclosed herein also include a non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to perform a process, the process comprising: retrieving reporting requirements for an enterprise; obtaining, based on the retrieved reporting requirements, at least partially unstructured data; creating, based on the obtained at least partially unstructured data, at least one template, wherein each template is a structured dataset; and generating, based on the created at least one template and the retrieved reporting requirements, at least one report.

[0011] Certain embodiments disclosed herein also include a system for automatically generating reports. The system comprises: a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to: retrieve reporting requirements for an enterprise; obtain, based on the retrieved reporting requirements, at least partially unstructured data; create, based on the obtained at least partially unstructured data, at least one template, wherein each template is a structured dataset; and generate, based on the created at least one template and the retrieved reporting requirements, at least one report.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The subject matter disclosed herein is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the disclosed embodiments will be apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0013] Figure 1 is a network diagram utilized to describe the various disclosed embodiments.

[0014] Figure 2 is a schematic diagram of a report generator according to an embodiment.

[0015] Figure 3 is a flowchart illustrating a method for automatically generating and sending reports according to an embodiment.

[0016] Figure 4 is a flowchart illustrating a method for creating a template according to an embodiment. [0017] Figure 5 is a flowchart illustrating a method for generating a dataset based on an electronic document according to an embodiment.

[0018] Figure 6 is a flowchart illustrating a method for determining whether an entity is verified according to an embodiment.

[0019] Figure 7 is a flowchart illustrating a method for generating a report according to an embodiment.

DETAILED DESCRIPTION

[0020] It is important to note that the embodiments disclosed herein are only examples of the many advantageous uses of the innovative teachings herein. In general, statements made in the specification of the present application do not necessarily limit any of the various claimed embodiments. Moreover, some statements may apply to some inventive features but not to others. In general, unless otherwise indicated, singular elements may be in plural and vice versa with no loss of generality. In the drawings, like numerals refer to like parts through several views.

[0021] The various disclosed embodiments include a method and system for automatic generation of reports. In an embodiment, data indicating enterprise characteristics of an enterprise for which a report should be generated is obtained. Based on the obtained data, at least one database storing reporting requirements for the enterprise is selected and the reporting requirements are retrieved from the selected at least one database. Data including information to be reported is obtained. Based on the reporting requirements and the reporting information data, a template is created. Based on the created template, a report is generated. The report may be sent to, e.g., a system of a reporting authority. A notification indicating the generation may be generated and sent to, e.g., a client device.

[0022] Fig. 1 shows an example network diagram 100 utilized to describe the various disclosed embodiments. In the example network diagram 100, a report generator 120, a client device 130, a plurality of reporting authority (RA) databases 140-1 through 140-N (hereinafter referred to individually as a reporting authority database 140 and collectively as reporting authority databases 140, merely for simplicity purposes), and an enterprise database 150, are communicatively connected via a network 1 10. The network 1 10 may be, but is not limited to, a wireless, cellular or wired network, a local area network (LAN), a wide area network (WAN), a metro area network (MAN), the Internet, the worldwide web (WWW), similar networks, and any combination thereof.

[0023] The reporting authority databases 140 may be, but are not limited to, regulatory databases storing data related to requirements for reporting. As a non-limiting example, the reporting authority database 140-1 may be a database of a tax agency that stores data indicating requirements for properly reporting VAT reclaim requests or other regulatory requirements. Such requirements may include, but are not limited to, a required type of regulatory report, required time pointers, required information (e.g., price, type of goods or services, etc.), and the like. The requirements may be stored in the form of, e.g., rules.

[0024] The enterprise database 150 stores data associated with an entity (e.g., a business or other enterprise, etc.). The entity data may include, but is not limited to, previously generated or filed reports, enterprise resource planning (ERP) data, consumer relationship management (CRM) data, enterprise characteristics, and the like. The enterprise characteristics may include, but are not limited to, whether the entity is a private corporation or a publicly traded corporation, revenues, profits, territories of operation, enterprise identifiers (e.g., an enterprise name, an enterprise identification number, a regulator reporting number, etc.), and the like. Any or all of the enterprise characteristics may be stored as metadata. The enterprise characteristics may be utilized to, e.g., determine reporting requirements.

[0025] The enterprise database 150 may further store electronic documents (e.g., an image file showing a scan of an invoice or other physical document, a text file, a spreadsheet file, etc.) including information used for reporting. Data included in the electronic document may be structured, semi-structured, unstructured, or a combination thereof. The structured or semi-structured data may be in a format that is not recognized by the validation system 120 and, therefore, may be treated like unstructured data.

[0026] In an embodiment, the report generator 120 is configured to collect the data indicating the enterprise characteristics from the enterprise database 150. In a further embodiment, based on the enterprise characteristics data, the report generator 120 is configured to select at least one of the databases 140 from which to retrieve reporting requirement data. As a non-limiting example, when enterprise characteristics of an enterprise indicate that the enterprise operates in Italy and in France, a reporting authority database 140-1 of an Italian regulatory agency and a reporting authority database 140-2 of a French regulatory authority are selected.

[0027] In an embodiment, the report generator 120 is configured to retrieve, from the selected at least one reporting authority database 140, a plurality of reporting requirements. In a further embodiment, the plurality of reporting requirements may be retrieved based on the enterprise characteristics. As a non-limiting example, the reporting requirements may be determined based on a geographic location of the enterprise, whether the enterprise is publicly or privately held, a net income of the enterprise, a gross income of the enterprise, a combination thereof, and the like.

[0028] In another embodiment, the retrieval of the reporting requirements may occur periodically based on, e.g., the enterprise characteristics and one or more retrieval rules. The retrieval rules may be predetermined. As a non-limiting example, if private enterprises are required to file a tax report annually and public enterprises are required to file a tax report quarterly, the retrieval rules may require annual retrieval and reporting for enterprises having private enterprise characteristics and quarterly retrieval and reporting for enterprises having public enterprise characteristics.

[0029] In an embodiment, the report generator 120 is configured to create datasets based on electronic documents including at least partially unstructured data. Data may be at least partially unstructured if it is or includes unstructured data, semi-structured data, structured data having an unknown structure, or a combination thereof. To this end, the report generator 120 may be further configured to utilize optical character recognition (OCR) or other image processing to determine data in the electronic document.

[0030] In an embodiment, the report generator 120 is configured to analyze the created datasets to identify reporting parameters indicated in the electronic documents. The reporting parameters include information required for reporting. As a non-limiting example, when reporting transactions for VAT refunding, the reporting parameters may include, but are not limited to, geographic location of purchase, type of goods or services purchased, amount spent, and the like. In some embodiments, the report generator 120 may be configured to verify an entity indicated in the created datasets. In another embodiment, the report generator 120 may be configured to determine whether the created datasets are eligible for reporting based on, e.g., whether the dataset meets at least one predetermined constraint.

[0031] In an embodiment, the report generator 120 is configured to create at least one template based on the created datasets. The template is a structured dataset including the identified reporting parameters. In a further embodiment, the report generator 120 is configured to apply, in real-time, at least one rule to the created template to determine if requirements for, e.g., validation are met by the transaction. In yet a further embodiment, the at least one template may be created based on the retrieved reporting requirements. In a further embodiment, each template may be created based on a different set of reporting requirements (e.g., a first template may be created based on reporting requirements of a first regulatory agency and a second template may be created based on reporting requirements of a second regulatory agency).

[0032] In an embodiment, based on the created at least one template, the report generator 120 is configured to generate at least one report. The at least one report indicates the identified reporting parameters. Utilizing a structured dataset template for generating a report reduces use of computing resources related to storing, transmitting, and analyzing datasets as compared to use of unstructured, semi-structured, or unknown structure data. In a further embodiment, generating the report may include completing at least one reporting form using the created at least one template.

[0033] In an embodiment, the report generator 120 may be configured to generate a notification. The report generator 120 may be further configured to send the notification, the generated report, or both, to, for example, the client device 130 communicatively connected to the network 1 10, a system associated with a regulatory agency, or both. The client device 130 may be, but is not limited to, a personal computer, a laptop, a tablet computer, a smartphone, a wearable computing device, or any other device capable of receiving and displaying notifications. The client device 130 may be, for example, a user device of a business engaged in a transaction that wishes to know whether the transaction is validated.

[0034] It should be noted that the embodiments described herein above with respect to Fig.

1 are described with respect to one enterprise database 150 merely for simplicity purposes and without limitation on the disclosed embodiments. Multiple enterprise databases may be equally utilized without departing from the scope of the disclosure.

[0035] Fig. 2 is an example schematic diagram of the report generator 120 according to an embodiment. The report generator 120 includes a processing circuitry 210 coupled to a memory 215, a storage 220, and a network interface 240. In an embodiment, the report generator 120 may include an optical character recognition (OCR) processor 230. In another embodiment, the components of the report generator 120 may be communicatively connected via a bus 250.

[0036]The processing circuitry 210 may be realized as one or more hardware logic components and circuits. For example, and without limitation, illustrative types of hardware logic components that can be used include field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), Application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), and the like, or any other hardware logic components that can perform calculations or other manipulations of information.

[0037]The memory 215 may be volatile (e.g., RAM, etc.), non-volatile (e.g., ROM, flash memory, etc.), or a combination thereof. In one configuration, computer readable instructions to implement one or more embodiments disclosed herein may be stored in the storage 220.

[0038] In another embodiment, the memory 215 is configured to store software. Software shall be construed broadly to mean any type of instructions, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code). The instructions, when executed by the one or more processors, cause the processing circuitry 210 to perform the various processes described herein. Specifically, the instructions, when executed, cause the processing circuitry 210 to perform automatic generation of reports, as discussed herein.

[0039] The storage 220 may be magnetic storage, optical storage, and the like, and may be realized, for example, as flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs), or any other medium which can be used to store the desired information.

[0040] The OCR processor 230 may include, but is not limited to, a feature and/or pattern recognition unit (RU) 235 configured to identify patterns, features, or both, in unstructured data sets. Specifically, in an embodiment, the OCR processor 230 is configured to identify at least characters in the unstructured data. The identified characters may be utilized to create a validation dataset including data required for validation of a transaction.

[0041] The network interface 240 allows the report generator 120 to communicate with the client device 130, the databases 140, the enterprise database 150, or a combination of, for the purpose of, for example, collecting metadata, retrieving data, sending reports and notifications, and the like. Additionally, the network interface 240 allows the report generator 120 to communicate with the client device 130 in order to send reports and notifications related thereto.

[0042] It should be understood that the embodiments described herein are not limited to the specific architecture illustrated in Fig. 2, and other architectures may be equally used without departing from the scope of the disclosed embodiments.

[0043] Fig. 3 is an example flowchart 300 illustrating a method for automatically generating and sending reports based on enterprise data according to an embodiment. In an embodiment, the method may be performed by a report generator (e.g., the report generator 120).

[0044] At S310, entity characteristics data is obtained. The entity characteristics data may be collected from, e.g., an enterprise database (e.g., the enterprise database 150). In an embodiment, the entity characteristics data may be obtained periodically.

[0045] At S320, based on the obtained entity characteristics data, reporting requirements are retrieved. In an embodiment, S320 further includes selecting at least one database storing reporting requirements. The selected at least one database stores reporting requirements for reporting related to the enterprise. As a non-limiting example, when the entity characteristics data indicates that the enterprise is in Spain and a report related to VAT refunds is to be generated, a database storing reporting requirements for claiming VAT refunds in Spain may be selected and the reporting requirements for claiming VAT refunds in Spain are retrieved. [0046] At S330, data including information to be reported is obtained based on the retrieved reporting requirements. The data may be obtained from, e.g., an enterprise database (e.g., the enterprise database 150). The obtained data may include at least one electronic document, and may be at least partially unstructured (i.e., the data may be or may include unstructured data, semi-structured data, or data lacking a recognized structure). Any of the electronic documents may be an image file.

[0047] At S340, a template is created based on the obtained data. The template is a structured dataset including key fields and values of the obtained data. Creation of templates based on at least partially unstructured data is described further herein below with respect to Fig. 4.

[0048] At S350, a report is generated based on the created template. In an embodiment, generating the report may include completing at least one reporting form. Generating reports based on templates is described further herein below with respect to Fig. 7.

[0049] At optional S360, the generated report may be sent to, for example, a client device (e.g., the client device 130), to a system of a reporting authority (e.g., a regulatory agency responsible for accepting and processing reports), or both. The sent report may be caused to be displayed on the client device 130. In another embodiment, S360 may include generating a notification indicating the generation of the report and sending the notification to, e.g., the client device 130. In a further embodiment, the notification may indicate, e.g., a deadline for filing the report.

[0050] In another embodiment, S360 may further include generating a dashboard for displaying the generated report, data related to the report (e.g., a data of sending of the report to the appropriate reporting authority), or both. A dashboard is an interactive management tool, an application programming interface (API), or both, used for displaying and managing reports.

[0051] It should be noted that the embodiments described herein above with respect to Fig.

3 are discussed with reference to creating a template and a report merely for simplicity purposes and without limitation on the disclosed embodiments. Multiple templates may be created, and for each template at least one report may be generated, without departing from the scope of the disclosure. [0052] Fig. 4 is an example flowchart S340 illustrating a method for creating a structured data template based on electronic documents including at least partially unstructured data according to an embodiment.

[0053] At S410, a dataset is created based on at least one electronic document including information to be reported. Each of the at least one electronic document may include at least partially unstructured data such as, but is not limited to, unstructured data, semi- structured data, structured data with structure that is unanticipated or unannounced, or a combination thereof. In an embodiment, S410 may further include analyzing the electronic document using optical character recognition (OCR) to determine data in the electronic document, identifying key fields in the data, identifying values in the data, or a combination thereof. Creating datasets based on electronic documents is described further herein below with respect to Fig. 5.

[0054] At S420, the created dataset is analyzed. In an embodiment, analyzing the dataset may include, but is not limited to, determining reporting parameters such as, but not limited to, at least one entity identifier (e.g., a consumer enterprise identifier, a merchant enterprise identifier, or both), information related to transactions (e.g., a date, a time, a price, a type of good or service sold, etc.), entity financial information, or a combination thereof. In a further embodiment, analyzing the dataset may also include identifying the transaction based on the dataset.

[0055] At optional S430, an entity indicated in the created dataset may be verified. The verification may be utilized to ensure, e.g., that the entity of the transaction is the entity for which a report should be generated. In an embodiment, the verification is based on the determined at least one entity identifier. In a further embodiment, S430 may include searching in at least one database based on the at least one identifier. Verifying entities of transactions based on datasets created using electronic documents dataset is described further herein below with respect to Fig. 6. In another embodiment, if the entity is not verified, it may be determined that the electronic document is not relevant to the reporting and a report may not be generated.

[0056] At S440, a template of the transaction is created. The template may be, but is not limited to, a data structure including a plurality of fields. The fields may include the identified transaction parameters. The fields may be predefined. [0057] Creating templates from electronic documents allows for faster processing due to the structured nature of the created templates. For example, query and manipulation operations may be performed more efficiently on structured datasets than on datasets lacking such structure. Further, organizing information from electronic documents into structured datasets, the amount of storage required for saving information contained in electronic documents may be significantly reduced. Electronic documents are often images that require more storage space than datasets containing the same information. For example, datasets representing data from 100,000 image electronic documents can be saved as data records in a text file. A size of such a text file would be significantly less than the size of the 100,000 images.

[0058] Fig. 5 is an example flowchart S410 illustrating a method for creating a dataset based on at least one electronic document according to an embodiment.

[0059] At S510, the at least one electronic document is obtained. Obtaining each electronic document may include, but is not limited to, receiving the electronic document (e.g., receiving a scanned image) or retrieving the electronic document (e.g., retrieving the electronic document from an enterprise system, a database, or both).

[0060] At S520, the at least one electronic document is analyzed. The analysis may include, but is not limited to, using optical character recognition (OCR) to determine characters in the electronic document.

[0061] At S530, based on the analysis, key fields and values in the electronic document are identified. The key field may include, but are not limited to, merchant's name and address, date, currency, good or service sold, a transaction identifier, an invoice number, and so on. An electronic document may include unnecessary details that would not be considered to be key values. As an example, a logo of the merchant may not be required and, thus, is not a key value. In an embodiment, a list of key fields may be predefined, and pieces of data that may match the key fields are extracted. Then, a cleaning process is performed to ensure that the information is accurately presented. For example, if the OCR would result in a data presented as "121 1212005", the cleaning process will convert this data to 12/12/2005. As another example, if a name is presented as "Mo$den", this will change to "Mosden". The cleaning process may be performed using external information resources, such as dictionaries, calendars, and the like. [0062] In a further embodiment, it is checked if the extracted pieces of data are completed. For example, if the merchant name can be identified but its address is missing, then the key field for the merchant address is incomplete. An attempt to complete the missing key filed values is performed. This attempt may include querying external systems and databases, correlation with previously analyzed invoices, or a combination thereof. Examples for external systems and databases may include business directories, Universal Product Code (UPC) databases, parcel delivery and tracking systems, and so on. In an embodiment, S530 results in a complete set of the predefined key fields and their respective values.

[0063] At S540, a structured dataset is generated. The generated dataset includes the identified key fields and values.

[0064] Fig. 6 is an example flowchart S430 illustrating a method for verifying an entity based on a dataset including information to be reported according to an embodiment.

[0065] At S610, at least one entity identifier is determined based on at least one electronic document. Each entity identifier indicates a respective entity. The at least one entity identifier may be, but is not limited to, a name of the entity, a location of the entity (e.g., an address), or both.

[0066] At S620, at least one database is searched using the at least one entity identifier. The at least one database may include, but is not limited to, databases storing entity identifiers of registered business or other entities. In an embodiment, S620 may include determining the at least one database to be searched based on entity characteristics of the entity.

[0067] At S630, based on the search, it is determined whether the entity is verified. In an embodiment, the entity is verified if at least one of the entity identifiers was found in any of the at least one database.

[0068] Fig. 7 is an example flowchart S350 illustrating a method for generating a report according to an embodiment. In an embodiment, the report may be generated using reporting requirements obtained from, e.g., a reporting authority database. Thus, the generated report may differ depending upon the reporting requirements. As a non-limiting example, a report generated for a publicly traded enterprise may include different information than a report generated for a privately owned enterprise. [0069] At S710, based on the reporting requirements, at least one reporting form potentially required for, e.g., meeting reporting regulations, is identified. The at least one potential reporting form may be retrieved from, e.g., one or more reporting authority databases (e.g., the reporting authority databases 140). In an embodiment, S710 includes crawling through the reporting authority databases for forms related to the reporting requirements. In a further embodiment, a form may be related to the reporting requirements if metadata for the form matches at least a portion of the reporting requirements above a predetermined threshold.

[0070] At S720, the identified at least one reporting form is analyzed to determine whether the report must include each reporting form. In an embodiment, S720 includes performing optical character recognition to identify key fields for providing reporting information. In a further embodiment, S720 further includes determining whether the identified key fields match the template above a predetermined threshold.

[0071] At S730, each reporting form that must be included in the report is retrieved from the reporting authority databases.

[0072] At S740, each retrieved reporting form is completed. In an embodiment, the obtained reporting forms are completed based on the created template. Using a structured dataset to complete reporting forms reduces use of computing resources as compared to use of at least partially unstructured datasets because data in structured datasets may be extracted and input into forms based on the structure and without analyzing an entire set of unstructured data.

[0073] It should be understood that any reference to an element herein using a designation such as "first," "second," and so forth does not generally limit the quantity or order of those elements. Rather, these designations are generally used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements may be employed there or that the first element must precede the second element in some manner. Also, unless stated otherwise a set of elements comprises one or more elements.

[0074] As used herein, the phrase "at least one of" followed by a listing of items means that any of the listed items can be utilized individually, or any combination of two or more of the listed items can be utilized. For example, if a system is described as including "at least one of A, B, and C," the system can include A alone; B alone; C alone; A and B in combination; B and C in combination; A and C in combination; or A, B, and C in combination.

[0075] The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium consisting of parts, or of certain devices and/or a combination of devices. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units ("CPUs"), a memory, and input/output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such a computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit. Furthermore, a non-transitory computer readable medium is any computer readable medium except for a transitory propagating signal.

[0076] All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the principles of the disclosed embodiment and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the disclosed embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.