Language selection

Search

Patent 2356716 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent Application: (11) CA 2356716
(54) English Title: POINT OF SALE TERMINAL
(54) French Title: TERMINAL DE POINT DE VENTE
Status: Deemed Abandoned and Beyond the Period of Reinstatement - Pending Response to Notice of Disregarded Communication
Bibliographic Data
(51) International Patent Classification (IPC):
  • G07G 01/14 (2006.01)
  • G06Q 20/20 (2012.01)
(72) Inventors :
  • SNELGROVE, WILLIAM MARTIN (Canada)
  • STUMM, MICHAEL (Canada)
  • LONG, EVERITT (Canada)
(73) Owners :
  • SOMA NETWORKS, INC.
(71) Applicants :
  • SOMA NETWORKS, INC. (United States of America)
(74) Agent:
(74) Associate agent:
(45) Issued:
(22) Filed Date: 2001-09-05
(41) Open to Public Inspection: 2003-03-05
Availability of licence: N/A
Dedicated to the Public: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): No

(30) Application Priority Data: None

Abstracts

English 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.


Claims

Note: Claims are shown in the official language in which they were submitted.

Sorry, the claims for patent document number 2356716 were not found.
Text is not available for all patent documents. The current dates of coverage are on the Currency of Information  page

Description

Note: Descriptions are shown in the official language in which they were submitted.


CA 02356716 2001-09-05
-1-
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

CA 02356716 2001-09-05
-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

CA 02356716 2001-09-05
-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

CA 02356716 2001-09-05
-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

CA 02356716 2001-09-05
-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)

CA 02356716 2001-09-05
-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

CA 02356716 2001-09-05
_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

CA 02356716 2001-09-05
-8-
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.

CA 02356716 2001-09-05
-9-
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

CA 02356716 2001-09-05
-1~-
the art, without departing from the scope of the invention which is defined
solely by the claims
appended hereto.

Representative Drawing
A single figure which represents the drawing illustrating the invention.
Administrative Status

2024-08-01:As part of the Next Generation Patents (NGP) transition, the Canadian Patents Database (CPD) now contains a more detailed Event History, which replicates the Event Log of our new back-office solution.

Please note that "Inactive:" events refers to events no longer in use in our new back-office solution.

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Event History , Maintenance Fee  and Payment History  should be consulted.

Event History

Description Date
Inactive: IPC deactivated 2012-01-07
Inactive: IPC from PCS 2012-01-01
Inactive: IPC expired 2012-01-01
Inactive: IPC removed 2011-09-29
Revocation of Agent Requirements Determined Compliant 2009-12-08
Inactive: Office letter 2009-12-08
Inactive: Office letter 2009-11-30
Inactive: Office letter 2009-11-30
Revocation of Agent Request 2009-11-02
Inactive: IPC expired 2009-01-01
Inactive: IPC expired 2009-01-01
Inactive: IPC removed 2008-12-31
Inactive: IPC removed 2008-12-31
Inactive: IPC from MCD 2006-03-12
Inactive: IPC from MCD 2006-03-12
Revocation of Agent Request 2004-06-18
Application Not Reinstated by Deadline 2004-04-28
Inactive: Dead - Application incomplete 2004-04-28
Revocation of Agent Requirements Determined Compliant 2004-03-23
Inactive: Office letter 2004-03-23
Inactive: Office letter 2004-03-19
Revocation of Agent Request 2004-02-17
Deemed Abandoned - Failure to Respond to Maintenance Fee Notice 2003-09-05
Inactive: Office letter 2003-07-10
Letter Sent 2003-07-10
Deemed Abandoned - Failure to Respond to Notice Requiring a Translation 2003-04-28
Inactive: Incomplete 2003-04-28
Inactive: Office letter 2003-03-26
Inactive: Office letter 2003-03-26
Application Published (Open to Public Inspection) 2003-03-05
Inactive: Cover page published 2003-03-04
Inactive: Incomplete 2003-01-28
Letter Sent 2002-04-09
Inactive: Correspondence - Formalities 2002-02-26
Inactive: Single transfer 2002-02-26
Inactive: Office letter 2002-01-29
Inactive: Single transfer 2001-12-17
Inactive: IPC assigned 2001-11-09
Inactive: First IPC assigned 2001-11-09
Inactive: IPC assigned 2001-11-09
Revocation of Agent Request 2001-10-26
Inactive: Filing certificate - No RFE (English) 2001-09-25
Application Received - Regular National 2001-09-19

Abandonment History

Abandonment Date Reason Reinstatement Date
2003-09-05
2003-04-28

Fee History

Fee Type Anniversary Year Due Date Paid Date
Application fee - standard 2001-09-05
Registration of a document 2001-12-17
Registration of a document 2003-02-11
Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
SOMA NETWORKS, INC.
Past Owners on Record
EVERITT LONG
MICHAEL STUMM
WILLIAM MARTIN SNELGROVE
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Drawings 2003-03-04 1 12
Representative drawing 2002-03-10 1 7
Abstract 2001-09-04 1 7
Claims 2001-09-04 1 12
Description 2001-09-04 10 461
Filing Certificate (English) 2001-09-24 1 175
Courtesy - Certificate of registration (related document(s)) 2002-04-08 1 113
Reminder of maintenance fee due 2003-05-05 1 107
Courtesy - Abandonment Letter (incomplete) 2003-05-19 1 167
Courtesy - Abandonment Letter (Maintenance Fee) 2003-11-02 1 176
Correspondence 2001-09-27 1 14
Correspondence 2001-10-25 4 130
Correspondence 2002-01-28 1 16
Correspondence 2002-02-25 7 181
Correspondence 2002-11-28 1 19
Correspondence 2003-03-25 1 11
Correspondence 2003-03-25 1 11
Correspondence 2003-07-09 1 9
Correspondence 2004-02-16 6 173
Correspondence 2004-03-18 1 13
Correspondence 2004-03-22 1 19
Correspondence 2004-06-17 4 119
Correspondence 2009-11-01 4 405
Correspondence 2009-11-29 1 15
Correspondence 2009-12-07 1 20
Correspondence 2010-02-09 4 111