WO2010113028A2 - Apparatuses, methods and systems for dynamically locating a global position to interface over mobile communications - Google Patents

Abstract

The apparatuses, methods and systems for dynamically locating a global position to interface over mobile communications ("DLGP-IMC") provides services based on dynamic geographical global locations of a registered user. In some embodiments, the DLGP-IMC is configured to provide social networking services such as dating features to a user. In some embodiments, the DLGP-IMC provides shopping locations with specialized incentives in proximity with a current global geographic location. In one embodiment, the DLGP-IMC is configured to locate a user's location through a message received. While in another implementation, the DLGP-IMC is configured so that the dynamic global location of a registered user can be based on calculated geographical coordinates of the registered user. In one embodiment, the DLGP-IMC is configured for launching message based advertising campaigns on behalf of business subscribers to target customers matching one or more campaign criteria.

Description

APPARATUSES, METHODS AND SYSTEMS FOR DYNAMICALLY

LOCATING A GLOBAL POSITION TO INTERFACE OVER

MOBILE COMMUNICATIONS

RELATED APPLICATIONS

[oooi] Furthermore, applicant hereby claims priority under 35 USC §119 for United States provisional patent application serial no. 61/166,652 filed April 3, 2009, entitled "APPARATUSES, METHODS AND SYSTEMS FOR DYNAMICALLY LOCATING A GLOBAL POSITION TO INTERFACE OVER MOBILE COMMUNICATIONS," attorney docket no. 20047-002PV. The entire contents of the aforementioned application are herein expressly incorporated by reference.

FIELD

[0002] The present invention is directed generally to an apparatuses, methods, and systems of communications based on global positioning, and more particularly, to APPARATUSES, METHODS AND SYSTEMS FOR DYNAMICALLY LOCATING A GLOBAL POSITION TO INTERFACE OVER MOBILE COMMUNICATIONS.

BACKGROUND

[0003] Mobile communications are utilized by a variety of users and employ various technologies. Different devices including cellular phones, handheld devices, 1 personal computers, music players, and other wireless devices utilize mobile

2 communications. These devices employ various wireless technologies and operating

3 systems that allows users to communicate.

SUMMARY

5 [0004] The APPARATUSES, METHODS AND SYSTEMS FOR DYNAMICALLY

6 LOCATING A GLOBAL POSITION TO INTERFACE OVER MOBILE

7 COMMUNICATIONS (hereinafter "DLGP-IMC") provides services based on dynamic

8 geographical global locations to a registered user. In particular, this disclosure

9 discusses the various aspects and applications of the DLGP-IMC. In some

10 embodiments, the DLGP-IMC is configured to provide social networking services such

11 as dating features to a user. In some embodiments, the DLGP-IMC provides shopping

12 locations with specialized incentives in proximity with a current global geographic

13 location. In one embodiment, the DLGP-IMC is configured to locate a user's location u through a received message. While in another implementation, the DLGP-IMC is

15 configured so that the dynamic global location of a registered user can be based on

16 calculated geographical coordinates of the registered user. Depending on the

17 embodiment, the DLGP-IMC may be implemented and/or configured for a variety of

18 uses and industries, such as, by way of non-limiting example, social networking,

19 commerce, supply chain and sales, automotive (e.g., GPS and entertainment), vendors

20 and sellers, tourism industries, airlines and transportation industry, and/or the like. In

21 one embodiment, the DLGP-IMC is configured for launching message based advertising

22 campaigns on behalf of business subscribers to target customers matching one or more 1 campaign criteria. In one embodiment, the DLGP-IMC is configured to provide

2 proximity-based introduction and communication services to users. In one

3 embodiment, the DLGP-IMC may be configured to receive a request from a requestor

4 with a unique request identifier and provide a query to resolve the unique request

5 identifier for a request location origin. In a further embodiment, the DLGP-IMC may be

6 configured to receive the request location origin and identify proximate subscribers

7 based on the received request location origin. In one embodiment, the DLGP-IMC may β provide a selection of identified proximate subscribers and may receive a selection of a

9 proximate subscriber. In one embodiment, the DLGP-IMC may provide the selected0 proximate subscriber with a communication request, receive a response to the1 communication request from the selected proximate subscriber and provide the2 requestor with a response acknowledgement based on the received response to the3 communication request. 4 BRIEF DESCRIPTION OF THE DRAWINGS s [0005] The accompanying appendices and/or drawings illustrate various non-6 limiting, example, inventive aspects in accordance with the present disclosure: 7 [0006] FIGURE ι(a) and (b) are data flow diagrams illustrating aspects of thes APPARATUSES, METHODS AND SYSTEMS FOR DYNAMICALLY LOCATING A9 GLOBAL POSITION TO INTERFACE OVER MOBILE COMMUNICATIONS0 (hereinafter "DLGP-IMC"); [ooo7] FIGURE 2(a)-(f) are screen shot diagrams illustrating registration by mobile device in one embodiment of the DLGP-IMC; [0008] FIGURE 3(a)-(b) are screen shot diagrams illustrating registration by web in one embodiment of the DLGP-IMC; [0009] FIGURE 4(a)-(c) are screen shot diagrams illustrating registration by web in another embodiment of the DLGP-IMC; [0010] FIGURE 5 is a data flow diagram illustrating geolocation in one embodiment of the DLGP-IMC; [0011] FIGURE 6 is a logic flow diagram illustrating geolocation in one embodiment of the DLGP-IMC; [0012] FIGURE 7 is a logic flow diagram illustrating establishing communication with a matching subscriber in one embodiment of the DLGP-IMC; [0013] FIGURE 8(a)-G) are screen shot diagrams illustrating establishing communication with a subscriber in one embodiment of the DLGP-IMC; [0014] FIGURE 9 is a logic flow diagram illustrating web and mobile phone based geolocation of a subscriber via his/her mobile phone number in one embodiment of the DLGP-IMC; [0015] FIGURE 10 is a logic flow diagram illustrating web-based geolocation of a subscriber via his/her mobile phone number in one embodiment of the DLGP-IMC; [0016] FIGURE 11 is a screen shot diagram illustrating aspects of the web and mobile based subscriber geolocation in an embodiment of the DLGP-IMC; 1 [ooi7] FIGURE i2(a) and (b) are screen shot diagrams illustrating subscriber

2 geolocation implementation in some embodiments of the DLGP-IMC;

3 [0018] FIGURE 13 is a logic flow diagram illustrating aspects of a message-based

4 store locator in an embodiment of the DLGP-IMC;

5 [0019] FIGURE 14 is a logic flow diagram illustrating aspects of a client-based

6 store locator implemented in an embodiment of the DLGP-IMC;

7 [0020] FIGURE i5(a)-(h) are screen shot diagrams illustrating aspects of a client- β based store locator implemented in an embodiment of the DLGP-IMC;

9 [0021 ] FIGURE i6(a), (b) and (c) are screen shot diagrams illustrating aspects of0 a text message based advertisement campaign in an embodiment of the DLGP-IMC; 1 [0022] FIGURE i7(a), (b), (c) and (d) are screen shot diagrams illustrating2 aspects of a text message based advertisement campaign in another embodiment of the3 DLGP-IMC; 4 [0023] FIGURE 18 is a logic flow diagram illustrating targeting an advertisement5 campaign to a customer in an embodiment of the DLGP-IMC; 6 [0024] FIGURE 19 is of a block diagram illustrating embodiments of the DLGP-7 IMC controller. s [0025] The leading number of each reference number within the drawings9 indicates the figure in which that reference number is introduced and/or detailed. As0 such, a detailed discussion of reference number 101 would be found and/or introduced1 in Figure 1. Reference number 201 is introduced in Figure 2, etc. , DETAILED DESCRIPTION

2 DLGP-IMC

3 [0026] FIGURE ι(a) is a diagram illustrating aspects of the APPARATUSES,

4 METHODS AND SYSTEMS FOR DYNAMICALLY LOCATING A GLOBAL POSITION TO INTERFACE OVER MOBILE COMMUNICATIONS (hereinafter "DLGP-IMC"). A user or customer may register an account or an authentication code using a personal computer through web services in 120. In one embodiment a user or customer may register an account or an authentication code using a portable/handheld device 102 through mobile (Wired Equivalent Privacy) registration in 105. In one embodiment, as seen in box 125, an opt in proposal maybe sent to the registered mobile device 1021 where the user can reply to the proposal in 130. A confirmation is sent in 135 through a mobile device 102 to complete the user or customer registration. In another embodiment, a confirmation may be sent to the user's personal computer in 140.

[0027] FIGURE i(b) is a diagram illustrating aspects of the DLGP-IMC. In one embodiment once a customer has registered, they can interact with other registered users. In one implementation a conversation request may be sent in 150 through a mobile device 110 to another user in 152, 153, and 155. No response may be received from an unavailable or uninterested user in 152 and 153. However, a response may be received from a user in 155 in one embodiment. The recipient interested user may respond to the sender using a mobile device in 110. As such, a text conversation may1 occur between the two users through mobile devices 110 in 160 and 165. In one embodiment users may exchange text messages without disclosing their identity or their cell phone numbers. These messages may be routed through DLGP-IMC servers so no personal details may be disclosed. Users with cellular phones may use a text message solution that offers texting solutions and services. In one embodiment, messages may be sent using Short Message Service (SMS). In another embodiment, messages may be sent using Multimedia Message Service (MMS). No software download may be needed. Geo- localization and communication may be accomplished by text messaging and (optional) Wireless Application Protocol (WAP) links (or waplinks) to geographical maps. Two users exchanging messages in one embodiment may setup meeting dates in 170 through mobile devices 110. In an alternate embodiment, users may download client applications for messaging and/or arranging meeting with other registered users/subscribers of interest. [0028] FIGURE 2(a)-(f) are screen shot diagrams illustrating registration by mobile device in one embodiment of the DLGP-IMC. In one embodiment, the user may initiate subscription by his/her mobile device. In a further embodiment, the subscription may be via an SMS or an MMS message and may include an action keyword for subscription (e.g., subscribe) and the user's mobile phone number as shown in FIGURE 2(a). In one embodiment, the DLGP-IMC, in response to the subscription request, may request the user to provide an alias and password as shown in FIGURE 2(b) and the user may send his/her alias and password to the DLGP-IMC as shown in FIGURE 2(c). In one embodiment, the DLGP-IMC may request the user for basic personal details (e.g., address) as in FIGURE 2(d) and the user may respond with the basic personal details as shown in FIGURE 2(e). In one embodiment, the DLGP-IMC, after receiving basic information from the user, may send a confirmation message 1 requesting the user to complete his/her profile online on a provided website as shown in

2 FIGURE 2(0- In a further embodiment, the message may include a waplink to the

3 website. In one embodiment, the user may be requested to complete his/her online

4 profile within a specified period of time in order to activate the service. In an alternate

5 embodiment, the user after receiving the confirmation message, may immediately start

6 using the DLGP-IMC service to find new people/subscribers. In one embodiment, the

7 service may be activated by the user at any time by sending an SMS message containing

8 an activation action keyword (e.g., online). In an alternate embodiment, an active

9 service may be suspended/deactivated at any time by the user by sending an SMS

10 message containing a deactivation action keyword (e.g., offline).

11 [0029] In an alternate embodiment, registration may be web based. FIGURE '2 3(a)-(b) are screen shot diagrams illustrating registration by web in one embodiment of

13 the DLGP-IMC. In one embodiment, during registration, the DLGP-IMC may request

14 the user to provide personal information such as the user's alias/nick name, phone

15 number, email, gender, address, personal message, phone number, etc as shown in

16 FIGURE 3(a) -(b).

1? [0030] FIGURE 4(a)-(c) are screen shot diagrams illustrating registration by web

18 in another embodiment of the DLGP-IMC. In one embodiment, the user may create a

19 personal profile during the registration. The user may provide preferences including but

20 not limited to: gender, age group, interests (e.g., sports, travel, books, high tec, cuisine,

21 music, automobiles, fashion, etc), and/or the like. In a further embodiment, the DLGP- 22 IMC may allow the user to enter items within each profile category/sub-category. In one 23 embodiment, after providing personal and/or profile information to the DLGP-IMC, the 1 DLGP-IMC may generate and display a confirmation code. In a further embodiment, the

2 user may send the confirmation code to a provided text messaging number to complete

3 the registration and receive confirmation via his/her mobile device.

4 [0031] FIGURE 5 is a data flow diagram illustrating geolocation in one

5 embodiment of the DLGP-IMC. In one embodiment, a user may discover subscribers in

6 his/her vicinity by using geolocation service. In one embodiment, the service may be

7 initiated by an SMS message to the DLGP-IMC to find subscribers. In one embodiment, β the DLGP-IMC may analyze/process the SMS message to determine the identity of the

9 mobile device and use the identifying information to query a telecom operator for the0 user's location. The DLGP-IMC may look up subscribers in the vicinity of the user based1 on a query to the database of subscribers and their last known locations and provide the2 subscribers' information to the user in an SMS/MMS message for user selection. In one3 embodiment, the user may select a subscriber and request communicate with the4 selected subscriber. In an alternate embodiment, the user may select multiple5 subscribers and request communication with all selected subscribers. In one6 embodiment, the DLGP-IMC may send a communication request to the selected7 subscriber and may receive a positive or a negative response. In one embodiment, if thes response is positive, the user and the positively responding subscriber may exchange9 messages. In a further embodiment, the user and the subscriber may desire anonymity0 and may use the DLGP-IMC as a go between to route messages. In one embodiment, if1 the response is negative, the DLGP-IMC may select the next closest subscriber and2 request communication. In an alternate embodiment, the DLGP-IMC may send a3 message to the user to reselect a subscriber. [OO32] FIGURE 6 is a logic flow diagram illustrating geolocation in another embodiment of the DLGP-IMC. In one embodiment, a user may initiate the process of geolocating himself/herself via an SMS message sent through a mobile device. The DLGP-IMC in 605 may receive the text message sent by the user containing an action keyword (e.g., geoloc) requesting the location of the user. In 610, the DLGP-IMC may process the Mobile Subscriber Integrated Services Digital Network Number (MSISDN) associated with the incoming SMS message to identify the user. The DLGP-IMC, in 615, may query the telecom operator based on the MSISDN for the location co-ordinates of the user. The telecom operator may look up the last known location of the user identified by the MSISDN and retrieve location co-ordinates in latitude and longitude for transmission to the requesting DLGP-IMC. In 620, the DLGP-IMC may receive the user's location in latitude and longitude form. In one embodiment, in 625, the DLGP- IMC may consult a location database to determine a physical address corresponding to the latitude and longitude co-ordinates. In a further embodiment, in 630, the DLGP- IMC may store the user's last known location in a user database. In one embodiment, the DLGP-IMC may send the user's physical address to the user's mobile device via an SMS message. In a further embodiment, the DLGP-IMC may generate a map identifying the user's physical address and send it to the user. In one embodiment, the DLGP-IMC may send a link to a dedicated WAP page, which may be clicked by the use to view the generated map. In another embodiment, the DLGP-IMC may send an MMS message with an image of the generated map. The user may then view the map identifying his/her location on the display of his/her mobile device. [OO33] In an example embodiment, the request to the telecom operator for the user's location co-ordinates may be implemented in PHP script as below:

$url = "https: //mlp. orange. fr/LocationQueryService" ; $sql = "SELECT telephone FROM mookup where numeroOrange = ' $mobile_number ' " ; $res = mysql_query ($sql) ; $row = mysql fetch assoc($res) ; $request_geoloc = request_geoloc ($row[ "telephone" ] ) ;

$latitude = $degre_lat itude + $nunute_latitude + $seconde_lat ltude; $longitude = $degre_longitude + $minute_longitude + $seconde_longitude; $sql = "UPDATE 'mookup" SET 'latitude¹ = '$latitude\ 'longitude' = '$longitude' WHERE 'numeroOrange' = ' $mobile_number ' LIMIT 1"; $res = mysql_query ($sql) ; if (mysql_affeeted_rows () == 0) { echo "ca passe"; $sql = "INSERT INTO mookup ('numeroOrange', 'latitude', 'longitude') VALUES ( ' $mobile_number ' , '$latitude', $longitudβ) " ; $res = mysql_query ($sql ) ; ) $address = $latitude . ", " . Slongitude; return $address; Jelseif ($resid == "4")( reponse_netsize ("IBLUEPOINT VOUS n'avez pas autorise Ibluepomt a vous localiser. Envoyez OUI ibluepoint (miniscule) au 20633", $mobile number); $address = 0; retu rn $address ; } else { reponse_netsize ("IBLUEPOINT Probleme lors de votre geolocalisat ion . Merci de reessayer ulteneurement " , $mobile_number) ; $address = 0; return $address ; ) [0034] FIGURE 7 is a logic flow diagram illustrating establishment of communication between a user and a matching subscriber in one embodiment of the DLGP-IMC. In one embodiment, the user may initiate the process of finding a matching subscriber to communicate with by sending an SMS message containing an action keyword (e.g., geoloc) to the DLGP-IMC. The DLGP-IMC may, in response to the user's SMS code, initiate a query for the user location from the telecom operator. The DLGP- IMC may then query the telecom operator for subscribers whose last known locations are within a predefined geographical radius of the user's current location. In one embodiment, before making the query, the DLGP-IMC may retrieve the predefined geographical radius and generate a set of co-ordinates mapping the circumference of the predefined radius and with the user's current location as the origin on the map. The DLGP-IMC may then transmit the generated set of co-ordinates to the telecom operator to assist the operator in determining the subscribers whose last known co-ordinates are within a predefined geographical radius of the user. In an alternate embodiment, a software package/code may be used to determine the subscribers that are within a geographical radius of the user. At 715, the DLGP-IMC receives information identifying all such subscribers. In one embodiment, the DLGP-IMC may query its database storing subscriber ids and last known locations to identify all subscribers within a geographical radius of the requesting user.

[0035] The DLGP-IMC, in 720 may retrieve the user's and the identified subscribers' profile data for comparison in 725. In one embodiment, the comparison may be based on one or more criteria. For example, gender, age and a plurality of interests including but not limited to: sports, travel, books, high tec, cuisine, music, automobiles, fashion, etc. In a further embodiment, the DLGP-IMC may allow entry of items within each category. For example, under the category music, a user may enter genres such as jazz, blues, rock, etc, or music artists such as Norah Jones, Pink Floyd, etc. Based on the level of detail provided in the profile data, the DLGP-IMC may compare one or more profile categories between the user and each subscriber to determine if they match any items and/or categories. In one embodiment, the DLGP- IMC may add each item and/or category matching to generate a matching score. In a further embodiment, the DLGP-IMC may rank the subscribers from the highest score to 1 the lowest score. In one embodiment, in 730, if there are no matching subscribers, the

2 DLGP-IMC may generate and may send to the user a "not found" message as shown in

3 732. In another embodiment, if there are matching subscribers, the DLGP-IMC in 736

4 may determine if the number of matching subscribers is greater than a threshold

5 number (e.g., five). In one embodiment, the number of matching subscribers may be e more than the threshold, in which case, the DLGP-IMC may identify top threshold 7 number of subscribers to the user. In an alternate embodiment, the number of matching β subscribers may be less than the threshold. In such a case, the DLGP-IMC may identify

9 all matching subscribers to the user. In 750, the DLGP-IMC may provide the identified

10 subscribers' profile information such as, but not limited to: alias, picture, gender, age

11 and location to the user. The user, based on the profile information, may select a

12 matching subscriber and may request to communicate with the selected subscriber in

13 755 by sending an SMS message containing the alias name of the selected subscriber to

14 the DLGP-IMC. In one embodiment, the DLGP-IMC in 770 may send the user's request

15 to communicate to the selected subscriber. If the selected subscriber refuses to

16 communicate with the user, the DLGP-IMC may remove the unwilling subscriber from

17 further participation and select the next closest subscriber. If the newly selected

18 subscriber agrees to communicate with the user, the DLGP-IMC may act as a go-

19 between receiving and delivering messages from the user to the subscriber and vice

20 versa. In this way, the subscriber's phone number or name remains anonymous and it is

21 up to the subscriber to disclose such information to the user.

22 [0036] FIGURE 8(a)-Q) are screen shot diagrams illustrating establishing

23 communication with a subscriber in one embodiment of the DLGP-IMC. In one 1 embodiment as shown in FIGURE 8(a), the user may request to meet new people in

2 his/her proximity by sending an SMS message containing an action keyword (e.g.,

3 friends). The DLGP-IMC, as shown in FIGURE 8(b) may respond with a request to

4 gelocate the user if the user's location details require updating or are non-existent. The

5 DLGP-IMC, as shown in FIGURE 8(c), may ascertain and as shown in FIGURE 8(d),

6 may provide the user's location and inquire if he/she would like to see subscribers in his

7 proximity. The user in FIGURE 8(e) may reply in an SMS message an action keyword β (e.g., see) to view proximate subscribers. The DLGP-IMC, as shown in FIGURE 8(f) may

9 provide profile information of the closest subscriber to the user and other options such0 as view a list of five closest subscribers, see picture of the subscriber, send a message,1 flirt, etc. In one embodiment, as shown in FIGURE 8(g), the user may reply an action2 keyword "list" to opt to see a list of subscribers close to his/her location. In one3 embodiment, as in FIGURE 8(h), the DLGP-IMC may in response to the user's request,4 provide a message with a link to a dedicated WAP page. In an alternate embodiment, thes DLGP-IMC may provide the user an MMS message with a map showing five closest6 matching customers and their profiles, as shown in FIGURE 8(i). In a further7 embodiment, as shown in FIGURE 8(j), the user may request to see the profile of a8 selected subscriber using an action keyword "profile." In one embodiment, the DLGP-9 IMC may respond with a WAP page link/MMS message with the selected subscriber's0 profile as shown in FIGURE 8(k). In a further embodiment, as in FIGURE 80), the user1 may view the selected subscriber's profile picture. In one embodiment, the user may2 send an SMS message to the selected subscriber via the DLGP-IMC. The selected 1 subscriber may receive the message from the user and respond directly or via the DLGP- 2 IMC.

3 [0037] FIGURE 9 is a logic flow diagram illustrating web and mobile phone based

4 geolocation of a subscriber via his/her mobile phone number in one embodiment of the

5 DLGP-IMC. In one embodiment, in 902, a user may visit a website through a personal

6 computer or a mobile device with internet browsing capabilities to determine

7 geographic location of a subscriber with a mobile device. The website in 906 may β prompt the user to register if the user is using the geolocation service for the first time.

9 In a further embodiment, the DLGP-IMC may store the received registration data in a

10 user database in 908. The user may log in to the website in 910 to initiate the process of

11 locating a subscriber. In one embodiment, the user may send an SMS message

12 containing an action keyword (e.g., locate) to a dedicated short code number in 914. The

13 DLGP-IMC in response to the received code or identifier, may generate another unique

14 code and send it to the user's mobile device in 420. The user upon receiving the unique

15 code in 922, may enter the code and a mobile phone number on the form in 424 and

16 submit it to the DLGP-IMC as seen in 926. The DLGP-IMC may then validate the

17 received code in 930 to make sure that the user has not used this code previously. In

18 932, the DLGP-IMC may send an SMS message with a request to the mobile phone

19 number that needs to be located. In one embodiment, while the mobile phone number is

20 being located, a response page (for example, a web page, WAP page, a text message,

21 and/or the like) may display a "please wait" screen. In one embodiment, the owner of

22 the mobile device that has been identified by the DLGP-IMC may agree to the request of

23 being located in 934 resulting in a location map being generated in 940 and displayed 1 on the website in 944. However, in an embodiment where the owner of the mobile

2 device does not agree to be located or does not respond, or the DLGP-IMC is incapable

3 of locating the tracked cell device, an error message (e.g., "not found") is generated and

4 displayed on the website of the tracking user in 946.

5 [0038] FIGURE 10 is a logic flow diagram illustrating web-based geolocation of a

6 subscriber via his/her mobile phone number in one embodiment of the DLGP-IMC. In

7 one embodiment, the DLGP-IMC provides a website in 1002 which may be accessed by

8 a user in 1004. Registration may be required for first time users and any registration

9 data may be received and stored by the DLGP-IMC in 1010. The DLGP-IMC may then

10 provide a webpage for the user to log in and access a form at 1016. In one embodiment,

11 the form may be filled out by the user by entering the mobile phone number to be

12 located in 1018. The user may then electronically submit the form to the DLGP-IMC in

13 1020. The DLGP-IMC may then receive the mobile phone number to be located and

14 send a message to the mobile phone number inquiring if the owner of the mobile phone

15 number wants to be located by the user in 1022 and 1024. In one embodiment, the

16 owner may respond to agree to being located by the user. The DLGP-IMC in 1032

17 queries the telecom operator for the last known location of the owner and at 1034

18 generates and sends to the user a map with the location of the owner. The user receives

19 and views the map in a display at 1038 and 1040. In another embodiment, the owner

20 may desire to not be located, may have his/her mobile device turned off, may be with a

21 telecom operator that does not permit geolocation or the owner may not have

22 responded. In each of these cases, the DLGP-IMC may generate a "not found" message

23 in 1034 and display the message to the user at 1042. 1 [OO39] FIGURE ii is a screen shot diagram illustrating aspects of the web and

2 mobile based subscriber geolocation in an embodiment of the DLGP-IMC. In one

3 embodiment, the website for geolocating a subscriber may look similar to that

4 illustrated in Figure ii. In one embodiment, the website may have step by step

5 instructions for geolocating a subscriber. In another embodiment, the code or identifier

6 which may accompany a text message request to locate a subscriber may be provided for

7 the user. In one embodiment, text boxes may be provided for entering, for example, any β code received from the DLGP-IMC, user name/alias and mobile phone number to be

9 located. In a further embodiment, a "submit" or "locate" button may be provided to0 request the DLGP-IMC for the location of the mobile phone number. 1 [0040] FIGURE i2(a) and (b) are screen shot diagrams illustrating subscriber2 geolocation implementation in an embodiment of the DLGP-IMC. In one embodiment,3 Figure 7(a) illustrates the user's mobile device receiving an exemplary code "A45678"4 generated by the DLGP-IMC in response to the code or identifier (e.g., locate) for5 geolocating a subscriber sent in an SMS message to the subscriber. In one embodiment,6 Figure 7(b) illustrates an exemplary message that the owner of the mobile phone to be7 located may receive from the DLGP-IMC on behalf of the requesting user. In one8 embodiment, the message may include an action keyword (e.g., OK) that the owner may9 use in a reply SMS message to confirm. In another embodiment, the message may0 indicate the cost to be incurred by the owner if the owner replies to the message. 1 [0041] In one example embodiment, the geolocation service may be implemented2 in PHP script as below: if ($r->faultCode() ) ( reponse_netsize( "IBLUEPOINT Erreur lors de votre geolocalisation. Merci de reessayer ulterieurement.", $mobile_number) ,

$address = 0; return $address; ) else (

$os=$r->value( ) ;

$sk=$os->scalarval () ;

$f=new xπilrpcmsg ( ' Deveryflow. locationRequest ' ) ; $f->addParam(new xmlrpcval ($sk) );

$f->addParam(new κmlrpcval ("alias: //SFR/" . $mobile_number,

"string") ) ;

$ f->addParam (new κml rpcval ( 0, " int " ) ) ;

$c->set Debug ( 0 ) ;

$r=& $c->send ( $f ) ; s leep ( 20) ; if ($r->faultCode( ) ) { reponse_netsize( "IBLUEPOINT Erreur lors de votre geolocalisation. Merci de reessayer ulterieurement.", $mobile_number) ;

$address = 0; return $address; ) else (

$f=new xmlrpcmsg ( ' Deveryflow. getLastLocation ' ) ; $f->addParam(new xmlrpcval ($sk) ) ; $f->addParam(new

/.mlrpcval ( "alias : //SFR/" . $mobile_number, "string") ) ;

$c->setDebug (0) ; $r=&$c->send($f) ; if ($r->faultCode() ) ( reponse_netsize( "IBLUEPOINT Erreur lors de votre geolocalisation. Merci de reessayer ulterieurement .", $mobile number); $address = 0; return $address; ) else {

$rval=$r->value ( ) ;

$rstate = $rval->structMem( "state" ) ->scalarval (); $rττud = $rval->structMem( "mid" ) ->scalarval ( ) ; $rlongitude = $rval->structMem( " longitude" )-

>scalarval ( ) ;

$rlatitude = $rval->st ructMem( "latitude" )- >scalarval ( ) ;

$raltitudeo = $rval->structMem ("altitude" );

$raltitude = 'not for this mobile'; if ($raltitudeo) (

$raltitude = $raltitudeo->scalarval ( ) ;

)

$sql = "UPDATE "mookup¹ SET 'latitude¹ =

¹ $rlatitude ' , longitude¹ = '$rlongitude ' WHERE "numeroOrarige ' = '$mobile_number' LIMIT 1";

$res = mysql_query ($sql ) ; if (mysql_affected_rows ( ) == 0)

{

$sql = "INSERT INTO 'mookup ( 'numeroOrange ' ,

'latitude', 'longitude') VALUES ( ' $mobile_number ' , '$rlat itude ' , $rlongitude) " ;

$res = mysql_query ($sql) ;

$address = $rlat itude. " , " . $rlongitude;

$f=new xmlrpcmsg ( ' Deveryflow. closeSession ' ; $f->addParam(new xmlrpcval ($sk) ) ; $c->setDebug(0) ; $r=&$c->send($f) ; return $address; ) ) ] ) [0042 ] FIGURE 13 is a logic flow diagram illustrating aspects of a store locator in an embodiment of the DLGP-IMC. In one embodiment, the DLGP-IMC may receive a user request to locate a product or a store via an SMS message containing an action keyword (e.g. store) in 1302. In one embodiment, the DLGP-IMC may locate the user using the user's mobile phone number in 1304. In a further embodiment, DLGP-IMC may request permission from the user to ascertain his/her location. In one embodiment, upon receiving the code or identifier, the DLGP-IMC in 1306 may initiate a query into a stores database to determine a matching store or stores selling matching products. The DLGP-IMC in 1308 may provide the requesting user with a listing of matching stores. In one embodiment, the provided listing may contain store information such as name, address, associated store ID, map showing the store location and/or the like. In another embodiment, the provided listing of stores in 1308 and 1312 may be arranged according to their proximity to the user's current location. In a further embodiment, in 1310, the user may be able to change the criteria according to which the stores are listed. For example, the stores may be listed according to their reviews, size, distance from city center, etc. In 1314, the user may select a desired sort criteria with which the stores in the listing are resorted in 1316 and provided to the user. The user may, in 1312, select a store and in 1318, send the store selection to the DLGP-IMC. In one embodiment, the selecting and sending may be performed by generating an SMS message containing an action keyword and a store ID. The DLGP-IMC, in 1320, may receive the user's store 1 selection and may provide to the user the location of the store in 1322. Using the

2 provided location, the user in 1324 may visit the store and decide if he/she wants to

3 make any purchase. The user in 1326 may select an item to purchase. In one

4 embodiment, in order to begin purchase, the user may generate and send an SMS

5 message with purchase order information such as item no., store ID, price, model no.

6 and/or the like and an action keyword as in 1328 and 1330. In one embodiment, the

7 user may take a picture of a barcode of the item being purchased and send the picture of

8 the item barcode to the DLGP-IMC as a purchase order. In one embodiment, the picture

9 may be sent as an MMS message. The DLGP-IMC upon receiving the purchase order in 10 1332 may validate the purchase order. In one embodiment, the validation may comprise

11 verifying if the store ID, item no., model no. and/or price are correct. The DLGP-IMC in

12 1334 may then query the stores database to determine the corresponding eligible

13 discounts and points to be earned for the purchase. In one embodiment, the query may

14 be based on the purchase order and/or the user's historical purchase data. In one

15 embodiment, the DLGP-IMC may generate a unique coupon code in 1336 and send the

16 coupon code, discount and points to the user in 1338. The user may in 1340 review the

17 discount available and the points that may be earned before deciding to purchase the is item in 1342. The user in purchasing the item may provide the store keeper the coupon

19 code. Upon using the purchase code, the DLGP-IMC is automatically informed of the

20 use of the coupon code and the DLGP-IMC acknowledges the purchase by storing the

21 purchase order in the user database and updating the user's points balance in the user

22 database in 1346. In one embodiment, the DLGP-IMC may send an SMS message to the

23 user with the updated points balance. In another embodiment, the user upon review of 1 the discount and the points may decide not to make the purchase. In such a case, the

2 DLGP-IMC having not received any confirmation message, may cancel the purchase

3 order and make no changes to the user's point balance.

4 [0043] FIGURE 14 is a logic flow diagram illustrating aspects of a client-based

5 store locator implemented in an embodiment of the DLGP-IMC. In one embodiment, e the client-based store locator is an application that may be downloaded, for free or at a 7 cost, and installed in a user's mobile device. In another embodiment, the mobile device β may be 3G or higher generation enabled smart phones based on mobile operating

9 systems such as Symbian, iPhone, Andriod, etc. In one embodiment, the user may

10 launch the store locator application installed in their mobile device to initiate the store

11 locator service in 1402. Upon the launch of the service, the DLGP-IMC may locate the

12 user and generate a map showing the user location in 1404. The user may receive the

13 map and view his/her location on the map displayed on the mobile device in 1406. In

14 one embodiment, the user may enter a keyword to search the location of a store or

15 product. In another embodiment, the user may navigate through categories of

16 stores/items and select a particular store/item of interest to be searched in 1408. In

17 1410, the DLGP-IMC may query the stores database based on the entered keyword or is selected category of stores/items to generate a store listing. In one embodiment, the

19 DLGP-IMC may sort the generated store listing in an order defined by proximity to the

20 user's current location and provided the sorted store listing to the user for review in

21 1412. In one embodiment, the user may be able to change the criteria according to which

22 the stores are listed in 1414. In a further embodiment, the user may select a different list

23 criteria such as ranking based on reviews, popularity, size, length of operation, clientele, 1 etc in 1416. In 1418, upon receiving a different list criteria, the DLGP-IMC may re-list

2 the stores according to the selected criteria and provide the updated store listing to the

3 user for store selection. In 1420, the user may select a store based on the provided store

4 listing and send it to the DLGP-IMC in 1422 for further processing. In 1424, the DLGP- 5 IMC may receive the store selection and generate and send an updated map with the

6 store and user location, along with the store address to the user. In 1428, the user may

7 receive the updated map on his mobile device and visit the store in 1430. In one β embodiment, the user may select an item to purchase in 1432 and create and submit a

9 purchase order by entering purchase information such as product no., model no., store

10 id, price, etc in 1434 and 1436. In one embodiment, the user may take a picture of a

11 barcode of the selected item being purchased and send the picture of the item barcode to

12 the DLGP-IMC in an MMS message as a purchase order. In 1438, the DLGP-IMC may

13 receive and validate the purchase order. In one embodiment, the DLGP-IMC may query

14 the stores database to determine discounts and points associated with the purchase in

15 the store, purchase of the particular item, or the item of the particular price in 1440. In

16 1442, the DLGP-IMC may generate a unique coupon/merchant code and provide the

17 code, along with the discount and the points to be earned to the user in 1446. In one

18 embodiment, the user may receive the coupon/merchant code and use it to purchase the

19 item at a new price after applying the discount in 1448. In 1450, the user may confirm

20 the purchase to the DLGP-IMC and the DLGP-IMC may acknowledge the purchase after

21 determining that the code has been used by the store in 1452. In own embodiment, the

22 DLGP-IMC may store the purchase order and points earned by the user after the

23 completion of the purchase in a user database in 1454. In an alternate embodiment, 1 where the user may decide to not make a purchase, the DLGP-IMC may cancel the

2 purchase order and make no changes to the user's points balance.

3 [0044] FIGURE i5(a)-(h) are screen shot diagrams illustrating aspects of a client-

4 based store locator implemented in an embodiment of the DLGP-IMC.

5 [0045] FIGURE i6(a), (b) and (c) are screen shot diagrams illustrating aspects of

6 a text message based advertisement campaign in an embodiment of the DLGP-IMC. In

7 one embodiment, the DLGP-IMC may provide businesses a platform to launch digital β promotions and advertisements for services and/or products. In a further embodiment,

9 the DLGP-IMC may provide users a platform to receive promotions, services and/or

10 products from businesses based on their location, interests, habits, and/or other

11 categories of information in their subscriber profile. In one embodiment, Figures i6(a)

12 and (b) illustrate exemplary embodiments of registration pages for a business subscriber

13 subscribing to the mobile advertisement campaign service. In order to create an account u for the mobile advertisement campaign service, the business subscriber may be required

15 to enter information related to, but not limited to: his/her name, company name,

16 address, user name, password, email, telephone number, mobile number and/or the

17 like. After submitting this web form, the DLGP-IMC may generate a subscription

18 confirmation page, as shown in Figure i6(c) and an email with a link which may be

19 clicked by the business subscriber to activate the mobile advertisement campaign

20 service account.

21 [0046] FIGURE I7(a), (b), (c) and (d) are screen shot diagrams illustrating

22 aspects of a text message based advertisement campaign in another embodiment of the 1 DLGP-IMC. In one embodiment, as shown in Figure I7(a), after activating his/her

2 service account, the business subscriber may log in to the service account and create

3 campaign criteria. In one embodiment, creating the campaign criteria may comprise

4 entering information such as the actual content of the text message a mobile customer

5 may receive, a time frame (e.g., weekdays between 11:00-13:00), campaign start date

6 and finish date, a location/neighborhood over which the campaign may be active, a

7 radius of campaign in miles/kilometers, etc in the provided web form. In a further β embodiment, the campaign criteria may include information related to targeted

9 subscriber profile such as age, gender, interests, etc. In one embodiment, as shown in0 Figure I7(b), after the business subscriber submits the form, the DLGP-IMC may1 generate a confirmation page/window verifying the content of the advertising campaign2 message. In a further embodiment, the confirmation page may include a map3 illustrating the geographical reach of the campaign. In one embodiment, as illustrated in4 Figure I7(c), the DLGP-IMC may also generate a web page verifying the campaign5 criteria created by the business subscriber. In a further embodiment, the confirmation6 page may include links to pay for the advertisement campaign via different payment7 methods such as credit and debit cards, Paypal, etc. Once, the payment has been made,8 the advertising campaign may begin at the time frame defined by the business9 subscriber. In one embodiment, Figure i7(d) shows an exemplary embodiment of an0 advertising campaign targeted to and received by a customer meeting the campaign1 criteria and located within the perimeter defined by the campaign criteria. 2 [0047] Figure 18 is a logic flow diagram illustrating targeting an advertisement3 campaign to a customer in an embodiment of the DLGP-IMC. In one embodiment, the process of finding a target customer may begin when a DLGP-IMC implemented process is triggered by an event in the campaign criteria (e.g. Monday, 11:00). In one embodiment, job schedulers such as UNIX cron may be configured to schedule launch of campaigns at a predefined time or time intervals. In an alternate embodiment, the launch of a campaign may be on demand. The DLGP-IMC in 1810 may then query the telecom operator to search for and determine all subscribers located in a region defined by the campaign criteria in 1805. In one embodiment, the DLGP-IMC may determine that there are no subscribers in the defined campaign region in 1815. In such a case, as in 1820, the advertising campaign may not be launched. In an alternate embodiment, the DLGP-IMC may continually or as in 1825 periodically scan for subscribers in the defined campaign region until the time frame has lapsed. In one embodiment, in 1815, the DLGP-IMC may determine that one or more subscribers are located in the defined region. In 1830, the DLGP-IMC may retrieve their user profiles and in 1835 compare the user profile categories with the corresponding campaign criteria categories to determine one or more category matches in 1840. In one embodiment, the DLGP-IMC may determine that no category matches exist and therefore, the campaign may be suspended as in 1820 until the DLGP-IMC finds another subscriber with one or more matching categories. In an alternate embodiment, the DLGP-IMC may determine existence of one or more category matches. In a further embodiment, the DLGP-IMC may select one or more users with matching categories as target customers as in 1845 and send advertisements to their mobile devices as in 1850. In one embodiment, interested subscribers may elect to receive advertisement campaigns, during registration, or at another time, by sending a text message containing an action keyword 1 (e.g. adsubscribe). In another embodiment, subscribers may elect to block

2 advertisement campaigns from appearing on their mobile devices. In a further

3 embodiment, subscribers may block advertising campaigns during registration, or at

4 another time, by sending a text message containing an action keyword(e.g. block).

5 [0048] In one embodiment, various action keywords are available for the user to

6 communicate a request with a specific function to the DLGP-IMC. An example list of

7 action keywords and their descriptions are summarized in table 1. β Table 1. Action Keywords and Descriptions

Action Keyword Description

1 DLGP-IMC Controller

2 [0049] FIGURE 19 illustrates inventive aspects of a DLGP-IMC controller 1901 in

3 a block diagram. In this embodiment, the DLGP-IMC controller 1901 may serve to

4 aggregate, process, store, search, serve, identify, instruct, generate, match, and/or

5 facilitate interactions with a computer through various communication technologies,

6 and/or other related data.

7 [0050] Typically, users, which may be people and/or other systems, may engage β information technology systems (e.g., computers) to facilitate information processing. 9 In turn, computers employ processors to process information; such processors 19030 may be referred to as central processing units (CPU). One form of processor is referred1 to as a microprocessor. CPUs use communicative circuits to pass binary encoded signals2 acting as instructions to enable various operations. These instructions may be3 operational and/or data instructions containing and/or referencing other instructions4 and data in various processor accessible and operable areas of memory 1929 (e.g.,5 registers, cache memory, random access memory, etc.). Such communicative6 instructions may be stored and/or transmitted in batches (e.g., batches of instructions)7 as programs and/or data components to facilitate desired operations. These stored 1 instruction codes, e.g., programs, may engage the CPU circuit components and other

2 motherboard and/or system components to perform desired operations. One type of

3 program is a computer operating system, which, may be executed by CPU on a

4 computer; the operating system enables and facilitates users to access and operate

5 computer information technology and resources. Some resources that may be employed

6 in information technology systems include: input and output mechanisms through

7 which data may pass into and out of a computer; memory storage into which data may β be saved; and processors by which information may be processed. These information

9 technology systems may be used to collect data for later retrieval, analysis, and0 manipulation, which may be facilitated through a database program. These information1 technology systems provide interfaces that allow users to access and operate various2 system components. 3 [0051] In one embodiment, the DLGP-IMC controller 1901 may be connected to4 and/or communicate with entities such as, but not limited to: one or more users from5 user input devices 1911; peripheral devices 1912; an optional cryptographic processor6 device 1928; and/or a communications network 1913. 7 [0052] Networks are commonly thought to comprise the interconnection and8 interoperation of clients, servers, and intermediary nodes in a graph topology. It should9 be noted that the term "server" as used throughout this application refers generally to a0 computer, other device, program, or combination thereof that processes and responds to1 the requests of remote users across a communications network. Servers serve their2 information to requesting "clients." The term "client" as used herein refers generally to a3 computer, program, other device, user and/or combination thereof that is capable of 1 processing and making requests and obtaining and processing any responses from

2 servers across a communications network. A computer, other device, program, or

3 combination thereof that facilitates, processes information and requests, and/or

4 furthers the passage of information from a source user to a destination user is

5 commonly referred to as a "node." Networks are generally thought to facilitate the

6 transfer of information from source points to destinations. A node specifically tasked

7 with furthering the passage of information from a source to a destination is commonly β called a "router." There are many forms of networks such as Local Area Networks

9 (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc.

10 For example, the Internet is generally accepted as being an interconnection of a

11 multitude of networks whereby remote clients and servers may access and interoperate

12 with one another.

13 [0053] The DLGP-IMC controller 1901 may be based on computer systems that

14 may comprise, but are not limited to, components such as: a computer systemization 15 1902 connected to memory 1929.

16 Computer Systemization

17 [0054] A computer systemization 1902 may comprise a clock 1930, central is processing unit ("CPU(s)" and/or "processor(s)" (these terms are used interchangeable

19 throughout the disclosure unless noted to the contrary)) 1903, a memory 1929 (e.g., a

20 read only memory (ROM) 1906, a random access memory (RAM) 1905, etc.), and/or an

21 interface bus 1907, and most frequently, although not necessarily, are all interconnected

22 and/or communicating through a system bus 1904 on one or more (mother)board(s) 1 1902 having conductive and/or otherwise transportive circuit pathways through which

2 instructions (e.g., binary encoded signals) may travel to effect communications,

3 operations, storage, etc. Optionally, the computer systemization may be connected to an

4 internal power source 1986. Optionally, a cryptographic processor 1926 may be

5 connected to the system bus. The system clock typically has a crystal oscillator and

6 generates a base signal through the computer systemization's circuit pathways. The

7 clock is typically coupled to the system bus and various clock multipliers that will β increase or decrease the base operating frequency for other components interconnected

9 in the computer systemization. The clock and various components in a computer

10 systemization drive signals embodying information throughout the system. Such

11 transmission and reception of instructions embodying information throughout a

12 computer systemization may be commonly referred to as communications. These

13 communicative instructions may further be transmitted, received, and the cause of u return and/or reply communications beyond the instant computer systemization to:

15 communications networks, input devices, other computer systemizations, peripheral

16 devices, and/or the like. Of course, any of the above components may be connected

17 directly to one another, connected to the CPU, and/or organized in numerous variations

18 employed as exemplified by various computer systems.

19 [0055] The CPU comprises at least one high-speed data processor adequate to

20 execute program components for executing user and/or system-generated requests.

21 Often, the processors themselves will incorporate various specialized processing units,

22 such as, but not limited to: integrated system (bus) controllers, memory management

23 control units, floating point units, and even specialized processing sub-units like 1 graphics processing units, digital signal processing units, and/or the like. Additionally,

2 processors may include internal fast access addressable memory, and be capable of

3 mapping and addressing memory 529 beyond the processor itself; internal memory may

4 include, but is not limited to: fast registers, various levels of cache memory (e.g., level 1,

5 2, 3, etc.), RAM, etc. The processor may access this memory through the use of a

6 memory address space that is accessible via instruction address, which the processor

7 can construct and decode allowing it to access a circuit path to a specific memory β address space having a memory state. The CPU may be a microprocessor such as: 9 AMD's Athlon, Duron and/or Opteron; ARM's application, embedded and secure0 processors; IBM and/or Motorola's DragonBall and PowerPC; IBM's and Sony's Cell1 processor; Intel's Celeron, Core (2) Duo, Itanium, Pentium, Xeon, and/or XScale;2 and/or the like processor(s). The CPU interacts with memory through instruction3 passing through conductive and/or transportive conduits (e.g., (printed) electronic4 and/or optic circuits) to execute stored instructions (i.e., program code) according to5 conventional data processing techniques. Such instruction passing facilitates6 communication within the DLGP-IMC controller and beyond through various7 interfaces. Should processing requirements dictate a greater amount speed and/or8 capacity, distributed processors (e.g., Distributed DLGP-IMC), mainframe, multi-core,9 parallel, and/or super-computer architectures may similarly be employed.Alternatively,0 should deployment requirements dictate greater portability, smaller Personal Digital1 Assistants (PDAs) may be employed. 2 [0056] Depending on the particular implementation, features of the DLGP-IMC3 may be achieved by implementing a microcontroller such as CAST'S R8051XC2 microcontroller; Intel's MCS 51 (i.e., 8051 microcontroller); and/or the like. Also, to implement certain features of the DLGP-IMC, some feature implementations may rely on embedded components, such as: Application-Specific Integrated Circuit ("ASIC"), Digital Signal Processing ("DSP"), Field Programmable Gate Array ("FPGA"), and/or the like embedded technology. For example, any of the DLGP-IMC component collection (distributed or otherwise) and/or features may be implemented via the microprocessor and/or via embedded components; e.g., via ASIC, coprocessor, DSP, FPGA, and/or the like. Alternately, some implementations of the DLGP-IMC may be implemented with embedded components that are configured and used to achieve a variety of features or signal processing. [0057] Depending on the particular implementation, the embedded components may include software solutions, hardware solutions, and/or some combination of both hardware/software solutions. For example, DLGP-IMC features discussed herein may be achieved through implementing FPGAs, which are a semiconductor devices containing programmable logic components called "logic blocks", and programmable interconnects, such as the high performance FPGA Virtex series and/or the low cost Spartan series manufactured by Xilinx. Logic blocks and interconnects can be programmed by the customer or designer, after the FPGA is manufactured, to implement any of the DLGP-IMC features. A hierarchy of programmable interconnects allow logic blocks to be interconnected as needed by the DLGP-IMC system designer/administrator, somewhat like a one-chip programmable breadboard. An FPGA's logic blocks can be programmed to perform the function of basic logic gates such as AND, and XOR, or more complex combinational functions such as decoders or 1 simple mathematical functions. In most FPGAs, the logic blocks also include memory

2 elements, which may be simple flip-flops or more complete blocks of memory. In some

3 circumstances, the DLGP-IMC may be developed on regular FPGAs and then migrated i into a fixed version that more resembles ASIC implementations. Alternate or

5 coordinating implementations may migrate DLGP-IMC controller features to a final

6 ASIC instead of or in addition to FPGAs. Depending on the implementation all of the

7 aforementioned embedded components and microprocessors may be considered the β "CPU" and/or "processor" for the DLGP-IMC.

9 Power Source 0 [0058] The power source 1986 may be of any standard form for powering small1 electronic circuit board devices such as the following power cells: alkaline, lithium2 hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like.3 Other types of AC or DC power sources may be used as well. In the case of solar cells, in4 one embodiment, the case provides an aperture through which the solar cell may5 capture photonic energy. The power cell 1986 is connected to at least one of the6 interconnected subsequent components of the DLGP-IMC thereby providing an electric7 current to all subsequent components. In one example, the power source 1986 is8 connected to the system bus component 1904. In an alternative embodiment, an outside9 power source 1986 is provided through a connection across the I/O 1908 interface. For0 example, a USB and/or IEEE 1394 connection carries both data and power across the1 connection and is therefore a suitable source of power. 1 Interface Adapters

2 [0059] Interface bus(ses) 1907 may accept, connect, and/or communicate to a

3 number of interface adapters, conventionally although not necessarily in the form of

4 adapter cards, such as but not limited to: input output interfaces (I/O) 1908, storage

5 interfaces 1909, network interfaces 1910, and/or the like. Optionally, cryptographic

6 processor interfaces 1927 similarly may be connected to the interface bus. The interface

7 bus provides for the communications of interface adapters with one another as well as β with other components of the computer systemization. Interface adapters are adapted

9 for a compatible interface bus. Interface adapters conventionally connect to the0 interface bus via a slot architecture. Conventional slot architectures may be employed,1 such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended)2 Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus,3 Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal4 Computer Memory Card International Association (PCMCIA), and/or the like. 5 [0060] Storage interfaces 1909 may accept, communicate, and/or connect to a6 number of storage devices such as, but not limited to: storage devices 1914, removable7 disc devices, and/or the like. Storage interfaces may employ connection protocols such8 as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet9 Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE),0 Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small1 Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like. 2 [0061] Network interfaces 1910 may accept, communicate, and/or connect to a3 communications network 1913. Through a communications network 1913, the DLGP- 1 IMC controller is accessible through remote clients 1933b (e.g., computers with web

2 browsers) by users 1933a. Network interfaces may employ connection protocols such as,

3 but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base

4 T, and/or the like), Token Ring, wireless connection such as IEEE 8θ2.na-x, and/or the

5 like. Should processing requirements dictate a greater amount speed and/or capacity,

6 distributed network controllers (e.g., Distributed DLGP-IMC), architectures may

7 similarly be employed to pool, load balance, and/or otherwise increase the β communicative bandwidth required by the DLGP-IMC controller. A communications

9 network may be any one and/or the combination of the following: a direct

10 interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area

11 Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured

12 custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing

13 protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, u and/or the like); and/or the like. A network interface may be regarded as a specialized

15 form of an input output interface. Further, multiple network interfaces 1910 may be

16 used to engage with various communications network types 1913. For example, multiple

17 network interfaces may be employed to allow for the communication over broadcast, is multicast, and/or unicast networks.

19 [0062] Input Output interfaces (I/O) 1908 may accept, communicate, and/or

20 connect to user input devices 1911, peripheral devices 1912, cryptographic processor

21 devices 1928, and/or the like. I/O may employ connection protocols such as, but not

22 limited to: audio: analog, digital, monaural, RCA, stereo, and/or the like; data: Apple

23 Desktop Bus (ADB), IEEE I394a-b, serial, universal serial bus (USB); infrared; joystick; 1 keyboard; midi; optical; PC AT; PS/2; parallel; radio; video interface: Apple Desktop

2 Connector (ADC), BNC, coaxial, component, composite, digital, Digital Visual Interface

3 (DVI), high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video, VGA,

4 and/or the like; wireless: 8θ2.iia/b/g/n/x, Bluetooth, code division multiple access

5 (CDMA), global system for mobile communications (GSM), WiMax, etc.; and/or the

6 like. One typical output device may include a video display, which typically comprises a

7 Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) based monitor with an

8 interface (e.g., DVI circuitry and cable) that accepts signals from a video interface, may

9 be used. The video interface composites information generated by a computer

10 systemization and generates video signals based on the composited information in a

11 video memory frame. Another output device is a television set, which accepts signals

12 from a video interface. Typically, the video interface provides the composited video

13 information through a video connection interface that accepts a video display interface u (e.g., an RCA composite video connector accepting an RCA composite video cable; a DVI

15 connector accepting a DVI display cable, etc.).

16 [0063] User input devices 1911 may be card readers, dongles, finger print readers,

17 gloves, graphics tablets, joysticks, keyboards, mouse (mice), remote controls, retina is readers, trackballs, trackpads, and/or the like.

19 [0064] Peripheral devices 1912 may be connected and/or communicate to I/O

20 and/or other facilities of the like such as network interfaces, storage interfaces, and/or

21 the like. Peripheral devices may be audio devices, cameras, dongles (e.g., for copy

22 protection, ensuring secure transactions with a digital signature, and/or the like),

23 external processors (for added functionality), goggles, microphones, monitors, network 1 interfaces, printers, scanners, storage devices, video devices, video sources, visors,

2 and/or the like.

3 [oo65] It should be noted that although user input devices and peripheral devices

4 may be employed, the DLGP-IMC controller may be embodied as an embedded,

5 dedicated, and/or monitor-less (i.e., headless) device, wherein access would be provided

6 over a network interface connection.

7 [0066] Cryptographic units such as, but not limited to, microcontrollers, β processors 1926, interfaces 1927, and/or devices 1928 may be attached, and/or

9 communicate with the DLGP-IMC controller. A MC68HC16 microcontroller,

10 manufactured by Motorola Inc., may be used for and/or within cryptographic units. The

11 MC68HC16 microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the

12 16 MHz configuration and requires less than one second to perform a 512-bit RSA

13 private key operation. Cryptographic units support the authentication of

14 communications from interacting agents, as well as allowing for anonymous

15 transactions. Cryptographic units may also be configured as part of CPU. Equivalent

16 microcontrollers and/or processors may also be used. Other commercially available

17 specialized cryptographic processors include: the Broadcom's CryptoNetX and other is Security Processors; nCipher's nShield, SafeNet's Luna PCI (e.g., 7100) series;

19 Semaphore Communications' 40 MHz Roadrunner 184; Sun's Cryptographic

20 Accelerators (e.g., Accelerator 6000 PCIe Board, Accelerator 500 Daughtercard); Via

21 Nano Processor (e.g., L2100, L2200, U2400) line, which is capable of performing 500+2 MB/s of cryptographic instructions; VLSI Technology's 33 MHz 6868; and/or the like. 1 Memory

2 [0067] Generally, any mechanization and/or embodiment allowing a processor to

3 affect the storage and/or retrieval of information is regarded as memory 1929. However,

4 memory is a fungible technology and resource, thus, any number of memory

5 embodiments may be employed in lieu of or in concert with one another. It is to be

6 understood that the DLGP-IMC controller and/or a computer systemization may

7 employ various forms of memory 1929. For example, a computer systemization may be β configured wherein the functionality of on-chip CPU memory (e.g., registers), RAM,

9 ROM, and any other storage devices are provided by a paper punch tape or paper punch

10 card mechanism; of course such an embodiment would result in an extremely slow rate

11 of operation. In a typical configuration, memory 1929 will include ROM 1906, RAM

12 1905, and a storage device 1914. A storage device 1914 may be any conventional

13 computer system storage. Storage devices may include a drum; a (fixed and/or

14 removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., Blueray,

15 CD ROM/RAM/Recordable (R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.);

16 an array of devices (e.g., Redundant Array of Independent Disks (RAID)); solid state

17 memory devices (USB memory, solid state drives (SSD), etc.); other processor-readable

18 storage mediums; and/or other devices of the like. Thus, a computer systemization

19 generally requires and makes use of memory.

20 Component Collection

21 [0068] The memory 1929 may contain a collection of program and/or database

22 components and/or data such as, but not limited to: operating system component(s) 1 1915 (operating system); information server component(s) 1916 (information server);

2 user interface component(s) 1917 (user interface); Web browser component(s) 1918

3 (Web browser); database(s) 1919; mail server component(s) 1921; mail client

4 component(s) 1922; cryptographic server component(s) 1920 (cryptographic server);

5 the DLGP-IMC component(s) 1935; and/or the like (i.e., collectively a component

6 collection). These components may be stored and accessed from the storage devices

7 and/or from storage devices accessible through an interface bus. Although non-

8 conventional program components such as those in the component collection, typically,

9 are stored in a local storage device 1914, they may also be loaded and/or stored in0 memory such as: peripheral devices, RAM, remote storage facilities through a1 communications network, ROM, various forms of memory, and/or the like. 2 Operating System 3 [0069] The operating system component 1915 is an executable program4 component facilitating the operation of the DLGP-IMC controller. Typically, the5 operating system facilitates access of I/O, network interfaces, peripheral devices,6 storage devices, and/or the like. The operating system may be a highly fault tolerant,7 scalable, and secure system such as: Apple Macintosh OS X (Server); AT&T Plan 9; Be OS; Unix and Unix-like system distributions (such as AT&T's UNIX; Berkley Software Distribution (BSD) variations such as FreeBSD, NetBSD, OpenBSD, and/or the like; Linux distributions such as Red Hat, Ubuntu, and/or the like); and/or the like operating1 systems. However, more limited and/or less secure operating systems also may be employed such as Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows 1 2OOO/2OO3/3-i/95/98/CE/Millenium/NT/Vista/XP (Server), Palm OS, and/or the like.

2 An operating system may communicate to and/or with other components in a

3 component collection, including itself, and/or the like. Most frequently, the operating

4 system communicates with other program components, user interfaces, and/or the like.

5 For example, the operating system may contain, communicate, generate, obtain, and/or

6 provide program component, system, user, and/or data communications, requests,

7 and/or responses. The operating system, once executed by the CPU, may enable the β interaction with communications networks, data, I/O, peripheral devices, program

9 components, memory, user input devices, and/or the like. The operating system may0 provide communications protocols that allow the DLGP-IMC controller to communicate1 with other entities through a communications network 1913. Various communication2 protocols may be used by the DLGP-IMC controller as a subcarrier transport3 mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast,4 and/or the like. 5 Information Server 6 [0070] An information server component 1916 is a stored program component7 that is executed by a CPU. The information server may be a conventional Internet8 information server such as, but not limited to Apache Software Foundation's Apache,9 Microsoft's Internet Information Server, and/or the like. The information server may0 allow for the execution of program components through facilities such as Active Server1 Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, Common Gateway2 Interface (CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH, Java, 1 JavaScript, Practical Extraction Report Language (PERL), Hypertext Pre-Processor

2 (PHP), pipes, Python, wireless application protocol (WAP), WebObjects, and/or the like.

3 The information server may support secure communications protocols such as, but not A limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure

5 Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols

6 (e.g., America Online (AOL) Instant Messenger (AIM), Application Exchange (APEX),

7 ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence β and Instant Messaging Protocol (PRIM), Internet Engineering Task Force's (IETF's)

9 Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging0 Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol1 (XMPP) (i.e., Jabber or Open Mobile Alliance's (OMA's) Instant Messaging and2 Presence Service (IMPS)), Yahoo! Instant Messenger Service, and/or the like. The3 information server provides results in the form of Web pages to Web browsers, and4 allows for the manipulated generation of the Web pages through interaction with other5 program components. After a Domain Name System (DNS) resolution portion of an6 HTTP request is resolved to a particular information server, the information server7 resolves requests for information at specified locations on the DLGP-IMC controller8 based on the remainder of the HTTP request. For example, a request such as9 http://123.124.125.126/mylnformation.html might have the IP portion of the request0 "123.124.125.126" resolved by a DNS server to an information server at that IP address;1 that information server might in turn further parse the http request for the2 "/mylnformation.html" portion of the request and resolve it to a location in memory3 containing the information "mylnformation.html." Additionally, other information serving protocols may be employed across various ports, e.g., FTP communications across port 21, and/or the like. An information server may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the information server communicates with the DLGP-IMC database 1919, operating systems, other program components, user interfaces, Web browsers, and/or the like. [0071] Access to the DLGP-IMC database may be achieved through a number of database bridge mechanisms such as through scripting languages as enumerated below (e.g., CGI) and through inter-application communication channels as enumerated below (e.g., CORBA, WebObjects, etc.). Any data requests through a Web browser are parsed through the bridge mechanism into appropriate grammars as required by the DLGP- IMC. In one embodiment, the information server would provide a Web form accessible by a Web browser. Entries made into supplied fields in the Web form are tagged as having been entered into the particular fields, and parsed as such. The entered terms are then passed along with the field tags, which act to instruct the parser to generate queries directed to appropriate tables and/or fields. In one embodiment, the parser may generate queries in standard SQL by instantiating a search string with the proper join/select commands based on the tagged text entries, wherein the resulting command is provided over the bridge mechanism to the DLGP-IMC as a query. Upon generating query results from the query, the results are passed over the bridge mechanism, and may be parsed for formatting and generation of a new results Web page by the bridge mechanism. Such a new results Web page is then provided to the information server, which may supply it to the requesting Web browser. [OO72] Also, an information server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.

User Interface [0073] The function of computer interfaces in some respects is similar to automobile operation interfaces. Automobile operation interface elements such as steering wheels, gearshifts, and speedometers facilitate the access, operation, and display of automobile resources, functionality, and status. Computer interaction interface elements such as check boxes, cursors, menus, scrollers, and windows (collectively and commonly referred to as widgets) similarly facilitate the access, operation, and display of data and computer hardware and operating system resources, functionality, and status. Operation interfaces are commonly called user interfaces. Graphical user interfaces (GUIs) such as the Apple Macintosh Operating System's Aqua, IBM's OS/2, Microsoft's Windows 2OOO/2OO3/3.i/95/98/CE/Millenium/NT/XP/Vista/7 (i.e., Aero), Unix's X-Windows (e.g., which may include additional Unix graphic interface libraries and layers such as K Desktop Environment (KDE), mythTV and GNU Network Object Model Environment (GNOME)), web interface libraries (e.g., ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, etc. interface libraries such as, but not limited to, Dojo, jQuery(UI), MooTools, Prototype, script.aculo.us, SWFObject, Yahoo! User Interface, any of which may be used and) provide a baseline and means of accessing and displaying information graphically to users. 1 [OO74] A user interface component 1917 is a stored program component that is

2 executed by a CPU. The user interface may be a conventional graphic user interface as

3 provided by, with, and/or atop operating systems and/or operating environments such

4 as already discussed. The user interface may allow for the display, execution,

5 interaction, manipulation, and/or operation of program components and/or system e facilities through textual and/or graphical facilities. The user interface provides a facility 7 through which users may affect, interact, and/or operate a computer system. A user β interface may communicate to and/or with other components in a component

9 collection, including itself, and/or facilities of the like. Most frequently, the user0 interface communicates with operating systems, other program components, and/or the1 like. The user interface may contain, communicate, generate, obtain, and/or provide2 program component, system, user, and/or data communications, requests, and/or3 responses. 4 Web Browser 5 [0075] A Web browser component 1918 is a stored program component that is6 executed by a CPU. The Web browser may be a conventional hypertext viewing7 application such as Microsoft Internet Explorer or Netscape Navigator. Secure Web8 browsing may be supplied with I28bit (or greater) encryption by way of HTTPS, SSL,9 and/or the like. Web browsers allowing for the execution of program components0 through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web1 browser plug-in APIs (e.g., FireFox, Safari Plug-in, and/or the like APIs), and/or the2 like. Web browsers and like information access tools may be integrated into PDAs, 1 cellular telephones, and/or other mobile devices. A Web browser may communicate to

2 and/or with other components in a component collection, including itself, and/or

3 facilities of the like. Most frequently, the Web browser communicates with information

4 servers, operating systems, integrated program components (e.g., plug-ins), and/or the

5 like; e.g., it may contain, communicate, generate, obtain, and/or provide program

6 component, system, user, and/or data communications, requests, and/or responses. Of

7 course, in place of a Web browser and information server, a combined application may β be developed to perform similar functions of both. The combined application would

9 similarly affect the obtaining and the provision of information to users, user agents,0 and/or the like from the DLGP-IMC enabled nodes. The combined application may be1 nugatory on systems employing standard Web browsers. 2 Mail Server 3 [0076] A mail server component 1921 is a stored program component that is4 executed by a CPU 1903. The mail server may be a conventional Internet mail server5 such as, but not limited to sendmail, Microsoft Exchange, and/or the like. The mail6 server may allow for the execution of program components through facilities such as7 ASP, ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, CGI scripts, Java,8 JavaScript, PERL, PHP, pipes, Python, WebObjects, and/or the like. The mail server9 may support communications protocols such as, but not limited to: Internet message0 access protocol (IMAP), Messaging Application Programming Interface1 (MAPI)/Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol2 (SMTP), and/or the like. The mail server can route, forward, and process incoming and 1 outgoing mail messages that have been sent, relayed and/or otherwise traversing

2 through and/or to the DLGP-IMC.

3 [0077] Access to the DLGP-IMC mail may be achieved through a number of APIs

4 offered by the individual Web server components and/or the operating system.

5 [0078] Also, a mail server may contain, communicate, generate, obtain, and/or

6 provide program component, system, user, and/or data communications, requests,

7 information, and/or responses.

8 Mail Client

9 [OO79] A mail client component 1922 is a stored program component that is

10 executed by a CPU 1903. The mail client may be a conventional mail viewing application

11 such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook

12 Express, Mozilla, Thunderbird, and/or the like. Mail clients may support a number of

13 transfer protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and/or the like. A u mail client may communicate to and/or with other components in a component

15 collection, including itself, and/or facilities of the like. Most frequently, the mail client

16 communicates with mail servers, operating systems, other mail clients, and/or the like;

17 e.g., it may contain, communicate, generate, obtain, and/or provide program

18 component, system, user, and/or data communications, requests, information, and/or

19 responses. Generally, the mail client provides a facility to compose and transmit

20 electronic mail messages. 1 Cryptographic Server

2 [oo8o] A cryptographic server component 1920 is a stored program component

3 that is executed by a CPU 1903, cryptographic processor 1926, cryptographic processor

4 interface 1927, cryptographic processor device 1928, and/or the like. Cryptographic

5 processor interfaces will allow for expedition of encryption and/or decryption requests

6 by the cryptographic component; however, the cryptographic component, alternatively,

7 may run on a conventional CPU. The cryptographic component allows for the β encryption and/or decryption of provided data. The cryptographic component allows for

9 both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or0 decryption. The cryptographic component may employ cryptographic techniques such1 as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital2 signatures, dual signatures, enveloping, password access protection, public key3 management, and/or the like. The cryptographic component will facilitate numerous4 (encryption and/or decryption) security protocols such as, but not limited to: checksum,5 Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data6 Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash7 function), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internets encryption and authentication system that uses an algorithm developed in 1977 by Ron9 Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure0 Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like.1 Employing such encryption security protocols, the DLGP-IMC may encrypt all incoming2 and/or outgoing communications and may serve as node within a virtual private3 network (VPN) with a wider communications network. The cryptographic component 1 facilitates the process of "security authorization" whereby access to a resource is

2 inhibited by a security protocol wherein the cryptographic component effects authorized

3 access to the secured resource. In addition, the cryptographic component may provide

4 unique identifiers of content, e.g., employing and MD5 hash to obtain a unique

5 signature for an digital audio file. A cryptographic component may communicate to

6 and/or with other components in a component collection, including itself, and/or

7 facilities of the like. The cryptographic component supports encryption schemes β allowing for the secure transmission of information across a communications network 9 to enable the DLGP-IMC component to engage in secure transactions if so desired. The0 cryptographic component facilitates the secure accessing of resources on the DLGP-IMC1 and facilitates the access of secured resources on remote systems; i.e., it may act as a2 client and/or server of secured resources. Most frequently, the cryptographic3 component communicates with information servers, operating systems, other program4 components, and/or the like. The cryptographic component may contain, communicate,5 generate, obtain, and/or provide program component, system, user, and/or data6 communications, requests, and/or responses. 7 The DLGP-IMC Database s [0081] The DLGP-IMC database component 1919 may be embodied in a database9 and its stored data. The database is a stored program component, which is executed by0 the CPU; the stored program component portion configuring the CPU to process the1 stored data. The database may be a conventional, fault tolerant, relational, scalable,2 secure database such as Oracle or Sybase. Relational databases are an extension of a flat file. Relational databases consist of a series of related tables. The tables are interconnected via a key field. Use of the key field allows the combination of the tables by indexing against the key field; i.e., the key fields act as dimensional pivot points for combining information from various tables. Relationships generally identify links maintained between tables by matching primary keys. Primary keys represent fields that uniquely identify the rows of a table in a relational database. More precisely, they uniquely identify rows of a table on the "one" side of a one-to-many relationship. [0082] Alternatively, the DLGP-IMC database may be implemented using various standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in (structured) files. In another alternative, an object-oriented database may be used, such as Frontier, ObjectStore, Poet, Zope, and/or the like. Object databases can include a number of object collections that are grouped and/or linked together by common attributes; they may be related to other object collections by some common attributes. Object-oriented databases perform similarly to relational databases with the exception that objects are not just pieces of data but may have other types of functionality encapsulated within a given object. If the DLGP-IMC database is implemented as a data-structure, the use of the DLGP-IMC database 1919 may be integrated into another component such as the DLGP-IMC component 1935. Also, the database may be implemented as a mix of data structures, objects, and relational structures. Databases may be consolidated and/or distributed in countless variations through standard data processing techniques. Portions of databases, e.g., tables, may be exported and/or imported and thus decentralized and/or integrated. 1 [0083] In one embodiment, the database component 1919 includes several tables

2 I9i9a-f. A User table 1919a includes fields such as, but not limited to: a subscriber_ID,

3 subscriber_name, subscriber_info, hardware_ID, password, authentication_question,

4 Credit_card_Info, points_bal and/or the like. A Perferences table 1919b may include

5 fields such as, but not limited to: subscriber_ID, Age_Pref, Height_pref, status_Pref,

6 education_Pref, Physical_Attributes, compatabilty_Pref and/or the like. The user table

7 may support and/or track multiple entity accounts on a DLGP-IMC. An geographic table β 1919c includes fields such as, but not limited to: subscriber_ID, Geographic_ID,

9 Walking_Dist, Miles, Ping_time and/or the like. A Settings table I9i9d may include0 fields such as, but not limited to: subscriber_ID, anonymous_setting, Profile_setting,1 Display _settings, Send_info_settings and/or the like. A Stores table 1919c may include2 fields such as, but not limited to: store_ID, product_ID, Price, Subscriber_ID,3 location_ID and/or the like. A Campaign table I9i9f may include fields such as, but not1 limited to: businessSubscriber_ID, company_ID, username, address, password, email,5 campaign criteria (e.g., period of business, activity time frame, text message, targeted6 customer criteria, target geographical location, target perimeter), credit card7 authorization, and/or the like. s [0084] In one embodiment, the DLGP-IMC database may interact with other9 database systems. For example, employing a distributed database system, queries and0 data access by search DLGP-IMC component may treat the combination of the DLGP-1 IMC database, an integrated data security layer database as a single database entity.2 [0085] In one embodiment, user programs may contain various user interface3 primitives, which may serve to update the DLGP-IMC. Also, various accounts may 1 require custom database tables depending upon the environments and the types of

2 clients the DLGP-IMC may need to serve. It should be noted that any unique fields may

3 be designated as a key field throughout. In an alternative embodiment, these tables have

4 been decentralized into their own databases and their respective database controllers

5 (i.e., individual database controllers for each of the above tables). Employing standard e data processing techniques, one may further distribute the databases over several 7 computer systemizations and/or storage devices. Similarly, configurations of the β decentralized database controllers may be varied by consolidating and/or distributing

9 the various database components I9i9a-f. The DLGP-IMC may be configured to keep0 track of various settings, inputs, and parameters via database controllers. 1 [0086] The DLGP-IMC database may communicate to and/or with other2 components in a component collection, including itself, and/or facilities of the like.3 Most frequently, the DLGP-IMC database communicates with the DLGP-IMC4 component, other program components, and/or the like. The database may contain,5 retain, and provide information regarding other nodes and data. 6 The DLGP-IMCs 7 [0087] The DLGP-IMC component 1935 is a stored program component that is8 executed by a CPU. In one embodiment, the DLGP-IMC component incorporates any9 and/or all combinations of the aspects of the DLGP-IMC that was discussed in the0 previous figures. As such, the DLGP-IMC affects accessing, obtaining and the provision1 of information, services, transactions, and/or the like across various communications2 networks. 1 [oo88] The DLGP-IMC component is configurable to receive, authenticate, access,

2 calculate, query, compile, engage, exchange, generate, identify, instruct, establish, route,

3 match, process, search, serve, store, reroute, ping, poll, and/or the like and use of the

4 DLGP-IMC components and/or affiliated entities, establishing a unique access

5 identification information, receiving an authentication request from a mobile device of a

6 registered user, handling multiple requests from mobile devices, authenticating the user

7 request based on the request received, updating a geographic location of the user, β receiving a request for other subscribers in the geographic location of the user,

9 compiling a list of subscribers based on the user's preferences and geographic location,0 sending the complied list to the user, receiving selected subscribers from the list of1 subscribers, routing an initiation request to the selected subscribers and/or the like.2 [0089] The DLGP-IMC component enabling access of information between nodes3 may be developed by employing standard development tools and languages such as, but4 not limited to: Apache components, Assembly, ActiveX, binary executables, (ANSI)5 (Objective-) C (++), C# and/or .NET, database adapters, CGI scripts, Java, JavaScript,6 mapping tools, procedural and object oriented development tools, PERL, PHP, Python,7 shell scripts, SQL commands, web application server extensions, web developments environments and libraries (e.g., Microsoft's ActiveX; Adobe AIR, FLEX & FLASH;9 AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype;0 script.aculo.us; Simple Object Access Protocol (SOAP); SWFObject; Yahoo! User1 Interface; and/or the like), WebObjects, and/or the like. In one embodiment, the DLGP-2 IMC server employs a cryptographic server to encrypt and decrypt communications. The3 DLGP-IMC component may communicate to and/or with other components in a 1 component collection, including itself, and/or facilities of the like. Most frequently, the

2 DLGP-IMC component communicates with the DLGP-IMC database, operating systems,

3 other program components, and/or the like. The DLGP-IMC may contain, A communicate, generate, obtain, and/or provide program component, system, user, 5 and/or data communications, requests, and/or responses.

e Distributed DLGP-IMCs

7 [0090] The structure and/or operation of any of the DLGP-IMC node controller

8 components may be combined, consolidated, and/or distributed in any number of ways

9 to facilitate development and/or deployment. Similarly, the component collection may0 be combined in any number of ways to facilitate deployment and/or development. To1 accomplish this, one may integrate the components into a common code base or in a2 facility that can dynamically load the components on demand in an integrated fashion.3 [0091] The component collection may be consolidated and/or distributed in4 countless variations through standard data processing and/or development techniques.5 Multiple instances of any one of the program components in the program component6 collection may be instantiated on a single node, and/or across numerous nodes to7 improve performance through load-balancing and/or data-processing techniques.8 Furthermore, single instances may also be distributed across multiple controllers9 and/or storage devices; e.g., databases. All program component instances and0 controllers working in concert may do so through standard data processing1 communication techniques. [0092] The configuration of the DLGP-IMC controller will depend on the context of system deployment. Factors such as, but not limited to, the budget, capacity, location, and/or use of the underlying hardware resources may affect deployment requirements and configuration. Regardless of if the configuration results in more consolidated and/or integrated program components, results in a more distributed series of program components, and/or results in some combination between a consolidated and distributed configuration, data may be communicated, obtained, and/or provided. Instances of components consolidated into a common code base from the program component collection may communicate, obtain, and/or provide data. This may be accomplished through intra-application data processing communication techniques such as, but not limited to: data referencing (e.g., pointers), internal messaging, object instance variable communication, shared memory space, variable passing, and/or the like. [0093] If component collection components are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), Common Object Request Broker Architecture (CORBA), local and remote application program interfaces Jini, Remote Method Invocation (RMI), SOAP, process pipes, shared files, and/or the like. Messages sent between discrete component components for inter- application communication or within memory spaces of a singular component for intra- application communication may be facilitated through the creation and parsing of a grammar. A grammar may be developed by using standard development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing functionality, which in turn may form the basis of communication messages within and between components. For example, a grammar may be arranged to recognize the tokens of an HTTP post command, e.g.: w3c -post ht tp : / / . . . Val uel

[0094] where Valuei is discerned as being a parameter because "http://" is part of the grammar syntax, and what follows is considered part of the post value. Similarly, with such a grammar, a variable "Valuel" may be inserted into an "http://" post command and then sent. The grammar syntax itself may be presented as structured data that is interpreted and/or otherwise used to generate the parsing mechanism (e.g., a syntax description text file as processed by lex, yacc, etc.). Also, once the parsing mechanism is generated and/or instantiated, it itself may process and/or parse structured data such as, but not limited to: character (e.g., tab) delineated text, HTML, structured text streams, XML, and/or the like structured data. In another embodiment, inter-application data processing protocols themselves may have integrated and/or readily available parsers (e.g., the SOAP parser) that may be employed to parse (e.g., communications) data. Further, the parsing grammar may be used beyond message parsing, but may also be used to parse: databases, data collections, data stores, structured data, and/or the like. Again, the desired configuration will depend upon the context, environment, and requirements of system deployment. The following resources may be used to provide example embodiments regarding SOAP parser implementation: http: //www. xav.com/perl/site/lib/SOAP/ Parser .html http: //publib. boulder . lbm. com/infocenter/t ivihelp/v2rl/ index.

ibm . IBt-IDI .doc/referenceguide295.htm and other parser implementations:

http: //publib. boulder . ibm. com/ mfocenter/t ivihelp/v2rl /inde.-: . jsp?topic=/com. ibm . IBMDI .doc/ referenceguide259.htm all of which are hereby expressly incorporated by reference.

[oo95] In order to address various issues and improve over previous works, the application is directed to APPARATUSES, METHODS AND SYSTEMS FOR DYNAMICALLY LOCATING A GLOBAL POSITION TO INTERFACE OVER MOBILE COMMUNICATIONS. The entirety of this application (including the Cover Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, Appendices, and otherwise) shows by way of illustration various embodiments in which the claimed inventions may be practiced. The advantages and features of the application are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding and teach the claimed principles. It should be understood that they are not representative of all claimed inventions. As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the invention or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It will be appreciated that many of those undescribed embodiments incorporate the same principles of the invention and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, organizational, structural and/or topological modifications may be made without departing from the scope and/or spirit of the disclosure. As such, all examples and/or embodiments are deemed to be non-limiting throughout this disclosure. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of reducing space and repetition. For instance, it is to be understood that the logical and/or topological structure of any combination of any program components (a component collection), other components and/or any present feature sets as described in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. Furthermore, it is to be understood that such features are not limited to serial execution, but rather, any number of threads, processes, services, servers, and/or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the like are contemplated by the disclosure. As such, some of these features may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some features are applicable to one aspect of the invention, and inapplicable to others. In addition, the disclosure includes other inventions not presently claimed. Applicant reserves all rights in those presently unclaimed inventions including the right to claim such inventions, file additional applications, continuations, continuations in part, divisions, and/or the like thereof. As such, it should be understood that advantages, embodiments, examples, functional, features, logical, organizational, structural, topological, and/or other aspects of the disclosure are not to 1 be considered limitations on the disclosure as defined by the claims or limitations on

2 equivalents to the claims. It is to be understood that, depending on the particular needs

3 and/or characteristics of a DLGP-IMC individual and/or enterprise user, database

4 configuration and/or relational model, data type, data transmission and/or network

5 framework, syntax structure, and/or the like, various embodiments of the DLGP-IMC,

6 may be implemented that enable a great deal of flexibility and customization. For

7 example, aspects of the DLGP-IMC may be adapted for social networking, business β and/or various other activities. While various embodiments and discussions of the

9 DLGP-IMC have been directed to social networking, however, it is to be understood that0 the embodiments described herein may be readily configured and/or customized for a1 wide variety of other applications and/or implementations.

Claims

, CLAIMS

2 What is claimed is:

3 l. A proximity-based introduction communication processor-implemented

4 method comprising:

5 receiving a request from a requestor with a unique request identifier;

6 providing a query to resolve the unique request identifier for a request location

7 origin;

8 receiving the request location origin;

9 identifying proximate subscribers based on the received request location origin;

10 providing a selection of identified proximate subscribers;

11 receiving a selection of a proximate subscriber;

12 providing the selected proximate subscriber with a communication request;

13 receiving a response to the communication request from the selected proximate u subscriber; and is providing the requestor with a response acknowledgement based on the received

16 response to the communication request.

17 2. The method of claim i, wherein the acknowledgement includes positive is conformation and meeting details, if the response to the communication is positive.

19 3. The method of claim 1, wherein the acknowledgement includes a selection

20 of alternative identified proximate subscribers, if the response to the communication is

21 negative. 4- The method of claim i, wherein the proximate subscriber is an individual user. 5. The method of claim 1, wherein the proximate subscriber is a business. 6. The method of claim 1, wherein the receiving and providing are via short messaging service. 7. The method of claim 1, wherein the receiving and providing are via multimedia messaging service. 8. The method of claim 1, wherein the communication request is made anonymously. 9. The method of claim 1, wherein the response to the communication request is made anonymously. 10. The method of claim 1, wherein the identifying proximate subscribers based on the received request location origin further comprises: providing a query based on the request location origin to determine proximate subscribers located within a predefined distance from the request location origin. 11. The method of claim 2, further comprising storing information related to the selected proximate subscriber and the meeting details in a database. 12. An apparatus, comprising: a memory; a processor disposed in communication with said memory, and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to: receive a request from a requestor with a unique request identifier; provide a query to resolve the unique request identifier for a request location origin; receive the request location origin; identify proximate subscribers based on the received request location origin; provide a selection of identified proximate subscribers; receive a selection of a proximate subscriber; provide the selected proximate subscriber with a communication request; receive a response to the communication request from the selected proximate subscriber; and provide the requestor with a response acknowledgement based on the received response to the communication request. 13. A processor-readable medium storing processor-issuable instructions to: receive a request from a requestor with a unique request identifier; provide a query to resolve the unique request identifier for a request location origin; receive the request location origin; identify proximate subscribers based on the received request location origin; provide a selection of identified proximate subscribers; receive a selection of a proximate subscriber; provide the selected proximate subscriber with a communication request; receive a response to the communication request from the selected proximate subscriber; and provide the requestor with a response acknowledgement based on the received response to the communication request. 14. A proximity introduction communication system, comprising means to: receive a request from a requestor with a unique request identifier; provide a query to resolve the unique request identifier for a request location origin; receive the request location origin; identify proximate subscribers based on the received request location origin; provide a selection of identified proximate subscribers; receive a selection of a proximate subscriber; provide the selected proximate subscriber with a communication request; receive a response to the communication request from the selected proximate subscriber; and provide the requestor with a response acknowledgement based on the received response to the communication request. 15. An introduction communication processor-implemented method, comprising: receiving a request from a requestor with a unique request identifier; providing a query to resolve the unique request identifier for a request location origin; receiving the request location origin; identifying proximate subscribers based on the received request location origin; retrieving profile data associated with the requestor and the identified proximate subscribers from one or more databases; comparing the retrieved profile data of the requestor and the identified proximate subscribers to determine proximate matching subscribers; and providing a selection of the proximate matching subscribers to the requestor for selection; receiving a selection of a proximate matching subscriber; providing the selected proximate subscriber with a communication request; receiving a response to the communication request from the selected proximate subscriber; and providing the requestor with a response acknowledgement based on the received response to the communication request. i6. The method of claim 15, wherein the acknowledgement includes positive conformation and meeting details, if the response to the communication is positive. 17. The method of claim 15, wherein the acknowledgement includes a selection of alternative identified proximate matching subscribers, if the response to the communication is negative. 18. An apparatus, comprising: a memory; a processor disposed in communication with said memory, and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to: receive a request from a requestor with a unique request identifier; 1 provide a query to resolve the unique request identifier for a request location

2 origin;

3 receive the request location origin;

4 identify proximate subscribers based on the received request location origin;

5 retrieve profile data associated with the requestor and the identified proximate

6 subscribers from one or more databases;

7 compare the retrieved profile data of the requestor and the identified proximate β subscribers to determine proximate matching subscribers; and

9 provide a selection of the proximate matching subscribers to the requestor for0 selection; 1 receive a selection of a proximate matching subscriber; 2 provide the selected proximate subscriber with a communication request; 3 receive a response to the communication request from the selected proximate4 subscriber; and s provide the requestor with a response acknowledgement based on the received6 response to the communication request. 7 19. A processor-readable medium storing processor-issuable instructions to:8 receive a request from a requestor with a unique request identifier; 9 provide a query to resolve the unique request identifier for a request location0 origin; 1 receive the request location origin; 2 identify proximate subscribers based on the received request location origin; retrieve profile data associated with the requestor and the identified proximate subscribers from one or more databases; compare the retrieved profile data of the requestor and the identified proximate subscribers to determine proximate matching subscribers; and provide a selection of the proximate matching subscribers to the requestor for selection; receive a selection of a proximate matching subscriber; provide the selected proximate subscriber with a communication request; receive a response to the communication request from the selected proximate subscriber; and provide the requestor with a response acknowledgement based on the received response to the communication request. 2O. A proximity introduction communication system, comprising means to: receive a request from a requestor with a unique request identifier; provide a query to resolve the unique request identifier for a request location origin; receive the request location origin; identify proximate subscribers based on the received request location origin; retrieve profile data associated with the requestor and the identified proximate subscribers from one or more databases; compare the retrieved profile data of the requestor and the identified proximate subscribers to determine proximate matching subscribers; and 1 provide a selection of the proximate matching subscribers to the requestor for

2 selection;

3 receive a selection of a proximate matching subscriber;

4 provide the selected proximate subscriber with a communication request;

5 receive a response to the communication request from the selected proximate

6 subscriber; and

7 provide the requestor with a response acknowledgement based on the received β response to the communication request.

9 21. A proximity user introduction communication processor-implemented0 method comprising: 1 obtaining a request from a requesting user with a unique identifier; 2 processing the unique identifier to identify the requesting user; 3 querying a database based on the processed unique identifier to determine4 requesting user location; 5 querying a database with the determined requesting user location to identify6 target subscribers proximate to the requesting user location; 7 compiling a list of the proximate target subscribers; s sending a list of the proximate target subscribers to the requesting user; 9 obtaining a selection of desired proximate target subscribers from the requesting0 user; 1 sending an invitation to the selected desired target subscribers; 2 obtaining answers to sent invitations; and forwarding contact information of positively answering target subscribers to the requesting user. 22. An apparatus, comprising: a memory; a processor disposed in communication with said memory, and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to: obtain a request from a requesting user with a unique identifier; process the unique identifier to identify the requesting user; query a database based on the processed unique identifier to determine requesting user location; query a database with the determined requesting user location to identify target subscribers proximate to the requesting user location; compile a list of the proximate target subscribers; send a list of the proximate target subscribers to the requesting user; obtain a selection of desired proximate target subscribers from the requesting user; send an invitation to the selected desired target subscribers; obtain answers to sent invitations; and forward contact information of positively answering target subscribers to the requesting user. 23. A processor-readable medium storing processor-issuable instructions to: obtain a request from a requesting user with a unique identifier; process the unique identifier to identify the requesting user; query a database based on the processed unique identifier to determine requesting user location; query a database with the determined requesting user location to identify target subscribers proximate to the requesting user location; compile a list of the proximate target subscribers; send a list of the proximate target subscribers to the requesting user; obtain a selection of desired proximate target subscribers from the requesting user; send an invitation to the selected desired target subscribers; obtain answers to sent invitations; and forward contact information of positively answering target subscribers to the requesting user. 24. A proximity introduction communication system, comprising means to: obtain a request from a requesting user with a unique identifier; process the unique identifier to identify the requesting user; query a database based on the processed unique identifier to determine requesting user location; query a database with the determined requesting user location to identify target subscribers proximate to the requesting user location; compile a list of the proximate target subscribers; send a list of the proximate target subscribers to the requesting user; obtain a selection of desired proximate target subscribers from the requesting user; send an invitation to the selected desired target subscribers; obtain answers to sent invitations; and forward contact information of positively answering target subscribers to the requesting user. 25. A processor-implemented method, comprising: establishing a unique access identification information; receiving an authentication request from a mobile device of a registered user; authenticating the user request based on the request received; updating a geographic location of the user; receiving a request for other subscribers in the geographic location of the user; compiling a list of subscribers based on the user's preferences and geographic location; sending the complied list to the user; receiving selected subscribers from the list of subscribers; and routing an initiation request to the selected subscribers; wherein, the authentication request from the mobile device includes a unique identifier and current geographic coordinates of the location of the mobile device. 26. An apparatus, comprising: a memory; a processor disposed in communication with said memory, and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to: establish a unique access identification information; receive an authentication request from a mobile device of a registered user; authenticate the user request based on the request received; update a geographic location of the user; receive a request for other subscribers in the geographic location of the user; compile a list of subscribers based on the user's preferences and geographic location; send the complied list to the user; receive selected subscribers from the list of subscribers; and route an initiation request to the selected subscribers; wherein, the authentication request from the mobile device includes a unique identifier and current geographic coordinates of the location of the mobile device. 27. A processor-readable medium storing processor-issuable instructions to: establish a unique access identification information; receive an authentication request from a mobile device of a registered user; authenticate the user request based on the request received; update a geographic location of the user; receive a request for other subscribers in the geographic location of the user; compile a list of subscribers based on the user's preferences and geographic location; send the complied list to the user; receive selected subscribers from the list of subscribers; and route an initiation request to the selected subscribers; wherein, the authentication request from the mobile device includes a unique identifier and current geographic coordinates of the location of the mobile device. 28. A processor-implemented method for locating a mobile device, comprising: receiving a request to locate a mobile device via a text message, said text message including an associated request identifier; generating a unique code in response to the received request identifier; receiving via a web browser an identifier associated with the mobile device and the generated unique code; querying an operator database based on the received mobile device identifier to determine last known location of the mobile device; and providing the last known location of the mobile device to a user. 29. An apparatus, comprising: a memory; a processor disposed in communication with said memory, and configured to issue a plurality of processing instructions stored in the memory, wherein the processor issues instructions to: receive a request to locate a mobile device via a text message, said text message including an associated request identifier; generate a unique code in response to the received request identifier; 1 receive via a web browser an identifier associated with the mobile device and the

2 generated unique code;

3 query an operator database based on the received mobile device identifier to

4 determine last known location of the mobile device; and

5 provide the last known location of the mobile device to a user.

6 30. A processor-readable medium storing processor-issuable instructions to:

7 receive a request to locate a mobile device via a text message, said text message β including an associated request identifier;

9 generate a unique code in response to the received request identifier; 0 receive via a web browser an identifier associated with the mobile device and the1 generated unique code; 2 query an operator database based on the received mobile device identifier to3 determine last known location of the mobile device; and 4 provide the last known location of the mobile device to a user. 5 31. A processor-implemented method of targeting mobile promotions to6 subscribers, comprising: 7 retrieving data associated with criteria for mobile promotion of products and8 services, including a defined geographical region from a database; 9 querying an operator database to compile a list of subscribers located within the0 defined geographical region; 1 retrieving profile data associated with the list of subscribers from a database;2 comparing the mobile promotions data with the profile data to determine3 matching target subscribers; and 1 sending multi-media messages to the matching target subscribers for the

2 promotion of products and services.

3 32. The method of claim 31, wherein the multi-media messages are sent

4 during a prescribed time.

5 33. An apparatus, comprising:

6 a memory;

7 a processor disposed in communication with said memory, and configured to β issue a plurality of processing instructions stored in the memory, wherein the processor

9 issues instructions to: 0 retrieve data associated with criteria for mobile promotion of products and1 services, including a defined geographical region from a database; 2 query an operator database to compile a list of subscribers located within the3 defined geographical region; 4 retrieve profile data associated with the list of subscribers from a database; 5 compare the mobile promotions data with the profile data to determine matching6 target subscribers; and 7 send multi-media messages to the matching target subscribers for the promotion8 of products and services. 9 34. A processor-readable medium storing processor-issuable instructions to:0 retrieve data associated with criteria for mobile promotion of products and1 services, including a defined geographical region from a database; 2 query an operator database to compile a list of subscribers located within the3 defined geographical region; retrieve profile data associated with the list of subscribers from a database; compare the mobile promotions data with the profile data to determine matching target subscribers; and send multi-media messages to the matching target subscribers for the promotion of products and services. 35. A proximity-based introduction communication processor-implemented method, comprising: generating a request for identifying a proximate subscriber, wherein said request is associated with a unique request identifier; transmitting the generated request to an operator over a communications network, wherein said operator determines location origin of the request and identifies subscribers proximate to the determined location origin of the request; receiving a list of the identified proximate subscribers; selecting a desired proximate subscriber from the received list of the identified proximate subscribers as a recipient of a communication request; receiving a response to the communication request from the selected proximate subscriber; and initiating communication with the selected proximate subscriber if the response to the communication request is positive. 36. An apparatus, comprising: a memory; 1 a processor disposed in communication with said memory, and configured to

2 issue a plurality of processing instructions stored in the memory, wherein the processor

3 issues instructions to:

4 generate a request for identifying a proximate subscriber, wherein said request is

5 associated with a unique request identifier;

6 transmit the generated request to an operator over a communications network,

7 wherein said operator determines location origin of the request and identifies β subscribers proximate to the determined location origin of the request;

9 receive a list of the identified proximate subscribers; 0 select a desired proximate subscriber from the received list of the identified1 proximate subscribers as a recipient of a communication request; 2 receive a response to the communication request from the selected proximate3 subscriber; and 4 initiate communication with the selected proximate subscriber if the response to5 the communication request is positive. 6 37. A processor-readable medium storing processor-issuable instructions to:7 generate a request for identifying a proximate subscriber, wherein said request is8 associated with a unique request identifier; 9 transmit the generated request to an operator over a communications network,0 wherein said operator determines location origin of the request and identifies1 subscribers proximate to the determined location origin of the request; 2 receive a list of the identified proximate subscribers; select a desired proximate subscriber from the received list of the identified proximate subscribers as a recipient of a communication request; receive a response to the communication request from the selected proximate subscriber; and initiate communication with the selected proximate subscriber if the response to the communication request is positive.