Stand-alone electronic cash registers including payment card readers and receipt printers have been used for years in stores, retail outlets and service outlets to facilitate the completion of cash, cheque, credit card or debit card transactions for the purchase of goods and/or services. With the advent of sophisticated and inexpensive computing equipment, input devices and secure communication networks, point-of-sale (POS) stations have, for the most part, replaced such stand-alone electronic cash registers.
POS stations typically include a host device and a plurality of peripherals connected to the host device. The host device is commonly in the form of a personal computer that executes a POS application. The peripherals often include a keyboard, a display screen, a cash drawer, a printing device, a payment card reader and a barcode reader. In some cases, a touch-sensitive display screen is used instead of separate keyboard and display screen peripherals. The POS application communicates with the peripherals via application program interfaces (APIs) to allow product and/or service transactions to be completed.
When payment is effected using a debit or credit card, the host device establishes a connection to the appropriate financial institution over an information network so that approval for the transaction may be obtained. Upon completion of any transaction, the host device signals the printing device causing the printing device to generate a transaction receipt and possibly a signing receipt, if payment is made using a credit card.
In larger stores, retail outlets and service outlets, POS stations are typically linked via a local area network and communicate with a backend computing device that maintains a database for transaction, inventory, accounting, sales, tax, etc. information. Transaction data received by each of the POS stations is conveyed to the backend computing device for storage in the database allowing all transaction data to be stored in a common location. Collectively storing all transaction data in one common location allows retailers to track, account for and maintain inventory, collected taxes and pricing information. Also, by linking the POS stations, updates relating to sales on products and/or services, tax, etc. can be communicated to each POS station over the local area network avoiding the need to update the POS stations one at a time.
Two initiatives to standardize the development of POS stations based on the UnifiedPOS standard have been developed, namely object linking and embedding POS (“OPOS”) and Java for Retail POS (“JavaPOS”). Java and all Java-based marks are a trademark or registered trademark of Oracle Corporation. These standards have enabled peripherals to be readily interchanged and easily integrated into POS stations allowing POS stations to be configured to meet changing needs. This of course has been a leading factor to POS station acceptance.
In JavaPOS environments, information relating to the configuration of peripherals is stored in one or more files, typically in XML format, that is separate from POS application run by the host device. Each configuration XML file contains information for all peripherals connected in a given configuration. The configuration XML file associated with the desired configuration is selected for use. To link the POS application and the configuration XML files, the POS application comprises a compressed Java archive (JAR) file that embodies a properties file storing pointers to the configuration XML files.
When a configuration XML file is deployed, i.e the selected configuration XML file is saved to a new location or a new configuration XML file that is to be used is saved, in order to update the pointer associated with the deployed configuration XML file, it has been necessary for a user to extract manually the compressed JAR file, locate and access the properties file therein and then update the appropriate pointer entry so that the pointer entry correctly points to the deployed configuration XML file. As will be appreciated, updating the pointer entry in this manner is cumbersome and time consuming.
Methods for enhancing the use of Java archive files and Java implemented applications, and improving file management are well documented in the art. For example, U.S. Pat. No. 6,571,389 to Spyker et al. discloses a method, system, and computer-readable code for improving the manageability and usability of a Java environment. A technique that combines the advantages of applets and applications while avoiding particular disadvantages of both is employed whereby all Java programs are executed without relying on the use of a browser to provide a run-time environment. Dependencies are specified in a manner that enables the Java programs to be dynamically located and installed, and in a manner that enables sharing dependent modules (including run-time environments) among applications. The dependency specification technique ensures that all dependent code will be automatically available at run-time, without requiring a user to perform manual installation. The run-time environment required for an application is specified, and a technique is provided for dynamically changing the run-time that will be used (including the ability to change run-times on a per-program basis), without requiring user intervention.
U.S. Patent Application Publication No. 2003/0225795 to Abdallah et al. discloses a mechanism for extending a Java archive file to include additional information that describes the contents of the archive file as update information. The mechanism comprises a program for determining differences between an initial file system tree and a final file system tree and for encoding the differences into entries in a Java archive file. An extractor class is included in the Java archive file and named as the main class. The Java archive file may be transported to a site that needs a file system update. The Java archive file may be executed in a Java runtime environment to update a target file system. The extractor class is executed to decode and effectuate the difference entries in the Java archive file.
U.S. Patent Application Publication No. 2004/0123285 to Berg et al. discloses application configurations, including applications themselves, application components, and modules associated with applications, which are installed on an application-server machine and stored in system-determined locations. The system-determined locations, or absolute paths, are then stored in a “loose configuration”. As new versions of applications, application components, and/or modules are installed, they are placed in unique locations and given unique version numbers. Records of each application configuration version are stored and are referred to as “snapshots”. These snapshots provide a record of, and pointers to, the various elements that make up the various application configuration versions, so that at any time, a current version of an application configuration can be “rolled back” to a previous version of an application configuration. The methodology can be utilized to provide a self-healing configuration, whereby a faulty version of an application configuration can be rolled back to a previous version automatically.
U.S. Patent Application Publication No. 2005/0021688 to Felts et al. discloses a system and method of configuring a domain. The method comprises providing a first user interface operable to configure the domain and a second user interface operable to configure a cluster. Configuration of the domain is based on a domain template.
U.S. Patent Application Publication No. 2005/0234987 to Cyphers discloses a method for updating values within the contents of a Java archive (JAR) file without altering the JAR file structure. A smart archive program (SAP) creates a temporary directory in memory and stores the JAR file structure in the memory. The SAP then extracts the JAR file content into the temporary directory and allows the user to update the field values within the JAR file content. When the user has finished updating the field values in the JAR file content, the SAP archives the JAR file content into a new JAR file according to the JAR file structure stored in the memory. Consequently, field values within the JAR file content can be updated without altering the JAR file structure.
U.S. Patent Application Publication No. 2005/0240902 to Bunker et al. discloses a system and method for an extendable application framework, comprising a user interface, at least one service, and at least one extension. At least one of the extensions provides access to functionality in the user interface and at least one of the services provides access to functionality in at least one of the extensions.
U.S. Patent Application Publication No. 2005/0278280 to Semerdzhiev et al. discloses a system for updating files in a computer system. The update system downloads files from a centralized database during a start up process. The start up process completes loading of all services and applications to be provided by the computer system and then initiates an update process. During the update process, open archive files are closed and may be replaced by downloaded files. File replacement is handled by an updated module without requiring the generation of scripts or code to be executed during a subsequent start up process in order to complete the update.
As will be appreciated, although the above references disclose Java management techniques, there exists a need for an improved method of dealing with POS peripheral configuration updates. It is therefore an object of the present invention to provide a novel configuration tool and method of updating an archive file property relating to at least one point-of-sale (POS) peripheral.