Patent Application
20080004980
In the following detailed description of embodiments of the invention, reference is made to the accompanying drawings in which like references indicate similar elements, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, mechanical, electrical, functional, and other changes may be made without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.
As an example of the invitation and certification process, if a supplier is invited by a customer of the service supplier, but the service supplier does not see fit to open up the supplier to broader access to the service supplier customer base, then the supplier can be certified to transact with just that one customer until they make needed improvements to their processes, technology, financial condition or other aspects of their business. Once the supplier makes necessary changes, they can re-apply for broader certification. Certification requests can be limited to n number within a time period or n days between certification requests.
Once the supplier registers itself into the network, tools would be provided to the supplier. The collaboration toolkit would provide a way for the supplier to interact in an automated way with the service supplier and its customers for setting up meetings, viewing each other's calendars, sending emails, accessing private and public address books and collaborating on the setup process for the customer-service supplier-supplier connection.
Another tool would be a set of SBL documents and a supplier portal that allows transactions to flow from customer through the service supplier to supplier and back. These SBL documents are covered in a separate patent application, but the general idea is that they are a predefined set of XML documents used as a communication mechanism for transactions. These documents contain a general wrapper for service transactions but can be customized for each industry, application or document type.
The transactional part of the supplier portal would allow the supplier to interact with the service supplier in a fully automated or partially automated manner. For example, a partially automated process would include a structured email that is sent to the supplier each time a customer wants to make a reservation request. The supplier is given n minutes to respond to the request before it is rescinded. If the supplier wishes, he can set auto-respond rules in his transaction portal that allow him to accept or decline, or request more information for these transactions.
Mapping of transaction data between customers and suppliers can be done in an easier manner through the service supplier. A best-match algorithm would allow a best-guess approximation of a mapping for all fields in an application document. For example, the set of temporary worker job titles varies widely among corporate customers and suppliers of temporary workers. There is no standard, agreed-upon taxonomy for this mapping. Therefore, a best-match algorithm that is based on such things as natural language parsing, a pre-built standard taxonomy and other technologies would reduce the amount of time needed to do this mapping.
All suppliers that are in the service supplier platform would plug into a generalized reporting and data analytics engine that would allow end users to see how the supplier has been performing. For example, a user may query the engine, “What was the average response time?” This function can be provided anonymously using aggregate data collected across customers the service supplier Platform will also monitor the service levels—the amount of time required to process a request—for the providers to ensure that they meet the agreed upon Service Level Agreements (SLAs). The supplier can sign up for automated alerts from the system when their Service Levels drop to configured thresholds.
Customers could rate the suppliers based on their interaction and these reviews would be available to the end customer before they select a supplier.
In step 203, an invitation is extended to the service provider to apply for certification in the network, and in step 204, the process branches, depending on whether the service provider accepts or declines the invitation. If the service provider declines the invitation, then in step 205, the recommending customer is notified, and in step 206, the process terminates. If the service provider accepts the invitation, then in step 210, the service provider specifies a working mode, such as automatic acceptance, require notification, manual decision, etc. See the description of element 302 in
For example, a limo provider could have a rule set in the service supplier transaction portal that allows him to auto-accept all limo reservations within Manhattan, but alert him when transactions come through for New Jersey so he can decide manually. This could be done by sending him an e-mail or text message (aka SMSmessage), to which he could reply a “yes”, “no” or for example an acceptance password etc. In other cases, the system could launch a voice call, allowing the provider to answer a “yes” or “no” or password in a voice system, further reducing potential problems, as sending e-mail while driving is not just dangerous, but may be illegal in many places. The rules mentioned above could be used to set pricing terms, geographic and time of day terms etc. In another example, a catering company could set a rule that auto-adds a $20 surcharge for all orders placed for delivery before 7 am.
The system would, on the request of the service provider, analyze past transactions that the supplier has approved/declined to build a predictive model, perhaps build on a decision tree or clustering or similar technologies, and make a recommendation to the supplier to embed as automatic approval/decline filters. The service provider will be able to do what-if analysis on the predictive model before accepting/declining it.
In yet other cases, instead of filters, check boxes or scripts might be used to allow a service provider to configure and customize his RSVP functionality. Though most advantageous for small suppliers in this example, in other cases, it may also be used for larger suppliers. For example, rules may be entered allowing a request to be routed to a specific driver of a larger limo company, based on GPS information and availability of those drivers, etc.
In yet another case, the service provider would be able to post to service supplier platform discounted inventory, that the service supplier could through its network offer it to potential users who may be interested in last-minute discounted services. For example a caterer could offer discounted food after a last minute cancellation, or a limo driver could offer a discounted ride to fill an empty return from the airport etc. Using certain rules and filters, certain customers, that for example registered in some cases, could be notified of such a short term opportunity becoming available, similar to co-pending case U.S. patent application Ser. No. 10/869,356, entitled, “SYSTEM AND METHOD FOR AVAILABILITY-BASED LIMITED-TIME OFFERINGS AND TRANSACTIONS,” filed Jun. 15, 2004, incorporated herein by reference.
For example, in one embodiment, the method of the present invention may lower an identified capacity of the first service provider in response to receiving a number of complaints greater than or equal to a threshold, within a predetermined period of time. In one embodiment, the method of the present invention may raise an identified capacity of the first service provider in response to receiving a number of compliments or positive reviews, greater than or equal to a threshold, within a predetermined period of time. In one embodiment, the method of the present invention may raise an identified capacity of the first service provider in response to receiving a number of complaints less than or equal to a threshold, within a predetermined period of time.
At least some embodiments, and the different structure and functional elements described herein, can be implemented using hardware, firmware, programs of instruction, or combinations of hardware, firmware, and programs of instructions.
In general, routines executed to implement the embodiments can be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as “computer programs.” The computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations to execute elements involving the various aspects.
While some embodiments have been described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that various embodiments are capable of being distributed as a program product in a variety of forms and are capable of being applied regardless of the particular type of machine or computer-readable media used to actually effect the distribution.
Examples of computer-readable media include but are not limited to recordable and non-recordable type media such as volatile and non-volatile memory devices, read only memory (ROM), random access memory (RAM), flash memory devices, floppy and other removable disks, magnetic disk storage media, optical storage media (e.g., Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks, (DVDs), etc.), among others. The instructions can be embodied in digital and analog communication links for electrical, optical, acoustical or other forms of propagated signals, such as carrier waves, infrared signals, digital signals, etc.
A machine readable medium can be used to store software and data which when executed by a data processing system causes the system to perform various methods. The executable software and data can be stored in various places including for example ROM, volatile RAM, non-volatile memory and/or cache. Portions of this software and/or data can be stored in any one of these storage devices.
In general, a machine readable medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.).
Some aspects can be embodied, at least in part, in software. That is, the techniques can be carried out in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM, volatile RAM, non-volatile memory, cache, magnetic and optical disks, or a remote storage device. Further, the instructions can be downloaded into a computing device over a data network in a form of compiled and linked version.
Alternatively, the logic to perform the processes as discussed above could be implemented in additional computer and/or machine readable media, such as discrete hardware components as large-scale integrated circuits (LSI's), application-specific integrated circuits (ASIC's), or firmware such as electrically erasable programmable read-only memory (EEPROM's).
In various embodiments, hardwired circuitry can be used in combination with software instructions to implement the embodiments. Thus, the techniques are not limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system.
In this description, various functions and operations are described as being performed by or caused by software code to simplify description. However, those skilled in the art will recognize what is meant by such expressions is that the functions result from execution of the code by a processor, such as a microprocessor.
Although some of the drawings illustrate a number of operations in a particular order, operations which are not order dependent can be reordered and other operations can be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be apparent to those of ordinary skill in the art and so do not present an exhaustive list of alternatives. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software or any combination thereof.
In the foregoing specification, the disclosure has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications can be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
The supplier regulator would include a mechanism that provides real time visibility to the status of suppliers so that we can monitor suppliers that are approaching the limit of their capacity or who may have already exceeded their capacity, or who are experiencing an outage of some kind. It would also maintain a record of historical performance that could be charted. Ideally, this would have some sort of user interface that displays the status of all vendors. It could also generate some type of automated alert as the supplier is reaching their capacity or if they are in a state where they have exceeded or cannot meet their capacity. This could include an email, phone call, text message or other electronic communication.
