Note: Descriptions are shown in the official language in which they were submitted.
CA 02781648 2012-06-28
SCALABLE AND TIMELY NETWORK INTERMEDIARY
FOR TIME OR QUANTITY LIMITED GOODS AND SERVICES
FIELD OF THE INVENTION
The invention is in the field of intermediary network applications and, more
particularly,
pertains to an intermediary for facilitating the making of offerings by
providers of goods
and services to their target customers through a computer communications
network.
BACKGROUND
Advertising has connected producers of goods and services with consumers by
way of
general broadcasting to all who were in reach of its medium: whether by a
poster on the
pole in the town square, an advertisement in a newspaper or magazine, a radio
or
television's advertisement. More recently knowledge of consumers' buying
patterns or
Internet browsing choices have allowed companies like Amazon and Google to
present
advertisements to potential customer's based on what they think, based on
knowledge
of the customer's preferences or habits, that customer might more likely be
interested
in.
A customer can sign up for a service or group and specify that he is only
interested in
notifications of a certain type. For example, one could join Oracle's Tech
Network and
specify an interest in database products only and not other products like web
http
servers. Or, a customer could use key words in a search engine to look for
products of
a certain type. The results he gets will likely still need to be filtered
manually for material
that have no relevance to his product or service search.
There have been magazines like Consumer Reports that have tried to make the
customer's job easier by amassing information about products and comparing
their
quality and price. More recently, with the growth of the Internet there have
websites
that have gathered information about comparative products using search engine
techniques and web crawlers.
1
CA 02781648 2012-06-28
When customers consider goods and/or services offered by a company they may
have
a desire to compare different options available from other companies. Amazon
advertises books both new and used from other companies and facilitates buying
from
The introduction of geographic information on stationary computers or mobile
devices
opens up additional possibilities. A customer might use a mobile phone to find
all the
brick and masonry retailers in a city. The customer could then check the
various
Currently retail e-commerce involves making an online purchase from a web site
and
ordering items that need to be shipped to the customer, often from a distance
city. So-
25 customer.
When a customer orders online today and there is not enough in stock to
satisfy the
order the order is backordered. The brick and mortar customer is less amenable
to
waiting for a similar arrangement. Today if the customer was willing to wait
for an order
2
CA 02781648 2012-06-28
brick and mortal retailers online for available goods. To satisfy the customer
the retailer
needs to reliably report the availability of goods for sale. A customer will
be dissatisfied
and probably won't order online again if after travelling to the retail shop
what was
reserved and bought is not there.
In addition to quality limitations a customer might wish to have retailer
information on
the basis of time limitations. Reservations at restaurants are time oriented.
On a given
day a restauranteur might find, by late afternoon, that the number of table
reservations
remaining for that evening are very low. As a result, the restaurateur might
want to offer
a last minute discount to potential customers if they purchase dinner that
evening.
Potential customers might use a stationary computer or mobile phone to
remotely
search on-line for restaurants in the vicinity that offer discounts for use
that evening. An
intermediary acting between the city restaurateurs and potential customers
might
provide to those potential customers information about the offerings of those
city
restaurants but to do so according this example, the intermediary would have
to keep
up to the minute information on availability of dinner reservation slots.
Otherwise, a bus
of tourists could appear at the restaurant's door while remote customers make
a dinner
reservation online.
However, trying to satisfy the need for accurate up to the moment information
on the
availability of goods and services brings technical challenges. The
conventional design
approach would be similar to Amazon's approach whereby information about
offerings
is amassed from various companies in its database. But amassing relevant
offering
information from, say, tens of thousands of restaurants in one or more areas
(e.g.
countries) and keeping volatile availability status information current is
problematic
when using a fully centralized approach. The cost of centralized data pose
less of
problem as storage costs reduce over time but a problem in scalability is
created by
particularly volatile (i.e. frequently changing) information such as quantity
available
information.
3
CA 02781648 2012-06-28
As an example, a mother and her daughter are checking their !Phone as they
walk
through a large mall trying to buy shoes for the daughter in her size and at a
desired
price. An intermediary e-commerce system serving them will wish to keep up to
the
moment information on products, price and quantity for several large retailers
in the mall
as well as many smaller boutiques. Taking an approach of trying to centralize
this
information in a database with up-to-the-moment availability information would
be
problematic from a technical standpoint and costly. However, in the absence of
such
timely information, the mother and her daughter may rely on retailer product
information
provided by the intermediary, walk to the end of the mall to that retailer's
store and then
find that, in fact, the product that they thought they had reserved or agreed
to buy has
already been purchased by a walk-in customer.
The present invention addresses these problems of timeliness and scalability
in such
intermediary e-commerce systems (alternately referred to herein as
intermediary sales
systems).
Current computer facilitated customer and merchant exchanges include Business-
to-
Business (B2B) where businesses trade with trusted partners, ecommerce
Business-to-
Consumer (B2C) websites where customers browse web pages and select items and
make purchases with security enhanced by such technologies as SSL with HTTPS,
and
web sites like eBay with what one may call untrusted merchants trading with
end
customers with credit cards or PayPal accounts.
B2B systems require high levels of trust and established relationships and do
not
provide a service which can quickly adapt to new ad hoc customer merchant
relationships.
B2C ecommerce sites can merchandise products and services and can establish
new
customer relationships in a quick ad hoc manner but the offerings usually come
from
one company or a limited number of companies. While adding new customers is
easy,
adding new merchants is more problematic. A business website can offer the
products
4
CA 02781648 2012-06-28
of other companies just as Amazon offers books from other book sellers. Or, a
business
can accumulate price and product information on a number of businesses either
through
techniques of web crawling or explicit agreements to carry the products of
those
businesses. However, keeping price and product information current and
synchronized
with the databases of the offering businesses is costly, computer time
consuming, and
not scalable to large numbers of businesses.
Patent application no. US 2008/0033862 of Ehsani entitled Business Method for
Last
Minute Sales uses the approach of amassing product detail and price
information in a
database. Amazon, for example, also stores product details and price
information from
other merchants in a centralized system. Also using a centralized database
approach is
patent no. 7657463 entitled Systems and methods for delivering item price
notifications
to a mobile device.
In the current B2C model a customer makes a query on a search engine like
Google or
Yahoo. The results have to be sifted through manually before the customer can
find
products of interest and the process is hit or miss. Further, the customer can
construct
a search through a search engine using various terms that may not be the terms
used
= by a provider, for example, a customer might specify "trousers" and the
provider "pants".
Today there are many offerings to customers of coupons and discounts. These
coupons
typically have a life span of at least several months. From the merchant's
point of view
this might not be optimum. A restaurant, for example, might have changing
customer
demand levels that are difficult to determine months in advance. Coupons
issued with a
life span of months might bring in customers at a lower profit during summer
months
when tourists would pay the full price. Equally, an occurrence of bad weather
might
keep customers away and be a good time to offer discounts. To account for such
changing demand levels, a just-in-time coupon and discount system is desirable
whereby a restaurateur is able control availability of offerings from moment
to moment.
5
CA 02781648 2012-06-28
Various systems of cataloguing and taxonomy are known for use in unrelated
applications involving data management. Examples include the Dewey Decimal
System
for libraries and distributed computer catalogue systems such as X.500
Directory
Services and Microsoft's Active Directory. While web sites use cataloguing and
taxonomy to list product offerings on their HTML pages (for example, Sears may
present a high level menu having appliances, jewelry, cosmetics, etc.)
cataloguing and
taxonomy are not being used to restrict and define searches across companies
offering
products and services.
One of the computer software techniques used today to transfer and update
information
between computing/telecommunication devices such as mobile phones, tablets and
computers operating over the Internet is that of the standardized open Web
services
(see www.w3.org of the World Wide Web Consortium (W3C)). These services
transfer
data in human readable form using Extensible Markup Language (XML) over
Hypertext
Transfer Protocol (HTTP) and perhaps Simple Object Access Protocol (SOAP). The
standardized Web services allows easier connection of dissimilar computer
systems
than its precursors. Today Web services include Representational State
Transfer
(REST) which runs over HTTP or Hypertext Transfer Protocol Secure (HTTPS), or
as
services defined using Web Services Description Language (WSDL) and running
over
SOAP which runs over HTTP/HTTPS. REST is more lightweight, so it is preferable
for
a mobile device.
The interaction over a web service is client-server. Almost exclusively today,
in an
implementation of a web service on a mobile device, the mobile device has the
role of
the client and role of the server is provided by a remote computer/server. A
contrary
example for which the server role is applied to mobile devices is the Mongoose
web
server (see http://code.google.com/p/mongoose/) implemented on !Phone and
Android
mobile devices for REST web services (see http://myutil.com/2009/6/15/simple-
way-to-
embed-a-http-server-into-your-iphone-app).
6
CA 02781648 2012-06-28
Distributing data and processing over a network creates a problem of how to
notify a
central server/manager of changes occurring in other nodes (e.g. a merchant)
of the
network. One method is to have the manager poll the various network nodes
periodically, but this is time consuming and uses up network bandwidth.
Another
method is to have the remote nodes send notifications to the central server
when their
state has changed. This is more efficient than polling but requires more
intelligence on
the remote nodes. A third method, more efficient than notifications in this
context, and
also requiring more intelligence on the remote node, is to locate a web
services server
there and just contact it as updates are needed. This method is not suitable
for an
application requiring immediate notification of changes as they occur, such as
for
notifications of alarms occurring at the remote node, but where suitably used
can
provide better performance than either of the polling and notification
methods.
SUMMARY OF THE INVENTION
The invention provides a method and intermediary system for facilitating
provision of
offerings associated with goods and/or services by offering entities to target
entities
through a computer communications network. An intermediary computer program
component is executed by a central computer in the network, an offering entity
computer program component is executed by an offering entity computer in the
network
and used by the offering entity, and a target entity computer program
component is
executed by a target entity computer in the network and used by the target
entity. The
intermediary computer program component, the offering entity computer program
component and the target entity computer program component are configured for
using
a shared predetermined goods and/or services taxonomy comprising a multi-level
structure of interconnecting nodes wherein a node in an upper level can be
connected
with one or more nodes of a lower level. The intermediary computer program
component configured for accessing a central datastore comprising offering
information
and node information for each of a plurality of offerings of an offering
entity.
7
CA 02781648 2012-06-28
The offering entity computer program component is configured for: obtaining
offering
information and associated node information for an offering of the offering
entity; storing
the offering information and associated node information in a datastore
accessible to
the offering entity computer program component; obtaining and storing in the
datastore
accessible to the offering entity computer program component updated offering
information for an offering associated with node information, the updated
offering
information comprising availability status for the offering; sending the
offering
information and associated node information for storage in the central
datastore; and, in
response to a notification of a reservation request for a selected offering,
notifying the
intermediary computer program component if the selected offering is not
available
based on an availability status of the offering information for the selected
offering stored
on the datastore accessible to the offering entity computer program component
and
reserving the selected offering if it is available. The reservation may, for
example, be a
purchase and the offering, intermediary and target computer program components
may
be configured for completing a purchase by a target entity of a selected
offering from
the offering entity. Optionally, the offering entity computer program
component may be
configured for retaining an external service for completing a reservation of
an offering
for which a reservation request has been received from the target entity
computer
program component.
The intermediary computer program component is configured for: receiving
offering
information and associated node information for an offering of the offering
entity;
storing in the central datastore the received offering information and
associated node
information; receiving from the target entity computer program component node
information selected by the target entity; searching the central datastore for
offering
information associated with the node information selected by the target entity
to locate
one or more matching offerings; sending to the target entity computer program
component offering information for one or more matching offerings; in response
to
receiving from the target entity computer program component a reservation
request for
a selected offering, notifying the offering entity computer program component
of the
reservation request for the selected offering; and, in response to receiving
notification
8
CA 02781648 2012-06-28
from the offering entity computer program component that the selected offering
is not
available, notifying the target entity computer program component that the
selected
offering is not available.
The target entity computer program component is configured for: sending to the
intermediary computer program component the node information selected by the
target
entity; receiving from the intermediary computer program component the
offering
information for one or more matching offerings; and, sending to the
intermediary
computer program component a request for reservation of a matching offering
selected
by the target entity.
The offering information for offerings in the central datastore may be
synchronized with
corresponding offering information for those offerings in the datastore
accessible to the
offering entity computer program component. Preferably, the reservation
request
received from the target entity computer program component comprises a
quantity
requested by the target entity for the selected offering; and, the
availability status of the
offering information for the selected offering stored on the datastore
accessible to the
offering entity computer program component comprises quantity available
information
for the selected offering. The offering entity computer program component is
preferably
configured for reserving the selected offering if the availability status of
the offering
information for the selected offering indicates that the selected offering is
available.
The offering entity computer and target entity computer may be mobile
computing
devices such as smart phones, tablets, personal digital assistants (PDAs),
notebooks,
netbooks and laptops and/or a stationery computer. The central computer may be
a
virtualized or cloud server.
The shared predetermined goods and/or services taxonomy may be stored in the
intermediary datastore, with the intermediary computer program component
configured
to send the shared predetermined goods and/or services taxonomy to the
offering and
target computer program components.
9
CA 02781648 2012-06-28
User interfaces are provided for use by the offering entity to send and
receive
communications to and from the intermediary computer program component and for
use
by the target entity to send and receive communications to and from the
intermediary
computer program component.
The offering computer program component optionally comprises a radio-frequency
identification (RFID) module configured for operating in combination with a
radio-
frequency identification (RFID) system of the offering entity for identifying
goods of
offerings of the offering entity which have been reserved by target entities.
The
intermediary and target computer program components optionally comprise RFID
modules configured for passing to the offering entity computer program
component
RFID information identifying the target entity computer and operating with the
RFID
system of the offering entity to locate the target entity computer when it
comes within
the operable range of the RFID system. The RFID modules instruct the target
entity
computer program component how to locate goods of an offering of the offering
entity
which have been reserved by the target entity.
The present invention addresses problems of organizational complexity and poor
timeliness and scalability associated with the prior art. A more efficient
organization and
retrieval of goods and services of interest to the customer is facilitated
(and extraneous
material is kept out) by using a predetermined shared goods and services
taxonomy.
The shared taxonomy is used by offering entities to categorize their offerings
and by
target entities to search for offerings of a selected category.
Offering information is centralized in a central server but where this
includes volatile
information such as availability status information that is particularly
volatile (e.g. the
quantity that remains available), the most up to date volatile information to
be relied
upon is distributed amongst the offering entities by storing it with or under
the control of
the offering entity computer and the intermediary component confirms via that
up-to-
date availability status information that an offering for which a target
entity has
CA 02781648 2012-06-28
requested a reservation is still available, failing which the target entity is
notified that the
reservation request has been rejected. By distributing the particularly
volatile data the
data provided to the customer (target entity) is more accurate (up-to-date)
and related
scalability and maintenance cost problems are greatly reduced. Merchant
providers can
be added quickly to the system through online procedures. Merchant providers
can
populate a database on their mobile computing device or stationary computer,
or they
can integrate an existing database with the invention. Merchant providers
maintain
control over the availability of coupon and sale offerings, allowing them to
create and
discontinue them as desired, rather than be committed to accept all previously
issued
coupons having a pre-set period of validity which could be several months or
more.
The prior art need for a central server to be kept up-to-date on the state of
the remote
merchants' product and services availability can be avoided by providing a
merchant
web service on the merchant's mobile computer device or computer acting in a
server
role. This allows the intermediary central server to contact the merchant to
query for
offering availability in reserving/purchasing a product/service. Intermediary
and
merchant nodes interchange client-server roles. In this respect, this
interaction is
somewhat similar to peer-to-peer (P2P).
The present invention increases the adaptability of an intermediary system as
compared
with B2B systems for adding both customer and provider participants while
overcoming
scalability and accuracy problems of the B2C approach that are due to the
synchronization challenges of duplicating and amalgamating the data of many
businesses in a centralized database.
Untrusted vendors of goods or services can be accommodated by the intermediary
system for other than the actual sale transaction. For example, an individual
could
register an offering which advertises that their house is for sale and be
facilitated by the
intermediary system to target that offering to potential buyers. To go
further, however,
to facilitate an actual sale of an offering by an offering entity it must have
verifiable
11
CA 02781648 2012-06-28
credentials such as a merchant account with a credit card company and the
target entity
must have verifiable methods of payment like credit cards.
A preferred implementation uses REST web services over the Internet using the
HTTP
or HTTPS protocol. The merchant and intermediary roles act as both clients and
servers
at times in the client-server web services interaction while the customer role
acts only
as a client.
In B2B protocols like Rosetta Stone Partner Interface Processes (PIPs) each
PIP
specification includes a business document with an associated vocabulary, and
a
business process with the choreography of the message dialog (see: http://
www.rosettanet.orgiTheStandards/RosettaNetStandards/PIPs/tabid/475/Default.aspx
).
Such protocols define various standard document layouts using XML Schema or
Document Type Definitions (DTD) to mandate required fields and the meanings of
fields
in documents passed in a B2B exchange. In contrast the protocol of this
invention uses
a shared taxonomy classifying goods and services offered, queried, and
reserved or
purchased.
Customer and merchant components, in the form of computer-readable
instructions
(software) can be downloaded or otherwise obtained and installed on mobile
computing
devices or stationary computers. A merchant can use a datastore that is part
of the
merchant component or an exterior data repository system can be integrated to
provide
price, item details and availability information. The intermediary component
coordinates
the interaction between customer and merchant.
A customer issues a query for goods/services using geographic location data
combined
with offering classification descriptions selected from a screen displayed
based on a
taxonomy of metadata describing potential offerings. In response, the
intermediary
returns to the customer goods and services offerings satisfying the query.
12
CA 02781648 2012-06-28
Advantageously, retrieval of product/service offering detail data is achieved
on the basis
of cataloging. Decisions can be made at any time by the merchant (to create or
cancel
offerings).
The system that is revealed here enables new ways of doing business. As
specific
items reserved or purchased can be identified by id numbers or RFID tags
someone
could purchase and reserve an item online from a local retailer and then go to
a location
where the item is dispensed by an automated system. In a similar manner as one
can
now purchase a car wash from an automated gas pump, and receive a code to type
in
as you enter the car wash, other goods and services could be dispensed using
id
numbers that could be generated from the system that is revealed here or the
RFID of
the mobile device could be captured in this system or other means of
interacting with
the customer's mobile device could be used.
BRIEF DESCRIPTION OF THE DRAWINGS
An exemplary embodiment of the invention is described in detail in the
following with
reference to the following drawings in which like references refer to like
elements
throughout:
Figure 1 is a block diagram illustrating the components of an exemplary
intermediary
system in accordance with the invention.
Figure 2 is a schematic diagram illustrating the use cases performed by the
exemplary
intermediary system.
Figure 3 is a sequence diagram illustrating the processes of the exemplary
intermediary
system.
13
CA 02781648 2012-06-28
Figure 4 is a diagram illustrating an exemplary taxonomy node selection
display, for a
target entity request, that is generated by the target entity component of the
exemplary
intermediary system.
Figure 5 is a diagram illustrating an exemplary offering entity taxonomy node
selection
display for an offering, generated by the offering entity component of the
intermediary
system.
Figures 6a and 6b are diagrams illustrating further exemplary display options,
for a
target entity request illustrating a search of taxonomy nodes by key word
search, that
are generated by the target entity component of the intermediary system. These
diagrams also apply to an offering entity taxonomy selection generated by the
offering
entity component but removing the location and search radius user interface
items.
Figures 7a and 7b are diagrams illustrating further exemplary display options,
for a
target entity request illustrating a search of taxonomy nodes by navigation,
that are
generated by the target entity component of the intermediary system. These
diagrams
also apply to an offering entity taxonomy selection generated by the offering
entity
component but removing the location and search radius user interface items.
Figures 8a, 8b and 8c are diagrams illustrating further exemplary display
options, for a
target entity request illustrating the display and selection of detail
offering data, that are
generated by the target entity component of the intermediary system.
Figure 9 is a diagram illustrating a further exemplary display option, for an
offering entity
selection generated by the offering entity component of the intermediary
system. This is
used to select a taxonomy node for an offering.
14
CA 02781648 2012-06-28
DETAILED DESCRIPTION OF THE INVENTION
The present invention provides a method and system for facilitating provision
of
offerings associated with goods and/or services (e.g. offers for sale or
lease, discount
coupons etc.) by offering entities (e.g. merchants, service providers, etc.)
to target
entities (e.g. potential customers, purchasers, etc.) through the network. A
standardized protocol, comprising a shared predetermined taxonomy used to
organize
offerings information, provides improved scalability, timeliness and ease of
use. The
predetermined goods and/or services taxonomy may be a hierarchical taxonomy
(classifications/subclassifications structured by
specialisation/generalisation or
containment, i.e., is part of, relation) or a faceted taxonomy (a set of
taxonomies each of
which is a hierarchical taxonomy, the top node of which is a facet i.e.,
attribute, for
example, a facet of jewelry could be material with subcategories gold,
platinum, silver,
etc.) or could be a combination of both where any node in a hierarchical
taxonomy
might also be the top node in one or more embedded faceted taxonomies.
For example, cars could be a specialization subclassification of motor
vehicles. Further
specialization subclassifications might be under it such as sports cars, hatch
backs,
sedans, etc. Cars might also be the top node of a facet hierarchy for
manufacturer
location with subcategories Europe, Asia, North America. Within Europe there
could be
a further subclassification of UK, France, etc. For the purposes of describing
herein the
populating of a taxonomy with offerings from offering entities, and requesting
offerings
for a selected node (subcategory) of the taxonomy by a target entity, a strict
hierarchy is
used. However, faceted taxonomies may, optionally, be used for another
implementation in which case, in such an implementation, the offering entity
could be
prompted for attribute values relevant to an offering within a subcategory
node, and
those values are then stored for later use as sorting or filtering criteria
for generating
secondary ways for the target entity (user) to view the offerings that exist
under that
node.
15
CA 02781648 2012-06-28
The shared predetermined taxonomy has a tree structure comprising multiple
levels of
interconnecting nodes wherein a node in an upper level can be connected with
one or
more to nodes of a lower level. Each node is represented by a descriptor and
may be
assigned a unique identifier (e.g. code). Each node in a level of the multi-
level
taxonomy below the top level is defined by a path of nodes extending from the
top level
to that node through one or more nodes in levels between the top level and
that node. A
unique identifier may be assigned to each node to enable that node to be
referenced
directly without reference to its path or relative location.
In the illustrated embodiment the taxonomy is in the form of a tree of XML
(extensible
markup language) or JSON (JavaScript object notation). The standardized
taxonomical
data used by the merchant component 200, and also used by the target entity
component 300, may be downloaded from the intermediary component 100 and
installed, or otherwise obtained by those components. The intermediary 100 may
periodically update or expand the predetermined taxonomy whereupon the version
on
the component applications 100, 200 and 200 is updated by means of downloading
or
otherwise.
The following terms are used herein to describe the invention and mean the
following
(the plural thereof having the same meaning for a plurality):
Goods and/or services: any and all physical and non-physical items, rights and
benefits
subject to being offered including, without limitation, goods, products,
works, matter,
real property, chattels, services, leases and other forms of contracts.
Offering entity: any entity or party subject to communicating an offer of a
good or
service over a network including, without limitation, a business, merchant,
supplier,
provider, vendor, renter, lessor, restauranteur and other goods and/or
services source.
16
CA 02781648 2012-06-28
Target entity: any entity or party subject to querying over a network for
communications
regarding offers of goods and/or services including, without limitation, a
customer,
purchaser, buyer, renter and other goods and/or services recipient.
Offering: A particular good or service offered by an offering entity (e.g.
the CD
called Kind of Blue by Miles Davis CD on offer by Shea's Tunes). At any given
time,
there may be a quantity (e.g. 1, 15 or 200) of an offering on offer and the
quantity will
change over time i.e. it will decrease as quantities of the offering are
reserved by target
entities and may increase or decrease as the offering entity updates the
offering. If the
quantity is zero the offering is no longer available.
Information: Interchangeably used herein with the term data. The communicated
and
selected information/data is in the form of computerized (i.e. digital) data
configured for
use and/or storage by a computer, for example, as a protocol data unit (PDU)
or other
data transmission delivered as a unit.
Node information: Information which may be used to identify a node of the
taxonomy,
for example, a unique identifier, a path defined by a list of node descriptors
of the
taxonomy structure connecting the top level node to the identified node. When
performing steps in accordance with the invention the information used to
identify a
node may transform from one step to another depending upon the data protocols,
coding and mappings used for a particular embodiment.
Availability status: Information from which the availability of an offering,
or part thereof,
may be determined. This may include quantity information (e.g. it may be
determined
that an offering is no longer available if the quantity equals zero or has
limited
availability if the quantity is less than a quantity selected by a target
entity) and/or price
information (e.g. it may be determined that an offering is no longer available
but is
available with updated information, if the price differs from that of offering
information
previously received for it).
17
CA 02781648 2012-06-28
Offering information: Information which may be used to identify an offering of
an
offering entity (e.g. Kind of Blue by Miles Davis from Shea's Tunes). For
different steps
performed by a system component the information also comprises one or more of
availability status information, detail information, geographical information,
reservation
information and/or other information indicated or implied by the particular
step.
Accordingly when performing different steps in accordance with the invention
the
offering information may differ and the particular form or type of information
used to
identify an offering may transform from one step to another depending upon the
step
and the data protocols, coding and mappings used for a particular embodiment.
Offering entity information: Information that may be used to identify an
offering entity
(e.g. Shea's Tunes). Optionally comprises financial account information and/or
geographical information. When performing steps in accordance with the
invention the
information used to identify an offering entity may transform from one step to
another
depending upon the data protocols, coding and mappings used for a particular
embodiment.
With reference to the illustrated embodiment shown in the drawings, the
intermediary
system includes an intermediary computer program component 100, an offering
entity
computer program component 200 (e.g. used by a merchant) 200 and a target
entity
computer program component 300 (e.g. used by a potential customer) which are
provided as an ecommerce application. As shown in Figure 1, the components
100,
200, 300 are in the form of computer program instructions executable by a
processor of
a computer, and reside in computer readable media of computers 600, 700, 800.
The
offering entity and target entity components 200, 300 in the illustrated
embodiment are
located on mobile devices 700, 800 and the intermediary component is located
on a
server 600 (i.e. remote computer) in the communications network 400 (e.g. the
Internet). A central datastore 500 is accessible to the intermediary 100. The
offering
entity computer 800 has a local datastore. For alternative embodiments the
computers
600, 700, 800 may be other types of computers including mobile computing
devices
(such as smart phones, tablets, personal digital assistants (PDAs), notebooks,
netbooks
18
CA 02781648 2012-06-28
and laptops) and stationery computers, etc. or cloud services providing
computer
functionality potentially across multiple physical devices. The term datastore
herein
means any repository of data and includes a database or cloud storage.
Figures 2 and 3 illustrate, by means of a use case diagram and sequence
diagram,
respectively, processes performed by the intermediary component 100, the
offering
entity component 200 and the target entity component 300 of the illustrated
exemplary
intermediary system. The intermediary computer program component 100, the
offering
entity computer program component 200 and the target entity computer program
component 300 are configured to use the predetermined goods and/or services
taxonomy.
With reference to Figures 2 and 3, the following is a summary of steps
performed by the
intermediary, offering entity and target entity components:
A. The shared predetermined taxonomy is established for use by the
intermediary,
offering entity and target entity components of the system. This may be done
by
downloading online via the Internet, for example, using HTTP or FTP, or by
installation
offline. The offering entity component registers with the intermediary
component (item 1
in Figures 2 and 3) by providing offering entity information to the
intermediary
component. The offering entity information is used to identify the offering
entity e.g.
name and email address and geographical information such as location i.e.
country,
zip/postal code and/or GPS location of the retail location using GPS 900, and
may also
include financial account information such as a merchant credit card account
etc. (item
1 of Figure 2 and 3).
B. When an offering entity (e.g. the merchant Shea's Tunes, as in the
illustrated
embodiment) wishes to communicate an offering (e.g. a Kind of Blue by Miles
Davis
CD) it selects one or more nodes of the taxonomy for association with the
offering and
inputs offering information to the offering entity component (item 2 in
Figures 2 and 3).
To do so, the offering entity uses a user interface device (e.g. a display) of
the offering
19
CA 02781648 2012-06-28
entity computer to navigate through selectable predetermined goods
and/services
descriptors (e.g. Jazz at one level and then CD at the level below it)
representing nodes
of the taxonomy. One or more of the descriptors is selected and, thus, the one
or more
nodes they represent. The offering entity component stores the offering
information and
associated node information in local datastore (not illustrated) accessed by
the offering
entity computer. The offering information stored in the local datastore is
updated by the
offering entity as availability (i.e. the quantity available and price) and/or
details of an
offering change.
C. The offering entity component then sends a protocol data unit (PDU) in HTTP
(or
other protocol) containing that offering information and associated node
information to
the intermediary component. The offering information and associated node
information
are stored in a datastore 500 accessed by the intermediary component and this
information is automatically updated if and when any of the information is
updated in the
local datastore of the offering entity, perhaps delayed for performance
reasons, for
example, to push updates to the intermediary every 15 minutes so updates are
batched
and network traffic reduced. Some offering information which change more often
like
price or quantity available might each have separately defined push update
(sending to
the intermediary) timings. Push update timings could be separated by
information type.
So, for example, the update timing for quantity available (if it alone has
changed) might
be never on its own or never on its own until it reaches zero, i.e., not
available. Should
any particular information item have changed, triggering a push update then
all changed
items would be sent including quantity available even should its update timing
be set to
never (if it alone has changed), for example. Synchronization activity between
the
central datastore 500 and local offering entity datastores is driven by
volatile information
such as quantity and price information which are more dynamic (change
frequently)
modified by settings for push update timings. As a greater number of offering
entities
provide their offerings to the intermediary component, the nodes become
associated
with a greater number of offerings for which offerings information is stored
in the
intermediary's central datastore 500. The communicated PDU may contain one or
more
good(s) and/or service(s) offering(s) per node, and the offering information
for an
CA 02781648 2012-06-28
offering may include availability status information, detail information and
geographical
information comprising details about the particular offering. Similarly, the
PDU may
include multiple offerings associated with different nodes. In the embodiment
described
herein, each node is identified by a unique identifier i.e. an identifier
which uniquely
identifies that node from other nodes of the shared taxonomy. In the
embodiment
described herein, the offering entity component also generates a unique
identifier for
each offering which is associated with quantity information for the offering,
and this
information is included in the offering information sent to the intermediary
component.
D. The target entity component sends to the intermediary component a PDU in
HTTP (or other protocol) a request comprising node information identifying one
or more
selected taxonomy nodes to query what offerings are available in association
with those
selected nodes (item 3 in Figures 2 and 3) and geographical information like
target GPS
location or a country identification with postal code/zip with a search radius
in kilometers
or miles. As shown in the drawings, a target entity (e.g. a customer, as in
the illustrated
embodiment) may use a user interface device (e.g. a display) of the target
entity
computer to initiate such a request by navigating through selectable
predetermined
goods and/services descriptors representing nodes of the taxonomy and
selecting one
or more of those descriptors.
E. In response to the request of D, the intermediary component sends to
the target
entity component offering information for zero, one, or more available
offerings stored in
the datastore in association with the selected node(s). Optionally,
availability status
(quantity and price) is included in the offering information for the offering.
The
availability of an offering is indicated by its offering information. For
example, a quantity
of zero may be used to indicate an offering is no longer available at a
particular time or
the offering information may have been removed, flagged as inactive and/or
transferred
to an inactive storage are of datastore 500. A unique identifier may also be
provided to
identify the offering information sent to the target entity component for an
offering.
21
CA 02781648 2012-06-28
F. If the target entity chooses to reserve (e.g. purchase, in the
illustrated
embodiment) one or more of the offerings for the offerings information
provided by the
intermediary component in E, it uses the user interface device to select the
offering(s).
The target entity component sends a reservation request to the intermediary
component
to reserve the selected offering(s) (item 5 in Figures 2 and 3) by sending a
PDU in
HTTP (or other protocol) comprising offering information for the selected
offering(s),
which may be the unique identifier(s) of E where such has been provided (or a
mapping
of it), and optionally quantity and/or other limiting information for the
reservation(s) (e.g.
purchase).
G. The intermediary component then sends a corresponding reservation
request to
the offering entity component to initiate a reservation transaction (e.g.
purchase
transaction) for the selected offering(s) (item 6 in Figures 2 and 3).
H. Because the volatile availability status information comprising quantity
and price
information in the intermediary datastore 500 may not be fully synchronized
(i.e. up to
date) with the master information on the offering entity's datastore, the
offering entity
component reviews the availability status of the offering information for the
selected
offering stored on its local datastore and compares it with any quantity
requested and
price information in the reservation request. From this review of the
availability status
information it may be determined that the requested offering is no longer
available or
that criteria of quantity requested and/or price in the reservation request is
not available
or is only partly available. The offering entity component sends reservation
information
notifying the intermediary component either that the request has been accepted
or that
it has been rejected in whole or in part. Optionally, a reservation identifier
(e.g. a
reservation number) may be included for use by the offering entity and
intermediary
components to reference this reservation response of the offering entity
component or
optionally reservation identifiers could be generated for each divisible
satisfied portion of
reservation response. If only a part of the reservation request can be filled
the
reservation information may indicate what part may be satisfied (e.g. a lesser
quantity
may be available than specified in the reservation request). Availability
status price
22
CA 02781648 2012-06-28
information will not be as volatile as quantity information but for some
offerings it might
be out of sync more often. If the price has increased and the offering entity
database
has a higher price than that of the reservation request, then the reservation
request will
be rejected if the offering entity component has preset such a result. If the
price has
decreased and the offering entity database has a lower price, then the
reservation
request will be confirmed for the lower price if the offering entity component
has preset
such a result. When a reservation is initiated by the offering entity
component the
reservation information may also include a unique identifier for the reserved
offering e.g.
a radio frequency identifier for the particular good which has been reserved
by that
offering entity in response to the target entity's reservation request.
I. The intermediary component sends the reservation information to the
target
entity component. If the reservation information could only be satisfied in
part in H but
the component entity was set to completely reject the offering in such
circumstances
then the target entity component may then send to the intermediary component a
new
reservation request for the part which was not rejected.
To select a node of the taxonomy to make offering (i.e. by the offering
entity) or to
request offerings (i.e. by the target entity) either a key word search of
category
descriptors can be used or the category descriptors can be navigated by
selecting top
level descriptors and drilling down to connected lower level descriptors until
the desired
category is found, as illustrated in Figures 6a through 9. The search radius
and
zip/postal selection options in Figures 6a and 7a are not displayed to
offering entity
users. However, they are presented to a target entity user whereby the target
entity can
select a search radius (e.g. in kilometers or miles) from the target entity
computer's
default current GPS location or a zip/postal code in a country selected from a
dropdown
list (e.g. for use by the target entity to book a hotel for a planned a trip).
The offering entity selects a node for an offering by pressing the selected
arrow head in
Figures 6b and 7b and then a form is displayed for the offering entity to
input offering
information for the offering. Node information identifying the selected node
and the
23
CA 02781648 2012-06-28
input offering information is stored in a datastore of the offering entity
computer 800 and
all of this data is transmitted to the intermediary component 100 (item 2 of
Figures 2
and 3) where it is stored in the central datastore 500. The target entity
selects a node
for an offerings request in similar manner.
The offering information input from offering entities for their offerings is
present in the
intermediary datastore 500 (each associated with a taxonomy node previously
selected
by the offering entity) as well as being present on the local datastores of
the offering
entity computers. Some of the offering information on the central datastore
500, in
particular the more volatile information such as quantity and price
information, may not
be synchronized with the counterpart data of the offering entity's local
datastore (in the
offering entity computer), in which case it is desirable that the intermediary
component
obtain and use the current data from the offering entity's datastore. While
price
information might have changed on the local datastore, and the offering itself
might
have been discontinued, the availability status information most likely to be
out of sync
is the quantity available. To keep quantity available information in sync
would be a
challenge to scalability with current technology. For this reason,
availability status
information may be omitted from those offering data items that trigger the
synchronization process used to automatically update the central datastore
when
offering information is changed in the offering entity's local datastore. To
make an
update the offering entity computer sends a web service call to the
intermediary 100
and intermediary 100 update the datastore 500. In such case, while a change
made to
the quantity available might not itself trigger this updating web service
call, any change
that has been made to the quantity available will be included in the update
made by the
web service call.
In response to a target entity's request for offerings associated with a
selected node e.g.
by selecting a specific goods and services descriptor, the intermediary
component 100
sends the offering information for the offerings of the selected node to the
target entity
component and the information is displayed to the target entity on a user
interface
device of the target entity's computer 700. In the example shown in Figure 8a
the target
24
CA 02781648 2012-06-28
entity 300 selects a displayed item for a grouping of three offerings, being
for the Kind of
Blue by Miles Davis CD by three different merchants, and offering information
for those
three offerings is displayed in Figure 8b. In this example, after the target
entity selects
one those offerings, the detail information for the offering is displayed as
shown in
Figure 8c. Optionally, a selectable button may be displayed to the user to
have the
display show the locations of the listed offering entities on a map (not
shown) using the
GPS or other location information for the offering entities and/or the
distance from the
current or selected position of the target entity to each offering entity may
also be shown
in the list of qualified offerings returned depending upon the target entity
computer and
its available display size.
When a request for a reservation for an offering is made by a target entity
and sent to
the offering entity by the intermediary, the offering entity component
initiates a
reservation transaction for the offering whereby the offering information in
the offering
entity's local datastore is updated to reflect the reservation and the
offering is
associated with a reservation identifier. If the reservation is for a sale of
the offering a
purchase and sale transaction is initiated and completed between the target
entity
component and the intermediary entity component and another purchase and sale
transaction is initiated and completed between the intermediary and offering
entity
component. Many ecommerce service options are available in this area of
technology
and the marketplace to debit the target entity's credit card or paypal account
and credit
the merchant's financial account or otherwise transact a transfer of money to
the
offering entity.
Invoices/receipts of sale and/or sale vouchers are sent by the intermediary
component
100 to target entity component 300, optionally including RFID information or
other
supplementary identifiers for the good or service purchased (e.g. a code to
use a car
wash). The target entity computer 700 may be enabled to print sale vouchers or
otherwise interact with manual or automated systems of the offering entity
component.
There might be a separate reservation number for each divisible portion of the
reservation or the reservation identified may be configured for a multiple
number of the
CA 02781648 2012-06-28
purchased offering, e.g. as a sequence number 1-n for a reserved quantity of
3. For
example, a target entity may reserve 3 discount vouchers at a restaurant but
intent to
use them one at a time, one per visit, in which case the target entity could
elect to print
three vouchers with a voucher code identified by an offering entity
code/reservation
number/sequence number.
Upon or after registration the merchant 200 may, optionally, provide the URL
address of
a designated web service accessible on the Internet that complies with
functionality and
web service function signatures of a standard merchant web service. These web
service
function signatures (i.e. the form of the web service function) normally would
be
identical to those of the REST web service residing on the merchant 200 device
but
alternately they might, for example, use a SOAP/WSDL based implementation.
Other
additional security information could be provided by merchant 200 to
intermediary 100
for access to this web service or such security information could be provided
through
other means offline. Such an external web service could be used by large
retailers or
other merchants where the volume of potential offerings already stored in
existing
systems and/or the volume of potential transactions would be too much for a
mobile
device or desk top computer. Should alternate web service URL information not
be
entered then the system will default to use the web service residing on the
merchant
200 device for web service calls to the merchant 200.
Advantageously, the more volatile offering information (i.e. availability
status
information) for an offering may be requested by the intermediary 100 from the
merchant component 200 when a target entity component sends it a reservation
request
for the offering. In this manner, volatile offering information (which is more
likely to be
out of sync on a centralized database) is distributed over the network with
the
applicable offering entities (i.e. in their computers 800) thereby improving
scalability and
improving the timeliness of the communication of offerings.
If the merchant offering selected by the target is for the sale of goods or
services, and
after successful reservation the customer decides to purchase the goods or
services of
26
CA 02781648 2012-06-28
the offering, the customer 300 sends a web service secure request to the
intermediary
100 over HTTPS (item 7 of Figures 2 and 3). The intermediary 100 checks to see
whether customer is logged in to and registered with the intermediary 100. If
not, the
intermediary sends a registration request to customer 300 and the customer 300
prompts the target to register (item 4 of Figures 2 and 3).
Payment to the offering entity (merchant) is provided through the intermediary
100
which credits a credit card merchant account or otherwise transfers funds to
the
merchant subject to any agreement that has been made, and debits a credit card
target
account of the target. The intermediary 100 notifies the merchant 200 that the
sale is
complete and sends to the merchant 200 and customer 300 detail information of
the
sale which the merchant 200 then stores in its datastore.
Upon completion of the sale transaction the intermediary 100 sends a receipt
or
voucher to the customer 300 over HTTPS. In future it is expected that the
marketplace
will provide improved software mechanisms for managing cross-platform
transactions
(meaning the software engineering use of this term whereby the transaction
changes
are isolated and not visible until the transaction has been completed).
Current efforts to
do so, such as web services standard WS_Transaction are not yet implemented
(see
http://searchsoa.techtarget.com/definition/WS-Transaction).
The intermediary system also facilitates offerings that do not involve a
requirement for
an exchange of money, for example, an offering of an appointment to view
rental
property (e.g. apartment), in which case the offering entity is a landlord and
the
intermediary 100 facilitates a negotiation of the appointment time/day between
the
merchant 200 and customer 300.
A merchant 200 used, for example, by a large retailer may prefer to store
offerings
detail data (e.g. service, product, and price, and quantities available data)
on an
external storage system e.g. an existing legacy system. To do so, a server web
service
in a defined format is created on an external storage system by the merchant
27
CA 02781648 2012-06-28
component 200. The Internet URL address of this web service is provided to the
intermediary 100 by the merchant component 200 as discussed above. In turn,
the
merchant 200 resides on various devices using run-anywhere languages like
Java,
which allows installs on most platforms excluding !Phone and !Pad, or
Objective C
which allows installs on IPhone and IPad 10S). Where the merchant 200 is
required to
make web service client calls as well as provide web service server
functionality should
the web service be located on an external system, then that external system of
the
merchant 200 must also be given security information to access the web service
server
functionality on intermediary 100. This information (e.g. userid, password,
encryption
details, etc.) may be provided offline.
The use of a shared (i.e. common) taxonomy of metadata (i.e. the goods and
services
node descriptors) for selections made by the merchant 200 and the customer 300
advantageously provides means to partition the offerings data for fast queries
and
effective communication having improved clarity. A customer 300 uses the
metadata
taxonomy so that, for example, a category and subcategories (i.e. nodes) are
selected
based on sets of predetermined goods and/or goods descriptors. The category
and
subcategory displayed to the target are "women's clothing" and "trousers" in
the display
presented by the customer 300 in Figure 4. The merchant 200 provides to the
offering
entity via the intermediary the same taxonomy of categories and subcategories
of goods
and services for the offering entity's use to send offerings data to the
intermediary 100
(see Figure 5). This use of a common taxonomy, maintained by the intermediary,
improves the ability of the customer to identify offerings of interest. The
customer may
further qualify a request for offerings by a distance or radius in a specified
geographic
area and/or by time and date criteria such as a query for music events at a
future date
and time range.
While the use of a predetermined taxonomy advantageously provides a more
precise
means of locating a good or service as compared with keyword search engines
where
unrelated material is returned and has to be sifted through manually, some
challenges
may be expected to ensure that the taxonomy is adequate, to avoid placement of
28
CA 02781648 2012-06-28
offerings in the wrong subcategory, to remove/move offerings placed in the
wrong node
in the category tree, and to remove junk.
The exemplary illustrated intermediary system uses REST web services to
communicate between the components 100, 200, 300 of the system and fulfill
requests.
Once a customer component 300 has generated a query, per step 3 of Figures 2
and 3,
a Web service call is made via the mobile device 700 or computer to the remote
intermediary 100. Like the usual Web services performed on mobile devices for
which
the mobile device has a role of client communicating with a remote machine
acting in a
server role, the mobile device 700 of the customer 300 acts as the client for
Web
services but, unlike usual Web services interactions, the intermediary and
merchant
components 100, 200 have roles both as servers and as clients for Web services
used
by the intermediary system.
A possible obstacle for implementation is presented by the possibility that a
vendor
using the system might install the merchant component behind network address
translation (NAT) within a sub-network using local IP addresses that are
different from
their IP addresses as seen on the public internet (the Internet). However,
this issue will
disappear as network providers convert from Internet Protocol version 4 (IPv4)
to IPv6.
Most mobile devices are IPv6 capable today and network providers are in the
process
of converting to IPv6. There are some techniques available such as JXTA
(Juxtapose)
to overcome IPv4 NAT issues, where/if desired.
Optionally, the components of the intermediary system may comprise RFID
modules for
operating in combination with radio-frequency identification (RFID) systems of
the
offering entities to identify products of offerings reserved by target
entities. RFID
systems are used by merchants for various purposes such as security and may be
adapted for use with the intermediary system to obtain additional services to
associate
merchant products with customers (target entities) who have reserved (e.g.
purchased)
them by means of the intermediary system. RFID systems allow placement of RFID
locators near RFID tagged items to be very precisely located. For example,
after a sale
29
CA 02781648 2012-06-28
of a product offering, an RFID module of a retailer's merchant component 200
passes to
the purchaser, through the intermediary 100, RFID information that enables an
RFID
module of the purchaser's customer component 300 to interact with an in-store
RFID
system of the retailer to locate the purchased product, thereby reducing the
need for
staff to assist the purchaser in the product pick-up process. In addition, the
RFID
module of the purchaser's customer component 300 passes to the merchant,
through
the intermediary component 100, RFID information identifying the purchaser's
mobile
device to enable the in-store RFID system to locate the purchaser when the
purchaser
arrives at the store to pick-up the product. As the purchaser enters the store
the
merchant's RFID system has the location of both the purchaser (via their
mobile device
700 on which the RFID module operates) and the purchased product. The RFID
system updates the purchaser regularly, via the RFID module on mobile device
700, on
the purchaser's distance and direction from the purchased product.
Alternatively,
instead of providing RFID information about the mobile device 700 to the
merchant's
RFID system, the mobile device 700 could be provided with product location
information
which the mobile device 700 uses to display a map of the store with a location
indicator
for the purchased product.
Further, when an in-inventory product has been sold the RFID system identifies
the
product, via the product's RFID tag, as having been sold and available only to
the
purchaser only. Should other customers attempt to purchase the item beforehand
it
would be possible stop this as RFID tags on the item and store systems would
know
that the item belongs to someone else.
The RFID modules used by the intermediary system components use a software
function which exchanges information describing the location points of the
customer
mobile device 700 and the location of the purchased product. The software
function
also receives information describing the context of those location points if
the location
points do not contain that data themselves. For example, if a location point
is on an X-Y
coordinate system, is it in a strictly north-south and west-east orientation
or does that
coordinate system point to the far wall of the store. By simple math the
orientation of
CA 02781648 2012-06-28
the purchaser relative to the purchased product can be calculated and a
direction vector
returned from the software function. If a strictly north-south and west-east
orientation
context is provided, the mobile device, using a compass in the device,
presents the
purchaser with a pointer to the product. If some other context is provided,
the mobile
device uses the displacement value to display direction instructions based on
that value,
for example, an instruction stating that "the product is 5 feet away towards
the mall
entrance". Alternatively, the RFID modules could use function calls or remote
access
calls to the software of the RFID system which controls RFID locators of RFID
modules
and RFID tags.
In some cases model numbers or offering names could be setup as subcategory
nodes
and a customer component could be preset to receive notifications for a price
change
(downward or upward) or a change in availability on offerings in model or
offering name
nodes (displays not shown). Or a customer component may be configured to be
able to
send a query to the intermediary to compare prices interactively for offerings
in such
nodes (displays not shown) and return the results. For example, a concert fan
might
want to be notified if concert tickets become available, or a home owner might
want to
quickly compare prices across offering entities in the local area on
Westinghouse
dishwasher model XYZ.
Optionally some offerings could be set up as restricted to a membership group.
For
example, a baby sitter might want to qualify customers before she lets them
book an
available time for babysitting. A tennis club might only allow members to book
courts. Or
a club type retailer may require membership before one can purchase an item.
To do
so the offering entity sets an attribute in the offering information that
indicates a
restricted membership group. Before sending a reservation request for an
offering to
the offering entity component, the intermediary component checks whether the
offering
is for a restricted membership group. If so, then the intermediary checks
whether the
target entity requesting the good or service is in the list of members of the
group. If they
are not, then a message to that effect is returned to the target entity
component to notify
the target entity that this is a restricted group.
31
CA 02781648 2012-06-28
For example, the membership list may be maintained by a separate software
component that uses email for confirmation. After refusal of a reservation
request the
requesting target entity is asked if they would like to join the membership
group and, if
they affirmatively reply, then an email request to approve the target user for
membership in the group is sent to the offering entity by email. If the
offering entity
sends an approval then the target entity is added to the membership list.
The invention has been described with reference to a specific embodiment
illustrated by
the drawing figure which should be considered as illustrative only and not
limiting of the
invention. Reference should be made to the claims to determine the scope of
the
invention.
32
