Browse Prior Art Database

Apparatus and Method of the Help Request Notification System

IP.com Disclosure Number: IPCOM000244943D
Publication Date: 2016-Feb-04
Document File: 8 page(s) / 165K

Publishing Venue

The IP.com Prior Art Database

Abstract

This disclosure is about a pairing mechanism to match up helpers (Provider) and people that needs help (Requesters). Both Providers and Requesters get a list of service name from remote repository into their mobile devices. Then, Requester boardcast himself/herself as a service requester to others near by. If a Provider happen to be near by will receive the boardcast and match up if he/she can provide such service in his/her mobile device. If matched, then the Provider will find the Requester via AR (Augmented Reality) technology on his/her mobile and provide the service.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 40% of the total text.

Page 01 of 8

Apparatus and Method of the Help Request Notification System

Sometime when we are out of home without friends. It is hard for me to ask somebody directly when I may need a little help, such as ask direction, take a photo for me, lost my stuff... etc. The main reason is I am afraid that I will bother someone who is in a rush or not willing to be interrupted. So I was wondering, if I can just send a simple message with my help requests, and someone around me is free with kindness will receive this message and know who needs a favor. Then he/she will come to find me and give me a hand. Eventually, we offer a notification service from mobile to let provider knows who needs help.

We present an intuitive method to notify the person who would like to provide help (Provider) to help the person in need (Requester). We simply use the technology of bluetooth to implement the idea. The Requester just need to open his/her bluetooth device like mobile phone, then the Provider would receive the notification through an selective algorithm. The algorithm is the key of our method. It could recognize different kinds of help and notify the right person who could provide that kind of help.

Claim point:

The pairing mechanism to match up service provider and service requester by broadcasting service list with short distance broadcast communication method

Encoding the service list and make it part of the device name for communication in the Requester side and decoding the device name in

the Provider side

Notifying Provider when there are matched service type received by his/her mobile device

Advantage:

All user experience is intutive and user-friendly.

The application only need to use bluetooth-like function which could provide device name list without connecting any device.

The communication between requester and provider doesn't need to go through server.

Encoded request can broadcast through bluetooth and be decoded by provider.

The encode/decode method can choose any algorithm which can make the result name shorter than the longest bluetooth name.

The Provider can only search for Requesters near him/her due to the locality of bluetooth device broadcast range.

The user can input new service pair they need and each input inserted will be unique.

The people who are willing to help (ie. Provider) can be notified when there is a person who needs help (ie. Requester) is around.There is a list of services that are defined for both service provider name and service requester name, so they know what kind of service will can be provided. The list is stored in both Provider's and Requester's mobile device. The APP in Requester's mobile device will encode the needed service name into bluetooth device name and broadcast. The APP in Provider's mobile device will check the bluetooth device name

1



Page 02 of 8

received and decode/parse the service name that is needed by Requesters.

First of all, there is a service item repostory that contain pre-defined table. I...