Instant generation and usage of HTTP URL based unique identity for engaging in multi-modal real-time interactions in online marketplaces, social networks and other relevant places

A system has mechanism to allow a provider of a product or service to sign up with basic identity information along with any service description resulting in an instant URL as a means for outside parties to contact this provider and engage in multi-modal interactions involving voice, video, chat and media sharing. A single user or a group of users can sign up with this system and provide optionally some contact information such as phone numbers. An URL is instantly generated that can be advertised as hyperlinks to the outside environment such as on a website, email or any other means. This URL can be advertised by the proposed system in various online marketplaces or social networks of the provider as well as on the web to be identified by search engines.

BACKGROUND OF THE INVENTION

Field

In general this invention is related to online initiated real-time interactions where any user online might interact with one or more users who are also online. This can be via various medium such as chats, voice call, video call and occur either in a specific user-based community or in a social network context. This invention is specifically related to allowing consumers/buyers who are online, to instantly engage in real-time interactions with providers of any service who may or may not be online. In this mode of interaction, the buyers and sellers are not subscribed to any specific common entity or community to communicate with each other.

Use of Terms

The terms—buyers, users and consumers are used interchangeably and refer to the same or similar entity. The terms—sellers, providers, producers are also used interchangeably and refer to the same or similar entity. Depending on the type of the online marketplace or social network or e-commerce website, these terms are changed as relevant in those contexts. As an example, an online dating site uses the term users to refer to its user base who are trying to connect with others. An online auction site would use the terms buyers and sellers. An online marketplace connecting growers and bakers may use the term producers and consumers to its user community. This invention is applicable to similar users and not limited by the specific terms used to describe the users of the proposed system.

Description of the Related Art

Marketplaces on the internet provide an environment where sellers of a service or a product can advertise their offering and prospective buyers can read through the description of these products (examples like Amazon, Ebay, Craigslist.org) and contact the sellers for further inquiries. In these marketplaces the most common mode of interaction is via email. In some cases the seller publishes their phone number with the caveat that only serious buyers should contact them. The only modes of engagement between buyers and sellers in these marketplaces are either via email where the actual email of the seller is hidden or via the published phone number that the seller has advertised. While marketplaces provide for protecting your email address, they have no such offering for protecting the privacy of the listed phone number. There have been some workarounds where sellers purchase an alias phone number from a different source and publish that in the marketplace and their actual phone numbers gets connected via this alias. However this is a very phone number centric solution and falls shorts of offering media rich (such as video and other media asset exchanges) engagements.

This kind of interaction in market places is far different than a more near real-time interaction in a group settings like social networks where all the users are members of the particular social network. Even though social real-time interaction with voice and video in these networks are evolving it still is meant for only the subscribed users of that group or network. Unless both parties wanting to interact are subscribers of the network or group, they will not be able to interact.

Currently the browser environment in the internet realm is being enhanced for real-time interactions via voice, video and data under the influence of html5. In this context, it becomes much easier to provide these media (voice, video and data) via the browser itself natively without requiring any special plugins like Microsoft Silverlight or Adobe Flash Player to be downloaded or relying on a third party software application like Skype.

In such a growing browser environment it is common for solutions to generate dynamic URL and have group of people come into a virtual location, like a room, and collaborate. However this is again a group-centric architecture rather than what is proposed here, which is a real-time engagement based architecture allowing users who are not associated with any group to engage via a unique generated URL that points to a provider for a service or even to the service itself handled by providers. In many instances the URL itself need not be visible (can be hidden behind some visual icons) for engagement to occur.

There have been other efforts in the industry to use URL as a means to refer to user information in a repository or to generate some user relevant data dynamically, generate a unique URL and have the user access that information. In some of these the structure of the URL played a key role as well. This proposed system does not depend on any specific structure of the URL itself but rather only relies on generation of globally unique URL scheme whose implementation can be very diverse as long as the URL retains its inherently necessary attributes pointing to some location with additional information.

What is now really needed in market places that we focus here, is for users who are prospective buyers to instantly engage in real-time interactions using chat, voice and video and a combination thereof with sellers or providers of any service. What this invention proposed here, in one embodiment, is to enable providers/sellers to publish contacts for instant real-time interactions and for users to engage with them without requiring both the users/prospective buyers and sellers/providers to be in any common network or group.

SUMMARY

The embodiments presented here as part of the invention enables anyone who is interested in advertising their service (say consulting on specific areas) or a product (say a car) to be able to sign-up with the proposed system by various means, to instantly acquire a unique URL and publish that URL in any website listing or social network as a hyperlink or to communicate that URL via emails. The buyers use that hyperlink or the HTTP URL in general to instantly communicate with the sellers via chat, voice, video depending on the type of device the seller is using to interact. In one embodiment the seller can communicate via SMS from a mobile phone and can then possibly join the same interactive session using a personal computer through the proposed system so as to enhance the medium of interaction using video call. In another embodiment the buyer who first engages with the seller via a text chat can add voice to the conversation and continue to interact with both text chat and voice. In yet another embodiment the buyer and seller can also add video (webcam) to the conversation and perhaps do a live demonstration of the product. They can also share different media such as images or video streams through the proposed system.

A seller who signs-up with the proposed system will provide basic contact information such as email along with additional information such as a phone number that can be used for SMS and voice calling by the proposed system as well as any other additional information such as more phone numbers if the seller has multiple personnel to handle the interaction. In one embodiment the seller can remain signed-in into the system and handle the incoming requests directly in the browser. While in one embodiment the seller is using a browser on a personal computer to remain signed-in into the proposed system to interact with buyers, the seller can do the same interactions on a browser on a smart device such as smartphone or a tablet and use the browser.

In another embodiment the proposed system also supports a smartphone application whereby the seller can remain signed-in through the app on their smart device. Here the app embeds the capability of the browser functionality that is necessary for the voice, video and chat interactions.

In one embodiment a buyer who is on a market place site and is interested in inquiring on a specific product that is displayed there, clicks on the link that had been generated by the proposed system is directed immediately to the system and a conversation window is immediately opened through which the buyer can start interacting via chat with the seller. The identity of the seller is not exposed to the buyer and the buyer does not have to be subscribed to the system and hence the buyer is completely unknown by the system. The buyer can receive the text responses from the seller and can choose to add voice to the conversation right in the same conversation window. Here the system uses the contact information of the seller and tries to make a voice connection between the buyer and the seller. The buyer can remain on the browser and start having voice conversations with the seller without having to know the phone numbers of the seller. Whether the seller is on a desktop browser or on a smart device using a browser or on a mobile phone using SMS and normal phone call, it remains completely hidden for the buyer.

The system that is proposed here envisions all interactions by the buyer using their browser that is enabled with html5 supporting audio, video and data. However the seller can be on a browser supporting the same capabilities or can use their mobile phone or even a landline. When the seller is on a landline the proposed system is aware that seller cannot be reached via SMS and hence lets the buyer know to add voice to the conversation.

In another embodiment the URL that is generated and published by the provider can itself indicate to the system to immediately connect the user with the provider using voice since the provider does not support a SMS medium (they have only a landline phone that does not support SMS).

In another embodiment the system enables provider to configure a phone number for SMS and voice and another phone number for voice only calls. In further embodiments the provider can configure up to even 5 phone numbers and all of them will be attempted by the system. In this embodiment the conversation window will support multiple people chatting where there can be more than one person on the provider side to assist the user who is inquiring about a service or a product.

In all these embodiments the common theme which is the core of this proposed invention is the ability to instantly generate a URL, publish them via various means and for users to instantly communicate with the providers through that URL without the users having to subscribe to any network or group and does not have to be related to the provider in any way. The interactions start as anonymous engagement which can at a later stage via sharing of the information through the medium provided by the system both the providers and users can get to know each other's information if there is a need. However the system does not require this and can enable completely anonymous interactions from the start to the end on the session.

In another embodiment a seller who is interested in advertising a product on craigslist, selects an option that is available on craigslist that allows for real-time interactions and there the seller enters contact information such as email and phone numbers and at the back-end the craigslist site uses an API (such as a REST (Representational State Transfer) API) to communicate with the proposed system, provides the information such as email and phone numbers and in response receives a URL that is presented as a hyperlink with the logo right on the site of craigslist advertisement for the provider. In this embodiment we can see that the information the provider had given is not visible on the advertisement but only the hyperlink to the proposed system. This hyperlink uniquely identifies the provider and the given contacts which is not exposed to the users visiting the craigslist advertisement.

While most of the embodiments presented here are marketplaces scenarios the proposed system can be used in other situations including party events, fundraisers, and in social media advertising and also in normal conversations placing the URL for immediate contact. The proposed system with its mechanisms also are independent of the market places themselves and do not have to be tightly integrated with any marketplace systems although that is a possibility.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The User Engagement System (UES) that is presented as invention here allows any individual or an entity (defined as a provider of a service or product) to sign-up with very basic identity information and instantly acquire a generated HTTP URL.

Through this URL the UES allows anyone on the internet in any context where this URL is displayed either explicitly or behind certain icons to engage in multi-modal interactions such as voice, video, data and media sharing with the provider of this URL.

The provider can be on the internet to engage with these interactions or can be on a phone, either mobile or landline as long as the provider has given these phone numbers with the UES. These contact information will remain hidden to the users who are engaging with the provider via the advertised URL. When the engagement of an internet user is with the provider who is on a mobile phone but only in a SMS and phone call and without internet connection, the engagement can still take place via SMS and Audio Call. In this engagement the provider is not signed-in into the UES as there is no internet connection. Even in such an engagement the Internet user who is engaging via the UES does not have to do anything different than when the provider is also on the Internet and is signed-in into the UES and handling the engagement via the browser.

FIG. 1illustrates a User Engagement Server100that consists of a Web Server103which is the first point of interaction for a provider who executes the browser119or120on a device and is able to sign-up with basic identity information and instantly able to acquire a URL from the URL Generator106within the UES100that runs on the Web Server103. In another embodiment a provider by executing a browser120on a device and from a marketplace website114is able to acquire a URL through API115with the Web Server103. In this instance the provider does not interact directly on the UES100site but rather is able to instantly acquire a URL so that users like112,113can engage with the provider once the URL is published on the marketplace website114. Whether the providers119or120sign-up with UES100directly via the UES website103or through an API115from another site114or111, their information is stored in the provider database105and accessed on a need basis. A provider119or120who has signed-up with UES via an API115will be able to directly access the UES100and sign-in with the same identity information given via the marketplace website114. In another embodiment, a provider119or120who already has a generated URL from UES100could visit any marketplace website111and publish directly this URL instead of sign-up via API from that site111. To be more concrete, in the case of advertising via craigslist the provider119can use the interface that the marketplace site114provides to acquire a URL via the API115with the UES100. This URL is automatically published in that marketplace advertisement. This is achieved via a integration of the UES100API with the marketplace website114. In another embodiment the same provider119who already has acquired a URL publishes another advertisement on the same marketplace site114and this time does not have to use the interface to fetch a URL but can directly set the URL on the marketplace site114. A User who is executing a browser112on a device visits one of the marketplace web pages111and wishes to contact the provider of an advertisement, clicks a URL seen on the web page111, access the UES100via the network110, the HTTP request reaches the Web Server103, using the URL that triggered the HTTP request, the Web Server103looks at the Provider Database105and finds the URL. Once the provider119is identified from the database105, a Session101is created for the user112regardless of the availability of the provider119. Associated with the Session101is a conversation between user112and provider119. If the provider119has not configured the UES100with a phone number and is also signed-in into the UES100and is not available to accept new requests, the user112can be immediately notified of the unavailability of the provider119after which the user112can be allowed to leave a text or voice message as per the capabilities of the UES100system. In one embodiment there can also be an email sent to the provider119using the Email Gateway121indicating the attempt from the user112assuming that the UES100has the ability to get a contact such as email from the user112as part of the established conversation. Extensions to this embodiment can involve a link to the ongoing engagement or session being sent in the email to the provider and the provider being able to use that and engage back with the user.

In another embodiment when a user113reaches UES100via a marketplace web page111, the provider116is identified and in this case the provider116has configured a phone number. The provider116is not signed-in into the UES100. Once the session101is created and conversation is initiated, through the phone gateway102a Short message is sent via the SMS Gateway117to the provider116. The user113is informed of the SMS connection as opposed to an chat/instant message with provider116. Here both the user113who is online and provider116who is on a mobile device can start texting each other although they can be in a completely different environment. In various embodiments the provider116can also be on a landline PSTN phone network or a VoIP phone network. All these embodiments highlight the instant access via a published URL (belonging to the provider116) to an anonymous user112visiting a marketplace web page111.

As part of the conversation that the UES100supports it can also allow the user113to initiate a voice call without having to know the phone number as the system100knows it and is residing in the provider database105. Here the voice call is established using the phone gateway102through the VoIP gateway118to the provider mobile device116. The voice session itself can be removed while in the conversation whereas the texting can continue. Either the user113or the provider116can choose to disconnect from the session at any point.

In another embodiment a user via the browser113in a device and from a web page111which in this case we can consider to be a marketplace site access the UES100via the Network110. The provider120sought after is signed-in into the UES and hence the provider120is presented with a conversation window right on the browser120window at the site UES100site via the Web Server103. Both the user113and provider120are in conversation, both being on the browser. Initially they exchange via text chat and the audio can be added and removed, also video can be added and removed. The provider120and the user113can also share other video streams in the conversation window supported by one embodiment of the UES100. For video streams and other media sharing such as pictures the content storage104offered by the UES100can be used or also external content can be accessed based on the capabilities of the UES100.

In all these embodiments we also see that any internet users112,113with a single click on the published URL can instantly engage with the provider regardless of the device used by the provider without these users having to know the identity of the providers for initiating an engagement. We also see that the users112,113and providers116,119,120need not be in any common user groups or networks. By instantly being able to generate URL106from UES100for their services/offerings, the providers116,119,120are quickly able to publish their contact identifier which is the URL in various web pages111and marketplaces114. In some cases the web pages111,114themselves via API115access UES100and acquire a URL for the providers.

In one embodiment the user executing a browser112on a device can be at a social network page111and in a profile of a person find the hyperlink for the URL that the person could have acquired earlier from UES100and then instantly engage with the owner of that URL which can be a provider119or120or116.

In another embodiment a user could have received an email with an embedded hyperlink containing the URL acquired from UES100. The user upon clicking the hyperlink in the email could be executing the browser113and engaging with the provider119.

In another embodiment, based on the ability of the UES100system to generate session url for the provider, can notify this URL to the provider via SMS (or email via Email Gw121) so that the provider116using a smart device can click the URL and transition to the browser120and access the same session and engage with the user113. It will be up to the system100to either allow the provider120to view only this session or in fact allow for login to the provider's account and access all sessions along with engaging in the current session.

In an environmentFIG. 1where Users are executing browsers112,113there are websocket connections from these browsers with the web server103. Similarly websocket connections exists from browsers120,119of the providers with the web server103. A WebSocket connection is a full-duplex communication channel over a single TCP connection. This is an existing technology that increasingly browsers are beginning to use today. The Users112,113upon clicking the URL first establish a https (Secure) connection with the Web Server103which also supports WebSocket and hence there is handshake between the Users112,113and Web Server103that transitions the https connection into a secure WebSocket connection. This WebSocket connection is used to exchange control signaling information which can be of any chosen format with the Web Server103. In one embodiment the control signaling information can be of JavaScript Object Notation. Similar exchange of control signaling exists between Web Server103and Providers119,120. However the connections are always initiated first by Users112,113to Web Server103and similarly by Providers119,120to Web Server103.

While the control signaling always goes through the Web Server103the media such as voice packets can flow directly between User112and Provider119in one embodiment. There can be other embodiments when the media between Users112,113and Providers119,120can be intercepted and forwarded by other server entities103. Overcoming firewall constraints at the user and provider premises using various security technologies are existing art and is assumed in this illustrationFIG. 1and other illustrations in this invention and for various embodiments described here as well as those that are not explicitly mentioned in this invention.

FIG. 2illustrates various (although not restricted only to these201-205) device and media combinations possible between user and provider devices for the engagement initiated by the usage of the URL by the User that had been generated by the provider in a particular context. Starting with a HTTP URL without any dependency or knowledge of the provider's identity nor the device nor any software dependency on the device of the provider, the user executing on a browser is able to engage with the provider on another device. The reference201indicates the combination where both the user and provider are executing a browser on their devices and all sorts of media is possible for this including text chat (instant messaging), voice, video, streaming and media sharing.

Whereas in201the provider was on a desktop or laptop in this202the provider is on a smart device such as a smart phone or a smart tablet. The user remains in either desktop or laptop or a smart device executing a browser.

The reference203is an embodiment where the provider is executing a smart app on the smart device that is able to interact directly with the UES100(FIG. 1). Here the smart app is a customized application that is able to interact with UES100and engage with users similar to what provider did with a browser. In all these embodiments201,202and203the user and provider can perform all rich media interactions. In the embodiment204the provider is on a mobile device with access only to SMS and Voice. There is no internet connection for the browser or an application to interact with UES100(FIG. 1). In this embodiment the engagement with the provider is via texting and voice. For texting the UES100(FIG. 1) communicates with the mobile device via SMS and for Voice there is a call made to the phone number of the mobile device. This phone number was registered by the provider with UES100(FIG. 1) in the sign-up process.

In the embodiment205the provider had given a PSTN phone number which is a landline device and which cannot receive SMS. In this case the user can engage with the provider via a voice call. The UES100(FIG. 1) can be capable of realizing the absence of SMS capability for this phone number and inform the user the inability to communicate via SMS with the provider after which the user can add video to the conversation session.

FIG. 3illustrates a sample sign-up user interface on a browser for a provider. In this the basic identity information such as a email301, password and its verification302and a nickname303that can be used for displaying to the user and provider for reference are required from the provider. The email301entered will have its backend verification such as is common in internet systems. It can involve a registration email being sent to that email and the provider confirming it. Another form of sign-up can also be via a pre-existing social network login306through which the UES100(FIG. 1) system can retrieve necessary identity information. The sign-up page can contain some form of introduction305to the provider who is signing-up or for anyone visiting the main web page of the UES100(FIG. 1) system. The UES100(FIG. 1) will ensure the email301entered is unique in the system and prompt the provider to supply that which is non existing in the system.

FIG. 4illustrates a sample profile section for a provider who has signed-in into the system UES100(FIG. 1). The profile shows Display Name401that which was entered during sign-up and which can be changed anytime by the provider. The profile also shows Phone Number402that is optional for the provider to enter. If a phone number is entered then the system UES100(FIG. 1) will try to contact the provider, if not already signed-in into the UES100(FIG. 1), to the phone number via SMS and Voice as chosen by the user who is trying to engage with the provider using a generated URL404. The modes of communication are given as options in403and which can be changed by the provider so that the user who is trying to engage with the provider will be allowed only these modes. Here in this embodiment403all the chat, voice and video is allowed by the provider although actual mode can be limited based on where the provider is reachable at a given time. This was illustrated inFIG. 2device and media combinations.

The generated URL404is displayed in the profile and which the provider can copy anytime and use them in different context such as on a marketplace website114(FIG. 1).

The provider can generate URL404again after which in one embodiment the previous URL gets outdated. In another embodiment the UES100(FIG. 1) shall be capable of supporting multiple URL404for the same provider. Other aspects of the profile such as privacy405and notifications406of information is also presented to the provider. The provider although signed-in407can choose to go offline408so as to avoid receiving incoming requests. Anytime the provider can sign-in407again and receive incoming requests from users. The provider can sign-off/logout409out of the UES100(FIG. 1) after which the provider can still be contacted via the phone number402if given by the provider.

FIG. 5is an illustration of a marketplace501(FIG. 1114, 115) where in this embodiment the marketplace is presenting the provider, who presumably does not have an account with UES100(FIG. 1), with a form and hence fills the form502presented which invokes an API (FIG. 1115) at the backend with the UES100(FIG. 1). The generated URL is retrieved via the API and gets displayed (FIG. 7, 702) on the same marketplace web page501. The information requested by the form502need not be exactly as shown in this illustration but also can request phone numbers (FIG. 4, 402) which gets usually configured in the profile. Once the provider fills the form502, the provider can also sign-in into the UES100(FIG. 1) using the same given credentials in the form502.

FIG. 6illustrates how an acquired URL601can be used in free form within a browser. This embodiment shows how a user who has this URL that is owned by a provider can use this URL directly on a browser and engage with the provider. The user could have access to this URL from an email received as part of a campaign by the provider in one embodiment, could have stored this URL in the contact maintained by a user for the provider in another embodiment. There are many other scenarios on how a user has handle to the URL owned by a provider.

FIG. 7is an embodiment similar to that of the illustration inFIG. 5except that here the provider who publishes this advertisement701in a marketplace, here trying to sell a car, actually has an acquired URL from the UES100(FIG. 1) and uses that URL directly702on the web page which allows hyperlinks to be embedded in the web page. This embodiment can be contrasted to that of the illustration inFIG. 5where an acquired URL via the form502(FIG. 5) is retrieved via a backend API115(FIG. 1) and will be displayed similar to702here. A user who is a prospective buyer upon visiting this advertisement can engage with the provider via the link702.

FIG. 8illustrates another marketplace where as shown a user is interested in purchasing shoes and finds a link803to interact with the provider to have further inquiries in real-time. The provider has made prior arrangements with the marketplace vendor to display contacts for the provider, here being the link803to UES100(FIG. 1). This facility of using the links803can be something that provider brings to the marketplace or the vendor of the marketplace itself can offer to the provider, similar to the embodiments ofFIG. 5andFIG. 7where in theFIG. 5it was the marketplace vendor who displayed the form502for the provider to have a backend API114,115(FIG. 1) interaction andFIG. 7(702) it was the provider who brought the link into the advertisement.

FIG. 9illustrates another embodiment where the URL903link for a provider is being posted either by the provider in one embodiment or by someone else in another embodiment into a social network web page. There can be various other embodiments where a social network has infrastructure to allow providers of various services to place advertisement in relevant sections of their web pages and these service providers advertise such URL903for the users in social network to engage with them. It is important to note that URL do not have to be exposed as in903but can be within images as illustrated in803(FIG. 8).

FIG. 10illustrates a conversation window for the engagement between a user and a provider. This is one specific rendering supported by the UES100(FIG. 1). The layout shown can be similar for the user and provider although in one embodiment the provider has more controls whereas in another embodiment it is possible that user has more controls. However all these will be configured by the provider in the UES100(FIG. 1). In this specific illustration we can see that there is a welcome page1001, various other sharing tabs such as repository1002, directions1003, scheduling1004, address book1005and conversation history1006. The modes shown in this illustration are Chat1007, Voice Call1008and Video Call1009. Typically it is the user who initiates the engagement starting from the URL and hence can start adding Voice1008and Video1009to the conversation. In this embodiment the engagement starts with the Chat1007and can continue along with other modes such as Voice1008and Video1009. In this embodiment we can see that the page1010displays the advertisement such as701(FIG. 7) so that both the provider and user are aware of the context of the conversation. In another embodiment the provider can describe parts of the car in more detail in real-time with the Video (Webcam)1009which the user could not have seen in an advertisement701(FIG. 7).

FIG. 11is a continuation ofFIG. 10where in this embodiment the provider shares in real-time the video1102of the car1010(FIG. 10). This illustrates the importance of a real-time engagement that the provider can leverage and assist the prospective buyer in addressing the questions that cannot be achieved in a static advertisement page701(FIG. 7)

FIG. 12illustrates the SMS mode of engagement by the provider. When the user clicks on a URL such as in702(FIG. 7), the user lands in a conversation window where the user can type in text on the chat window1007(FIG. 10). This text1203(FIG. 12) along with an initial header message1202appears on the device of the provider receiving the SMS. The text that provider types such as1203will appear on the chat window1007(FIG. 10) for the user. The calling number1201on the provider device can already be configured as a service number in a contact of the address book so that the provider knows that this SMS originates for a service. The information in the initial header message1202helps provider to be aware of the context of this SMS.

FIG. 13illustrates an incoming call on the device of the provider. The calling number which the provider can know in one embodiment based on the capabilities of the UES100(FIG. 1), can be configured as a contact1301,1303in the device of the provider. A user on the conversation window can add voice1008(FIG. 10) to the conversation along with the ongoing chat which is SMS on provider's device and that voice shows up as an incoming call1302on the provider's device.

FIG. 14flowchart illustrates the steps involved for a provider to post an advertisement in a marketplace such as craigslist.org using the generated URL acquired from UES100(FIG. 1). In one embodiment1413the provider visits the UES100(FIG. 1) site, signs-up there and gets access to the URL that the provider now owns. This provider visits the marketplace such as craigslist.org in this embodiment and posts an advertisement1402. In that web page the provider is requested (1403) if there is a need for a Contact ID towards a better user engagement with his clients. This provider in one embodiment declines (1405) as the provider already has a URL and intends to use it. The provider inserts the already acquired and owned URL (1416) into the web page (1411) and it appears like702(FIG. 7) in one embodiment but it can appear within an icon as well such as shown in803(FIG. 8) in another embodiment. If the provider chooses to use the web page option1403to instantly acquire another URL, the provider can enter a different identity on the form1407such as a different email address that the provider owns and using the backend API1408the marketplace webpage fetches a new URL1409for the provider which gets posted on the webpage. In another embodiment based on the capability of the UES100(FIG. 1) and hence the API1408the provider can enter the same information which the provider uses to sign-in into the UES100(FIG. 1) system and here acquire a different URL1409. In one embodiment the UES100(FIG. 1) is capable of generating new URL and replacing older ones and in another embodiment it can even support multiple active URLs for a provider.

FIG. 15illustrates a user visiting1501the marketplace and engaging with the provider through the system UES100(FIG. 1) which is one embodiment of a system that is necessary to support the methods and mechanisms that is presented in this invention.

After searching and finding an advertisement1502the user goes through the advertisement page and has more inquiries and hence clicks1503the displayed URL702(FIG. 7) which initiates a new conversation window1504. In order to keep the user aware of the context in one embodiment the conversation window displays the web page1505that the user arrived from which here is the advertisement posted by the provider. If the provider is online1507and signed-in into the system UES100(FIG. 1) then a Chat Tab1508is displayed to the User. The user shall start engaging with text chat1509and then later add and remove voice and video1510to the same conversation with the provider. If however the provider is offline1512the user is presented with a SMS Tab1513and the user can start engaging1514with text chat although the provider is on a mobile handset in one embodiment. Based on their mutual understanding the user can initiate a voice1515with the provider while they can continue to chat both ways. What this illustrates is that, with a click of a URL the user is able to experience an engagement with the provider regardless of the location of the provider.

FIG. 16illustrates how a provider handles an incoming request through a published URL in a marketplace1601. The experience for the provider depends on whether the provider is signed-in into the system UES100(FIG. 1) or not. When signed-in and ready to receive incoming requests for engagement1609the provider is given a conversation window1610for an incoming request. In one embodiment the provider can receive only one outstanding request whereas in another embodiment based on the capabilities of the UES100(FIG. 1) the provider can simultaneously be given more than one incoming request and hence more than one conversation window. On the conversation window the provider can start1611text chat, add and remove voice and video and in one embodiment be able to see the web page from which the user is calling so that the provide can be aware of the context of the incoming request. Based on the interaction and the need for the user the provider can share some real-time videos1612with the user. If however the provider is not signed-in into the system1604the provider gets an SMS1605on a device with phone number402(FIG. 4) that the provider has configured with the system UES100(FIG. 1). In this SMS based on the capabilities of the UES100(FIG. 1) additional information such as the public name of the provider shall be presented so as to make the provider aware of the context of the SMS. In one embodiment the provider could have stored the calling number1201(FIG. 12) of the SMS as a Contact and hence a name1301(FIG. 13) shall appear instead of the phone number so that the provider knows the SMS context. While the text chat continues with user on the internet and provider with a SMS capable device, the user can initiate a voice call1606to the same device that the provider is using and they both can now continue with voice as well as chat. Based on the capabilities that UES100(FIG. 1) offers the provider can get online and continue the engagement with the user. This illustrates various options and flexibility that the provider has in being engaged with a user who starts with a URL702(FIG. 7) found in a marketplace.

The invention presented here incorporates several embodiments and it should be evident for those skilled in the same art that various other embodiments are possible and can be practiced. Various components within UES100(100thru106,121) referred in the main illustrationFIG. 1are used to convey one form of implementing the overall solution that is required to support the invention presented here. Using similar components or a combination of these alternate ways of implementing the solution presented in this invention can be achieved. Other external components such as SMS Gateway117, VoIP Gateway118can manifest themselves either as a single or multiple components in different embodiments. In summary the components within UES100and those outside such as SMS Gateway117, VoIP Gateway118can exist in different forms and combinations and can all be software-based components or some of them can also exist as hardware components.

Within this written description, the particular naming of the components, capitalization of terms, the attributes, data structures, or any other programming or structural aspect is not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, formats, or protocols. Further, the system may be implemented via a combination of hardware and software, as described, or entirely in hardware elements. Also, the particular division of functionality between the various system components described herein is merely exemplary, and not mandatory; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component. For example, the particular functions of the session manager101, URL Generator106, Phone No Gateway102, and so forth may be provided in many or one module.