Sélection de la langue

Search

Sommaire du brevet 2356716 

Énoncé de désistement de responsabilité concernant l'information provenant de tiers

Une partie des informations de ce site Web a été fournie par des sources externes. Le gouvernement du Canada n'assume aucune responsabilité concernant la précision, l'actualité ou la fiabilité des informations fournies par les sources externes. Les utilisateurs qui désirent employer cette information devraient consulter directement la source des informations. Le contenu fourni par les sources externes n'est pas assujetti aux exigences sur les langues officielles, la protection des renseignements personnels et l'accessibilité.

Disponibilité de l'Abrégé et des Revendications

L'apparition de différences dans le texte et l'image des Revendications et de l'Abrégé dépend du moment auquel le document est publié. Les textes des Revendications et de l'Abrégé sont affichés :

  • lorsque la demande peut être examinée par le public;
  • lorsque le brevet est émis (délivrance).
(12) Demande de brevet: (11) CA 2356716
(54) Titre français: TERMINAL DE POINT DE VENTE
(54) Titre anglais: POINT OF SALE TERMINAL
Statut: Réputée abandonnée et au-delà du délai pour le rétablissement - en attente de la réponse à l’avis de communication rejetée
Données bibliographiques
(51) Classification internationale des brevets (CIB):
  • G07G 01/14 (2006.01)
  • G06Q 20/20 (2012.01)
(72) Inventeurs :
  • SNELGROVE, WILLIAM MARTIN (Canada)
  • STUMM, MICHAEL (Canada)
  • LONG, EVERITT (Canada)
(73) Titulaires :
  • SOMA NETWORKS, INC.
(71) Demandeurs :
  • SOMA NETWORKS, INC. (Etats-Unis d'Amérique)
(74) Agent:
(74) Co-agent:
(45) Délivré:
(22) Date de dépôt: 2001-09-05
(41) Mise à la disponibilité du public: 2003-03-05
Licence disponible: S.O.
Cédé au domaine public: S.O.
(25) Langue des documents déposés: Anglais

Traité de coopération en matière de brevets (PCT): Non

(30) Données de priorité de la demande: S.O.

Abrégés

Abrégé anglais


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.

Revendications

Note : Les revendications sont présentées dans la langue officielle dans laquelle elles ont été soumises.

Désolé, les revendications concernant le document de brevet no 2356716 sont introuvables.
Les textes ne sont pas disponibles pour tous les documents de brevet. L'étendue des dates couvertes est disponible sur la section Actualité de l'information .

Description

Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.


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.

Dessin représentatif
Une figure unique qui représente un dessin illustrant l'invention.
États administratifs

2024-08-01 : Dans le cadre de la transition vers les Brevets de nouvelle génération (BNG), la base de données sur les brevets canadiens (BDBC) contient désormais un Historique d'événement plus détaillé, qui reproduit le Journal des événements de notre nouvelle solution interne.

Veuillez noter que les événements débutant par « Inactive : » se réfèrent à des événements qui ne sont plus utilisés dans notre nouvelle solution interne.

Pour une meilleure compréhension de l'état de la demande ou brevet qui figure sur cette page, la rubrique Mise en garde , et les descriptions de Brevet , Historique d'événement , Taxes périodiques et Historique des paiements devraient être consultées.

Historique d'événement

Description Date
Inactive : CIB désactivée 2012-01-07
Inactive : CIB du SCB 2012-01-01
Inactive : CIB expirée 2012-01-01
Inactive : CIB enlevée 2011-09-29
Exigences relatives à la révocation de la nomination d'un agent - jugée conforme 2009-12-08
Inactive : Lettre officielle 2009-12-08
Inactive : Lettre officielle 2009-11-30
Inactive : Lettre officielle 2009-11-30
Demande visant la révocation de la nomination d'un agent 2009-11-02
Inactive : CIB expirée 2009-01-01
Inactive : CIB expirée 2009-01-01
Inactive : CIB enlevée 2008-12-31
Inactive : CIB enlevée 2008-12-31
Inactive : CIB de MCD 2006-03-12
Inactive : CIB de MCD 2006-03-12
Demande visant la révocation de la nomination d'un agent 2004-06-18
Demande non rétablie avant l'échéance 2004-04-28
Inactive : Morte - Demande incomplète 2004-04-28
Exigences relatives à la révocation de la nomination d'un agent - jugée conforme 2004-03-23
Inactive : Lettre officielle 2004-03-23
Inactive : Lettre officielle 2004-03-19
Demande visant la révocation de la nomination d'un agent 2004-02-17
Réputée abandonnée - omission de répondre à un avis sur les taxes pour le maintien en état 2003-09-05
Inactive : Lettre officielle 2003-07-10
Lettre envoyée 2003-07-10
Réputée abandonnée - omission de répondre à un avis exigeant une traduction 2003-04-28
Inactive : Incomplète 2003-04-28
Inactive : Lettre officielle 2003-03-26
Inactive : Lettre officielle 2003-03-26
Demande publiée (accessible au public) 2003-03-05
Inactive : Page couverture publiée 2003-03-04
Inactive : Incomplète 2003-01-28
Lettre envoyée 2002-04-09
Inactive : Correspondance - Formalités 2002-02-26
Inactive : Transfert individuel 2002-02-26
Inactive : Lettre officielle 2002-01-29
Inactive : Transfert individuel 2001-12-17
Inactive : CIB attribuée 2001-11-09
Inactive : CIB en 1re position 2001-11-09
Inactive : CIB attribuée 2001-11-09
Demande visant la révocation de la nomination d'un agent 2001-10-26
Inactive : Certificat de dépôt - Sans RE (Anglais) 2001-09-25
Demande reçue - nationale ordinaire 2001-09-19

Historique d'abandonnement

Date d'abandonnement Raison Date de rétablissement
2003-09-05
2003-04-28

Historique des taxes

Type de taxes Anniversaire Échéance Date payée
Taxe pour le dépôt - générale 2001-09-05
Enregistrement d'un document 2001-12-17
Enregistrement d'un document 2003-02-11
Titulaires au dossier

Les titulaires actuels et antérieures au dossier sont affichés en ordre alphabétique.

Titulaires actuels au dossier
SOMA NETWORKS, INC.
Titulaires antérieures au dossier
EVERITT LONG
MICHAEL STUMM
WILLIAM MARTIN SNELGROVE
Les propriétaires antérieurs qui ne figurent pas dans la liste des « Propriétaires au dossier » apparaîtront dans d'autres documents au dossier.
Documents

Pour visionner les fichiers sélectionnés, entrer le code reCAPTCHA :



Pour visualiser une image, cliquer sur un lien dans la colonne description du document. Pour télécharger l'image (les images), cliquer l'une ou plusieurs cases à cocher dans la première colonne et ensuite cliquer sur le bouton "Télécharger sélection en format PDF (archive Zip)" ou le bouton "Télécharger sélection (en un fichier PDF fusionné)".

Liste des documents de brevet publiés et non publiés sur la BDBC .

Si vous avez des difficultés à accéder au contenu, veuillez communiquer avec le Centre de services à la clientèle au 1-866-997-1936, ou envoyer un courriel au Centre de service à la clientèle de l'OPIC.


Description du
Document 
Date
(aaaa-mm-jj) 
Nombre de pages   Taille de l'image (Ko) 
Dessins 2003-03-04 1 12
Dessin représentatif 2002-03-10 1 7
Abrégé 2001-09-04 1 7
Revendications 2001-09-04 1 12
Description 2001-09-04 10 461
Certificat de dépôt (anglais) 2001-09-24 1 175
Courtoisie - Certificat d'enregistrement (document(s) connexe(s)) 2002-04-08 1 113
Rappel de taxe de maintien due 2003-05-05 1 107
Courtoisie - Lettre d'abandon (incompléte) 2003-05-19 1 167
Courtoisie - Lettre d'abandon (taxe de maintien en état) 2003-11-02 1 176
Correspondance 2001-09-27 1 14
Correspondance 2001-10-25 4 130
Correspondance 2002-01-28 1 16
Correspondance 2002-02-25 7 181
Correspondance 2002-11-28 1 19
Correspondance 2003-03-25 1 11
Correspondance 2003-03-25 1 11
Correspondance 2003-07-09 1 9
Correspondance 2004-02-16 6 173
Correspondance 2004-03-18 1 13
Correspondance 2004-03-22 1 19
Correspondance 2004-06-17 4 119
Correspondance 2009-11-01 4 405
Correspondance 2009-11-29 1 15
Correspondance 2009-12-07 1 20
Correspondance 2010-02-09 4 111