1. Field of the Invention
The present invention relates to information systems generally and, more specifically, to an Internet-based assistance request system and methods of operating same.
2. Description of the Related Art
Cellphone coverage and use is ubiquitous. A cellphone has transformed from a voice only device to a multi-functional converged smartphone with multimedia, data, networking, and physical locating capabilities amongst many of the smartphone's features.
Users may sometimes voluntarily publish their location and activities such as Checking In with Facebook or via many other applications that allow the users to locate other smartphone users. Other similar exemplary applications include, “Family Phone Locator” offered by Verizon, iPhone applications such as “Find iPhone” and “Find My Friends”, “EchoEcho”, Facebook Messenger, etc. These and other so-called “geo-social” networking applications enable users to publish their location and can also be used to identify all contacts, or in some cases unknown but interested individuals, which are proximate and have elected to be “visible” to other users.
These applications are focused towards social interactions and the users are therefore alerted to the presence of other local “visible” users. For example, this feature enables a user to send requests to a single individual or multicast it to a group to assemble at a particular location.
Once the user is aware that there are identified individuals in the area, those individuals' privacy is compromised. To avoid this, those individuals might switch status from “visible” to “invisible”.
In addition, not all requests are suitable or appropriate for distribution to all visible contacts. Furthermore these requests are made without consideration of a contact's capability to address a specific request or concern for immediate privacy. For example a contact may be temporarily indisposed and unable to reply let alone address a specific request.
At times a smartphone user might need help (assistance) other than a life threatening “911” issue requiring emergency personnel, such as to locate a friend or colleague nearby for a specific task. In this situation, the smartphone user needs the ability to locate a capable and willing contact in close proximity to the user (the “requestor”), rather than having to call contacts (potential helpers) at random who might be unavailable, unable, unwilling, or too far away to be of immediate help. Also what is needed is a way to avoid requesting more help than is required and to provide feedback to the requestor and potential helpers about the status of a help request.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Described embodiments include a method comprising the steps of receiving, from a requestor, a request for assistance for a specified task; selecting, from a list of contacts, contacts based on the request for assistance for the specified task using keywords of the request compared against capabilities of the contacts on the list of contacts; determining physical locations of the requestor and one or more of the selected contacts; identifying, from the selected contacts, one or more potential contacts based on physical distance between the one or more selected contacts and the requestor; calculating an attribute for each of the one or more potential contacts having a determined physical location; selecting, from the one or more potential contacts having a calculated attribute, a set of one or more viable contacts based on a comparison between the calculated attribute and a requestor-defined limitation; and forwarding the request for assistance to the one or more selected viable contacts. The attribute is at least one of: speed of the potential contact having a determined physical location, trajectory of the potential contact having a determined physical location with respect to the physical location of the requestor, altitude of the potential contact having a determined physical location with respect to the physical location of the requestor, and residence time of the potential contact at a determined physical location.
Other aspects, features, and advantages of the present invention will become more fully apparent from the following detailed description, the appended claims, and the accompanying drawings in which like reference numerals identify similar or identical elements.
Reference herein to “one embodiment” or “an embodiment” herein means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments necessarily mutually exclusive of other embodiments. The same applies to the term “implementation”.
As used in this application, the word “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the word exemplary is intended to present concepts in a concrete fashion.
Additionally, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form.
Described embodiments relate to a system and method for sequential requests for assistance from nearby contacts without having them divulge their presence or location.
In the described embodiments, a list of contacts may be generated and stored in a server of the system. At the outset, the contacts would agree to have their location determined when needed but not divulged to anyone. Once the requestor summons a request for help for a specified task, an application executed by the server determines the closest contact to the requestor capable of addressing the specified request by matching the request to the capabilities of the contacts as potential helpers, calculating one or more attributes to determine whether a contact should be considered viable, and sends to the closest contact a communication informing them of the request for help from the requestor. The calculated attribute includes at least one of the following: speed, trajectory, altitude, and residence time. The closest contact may choose to respond or decline the request. The application then contacts the next closest viable contact to the requestor when the closest viable contact does not respond or declines and so on. The contacts may retain their anonymity. The requestor may never know who was contacted or who was available but ignored or declined the requestor's request for help.
Note that herein, the terms “helper”, “potential helper”, “contact”, “individual”, and “person” may be used interchangeably. It is understood that a helper or potential helper may correspond to, or relate to, a contact, or an individual, or a person, and that the contact, the individual, or the person may refer to the helper or a potential helper. Similarly, the terms “help” and “assistance” may be used interchangeably.
Note that herein, the terms “application”, and “server” may be used interchangeably. It is understood that an application may correspond to, relate to, or be executed by a server, and that the server may refer to the application. Further, the plural of certain terms, such as contacts, may also refer to non-plural instances of the term.
Cellular network 102 is a well-known wireless network distributed over land areas called cells, each served by at least one fixed-location transceiver, known as a cell site or base station (not shown). In cellular network 102, each cell might use a different set of frequencies or spreading codes from neighboring cells to avoid interference between cells and provide a minimum data capacity within each cell. When joined together, these cells provide radio coverage over a wide geographic area. This enables a large number of portable transceivers (e.g., mobile phones, tablet computers, pagers, etc.) to communicate with each other and with fixed transceivers and telephones anywhere in cellular network 102 via the base stations (cell sites) even if some of the transceivers are moving through more than one cell during transmission. As shown in
Server 106 is a system including software and suitable computer hardware that responds to requests across cellular network 102 to provide, or help to provide, a network-based assistance request service. Conventional server 106 can be a dedicated computer or a networked group of computers. Server 106 operates with the wired/wireless Internet infrastructure 112. Server 106 provides an assistance request service, as described below, across cellular network 102, either to wirelessly connected users 108 or wired connected users 110. The server 106 stores a requestor's contacts and executes applications performing assistance request operations, such as calculating locations of all users including the requestor and potential helpers (contacts) and attributes of requestor's contacts, determining potential helpers and the closest contact to the requestor, and forwarding the request to the closest contact, etc.
Wirelessly connected users 108 may be mobile objects, such as people on the go, automobiles running on the road, etc. In one embodiment, wirelessly connected users 108 may be a smartphone user or a tablet computer with wireless data connectivity. Wired connection users 110 may be a computer at home or at work, and so on.
At times the smartphone user might need help and needs to locate a friend or colleague nearby for a specific task. The nature of help could be non-life threatening and not warrant “911” assistance. The following exemplary scenarios might necessitate such help with system 100:
If, however, the determined contact declines or remains unresponsive after the requestor-defined time has elapsed, at step 926 the declining/unresponsive contact is optionally tagged as not to be contacted again if the requestor repeats his/her request for help. Then, at step 928 it is determined if there are more viable contacts to be tried and, if so, control passes to step 930 where the next closest one of the viable contacts is determined and control passes back to step 918 so that the request is sent to the next closest viable contact. If, however, no more viable contacts remain, then control passes to step 932 where the server notifies the requestor that there is no help available in the requestor-defined proximity and matching the requirements of the request was found. The requestor can then choose to modify the search parameters or exit the application (see, for example,
In an alternative embodiment, the requestor might optionally have the server 106 sequentially contact the contacts again if no contact accepted the requestors help request.
In step 1002, the list of potential contacts is obtained. Then at step 1004, the application begins the process of determining the speed, altitude, trajectory, residence time of all potential contacts that can be determined beginning, at this point, with the first contact on the potential contact list from step 1002. In step 1006, if it is possible to determine the altitude of the contact being analyzed and the requestor, then control passes to step 1008 in which the altitude of the contact is determined. Then in step 1010 the difference between the altitude of the contact and the altitude of the requestor (from step 908) is compared to the requestor-defined limit. If the difference in altitude (delta) is greater than the limit, then the contact is not a viable contact and it is removed from the list in step 1012 and then control passes back to step 1004 where the next contact on the list is evaluated.
Returning to step 1010, if the altitude delta is less than the limit, then in step 1014 if it is possible to determine the speeds and trajectories of the contact, then control passes to step 1016 in which the speed and trajectory of the contact is determined. Next, in step 1018, if the speed of the contact is greater than a speed limit set by the requestor, then control passes to step 1020 where the trajectory of the contact is compared to the requestor's position to see if the contact's trajectory is away from the requestor or not. If the trajectory is away from the requestor, then control passes to previously described step 1012. If the speed is less than the speed limit (step 1018), in which case the contact is moving slowly enough so that it could be confirmed as a viable contact, or if the trajectory of the contact is not away from the requestor (step 1020), then control passes to step 1022. In this embodiment, is assumed that the requestor is not moving; in another embodiment, the requestor is moving and as such the speed being checked in step 1018 and the trajectory in step 1020 might be made relative to the speed and instantaneous position of the requestor, respectively.
In step 1022, if it is possible to determine the residence time of the contact, then control passes to step 1024 where the residence time of the contact is determined. As used here, the time a contact identified as being proximate a location solely based on social website information is the residence time of the contact. Then in step 1026, if the residence time of the contact is greater than a requestor-specified limit, then control passes to the previously described step 1012, otherwise control passes to step of 1030. Steps 1022-1026 serve to remove those contacts on the list of potential contacts that have an extended residence time. For example, someone who visits a restaurant and “checks in” but appears to remain there for unreasonably extended periods of time (e.g., more than one day) has an unreasonable extended residence time. Even though this contact might be close to the requestor, he/she is excluded from the list of the potential contacts and control passes to step 1030.
In step 1030, the list of contacts is checked to see if the final one of the contacts has been evaluated and if not, then control passes back to step 1004 and the next contact on the list of contacts is analyzed as described above. If, however, the final contact has been analyzed, then in in step 1032 the contacts remaining on the list from step 1002 is a set of viable contracts for the particular request made by the requestor and that list is exported as a list or set of viable contacts. Then control passes to step 916 in
In this embodiment, if the speed, altitude, and trajectory of any of the selected contacts cannot be determined, then the method, by virtue of steps 1006, 1014, and 1022, does not remove those contacts from the list of contacts and, thus, treats them as viable contacts. Instead of treating those contacts as viable contacts by default, in another embodiment the steps in
In an alternative embodiment, instead of deleting contacts that do not meet the requestor-specified limits or thresholds, contacts are added to form a list of viable contacts that satisfies the requestor-specified limits or thresholds. Using either technique, the process described above selects, from the one or more contacts having a calculated attribute, a set or list of one or more viable contacts based on a comparison between the calculated attribute and a requestor-defined limit or threshold.
As described here, the contacts retain their anonymity by default until they respond with their agreements to help. The requestor and other contacts would never know who was contacted and who was available but ignored the call for help.
The described embodiments provide a non-emergency help system that is anonymous, sequential, and matches capabilities of the helpers to the requestor's needs. Helpers identify the type of assistance they could or would be willing to provide/fulfill and then agree to become available anonymously and are sequentially located during a request for assistance that matches their capabilities and proximity to the requestor and, upon their agreement to comply to the request, then made visible to the requestor. The nearest helper may choose to respond or decline the request. This anonymous location process occurs sequentially awaiting a requestor-defined timeout, until one of the identified individuals agrees to fulfill the request or until there are no other individuals proximate that meet the specific request criteria. A call for help is not broadcast, but contacts are chosen based on their disclosed skills/capabilities and their proximity to the requestor. Examples of capability-based help requests could include but not limited to a requestor's situations, such as, car needs a jumpstart, being locked out of the house, needing help moving heavy objects, requiring babysitting services, needing truck to transport a large item, requiring minor home plumbing help/expertise, etc.
The described embodiments also provide feedback to the requestor and the potential helpers. The feedback is provided to the requestor or the requestor and anonymously to the potential helpers. If one individual does agree to comply with the request, all of the other individuals previously contacted are notified that the request is being fulfilled. If the list of potential candidate helpers is exhausted and/or no complying individuals found, the requestor is notified that there are no individuals proximate and given the option to expand their search range, modify criteria, etc. If a helper agrees to comply with a request, a message with the preferred direct contact information (phone call, text, email, etc.) is provided to the helper. An additional embodiment allows for a requestor-specified preference of contacting key or favorite individuals (e.g. family) over the next nearest proximate helpers in, for example, steps 916 and 930.
Contacts identified as being proximate solely from geo-social networking location applications or geo-social networking website information (collectively referred to as geo-social networking) may be excluded based on excessive “residence time” such as, for example, when someone visits a restaurant and “checks in” there but appears to remain there for an unreasonable period of time (e.g., 1 days).
Speed of the potential helpers is determined to eliminate contacts that may appear within the specified proximity of the requestor. Travelling on an airplane precludes those contacts from being selected as potential helpers.
Contacts travelling at a trajectory towards the requestor, at normal driving speeds may, however, qualify as suitable potential helpers.
The described embodiments rely on existing available means for determining the speed and trajectory of the contacts. These may include utilizing Doppler shifts or calculating a change in location over time.
Although the subject matter described herein may be described in the context of illustrative implementations to process one or more computing application features/operations for a computing application having user-interactive components the subject matter is not limited to these particular embodiments. Rather, the techniques described herein can be applied to any suitable type of user-interactive component execution management methods, systems, platforms, or apparatus.
While the exemplary embodiments have been described with respect to processes implemented by a server or the like, the embodiments are not so limited. As would be apparent to one skilled in the art, various functions of the server as described herein might also be implemented by distributed processes executed by physically diverse systems, such as other smartphone devices.
It should be understood that the steps of the exemplary methods set forth herein are not necessarily required to be performed in the order described, and the order of the steps of such methods should be understood to be merely exemplary. Likewise, additional steps may be included in such methods, and certain steps may be omitted or combined, in methods consistent with various embodiments.
It will be further understood that various changes in the details, materials, and arrangements of the parts which have been described and illustrated in order to explain the nature of described embodiments may be made by those skilled in the art without departing from the scope as expressed in the following claims.
This application claims the benefit of the filing date of U.S. Provisional Patent Application Ser. No. 61/919,141, filed on 20 Dec. 2013, the teachings of which are incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
61919141 | Dec 2013 | US |