Providing contact data of second mobile devices proximate to a target person of a first mobile device

BACKGROUND

Mobile technology, such as that found in many smart phones, uses Global Positioning System (GPS) technology, or equivalent, to track the mobile device and identify the geographical location of such mobile devices with accuracy. Such tracking technology is often used to identify the whereabouts of a child or spouse that is the user of the mobile device. However, oftentimes contacting the user of the mobile device is difficult. For example, the audible ringer on the mobile device might be turned off or the user cannot hear the audible ringer due to loud background noise, such as at a party. While other people near the user might be of assistance, the caller is often unaware of which people are proximate to the user and is therefore unable to contact such other individuals.

SUMMARY

An approach is disclosed that identifies a location of mobile device associated with a target person, such as a spouse, child, or employee. The approach then identifies other mobile devices that have current locations that are near, or proximate to, the identified location. The requestor is then provided with contact data corresponding to one or more users of the other mobile devices.

The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages will become apparent in the non-limiting detailed description set forth below.

BRIEF DESCRIPTION OF THE DRAWINGS

This disclosure may be better understood by referencing the accompanying drawings, wherein:

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of a data processing system in which the methods described herein can be implemented;

<figref idref="DRAWINGS">FIG. 2</figref> provides an extension of the information handling system environment shown in <figref idref="DRAWINGS">FIG. 1</figref> to illustrate that the methods described herein can be performed on a wide variety of information handling systems which operate in a networked environment;

<figref idref="DRAWINGS">FIG. 3</figref> is a component diagram depicting the identification of objects and people in proximity to a located object or person;

<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart depicting setup steps performed to configure a user's preferences in a system that identifies objects and people proximate to a located object or person;

<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart showing steps taken to keep track of registered user locations at a service provider;

<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart depicting steps performed between a user and a service provider of receiving a location of a device associated with a target person that the user is trying to contact;

<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart showing steps performed to inform the user of other contacts proximate to the target person and allowing the user to contact such other contacts; and

<figref idref="DRAWINGS">FIG. 8</figref> is a flowchart showing steps of an alternative embodiment in which the service provider establishes a communication link between the requestor and one or more proximate contacts.

DETAILED DESCRIPTION

<figref idref="DRAWINGS">FIGS. 1-8</figref> show an approach that provides a way to reach a target person, such as a spouse, child, employee, etc., based on the target person's proximity to other contacts. The approach identifies a location of the target person based on a geographical location of a device, such as a smart phone, associated with the target person. In one embodiment, the geographical location is provided based upon Geographic Positioning System (GPS) technology included in the device that is associated with the target person. Other contacts are then identified based upon the target location. In one embodiment, the other contacts are associated with other mobile devices, such as smart phones, that routinely update the other contacts' current location at a service provider, such as a social media site, etc. In a further embodiment, the contacts are able to configure preferences that determine which people are provided access to the contacts' current location information. When a contact is identified that is proximate to the target person, that contact's information is provided to the requestor. The requestor can then contact such contact (e.g., via text message, phone call, etc.) to let the contact know that the requestor is attempting to reach the target person.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The detailed description has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

As will be appreciated by one skilled in the art, aspects may be embodied as a system, method or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. As used herein, a computer readable storage medium does not include a computer readable signal medium.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present disclosure are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The following detailed description will generally follow the summary, as set forth above, further explaining and expanding the definitions of the various aspects and embodiments as necessary. To this end, this detailed description first sets forth a computing environment in <figref idref="DRAWINGS">FIG. 1</figref> that is suitable to implement the software and/or hardware techniques associated with the disclosure. A networked environment is illustrated in <figref idref="DRAWINGS">FIG. 2</figref> as an extension of the basic computing environment, to emphasize that modern computing techniques can be performed across multiple discrete devices.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates information handling system <b>100</b>, which is a simplified example of a computer system capable of performing the computing operations described herein. Information handling system <b>100</b> includes one or more processors <b>110</b> coupled to processor interface bus <b>112</b>. Processor interface bus <b>112</b> connects processors <b>110</b> to Northbridge <b>115</b>, which is also known as the Memory Controller Hub (MCH). Northbridge <b>115</b> connects to system memory <b>120</b> and provides a means for processor(s) <b>110</b> to access the system memory. Graphics controller <b>125</b> also connects to Northbridge <b>115</b>. In one embodiment, PCI Express bus <b>118</b> connects Northbridge <b>115</b> to graphics controller <b>125</b>. Graphics controller <b>125</b> connects to display device <b>130</b>, such as a computer monitor.

Northbridge <b>115</b> and Southbridge <b>135</b> connect to each other using bus <b>119</b>. In one embodiment, the bus is a Direct Media Interface (DMI) bus that transfers data at high speeds in each direction between Northbridge <b>115</b> and Southbridge <b>135</b>. In another embodiment, a Peripheral Component Interconnect (PCI) bus connects the Northbridge and the Southbridge. Southbridge <b>135</b>, also known as the I/O Controller Hub (ICH) is a chip that generally implements capabilities that operate at slower speeds than the capabilities provided by the Northbridge. Southbridge <b>135</b> typically provides various busses used to connect various components. These busses include, for example, PCI and PCI Express busses, an ISA bus, a System Management Bus (SMBus or SMB), and/or a Low Pin Count (LPC) bus. The LPC bus often connects low-bandwidth devices, such as boot ROM <b>196</b> and “legacy” I/O devices (using a “super I/O” chip). The “legacy” I/O devices (<b>198</b>) can include, for example, serial and parallel ports, keyboard, mouse, and/or a floppy disk controller. The LPC bus also connects Southbridge <b>135</b> to Trusted Platform Module (TPM) <b>195</b>. Other components often included in Southbridge <b>135</b> include a Direct Memory Access (DMA) controller, a Programmable Interrupt Controller (PIC), and a storage device controller, which connects Southbridge <b>135</b> to nonvolatile storage device <b>185</b>, such as a hard disk drive, using bus <b>184</b>.

ExpressCard <b>155</b> is a slot that connects hot-pluggable devices to the information handling system. ExpressCard <b>155</b> supports both PCI Express and USB connectivity as it connects to Southbridge <b>135</b> using both the Universal Serial Bus (USB) the PCI Express bus. Southbridge <b>135</b> includes USB Controller <b>140</b> that provides USB connectivity to devices that connect to the USB. These devices include webcam (camera) <b>150</b>, infrared (IR) receiver <b>148</b>, keyboard and trackpad <b>144</b>, and Bluetooth device <b>146</b>, which provides for wireless personal area networks (PANs). USB Controller <b>140</b> also provides USB connectivity to other miscellaneous USB connected devices <b>142</b>, such as a mouse, removable nonvolatile storage device <b>145</b>, modems, network cards, ISDN connectors, fax, printers, USB hubs, and many other types of USB connected devices. While removable nonvolatile storage device <b>145</b> is shown as a USB-connected device, removable nonvolatile storage device <b>145</b> could be connected using a different interface, such as a Firewire interface, etcetera.

Wireless Local Area Network (LAN) device <b>175</b> connects to Southbridge <b>135</b> via the PCI or PCI Express bus <b>172</b>. LAN device <b>175</b> typically implements one of the IEEE 802.11 standards of over-the-air modulation techniques that all use the same protocol to wireless communicate between information handling system <b>100</b> and another computer system or device. Optical storage device <b>190</b> connects to Southbridge <b>135</b> using Serial ATA (SATA) bus <b>188</b>. Serial ATA adapters and devices communicate over a high-speed serial link. The Serial ATA bus also connects Southbridge <b>135</b> to other forms of storage devices, such as hard disk drives. Audio circuitry <b>160</b>, such as a sound card, connects to Southbridge <b>135</b> via bus <b>158</b>. Audio circuitry <b>160</b> also provides functionality such as audio line-in and optical digital audio in port <b>162</b>, optical digital output and headphone jack <b>164</b>, internal speakers <b>166</b>, and internal microphone <b>168</b>. Ethernet controller <b>170</b> connects to Southbridge <b>135</b> using a bus, such as the PCI or PCI Express bus. Ethernet controller <b>170</b> connects information handling system <b>100</b> to a computer network, such as a Local Area Network (LAN), the Internet, and other public and private computer networks.

While <figref idref="DRAWINGS">FIG. 1</figref> shows one information handling system, an information handling system may take many forms. For example, an information handling system may take the form of a desktop, server, portable, laptop, notebook, or other form factor computer or data processing system. In addition, an information handling system may take other form factors such as a personal digital assistant (PDA), a gaming device, ATM machine, a portable telephone device, a communication device or other devices that include a processor and memory.

The Trusted Platform Module (TPM <b>195</b>) shown in <figref idref="DRAWINGS">FIG. 1</figref> and described herein to provide security functions is but one example of a hardware security module (HSM). Therefore, the TPM described and claimed herein includes any type of HSM including, but not limited to, hardware security devices that conform to the Trusted Computing Groups (TCG) standard, and entitled “Trusted Platform Module (TPM) Specification Version 1.2.” The TPM is a hardware security subsystem that may be incorporated into any number of information handling systems, such as those outlined in <figref idref="DRAWINGS">FIG. 2</figref>.

<figref idref="DRAWINGS">FIG. 2</figref> provides an extension of the information handling system environment shown in <figref idref="DRAWINGS">FIG. 1</figref> to illustrate that the methods described herein can be performed on a wide variety of information handling systems that operate in a networked environment. Types of information handling systems range from small handheld devices, such as handheld computer/mobile telephone <b>210</b> to large mainframe systems, such as mainframe computer <b>270</b>. Examples of handheld computer <b>210</b> include personal digital assistants (PDAs), personal entertainment devices, such as MP3 players, portable televisions, and compact disc players. Other examples of information handling systems include pen, or tablet, computer <b>220</b>, laptop, or notebook, computer <b>230</b>, workstation <b>240</b>, personal computer system <b>250</b>, and server <b>260</b>. Other types of information handling systems that are not individually shown in <figref idref="DRAWINGS">FIG. 2</figref> are represented by information handling system <b>280</b>. As shown, the various information handling systems can be networked together using computer network <b>200</b>. Types of computer network that can be used to interconnect the various information handling systems include Local Area Networks (LANs), Wireless Local Area Networks (WLANs), the Internet, the Public Switched Telephone Network (PSTN), other wireless networks, and any other network topology that can be used to interconnect the information handling systems. Many of the information handling systems include nonvolatile data stores, such as hard drives and/or nonvolatile memory. Some of the information handling systems shown in <figref idref="DRAWINGS">FIG. 2</figref> depicts separate nonvolatile data stores (server <b>260</b> utilizes nonvolatile data store <b>265</b>, mainframe computer <b>270</b> utilizes nonvolatile data store <b>275</b>, and information handling system <b>280</b> utilizes nonvolatile data store <b>285</b>). The nonvolatile data store can be a component that is external to the various information handling systems or can be internal to one of the information handling systems. In addition, removable nonvolatile storage device <b>145</b> can be shared among two or more information handling systems using various techniques, such as connecting the removable nonvolatile storage device <b>145</b> to a USB port or other connector of the information handling systems.

<figref idref="DRAWINGS">FIG. 3</figref> is a component diagram depicting the identification of objects and people in proximity to a located object or person. User community <b>300</b> is a group of users, such as a set of social media users, employees of an organization, etc. Service provider <b>320</b> provides services to the user community, such as social media services in the case of a social media community, organizational services in the case of a business or other type of organization, and the like. One of the services that service provider <b>320</b> provides is location services so that users of the user community can geographically locate one another. Data store <b>340</b> is used to maintain user configurations, preferences, and current geographic locations of users served by service provider <b>320</b>. Location sharing data includes access data such as “whitelists” that identify users from the user community that are allowed to retrieve a particular user's current geographic location, “blacklists” that identify users from the user community that are denied access to a particular user's current geographic location, and current user location data that is periodically updated as the user moves about. The users' current geographic locations are received from the users' mobile devices, such as smart phones with GPS receivers, that identify the current geographic location of the users. A number of processes are used to update and utilize the data stored in data store <b>340</b>.

Process <b>360</b> is a user location sharing setup process that allows the users to decide which users are allowed access to the users' current geographic location data. This process updates the users' “whitelists” and “blacklists” that detail those users from the user community that are allowed to access the users' current geographic location data and those that are denied access to such data. Process <b>370</b> is the user current location handler process that routinely receives updated current location data from the users included in the user community. The location data is automatically transmitted from the users' mobile devices, such as smart phones, without the user having to manually perform any actions or functions on the device. The users' current geographic location data is stored in data store <b>340</b>.

Process <b>380</b> is the user location request handler that processes location requests from users (requestors) for the current location of other users in the user community. Process <b>380</b> determines whether a requestor can access a particular user's current location data and returns a user location response to the requestor pertaining to relevant users that have allowed the requestor access to such users' current geographic location data.

<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart depicting setup steps performed to configure a user's preferences in a system that identifies objects and people proximate to a located object or person. <figref idref="DRAWINGS">FIG. 4</figref> processing commences at <b>400</b> and shows the steps taken by a setup process that receives and stores the user's preferences. At step <b>420</b>, the user selects the first contact or group of contacts that the user wants to allow access to the user's current location data (e.g., everyone, all “friends,” etc.). Step <b>410</b> retrieves the contact data from data store <b>410</b>, such as a social media site, an organizational site listing employees of an organization, etc. Step <b>420</b> stores the data pertaining to users that are allowed to access the user's current location data in user's location whitelist data store <b>430</b>. The process next determines whether the user wishes to add more contacts to the user's whitelist (decision <b>440</b>). If the user wishes to add more contacts to the user's whitelist, then decision <b>440</b> branches to the ‘yes’ branch which loops back to step <b>420</b> to receive and process the next contact or group of contacts to add to the whitelist. This looping continues until the user does not wish to add any more contacts to the whitelist, at which point decision <b>440</b> branches to the ‘no’ branch exiting the loop.

At step <b>450</b>, the user selects the first contact or group of contacts that the user does not want to have access to the user's current location data (e.g., non-friends, blocked users, etc.). Step <b>450</b> retrieves the contact data from data store <b>410</b>, such as a social media site, an organizational site listing employees of an organization, etc. Step <b>420</b> stores the data pertaining to users that are not allowed access to the user's current location data in user's location blacklist data store <b>460</b>. The process next determines whether the user wishes to add more contacts to the user's blacklist (decision <b>470</b>). If the user wishes to add more contacts to the user's blacklist, then decision <b>470</b> branches to the ‘yes’ branch which loops back to step <b>450</b> to receive and process the next contact or group of contacts to add to the blacklist. This looping continues until the user does not wish to add any more contacts to the blacklist, at which point decision <b>470</b> branches to the ‘no’ branch exiting the loop. At step <b>480</b>, the process transmits the user's whitelist and blacklist data to service provider <b>320</b> that provides a central registration service (e.g., social media site, organization's site, etc.). The user's preferences are updated by the service provider in user preferences data store <b>340</b>. The setup processing shown in <figref idref="DRAWINGS">FIG. 4</figref> thereafter ends at <b>495</b>.

<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart showing steps taken to keep track of registered user locations at a service provider, such as a social media site, an organization's website, etc. Processing performed by the user's mobile device (e.g, smart phone, etc.) is shown commencing at <b>500</b> and includes steps <b>500</b> through <b>540</b>. The Current Location Handler is performed at the mobile device of each user that has the location tracking feature enabled. At step <b>510</b>, the process performed by the user's mobile device transmits the user's current location data to a central registration that is maintained by the service provider. The user's mobile device determines the user's current location data using GPS technology installed on the user's mobile device. At step <b>520</b>, the process waits for a period of time to elapse before sending the next location data (e.g. one minute, etc.). In one embodiment, the process only sends updated current location data when it senses that the user's current location has changed by a distance that exceeds a given threshold (e.g., when the user has moved more than five feet, etc.). At step <b>530</b>, the process performed by the mobile device retrieves user's current location from the GPS installed on the mobile device. The process determines whether the user moved to a different physical location (decision <b>540</b>). In one embodiment, the determination is made based on whether the user has moved a distance that exceeds a given threshold. If the user has moved to a different physical location, then decision <b>540</b> branches to the ‘yes’ branch which loops back to step <b>510</b> to send the user's new physical location to the service provider. On the other hand, if the user has not moved to a different physical location, then decision <b>540</b> branches to the ‘no’ branch which loops back to the wait process of step <b>520</b> without sending the user's physical location to the service provider.

Service provider processing shown in <figref idref="DRAWINGS">FIG. 5</figref> commences at <b>550</b> and includes steps <b>550</b> through <b>595</b>. These steps are taken by a process performed by a service provider (e.g., social media site, organization's website, etc.) that maintains the location registration data. At step <b>560</b>, the service provider receives the user's current physical location that was transmitted from the user's mobile device to the service provider via computer network <b>200</b>, such as the Internet. At step <b>570</b>, the service provider stores the user's current physical location that was received from the user in data store <b>340</b>. This location data is available for sharing with contacts that have been authorized by the user, such as the user's employer, spouse, family, etc. The service provider process shown in <figref idref="DRAWINGS">FIG. 5</figref> thereafter ends at <b>595</b>.

<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart depicting steps performed between a user and a service provider of receiving a location of a device associated with a target person that the user is trying to contact. Processing performed by the user's device shown in <figref idref="DRAWINGS">FIG. 6</figref> commences at <b>600</b> and depicts steps taken by the user's device to request another user's location and perform a reverse lookup on other users if desired. At step <b>610</b>, the user's device transmits a request for the current location of another user, such as the user's spouse, child, employee, etc. The request is transmitted through computer network <b>200</b>, such as the Internet, to the service provider.

Service provider processing shown in <figref idref="DRAWINGS">FIG. 6</figref> commences at <b>620</b> and shows the steps taken by the service provider (e.g., social media site, organization website, etc.) to process a location request from a requestor. At step <b>625</b>, the service provider receives a location request from the requestor via computer network <b>200</b>. The service provider process determines whether the request is for a contact location lookup for a reverse lookup for contacts that are near, or proximate to, a location provided by the requestor (decision <b>630</b>). If the request is for a particular contact, then decision <b>630</b> branches to the ‘yes’ branch to perform steps <b>635</b> through <b>650</b>. On the other hand, if the request is a reverse lookup request for those contacts proximate to a given location, then decision <b>630</b> branches to the ‘no’ branch whereupon, at predefined process <b>655</b>, the service provider performs predefined process <b>655</b> (see <figref idref="DRAWINGS">FIG. 7</figref> and corresponding text for processing details).

If the request is for the location of a particular contact then, at step <b>635</b>, the service provider checks the preferences of the contact that is being requested by the requestor. The contact's preferences are retrieved from data store <b>340</b> and includes the contact's whitelist of users allowed to access the contact's location data as well as the contact's blacklist of users not allowed to access the contact's location data. Based on the contact's preferences, the service provider determines whether to allow the requestor access to this contact's current location data (decision <b>640</b>). If the contact allows this requestor access to the contact's current location data, then decision <b>640</b> branches to the ‘yes’ branch to perform step <b>645</b>. On the other hand, if the contact does not allow this requestor access to the contact's current location data, then decision <b>640</b> branches to the ‘no’ branch to perform step <b>650</b>. In the case where the request is granted then, at step <b>645</b>, the service provider transmits the contact's current location data back to the requestor. In the case where the request is denied then, at step <b>650</b>, the process transmits an access denied error back to the requestor. Service provider processing shown in <figref idref="DRAWINGS">FIG. 6</figref> thereafter ends at <b>660</b>.

Returning to processing performed at the requestor's device, at step <b>670</b>, the requestor's device receives a response from the service provider. The requestor now determines whether a reverse lookup of other contacts near the location provided by the service provider is desired (decision <b>675</b>). If a reverse lookup of other contacts near the location provided by the service provider is desired, then decision <b>675</b> branches to the ‘yes’ branch to perform steps <b>680</b> and <b>690</b>. On the other hand, if a reverse lookup of other contacts near the location provided by the service provider is not desired, then decision <b>675</b> branches to the ‘no’ branch bypassing steps <b>680</b> and <b>690</b>.

If a reverse lookup of other contacts is desired, then at step <b>680</b>, the process transmits a reverse lookup request to the service provider with the request including the geographic area of interest to the user. In addition, the request might include a circumference or size of the area of interest around the geographic area (e.g., contacts within ten feet of the location, contacts within one hundred yards of the location, etc.). The size of the area of interest might depend on the type of environment in which the target contact was located (e.g., in a store, in a park, etc.). At predefined process <b>690</b>, the user's device performs the Reverse Lookup routine (see <figref idref="DRAWINGS">FIG. 7</figref> and corresponding text for processing details). This routine receives contact data pertaining to contacts proximate to the area of interest (e.g., those contacts near the requestor's wife, child, employee, etc.). The requestor's device process shown in <figref idref="DRAWINGS">FIG. 6</figref> thereafter ends at <b>695</b>.

<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart showing steps performed to inform the user of other contacts proximate to the target person and allowing the user to contact such other contacts. The service provider processing shown in <figref idref="DRAWINGS">FIG. 7</figref> commences at <b>700</b> and depicts the steps taken by the service provider when processing a reverse lookup request. At step <b>710</b>, the service provider process selects all contacts that are currently proximate to location provided by the requestor (e.g., within 50 feet, etc.). In one embodiment, the size of the area is a parameter that is provided in the request received from the requestor. Step <b>710</b> stores the selected contact data in proximate contacts data store <b>720</b>. At step <b>725</b>, the service provider process selects the first proximate contact from data store <b>720</b>.

At step <b>730</b>, the service provider process checks the selected contact's preferences (e.g., whitelist, blacklist, etc.) to determine if the selected contact allows this user (the requestor) access to the selected contact's current location data. The service provider process determines as to whether the requestor is allowed access to the selected contact's location data (decision <b>735</b>). If the requestor is allowed access to the selected contact's location data, then decision <b>735</b> branches to the ‘yes’ branch to perform step <b>740</b>. On the other hand, if the requestor is not allowed access to the selected contact's location data, then decision <b>735</b> branches to the ‘no’ branch bypassing step <b>740</b>. At step <b>740</b>, the service provider process retains the selected contact's data in filtered proximate contacts data store <b>755</b>.

The service provider process determines whether there are more proximate contacts to process (decision <b>750</b>). If there are more proximate contacts to process, then decision <b>750</b> branches to the ‘yes’ branch which loops back to step <b>725</b> to select and process the next proximate contact as described above. This looping continues until there are no more proximate contacts to process, at which point decision <b>750</b> branches to the ‘no’ branch exiting the loop. At step <b>760</b>, the service provider process transmits the retained (filtered) contact data to the requesting user or transmits an error to the requestor if no proximate contacts were found that can be provided to this requestor. The service provider processing shown in <figref idref="DRAWINGS">FIG. 7</figref> thereafter ends at <b>765</b>.

The requestor's processing performed at the requestor's device shown in <figref idref="DRAWINGS">FIG. 7</figref> commences at <b>770</b> and shows the steps taken by the requestor's device to process a reverse lookup for contacts in a given geographic area. At step <b>775</b>, the requestor's device receives a response from the service provider. The process performed by the requestor's device determines as to whether the service provider provided data pertaining to one or more proximate contacts (decision <b>780</b>). If the service provider provided data pertaining to one or more proximate contacts, then decision <b>780</b> branches to the ‘yes’ branch to perform steps <b>785</b> and <b>790</b>. On the other hand, if the service provider did not provide data pertaining any proximate contacts, then decision <b>780</b> branches to the ‘no’ branch bypassing steps <b>785</b> and <b>790</b>.

At step <b>785</b>, the requestor selects one or more of the proximate contacts that were provided by the service provider to contact electronically. At step <b>790</b>, the process performed by the requestor's device receives input from the requestor to contacts one or more contact(s) proximate to the geographic area of interest (e.g., area where the requestor's spouse, child, employee is currently located, etc.). The contact can be made using any communication means such as a text message, phone call, etc. The process performed by the requestor's device as shown in <figref idref="DRAWINGS">FIG. 7</figref> thereafter ends at <b>795</b>.

<figref idref="DRAWINGS">FIG. 8</figref> is a flowchart showing steps of an alternative embodiment in which the service provider establishes a communication link between the requestor and one or more proximate contacts. Processing performed by the requestor in <figref idref="DRAWINGS">FIG. 8</figref> commence at <b>800</b> and shows the steps taken by the requestor that is attempting to communicate with a target person that is proximate to one or more contacts. At step <b>805</b>, the process performed by the requestor's device sends a request (e.g., emergency, etc.) to the service provider.

Processing performed by the service provider in <figref idref="DRAWINGS">FIG. 8</figref> commence at <b>810</b> and shows the steps taken by the service provider (e.g., social media site, organization's site, etc.) that facilitates communication between the requestor and one or more contacts that are proximate to the target person. At step <b>815</b>, the service provider process receives the request from the requestor and attempts to authenticate the requestor. For example, a user identifier and password might be used or other authentication means. The process determines as to whether the requestor was authenticated by the service provider (decision <b>820</b>). If the requestor was authenticated by the service provider, then decision <b>820</b> branches to the ‘yes’ branch for further processing. On the other hand, if the requestor was not authenticated by the service provider, then decision <b>820</b> branches to the ‘no’ branch and processing ends at <b>825</b>.

The process performed by the service provider determines whether the situation (if any) reported by the requestor should be verified before contacting the proximate contacts (decision <b>830</b>). If the situation should be verified, then decision <b>830</b> branches to the ‘yes’ branch to perform step <b>835</b>. On the other hand, if the situation need not be verified, then decision <b>830</b> branches to the ‘no’ branch bypassing step <b>835</b>. At step <b>835</b>, the service provider process attempts to verify the situation reported by the requestor. The service provider might use news reports, contact emergency responders, or the like, to verify the situation. The service provider process determines whether the situation was successfully verified (decision <b>840</b>). If the situation was successfully verified, then decision <b>840</b> branches to the ‘yes’ branch for further processing. On the other hand, if the situation was not successfully verified, then decision <b>840</b> branches to the ‘no’ branch whereupon processing ends at <b>845</b>.

The service provider process determines whether to over-ride privacy preferences made by contacts based on the requestor and/or the situation that is being reported (decision <b>850</b>). If the system decides to over-ride contact privacy preferences, then decision <b>850</b> branches to the ‘yes’ branch to perform step <b>855</b>. On the other hand, if the system decides to not over-ride contact privacy preferences based on the requestor and/or the situation, then decision <b>850</b> branches to the ‘no’ branch to perform step <b>860</b>. At step <b>855</b>, the service provider process selects all proximate contacts from data store <b>340</b> that are proximate to the target person regardless of the proximate contacts' privacy settings. If contact privacy settings are being observed, then at step <b>860</b>, the service provider process selects all contacts that are proximate to the target person and that allow the requestor access to such contacts' current location data. The service provider process stores the relevant proximate contact data in contacts data store <b>865</b>.

At step <b>870</b>, the service provider process performs an optional process that transmits a photograph of the target person to the proximate contacts with an appropriate message to convey to target (e.g., “important message—you are currently near the pictured individual that the requestor is trying to contact—please help by notifying the pictured target person of the communication request.”). Processing performed by the proximate contacts that are being contacted in <figref idref="DRAWINGS">FIG. 8</figref> commence at <b>875</b> and shows the steps taken by the contacts that are proximate to the target person. At step <b>880</b>, the process performed by the proximate contacts' devices receives a message with a photograph of the target person along with an appropriate message. At step <b>885</b>, the services provider process provides a communication link between one or more proximate contacts and the requestor. The communication link allows the requestor's device to communicate (e.g., voice, text, etc.) with one or more devices used by proximate contacts without the requestor being provided with identification information (e.g., telephone numbers, name, etc.) of the proximate contacts. At step <b>890</b>, the process performed by the requestor's communication device (e.g., smart phone, etc.) communicates with one or more proximate contacts using the communication link provided by the service provider. Likewise, at step <b>895</b>, the process performed by the proximate contact(s) communicates with the requestor using the communication link provided by the service provider.

While particular embodiments have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, that changes and modifications may be made without departing from this invention and its broader aspects. Therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.