|Publication number||US7617162 B2|
|Application number||US 11/182,668|
|Publication date||Nov 10, 2009|
|Priority date||Mar 4, 2005|
|Also published as||US20060200387|
|Publication number||11182668, 182668, US 7617162 B2, US 7617162B2, US-B2-7617162, US7617162 B2, US7617162B2|
|Original Assignee||Atul Saini|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (19), Non-Patent Citations (5), Referenced by (9), Classifications (17), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The method and structure of the implementation of event driven networks fundamentally differ from one another in the type of notification system, type of data storage, location of data storage, security, routing and network topology.
In currently used e-commerce solutions, including peer-to-peer networks, a “pull notification” system is used for deriving a match between the requirements of a buyer and a seller. In a pull notification system, the buyer issues a buy request, which is then matched against the seller's profile at that point in time. However, if a seller does not have a matching product or service at that point in time, the seller has to wait until the search is again initiated by the buyer. However, this method reduces the incidence of a match at the time of posting of the changed attribute and also reduces an eventual match between the buyer and seller. Even if the buyer automates the search to be conducted at short periodic time intervals, during that short time interval the seller loses his or her opportunity to complete the transaction of the product or service if the seller's product or service was not posted for sale during that time interval. Also, if a seller updates their profile and places a product or service on sale that would have matched the buyer's requirements just after a search is conducted by the buyer, the transaction will again not be completed. The seller will now have to wait until the next automatic or manual search is conducted by the buyer after a predetermined time interval. In today's e-commerce networks containing thousands if not millions of users, a fraction of a second lost in the posting of information by sellers on the availability of their product or service can potentially be a significant lost sale opportunity for that seller. In summary, the “pull notification” strategy that is buyer-driven places some sellers at a disadvantage in e-commerce networks. Also, in a large network of users, if automated searches are set by users to be conducted at short periodic time intervals, the network traffic may get over-loaded as a result of the frequent automated notifications.
Typically, in currently available pull notification solutions, all transaction data, for example the details of the buyer and seller are stored in a central database. The user, which may be the buyer or the seller, logs on to the system and searches this central database to determine a match for the user's requirements. When the system finds a match for the user's query, the system notifies the user. If a match is not indicated at that point in time, the user has to re-initiate the search at a later point in time. In the above solution, a central database is required; the local databases of the users' user applications are not utilized for storing data. Even in the case of a pull notification system with a distributed database, typically intelligence is located centrally. A central controller would conduct the predetermined periodically-timed searches of the buyer and would execute the transactions.
In the present push notification invention, the event driven network is brought to the user, thereby empowering all sellers. The user does not have to actively conduct search queries at short periodic time intervals for buy or sell transactions. The user only needs to feed the changed attributes in the attribute profiles of the user's application for conducting a transaction. Once the user changes the buy or sell attribute profile, the notification of the change in attribute is automatically broadcasted in real time to all users of the event driven network. This automatic broadcast of attribute changes in this event driven network will hereafter be referred to as push notification. The user can change the user's attribute profiles even if the user application is not logged on to the event driven network. Once the user application logs on to the event driven network, the notification of the change in attributes is sent to all other users in the event driven network.
The following example illustrates the differences between the pull notification method of existing solutions available today in the market from the push notification system of this invention that is implemented in real time and is event driven. For example, consider an e-commerce event driven network used for buying and selling goods. A buyer desires to purchase a book at a certain sale price using this event driven network. The buyer would send out a search request on the event driven network to find a seller for that book at that sale price at that point in time. Assume that the first search is conducted at 12:00 P.M. and no sellers have that book at the sale price at 12:00 P.M. The buyer then requests the network to automatically conduct a search for the book at one-hour intervals. Therefore, the next search will be conducted at 1:00 P.M. Assume that at 12:59 P.M., Seller A posts the required book at that sale price in the event driven network, and that Seller B posts that book at that sale price at 1:01 P.M. on the same network. When the automated search is conducted at 1:00 P.M., only Seller A's book will show as available for sale on the network to the buyer. Assume that the buyer needs to take a decision on buying the book by 1:30 P.M. In a pull notification system, the transaction for the purchase of the book will be executed through Seller A, because the buyer was not made aware of the availability of the book by Seller B at 1.01 P.M. as the search of the book will not be re-conducted by the buyer from 1 P.M. to 1.30 P.M. Even though Seller B posted his or her book on sale on the network at 1:01 P.M., i.e. just 2 minutes later than Seller A, Seller B lost the opportunity to sell the book to the buyer. This is the disadvantage of the typical pull notification system of currently available solutions. The current pull notification system places some sellers at a disadvantage. However, in the event driven push broadcast notification of this invention, there is no need to conduct a search periodically at predetermined time intervals. If a seller posts a book or updates their attribute profile at a point in time after the search query is conducted but before the execution time of the transaction and where the book meets the requirement of the buyer on sale, the new information is pushed out and broadcasted to other users, i.e., to potential buyers in the network. Hence, under this invention, Seller's B notification of the book at the sale price will be sent to the buyer at 1:01 P.M. and the buyer now can choose between the books of Seller A and Seller B as the buyer will execute the transaction for the purchase of the book at 1:30 P.M.
It may appear that the use of a push notification strategy will result in the event driven network to be flooded with update messages. In reality, the network traffic generated as a result of notification updates of sellers is less than network traffic generated by a majority of the buyers that conduct automated searches at short periodic time intervals in a commercial network using the conventional pull notification method. In current commercial pull notification system networks, the buyer does not have an incentive to place a time limit for the period of time such periodic searches are to be conducted. However, the shorter the time interval, the greater is the traffic burden on the network. Hence, the current pull notification system network is heavily burdened with redundant automatic searches that are sometimes conducted even after the buyer has decided not to purchase the product or service.
Under this push notification invention, there is there is no need for any centralized intelligence for performing the matching of attributes. The intelligence for performing attribute matching lies in each user application.
Also, under this push notification invention there is no need for a large centralized database to store the user's attribute information. The user's attribute information is stored either locally in the device hosting the user's application or is stored in a distributed database spread across the event driven network.
Also, under this push notification invention the user can send the search query to either all the users in the network or to a specific group of users. The user can specify the radius within which the search is to be conducted. The application allows a user to easily perform off-line zip code look-ups, and distance and radius calculations.
Also, under this push notification invention when a successful match between the attributes occurs, the two users can continue the transaction external to the network, thereby eliminating any mediator between the interested parties.
Also, under this push notification invention, the user applications can include computers, personal digital assistants, wireless handsets, landline phones and other forms of computing and communicating equipments. Notifications can be sent between multiple types of user applications.
Also, this push notification invention allows the optional rating of the sellers by individual buyers without any centralized intervention. When a search is initiated, higher rated sellers will be listed above lower rated sellers, with the seller-rating data being stored, like the match information, at the end-points of the network.
Also, this push notification invention allows the user to create and send out multiple search queries using the same user interface window. This allows the user to conduct multiple transactions simultaneously.
A new user is permitted to join the event driven network through registration of its attributes, subnet choices and its logical name. The subnet choices define the group of users within the event driven network that the user wishes to transact with. For example, a buyer may desire to buy a car from sellers located in his hometown. He would then set the subnet to only include users of the event driven network who are located within a certain distance from his residence, or to a named set of users, or to an automatically determined subnet of users on the network, for example, via a table look-up.
Each user in the event driven network generates a specific user attribute profile that contains information on the characteristics of the user and the specifics of the transactions the user wishes to enter into. The user attribute profile of each user is stored in the storage database. Note that the storage database is either the local database of the device in which the user application is hosted, or a distributed database in the event driven network. For example, a user may desire to purchase a car with an odometer reading of less than 20,000 miles, manufactured by BMW and at a maximum price of $40,000. Hence, this purchase request consisting of the odometer reading, car model and price attributes are stored in the storage database of the user.
For example, consider the case of John Smith who places a search for a used Harry Potter novel at a price of $10. Assume that at 1:00 P.M. when he conducts the search for the novel over the event driven network, he is unable to find a seller for the novel. Assume that at 2:00 P.M., Jerry Carter placed his Harry Potter novel for sale to all the users over the event driven network. When Jerry Carter updates his local database with the attributes of the book and its price, this information is broadcast to all users of the network. This update notification will reach John Smith through the event driven network the instant the information is updated in Jerry Carter's user application. For example, Jerry Carter's user application may reside in a smart phone that contains a computer with wireless communication capability, and John Smith's device may be a desktop computer communicating with the event driven network through a wire line.
A network of user applications is created wherein each user application has a set of one or more up-datable attributes. An attribute profile for the user is generated for every user application in the network, wherein an attribute profile consists of a set of sub-attributes, each of which is a set of bytes of information 301. The new attribute of the user application is stored in the user's profile in a database 302. The attribute profile is transmitted to other user applications over the event driven network. The user applications exchange information with one another other either directly, or indirectly using one or more transmission protocols. The information of any changed attribute in the attribute profile is recorded by a user application 303 and the changed attribute is broadcasted to one or more user applications in the event driven network 304, the broadcasting occurring immediately after any attribute in the attribute profile of the user application is changed. One or more sub-attributes of an incoming attribute profile is compared with one or more sub-attributes of the stored attribute profile of the receiving user application 305 by the notification manager. The matching of the sub-attributes is performed within the receiving user application 306, which precludes the need for a centralized matching engine. The step of comparing one or more sub-attributes is implemented by a set of matching instructions for the attributes, with the matching instructions being stored in any user application thereby precluding the need for a central user application or central device.
In the event of a successful match, a notification is created and transmitted to one or more of the transmitting user applications on the network 307. The transaction is successful 309 if both the transmitting user and receiving user execute 308 the transaction. The transmitting user is defined as user whose changed attribute is being broadcasted. The receiving user is defined as a user who is receiving the changed attributes of the transmitting user. The notification of a change of the attribute of a user application can be sent through a number of user notification devices. The notification system is fully automated, wherein the user is notified with information about the detected condition. If done via telephone and an interactive automated system, a voice recognition system or a touch-tone system is used so that once contacted the user may obtain additional information about the user item. The system can be coupled to an e-mail server so that system can notify users of detected conditions using an e-mail process.
The notification manager includes a time provider that provides a time-out period for a notifying the user. The time-out period can specify a time duration or expiration period, wherein the user notification expires after the expiry of the time period. At times, communication may be lost between the notification delivery service and the user. Hence, acknowledge communication codes are employed to acknowledge error free transmission and indicate corrupt transmission or no transmission.
If one or more of the attributes of a buyer and seller match, the user is notified, and the system allows the matching algorithm to be customized by matching multiple words concurrently. Notification of the communication of a successful match of attributes may be accomplished via several means. Examples of notification means include, but are not limited to, e-mail notification, telephone, fax and beeper. The user may rank these notification choices and have the notification system attempt to contact the user based on the ranking of the preferences. If the user is not available by using the first notification means, then the matching services tries to reach the user by using the next notification means. A default notification means may also be provided. When both the sender and recipient agree upon the deal, they may choose to by-pass the entire event driven network and communicate externally to the network.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5745882||Jan 9, 1995||Apr 28, 1998||Us West Marketing Resources Group, Inc.||Electronic classified advertising interface method and instructions with continuous search notification|
|US5974406||Aug 18, 1997||Oct 26, 1999||International Business Machines Corporation||Automated matching, scheduling, and notification system|
|US6185611||Title not available|
|US6253198 *||May 11, 1999||Jun 26, 2001||Search Mechanics, Inc.||Process for maintaining ongoing registration for pages on a given search engine|
|US6591094||Apr 11, 2000||Jul 8, 2003||Televoke, Inc.||Automated user notification system|
|US7069308 *||Jun 16, 2003||Jun 27, 2006||Friendster, Inc.||System, method and apparatus for connecting users in an online computer system based on their relationships within social networks|
|US7216093 *||Aug 28, 2000||May 8, 2007||International Business Machines Corporation||Method of, apparatus for, and computer program product for trading goods|
|US7424409 *||Feb 19, 2002||Sep 9, 2008||Context-Based 4 Casting (C-B4) Ltd.||Stochastic modeling of time distributed sequences|
|US20020042846 *||Oct 1, 2001||Apr 11, 2002||Bottan Gustavo L.||Personal support network|
|US20030191650 *||Sep 25, 1998||Oct 9, 2003||Philips Electronics North America Corporation||Customized upgrading of internet-enabled devices based on user-profile|
|US20030229674 *||Jun 10, 2002||Dec 11, 2003||Microsoft Corporation||Internet scaling in a PUB/SUB ENS|
|US20040107283 *||Oct 6, 2003||Jun 3, 2004||Trilibis Inc.||System and method for the aggregation and matching of personal information|
|US20040162064 *||Nov 10, 2003||Aug 19, 2004||Himmelstein Richard B.||System and method for matching users based on proximity and/or user-defined profiles|
|US20040203923 *||Mar 25, 2003||Oct 14, 2004||Mullen Jeffrey D.||Systems and methods for locating cellular phones and security measures for the same|
|US20040205048||Mar 28, 2003||Oct 14, 2004||Pizzo Michael J.||Systems and methods for requesting and receiving database change notifications|
|US20060031400 *||May 20, 2002||Feb 9, 2006||Universal Electronics Inc.||System and method for upgrading the remote control functionality of a device|
|US20060242291 *||Jun 30, 2003||Oct 26, 2006||Mikko Nevalainen||Method and device for determining and notifying users having matching preference profiles for accessing a multiple access online application|
|US20080091662 *||Oct 17, 2007||Apr 17, 2008||Software Management, Inc.||Method and System for Conducting a Plurality of Cyber-Based Conventions|
|WO2000073955A2 *||May 24, 2000||Dec 7, 2000||Accenture Llp||Methods, concepts and technology for a virtual shopping system capable of assessing needs of a customer and recommending a product or service based on such assessed needs|
|1||*||Anon., "Geac's Interealty.com and Sitesnet.com Partner to Supply Real-Time Data to Real Estate Professionals," CCN Disclosure, Apr. 12, 2000.|
|2||*||Anon., "Major Key Components of Verity Search '97 Platform Now Shipping," PR Newswire, p. 1211SFW002, Dec. 11, 1996.|
|3||*||Anon., "PLS Unveils 'Smart' Personal Agent Software," Online, vol. 20, No. 2, p. 10, Mar.-Apr. 1996.|
|4||*||McGuire, J.G., et al., "SHADE: Technology for Knowledge-Based Collaborative Engineering" (Abstract only) Concurrent Engineering:Research and Applications, vol. 1, No. 3, pp. 137-146, Sep. 1993.|
|5||*||R.C. Johnson, "Neural Agent Enables Personalized Surfing-Web-based Information Service Employs Algorithms to Discern User' Tastes," Electronic Engineering Times, p. 39, Feb. 9, 1998.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8265938||Dec 13, 2011||Sep 11, 2012||Verna Ip Holdings, Llc||Voice alert methods, systems and processor-readable media|
|US8595322||Oct 21, 2011||Nov 26, 2013||Microsoft Corporation||Target subscription for a notification distribution system|
|US8694462||Oct 21, 2011||Apr 8, 2014||Microsoft Corporation||Scale-out system to acquire event data|
|US8970400||Jan 30, 2012||Mar 3, 2015||Verna Ip Holdings, Llc||Unmanned vehicle civil communications systems and methods|
|US9208476||Oct 21, 2011||Dec 8, 2015||Microsoft Technology Licensing, Llc||Counting and resetting broadcast system badge counters|
|US20090063301 *||Sep 4, 2007||Mar 5, 2009||Alan Ward||Digital Asset Delivery to Different Devices|
|US20100250643 *||Mar 26, 2009||Sep 30, 2010||Microsoft Corporation||Platform for Societal Networking|
|US20120233031 *||Jun 28, 2011||Sep 13, 2012||Chang Christopher B||Intelligent Delivery and Acquisition of Digital Assets|
|US20150067062 *||Sep 9, 2014||Mar 5, 2015||Apple Inc.||Message push notification client improvements for multi-user devices|
|U.S. Classification||705/500, 709/218, 705/14.66, 707/999.003, 705/26.61|
|International Classification||G06Q30/00, G06F17/00, G06Q90/00|
|Cooperative Classification||G06Q30/0623, G06Q99/00, G06Q30/06, Y10S707/99933, G06Q30/0269|
|European Classification||G06Q30/06, G06Q30/0269, G06Q30/0623, G06Q99/00|