CA2356716A1 - Point of sale terminal - Google Patents

Abstract

A Point-of-Sale terminal that uses a distributed operating system that utilizes software agents to represent parties involved in the interaction. Transaction behaviors are negotiated between the retailer, credit card agency and the customer.

Description

FIELD OF THE INVENTION
The present invention relates to the field of Point of Sale Terminals. More specifically, the present invention is a wireless PoS terminal using SOMA Network's CPE
architecture.
SUMMARY OF THE INVENTION
The present invention provides a Point-of-Sale terminal (PoS terminal) based upon SOMA Network' network, hardware and software architecture, as described in Canadian Patent application 2,302,461, filed 27 March 2000.
Credit card issuers or the like own point-of-sale operations. SOMA would offer one or more of them (SOMA partners) an upgraded terminal. The PoS terminal is backwards-compatible so that other credit card issuers or debit-card issuers also benefit from the faster "always on" transaction speed but SOMA Partners would be the first movers on advanced features.
Abstractly, a credit-card swipe is "like dialing", and the PoS terminal re-uses much of the SOMA architecture. The credit-card number is transmitted to a database owned by the credit card company. Based upon rules defined by the credit card company and preferences set by the retailer and card user, the transaction is processed.
BACKGROUND OF THE INVENTION
The 14.4k modem in a Verifone (e.g.) modem adds 8 seconds to a transaction, slowing down the line and giving clients a period of tension about the outcome. Each terminal requires its own line and the setup generally prevents flexibility for retailers who wish to deploy extra terminals during peak periods or at specific locations in the store.
The functionality of a conventional PoS terminal is limited to authorizing/declining transactions, and provides little in the way of customization.
BRIEF DESCRIPTION OF THE DRAWINGS
Preferred embodiments of the present invention will now be described, by way of

-2-example only, with reference to the attached Figures, wherein Figure 1 shows a diagram of the invention.
DETAILED DESCRIPTION OF THE INVENTION
Multiple PoS terminals communicate with a remote base station (typically across wireless protocols), that in turn is connected to other networks, such as the Internet, private date networks, the PSTN, and private leased-line networks. Each base station can support multiple PoS terminals as well as traditional SOMA CPE equipment. Another possibility is the use of small 'micro' base stations that operate at a lower power and function within the retailer's premise. A micro base station could also use an unlicensed spectrum band.
Connected to the network are the servers and databases used by the credit card companies. Also connected to the network are other databases that such as ERP
systems, customer loyalty databases, etc.
Communication between the PoS terminal and the base station used a packet-based protocol (such as TCP/IP) with additional QoS features. The wireless version of the PoS
terminal uses CDMA technology over the air interface. The SOMA PoS terminal maintains a connection at all times, so the transaction delay disappears. The SOMA PoS
terminal is capable of speeds much greater that 14.4 Kbits/s in a conventional PoS termainl. QoS
capabilities further ensure prompt seance.
The POS terminal is a combines an always-on high-speed modem (typically wireless) with a standard processor and operating system. Additionally, the terminal contains various interfaces to connect with telephones, computer LANs, and other devices. The PoS terminal is customized with the addition of card-swipe and smart-card readers and a cash-register interface, and perhaps with other hardware such as a camera, display monitor, fingerprint scanner, speaker phone or built-in telephone handset.
The standard PoS terminal is capable of telephony functions, such as a connecting a call between a sales representative in a store and a credit card representative in a call-center. Other variants of the PoS terminal, designed for a lower cost, are data-only terminals. PoS terminals can be designed with other criteria in mind such as compactness and portability.
On top of its operating system, the PoS terminal operates a filter-runtime-environment

-3-(FRE). The FRE is an execution environment specifically designed to run filter plug-ins. Filter plug-ins are loaded into the network dynamically, on demand, as part of the transaction process.
Dynamically loaded filter plug-ins can perform their particular, specialized function on the data stream. For example, filters can specialize in voice coding, encryption, logging, filtering, mixing, IP traffic shaping, IP traffic policing, or IP content filtering. Single terminals can be dynamically configured based on user, content type, party called, and so on-on a transaction by transaction basis.
Additionally, the software running on both the base station and the PoS
terminal contains a number of software 'agents', which negotiate for resources from other devices and define the rules of the transaction. In a negotiation, user agents represent the subscribers on the system, and the service provider agent represents the telecommunications service provider.
Agents negotiate service parameters for each call during the transaction setup process. For example, user agents negotiate security, billing processes and payment for services. Agents used in monetary transactions are described further below.
All telephony, data-handling (such as HTTP) and financial services are all handled through software applications. Software features can be customized for each particular PoS
terminal.
The software architecture is distributed so that.agents can operate on different components of the network such as the base stations or the terminals, wherever computational resources are available.
SOMA's existing telephony software customizes behavior in transactions as a function of:
~ who the current client is ~ who owns the PoS terminal ~' which credit card company is being used ~ what product is being purchased Software agents negotiate on behalf of their customer and can dictate customized rules and behavior. For a monetary transaction, there are:
~ Client agents for the credit/debit card holder ~ Retail agents for the merchant

-4-~ Creditor Agents, on behalf of the credit-card company ~ Merchandise Agents, on behalf of the company who manufactured the item or provides the service being purchased Interactions between these user and terminal features will occur, for example with extended credit limits and when a loyalty-card function applies a discount which may in turn affect authorization.
Agent behaviors are expressed, in the SOMA system, in Java code. This provides a secure, flexible, and powerful approach. Feature interaction is a subtle problem in telephony, and design of an architecture able to handle it will need the skills and software architecture we've developed for the telephony problem. The Java agents come, in our system, from an LDAP
database. Some components of them can be generic and some can be custom ("holder known to be violent; process as if normal and silently advise police"). Credit card issuers or the like could administer this database exclusively or could allow large merchants to administer the portion of the database that expressed their own "terminal" behavior. Legacy behavior for other issuers is similarly expressed by these agents.
Customers would likely set their own client agent preferences from a web-page hosted by the credit-card company.
As the software architecture is distributed, the software agents are independent of any particular server or location. For example, client agents could be located at the credit card company's central server. However, during a period of heavy network traffic, the client agent could be pushed to the base station, or even the PoS terminal.
Client Agents represent the customized rules and behaviors of the credit/debit card user.
The client agent is accessed upon swiping the user's credit card and transmitting the card number to the credit card company.
Possible features that users can customize their card for include:
~ self-determined credit limits (within the restrictions set by the credit card company) ~ privacy preferences allowing the user to automatically opt in or out of providing personal information to the retailer.
~ payments of small percentages to specified charities or for air miles etc.
~ scalable security requirements depending on the amount of purchase, such as

-5-requirement of a PIN or other special method of authentication (electronic capture of signature, thumbprint, handprint, voiceprint, retinal scan, etc.) ~ availability and rapid download of client photographs for authentication, ~ multiple users for the same card, each with different levels of access, such as allowing the user's children to use the card but require parental authorization over the phone ~ restrictions on where the card can be used (the card owner can create a list of retailers authorized to use the card) ~ initiation and upload of a security-camera portrait on suspected fraudulent use ~ administration of purchase expenses by category (personal/business, travel, entertainment, etc.) with generation and e-mail of files in a preferred format ~ e-mail or Web-based detailed invoices and credit-card receipts, including authentication data ~ expression of prices in a home currency, Credit card agencies will be able to develop custom options for their clients using SOMA-provided APIs.
Retailer agents represent the customized rules and behaviors of the retailer.
The retailer agent typically resides within the PoS terminal, and is automatically accessed at the beginning of the transaction.
Possible features of the retailer agent include:
~ update and query of ERP databases including customer information ~ automated reconciliation of credit card issuer or the like/bank and retailer accounts ~ similarly update and query for loyalty-card databases ~ display of script cues for the retailer ("Congratulations! It's your hundredth purchase from us, and it's free!").
~ telephone service at the checkout counter, with custom dialing features (local only, headquarters only, intercom modes, call-in restricted to supervisor, etc.) ~ monitoring of individual teller throughput or behavior (if a microphone or telephone handset is built in to the PoS device, for example)

-6-~ extended credit limits for loyalty members, perhaps in financial partnership with credit card issuers or the like.
~ customized security levels, based upon the amount of purchase, individual customer history, and card type. For example, gold-card users would automatically be approved of all transactions less than $1000.
~ the ability to store and then process a number of transactions all at once.
Such a service would be valuable when dealing with high volumes of customers and a low risk of declined cards. An example of this would be a concession stand at a sports stadium.
Retailers, in conjunction with the the credit card agencies will be able to develop custom rules and options for their clients using SOMA-provided APIs.
Creditor agents represent the customized rules and behaviors of the credit/debit card company. These agents could reside at the credit card company's central server, but could be pushed out to the base station or the PoS terminal.
Possible features of the creditor agents include:
~ automated reconciliation of credit card issuer or the like/bank and retailer accounts ~ similarly update and query for loyalty-card databases ~ Customized security levels, based upon the amount of purchase, individual customer history, geographical location and card type. For example, a store in an area known for a high level of fraudulent activity could use a higher level of security than one in an area with lower levels of fraud. Another example would be a request to authorize a $1000 purchase in made from a Paris shop for a North American customer without a history of traveling to Europe. Based upon these circumstances, the credit card company requires a higher level of security to authorize the transaction.
In developing and administering this database credit card issuers or the like would extend its brand to define "the behavior of money". Credit card agencies will be able to develop their own rules and options for their clients using SOMA-provided APIs Merchandise agents represent the customized rules and behaviors of the company which produces the product or service being purchased.. These agents could reside at the credit card company's central server, the base station, the PoS terminal, or a central server owned by the _7_ manufacturer.
Possible features of the merchandise agents include:
~ Provide instant customer rebates ~ Extended warranties for the purchaser when using the credit card ~ Extra frequent flyer points, or the like Other special offers made in conjunction with the credit card company, retailer or customer (e.g., "Buy 2 XYZ products this month and get the third one at 50%
ofd') Manufactures, in conjunction with the retailer and credit card agency will be able to develop custom options for their clients using SOMA-provided APIs This invention conceives of security as a scalable model, with different levels determined by the customer, retailer and creditor. When these levels differ, generally, the most secure level will be chosen.
Agents can interact with one another, so that a transaction which involves multiple parties and rules can occur invisibly to the customer and the sales representative.
e.g., a customer goes into an electronics shop and purchases and purchase a video game console with a preferred credit card. Because the customer used the preferred credit card, he or she gets an instant discount in the price. The manufacturer of the console gives the retail shop a credit to reimburse it for the lower sale price.
It is contemplated that, leveraging the telephony capabilities of the SOMAport, the POS
terminal could provide a voice connection to be established between the POS
terminal and the Authorization center, rather than just refusing the transaction and asking that the merchant call (which they are often reluctant to do). With a built-in telephone handset or speaker phone, the authorization process can be expedited.
Since the POS terminal has enhanced communications and processing capabilities, it can provide other authentication means such as voice print, biometric, smart card and or web cam of the card holder It is contemplated that adding a LCD display and/or touchscreen: to enhance user allows the unit to display a picture of the credit card user - instantly downloading a picture for visual recognition. Additionally, if connected to a web camera, the unit could upload pictures of the customer to a central registry allowing the credit card company to interface;
to allow videophone calls; to allow "visual call display" (i.e. - show a picture of mom when she calls); to act as a Smart Photo Frame (i.e. - display various family photos, etc. when the terminal is not in use;
provide integrated web browsing; allow video on demand downloads (or push video advertisements down) It is contemplated that the POS Terminals, not requiring a line connection, could be deployed anywhere in the store. Configuring the POS Terminals could be as simple as turning the device on. Automatic provisioning capabilities of the SOMA Netport is described in CDN
patent application 2,346,158.
It is contemplated that the portability and rapid deployment of the PoS
terminal provides for new possibilities. PoS terminals could be moved throughout the store to take advantage of sales in particular departments. During peak sales seasons such as Christmas, the store could deploy additional units. The rapid deployment of the device would make the terminals suitable for being rented by the service provider, so that the store would not have to own excess units.
Such units would also be of use for special events such as outdoor concerts.
It is further contemplated that utilizing the distributed capabilities of the operating system, credit card validations could be pushed to the 'edges' of the network.
Rather than relying upon a central authorization services, customer information could be cached at the base stations.
This way, if the network was congested or unavailable, then the decision to approve or decline customers can be made automatically.
Even if the link between the PoS terminal and the base station failed, authentication rules could be available in the PoS terminal, so that transactions could still occur. The PoS terminal would store the transaction records until the link was restored.
It is further contemplated that, with a bar-code reader attached to the unit and a monitor/touchscreen attached, the PoS terminal could serve as a self-serve kiosk. Leveraging the broadband capabilities of the terminal, the unit could access HTML pages such as a catalog or schedule information.
Alternatively, the PoS terminal could be connected/installed in a vending machine. For example, a PoS terminal in a commuter train station could sell individual tickets and monthly passes. The network connectivity allows the screen to display up-to-date schedule information, so that the commuters could order specific tickets.

A PoS terminal could be connected to a newspaper vending machine. The price changes according to the time of day, so that the paper is $1 in the morning, $0.50 in the afternoon, and free after 7:00. Dynamic pricing is useful for a wide range of time-sensitive products such as airline and concert tickets. Since the PoS terminal is remotely linked to a central server, then prices could be adjusted at the vendor's discretion.
It is further contemplated that the capabilities of a PoS terminal could be built into a terminal present at the customer's residence. The home terminal is operable to be connected to the customer's telephone and/or computer. The home terminal would include an authentication mechanism such as a card swipe reader. Another security feature would be an LCD screen on the home terminal that would show the identity of the retailer and the actual amount being purchased. Additional security measures such as PIN numbers or passwords are also possible.
In order to make a purchase, the customer would shop either online or by telephone..The retailer and the purchase amount would be displayed on the LCD screen of the home terminal.
When the customer is ready to complete the transaction, the customer engages the authentication mechanism (such as swiping the card in the card reader). The authentication mechanism gathers the security information stored on the card (either in the magnetic stripe or in a chip on a 'smart' card) and transmits the authentication information across an encrypted secure channel to the retailer. Alternatively, the authentication information is transmitted directly to the credit card agency, which then issues an approval notice to the retailer.
For example, a client goes to a portal website hosted by the credit card agency. From the portal site, the client can then travel to different e-commerce web sites displayed within a sub-window generated by the portal site. The client browses and shops online normally in the sub-window. However, when the transaction occurs, the credit card website 'intercepts' the credit card number and transmits only a one-time use number to the retailer's web page in the sub-window. The retailer never sees the customer's real credit card number.
The examples given here all assume credit card use. However, other monetary transaction methods are available the invention, such as debit cards, cash cards, micropayment schemes, virtual currencies (such as PayPal), etc.
The above-described embodiments of the invention are intended to be examples of the present invention and alterations and modifications may be effected thereto, by those of skill in -1~-the art, without departing from the scope of the invention which is defined solely by the claims appended hereto.

Claims