Patent Application
20140289074
The present invention relates to systems and methods of selecting a provider or providers—enhanced by micro-casting techniques—to proffer to a seeker from a plurality of providers of an urgent good(s) or service(s) requested by the seeker.
There are times when we travel—or even when we are close to home—that we have a near-emergency need for services and/or goods. Let's call such ‘really-need-to-have-now’ services and goods: Urgently Required Goods and/or Services (“URGS”).
An URGS fulfillment system is quite different from the typical consumer fulfillment system that aims to sell a consumer a stocked or orderable commodity. A “Seeker” in search of URGS is often in pain or under the pressure of some distress and therefore is much more likely to be harder to please, and also much more easy to alienate than say an on-line shopper looking for the best price for a book. A Seeker who is in pain or other distress may be much less forgiving of a fulfillment system that is hard to use, slow to respond, or produces poor or no results.
Additionally, although the URGS fulfillment system may be automated, the URGS fulfillment process may typically involve real-time ‘live’ participation of “users”—i.e., a human Seeker and one or more human providers of URGS (“Providers”). The Seeker, and also the URGS Providers who may be proffered to the Seeker, each have physical, emotional and other requirements that the URGS fulfillment system may be expected by the users to satisfy. Such physical, emotional and other requirements may change over time for a given user, especially for a Seeker. Adaptation to such changes by the URGS fulfillment system may be experienced favorably by users, whereas not adapting accordingly may be experienced less favorably. For example, a Provider may turn down several Seeker requests for URGS in a row and explicitly indicate availability status is ‘not available’. A suitably adaptive URGS fulfillment system may interpret such actions to indicate that that Provider is adamant about being unavailable rather than perhaps having time for maybe just one more client.
There may be a significant asymmetry between the requirements, expectations and time-of-use temperaments of Seekers and Providers. Unlike a typically distressed Seeker, most Providers are more calmly focused on longer term results. To a Provider, a Seeker's URGS request may be considered as a good business opportunity—or an annoying distraction—based on the Provider's circumstance at the time.
It is therefore apparent that an urgent need exists for systems and methods for an URGS fulfillment system to satisfactorily meet the requirements of both Seeker and corresponding Provider(s) in the process of fulfilling the Seeker's URGS need(s). A micro-casting distributed URGS fulfillment (“MCDUF”) system may therefore serve a need that is fundamental and undeniable by providing an URGS fulfillment system that is adaptively responsive to the changing physical, emotional and other requirements of users—both Seekers and Providers—in the process of fulfilling the Seeker's URGS need(s).
To achieve the foregoing and in accordance with the present invention, systems and methods for matching seekers to providers of urgent goods and services is provided. In particular the systems and methods for screening and proffering a plurality of providers of an urgent service or goods requested by a seeker is provided.
In one embodiment, a computerized multi-casting distributed urgent goods and services fulfillment system is configured to triage a plurality of providers with respect to an urgent need for one or more goods and/or services of a seeker thereby generating a current seeker-adaptive micro-casting triaged provider pool, and further configured to successively proffer an adjustable portion of the current micro-casting triaged provider pool to the seeker
The fulfillment system may also be configured to determine the suitability of each of the plurality of providers in response to a seeker selected Urgently Required Goods and Service (“URGS”) category, to determine the proximity of each of the plurality of providers, wherein the proximity includes temporal and/or physical proximity, and also to determine the availability of each of the plurality of providers, wherein availability is determined from corresponding explicit provider schedule(s) and/or supplemental availability characteristic(s).
In some embodiments, the fulfillment system creates the URGS category in anticipation of the urgent need, and also individually pre-vets the plurality of providers, wherein the pre-vetting each of the plurality of providers includes qualifying and/or ongoing evaluation with respect to the URGS category.
Note that the various features of the present invention described above may be practiced alone or in combination. These and other features of the present invention will be described in more detail below in the detailed description of the invention and in conjunction with the following figures.
In order that the present invention may be more clearly ascertained, some embodiments will now be described, by way of example, with reference to the accompanying drawings, in which:
The present invention is described in detail with reference to selected preferred embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It is apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known technologies—such as World Wide Web operation, functionality of Internet-enabled mobile communication devices such as “smart phones”, and/or device-centric graphic user display techniques—have not been described in detail in order to not unnecessarily obscure the present invention. The features and advantages of the present invention may be better understood with reference to the drawings and discussions that follow.
Aspects, features and advantages of exemplary embodiments of the present invention will become better understood with regard to the following description in connection with the accompanying drawing(s). It should be apparent to those skilled in the art that the described embodiments of the present invention provided herein are illustrative only and not limiting, having been presented by way of example only. All features disclosed in this description may be replaced by alternative features serving the same or similar purpose, unless expressly stated otherwise. Therefore, numerous other embodiments of the modifications thereof are contemplated as falling within the scope of the present invention as defined herein and equivalents thereto. Hence, use of absolute and/or sequential terms, such as, for example, “will,” “will not,” “shall,” “shall not,” “must,” “must not,” “first,” “initially,” “next,” “subsequently,” “before,” “after,” “lastly,” and “finally,” are not meant to limit the scope of the present invention as the embodiments disclosed herein are merely exemplary.
The present invention relates generally to systems and methods for manipulating and utilizing data in a database or databases accessed over wide area networks (WANs) via any of a wide assortment of electronic network terminal devices. In particular, the present invention is directed to novel methods and systems to enable consumers with urgent needs (“Seekers”) to expeditiously locate, evaluate and acquire services and goods using devices such as, but not limited to, mobile communication devices; and for the vendors (“Providers”) of such urgently required good(s) and/or service(s) (“URGS”) to electronically offer them through a centralized enhanced automated directory service and to respond to Seekers requests for URGS via any of a wide assortment of electronic network terminal devices.
Of note is that, in the remainder of this application, particular attention is placed upon visual displays on a mobile communication device. It is important to realize that the present invention may apply equally well to operation with all manner of consumer electronic network terminal devices including, but not limited to, computers, tablet computer systems, e-reader devices, and virtually any electronic device which includes WAN access and a user interface. In addition, while examples of a visual interface are described in great detail, the present invention is entirely capable of operation with a wide range of interface types, including any combination of a visual display, tactile and audio output and a visual, tactile or acoustic user interface (UI). And although the present invention may utilize the PSTN for communication between Seeker and Provider, it may equally well utilize equivalent communication over other WANs using services such as, but not limited to, VoIP and Skype.
The present application for letters patent describes a directory, request processing and fulfillment agent system which interposes between database(s) and the user interfaces of electronic network terminal devices in such a way as to bring Seekers and Providers of URGS together virtually and/or physically in a timely fashion.
The present invention enables a Provider to adaptably conduct commercial activities such as: to advertise and offer URGS, detail the type of URGS provided, accumulate independent third-party assessments and reviews, display credentials, leverage the draw of a centralized need-targeted electronic directory, offer informative mini-tutorials and FAQs, update and display availability status, prequalify prospective Seeker customers, provide repeatable direct Seeker-Provider communication, arrange for commercial transactions, facilitate and track progress towards consummating commercial transactions, consummate commercial transactions for URGS and possibly other service(s) and/or good(s) with Seekers, follow-up post-transaction with Seekers to encourage and enhance good-will, and measure and evaluate the effectiveness of the foregoing and make adjustments and refinements.
Additionally, the present invention enables a unified adaptable facility for a Seeker to prequalify, locate, evaluate, make repeatable contact with, and acquire URGS from, one or several Providers.
Although at first consideration, the present invention may have some resemblance to generic search engines such as Google, it is much different in operation, function and result. Unlike a generic search engine, it uses a great deal of specificity—including Seeker- and Provider—sourced Profiles—in selecting a usably small set of well qualified results. Furthermore, it provides a much richer service that is tailored to urgent requirement fulfillment. When using a generic search engine, a user is generally anonymous and the user's motivations not apparent, and therefore the results provided are often voluminous, non-applicable, poorly differentiated, commonly misranked and generally of little or no use. The present invention on the other hand—based in part on information provided by a given Seeker specifically for this purpose—may pre-authenticate, validate, rank and otherwise screen Providers before responding with a vetted set of Providers in reply to that Seeker's specific request.
The services of the Fulfillment System 2700 are provided by the Fulfillment Server(s) 155, which utilize one or more Database(s) 158 containing information about users who can utilize the Fulfillment System 2700 either as a Seeker or as a Provider. This distinction of two separate types of users does not prevent a user who is a Provider from also separately using the System 2700 as a Seeker; nor does it prevent a Seeker from separately using the System 2700 as a Provider. When describing use of the Fulfillment System 2700 that is equivalent whether by a Seeker or by a Provider, the term “User” is used to mean either of these two types of users.
Seeker terminal choices, 110 through 119, represent the multiplicity of devices that can support access to the Fulfillment System 150. Often these terminals are mobile communication devices—i.e., devices that can be carried easily from place to place by the Seeker—typically with Wi-Fi or cellular data or other wireless connectivity and in numerous instances with built-in mobile telephone capability. However, less portable or fixed installation terminals may also support access to the Fulfillment System 150.
Provider terminal choices, 190 through 199, mirror the choices available to a Seeker. They differ specifically in the role of the User, i.e., Provider rather than Seeker, and the specific device chosen by each individual User. So for instance a given Seeker may use a “smart phone” mobile communication device, 110, whereas a Provider may use a desktop computer, 199.
In some embodiments, a Seeker or Provider's use of the Fulfillment System 150 is not bound to a specific terminal device, so for instance a Seeker could initially access the Fulfillment System 150 using a laptop computer, say from home, and subsequently use the Fulfillment System 150 with a tablet computer, while traveling in a car.
In some instances, a User's electronic network terminal device that is dedicated to providing data access, e.g., a desktop computer, 119/199, may be augmented for telephone communication by a separate telephony device (not shown) and/or third party telephony software (not shown) running on the terminal device. Such separate telephony devices may include, but not be limited to: a mobile cellular phone or a landline telephone, or a headset paired with third party telephony software running on the terminal device, e.g., Skype.
At the level of network connectivity, a Seeker's terminal and a Provider's terminal operate in equivalent ways, therefore for simplicity: the terms “User's” device or “User's” terminal is used when operation of a Fulfillment System 150 feature applies in the same fashion to either a Seeker's terminal or a Provider's terminal device.
Inter-communication between a User's terminal device and the Fulfillment System 150 may use a Wide Area Network (WAN), 140, such as the Internet. Communication between a User and the Fulfillment System 150, or between a Seeker and a Provider, may involve traversing more than one WAN (not shown). In some embodiments, Fulfillment System-facilitated communication between a Seeker and a Provider may also involve a WAN or WANs such as the PSTN and/or the Internet.
The Database(s) 158 used by the Fulfillment System 150 may be centralized or distributed. In some embodiments, the Fulfillment System 150 is coupled to one or more external database(s) 170 via WAN 140.
Generally, the Database 158 used by the Fulfillment System 150 is remote from the User's terminal; however in some embodiments, portions of database(s) used by the System 150 may reside on the User's electronic terminal device (not shown).
Depending on the embodiment, the Fulfillment System 150 may use one or several models of connectivity including, but not limited to: client/server and peer-to-peer. Client/server connectivity may use a WAN such as the Internet for access between the User's terminal device and the Fulfillment System's server(s) 155. Peer-to-peer connectivity, such as a Fulfillment System-facilitated telephone call or text message exchange between a Seeker and a Provider, may typically also use a WAN such as the PSTN or the Internet.
In some embodiments, communication between a Seeker and a Provider may be intermediated by the Fulfillment System 150. In such intermediation—sometimes referred to as “proxying”—the System 150 may source, receive, reroute, multicast, broadcast or otherwise initiate or respond to and/or terminate communication: from a Seeker (or on a Seeker's behalf) intended for a Provider, and/or; from a Provider (or on a Provider's behalf) intended for a Seeker. In addition, the System 150, may translate, clarify, expand, simplify, repeat, and/or generally modify or enhance the content communicated between Users in such a way as to improve or enhance comprehension or to increase the likelihood of successful completion of the communication. Such intermediation services may have varying mixes of automation and/or direct human participation depending on the embodiment.
Additionally, the Fulfillment System 150 may translate, clarify, expand, simplify and otherwise modify or enhance what is communicated. At a signal content level, the System 150 may amplify, filter, encode, decode, transcode, compress, expand, error correct and generally process the signal corresponding to the communication in ways well understood to one well versed in the art.
In some embodiments, voice communication may be intermediated by the Fulfillment System 150 in such a way that the telephone number(s) nominally routed directly to a User are actually directed to and/or are routed by the System 150. For example, the Fulfillment System 150 may provide additional services to a Provider or on a Provider's behalf including, but not limited to: PBX services including call routing/forwarding, call attendance, voice mail, call center and client notifications by outgoing call.
In some embodiments, data communication may be intermediated by the Fulfillment System 150 in such a way that logical network addresses—e.g., web site URLs and email addresses—nominally routed directly to a User are actually routed to and/or sourced from and/or redirected by the System 150. For example, the Fulfillment System 150 may provide additional services to a Provider or on a Provider's behalf including, but not limited to: Web site, email, blog, on-line forum/social network posts, electronic newsletters, and push notifications to clients.
In some embodiments, text messaging communication may be intermediated by the Fulfillment System 150 in such a way that logical texting addresses—e.g., Universal Resource Identifiers—nominally routed directly to a User are actually routed to and/or sourced by and/or redirected by and/or translated by the System 150. For example, the Fulfillment System 150 may provide additional services to a Provider or on a Provider's behalf including, but not limited to: text-email translation, text-voice translation, system-to-system gateway (e.g., between SMS and IM) and push text messaging notifications to clients.
A number of third parties, such as Better Business Bureau, Chamber of Commerce, professional/trade organizations and consumer rating sites—e.g., Angie's List and 1800Dentist—maintain large databases describing service vendors. In some embodiments, the Fulfillment System 150 may use data from such third party databases and/or from Users' terminal devices. Hence, Seekers have access to a very wide variety of Providers listed in a virtual aggregate database or virtual composite database comprised of Database 158 plus data accessed or acquired from third parties plus data stored on or acquired from Users' terminal devices. For simplicity in the following description, we refer to representative Database 158.
A large number of third parties, such as telephone companies, business journals, professional associations, and business directory companies—e.g., yp.com—maintain directories of service vendors as a business. In some embodiments, the Fulfillment System 150 may redirect certain Seekers to third party directory sites; or the System 150 may display contents from third party sites to Seekers. Motivations to do so may include, but not be limited to: Seeker requires non-urgent service, the third party pays for referrals, no suitable Providers are found in the Database 158 for the URGS the Seeker requires.
Elemental to the operation of the Fulfillment System 150 is User-descriptive data entered into the Database 158 voluntarily by Seekers and Providers themselves. In some embodiments, this data may be augmented with data from third parties, which may be copied or simply utilized on a one-time basis. Such User-descriptive data for a given User may be referred to as a “Profile” or for multiple Users or in aggregate—“Profiles”.
Profiles may be stored in Database 158 and can be organized, portioned, sorted, encrypted, firewalled, access-restricted, backed-up, transaction logged and otherwise managed, maintained and protected using techniques familiar to one skilled in the art.
In general, industry best practices are applied so as to comply with any legal mandates, regulatory requirements, or industry consensus on the protection of private, sensitive and proprietary information or otherwise privileged information. So for instance when a Profile includes or the System 150 accesses a User's medical records, appropriate HIPPA standards are complied with. Encryption may be applied to protect information in the Database 158 and also protect information communicated between Users and the System 150 and/or third parties and the System 150. In many embodiments, encryption may occur as appropriate using technologies familiar to one well versed in the art, such as Secure Sockets Layer (SSL), Transport Layer Security (TLS) and Virtual Private Network (VPN).
In some embodiments, Seekers' Profiles may describe things such as their creditworthiness, their employment, their recent purchases, their property, their health, their physical and work addresses, their phone number(s), their email address(es), and similar descriptive information that may assist in determining whether a given Seeker is someone a given Provider might want to do business with. The Fulfillment System 150 may automatically and transparently vet some Seekers so as to preempt a potential match with a Provider. In other instances, portions of a Seeker's Profile may be viewable to a Provider to assist that Provider in deciding whether to do business with a given Seeker.
In the case of Providers, their Profiles may describe details such as their qualifications and specializations, their education and training, their credentials and licenses, their professional memberships and associations, their career histories, their work philosophies, languages they may speak, as well as more prosaic information such as a business address, telephone number and email address.
In a typical embodiment, a User's Profile may specify requirements that User has for transacting commerce with their counterpart User—i.e., a Seeker with a given Provider; and a Provider with a given Seeker. So for instance, a Seeker may indicate what form of payment they wish to have accepted, what awards programs they wish to have credited, what language they prefer to be spoken to them, and other details of how they prefer or require a transaction to be conducted. Similarly, a Provider may indicate what form of payment they are willing to accepted, what awards programs they support, what language(s) they speak, and other details of how they prefer or require a transaction to be conducted.
Sources for information in a User's Profile may include, but are not limited to: the User directly, private records from third parties (possibly with the User's permission), and publicly accessible records. Some Profile information may be placed into the Database 158 and not be updated for indeterminate periods of time. Other Profile information may have a specific “time to live” after which it is either updated or simply deleted. The shortest such “time to live” may be per access. Other Profile information may be sourced from a User or a third party on a per use basis. This may be done for instance because the sources prohibit retaining copies of it, or because there is a need to get the most up-to-date information, e.g., checking criminal records.
Information in a User's Profile may be beneficial or derogatory. The information in a Provider's Profile is generally there for the use of Seekers. Similarly, the information in a Seeker's Profile is generally there for the use of Providers. Consequently, even if a User can enter or view an item of information in their Profile, they may not necessarily be able to alter or delete it.
Some information in a Provider's Profile may be entered by Seekers—typically in the form of ratings. Similarly, a Seeker's Profile may contain information entered by Providers. Additionally, third parties may source some information in a User's Profile. In some instances, such ratings or characterizations may be unsolicited or gathered as part of a follow-up instigated by the Fulfillment System 150.
Profiles for Seekers contain generally different information than, and are commonly kept separate from, Profiles for Providers. In the instance where a User is both a Seeker and (separately) a Provider, the contents of the User's Seeker and Provider Profiles are typically not intermingled. Of course, some User information may be duplicated in both Profiles, for example the User's name.
Some portions of a User's Profile may be used strictly internal to the Fulfillment System 150 or for the purposes of operators of the Fulfillment System and never be visible to any Users—Seeker or Provider—nor utilized on their behalf by the System 150.
Some Seeker Profile information may be visible to a Provider or to the Fulfillment System 150 on a Provider's behalf, but not visible to that Seeker. Similarly, some Provider Profile information may be visible to a Seeker or to the System 150 on a Seeker's behalf, but not visible to that Provider.
Some of the Profile information of a Seeker may be visible to other Seekers. For example, in some embodiments limited Profile information may be viewable via an on-line user forum that is part of the Fulfillment System 150.
A User who is a Provider may conceivably offer several different types of URGS as separate businesses. The Fulfillment System 150 may allow multiple Provider Profiles for such a User, where some of the information in the Profiles is duplicated in each Profile and other information is unique to a Profile specific to the corresponding URGS provided. In some embodiments, such Profiles may be accessed using separate unique accounts.
Referring to
In step 230, the Fulfillment System 150 prepares to proffer a set of potential Providers to the Seeker. Substantial amounts of information about the Seeker and about potential Providers may be retrieved from the Database 158 and utilized by the System 150 to either validate or reject potential pairings of the Seeker to proximate Providers.
As mentioned above, both the Profiles of the Seeker and potential Providers may contain requirements that are mandatory qualifiers as well as other requirements that reflect non-mandatory preferences. Accordingly, some embodiments may apply weightings to Profile preferences and instantiate rankings of potential Providers based on the degree of “acceptability” or “goodness” of a given Provider as determined algorithmically based on Seeker and Provider Profiles, third party ratings, and other external data. In some embodiments, the ranking of potential Providers may be displayed for the Seeker's use (not shown herein) prior to selecting a Provider. A given Provider's ranking may be represented by a color code, icon size, some number of stars, a ranking number, or any of a multiplicity of indicators of relative rank familiar to one skilled in the art. In some embodiments and some instances, there may be more potential Providers than is practical to proffer. In some embodiments, the Fulfillment System 150 may limit the number of potential Providers proffered to a number lower than the total available. In such instances, the ranking of a given Provider—relative to other potential Providers—may determine whether or not that Provider is proffered.
Some of the Profile information of a User may affect other aspects of Fulfillment System 150 operation and use. For example, language preference may cause the System 150 to generate displays in a language suited to the User. A “zooming” feature and/or audio dialog may support the visually impaired. A multiplicity of behaviors—System 150 operation in general and display operation specifically—may be influenced by User Profile preference settings.
As shown in step 320 of
Information from the Seeker's Profile may include preferences that affect how the Seeker's Locale is determined. In many embodiments, the Fulfillment System 150 displays information reflecting the Fulfillment System 150's calculation of the Seeker's Locale (not shown)—allowing the Seeker to determine if the Fulfillment System 150 has made a mistake in attempting to establish a Locale for the Seeker.
Having ascribed a Locale to the Seeker, in Step 330 the Fulfillment System 150 processes the Database 158 to identify proximate Provider(s) of the URGS sought by the Seeker. Proximity typically involves measuring between locations. As relates to URGS fulfillment, those locations commonly correspond to the Seeker's Locale and to the Provider's Locale. Where the Seeker's Locale or a given Provider's Locale may be ascertained to be—for the purpose of determining proximity—can depend on a number of factors. In some instances, determination of proximity may be affected by preferences in the Seeker's Profile in the Database 158 and/or in a given Provider's Profile in the Database 158. For example, a given Provider's Profile preference may require the rendezvous location and/or the Seeker's Locale to lie within a specific region or territory based on the strictures of a License or Certificate or third party permission issued to that Provider. If that preference is not met, the Provider is determined by the Fulfillment System 150 to not be proximate to the Seeker.
Proximity may also have temporal determining factors. For instance, a potential Provider may be relatively near a Seeker, but have prior commitments that must be seen to first. Or for example, bad traffic may slow the time it takes to travel to a rendezvous location. In an urgent situation, temporal proximity may be more important than physical proximity. In many embodiments, the Fulfillment System 150 may ascribe proximity to a given Provider based on a multiplicity of temporal-related factors including, but not limited to: projected travel route, third party traffic congestion and weather reports, historical traffic patterns and records, and Provider promptness ratings. In some instances, factors impacting temporal proximity may not be apparent to the System 150 such that communication between the Seeker and a Potential Provider may indicate a different—perhaps less attractive—temporal proximity.
For the purposes of Step 330, the Provider's Locale may be ascribed in a number of different ways depending on numerous factors including but not limited to: the type of URGS provided; whether the acquisition of the URGS requires the actual physical presence of the Provider and/or of the Seeker; whether the Provider operates from a fixed business location; and/or whether it is necessary for the Provider to travel to provide the URGS. So for instance, the Provider's Locale may be taken to be the Provider's place of business as defined by the Provider's Profile in the Database 158. Or the Provider's Locale may be taken to be the expected location of the Provider based on a schedule defined by the Provider's Profile in the Database 158. Or the Provider's Locale may be taken as a geo-location provided by the Provider or by a mobile communication device in the Provider's possession. Information from the Provider's Profile may include preferences that affect how the Provider's Locale is determined.
In many embodiments, the information: URGS sought, Seeker's Locale, and each Provider's availability and Locale is deemed sufficient to allow the Fulfillment System 150 to process the Database 158 to identify proximate Provider(s) of the sought after URGS—see 330.
In many embodiments, additional winnowing of the set of potential Provider's may occur based on additional preferences a Seeker has indicated in their Profile and/or additional preferences a given Provider has in theirs—reference 340.
In some embodiments, the Fulfillment System 150 may attempt to winnow down the set of potential Providers. In 350, the Fulfillment System 150 may present the resulting set of potential Providers to the Seeker. In some embodiments, the System 150 may modulate the winnowing process so as to proffer at least two potential Providers.
In some embodiments, the set of potential Providers is displayed on a map that shows their approximate Locales and their relative proximity to the Seeker—see
Referring to 240—the Seeker typically selects one of the Providers proffered by the Fulfillment System 150.
The response by the Fulfillment System 150 to the Seeker's selection of a URGS Provider may vary between embodiments, but also in some instances, within a given embodiment based on the Provider's Profile.
A Seeker's selection of an URGS Provider—see 510—may be acknowledged by the Fulfillment System 150—reference 520—so the Seeker knows the Fulfillment System 150 has recorded the correct selection.
Referring to 525, a confirmation ID may be assigned that may be used subsequently to look up a record of the Seeker-Provider match that is stored in the Transaction Log—see 530.
In some embodiments, the Fulfillment System 150 may attempt—on behalf of the Provider—to pre-qualify the Seeker's ability to pay by running a test charge for a pre-set amount—typically a minimum payment—against the Seeker's payment card, insurance payer, or other payment source—see 535. Referencing 540, the Fulfillment System 150 may query the payment source for pre-approval.
In such embodiments, if the test charge is rejected by the payer, the Provider's Profile may be checked to see if the Provider accepts Seekers with potential payment problems—see 550. If not, the Fulfillment System 150 may inform the Seeker of denial—see 590—typically causing the Seeker to select a different potential Provider.
If on the other hand, the Seeker's payment source can pay, or the Provider accepts Seekers with potential payment problems, appropriate data about the Seeker—see 560—may be made available for the Provider and notification of the selection sent to the Provider—see 570—and a corresponding confirmation to the Seeker—see 580.
In some embodiments, the Fulfillment System 150 offers the Seeker the opportunity to initiate contact with the selected Provider immediately—
In most embodiments, particularly those where the Seeker contacts the Provider to complete the transaction, the Fulfillment System 150 acts to notify the Provider promptly of the selection—
To assist both the Seeker and the Provider, the Fulfillment System 150 may provide a tracking service—see 260—and corresponding map-based display mechanism that periodically updates, substantially in real-time, the geo-location of the traveler(s)—be it the Seeker, the Provider, or both—relative to the rendezvous location where the Seeker and Provider intend to transact the acquisition of the URGS. In some embodiments, tracking maps are made available for both the Seeker—
In some instances, where the URGS are a good or goods, it may be the good(s) traveling and the tracking map reflecting the current Locale of the good(s). In some instances, the URGS may be provided by ways that are not well suited to tracking on a map, e.g., funds may be wired electronically with seeming instantaneous travel.
The Fulfillment System 150 may utilize an internal set of identifiers and transaction records in the process of matching Seekers to Providers for the purpose of acquiring URGS. In a typical embodiment, a stored set of records is retained in the Database 158 (“Transaction Log”) that records the details of each such process.
Operators of the Fulfillment System may derive revenue or other recompense—from Seekers and/or Providers and/or third parties—for use of the System 150 and/or use of information accumulated in the Database 158. Information stored in the Transaction Log may serve to determine what recompense is appropriate and from whom. It may be used for instance, to provide details that may appear in an invoice. Such details may for example include transaction information representing a “billable moment”—e.g., when a valued service—such as facilitating a Seeker to contact a Provider—instantiated and correspondingly recorded in the Transaction Log.
In addition to maintaining Transaction Logs, in some embodiments, the Fulfillment System 150 may maintain in its Database 158 algorithmic manipulations of various log data (“Metrics”) for a single User or several Users individually or a set of Users as an aggregate—where a given User may be a Provider, or a Seeker, or both a Provider and a Seeker (dual use of Fulfillment System 150). Such data may be measurements, statistics, and correlations for an individual Provider, or Providers as individuals, or Providers as an aggregate, and/or Multiple Providers.
In addition to maintaining Transaction Logs, and Metrics, in some embodiments the Fulfillment System 150 may keep stored copies (as permissible) or aggregations of any information—from or about Users or third parties—that enters the Fulfillment System 150. This information may at some time be manipulated to derive useful data that may be of value to operators of the Fulfillment System, Fulfillment System Users, or third parties.
For most Providers, a key goal of providing URGS is to be compensated. In many instances a Seeker may contemplate using the Provider again, and therefore want the Provider to be pleased with being compensated. Also—for both a Seeker and a Provider—having a record of having transacted the requisite compensation is useful in case of a dispute, or more in general, to maintain good credit histories.
The Fulfillment System 150 may facilitate the compensation of Providers—270. In some embodiments, the Fulfillment System 150 provides a basic service to the Provider—access to a reproduction of the Transaction Log record reflecting the pairing of the Provider and the Seeker.
In some embodiments, the Provider may enter additional information into the Transaction Log to record the status of the transaction with the Seeker and the status of the corresponding compensation by the Seeker. Such information may include third party confirmation of compensation of the Provider by the Seeker. In some instances, such information may be provided to the Fulfillment System 150 directly from authoritative third parties.
Some embodiments may provide broader facilitation to a Provider such as Appointments, Billing and Accounting.
In some embodiments, a Seeker has access to a record of Provider searches and pairings conducted by the Fulfillment System 150 on behalf of the Seeker. Furthermore, in some embodiments, a Seeker may have access to a record of other related transactions conducted by the Fulfillment System 150 on behalf of the Seeker.
Facilitating follow-up between Seekers and their Providers—see 280—is another utilization of the Transaction Log. For instance, the Fulfillment System 150 may communicate instructions from a selected Provider to the corresponding Seeker. In the opposite direction, the System 150 may communicate feedback from a Seeker to a Provider selected by that Seeker. Additionally, in some embodiments, the System 150 may obtain Provider ratings from Seekers and Seeker ratings from Providers and add these to User metrics in the Database 158. In some embodiments, positive or negative ratings may cause the System 150 to increase or decrease a given Provider's ranking, which may in turn impact the frequency of that Provider being proffered.
Follow-up with Seekers may be a key component of a Provider's client loyalty program. In some instances, it may generate immediate follow-on transactions. In other instances, it may generate good-will. By facilitating follow-ups, the Fulfillment System 150 may gain access to the Seeker's opinions, and help increase the Seeker's loyalty to the Provider. A side benefit may be increased loyalty of both the Seeker and the Provider to the Fulfillment System 150.
In addition to direct follow-up, the System 150, may provide, support, be affiliated with, link to, direct Users to, or otherwise facilitate follow-up via user forums/social media. Many consumers use social media such as Yelp, Facebook and Twitter to express their praise and/or criticisms regarding a vendor.
The Fulfillment System 150 facilitates Loyaltization—i.e., creating, maintaining, promoting and expanding User loyalty to the Fulfillment System 150—focused on both Providers and Seekers—see 290. Loyaltization may play an important role in the commercial acceptance and success of the Fulfillment System 150.
Loyalty may be created as a byproduct of the inherent usefulness of the Fulfillment System 150, but in some embodiments loyalty may be actively sought—using additional features and incentives—to make Providers and Seekers want to recommend the Fulfillment System 150 to others and continue using it themselves. For example, the System 150 may increase the ranking of a valued Provider and thereby increase the likelihood and frequency of that Provider being proffered. Additionally, in some embodiments, the System 150 may improve other metrics associated with a valued Seeker or Provider. Such metrics might be shared for instance with other Users and/or third parties.
In some embodiments, the Fulfillment System 150 may administer loyalty programs on the behalf of individual Providers. Additionally, the Fulfillment System 150 may operate loyalty programs on behalf of an aggregate of multiple Providers and offer incentives to Seekers based on desired behavior relative to any Provider within said aggregation. Such loyalty programs conducted on behalf of Providers also have the benefit of Loyaltization of Providers to the Fulfillment System 150. Similarly, in some embodiments, the System 150 may administer loyalty programs—on behalf of individual Seekers or Seekers in aggregate—that reward Providers and increase good-will between Providers and Seekers and perhaps the System 150 as well. Loyalty programs, whether on behalf of Seekers or Providers, may award benefits to Users—for example discounts for future URGS acquired using the System 150 or rewards such as goods and/or services from Providers and/or third parties. For instance, rewards may include airline frequent flier miles or hotel stay points. Also, in some embodiments, the System 150 may offer enrollment in third party loyalty programs.
In many urgent situations, a Seeker may have need for more than one URGS. For example, a vacationer with a broken down car may need a place to stay overnight in addition to automotive repair. If the car is seriously damaged, a rental vehicle may be needed. In typical embodiments, the Fulfillment System 150 may proactively facilitate the proffering of a set of related URGS based on Seeker-provided information and/or inference by the System 150. In some embodiments, the System 150 may facilitate the proffering of non-urgent services and goods that might be useful in the context of the Seeker's circumstances. For instance, the stranded traveler might like a book or newspaper to read or perhaps some comfort food—once the car and a place to stay have been taken care of. A Seeker's Profile may determine whether and how the System 150 proffers, suggests or recommends additional services and goods.
In addition to directly facilitating the Seeker's acquisition of a set of circumstance-related URGS and non-urgent services and goods—in some embodiments—the Fulfillment System 150, may suggest, recommend or otherwise prompt a Provider to proffer additional URGS and other non-urgent services and goods to a Seeker.
The following discussions and references to figures are provided to illustrate a set of exemplary scenarios for some embodiments of the Fulfillment System 150. The examples may include particular limitations which are unique to the given example and are not intended to extend to the invention as a whole. Likewise, some examples may have been simplified in order to aid in clarity. It is understood that while the foregoing examples aid in explanation and clarification of the present invention, these examples do not limit the scope or function of the present invention.
In some instances, graphic representations with the appearance of screenshots from mobile communication devices are provided by way of example to aid in the illustration of some embodiments. This is not intended to imply that mobile communication devices are preferred to the exclusion of other terminal device types.
Several different fulfillment scenarios may occur when a Seeker and Provider are not situated at the same place. Such scenarios include, but are not necessarily limited to:
The scenario descriptions that follow detail the individual Scenarios—A, B, C and D—by stepping through the logic flow diagrams—
To illustrate the scenario of a Seeker traveling to the Provider's Locale, the Seeker is imagined to be a business traveler from Spain—Mirabella Sanchez—who has a severe toothache; the URGS is urgent dental care; and the URGS Providers are dentists. Referring back to
Referring to
In step 320, the Fulfillment System 150 determines the Seeker's Locale. In this example, the Seeker is imagined to use a “smart phone” mobile communication device, which allows the Fulfillment System 150 to use GPS to geo-locate the Seeker, who at the time is in San Ramon, Calif.
Referencing step 330, the Fulfillment System 150 examines its Database 158 and determines that the corresponding type of Provider sought is: a dentist. In this example, the Fulfillment System 150 uses the dentist office location specified in each Provider's Profile in the Database 158 as that Provider's Locale. Each Provider's Locale, so determined, is compared to the Seeker's Locale—San Ramon in this example—to determine if a given Provider is proximate. A set of proximate Providers is accumulated in this fashion by the Fulfillment System 150. In this example, the Fulfillment System 150 examines the Database 158 for dentists and identifies eight Providers proximate to San Ramon.
In Step 340, the Fulfillment System 150 further vets the potential Providers.
In Step 460, for each potential Provider, the Provider is vetted based on the Provider's willingness to accept the Seeker based in turn on a comparison of preferences—preset by the Provider in the Provider's Profile in the Database 158—against the Seeker's characteristics found in the Seeker's Profile in the Database 158. Two potential Providers have indicated preferences for payment specifically in cash or by pre-approved insurance organization. Mirabella's Seeker Profile indicates that she desires to pay either with V-Pay debit card or by check. Mirabella's Spanish dental insurance does not match the pre-approved insurance payers in these two Provider's Profiles. Therefore, these additional two potential Providers are rejected by the Fulfillment System 150. Three other Providers do accept checks and therefore pass the vetting process.
Referring to step 350, the Fulfillment System 150 has three potential Providers to display to Mirabella, so she can select one from them. One Provider has an office in Berkeley, one has an office in Vallejo, and the third has an office in Walnut Creek.
Referring to
The Fulfillment System 150 can facilitate communication between Seeker and Provider, by either providing contact information for the Provider or—as in this example—providing a facility to contact the Provider directly. In this instance, Mirabella telephones Dr. White by actuating the virtual button 1110 which causes her mobile communication device to place the phone call directly. The Fulfillment System 150 is not a party in the conversation between the Seeker Mirabella and the URGS Provider Dr. White, DDS.
Referring to
Dr. White's mobile communication device rings with the call from Mirabella—Dr. White answers. They discuss Mirabella's tooth and her dental history; go over compensation and any final details necessary to decide whether to meet; and agreeing to do so, set up an appointment for Mirabella.
In step 260, the Fulfillment System 150 initiates ongoing tracking of the progress of the Seeker traveling to meet the Provider. Referring to
In step 270, the Fulfillment System 150 facilitates compensation by logging the transaction that has just occurred whereby Seeker Mirabella Sanchez selected Provider Dr. White. Both Dr. White and Mirabella Sanchez can subsequently look up the Transaction Log record.
Referring to step 280—in this example, Dr. White's Provider Profile in the Database 158 is preset for the Fulfillment System 150 to facilitate follow-ups by alerting Dr. White at a future time to follow-up with a Seeker who has selected him—in this instance with Mirabella Sanchez.
The Fulfillment System 150 facilitates Loyaltization—step 290—as described above.
To illustrate the scenario of a Provider traveling to the Seeker's Locale, the Seeker is imagined to be a high-powered corporate executive just arrived at a major airport and running late for a critically important business meeting—Lee Nelson; the URGS is transportation to meeting location in time for his presentation; and the URGS Providers are helicopter operators. Referring back to
Referring to step 230—the Fulfillment System 150 works to proffer Providers of the type sought by the Seeker.
Referring to
In step 320, the Fulfillment System 150 determines the Seeker's Locale. In this example, the Seeker's Locale is determined by the System 150 via GPS support in his “smart phone” to be Alameda, Calif.
In Step 330, the Fulfillment System 150 examines its Database 158 and determines that the corresponding type of Provider sought is: a helicopter operator. In this example, the Fulfillment System 150 uses the Provider's heliport location specified in each Provider's Profile in the Database 158 as that Provider's Locale. Each Provider's Locale, so determined, is compared to the Seeker's Locale—Alameda—to determine if a given Provider is proximate. A set of proximate Providers is accumulated in this fashion by the Fulfillment System 150. The System 150 examines the Database 158 for helicopter operators and identifies four Providers proximate to Alameda.
Referring to step 340, the Fulfillment System 150 further vets the potential Providers.
In step 460, for each potential Provider, the Provider is vetted based on the Provider's willingness to accept the Seeker. Such willingness is determined by a comparison of preferences—preset by the Provider in the Provider's Profile in the Database 158—against the Seeker's characteristics found in the Seeker's Profile in the Database 158. Lee has sterling credit and five major credit cards. He is acceptable to all of the Providers.
Referring to
In
The Fulfillment System 150 can facilitate communication between Seeker and Provider, by either providing contact information for the Provider or—as in this example—providing a facility to contact the Provider directly. In this instance, Lee telephones Ms. Kelley by actuating the virtual button 1510 which causes his mobile communication device to place the phone call directly. The Fulfillment System 150 is not a party in the conversation between the Seeker Mr. Lee Nelson and the URGS Provider Ms. Chris Kelley—helicopter operator.
Referring to
Ms. Kelley's mobile communication device rings with the call from Lee Nelson—Ms. Kelley answers. They discuss Lee's urgent need for an immediate helicopter ride to Palo Alto; go over compensation and any final details necessary to be certain that Mr. Nelson is at the correct location at the airport in Alameda; and agreeing to the fare, set up to meet at Lee Nelson's Locale in Alameda.
In step 260, the Fulfillment System 150 starts ongoing tracking of the Provider as the Seeker awaits the Provider's arrival. Referring to
In step 270, the Fulfillment System 150 facilitates compensation by logging the transaction that has just occurred whereby Seeker Lee Nelson selected Provider Ms. Kelley—the helicopter operator. Both Ms. Kelley and Lee Nelson may subsequently look up the Transaction Log record.
Referring to step 280—in this example, Ms. Kelley's Provider Profile in the Database 158 is not preset for the Fulfillment System 150 to facilitate follow-ups. However because the Transaction Log record is available to Ms. Kelley, she can follow-up with Lee Nelson if she chooses to do so. In this case she does follow up promptly—step 280—because she would like referrals and hopefully a repeat customer. She subsequently revises her Provider Profile to facilitate follow-ups.
The Fulfillment System 150 facilitates Loyaltization—step 290—as described above.
To illustrate the scenario of a Seeker and a Provider both traveling to a rendezvous location, the Seeker is imagined to be a landlord—Rick Sawyer—who has a leaking pipe at a rental home; the URGS is urgent plumbing repair; and the URGS Providers are plumbers. Referring back to
Referring to
Referring to step 320, the Fulfillment System 150 determines the Seeker's Locale. In this example, the Seeker is not at the location where the URGS need to be provided—i.e., the rental home with the leaking pipe. Rick Sawyer, the Seeker, enters the address of the rental home—located in Cotati, Calif.—into the Fulfillment System 150. The Fulfillment System 150 processes the address to derive a geo-location and puts both the address and the corresponding geo-location into the Database 158 to set the rendezvous location.
At Step 330, the Fulfillment System 150 examines its Database 158 and determines that the corresponding type of Provider sought is: a plumber. In this example, the System 150 uses the plumber business location specified in each Provider's Profile in the Database 158 as that Provider's Locale. Each Provider's Locale is compared to the rendezvous location—Cotati—to determine if a given Provider is proximate. A set of proximate Providers is figured accordingly by the Fulfillment System 150. Processing plumbers in the Database 158, the System 150 identifies ten Providers proximate to Cotati.
Referring to Step 340, the Fulfillment System 150 further vets the potential Providers.
In Step 430, each of the potential Providers is vetted based on a comparison of preferences set by the Seeker in the Seeker's Profile in the Database 158—against a Provider's characteristics set in the Provider's Profile. Rick Sawyer's Seeker Profile indicates that he requires a English-speaking Provider. The Fulfillment System 150 rejects one of the potential Providers because their Profile in the Database 158 does not include English as one of the languages spoken by that plumber. Rick also requires licensed and bonded contractors—all potential Providers comply. Additionally, Rick's Seeker Profile contains a preference for a work guarantee. Two of the potential Providers do not have “work guaranteed” selected in their Profiles, and as a result are rejected by the System 150.
In Step 460, for each potential Provider, the Provider is vetted based on the Provider's willingness to accept the Seeker. That willingness is determined based on a comparison of preferences—the Provider's preferences expressed in the Provider's Profile in the Database 158—against the Seeker's characteristics preset in the Seeker's Profile in the Database. Three potential Providers have indicated preferences for payment specifically in cash. Rick's Seeker Profile reflects his preference to pay by check or credit card—but not cash. Therefore, the Fulfillment System 150 rejects these three additional potential Providers. Four remaining Providers accept check or credit payment—so they pass the vetting process.
Referring to
In
The Fulfillment System 150 can facilitate communication between Seeker and Provider, by either providing contact information for the Provider or—as in this example—providing a facility to contact the Provider directly. In this instance, Rick telephones Mark by actuating the virtual button 1910 which causes his mobile communication device to place the phone call directly. The Fulfillment System 150 is not a party in the conversation between the Seeker Rick and the URGS Provider Mark Walsh.
Referring to
In step 260, the Fulfillment System 150 starts ongoing tracking of the progress of the Provider and/or the Seeker both traveling to meet at the rendezvous location. Referring to
Referring to step 270, the Fulfillment System 150 facilitates compensation by logging the transaction whereby Seeker Rick Sawyer selected Provider Mark Walsh. Both Seeker and Provider can subsequently look up the Transaction Log record. Each can separately associate additional annotation with the Transaction Log. The Seeker and Provider annotations are separate and private to Seeker and Provider, respectively. They have no indication of, or access to, each other's annotations. In this example, Rick makes notes on the verbal guarantee he received from the Provider Mark. Separately, Mark records the details of the work done including time and materials and the amount charged to the Seeker's credit card.
In step 280, the Fulfillment System 150 facilitates follow-up. Mark's Provider Profile in the Database 158 indicates that the Fulfillment System 150 may, at a set number of days subsequent to a given transaction, prompt him to follow-up with the Seeker—in this case Rick Sawyer. The corresponding annotated Transaction Log reminds him of details of his work for the Seeker that are useful in conducting the follow-up. Mark may add further annotation to the Transaction Log to record the results of a given follow-up.
The Fulfillment System 150 facilitates Loyaltization—step 290. Mark has handled a large number of Seeker's URGS requests and has gotten consistently high ratings for quality and promptness. Accordingly, the Fulfillment System 150 improves the weighting in Mark's Provider Profile so as to increase his ranking and therefore likelihood of selection in the future. In some embodiments, the System 150 notifies the Provider of such improvement in weighting/ranking.
Scenario D—Seeker and Provider's Both Travel Until they Converge
To illustrate the scenario of a Seeker and a Provider both traveling towards each other—without a fixed rendezvous location—until they converge, the Seeker is imagined to be a baseball fan—Judy Piper—who has arrived at the stadium with her son Bobby on his birthday, but has tickets for the wrong day; the URGS are two tickets for today's baseball game; and the URGS Providers are same-day ticket sellers.
Referring to
Referring to step 320, the Fulfillment System 150 determines the Seeker's Locale. In this example, the Seeker is in the North parking lot of the baseball stadium as geo-located by her “smart phone.”
At Step 330, the Fulfillment System 150 examines its Database 158 and determines that the corresponding type of Provider sought is: a same-day ticket seller. In this example, the Fulfillment System 150 uses the geo-location determined from a given Provider's “smart phone” to determine that Provider's Locale.
Each Provider's Locale is compared to the Seeker's Locale to determine if a given Provider is proximate. A set of proximate Providers is figured accordingly by the Fulfillment System 150. Processing same-day ticket sellers in the Database 158, the System 150 identifies twelve Providers proximate to Judy's Locale at the baseball stadium.
Referring to Step 340, the Fulfillment System 150 further vets the potential Providers.
In Step 430, each of the potential Providers is vetted based on a comparison of preferences set by the Seeker in the Seeker's Profile in the Database 158—against a Provider's characteristics set in the Provider's Profile. Judy Piper's Seeker Profile indicates that she requires a positive proof of identification. Six of the potential Providers do not have “will prove identity” selected in their Profiles, and as a result are rejected by the Fulfillment System 150.
In Step 460, for each potential Provider, the Provider is vetted by the Fulfillment System 150 based on the Provider's willingness to accept the Seeker. That willingness is determined based on a comparison of preferences—the Provider's preferences expressed in the Provider's Profile in the Database 158—against the Seeker's characteristics preset in the Seeker's Profile in the Database 158. Four potential Providers have indicated preferences for payment specifically in either cash or by credit card. Judy's Seeker Profile reflects her need to pay by check—not credit card nor cash. Judy assumes she isn't carrying sufficient cash and is not about to give out her credit card info to a stranger in a stadium parking lot. The System 150 rejects these four additional potential Providers. Two remaining Providers accept checks—so they pass the vetting process.
Referring to
In
When Judy sees that Jack can not be phoned, she immediately actuates the “back” virtual button 2310 that returns her to an updated Provider proffer display—FIG. 22B—where she taps the violet icon 2230. The fall back Provider in this example—Linda Rogers—has set up her preferences in her Provider's Profile in the Database 158 so that the Fulfillment System 150 prompts the Seeker—Judy—to contact Linda, as shown in
The Fulfillment System 150 can facilitate communication between Seeker and Provider, by either providing contact information for the Provider or—as in this example—providing a facility to contact the Provider directly. In this instance, Judy telephones Linda by actuating virtual button 2320 which causes her mobile communication device to place the phone call directly. The Fulfillment System 150 is not a party in the conversation between the Seeker Judy and the URGS Ticket Seller Linda Rogers.
The Provider—see FIG. 24—having been alerted to expect to be contacted by a new Seeker—can view the Locale of the new Seeker by actuating the virtual button 2410, which Linda Rogers chooses to do. This displays a tracking map showing Seeker Judy's Locale as she walks toward the main gate of the stadium and Provider Linda's Locale as she is just pulling into the stadium parking lot—see
Linda's mobile communication device rings with the call from Judy Piper—Linda pulls over, parks, and then answers. Judy immediately explains her situation including limited cash. They negotiate a total sale amount—partially to be paid in cash and partially by check. Neither Judy nor Linda are familiar with stadium land marks, but they agree to walk in each other's direction as they both can see on instances of tracking maps on their respective mobile communication devices.
In step 260, the Fulfillment System 150 starts ongoing tracking of the progress of the Provider and/or the Seeker both traveling to meet at an ad hoc rendezvous location. Referring to
The Seeker and Provider continue walking roughly towards each other—each looking around and at their respective tracking map screens. Referring to
Referring to step 270, the Fulfillment System 150 facilitates compensation by logging the transaction whereby the Seeker—Judy Piper—selected the Provider—Linda Rogers. Both Seeker and Provider can subsequently look up the Transaction Log record. Each can separately associate additional annotation with the Transaction Log. In this example, Judy will make a note of Linda's driver license number.
In step 280, the Fulfillment System 150 facilitates follow-up. Linda's Provider Profile in the Database 158 indicates “no follow-up”. Judy's Seeker Profile is set for a next day follow-up, which will turn out to be a brief but heartfelt thank you call.
The Fulfillment System 150 facilitates Loyaltization—step 290—as described above.
A micro-casting distributed URGS fulfillment (“MCDUF”) system may typically operate as an intermediary facilitator in a distributed system that matches a seeker with an acceptable appropriate third-party provider of URGS (“Seeker” and “Provider” respectively). Micro-casting provides a highly responsive urgency-mediated regime for URGS fulfillment—directing individual system interactions with a given user (i.e., Seeker or Provider) based in part on evolving assessments of user needs, temperament, condition, and circumstance. A MCDUF system utilizes systems and methods of on-going urgency monitoring, measurement, evaluation and adjustment to provide an individually tailored experience that continually and iteratively adapts in real time to a given Seeker's sense of urgent need and/or a given Provider's business and/or other needs.
In order to succeed commercially, the MCDUF system must be satisfactory to both Seekers and Providers; accordingly, micro-casting may concurrently accommodate the requirements of both Seekers and Providers. However, that said, there may be a substantial asymmetry between the requirements, expectations and time-of-use temperaments of Seekers and Providers. To a Provider, the MCDUF system may be viewed as if it were a type of targeted advertisement and/or lead generation facility—even though it may provide much more service than that. Immediate results may have a very positive effect; yet ongoing longer-term sourcing of additional business may perhaps be more likely to cause a Provider to become not only a dedicated user, but also a positive recommender. Therefore, the MCDUF system additionally may have facilities for satisfying and retaining Providers by determining, measuring and individually fulfilling their needs. For example, scheduling and maintaining a schedule of availability may be an annoying, if not onerous, task for a busy Provider; therefore the MCDUF system provides numerous facilities for simplifying and automating availability and notifications.
To better understand embodiments of a MCDUF system, it is useful to understand the positive user experiences and behaviors such a system is intended to engender and sustain. Perhaps the most direct way of doing that is to consider first the Seeker experience, then the Provider experience and then their combined experiences in exemplary MCDUF system embodiments. In some instances, the facilities and functions of a MCDUF system may be nearly indistinguishable between user types such as Seeker and Provider. In such instances a Seeker and/or Provider may simply be referred to as a “user”. Additionally, other third party “utilizers” such as data providers (e.g., vendor rating sites) and data acquirers (e.g., credit agencies) may utilize facilities of the MCDUF system.
As a distributed system, a MCDUF system may in a multiplicity of embodiments utilize a client-server architecture, or a peer-to-peer architecture, or various hybrid combinations of both. MCDUF system client logic may operate on a variety of remote devices or systems, but perhaps most commonly on a mobile device kept in the personal possession of a user. Typically, MCDUF system client logic for a mobile device may be in the form of an application program (or in common parlance an ‘app’) that either executes natively or in a Web browser hosted on that device, i.e., a “native app” or a “web app” respectively. For simplicity, the description that follows refers to the client logic operating on a Seeker client system/device as the “Seeker device client” or just “Seeker's app”; and the equivalent Provider client logic as the “Provider device client” or “Provider's app”. Although ‘apps’ are most commonly associated with mobile devices, in the description that follows, the terms “Seeker app” and “Provider app” also apply to MCDUF system client logic running on a non-mobile device or system such as a desktop PC. In some embodiments, a MCDUF system client may be embedded in the operating logic of a device or system, but for simplicity, such embodiments are also intended to be encompassed by the term “app”.
As communication technologies rapidly evolve, a plethora of new devices running a Seeker device client 2710 and/or Provider device client 2790 may operate together in the computerized and network-interconnected MCDUF system 2700. Nonetheless, the basic characteristics of such user devices may share common features including: facilities to communicate over wide area networks 140 with the URGS fulfillment system 150; facilities to obtain input from users; and facilities to present system output to users. Furthermore, a new generation of innovation may provide measurements such as perspiration, pulse, blood pressure, blood sugar level, pupil dilation, respiration rate, skin conductivity and voice pitch that may be particularly useful as additional forms of input—particularly when assessing the status of an individual Seeker or Provider. Wearable or implanted devices are already on the market or in development—for example ‘Smart Glasses’ and ‘Smart Watches’. Overall, the trend in personal electronic devices and systems is toward being smaller; processing faster; having more and better sensors; serving a wider variety of applications; storing and processing larger data; and residing more continuously and in closer proximity to the user's body. The adaptive and user-specific nature of the MCDUF system 2700 may anticipate leveraging such improvements on a user-by-user basis as they come into use.
As described above, a number of facilities may be provided by a user's client device that may be utilized to measure the user's circumstance including the user's sense of urgency. For example, the user's client device may provide a date/time indication, which may be measured in a granularity as fine as milliseconds. Such a facility may be utilized to provide measurements such as “date/time stamping” and “elapsed response time”. Date/time stamping may for example provide information that is included in a “transaction log” by the MCDUF system 2700, wherein such a transaction log may record interaction with a given user in an information repository such as data bases(s) 158. Elapsed response time may for example be utilized to measure the difference in time between when a screen is displayed to the user and when that user enters a corresponding response such as pressing a virtual button to make a selection or entering requested information. The relative length or shortness of elapsed response time may be utilized by the MCDUF system 2700 as a measure of the user's sense of urgency. Elapsed response times may be accumulated to get an ongoing measurement of the user's sense of urgency. In some instances, the elapsed response times may shorten perhaps indicating that the user may be feeling increased urgency or other distress. Or the elapsed response times may be lengthening perhaps indicating that the user may be feeling less distress. Elapsed response times may be compared against earlier measured elapsed response times for the same user and/or against elapsed response times measured for one or more other users or perhaps against other ‘benchmark’ response time data.
In some embodiments an URGS seeker may not be human—such as an animal or a device. In some embodiments an URGS seeker may be human, but not deemed fully legally competent—such as a child or a functionally-challenged adult. Additionally, in some embodiments, an URGS seeker may be ‘proxied’ by an individual or a device acting on the URGS seeker's behalf—for example, a neighbor may arrange an urgent plumbing appointment for an elderly neighbor (the URGS seeker) who may lack the skills and/or ability to operate a Seeker client device. Such an URGS-seeker-proxying or imitating entity may be termed a “proxy-seeker”. In some embodiments, a proxy-seeker may be undetected by the MCDUF system 2700. For example, a husband (the proxy-seeker) may make an urgent appointment for his wife (the URGS seeker) interacting with the MCDUF system as if he were his wife.
In some embodiments, a proxy-seeker may utilize the MCDUF system 2700 explicitly as a proxy-seeker. For example, a computerized controller in a network-connected appliance such as an ‘intelligent’ refrigerator may detect a fault that requires urgent service; or perhaps a human house sitter discovers that the refrigerator is no longer cold. Such a proxy-seeker may utilize the MCDUF system 2700 just as a Seeker would, but perhaps identify themselves (or itself) as a proxy-seeker seeking URGS on the URGS seeker's behalf (i.e., the refrigerator owner's behalf). In some instances, this may be done transparently to the MCDUF system 2700, wherein such proxy-seeker identifying information may be communicated directly to the Provider(s). Or in some embodiments, the MCDUF system 2700 may provide facilities (not shown) for an explicit “associate account” whereby a proxy-seeker may utilize the MCDUF system 2700 explicitly as a proxy-seeker so as to request URGS via proxy-seeker specific or adapted MCDUF system facilities. In some embodiments, non-human proxy-seekers may utilize alternative MCDUF system ‘machine’ facilities rather than the MCDUF system facilities for human URGS seekers. For example, the MCDUF system 2700 may support an “automated proxy-seeker facility” dedicated to exchanging digitally encoded messages with a refrigerator, home monitoring system or other ‘intelligent’ home appliance or system. In some embodiments, a MCDUF system 2700 may support a multiplicity of device-specific automated proxy-seeker facilities (not shown).
In some embodiments, an associate account may be affiliated with a registered Seeker's account and/or may be managed by a registered Seeker. Such an affiliated Seeker may be termed a “Master Seeker”. Furthermore, in some embodiments, the associate account may be configured so that the Master Seeker may be notified by the MCDUF system 2700 should an URGS request be made utilizing the associate account. Additionally, in some embodiments, the micro-casting facilities of the MCDUF system 2700 associated with Providers may be adapted in order to so notify a Master Seeker. For example, the Master Seeker may ‘appear’ to the MCDUF system 2700 to be a “virtual provider” with a priority micro-casting ranking such that the first URGS need request may be sent by the MCDUF system 2700 to the Master Seeker. Accordingly, as a virtual provider, a Master Seeker may utilize the same MCDUF system facilities intended to mediate and route URGS needs requests for Providers. Therefore, in some embodiments a Master Seeker may use MCDUF system 2700 Provider account management facilities such as those to maintain availability schedules and specify notification message routing.
The facilities provided by the MCDUF system 2700 may unintentionally or unknowingly allow a malicious individual to pose as a Seeker or as a proxy-seeker. Accordingly, in some embodiments, the MCDUF system 2700 may utilize authentication, encryption, secure dedicated link communication, device-to-account binding and other security mechanisms to deter or foil such malicious ‘spoofing’ attempts. In some embodiments, a proxy-seeker may be subject to account access controls similar to those for a Seeker—such as a unique proxy-seeker identifier and possibly a shared secret such as a password. In some embodiments, a proxy-seeker communications may be routed through and/or certificated by a third party. As opposed to potentially fraudulent URGS requests, even legitimate proxy-seeker URGS requests may create problems, disputes or liabilities for the Master Seeker; therefore, in some embodiments an associate account may be configured so as to limit the category(s) of URGS that the proxy-seeker may request. Furthermore, for each such Master Seeker-allowed URGS category, the Master Seeker may simply pre-approve it or alternatively may require notification and explicit Master Seeker approval per associate account-initiated URGS need request incident. In some embodiments, the MCDUF system 2700 may be configured to notify the Master Seeker, but not to issue associate account-initiated URGS need requests.
A proxy-seeker may utilize the MCDUF system 2700 facilitated by a Seeker app. Alternatively, in some embodiments, a proxy-seeker may utilize proxy-seeker specific client logic, i.e., a “proxy-seeker app” (not shown). Dedicated proxy-seeker apps may be devised for specific proxy-seeker devices, for example a proxy-seeker app may be devised for an ‘intelligent’ bread-maker so as to utilize the proxy-seeker facilities of the MCDUF system 2700.
At step 2810, a Provider may be distinguished from other service classes of users/utilizers.
At step 2820, a Provider may be served in order to facilitate the Provider's utilization of the MCDUF system 2700.
At step 2830, a Seeker may be distinguished from other service classes of users/utilizers.
At step 2840, a Seeker may be served in order to fulfill that Seeker's URGS need(s).
At step 2850, the MCDUF system 2700 may fulfill the needs of additional utilizers. In some embodiments, the MCDUF system 2700 may provide services to other utilizers in addition to Seekers and Providers. For example, aggregated information about Seekers and/or Providers may be anonymized, aggregated and processed to provide useful statistical data to third parties such as trade organizations, consumer interest groups, government bodies, rating organizations, and many other parties that have interest in commercial transactions involving URGS.
Step 2860 is described further below.
At step 2920, the MCDUF system 2700 may facilitate the Provider to manage the Provider's MCDUF system account. In some embodiments, the MCDUF system 2700 may gather information about a given potential provider in order to attempt to fulfill their needs to acquire customers. (Some embodiments of “Provider account management” may be described in detail further below in this document in the context of exemplary Provider app screen shots.)
At step 2930, the MCDUF system may differentiate between types of autonomous initiation of MCDUF system operation leading to Provider interaction. In some embodiments, such autonomously initiated MCDUF system interaction with a Provider may be facilitated utilizing an indication on the Provider's client device that some ‘event’ may have occurred that requires the Provider to utilize the Provider's app. The provider may then choose to cause the app to execute on the Provider's client device. This process of ‘alerting’ a user is a standard feature supported by most network attached computing devices. On a personal computer for example, a notification virtual window may open, or an application icon on the ‘screen icon tray’ may start ‘hopping’. On many mobile devices, the effected app's icon may be highlighted in some way that draw's the user's attention. For mobile devices, the industry term for such autonomously initiated user interaction is ‘push notification’. In order to alert a Provider that a Seeker has an URGS need that the Provider may have an opportunity to fulfill, in some embodiments, the MCDUF system 2700 may utilize such notification mechanisms as described above. For the purposes of this description, such notification may be termed a “Seeker request notification”; and may be applied agnostic to the type of Provider client device.
In some embodiments, other types of autonomously initiated Provider notifications may be utilized. Referring to
Additionally, in some embodiments, notifications may also be utilized in interactions with Seekers (not shown)—for example to facilitate a ‘follow-up appointment reminder’ or perhaps to provide a ‘Seeker review posting alert’.
The ‘Seeker-to-Provider match’ service(s) provided by the MCDUF system 2700 as part of URGS fulfillment may entail concurrent interactions with a given Seeker and corresponding Provider(s)—in a ‘back and forth’ fashion—as the MCDUF system 2700 intermediates between them. Therefore, as a conceptual aid, some MCDUF system embodiments as exemplified by
To help illustrate the ‘back and forth’ intermediation of the MCDUF system 2700 in some embodiments, the following descriptions of respective flows through
Referring to
Clearly, key components that may become increasingly important if not critical in measuring Seeker urgency as well as ascertaining Seeker URGS need(s) may be the set of sensors embedded in the Seeker's device and/or other sensors temporarily or persistently near the Seeker that may be MCDUF system accessible. For example, an office seating system with bio-feedback capability may intercommunicate with the Seeker device and provide bio-metric information measured by the chair's sensors. Such sensor-based measurement of the Seeker, whether by the Seeker device or by other sensors in the Seeker's environment, may be termed “Seeker instrumentation”. A more generic term—“instrumentation”—may apply to sensor-based measuring of MCDUF users, whether Seeker or Provider.
At step 3020, the MCDUF system 2700 may incrementally “enroll” the Seeker. Enrollment may include both acquiring user descriptive information (“registration”) and user selection of service-related preferences (“personalization”). A Seeker may be queried to obtain information that uniquely identifies that user such as full name, phone number, e-mail address. Such a Seeker may be further queried to create a unique Seeker account user name and password. Such a registration process may be relatively straight forward and quick, yet a highly distressed Seeker may still find it burdensome. Consequently, in some embodiments, a Seeker may be given the option to bypass or postpone registration. In some embodiments, the MCDUF system 2700 may associate a unique identifier with the Seeker; for example, such a “Seeker ID” may be a multi-byte identifier assigned by the fulfillment server 155 (or perhaps the Seeker's app 2710) and stored for subsequent inclusion in transactions back and forth between the Seeker's app 2710 and the fulfillment server 155 of the MCDUF system 2700. In this way, a given Seeker may be distinguished from all other Seekers and yet potentially remain nominally anonymous.
Although it is useful and otherwise desirable to build a data base characterizing MCDUF system users, seemingly extraneous data gathering may annoy or even infuriate a distressed Seeker. Therefore in some embodiments, the MCDUF system 2700 may utilize various “en passant” approaches to collecting enrollment information from the Seeker. Such en-passant information gathering may include querying for specific item(s) of Seeker information when it seems directly applicable to helping immediately further meet the Seeker's URGS or other needs. Such incremental enrollment data gathering may be interspersed throughout the Seeker interaction with the MCDUF system 2700.
At step 3030, the MCDUF system 2700 may assess the Seeker's URGS need(s). Direct Seeker input may provide a primary source of URGS need information. The Seeker may be queried for a description of the needed URGS in a multiplicity of ways including, but not limited to a menu of selections, a Seeker typed description, a Seeker spoken description, as well as URGS need(s) deduced from Seeker instrumentation. Additionally, the MCDUF system 2700 may deduce a secondary set of URGS need(s) based on the Seeker's self-described URGS need(s). For example, the Seeker may indicate the urgent need for a dentist to treat a broken tooth. The MCDUF system 2700 may consequently deduce the secondary URGS need for pain medication. In some embodiments, the MCDUF system 2700 may make suggestions or recommendations to the Seeker and/or Provider based on the MCDUF system's assessment of the Seeker's URGS need(s).
In some embodiments, other facilities for identifying the Seeker's URGS need(s) may be utilized—for example, key word URGS search (not shown).
At step 3040, the MCDUF system 2700 successively proffers Providers. In some embodiments, the Seeker may be offered the choice to select and contact a specific individual Provider or to send out a ‘request for help’ to more than one Provider. A Seeker may be further facilitated in the Provider location process by a “search results map”—a map that may display the location of both the Seeker and pre-qualified Providers the Seeker may choose to contact.
At step 3050, the MCDUF system 2700 may obtain the Seeker's choice of Provider(s). In some embodiments, the MCDUF system 2700 may facilitate the Seeker to simultaneously request URGS from more than one Provider. In some embodiments, a MCDUF system-intermediated ‘back-and-forth’ between Seeker and Provider(s)—to work out details of fulfilling the Seeker's need—may follow step 3050.
Referring to
At step 2940 in some embodiments, the MCDUF system 2700—utilizing the facilities of the Provider app 2790—may ‘alert’ the Provider so as to display the Seeker's URGS(s) request.
At step 2950 in some embodiments, the MCDUF system 2700—utilizing the facilities of the Provider app 2790—may acquire the Provider's response to the Seeker's URGS(s) request.
Referring once again to
At step 3070 in some embodiments, the MCDUF system 2700—utilizing the facilities of the Seeker app 2710—may obtain the Seeker's response to a given Provider's offer of URGS.
Referring both to
In some embodiments, post-acceptance communication between the Provider and the Seeker may be facilitated by the MCDUF system 2700 acting as a ‘man-in-the-middle’ proxy. Such proxying may not only facilitate communication between the Seeker and the Provider, but may enable the MCDUF system 2700 to record details relating to such communication so as to substantiate the likelihood of a corresponding “billable moment” wherein a commercial transaction between the Seeker and Provider may be considered to have been consummated.
Referring to
Referring again to
Referring again to
The logic flow diagrams in
Referring once again to
Referring once again to
Returning to
In some embodiments, as exemplified by the description above, the MCDUF system 2700 may utilize a user interface navigation topology that is at least partially meshed—as opposed to tree-like—thus for example allowing a distressed Seeker more than one way to navigate to the same result; and thereby decreasing the likelihood that the Seeker unintentionally navigates into a ‘blind alley’ where the desired result cannot be attained. Nonetheless, a distressed Seeker may navigate into a blind alley, perhaps by ‘fat fingering’ the wrong virtual button. A ‘back’ virtual button—for example virtual button 3410 in FIG. 34—may provide a facility for the Seeker to recover from mis-navigation. In some embodiments, any user utilization of a ‘back’ virtual button or similar control may be measured and recorded as a possible indication of user perceived experiential urgency or distress.
Referring once again to
In some embodiments, virtual buttons on screen 3600 (as well as other screens) may be instrumented to facilitate assessing the Seeker's perceived experiential urgency and potential distress.
Regardless of whether the Seeker chooses to select a specific Provider via or to reach out to multiple Providers, some specific information about the Seeker may be useful to any Provider receiving an URGS needs request. Such Seeker specific information may include, but not be limited to: the Seeker's location, the Seeker's contact information, the Seeker's URGS need(s), and the Seeker's desired timeframe for acquiring URGS.
The Seeker's self-descriptive note entered in input box 3740B may contain a multiplicity of words and phrases that may be utilized by the MCDUF system 2700 to further assess the Seeker's condition. For example, in the above example, Sam Smith entered the following terms to describe his URGS needs: ‘injured’ and ‘2 broken teeth’. In some embodiments, a natural language processing facility (not shown) may be utilized by the MCDUF system 2700 to identify and process such Seeker condition indicative words and phrases. Such information may be aggregated into the ongoing cumulative assessment of the Seeker's sense of urgency and level of stress.
In some embodiments, the appearance of a Provider icon may be visibly altered in order to convey the status of that responder—including, but not limited to, that responder receiving the Seeker's request and undertaking to respond to the Seeker's request or choosing to decline it.
In some embodiments, micro-casting may be utilized by the MCDUF system 2700 to identify and possibly rank two or more possible URGS-need(s) suitable Providers to attempt to contact on the Seeker's behalf; and further to control the order and timing of such contact attempts. In some embodiments, such contact attempts may be “triaged”, i.e., executed in successive tiers, so as to allow time for a preceding tier or tiers of Providers to receive the Seeker's URGS request and to undertake to respond to it. Such a triaging of possible Providers may be utilized to avoid disturbing Providers other than a tier of Providers adequate in number to likely generate an acceptance offer to the Seeker's URGS request; and utilizing such a tiered approach, successive tiers of Providers may be contacted if preceding tiers of contact attempts fail to result in URGS fulfillment offer(s) to the Seeker. Various “bracketing” processes may be utilized so as to provide a hysteresis that controls pausing and resuming the proffering of successive tiers of triaged Providers. In some embodiments, such a bracketing may pause proffering when a sufficient number of triaged Providers have been proffered and may resume proffering when the number of proffered triaged Providers drops below a minimum threshold due to causes such as: one or more Providers declining a Seeker's request; the Seeker declining one or Provider offers; or one or more Provider's not responding to a Seeker's URGS request within the window of a ‘time-out’ period.
In some embodiments of micro-casting, a number of factors may be utilized by the MCDUF system 2700 to determine and control how the contacting of Providers may be triaged. For example, the MCDUF system 2700 may utilize a preferential system of Provider triage whereby a Provider may be determined to be “suitable” based on factors including, but not limited to proximity, availability and Provider qualification. In some embodiments, such a preferential system may utilize a “current seeker-adaptive micro-casting triaged provider pool” (or more simply “triaged provider pool”), generated in real-time, which essentially may be a collection of Providers deemed suitable to possibly proffer to the Seeker. In some embodiments, during micro-casting, additional newly-available suitable Providers may be triaged into a given triaged provider pool. Similarly, newly-unavailable suitable Providers may be removed from a given triaged provider pool.
In some embodiments, Providers evaluated for a given Seeker's triaged provider pool may be qualified and perhaps ranked utilizing a multi-dimensional gradient wherein the dimensions of the gradient may include but not be limited to “virtual proximity”, “weighted availability”, and “synthesized suitability”. The derived locus of a given Provider on such a gradient may be utilized to determine the relative ranking of that Provider against other Providers for the purpose of ordering the offering of the Providers to the Seeker. A given Provider may be significant enough of an outlier on such a gradient that the Provider may be excluded from the triaged provider pool.
In some embodiments, virtual proximity may be derived from a combination of factors including but not limited to: the Seeker's means of conveyance; mapped travel distance; traffic speed conditions; the Provider's commercial territory (e.g., tow truck service limited to a region); and the projected time of travel. Weighted availability may be derived from a combination of factors including but not limited to: the scheduled explicit availability or unavailability of the provider; the ‘freshness’ of the Provider's schedule (i.e., how recently was the schedule updated); the degree of certainty of the Provider's availability or unavailability (for example a ‘time of day preference’ unavailability vs. a ‘blocked out multi-day’ unavailability); the number of Seeker requests recently received by the Provider; and the number of the Provider's offers accepted and/or rejected by Seekers. Synthesized suitability may be derived from a combination of factors including but not limited to: the Provider's self-categorization of URGS provided; ongoing qualifying evaluation specific to an URGS category; Provider quality based on responsiveness, likelihood to accept Seeker requests, Seeker satisfaction, and third party ratings (e.g., Yelp, Angie's List, Better Business Bureau, etc.); background and performance checks; years of experience; and length of use of the MCDUF system 2700.
Referring once again to
The preceding sequence of figures provided examples of screens a Seeker might utilize in some embodiments of the MCDUF system 2700. A given Provider may also utilize a sequence of one or more screens in order to share the Provider's information with the MCDUF system and also to interact with Seekers facilitated and/or intermediated by the MCDUF system 2700.
Referring once again to
In some embodiments, acceptance of a potential provider as a Provider in a provider URGS category may be perfunctory with little or perhaps no pre-qualification other than providing information sufficiently describing the potential provider so as to facilitate proffering by the MCDUF system 2700. In other embodiments, qualification may be more complex and perhaps more selective. In some embodiments of the MCDUF system 2700, URGS needs Providers may be proffered by the MCDUF system only after pre-qualification vetting. Such an individual pre-qualification “Provider pre-vetting” may include a mixture of automated and human-mediated procedures. Also in some embodiments, Provider pre-vetting may include ongoing evaluation during a probationary acceptance period. Furthermore, qualification evaluation of a Provider may continue subsequent to full acceptance of the Provider into the MCDUF system provider resource pool. Consequently, in some embodiments, a Provider may be disqualified during pre-vetting, during any probationary period, or subsequent to full acceptance; and therefore may be removed from the MCDUF system provider resource pool and therefore may subsequently no longer be a Provider. The factors that may be used to thusly “disqualify” a Provider may include factors including but not limited to those used in pre-qualifying a Provider. In some embodiments, disqualification of a Provider may occur by stages, whereby an intermediate stage may include but not be limited to a renewed probationary trial period that may precede either re-acceptance or full disqualification.
In some embodiments, a potential new Provider may be required to have a prior history as a Seeker in order to be qualified as a Provider. In other embodiments, such a prior history may be a factor in, rather than a pre-condition for, qualification of a Provider.
A potential provider may actively seek out such an automated MCDUF system provider registration form or may receive a solicitation that directs the potential provider to such a form. Such solicitation may be automated or human mediated or both. In some embodiments, a pre-qualification process may control whether a potential provider is solicited; such a deliberately pre-qualified solicitation may be termed an “invitation”.
In some embodiments, any information provided by a user—either a Seeker or a Provider—may be recorded and perhaps subsequently utilized by the MCDUF system 2700 regardless of whether the user completes or cancels the information acquisition process. So for example, the MCDUF system 2700 may record that a potential provider started the application process and then chose to cancel it. Furthermore, as may be the case with all app screen inputs from a user who is a Seeker, any app screen inputs screens utilized by a potential provider or qualified Provider may be instrumented so as to assess their temperament, degree of patience and/or other detectable or deducible personality traits.
The information gathered for a given provider profile may vary depending on the URGS involved. For instance, a dentist may accept Delta Dental Insurance for payment whereas a plumber may not.
In some embodiments, the MCDUF system 2700 may proxy communications between a given Seeker and a correspondingly selected Provider so as to mediate, control, translate and possibly monitor the communication. For example. communications that are proxied by the MCDUF system 2700 may be subject to recording for quality control and/or other purposes. With the very real possibility, if not certainty, of being drawn into a dispute between a Seeker and a Provider, the MCDUF system 2700 may find recorded communications very useful to help mediate such situations.
Furthermore, with a proliferation of communication devices, media, technologies and providers, mismatches may occur wherein direct communication between a Seeker and a Provider may not be possible without translation. Acting as a ‘man in the middle’ communications proxy (not shown), for example, a MCDUF system 2700 may provide communication translation services such as translating between text and voice media. Furthermore, a MCDUF system 2700 may provide an enhanced service or combination of enhanced services not available to (or otherwise not subscribed to) by a given Provider and/or Seeker. So further by example, a MCDUF system 2700 may provide a Seeker with an automated message delivery and call back service (not shown) whereby a Seeker's message might be recorded, sent to one or several Providers possibly on a time delayed basis, and the Provider's responses routed back to the Seeker via one or several Seeker-specified communication facilities, e.g., voice, instant messaging and texting. Such enhanced communication services may additionally be offered to Seekers for utilization other than satisfying URGS needs.
In an another example, the MCDUF system 2700 may provide an automated electronic communication exchange capability (not shown) for a given Provider, whereby Seekers' requests may be recorded, forwarded, multi-cast, translated, rolled-over and otherwise processed in order to deliver communications to the Provider in real time or on a delayed basis. Such an automated communication exchange capability may also provide services mediated by a schedule such that, for example, communications may be routed differently depending on the time of day or day of the week—say to an office phone and an e-mail address during office hours; and to a personal cell phone and a text number after hours. Additionally, such an exchange may provide access to human-mediated communications services such as a live phone or on-line chat attendant. Such enhanced communication services may additionally be offered to Providers for utilization other than satisfying URGS needs.
Similarly, the routing of communication or the control of other services to a Provider or to a Seeker by the MCDUF system 2700 may be based on “presence”, i.e., the apparent (or deduced) location of that user. Presence may be determined in numerous ways including but not limited to: explicit or predictive scheduling; instrumentation such as smart phone or automotive GPS; cell tower utilization; home, private or public monitoring systems; as well as explicit setting by the user.
In addition to supporting and possibly augmenting a Provider's communication with Seeker's, the MCDUF system 2700 may provide services related to ‘new media’ such as social networks (not shown). So for example, the MCDUF system 2700 may aggregate consumer reviews of a given Provider that may appear on third party sites such as Yelp. Conversely, the MCDUF system may provide selected or aggregated data to third party services such as Yelp or Angie's List. So for example, the MCDUF system 2700 may provide an on-line provider reputation monitoring and enhancement service.
Referring again to
Referring again to
Furthermore, subscreen 5250 may include a textual description that may explain to the potential provider that the profile configuration process may have been successfully concluded. Near the bottom of subscreen 5250, virtual buttons 5270 and 5280 may provide the Provider with the respective options to either ‘continue’ the process to potentially become a Provider or to ‘cancel’ the process.
It may be noted, that by navigating through screens such as 4100, 4200A, 4200B, 4300, 4400A, 4400B, 4500, 4600, 4700, 4800A, 4800B, 4900, 5000, 5100, 5200 and 5300A, a new Provider may have both configured the Provider's account so that the MCDUF system 2700 may proffer that Provider to Seekers of URGS, but additionally may have in effect given the new Provider a guided tutorial for many of the screens that the Provider may utilize subsequently to maintain the Provider's account.
As mentioned above, the Provider may check the ‘24/7’ check box 5335B, thusly overriding the duration setting in input box 5330B as well as any regularly scheduled availability or unavailability; and thereby potentially making the Provider immediately and continuously available (or unavailable) until check box 5335B is unchecked or until such 24/7 availability (or unavailability) is otherwise overridden. The Provider may uncheck (or leave unchecked) check box 5335B such that the duration time setting in input box 5330B may control the duration of availability or unavailability selected utilizing one of radio buttons 5320B and 5325B.
Utilizing input box 5340B, the Provider may specify a contact number where to route Seeker calls for the duration specified by the combined operation of 5330B and 5335B. Similarly, utilizing input box 5345B, the Provider may specify a contact number where to route Seeker text messages for the same duration. In some embodiments, the Provider may utilize facilities (not shown) to specify a multiplicity of alternative contact numbers to route calls as well as a multiplicity of alternative contact texting numbers and/or email addresses to route messages.
The ‘remember’ checkbox 5350B may be checked so as to retain the settings in input box 5340B and 5345B subsequent to expiration or over-ride of the duration specified by 5330B or 5335B, otherwise 5330B and 5335B may revert to values configured via screen 4600 (or otherwise determined by default values in lieu of such configuration utilizing screen 4600). The Provider may select the ‘save’ virtual button 5355B so as to cause the settings 5320B, 5325B, 5330B, 5335B, 5340B, 5345B and 5350B to go into effect immediately. Otherwise, such settings may not go into effect and may be lost at such time as the next scheduled availability occurs, except that 5340B and 5345B may be preserved by the possible selection of the 5355B ‘remember’ checkbox.
A menu 5360B consisting of virtual buttons may appear below subscreen 5310B. Such virtual buttons may include: a ‘view callers map’ virtual button 5360B, a ‘recent callers’ virtual button 5365B and a ‘my settings’ virtual button 5370B. In some embodiments, a ‘my current availability’ virtual button (not shown) may be included in menu 5360B in lieu of subscreen 5310B such that selecting such a ‘my current availability’ virtual button may facilitate navigation to a separate screen with display content and operational utility similar and perhaps equivalent to subscreen 5310B. In some embodiments, other additional virtual button menu selections may be included. For example, such an additional virtual button may be ‘my other businesses’ (not shown) whereby a Provider may be facilitated to offer URGS in more than one URGS category from the same provider account. So for example, Keith White may thusly be proffered by the MCDUF system 2700 say as a watch repair specialist in addition to as a general dentist.
Selecting virtual button 5365B may navigate the Provider to a callers map screen 5400 similar to the callers map previously viewed by the potential provider at screen 5100, but without the explanatory subscreen overlay 5130.
Referring back to
Referring again to
Referring again to
Having configured and enabled operation of the provider account, for example as described above, the Provider may utilize the MCDUF system 2700 via one (or a combination of) Provider apps 2790 so as to receive notifications of Seeker requests. Such Seeker request notifications may seem most valuable to the Provider in instances that the Provider may be both: available to respond to such requests; and also subsequently available to provide the requested URGS in a timeframe and location that may be satisfactory to the corresponding Seeker. The reception of Seekers' URGS requests may be a mixed blessing. Get too many requests and the Provider may become frustrated by distractions that may detract rather than add to business. Or perhaps worse, get too few requests—particularly early on in the utilization of the MCDUF system 2700—and the Provider may lose interest in utilizing the system. Micro-casting may address such dilemmas by dynamically modulating the volume of URGS requests sent by the MCDUF system 2700 to any given Provider.
A number of factors may be considered individually and in concert as the MCDUF system 2700 utilizes micro-casting to modulate the transmission of Seeker requests to URGS Providers. At a high level such factors may include (but not be limited to): Seeker interests, Provider interests, the interests of the MCDUF system 2700 (i.e., system owners and operators), and possibly the interests of third parties in various combinations that may include (but not be limited to): licensing and regulatory organizations, investors, public interest groups, law enforcement, industry special interest groups, and possibly, advertisers. Furthermore, the relative importance of—and therefore the weighting assigned to—any given such factor may vary depending on additional mediating factors such as: the geographic region of the URGS search, the URGS category(s), the density of available URGS suitable Providers, the density of nominally URGS need-equivalent Seekers, external events such as bad weather, traffic jams, catastrophes, as well as predictive statistical patterns related to additional factors such as time of day, season of the year, phase of the moon, weather, holidays and other factors effecting human behavior.
Therefore, it may be understood that micro-casting may utilize densely complex algorithms. And short of listing out algorithmic source code, such algorithms may best be characterized by reduction to a set of decision guidelines wherein such guidelines may be applied in combination with respective relative weightings. Furthermore, in combining the guidelines of micro-casting, it may occur that any given micro-casting guideline may be moderated, i.e., ‘bent’ or even over-ridden by another micro-casting guideline depending on the relative weighting given to each of a set of applicable guidelines and the determining factors controlling the application of those micro-casting guidelines by the MCDUF system 2700 so as to modulate transmissions of a given Seeker's URGS request to URGS Providers.
To illustrate the utilization of micro-casting by the MCDUF system 2700, an example is provided below. As mentioned previously, micro-casting may operate so as to utilize guidelines to attempt to balance the interests of the Seeker, of Providers, of the MCDUF system 2700, and of third parties. Some such guidelines and associated determining factors are represented by the tables and associated descriptions that follow.
A multiplicity of factors and corresponding guidelines may be utilized for a given Seeker and a corresponding set of suitable Providers. The tables below summarize an example of nine potential factors and corresponding guidelines. The first three guidelines may apply to a given Seeker with a need for URGS. The exemplary guidelines related to such a Seeker may be utilized to help rank that Seeker's request for URGS against any potential competing Seeker's request. Therefore, if more than one Seeker is seeking to obtain URGS from a given Provider, the request of a higher prioritized Seeker may be sent to that Provider before the request of a lower prioritized Seeker may be sent to that Provider.
So for example, guideline 1 may be based on the urgency inherent in the type of URGS sought. Such urgency may be determined perhaps by an analysis of the Seeker's description of their needs. Screen 3700B in
Guideline 2 may be based on the Seeker's sense of urgency. As described previously, such a sense of urgency may be assessed from instrumentation of the Seeker app.
Guideline 3 may be based on the Seeker's registration status. A fully registered Seeker may perhaps be more likely to commit and therefore be more reliable to obtain the URGS from a proffered Provider.
The example guidelines 4 through 9 above may apply to a given Provider who may be suitable to provide the URGS sought by a given Seeker. The exemplary guidelines may be utilized to rank such a Provider so as to help determine whether to present a given Seeker's request to that Provider or to another suitable Provider before that Provider. So if more than one Provider is suitable to provide the URGS sought by a given Seeker, a Provider ranked higher may be sent such a request before it may be sent to a lower ranked provider.
So further by example, guideline 4 may be based on a Provider's explicitly scheduled availability or unavailability to receive Seeker requests. Screens 4700, 4800A, 4800B, 4900, 5000 as well as screen 5300B illustrate examples of how general dentist Dr. Keith White may schedule availability to receive Seeker requests. Screens 5000 and 5300B illustrate examples of how Dr. White may schedule a period of time as explicitly unavailable (as opposed to explicitly available) utilizing check box 5025 in screen 5000 and/or utilizing check box 5330B in screen 5300B.
Guideline 5 may be closely related to guideline 4. In some instances, periods of a given Provider's time may be left unscheduled—i.e., neither explicitly available nor explicitly unavailable. The MCDUF system 2700 may treat such unscheduled periods to be more likely to be periods of availability than time periods for that Provider that have been explicitly scheduled as unavailable. Guidelines 4 and 5 in combination may result in a continuity of prediction of Provider availability, wherein explicitly scheduled availability may be ascribed the highest certainty, the lack of any scheduling either way may be ascribed a lower degree of certainty, and scheduled unavailability may be ascribed the lowest certainty of availability.
Furthermore, in some embodiments, an explicit scheduling of unavailability may be over-ridden by the MCDUF system 2700 such that a Seeker's request may be sent to a given Provider who is nominally unavailable for Seeker requests. A number of factors may be considered in determining whether to over-ride a Provider's setting of scheduled unavailability—such factors may be termed “supplemental availability characteristics”. For example, if many days or maybe weeks have passed since the Provider scheduled such unavailability, such scheduling may be stale and therefore inaccurate. On the other hand, if the Provider has very recently scheduled the unavailability, it is more likely to correctly reflect the Provider's current intention. As another example, if the Provider is relatively new to the MCDUF system 2700 and perhaps has not yet received many Seeker requests, it may be reassuring to that Provider to receive some requests even if they come at times that the Provider would prefer not to respond. If the Provider wishes to enforce a scheduled unavailability, such scheduling may be updated to make the intention more explicitly current. Scheduling screens such as 5000 and 5300 may be instrumented so that the MCDUF system 2700 may take notice of a Provider's deliberate re-iteration of unavailability and therefore be less likely to over-ride it again soon. On the other hand, if a Provider responds to Seeker requests that over-ride scheduled unavailability—especially if the Provider accepts some such over-riding requests—the MCDUF system may continue to over-ride scheduled unavailability for that Provider. Again, instrumentation of Provider app screens may be utilized by the MCDUF system 2700 to determine how the Provider responds to such over-riding Seeker requests. Finally, the MCDUF system may take into account time temporal circumstances such as time of day, or day of week, in determining whether to over-ride a scheduled unavailability. For example, it may be undesirable to over-ride unavailability late at night or perhaps on a day that is commonly observed as a Sabbath day.
In some embodiments, supplemental availability characteristics may also include factors that may cause a Provider to be triaged as if ‘available’ even if neither availability nor unavailability may be explicitly scheduled for that Provider. For example, a Provider may explicitly schedule weekdays, but neglect to schedule time during weekend days as available or unavailable.
Referring again to the exemplary guideline tables above, guideline 6 is based on the proximity of the Provider's nominal location to the nominal location of a given Seeker requesting URGS. In the example of Provider general dentist Dr. Keith White, his nominal location may be taken to be at his office address as indicated by Dr. White utilizing screen 4400B. The nominal location of a Seeker such as Sam Smith may be determined automatically for example by utilizing a facility such as a GPS reading from the Seeker's mobile device. Alternatively, in some embodiments, a Seeker may explicitly specify the Seeker's nominal location—for example, utilizing screen 3900B.
Guideline 7 is based on a Provider's quality rating. Such a rating may be aggregated from the feedback of a multiplicity of Seekers who have utilized the Provider for URGS needs and therefore have first-hand experience with the Provider. For example, referring to screen 4000D, Dr. Keith White may be seen to have a very laudatory 4 out of 4 stars quality rating. In some embodiments, ratings of Seekers who have not received URGS may be aggregated into a Provider's quality rating. Such Seekers may for example been turned down by the Provider. Additionally, in some embodiments, third party ratings may be aggregated into a Provider's quality rating. A given Seeker's request may be sent to a higher quality rated Provider before it may be sent to a lower rated one. However, in some embodiments a lower rated Provider may be favored. For example, a new Provider may have had very few Seeker requests and therefore any quality rating of that Provider may be based on a small sample size and therefore be perhaps less than reliable. In some embodiments, a loyalty-inducing factor may be included in Provider rankings such that an incremental bias may to some degree favor and thus encourage new Providers to continue utilization of the MCDUF system 2700.
Referring once more to the exemplary guideline tables above, guideline 8 is based on a given Provider's likelihood to respond. A response by a Provider may be both of valued to a Seeker and to the MCDUF system 2700. For a Seeker, a Provider's response may give a very clear acknowledgement that the MCDUF System 2700 may in fact be successfully contacting Providers on the Seeker's behalf. Even if a Provider turns down a Seeker's request, the Seeker may be encouraged a momentary expression of interest and perhaps concern. For example, in turning down a Seeker's request, a Provider may still provide useful advice and/or heartfelt sympathy. A response from a Provider may also be valuable to the MCDUF system 2700 in that it may cause the MCDUF system to stop sending Seeker requests—assuming the Provider responded positively; or to continue sending out Seeker requests to additional Providers—assuming the Provider responded negatively thereby decreasing the number of outstanding Seeker requests.
Guideline 9 is based on the likelihood of a Provider accepting a Seeker's request. Just as it may be more desirable for a Seeker to receive a courteous response in the negative than no response at all, it most certainly may be more desirable—and in fact is a key goal of the MCDUF system 2700—that a Seeker receive a positive response. Accordingly, the MCDUF system 2700 may favor sending Seeker requests sooner to those Providers who are more likely to respond with an acceptance. That said, a given Provider's high acceptance rating may not always be the best indicator of a good potential match. Consider the provider with a high acceptance rating, but a poor quality rating. Conversely, a low acceptance rating may not always be a reliable indicator of a bad potential match. Many factors may play into a Provider's decision to accept or turn down a Seeker's request, therefore in some embodiments, the MCDUF system 2700 comprehensively and exhaustively analyzes Seekers requests and Provider's responses (and non-responses) to develop a multi-factor based assessment of the types of Seeker requests a given Provider is most likely to accept. In this way, the MCDUF system 2700 may increase the likelihood that any given Seeker will quickly find a Provider, and that even the more picky Providers will receive requests from Seekers that may be a good match.
In some embodiments of micro-casting, Seeker requests may be sent out using a metering facility such that a limited number of Seeker requests may be outstanding at any one time. By metering requests thusly, particularly when statistically responsive Provider's may be favored, the MCDUF system 2700 may avoid bothering Providers with requests that they may not respond to in time to obtain the Seeker's business.
In addition to considering the factors and guidelines that may contribute to the operation of micro-casting, it may be informative to consider an example of a Seeker/Provider interaction utilizing the MCDUF system 2700.
Referring once again to
Referring back to
Referring again to
In some embodiments, subscreen 5700 may include a descriptive note 5740 from the Seeker conveying the Seeker's URGS need(s) to the Provider. Such a descriptive note may have been entered by the Seeker—in this example, Sam Smith—utilizing screen 3700B.
Referring again to
Referring once again to
Referring once again to
Referring once again to
Referring further to
Referring once again to
Similarly, referring once again to
In some embodiments, the Seeker's search result map and/or the Provider's caller map may include a facility (not shown) that displays an estimated ‘time of arrival’ based on potentially predictive factors including, but not limited to: travel progress, average travel speed, time of day, traffic and weather conditions, and conveyance type.
Referring once again to
It may be apparent from the foregoing discussion of micro-casting that efficacy of the MCDUF system 2700 relies substantially on a detailed and accurate assessment of Seekers' needs and Providers' likelihood to accept Seeker's requests and satisfy Seeker's needs. Any and all information that may be gathered relating to any Seeker's request and also any Provider's response (or lack thereof) and subsequent delivery of URGS may be recorded for subsequent analysis and ongoing aggregation and reanalysis. The operation of micro-casting may be highly dynamic and adaptive based on ongoing measurement, recording and thorough analysis of Seeker and Provider interactions. Not only may the data acquired and recorded from Seeker and Provider inputs be valued, but also information that may be gleaned from instrumentation of Seeker apps and Provider apps may provide the MCDUF system with a seeming intuitive like quality that statistically improves the likelihood of both Seeker and Provider satisfaction.
In some embodiments, the MCDUF system 2700 may utilize micro-casting with the goals of: satisfactorily matching as many Seekers as possible as quickly as possible with suitable Providers who accept the Seeker's requests and subsequently satisfy the Seekers' URGS needs; or in instances where they can not or choose not to attend to Seekers' URGS needs, they respond so as to make the Seekers feel valued. Additionally, micro-casting may be utilized so as to achieve the foregoing while causing as little inconvenience as possible to Providers and to Seekers such that both Providers and Seekers have on balance a positive experience utilizing the MCDUF system 2700; and further are motivated to utilize it on an ongoing basis as well as to recommend it to others.
In sum, the present invention provides systems and methods for micro-casting in urgent needs fulfillment matching. Such systems and methods may enable a Seeker to utilize a computerized MCDUF system to automatically and systematically search for, list, profile, select, and establish communication with a per-qualified Provider who may satisfy the Seeker's URGS need(s). Such systems and methods may include micro-casting facilities that may optimize the matching of a Seeker and an suitable pre-qualified Provider utilizing micro-casting techniques to balance the interests of the Seeker, the Provider, the MCDUF system, and perhaps related third parties in such a way as to provide a higher probability of not only locating suitable Providers, but also exchanging Seeker requests and corresponding Provider responses so as to quickly establish a match while disturbing a limited number of possible Providers.
While this invention has been described in terms of several embodiments, there are alterations, modifications, permutations, and substitute equivalents, which fall within the scope of this invention. Although sub-section titles have been provided to aid in the description of the invention, these titles are merely illustrative and are not intended to limit the scope of the present invention.
It should also be noted that there are many alternative ways of implementing the methods and apparatuses of the present invention. It is therefore intended that the following appended claims be interpreted as including all such alterations, modifications, permutations, and substitute equivalents as fall within the true spirit and scope of the present invention.
This Continuation-in-Part application claims priority to non-provisional application Ser. No. 13/910,812, filed on Jun. 5, 2013, which claims the benefit of provisional application No. 61/657,013 filed on Jun. 7, 2012, both entitled “Systems and Methods for Screening and Proffering Providers of an Urgent Goods or Service”, which applications are incorporated herein in their entirety by this reference. This Continuation-in-Part application also claims priority to non-provisional application Ser. No. 13/910,825, filed on Jun. 5, 2013, which claims the benefit of provisional application No. 61/657,015 filed on Jun. 7, 2012, both entitled “Systems and Methods for Matching a Seeker with a Proffered Provider of an Urgent Goods or Service”, which applications are incorporated herein in their entirety by this reference. Additionally, this Continuation-in-Part application claims priority to non-provisional application Ser. No. 13/910,831, filed on Jun. 5, 2013, which claims the benefit of provisional application No. 61/657,018 filed on Jun. 7, 2012, both entitled “Systems and Methods for Facilitating Transactions Between a Seeker and a Proffered Provider of an Urgent Goods or Service”, which applications are incorporated herein in their entirety by this reference.
| Number | Date | Country | |
|---|---|---|---|
| 61657013 | Jun 2012 | US | |
| 61657015 | Jun 2012 | US | |
| 61657018 | Jun 2012 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13910812 | Jun 2013 | US |
| Child | 14217014 | US | |
| Parent | 13910825 | Jun 2013 | US |
| Child | 13910812 | US | |
| Parent | 13910831 | Jun 2013 | US |
| Child | 13910825 | US |
