The present disclosure generally relates to the field of providing service, and in particular, the present disclosure relates to method and system for enabling real-time interactive services .

BACKGROUND OF THE DISCLOSURE

Owing to the fast tracked digitalized that has happened in the past decade, most of the products and service providers have made their products and services available online. Not just the ordering and delivery of the products, but the process of rendering of services relating to such products and their maintenance has also been digitalized. However, the current methods for consumption of the products and services are cumbersome and time intensive. Facilities like Interactive Voice Response System (IVRS), though digital, require huge amount of investment of the resources from the service provider as well as the users. Often, the waiting times in the IVR systems is inordinate and requires a user to patiently wait for a computerized voice to spell out all options before the user can make a selection. Further, on the service provider end, this puts a logistical burden as they have to put an army of executives (often hierarchical) for assisting the availing the requested services.

In certain other scenarios, chatbots are used for eliciting a generic query from the user and based on techniques such as Natural Language Processing (NLP), the chatbots guide the users regarding the procedures for availing the requested products and services. However, a major limitation with such chatbots is scalability and accurate comprehension of a users’ interest. While the chatbots may work well in for operations such as registering a complaint or booking an appointment, they fall short of being able to efficiently scale up for handling end-to-end workflows for a product and service provider. Other technologies mandate a user to log into a company’s portal and by use of predefined workflows and dedicated user interfaces, place an order for a product or a service. Another challenge with the systems discussed above is the security. Most of the systems currently being used require a user to provide a one or more input credentials for authentication and the session for the user, once initiated, remains active for the length of the transaction. This allows the entities with mal-intent an opportunity to exploit and leverage the network vulnerabilities and take control of an ongoing session for affecting rogue transactions.

In light of the above, there is a pressing need for having a solution optimizes the utilization of resources such as work force and time for handling the process of providing products and services. The optimization needs to happen at the end of the product and service provider as well as the user intending to consume the products and services. Further, there is an acute need to provide flexibility to the users to tailor their orders basis their requirements, which may be based on their changing preferences and/or environment and are thus transient and dynamic in nature. Furthermore, there is a need for a system and a method for enabling real-time interactive services as well as an added layer of security above the existing layers provided by the technologies that exist.

SUMMARY OF THE DISCLOSURE

The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

The present subject matter discloses a method and a system for enabling real-time interactive services. The method for enabling real-time interactive services comprises various steps to enable the real-time interactive session between the user and a target product or service provider through a service management platform. In first step the user is registered over the service management platform. Further, the service management platform is configured to generate the customer user identification (CUID). Further the plurality of product or service providers are registered on the service management platform. The service management platform is configured to enlist products or services offered from the plurality of product or service providers. The service management platform is configured to receive a request or an order from the user for the target product or services offered by the target product or service provider from the plurality of product or service provider. Further, the service management platform is configured to establish communication with the target product or service provider from the plurality of product or service providers based on the request or the order. Furthermore, the real-time interactive session between the user and the target product or service provider is enable for fulfilling the request or the order of the user based on the customer user identification (CUID).

These and other features and advantages of the present disclosure may be appreciated from a review of the following detailed description of the present disclosure, along with the accompanying figures in which like reference numerals refer to like parts throughout.

BRIEF DESCRIPTION OF DRAWINGS

This disclosure will be more fully understood from the following detailed description taken in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates an exemplary environment in which various embodiments of the present disclosure can be practiced.

FIG. 2 is a method flowchart for registering a user with the service management platform, according to an example embodiment of the present disclosure.

FIG. 3A is a method flowchart for registering a request for a product or a service on the service management platform, according to an example embodiment of the present disclosure.

FIG. 3B is a method flowchart for registering a request for a product or a service relating to amusement of a user on the service management platform, according to an example embodiment of the present disclosure. FIG. 4 is a method flowchart for generating a customer user identification (CUID) for a user using the service management platform, according to an example embodiment of the present disclosure.

FIG. 5 is a method flowchart for automatic generation and submission of details pertaining to a user request using the service management platform, according to an example embodiment of the present disclosure.

FIG. 6 is a method flowchart for registering a product and service provider with the service management platform, according to an example embodiment of the present disclosure. FIG. 7 is a method flowchart for notifying a product and service provider about the registered using the service management platform, according to an example embodiment of the present disclosure.

FIG. 8 shows an exemplary system for providing a service management platform, according to an example embodiment of the present disclosure.

DETAILED DESCRIPTION OF THE DISCLOSURE

The present disclosure will now be described more fully with reference to the accompanying drawings, in which embodiments of the present disclosure are shown. However, this disclosure should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art. In the present disclosure, like-numbered components of various embodiments generally have similar features when those components are of a similar nature and/or serve a similar purpose.

The terms "a" and "an" herein do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item.

The term "having", "including" and "comprising" herein refer to inclusion of at least one of the referenced items. FIG. 1 illustrates an exemplary environment in which various embodiments of the present disclosure can be practiced. The exemplary environment comprises a service management platform 102, a user 104, and a plurality of product or service providers (PSPs) - IO6 ₁ , IO6 _{2, ...} 106 _n . In an implementation, the user 104 may interface with the service management 102 by use of the electronic device 108, which may include, but are not limited to, a desktop, a laptop, a personal digital assistant (PDA), and the like.

In one embodiment referring to the Fig. 1, a method for enabling real-time interactive services is disclosed. The method comprises various steps to enable the real-time interactive session between the user 104 and the target product or service provider for fulfilling the request or the order of the user 104 based on the customer user identification (CUID) through the service management platform 102. The service management platform 102 may be configured to register the user 104. Further, the service management platform 102 may be configured to generate the customer user identification (CUID). Further the PSPs IO6 ₁ , IO6 ₂ , ...106 _n are registered on the service management platform 102. The service management platform 102 may be configured to enlist products or services offered from the PSPs IO61, IO62, ...106 _n . The service management platform 102 may be configured to receive a request or an order from the user 104 for the target product or services offered by the target product or service provider 106 _t from the PSPs IO6 ₁ , IO6 ₂ , ...106 _n . Further, the service management platform 102 may be configured to establish communication with the target product or service provider 106 _t from the PSPs IO6 ₁ , IO6 ₂ , ... 106 _n based on the request or the order. Furthermore, the real-time interactive session between the user 104 and the target product or service provider 106 _t is enable for fulfilling the request or the order of the user 104 based on the customer user identification (CUID).

Further, each of the plurality of PSPs 106i, IO62 _{, ...} 106 _n may provide a one or more products and services which may be registered on the service management platform 102. The one or more products may include, but are not limited to, electronic items, electrical appliance, banking products, medical products, travel bookings, online subscriptions, food delivery, and the like. The one or more services may correspond to the product offerings of a PSP (like PSP IO6 ₁ ) and may be specifically directed to services that include, but are not limited to, providing maintenance and feature enhancements, and the like. A person of ordinary skill in the art will appreciate that each of the PSPs 106i, IO6 _{2, ...} 106 _n may correspond to one or more users or an administrators representing a PSP. The request for service and products are managed by the administrators based on their interaction with the service management platform 102. Further, each of the PSP from the PSPs 1061, 1062, ... 106n may be associated with a dedicated database for storing the transaction details or the metadata associated with the transactions.

In operation, the service management platform 102 may provide an interface on the electronic device 108 of the user 104 for registering with the service management platform 102. In an implementation, the interface may be available to the user on cloud that can be accessed using the electronic device 108. In another implementation, the interface may correspond to an application programming interface (API) which can be downloaded on the electronic device 108.

In order to register with the service management platform 102, the user 104 may provide one or more personal details to the service management platform 102. Such details may include, but are not limited to, an identification, one or more addresses of the user 104, one or more products used by the user 104, one or more documents associated with purchased products or availed services, one or more preferences, one or more interest, and the like.

On similar lines, the service management platform 102 may provide one or more dedicated interfaces to each PSP for registering the products and services provided by each of the PSPs on the platform. Using the one or more dedicated interface (cloud-based or downloadable API), an administrator of a PSP (such as the PSP 106i) may enlist all the products and services offered by the PSP. The enlisted products and service may be rendered by the service management platform 102 on the electronic device 108 of the user 104 during the interaction between the user and the platform. In an implementation, a registered user 104 may launch the interface of the service management platform 102 and may provide one or more user inputs for initiating the session. The user inputs may include, but are not limited to, one or more pre-defined keywords, one or more codes, one or more biometric samples, one or more gestures, and the like. The session may be initiated with the intent of placing an order for a product, availing a service, and/or fetching information regarding a listed product or a service. Based on the receipt of the session initiation request the service management platform 102 may render a list of products and services on offer by the plurality of PSPs 106i, IO6 _{2, ...} 106 _n . Each of the product and service may be associated with a pre-defined code. The menu options rendered to the user 104 may be refined basis the combination of one or more pre-defined codes received from the user 104.

In an implementation, the registered account of the user 104 may remain in a dormant state unless activated by the one or more inputs. The service management platform 102 upon receiving the one or more inputs for initiating the session may activate the account of the user for a pre-defined time interval post, which the account will become dormant once again.

In another implementation, the service management platform 102 may be reachable by the user by means of a chat option offered by the API. To this end, the service management platform 102 may provide each user with a dedicated identifier (or a number) for initiating a session. For example, user A may be provided a contact “1234” which may be save on the electronic device contact list, whereas a user B may be provided a contact “6789”. Upon pinging the contact “1234” on the chat window of the API, the user A may be required to provide one or more inputs for initiating the session. Similarly, the contact for the user B would be “6789”. Such a customization in the contact allows for added privacy as each user can have a dedicated and customized contact number for initiating a session, whereby the integrity of the account of the users is maintained even if the electronic device associated with a user is misplaced. Further, the service management platform 102 may allow each PSP to create one or more templates for facilitating the placement of order for products and services. Once finalized, the templates may be assigned a specific identifier and may be presented to the user 104 during a session. The one or more templates may include, but are not limited to, forms, layouts, blueprints, and the like.

In an implementation, the user 104 may provide one or more inputs pertaining to the identity of the user 104. Such inputs may include, but are not limited to, one or more documents, location details of the user 104, one or more preferences associated with the user 104, and the like. Basis the one or more inputs, the service management platform 102 may generate a customer user identification (CUID, hereinafter) for the user 104. In an alternate implementation, a user 104 may provide multiple distinct inputs so as to be able to generate a plurality of CUIDs. For each of the users registered with the service management platform 102, CUIDs may be stored in the user database. In a scenario, when the user places a request for ordering a product or availing a service related thereto, the service management platform 102 may use one or more stored CUIDs associated with the user and link it with the order placed. In another scenario, the service management platform 102 may prompt the user to select a specific CUID for placing the request. In an alternate embodiment, the service management platform 102 may generate a location user identification (LUID) which may be used by the user to provide to the PSP for servicing a requet placed by the user. The LUID may provide the location details of the user to the PSP.

In a scenario, based on the one or more inputs provided by the user 104, the service management platform 102 may automatically retrieve the CUID of the user 104 along with other details. The CUID and details may be used to automatically populate the fields in the one or more templates and the populated template may be rendered to the user 104 for approval before submission. An order for delivery of a product or a service from a specified PSP may be placed basis the approval provided by the user 104. Once a request for a product or a service is registered by the user 104, the service management platform 102, by use of the one or more dedicated interfaces for PSPs, may notify a PSP best equipped for handling the request. Further, the service management platform 102 may execute a service level agreement (SLA) with the user 104 upon submission of the request. At each step of the delivery of the product or service, the service management platform 102 may track the SLA in terms of time taken and feedback provided by the user 104 on the request. In scenarios, when any of the SLA is violated, the service management platform 102 may automatically escalate the request to a higher-level administrator associated with a PSP, which was tasked with the delivery of the product or service mentioned in the user request.

In one embodiment the service management platform 102 is configured to send an encrypted CUID on the electronic device 108 of the user 104 to facilitates secure communication between the user 104 and the service management platform 102. Further, the encrypted CUID may be decrypted by entering one or more keys by the user (104).

In one embodiment the user 104 may be configured to communicate with the service management platform 102 using a plurality of communication channels. Further, the plurality of communication channels may comprise text, voice, and combination thereof. Further, the service management platform 102 may be configured to encrypt messages that are transmitted through the communication channels to the electronic device 108 of the user 104. The service management platform 102 may be configured to choose the communication channel as per the input from the user 104. The service management platform 102 may be configured to send messages in encrypted form. The user 104 may be configured to enter a secret key to decrypt the messages sent over the communication channel. The user 104 may be configured to enter the secret key by using an eye retina scanning, a fingerprint scanning, and a face scanning. In one embodiment the application programming interface (API) configured to stay in inactive state. Further, the user 104 may be configured to activate the API by entering the secret keys.

In one embodiment the service management platform 102 may beconfigured to send a service code to the user 104 after successful verification of passwords receive from the user 104.

The methods disclosed below may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform particular functions or implement particular abstract data types.

The order in which the methods disclosed below have been described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.

FIG. 2 is a method flowchart for registering a user with the service management platform, according to an example embodiment of the present disclosure. With reference to FIG. 2, there is shown a flow chart 200. The flow chart 200 is described in conjunction with FIG. 1. The process starts at step 202 and proceeds to step 204.

At step 204, the service management platform 102 receives one or more keywords from the user 104. In an embodiment, the one or more keywords may include a string (such as “Hello”) to trigger activation of a session between the user 104 and the service management platform 102. Upon receipt, at step 206, the service management platform 102 determines whether the user 104 is already registered with the system, at step 204. In scenarios, when the user 104 is already registered, the control passes to step 302 of FIG. 3 A. In scenarios, when the user 104 is not registered, the control passes to step 208. As step 208, the service management platform 102 may request the user 104 to provide details specific to the user that include, but are not limited to, one or more identification documents, one or more products or services used, one or more documents associated with purchased products or availed services, one or more preferences, one or more interest, and the like. In an embodiment, the one or more identification documents may include identification issued by one or more of a government authority, a regional authority, the service management platform 102, and an organization. Further, the one or more documents associated with purchased products or availed services may include an invoice, a maintenance contract, billing details, and one or more snapshot for identifying a product. Further, the service management platform 102 may be configured to receive at least one personnel detail of the user 104. The at least one personnel detail comprises a unique identification number, one or more addresses of the user 104, one or more products used by the user 104, one or more documents associated with purchased products or availed services, one or more preferences, and one or more interest.

As step 210, the service management platform 102 may be configured to verify the one or more registration details of the user from each of the service providers The service management platform 102 may be also configured to confirm the at least one personnel detail of the user 104. The service management platform 102 may be communicate with an issuning authority of the at least one personnel detail to authenticate the same. For example, the user 104 may be entered an account number of a HDFC bank. The service management platform 102 may be communicate with a FIDFC bank to authenticate the account number of the user 104.

In an embodiment, the service management platform 102 may further utlize the identification of the user 104 provided by the network provider and the device manufacturer for completing the regiatration. For example, in an exemplary scenario, the service management platform 102 may make use of Mobile Station Integrated Services Digital Network (MSISDN) and the International Mobile Equipment Identity (IMEI)of the electronic device 108 of the user 104 for completing the registration. Once registered, the service management platform 102 may validate each incoming request from the user 104 against the MSISDN and the IMEI. In a scenario, when the user 104 changes the contact number (MSISDN) and intends to access the account from a new MSISDN, the service management platform 102 may first authenticate the user using CUID (discussed in detail in FIG. 4) and then request the user 104 to authorize the the de-link. Once de-linked, the service management platform 102 may link the new MSISDN of the user 104 with the registered account.

Similarly, in case the user 104 attempts to access the registered account from a new electronic device, the service management platform 102 may perform the de-linking of the older IMEI from the account and link the new IMEI, in a manner similar to the one discussed with respect to MSISDN. In another embodiment, the service management platform 102 may receive a list of one or more trsuted electronic devices from which a valid request can be submitted for an order relating to a product or service. The above mechanism allows for additional security to prevent any rogue and un-authorized entity from accessing user’s account in an even of loss or change of the electronic device or the registered mobile number.

At step 212, the service management platform 102 may register and store the details provided by the user 104 in a user database (details mentioned in FIG. 8) and may notify the user about the successful registration. The control passes to end step 214.

FIG. 3A is a method flowchart for registering a request for a product or a service on the service management platform, according to an example embodiment of the present disclosure. With reference to FIG. 3A, there is shown a flow chart 300a. The flow chart 300a is described in conjunction with FIG. 1. The process starts at step 302 and proceeds to step 304.

At step 304, the service management platform 102 receives one or more keywords from the user 104. In an embodiment, the one or more keywords may include a string (such as “Hello”) to trigger activation of a session between the registered user 104 and the service management platform 102. At step 306, the service management platform 102 may activate the session of the registered user 104.

At step 308, within an interface associated with the activated session, the service management platform 102 may present a plurality of menu options to the user 104. The menu options may comprise one or more products and services which may be order by the user 104. The presented menu options may be categorized based on one or more metadata associated with the products and services. In an embodiment, the metadata may include, but is not limited to, make of a product, service provider, type of a product, type of service, interest of the user 104, preferences of the user 104, historical purchase history of the user 104, average rating of the products and service, sponsorship arrangement between the service provider and the service management platform 102, time of the day or year, an ongoing sale or offer, and the like. Further, the service management platform 102 may provide one or more options to the user to choose one or more filters for arranging the listed products and services based on the metadata categories discussed above.

In an embodiment, for each of the menu options presented to the user, the service management platform 102 may also communicate a corresponding code to the user 104 for selecting a menu option. The code may include a combination of alphabets, numerals, and/or special characters. In an embodiment, the presentation of the aforesaid codes may be customized for each user at least based on their language preference, ethnicity, physical status, the kind of electronic device 108 being used by the user 104, and the mode in which the electronic device is being used. For example, for an activated session for a user 104 travelling in a car or for a differently abled user 104, the mode of presenting the menu options may be based on audio. For a user belonging to India, the menu options and corresponding codes may be based on Devanagari script, whereas for an Arab resident, the menu options and corresponding codes may be based on Arabic.

In another embodiment, the user 104 may be presented an interface whereby the user is able to specify a preferred code for a listed menu item. This customization enables the user 104 to specify codes which they can remember so that in case the electronic device 108 is misplaced or lost, no other user is able to initiate a session and perform transactions. As an example, for a banking PSP, for each of the listed menu items, such as mutual funds, fixed deposits, services associated with maintenance and upkeep of accounts account, a user “ABC” may specify the codes as MF*ABC#, FD*ABC#, MAINT*ABC#, respectively. Further, the codes the service management platform 102 may allow the user to change the codes mentioned above at any time. To this end, the service management platform 102 may make use of the CIUD of the user 104 for authentication and authorization for servicing such a request. Upon receiving the customized code from a user, the service management platform 102 may service the request based on validation of one or more of the contact number of the user, CUID code, CUID.

At step 310, the service management platform 102 may receive one or more selected codes corresponding to the preferred menu option, from the user 104. At step 312, the service management platform may iteratively generate one or more other menu options and the corresponding codes until the user 104 selects a product or a service. At step 314, based on the selection of the product or service, the service management platform 102 may generate one or more details corresponding to the order and seek order confirmation from the user 104. At step 316, the service management platform 102 may receive one or more inputs from the with regards to the CUID of the user. The details of an exemplary request have been explained in detail in FIG. 3B. The details of the CUID have been explained in detail in FIG. 4.

At step 318, the service management platform 102 may finalize the details of the order of the user 104 and may communicate the details to an administrator of a PSP (such as PSP 106i) associated with the selected product or service. The details communicated to the PSP 106i may be displayed on an interface of the PSP 106i that corresponds to the selected product or service (explained in detail in FIGs. 6 and 7 of the following disclosure). In an embodiment, for selection of a PSP that is to service the order, the service management platform 102 may consider one or parameters that include, but are not limited to, proximity of the PSP to a user’s location, turn-around-time, repurtation, one or more preferences specified by a user.

Further, the service management platform 102 may communicate the metadata of the request to the PSP which may be stored in a dedicated database associated with the PSP. The metadata may include, but is not limited to, a request timestamp, CUID, CUID code (discussed in detail in FIG. 4), historical request data associated with the requesting user. The metadata may further be stored in the memory or the dedicated database associated directly with the service management platform 102.

In an embodiment, in the event of lack of network connectivity, the service management platform 102 may further notify the placement of the order via short messagin service (SMS). Further, upon restoration of the connectivity, the details may be imported directly from the SMS into the interface presented to the user for placing the order. The control passes to end step 320.

FIG. 3B is a method flowchart for registering a request for a product or a service relating to amusement of a user on the service management platform, according to an example embodiment of the present disclosure. With reference to FIG. 3B, there is shown a flow chart 300b. The flow chart 300b is described in conjunction with FIGs. 1 to 3A. The process starts at step 322 and proceeds to step 324.

At step 324, from the menu list presented to the user, a selection for “play and win” may be received. At step 326, basis the receipt of the request above, the service management platform 102 may credit a pre-defined amount of reward points that may be assigned some monetary value based on a pre-defined conversion rate. The credit may be made to a centralized pool. In an embodiment, while making this transaction a transaction identification may be generated. The transaction identification may be treated as winning identification for the user 104, if this winning identification matches with any details of that user saved in the system. The details may be retrieved from the CUID. In an embodiment, winning identification may include, but is not limited to, a combination of numeric, alphanumeric, special characters and symbols. In an embodiment, the user 104 transaction identification may specified by the user 104 for submission of the “play and win” request. The transaction identification may be derived from personal information of the user that includes, but is not limited to, date of birth, marriage date, vehicle number, driving license number, government identification number, a card Number, and the like. After specifying the transaction identification, the user 104 may request for generation of a code which may be used for matching with the winniing identification. On the basis of lucky code generated by the service management platform 102, the user will have chance of getting rewarded on the basis the matching. The service management platform 102 may further provide a customized facility under which the user may select a portion of the identification or the code which is to be matched. Accordingly, the service management platform 102 may calibrate the reward amount basis the extent of match between the identification or the code and the winning identification. The reward points may also be varyied as per user document type or reward points decided by the service provider. For example, the mechanism applies on the basis of digits matches with profile; if more digits matches with winning id the user will get more reward points.

At step 328, the service management platform may determine whether the user 104 is the winner. In scenarios, when a user becomes a winner the control passes to step 330. In scenarios, when a user becomes a winner the control passes to step 338.

At step 330, the service management platform 102 may debit a portion of the reward points from the pool account and credited the same to a hidden account. At step 332, the service management platform 102 may wait for a pre-defined time interval in which the reward amount can be claimed or redeemed by the user 104. In scenarios, when the user 104 submits a request for redemeption within the pre-defined time interval, the control passes to step 334. In scenarios, when the user 104 does not submit a request for redemeption within the pre-defined time interval, the control passes to step 336. At step 334, upon receipt of the redemption request, the service management platform 102 may debit the reward points from hidden account and credited it to user’s account. At step 336 the reward points may be reverted to pool account by debiting the hidden account with the reward points and crediting the same to the centralized account. The control passes to end step 338.

FIG. 4 is a method flowchart for generating a customer user identification (CUID) for a user using the service management platform, according to an example embodiment of the present disclosure. With reference to FIG. 4, there is shown a flow chart 400. The flow chart 400 is described in conjunction with FIG. 1. The process starts at step 402 and proceeds to step 404.

At step 404, upon receipt of a selection input for placing an order for a product or a service, the service management platform 102 may determine whether there is any CUID associated with the user 104. In scenarios, when it is determined that no CUIDs are associated with the user 104, the control passes to step 406. In scenarios, when it is determined that one or more CUIDs are already associated with the user 104, the control passes to step 414.

At step 406, the service management platform 102 may present one or more options to the user 104 for generating a CUID. At step 408, for generating the CUID, the user 104 may provide one or more inputs pertaining to the identity of the user 104. Such inputs may include, but are not limited to, one or more documents, location details of the user 104, one or more preferences associated with the user 104, and the like. In an embodiment, the one or more identification documents may include identification issued by one or more of a government authority, a regional authority, the service management platform 102, and an organization. The location details may correspond to the location of the user mentioned in the one or more identification documents. The one or more preferences may include a preferred time for delivery, a preference associated urgency pertaining to the delivery, a preference associated with the nature of product being delivered (office specific or for household purpose), a preference corresponding to delivery instructions in case of unavailability of the user 104 at said location, and the like. In an embodiment, the inputs may also include one or more preferred payment modes of the user 104.

At step 410, the service management platform 102 may generate a customer user identification (CUID) for the user 104 basis the received one or more inputs. In an embodiment, the CUID may correspond to a Quick Response (QR) code, a bar code, an alphanumeric key, an private key, and the like. At step 410, the service management platform 102 may store the generated key in the user database, which may be retrieved whenever an order for a product of service is finalized by the user 104. In an embodiment, the stored CUID may be encrypted based on one or more keys and/or biometric information provided by the user 104. Further, the CUID may also be presented to the user 104 for being downloaded to the electronic device 108. In an alternate implementation, a user 104 may provide multiple distinct inputs so as to be able to generate a plurality of CUIDs. For each of the users registered with the service management platform 102, CUIDs may be stored in the user database.

In an embodiment, the generation of the CUID may further comprise generation of a dedicated code that corresponds to the contact details of the user 104. As an example, for a generated CUID, a code such as ABX#500* (hereinafter, CUID code) may also be generated. Such a code may be an amalgamation of the contact details of the user. Further, such a code may also substitute the network operator or internet service provider identification. Instead of using the conventional contact details such as phone numbers, email, social networking handles, the user may simply share the CUID code with other user and the respective network provider. The other users may save it in their contact lists on associated electronic devices. When the other users intend to contact the user 104, they may simply tap (or click) the CUID code of the user 104 basis which, the network provider may cross-reference the CUID code with the actual contact of the user and may accordingly facilitate establishing a communication session between said users. In an embodiment, when the contact details, such as the contact details such as phone numbers, email, social networking handles are updated, the service management platform 102 may automatically update the CUID code of the user 104. Further, the updated CUID codes may be automatically (via a background synchronization) update the contact lists of all the users that may have stored the CUID code of the user in their contact lists.

In an embodiment, the the service management platform 102 may facilitate generation of a plurality of user identifications (UID) that may contain one or more subsets of information contained in the CUID. For example, the user 104 may generate a dedicated UID that include one or more of social media details, address details, form filling details, bank details, educational details, vehicle details, property details. The UID capturing the social media details may be a social media UID (SMUID), address details may be contact UID (ConUID), the form filling details may be a forma filling UID (FFUID), the bank details may be a banking UID (BUID), educational details may be a qualification UID (QUID), vehicle details may be a vehicle UID (VUID), property details UID may be a asset UID (AUID).

In an embodiment, the user 104 may use each of the UIDs discussed above in specific scenarios. For example, the ConUID may be used for sharing contact information with another user; the SMUID comprising details of users’ account on social media platforms may be used for sharing social media information with another user; the BUID may be used for sharing banking information with another user; the VUID may be used for sharing vehicle information with another user or platform (say for renewing insurance); and the PUID may be used for sharing property information with another user or platform (say, during home loan application, property tax payment, and the like). Upon sharing the UIDs mentioned above, the respective platform consuming the UIDs may extract relevant information corresponding to the fields for which data is readily available from the UIDs. In a scenario, when the data for the fields is not available, the service management platform 102 may generate a prompt for the user 104 using the missing data can be provided by the user 104 in real-time. Furthermore, just the way CUID is automatically updated in the registry of the users who may have saved the CUID, in the same manner, any updates made to the UIDs discussed above will be automatically updated in the instances of the UIDs of the user 104 stored in the contact lists of other user and/or the respective databases. A person of ordinary skill wil appreciate that virtue of the above, the overhead induced by manual entry and sharing of the specific details of the user 104 will be circumvented as the details will no longer have to be keyed in manually. Further, the segregation of the user information across various UIDs facilitates requisite data privacy so that only relevant details are shared with the stakeholders involved in a transaction.

At step 414, the service management platform 102 may retrieve the CUIDs from the database (explained in FIG. 8) and present to the user for selecting a preferred CUID. In an embodiment, the service management platform 102 may request the user 104 to provide one of the downloaded CUIDs for confirming the order. In another embodiment, the service management platform 102 may request one or more keys from the user 104 for decrypting an encrypted CUID retrieved from the database. In yet another embodiment, the service management platform 102 may request the user 104 to provide a private key for decrypting the retrieved CUID. The control passes to end step 416.

FIG. 5 is a method flowchart for automatic generation and submission of details pertaining to a user request using the service management platform, according to an example embodiment of the present disclosure. With reference to FIG. 5, there is shown a flow chart 500. The flow chart 500 is described in conjunction with FIG. 1. The process starts at step 502 and proceeds to step 504.

At step 504, the service management platform 102 may receive one or more inputs from the user regarding the CUID to be used for placing an order for a product or a service. At step 506, the service management platform 102 may populate one or more fields for finalizing the aforesaid order based on the CUID. In an embodiment, the fields required for finalizing the order may be automatically filled by the service management platform 102 based on the corresponding fields of the CUID.

At step 508, service management platform 102 may determine whether the fields required for finalizing the order cannot be filled based on the fields present in the CUID. When the service management platform 102 determines that the fields required for finalizing the order cannot be filled based on the fields present in the CUID, the control passes to step 510. When the service management platform 102 determines that the fields required for finalizing the order can be filled based on the fields present in the CUID, the control passes to step 514.

At step 510, the service management platform 102 may prompt the user 104 to provide the data corresponding to the fields for which the data could not be filled based on the CUID. At step 512, the service management platform 102 may receive the requested data from the user 104. At step 514, the service management platform 102 may finalize the order for the product or service requested by the user 104 and may inform the corresponding administrator of the PSP via an interface. The control passes to step 516.

FIG. 6 is a method flowchart for registering a product and service provider with the service management platform, according to an example embodiment of the present disclosure. With reference to FIG. 6, there is shown a flow chart 600. The flow chart 600 is described in conjunction with FIG. 1. The process starts at step 602 and proceeds to step 604.

At step 604, the service management platform 102 may present one or more options to the PSPs (such as PSP 106i) for registration. The one or more options may be presented on a dedicated interface associated with the PSP 106i. At step 606, the PSP 106i may provide one or more inputs pertaining to the products and services offered by it. The PSP 106i may further specify one or more requirements for completing the transaction for ordering the products and services offered. In an exemplary scenario, the PSP 106i may correspond to a bank. In such a scenario, the products offered are mutual funds, fixed deposits, services associated with maintenance and upkeep of accounts. At the time of registration of such a PSP, the administrator associated with the PSP may specify one or more forms that are required to be filled by a user for ordering the products and services. To this end, the administrator may specify a template for the forms associated with each product and service offering. Further, the administrator may specify the fields that are required to be filled, the service management platform in the forms. Additionally, the administrator may assign a unique identifier to each form. At step 608, the service management platform 102 may store the one or more inputs in a database associated with the PSP.

At step 610, the administrator of the PSP 106i may provide a matrix of executives for managing the delivery of the products and services offered by the PSP 106i. The matrix may hierarchically define the roles and responsibilities of the executives and their position in the hierarchy of the executives. As an example, the executives categorized as LI may constitute a first line of executives that are notified when an order is placed. The executives categorized as L2 may constitute a second line of executives that may be superiors of LI executives and may be are notified when there is any issue with the delivery of the order. The executives categorized as L3 may constitute the third line of executives that may be superiors of the L2 executives and may be are notified when any issue is not resolved within a specified service level agreement (SLA).

At step 612, once registered, the service management platform 102 may activate one or more interfaces for the PSP 106i. Each of the activated one or more interfaces may correspond to a product and service offered by the PSP 106i. For example, when the PSP 106i corresponds to a bank, the service management platform 102 may provide a first interface for account opening, a second interface for managing fixed deposit transactions, a third interface for conducting trading, a fourth interface for managing account transfers, and the like. In an alternate embodiment, a single interface may be provided by the service management platform 102 to the PSP 106i for listing and managing the order and delivery of all the products and services. In an embodiment, the PSP 106i may access the service management platform 102 interface through a downloadable mobile API, a standalone desktop based application, or a cloud based application. The control passes to end step 614.

FIG. 7 is a method flowchart for notifying a product and service provider about the an order the service management platform, according to an example embodiment of the present disclosure. With reference to FIG. 7, there is shown a flow chart 700. The flow chart 700 is described in conjunction with FIG. 1. The process starts at step 702 and proceeds to step 704. At step 704, the service management platform 102 may receive an order from the user 104.

At step 706, the service management platform 102 may determine an appropriate interface of the PS 106i _, which is to be used for alerting the administrator. To this end, the service management platform 102 may analyse the metadata associated with the order. For example, when the PSP 106i corresponds to an ecommerce vendor offering vast variety of products and services, the service management platform 102 may determine the nature of product or service ordered by the user 104. In case the product corresponds to payment service, the service management platform 102 may alert the PSP 106i via an interface dedicated to managing orders related to payment service offered by the PSP. Similarly, in case user has registered a complaint, the service management platform 102 may alert the PSP 106i via an interface dedicated to grievance redressal. At step 708, present the notification regarding the order on an appropriate interface of the PSP 106i. The control passes to end step 710.

FIG. 8 shows an exemplary system for providing a service management platform, in accordance with some embodiments of the present disclosure. FIG. 8 is explained in conjunction with elements from FIG. 1 to 7. With reference to FIG. 8, there is shown the service exchange platform 102 that may comprises processor 802, a memory 204, a user database 806, a product and service database 808, a product and service code database 810, a customer user identification (CUID) module 812, an automatic form filling module 814, a security module 816, an input/output (I/O) module 818, and/or a transceiver 820, an IMEI capturing module (822), and IMEI verification module (824).

The processor 802 may include suitable logic, circuitry, interfaces, and/or code that may be configured to execute a set of instructions stored in the memory 804. The processor 802 may be configured to register the plurality of users and the PSPs with the service management platform 102. The processor 802 may further track the exchange of one or more products and services between the users registered with the service management platform 102. Examples of the processor 802 may be an X86-based processor, a Reduced Instruction Set Computing (RISC) processor, an Application-Specific Integrated Circuit (ASIC) processor, a Complex Instruction Set Computing (CISC) processor, and/or other processors.

In one embodiment the service management platform 102 comprises the memory 804 and the processor 802. Further, the processor 802 configured to execute programmed instructions stored in the memory 804 for performing below steps:

In step 1, the user 104 may be registered over a service management platform 102.

In step 2, the service management platform 102 may be configured to generate a customer user identification (CUID) for the user 104 upon registration.

In step 3, the service management platform 102 may be configured to registered the plurality of product or service providers 106i, IO6 ₂ , ...106 _n . The service management platform 102 is configured to enlist products or services offered from the plurality of product or service providers IO6 ₁ , IO6 ₂ , ...106 _n .

In step 4, the service management platform 102 may be configured to receive the request or the order from the user 104 for a target product or services offered by a target product or service provider 106 _t from the plurality of product or service provider IO6 ₁ , IO6 ₂ , ... 106 _n .

In step 5, the service management platform 102 may be configured to establish communication with the target product or service provider from the plurality of product or service providers IO6 ₁ , IO6 ₂ , ... 106 _n based on the request or the order. In step 6, the service management platform 102 may be configured to enable the real-time interactive session between the user 104 and the target product or service provider for fulfilling the request or the order of the user 104 based on the customer user identification (CUID).

The memory 804 may include suitable logic, circuitry, and/or interfaces that may be configured to store a machine code and/or a computer program with at least one code section executable by the processor 802. In an embodiment, the memory 804 may be configured to store the details related to the orders placed by the users which may be used for performing analytics on the orders serviced by the service management platform 102. The memory 804 may be further configured to store computed scores, such as the proficiency score, and/or the expertise index. Examples of implementation of the memory 204 may include, but are not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Hard Disk Drive (HDD), and/or a Secure Digital (SD) card.

The user database 806 may include suitable logic, circuitry, interfaces, and/or code that may be configured to store the personal information of the users, such as the user 104. The aforementioned personal information of the users may be stored in the user database 806 at the time of registration of the users with the service management platform 102. In an implementation, the user database 806 may be an entity separate from the memory 804 (as shown). In another implementation, the member database 208 may be integrated with the memory 804.

The product and service code database 808 may include suitable logic, circuitry, interfaces, and/or code that may be configured to store the personal information of the service providers from the plurality of product and service providers 106. The product and service database 808 may be configured to store the information of the PSPs (as discussed in the FIG. 6). The aforementioned information may be stored in the databases at the time of registration. In an implementation, the product and service database 808 may be an entity separate from the memory 804 (as shown). In another implementation, the product and service database 808 may be integrated with the memory 804.

The product and service code database 810 may include suitable logic, circuitry, interfaces, and/or code that may be configured to store the codes associated with the products and services offered by the PSPs 106. Further, the stored codes may be tagged to the registered users so as to provide an element of customization where the menu options codes for every user is different. The customizations have been explained in detail in FIG. 3A. In an implementation, the product and service database 808 may be an entity separate from the memory 804 (as shown). In another implementation, the product and service database 808 may be integrated with the memory 804.

The customer user identification (CUID) module 812, may include suitable logic, circuitry, interfaces, and/or code that may be configured to facilitate the generation of the CUIDs for the users registered with the service management platform 102. The CUID module 812 may enable a user to provide multiple distinct inputs so as to be able to generate a plurality of CUIDs. For each of the users registered with the service management platform 102, CUIDs may be stored in the user database 806. In a scenario, when the user places a request for ordering a product or availing a service related thereto, the processor 802 may be configured to use one or more stored CUIDs associated with the user and link it with the order placed. In another scenario, the processor 802 may prompt the user to select a specific CUID for placing the request.

The automatic form filling module 814 may include suitable logic, circuitry, interfaces, and/or code that may be configured to automatic filling of the forms specified by the PSPs 106. To this end, the automatic form filling module 814 in conjunction with the processor 802 may retrieve a specific CUID associated with a user and may extract details from the CUID to fill the fields of form specified by the PSP. The security module 816 may include suitable logic, circuitry, interfaces, and/or code that may be responsible for ensuring that the session is activated for a registered user only for a pre-defined duration. Beyond that time window, the session is to be maintained in a dormant state so as to minimize the risk of intrusions by a rogue entity.

The I/O module 818 may include suitable logic, circuitry, interfaces, and/or code that may be configured to render the services availed by a user 104 from a PSP, on an associated electronic device 108 of the user 104. The I/O module 818 may be configured to render the details of the ordered product and services availed by a user 104 from a PSP, on one or more interfaces associated with the PSP. The I/O module 818 may include various input and output devices that may be facilitate communication between the service seeker and the service provider. In an implementation, the one or more electronic devices that, in conjunction with the I/O module 818, may be configured to display one or more interfaces for exchange of services between the PSP and the user, via a respective display screens or audio/visual device. Examples of the display screens may include, but are not limited to, Liquid Crystal Display (LCD) display, Light Emitting Diode (LED) display, Organic LED (OLED) display technology, and/or the like.

In an implementation, the I/O module 818 may be further equipped with a photographic optical system, such as a photographic lens and/or a zoom lens, as well as one or more image sensors, such as a charge -coupled device (CCD) or a complementary metal-oxide- semiconductor (CMOS), a digital camera, a camera embedded in a personal digital assistant (PDA), a video camera, and/or a motion camera. A person of ordinary skill in the art will appreciate that the I/O module 818 may further include one or more audio based output devices for enabling communication with a community club member or an administrative user. This enables the user to provide photographic inputs to the service management platform 102 that may include, but are not limited to, documents relating to product, documents relating to an identity of the user, pictures of a desired product which is to be ordered, pictures of an already order product to convey its working status, and the like. The transceiver 820 may include suitable logic, circuitry, interfaces, and/or code that may be configured to facilitate communication among the plurality of PSPs 106 and the user 104. The transceiver 820 may be implemented based on known technologies to support wired or wireless communication. The transceiver 820 may include, but is not limited to, an antenna, a radio frequency (RF) transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a coder-decoder (CODEC) chipset, a subscriber identity module (SIM) card, and/or a local buffer. The transceiver 820 may communicate via wireless communication with networks, such as the Internet, an Intranet and/or a wireless network, such as a cellular telephone network, a wireless local area network (LAN) and/or a metropolitan area network (MAN). The wireless communication may use any of a plurality of communication standards, protocols and technologies, such as Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), wideband code division multiple access (W-CDMA), code division multiple access (CDMA), Long Term Evolution (LTE), time division multiple access (TDMA), Bluetooth, Wireless Fidelity (Wi-Fi) (such as IEEE 802.11a, IEEE 802.11b, IEEE 802. llg and/or IEEE 802.1 In), voice over Internet Protocol (VoIP), Wi-MAX, a protocol for email, instant messaging, and/or Short Message Service (SMS).

In one embodiment the International Mobile Equipment Identity (IMEI) capturing module may be configured to capture the IMEI number of an electronic device 108 of the user 104. Further, the International Mobile Equipment Identity (IMEI) verification module may be configured to verify the IMEI number of an electronic device (108) of the user (104).

The present disclosure may be implemented for any environment having multiple server nodes. Various environments are discussed in FIG. 1 but the disclosure may be implemented for other environments although not mentioned.

The present disclosure may be implemented in a regular client-server configuration, however other configurations may also be implemented. The method flowcharts or processes described above, and steps thereof, may be realized/executed in hardware, software, or any combination of these suitable for a particular application. The hardware may include a general-purpose computer and/or dedicated computing device. The processes may be realized in one or more microprocessors, microcontrollers, embedded microcontrollers, state machine, programmable digital signal processors or other programmable device, along with internal and/or external memory. The processes may also, or instead, be embodied in a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices that may be configured to process electronic signals. It will further be appreciated that one or more of the processes may be realized as computer executable code created using a structured programming language such as C, an object oriented programming language such as C++/Java, or any other high-level or low-level programming language (including assembly languages, hardware description languages, and database programming languages and technologies) that may be stored, compiled or interpreted to run on one of the above devices, as well as heterogeneous combinations of processors, processor architectures, or combinations of different hardware and software.

Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media can include memory devices (e.g., random access memory (RAM), read only memory (ROM), electrically erasable programmable read-only memory (EEPROM)), magnetic storage devices (e.g., hard disk, floppy disk, cassettes, tape), optical disks (e.g., compact disk (CD), digital versatile disk (DVD)), and solid state devices (e.g., solid state drive (SSD), flash memory drive (e.g., card, stick, key drive)), or any other like medium which can be used to store the desired information and which can be accessed by the computer.

The database management system as described in the present disclosure or any of its components, may be embodied in the form of a computer system. Typical examples of a computer system include a general-purpose computer, a programmed microprocessor, a micro-controller, a peripheral integrated circuit element, and other devices or arrangements of devices that are capable of implementing the method of the present disclosure.

The computer system comprises a computer, an input device, a display unit and the Internet. The computer further comprises a microprocessor. The microprocessor is connected to a communication bus. The computer also includes a memory. The memory may include Random Access Memory (RAM) and Read Only Memory (ROM). The computer system further comprises a storage device. The storage device can be a hard disk drive or a removable storage drive such as a floppy disk drive, optical disk drive, etc. The storage device can also be other similar means for loading computer programs or other instructions into the computer system. The computer system also includes a communication unit. The communication unit communication unit allows the computer to connect to other databases and the Internet through an I/O interface. The communication unit allows the transfer as well as reception of data from other databases. The communication unit may include a modem, an Ethernet card, or any similar device which enables the computer system to connect to databases and networks such as LAN, MAN, WAN and the Internet. The computer system facilitates inputs from a user through input device, accessible to the system through EO interface.

The computer system executes a set of instructions that are stored in one or more storage elements, in order to process input data. The storage elements may also hold data or other information as desired. The storage element may be in the form of an information source or a physical memory element present in the processing machine.

The set of instructions may include one or more commands that instruct the processing machine to perform specific tasks that constitute the method of the present disclosure. The set of instructions may be in the form of a software program. Further, the software may be in the form of a collection of separate programs, a program module with a larger program or a portion of a program module, as in the present disclosure. The software may also include modular programming in the form of object-oriented programming. The processing of input data by the processing machine may be in response to user commands, results of previous processing or a request made by another processing machine.

For a person skilled in the art, it is understood that these are exemplary case scenarios and exemplary snapshots discussed for understanding purposes, however, many variations to these can be implemented in order to detect objects (primarily human bodies) in video/image frames.

In the drawings and specification, there have been disclosed exemplary embodiments of the present disclosure. Although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the present disclosure being defined by the following claims. Those skilled in the art will recognize that the present disclosure admits of a number of modifications, within the spirit and scope of the inventive concepts, and that it may be applied in numerous applications, only some of which have been described herein. It is intended by the following claims to claim all such modifications and variations which fall within the true scope of the present disclosure.