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