METHOD AND SYSTEM TO PROVIDE RELEVANT LOCAL SERVICE  OVER WI-FI

This invention provides method and system for a person to get accurate information about service providers in vicinity to serve real time needs. A user can get information services needed in day-to-day life, which includes but is not limited to house hold, emergency, entertainment etc. The Service Providers are within few km/miles so that User's needs are served when needed. This invention uses Wi-Fi (or future advanced technologies which enhance the wireless reach) technology for implementing this invention without any mobile operators involvement.

DETAILED DESCRIPTION

In the present description, some words are being used interchangeably to mean the same thing/entity: ‘Customers’ & ‘Users’; ‘He’ and “She”.

It is appreciated that present invention can be implemented in a variety of systems, devices, architectures and configurations. For example, it can be used as an application with several known platforms, such as for, mobile platforms (iPhone, iPad, Android, Windows), distributed computing environment, a cloud computing environment, a client server environment, social networking websites, etc. Embodiments described herein may be discussed in the general context of computer-executable instructions residing on some form of computer-readable storage medium, such as program modules, executed by one or more computers, computing devices, or other devices.

FIG. 1depicts a block diagram of a system that includes the module of Mobile Application—Framework, according to one or more embodiments of the present invention. Various services are presented in the logical, hierarchal form and are clubbed together. For example, Sub-Service Category (SSC) 11 and SSC 12 are clubbed under the Main Service Category (MSC) 1. When the mobile application is launched the user first sees all the main services. Upon the selection of Main Service Category, the User can select the desired Sub-Service. Once the sub service is selected, the User is provided with information on registered and active Service Provider.

FIG. 2depicts a block diagram of a system that includes the module of Mobile Application—Framework Example, according to one or more embodiments of the present invention. Under Main-Service of “Emergency”, Sub-Service Category Doctor, Police and Ambulance are clubbed together. Similarly, for Main Service of Entertainment, Sub-Service categories of Theme Park, Gaming Zone and Theatres may be clubbed together. The Application can be modified to include as many Main-Services or Sub-Services as are registered with it, for example:Emergency ServiceShopping ServiceEntertainment ServiceHotel & Restaurant ServiceAutomobile ServiceFinancial ServiceEducation ServiceHome ServiceHealth ServiceTravel ServiceRental ServiceReal Estate ServiceElectrical & Electronic ServiceGovernment ServiceDay2Day Service

All the services defined at the sub-category level is assigned a service tag, which can identify the Main-Service and Sub-Service. A service provider has to register his service under the appropriate category and be logged into the application. The details of the service provider will reside in the device (mobile phone) memory.

In one embodiment of implementation of the present invention, the app-owner can seek to have several revenue models for its application. It can charge fees to register Service Providers or may make provisions to charge fees based upon User's selecting to see the information of a Service-Provider. In addition, a revenue model of flat fees of installing App and/or charges for upgrade may also be considered, according to one or more embodiments of the present invention.

FIG. 3depicts a block diagram of a system that includes the module of Services Options, according to one or more embodiments of the present invention. A Service Provider can choose any of the following options:Register ServiceEnable/Disable ServiceDe-Register Service

A Customer may choose any of the following Service options:Make Service RequestCancel Service

FIG. 4depicts a flowchart of a system that includes the module of Registration of Service by the Service Provider, according to one or more embodiments of the present invention.

A Service Provider may choose to provide either a single service or multiple services. In the case of providing a single service, the registration can be done once. For multiple services, a service provider has to register as many times as the number of service he wishes to provide under various MSC and SSC categories.

The Service-Provider gets into application as a Service-Provider, then chooses the MSC or SSC and thereafter selects the Register button. The Service-Provider enters all the particulars that includes the following:Service provider Name (SN)—Optional. If not provided, default Wi-Fi Name will be used.Service Time (ST)—Optional. If not provided, 24 hours service will be considered. Time is in 24 hour format.i) STS—Service Time Start—09:30ii) STE—Service Time End—19:00iii) Time structure can be used.Business address.

Once the Service Provider selects Submit button the Registration is completed and message to enable the service is flashed. By default the Service will be disabled. When the service is disabled, the service provider will not be listed in the customer search results.

In a preferred embodiment of the present invention, it is recommended that the Service Provider does the registration from a mobile phone for any service which he/she wants to register. Hence, system will take mobile number automatically and not ask the Service Provider to give mobile number as an input during registration.

After Registration is complete, the Service Provider can select to Register another Service, if needed.

FIG. 5depicts a flowchart of a system that includes the module of Service Provider: Enable/Disable Service according to one or more embodiments of the present invention. A Service Provider may choose to enable/disable one or more services.

When the Service-Provider selects the Enable/Disable Service Option, he is presented with MSC and SSC menu for only those services the service provider has registered for. The MSC/SSC may not be the complete list as displayed in the registration module. The Service Provider navigates through the registered services and selects the service to enable/disable using the “Enable/Disable” button. Once the Service Provider confirms the selected service is enabled/disabled, as desired. The Service-Provider can also choose to enable/disable one or more services.

FIG. 6depicts a flowchart of a system that includes the module of Service Provider: De-Register Service according to one or more embodiments of the present invention. A service provider may choose to De-Register one or more services.

When the Service-Provider selects to De-Register Service Options, he is presented with MSC and SSC menu for only those services the service provider has registered for. The MSC/SSC may not be the complete list as displayed in the registration module. The Service Provider navigates through the registered services and selects the service for De-Register using the “De-Register” button. Once the Service Provider confirms the De-registration, the selected service is De-Registered. The Service-Provider can also choose to De-Register one or more services.

FIG. 7depicts a flowchart of a system that includes the module of Make Service Request by the Customer, according to one or more embodiments of the present invention.

Customer requesting for a service, need not perform any registration. They need to start the application and start selecting in the MSC and SSC fields and issue a search request.

When the customer selects the Make Service Request Option, he is presented with list of available services. He navigates through MSC & SSC to select the desired service and submits using the search button. The User is given search time option because the user will make the service request and can move to different location in search of a Service Provider. The application should be capable enough to provide option to customer to extend the search time to 5 min/10 min or Continuous Search. Under such option this cancel service becomes more applicable. Maybe decide this at the time of implementation. By default we will have no timeout to support customer search for this very reason. A list of service Provider who can provide the desired service is made available to the Customer, so that the Customer can choose the Service Provider desired. The Service Provider registration details includes, name, Business time (Start, End or 24 hrs), Business address and mobile phone. The Customer can choose the mode of communication that includes mobile, SMS and/or video. The key is to get connected to the Service-Provider. In case there is no Service-Provider found, who can provide the desired service the User is informed about the same. Thereafter, the User can decide to select another service/category that he/she feels more appropriate.

FIG. 8is a flowchart of a system depicting Cancel Service Request by the Customer according to one or more embodiments of the present invention. The customer may choose to cancel one or more services.

When the Customer selects the Cancel Service Request Option, he is presented with MSC and SSC menu for only those services the User has requested search for. The MSC/SSC may not be the complete list as displayed in the registration module. The Customer navigates through the list of previous service requests made in the form of MSC/SSC and selects the service for Cancel using the “Cancel” button. As explained above forFIG. 7, the application allows Customer to extend search time. Once the Customer confirms the selected service is cancelled, as desired. The Customer can also choose to Cancel one or more services.

FIG. 9is a block diagram of a system depicting Services in One Service Area according to one or more embodiments of the present invention. It depicts a simple real time environment for highlighting the core of the invention. The Service Area1comprises of Service-1which is provided by Service Provider1. Similarly Service Area2comprises of Service-2which is provided by Service Provider2. When Customer-11or Customer-12makes request for Service-1, the Service Provider-1provides them the information as has been described earlier. The Customer can select the desired service and is connected to the Service Provider-1who happens to be in the vicinity.

FIG. 10is a block diagram of a system depicting Services in Multiple Service Areas according to one or more embodiments of the present invention. It depicts the real time environment in which multiple service providers will provide the information about services by passing information to each other. Customer11makes request for a service which happens to be in Service Area3. Service Provide3provides info about Service3to Service Provider2which in turn provides the information to Service Provider1. Customer11selects Service3and he/she is served.

The environment of network is needed when Customer11makes a request for service that happens to occur in Service Area3and that Service Provider1is not able to provide the information on Service3. It in turn, requests the Service Provider2and3to check if the Services can be provided by them. As Service3can be served by Service Provider3, it passes on this information back to Service Provider2which in turn passes this information to Service Provider1. The Customer can select Service3and can be served by this Service Provider, which is not in its immediate vicinity. This enables to increase the coverage/serviceable area beyond the Wi-Fi coverage area.

In another embodiment of the present invention, an additional option of distance between the customer and a service provider can be displayed against the service provider, if Wi-Fi supports calculation of distances between any two P2P Wi-Fi devices using the Round Trip Time (“RTT”).

The Wi-Fi Direct coverage in P2P communication as per the latest specification is 658 feet, roughly 200+ meters. This is a real constraint for obtaining any local service. To improve the coverage area, it is proposed here is to make all the participating Wi-Fi Direct enabled devices (i.e. devices which run this application) to support forwarding of application data (in the form of customer requests/search results) to the originator of the request. This requires embedding the application with knowledge of forwarding the data from and to the customer, with the help of intermediate Wi-Fi nodes permission.

To support this, the participating nodes (who are also potential customers/service provider) or intermediate nodes, need to permit the application to forward data specific to request and search results. This acceptance can be voluntary. Once accepted, the intermediate nodes will act as a Forwarding Agent for the far end nodes.

The coverage can be restricted to number of hop counts, say 50, in which case we can reach a maximum of 50*200 meters which is 10 KM, provided we have so many AP's in between. In a densely populated area (for example in Manhattan, N.Y.), we can expect the intermediate nodes to lie within 50 m, in which case we can expect the range to be 50*50 meters=2.5 KM.

The Idea is to replicate the functioning of Napster File sharing or Torrent File sharing tools like uTorrent application. This is done on the internet, whereas the present invention replicates this model on Wi-Fi direct devices.

The source of request or customer end application can have intelligence to discard the duplicate data based on MSC, SSC and Mobile number. Alternatively, the intermediate nodes can also have the intelligence of filtering duplicate entries and forward only one instance of the service provider. This will not flood the network.A->B->C->->D->F->G->H
e.g. If A requests for service m, which H can serve. H's data is forwarded by G and F to D and C. D & C has the duplicate entry of H. Either they can forward the complete data with duplicate entry to B, in which case B will have four duplicate entries. Or they can send one instance of the entry, in which case B will have two entries from one each from C and D. B will now send only one instance of the entry to A.

If somehow B quits the application, A will not receive any responses and A has to retry his request again sometime later, to find if he can get that service.

The present invention envisages, that Customers and Service Providers are not stationed, they are moving at a much faster pace when compared to our coverage which is just 200 meters. Hence, a decision to whether consider the SP_REPLY (as explained below), as valid or not will have to be made in this case.

FIG. 11is a block diagram of a system depicting Data Model and Packet Types Request according to one or more embodiments of the present invention. It depicts the packet exchange between Customer and Service Provider. It also shows the packet structure used.

Customer Sending Request (CS_REQ):Customer Identification Fields required for reply as per WiFi Direct standardsRequest Id—Request/Reply CorrelatorMSC—Requested MSCSSC—Requested SSCTTL

Service provider Reply Message (SP_REPLY):Service provider Identification Fields as per WiFi Direct standardsRequest Id—Request/Reply CorrelatorMSC—Service provider MSCSSC—Service provider SSCOther details from SN . . . Mobile Number.Landline under consideration.

Customer Pushing Request (CS_PUSH_REQ): This is more of a P2P communicationCustomer Identification Fields required for reply as per WiFi Direct standardsService provider Identification Fields (alike Destination) where the request has to be pushed.Request Id—Request/Reply CorrelatorMSC—Requested MSCSSC—Requested SSCOptional Text Message

This can be achieved simply buy sending a SMS to the service provider mobile. Nevertheless, we can have it here for simplicity of just push our request to the service provider with just one or two touch, instead of typing the long message followed by mobile number in the trivial SMS communication.