(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2004/0081120 A1
`Chaskar
`(43) Pub. Date:
`Apr. 29, 2004
`
`US 20040081120A1
`
`(54) METHOD AND APPARATUS PROVIDING
`USER PROGRAMMABLE, PERSONALIZED
`LOCATION-AWARE SERVICES
`(75) Inventor: Hemant Chaskar, Woburn, MA (US)
`
`Correspondence Address:
`HARRINGTON & SMITH, LLP
`4 RESEARCH DRIVE
`SHELTON, CT 06484-6212 (US)
`
`(73) Assignee: Nokia Corporation, Espoo (FI)
`(21) Appl. No.:
`10/283,808
`
`(22) Filed:
`
`Oct. 29, 2002
`
`Publication Classification
`
`(51) Int. Cl." ....................................................... H04Q 7/00
`(52) U.S. Cl. ............................................ 370/328; 370/412
`(57)
`ABSTRACT
`A method and System is disclosed to provide a personalized,
`location related Service to a user of a mobile terminal. The
`method includes: (A) generating a Service specification
`object that comprises a user-specified location and a mes
`Sage to be generated when the user arrives at the location
`with the MT; and (B) storing the service specification object
`for later use. The method further entails: (C) tracking the
`location of the mobile terminal; and when the location of the
`mobile terminal matches the location in the Stored Service
`creation object, (D) generating the message for activating a
`user-specified action.
`
`COMPUTER,23
`
`
`
`
`
`SERVICE
`SPECIFICATION
`OBJECT,22
`26
`
`OPERAOR
`NETWORK,3-
`25
`
`
`
`22,SERVICE
`SPECIFICATION
`
`- - - -
`
`OBJECT
`
`2,PARLAY API
`
`
`
`1THIRD PARTY
`APPLICATION SERVER
`
`6,SERVICE CAPABILITY
`SERVER (SCS)
`
`-
`LOCATION
`TRACKER
`
`Google, Exhibit 1012
`IPR2022-00742
`Page 1 of 12
`
`

`

`Patent Application Publication Apr. 29, 2004 Sheet 1 of 4
`
`US 2004/0081120 A1
`
`
`
`|-y ?yngyaºz_zz ------------------------------------
`èHWV" . _____________________
`
`
`
`SENES , BOI/\\|BS(s)NOLIVOITddy" |MMM
`
`Google, Exhibit 1012
`IPR2022-00742
`Page 2 of 12
`
`

`

`Patent Application Publication Apr. 29, 2004 Sheet 2 of 4
`
`
`
`SHENNES NOIIVOITdd7"|_^
`
`
`
`(SOS) SMJENJES
`
`
`
`
`
`ALITIEWdWO EOIN HES'9»,
`
`
`
`
`
`Ç‘X’HOMIEN
`
`Google, Exhibit 1012
`IPR2022-00742
`Page 3 of 12
`
`

`

`Patent Application Publication Apr. 29, 2004 Sheet 3 of 4
`
`US 2004/0081120 A1
`
`
`
`n
`
`(/)
`n
`c
`
`-
`
`Google, Exhibit 1012
`IPR2022-00742
`Page 4 of 12
`
`

`

`Patent Application Publication Apr. 29, 2004 Sheet 4 of 4
`
`US 2004/0081120 A1
`
`
`
`
`
`Z IdW AWTHWd=O
`
`EIWRJENES)
`
`Google, Exhibit 1012
`IPR2022-00742
`Page 5 of 12
`
`

`

`US 2004/0081120 A1
`
`Apr. 29, 2004
`
`METHOD AND APPARATUS PROVIDING USER
`PROGRAMMABLE, PERSONALIZED
`LOCATION-AWARE SERVICES
`
`TECHNICAL FIELD
`0001. The teachings of this invention relate generally to
`data communications networks and procedures and, more
`Specifically, relate to techniques for providing Services for a
`mobile node (MN) or mobile terminal (MT) based on the
`location of the MN or MT, as well as techniques for a user
`to specify the desired location-related Service(s).
`
`BACKGROUND
`0002 Currently, cellular and other MT users can Sub
`Scribe to various location-aware Services Such as news, maps
`and local information provided by the wireless network. The
`wireless network tracks the movement of the MT to deter
`mine its location, or obtains the location from the MT if the
`MT has a Global Positioning System (GPS) receiver, and
`provides the user-specified content to the user based on the
`user's location.
`0003. There is currently a proposed mechanism for
`enabling Service creation and management in regards to
`wireless networks. This mechanism in known as the Parlay
`Application Programming Interface (API), and is reviewed
`here as it provides a non-limiting example of a System that
`can be employed during the implementation of the teachings
`of this invention. The Parlay API has been developed by the
`Parlay group (WWW.parlay.org), an open, multi-vendor
`forum. The Parlay API has been accepted by the third
`generation partnership project (3GPP) for the Open Services
`Access (OSA) architecture of next generation cellular Sys
`tems. The Parlay API is intended to provide an open,
`Standard, technology-independent interface Specification
`between applications and the wireleSS network functionality.
`0004 FIG. 1 shows a conceptual diagram of an applica
`tion(s) server 1, possibly embodied as a WWW server, a
`Parlay API layer 2, and one or more underlying, possibly
`heterogenous wireleSS networkS 3. For example, one of the
`networks 3 may be a circuit Switched network (e.g., a Public
`Switched Telephone Network (PSTN) network or a Global
`System for Mobile Communication (GSM) network), while
`others of the networks 3 may be packet switched networks
`(e.g., one or more of a General Packet Radio System (GPRS)
`network, a Universal Mobile Telephone System (UMTS)
`network, a cdma2000 network or a WLAN communication
`network). The Parlay API layer 2 is intended to enable
`Service portability acroSS heterogenous networks. The Par
`lay API 2 provides a logical Separation of Service logic and
`network functionality, enabling customized third party Ser
`vices to be offered. A function of the Parlay API 2 is to hide
`the complexity of the target network(s) from the Service
`logic and, by extension, the developers of the Service logic.
`That is, a desired Service can be developed to run on the
`application Server 1 without regard for the Specifics of the
`network 3. An important aspect of the Parlay API layer 2 is
`that it enables the Service logic of the application 1 to use
`information and control capabilities of the networks 3,
`including network 3 call control, billing and MT location
`functions.
`0005 FIG. 2 is a more detailed view of the Parlay API 2
`in the context of the OSA architecture. The application
`
`ServerS 1 are shown to include, by example, enterprise
`applications 1A and client applications 1B. Communication
`with the network 3 occurs through the Parlay APIs 2 over an
`administrative boundary 4. The network 3 is shown as
`including a network framework 5 and Service capability
`servers (SCS) 6. The SCS 6 includes, by example, a call
`control server 7, a location server 8 and other servers 9. The
`framework 5 functions as a name server for the distributed
`network architecture, where available Services, Such as the
`call control 7, location 8, billing and so forth register their
`availability. The framework 5 serves as a first point of
`contact for consumers of the Services, Such as third party
`applications (e.g., the WWW server 1). A service consumer
`can discover the available Services by querying the frame
`work 5. The framework 5 also performs authentication of
`consumers and directs them to the actual Service that resides
`in the SCS 6.The framework 5 may also accomplish per
`formance-related taskS Such as load balancing acroSS differ
`ent SCSS 6 offering the same service. The functionality
`provided by SCS 6 is referred to as the Service Capability
`Feature (SCF).
`0006. In the illustrated embodiment a first Parlay API2 is
`available between the framework 5 and the client applica
`tions 1B, and is referred to for this example as an Authen
`tication, Access Control and Service Discovery API. Second
`Parley APIs (SCF Usage) are available between the client
`applications 1B and the call control server 7, the location
`server 8 and the others server 9. A third Parley API 2
`(Service Registrations, Integrity, Multi-Domain Support) is
`used between the framework 5 and the SCS 6. A fourth
`Parley API (Enterprise Application Subscription) is speci
`fied between the Enterprise Applications 1A and the frame
`work 3, while a fifth Parley API 2 is defined between the
`Enterprise Applications 1A and the SCS 6, and is a coun
`terpart to the second Parlay API when the consumer is the
`enterprise applications 1A. Normally the enterprise appli
`cations 1A engage in aggregate Service contract with the
`network provider and maintain fine-grained control within
`themselves.
`0007. In the context of location-aware services, it should
`be noted that, at present, while the user is provided the
`option to Subscribe to different Services, the Services them
`Selves are not personalised. This is further explained below
`for the exemplary case that can arise during a cellular (e.g.,
`GPRS or UMTS) to wireless local area network (WLAN)
`Seamless inter-technology handoff.
`0008. In this case assume that the user's MT has two
`wireless RF interfaces, i.e., a cellular interface and a WLAN
`interface (e.g., a IEEE 802.11 or a Hyperlan interface).
`When the user runs an application, Such as a voice over
`Internet Protocol (VoIP) call over the cellular network (for
`example while driving), the user typically desires to have the
`WLAN interface Switched off for power saving purposes.
`However, when the user arrives at a certain location where
`the user can access a WLAN, Such as the user's home or
`office, the user wishes to Switch Seamlessly (and automati
`cally) to the WLAN. For this to occur the WLAN interface
`of the MT should be activated when the user comes close to
`the certain location where the WLAN is available so that the
`WLAN interface can begin scanning for the WLAN access
`point beacons, and can then register with the WLAN to
`enable the cellular/WLAN handoff to occur.
`
`Google, Exhibit 1012
`IPR2022-00742
`Page 6 of 12
`
`

`

`US 2004/0081120 A1
`
`Apr. 29, 2004
`
`0009 Prior to this invention, such highly personalized
`location-aware applications could not be realized with con
`ventional wireless networks and MTS, with or without the
`use of the Parlay API.
`
`SUMMARY OF THE INVENTION
`0.010 The foregoing and other problems are overcome by
`methods and apparatus in accordance with embodiments of
`this invention.
`0.011
`This invention provides embodiments of commu
`nication networks and MTS that enable personalized, user
`Specified, location-aware Service Creation and Notification
`procedures to be realized. The Service Creation procedure
`enables the user to define a personalised location-aware
`Service, while the Notification procedure is used to generate
`pre-programmed messages to appropriate user processes
`when the user arrives at a user-specified location. The user
`processes that receive the pre-programmed messages may
`reside in the network or in the MT, depending on the nature
`of Service.
`0012. A method and system is disclosed to provide a
`personalized, location-aware Service to a user of a MT. The
`method includes: (A) generating a Service specification
`object that includes at least in part a user-specified location
`and a message to be generated when the user arrives at the
`location with the MT; and (B) storing the service specifica
`tion object for later use. The method further entails: (C)
`tracking the location of the mobile terminal; and when the
`location of the mobile terminal matches the location in the
`Stored Service specification object, (D) generating the mes
`Sage for activating a user-specified Service.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0013 The above set forth and other features of these
`teachings are made more apparent in the ensuing Detailed
`Description of the Preferred Embodiments when read in
`conjunction with the attached Drawings, wherein:
`0.014
`FIG. 1 is a block diagram showing the relationship
`between a Parlay API layer and service and network
`domains,
`0.015
`FIG. 2 is a more detailed block diagram showing
`the use of Parlay APIs between application servers and a
`wireleSS network;
`0016 FIG. 3 is a network architecture diagram in accor
`dance with an aspect of this invention;
`0017 FIG. 4 is a logic flow diagram in accordance with
`the invention; and
`0018 FIG. 5 is a block diagram of a mobile terminal that
`is Suitable for use in practicing the teachings of this inven
`tion.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`0019. This invention provides in one embodiment a
`mechanism and a process whereby a user (with a MT), when
`physically present at certain location, is enabled to create a
`location-aware Service that is significant for that location, So
`that the user can avail himself or herself of the service during
`future visits to this certain location. In another embodiment
`
`the user need not be physically present at the certain
`location, So long as the user can identify the certain location
`with Sufficient specificity, when performing the task of
`location-aware Service creation. For example, the Service
`creation can take place offline using a PC or Some other
`Suitable terminal communicating with applications Server
`over the Internet, if the user knows the coordinates (Such as
`cell ID, GPS coordinates, etc.) of the location of interest.
`The user may also employ a characteristic Semantic Speci
`fication of the location (rather than actual coordinates) that
`can be understood by the network server 20 or third party
`application Server 1 and converted to location coordinates.
`For example, the user may specify the location of interest as
`“all WLAN hot-spots’ covered by a particular network
`operator, or “all WLAN hot-spots at airports covered by a
`certain operator”. The network server 20 or application
`Server 1 is then enabled to map Such a characteristic Speci
`fication of location to the actual coordinates of the loca
`tion(s) of interest using a database of actual coordinates, or
`by any Suitable technique.
`0020. The desired result is that when the user carrying the
`MT is located at the specified coordinates, or is within some
`radius of the Specified coordinates, the user-desired Service
`is triggered or initiated. One non-limiting example of a
`user-desired, location-specific or location-aware Service is a
`message that is generated to cause the WLAN interface of
`the MT to become active.
`0021
`FIG. 3 is a network architecture diagram that
`illustrates an embodiment of this invention, and illustrates
`the operator network 3 that contains a radio acceSS network
`25 and a packet core network 26. The MT 14 can connect to
`the operator network 3 via Base Stations (BS) 12. The
`operator network 3 is connected to the Internet 10 through
`gateway 13. The operator network 3 contains a location
`tracker function 24 which can determine the location of the
`MT14 using techniques such as cell ID or triangulation. The
`operator network 3 also contains a network server 20 which
`enables the creation and provision of the location-aware
`Services described herein. Network server 20 has access to
`the location tracker 24 of the radio access network 25.
`Network server 20 may store and maintain a Service Speci
`fication Object (SSO) 22. The operator network 3 also
`contains SCS 6 that enables third party application server 1
`to access information in the network 3 (Such as location of
`the MT 14 connected to network 3) over a Parlay API. Third
`party application Server 1 may also Store and maintain SSO
`22. The SCS 6 also has access to location tracker 24. A
`computer 23 connected to Internet 10 can communicate over
`the Internet 10 with the network server 20, with the third
`party application server 1, or with the MT 14 connected to
`operator network 3, for the purposes of Service creation.
`0022 Referring also to FIG. 5, in this example it is
`assumed that the MT 14 has two radio interfaces, namely a
`cellular interface 14B for connecting with BSS 12 of the
`network 3, and a WLAN interface 14A for connecting with
`APS 16 of a WLAN 18. The MT 14 also includes a control
`unit 16C, Such as a programmed microprocessor, and may
`include a user interface (UI) 14D. There is an area of overlap
`19 shown in FIG. 3 between the operator network 3 and the
`WLAN 18 where the MT 14 can receive Service from either
`the WLAN 18 or the operator network 3, and can thus be
`handed off from one to another. Note that a plurality of
`
`Google, Exhibit 1012
`IPR2022-00742
`Page 7 of 12
`
`

`

`US 2004/0081120 A1
`
`Apr. 29, 2004
`
`WLANs (not shown) could be present, and that the operator
`network 3 may overlap with a plurality of other operator
`networks (not shown).
`0023. It should be noted that the SSO 22 can be stored in
`the network server 20, or in the application server 1, or it
`could be located in the MT 14, as described below for the
`Service Creation cases (ii) and (iii). The creation and use of
`the SSO 22 will now be described in detail below.
`0024. By way of example, several techniques for the
`creation and provision of personalised location-aware Ser
`vices are now described in the context of Specific and
`non-limiting embodiments or cases.
`
`Case (i): Network Based Location Tracking and
`Message Generation
`In this case the network server 20 has the respon
`0.025
`sibility to track the location of the MT 14, as well as to
`generate the appropriate trigger messages to activate the
`service when the MT 14 arrives at the user-specified loca
`tion. If the SSO 22 is located in third party application server
`1, server 1 queries SCS 6 over Parlay API 2 to determine the
`location of the MT 14. The server 1 can then send a trigger
`message to activate the Service. AS was noted above, the
`network server 20 and the SCS 6 have access to the location
`tracking function 24 of operator network 3. In another
`embodiment, the network server 20 may push (location tags
`in) SSO 22 to an entity co-located with location tracker 24
`and request notification upon a match. For example, in
`GPRS, this entity could be the SGSN (Serving GPRS
`Support Node) which always has up-to-date knowledge of
`the location of the MT 14. Similarly, server 1 can register
`(location tags in) SSO 22 with SCS 6, which in turn may
`push then to entity co-located with location tracker 24.
`
`Case (ii): Network Based Location Tracking and
`MT 14 Based Message Generation
`0026. In this case the network has the responsibility to
`track the location of the MT 14. It then informs the MT 14
`of its current location and the MT 14 has the responsibility
`to generate the appropriate trigger messages to activate the
`user-specified service when the MT 14 arrives at the speci
`fied location. Here, the MT 14, sends periodic requests to
`location tracker 24 for location information (possibly via
`server 20 or server 1). Alternatively, location information is
`periodically pushed to MT 14. Which of these modes to
`follow can be specified at the time of creation of the SSO 22.
`0027) For Cases (i) and (ii), the MT 14 need not have
`location tracking functionality of its own, rather the location
`tracking function 24 of the network 3 can be used. For Cases
`(i) and (ii) the location tracking function 24 can be based
`simply on cell ID based location tracking. Other network
`based location tracking techniques, Such as triangulation,
`can be used as well.
`
`Case (iii): MT 14 Based Location Tracking and
`Message Generation
`0028. In this case the MT 14 tracks its location, such as
`by the use of a GPS receiver 14E shown in FIG. 5, and also
`generates the appropriate trigger messages to activate the
`desired service when the MT 14 arrives at the specified
`location. Thus, for Case (iii) the existence of Some location
`
`tracking functionality, such as the GPS receiver 14E or
`AGPS, is assumed to be present in or otherwise available to
`the MT 14, which allows the MT 14 to self-locate itself.
`0029. These embodiments are now further described for
`the exemplary Service of activating the powered down or
`sleeping WLAN radio interface 14A of the MT 14 when the
`user carrying the MT 14 arrives at a pre-specified location,
`thereby enabling an inter-technology handoff (cellular to
`WLAN in this embodiment) to be performed. Other loca
`tion-based Services may also be implemented.
`0030) A description of the procedures of location-aware
`Service Creation and Notification is now provided.
`
`Service Creation
`0031. During this procedure, a user specifies: (a) the
`location where a certain message should be generated; (b)
`the entity that is to track the MT 14 location (e.g., location
`tracker 24 or GPS receiver 14E); (c) the message(s) to be
`generated at the location specified in (a) (e.g., activate the
`WLAN interface 14A); (d) the originator of the message(s);
`(e) the receiver of the message(s); and (f) the action(s) to be
`performed upon generation/reception of the messages.
`0032) Of these, step (a) can be performed by being
`physically present (e.g., while carrying MT 14) at the
`location (e.g. home, office, Store, etc.), or by Specifying
`coordinates of the location, or by Some characteristic Speci
`fication that allows the network server 20 or third party
`server 1 to identify the coordinates of the location(s) the user
`is referring to. An example of the last case is a location
`specification such as, “all WLAN hot-spots covered by a
`particular operator'. Such a specification in turn allows the
`network server 20 or third party server 1 to provide the user
`with a specified service when, for example, the MT 14
`arrives at an airport covered by the operator's WLAN.
`0033. An example is now described of the Service Cre
`ation procedure for the exemplary Scenario of the inter
`technology handoff described above. During the Service
`Creation procedure the user creates a data object, the SSO,
`of the form described below. The SSO can be created from
`the MT14 or from Some computer 23 connected to server 20
`in the network 3 or server 1, over the Internet 10. One
`suitable server may be one affiliated with the assignee of this
`patent application, and known as “Club Nokia'TM. The SSO
`22 is Subsequently Stored in and maintained by the network
`server 20, or third party application server 1, or in the MT
`14 shown in FIG. 3.
`
`Case (i): Network Based Location Tracking and
`Message Generation
`
`0034) Tag:
`0035) Location=<''This">/<Coordinates>/<Charac
`teristica, RadiuS=<value>,
`0036) The “f” symbol in this logical expression implies
`an OR function. The value “This” is used when the service
`creation is performed when the MT14 is physically present
`at the location. In addition, the MT 14 will be connected to
`either network server 20 or server 1 for uploading SSO 22,
`or MT14 can be continuously connected to the network
`server 20 or server 1, which guide the MT14 through the
`Service Creation procedure over a web-based interface. In
`
`Google, Exhibit 1012
`IPR2022-00742
`Page 8 of 12
`
`

`

`US 2004/0081120 A1
`
`Apr. 29, 2004
`
`this case network server 20 determines the co-ordinates of
`current location of MT 14 or server 1 queries SCS 6 for the
`location information. If the MT 14 has GPS functionality,
`the value “This can be locally replaced by appropriate
`coordinates. Thus, the value “This” is automatically
`replaced by the appropriate coordinates of the MT14 current
`location. The value “Coordinates' is used when the user
`explicitly provides a coordinate Set to describe the current or
`a desired location. The value “Characteristic' is used when
`the user implicitly provides the coordinate Set, Such as by
`entering a character String Such as “Airport' or "Shopping
`Mall'. In this case the network server 20 or third party
`application Server 1 looks up or otherwise determines the
`appropriate coordinate Set. For the last two cases, Service
`creation can be preformed from computer 23 connected to
`network server 20 or third party application server 1 over the
`Internet 10, for the purpose of uploading SSO 22 (and for
`guiding the Service creation procedure). The value of
`"Radius' can be defaulted to Some Suitable value (e.g., one
`kilometer),or it can be specified with any desired precision
`(e.g., 200 meters), depending on the nature of the Service to
`be provided at the Specified location. In general, it may be
`preferred to require the entry of the value of Radius when
`more accurate location tracking techniques (triangulation)
`are used. On the other hand, if coarse location tracking
`techniques, Such as cell ID, are used, the Radius Specifica
`tion may be optional.
`0037 Location Tracker:
`0.038 Tracker=<“Network's;
`0.039
`This field specifies which entity is to be responsible
`for tracking the MT 14 location for when providing the
`service. Note that when “Network” is specified, and if the
`SSO 22 is stored on the network server 20, the server 20 can
`track the location of the MT 14 using location tracker 24. If
`the SSO 22 is stored on the third party application server 1,
`the server 1 can track the location of the MT14 by querying
`the SCS 6 over the Parlay API 2. The SCS 6 can obtain the
`location of the MT 14 from the locating tracker 24.
`0040 Service Profile:
`0041) Message=“Wake up WLAN”
`Originator=<''Network's
`0.042
`0043)
`Receiver-C"Terminal’s
`0044 Action=<Activate WLAN interface 14A upon
`receiving this message>.
`0.045. Note that in this example it is assumed that the
`control unit 14C of the MT 14 recognizes the incoming
`message from the network server 20 or the third part
`application Server 1, and can take the appropriate action.
`That is, the mapping of Message to Action is performed by
`the control unit 14C. Note as well that the value of Action
`may not need to be expressly specified as it maybe already
`programmed into the MT 14 and accessible to the control
`unit 14C.
`0046) In the foregoing (and Subsequent) examples it is
`possible to provide an optional Tag representing other cri
`teria, such as “Time” and/or “Date”. For example, one may
`wish to activate the WLAN interface 14A when near to one's
`office only on weekdays between 8:00 AM and 5:00 PM,
`otherwise only the cellular interface 14B should be used.
`
`0047 The resulting service creation object composed by
`the MT14, in cooperation with the control unit 14C and the
`UI 14D, is then sent to the network server 20 or third party
`application Server 1 and Stored in a user profile as the
`Service Specification Object 22. Note that in this and the
`following cases multiple tags (corresponding to different
`location tracking technologies) may be associated with the
`Same SSO.
`0048 When the Service Creation function is performed
`off-line, such as by accessing the network server 20 or third
`party server 1 from the PC 23, the identity of the MT 14,
`Such as the phone number, is preferably provided as well
`when the value “Terminal' is used for any of the fields. For
`the off-line Service Creation function the resulting SSO can
`be forwarded to the network server 20 for storage, or it can
`be stored and maintained external to the network 3, Such as
`by the third party application server 1 as shown in FIG. 3
`(which may be the same server used for the Service Creation
`function).
`Case (ii): Network Based Location Tracking and
`MT 14 Based Message Generation
`0049) Tag:
`0050. Location=<''This">/<Coordinates>/<Charac
`teristica, RadiuS=<value>,
`0051) Location Tracker:
`0.052 Tracker=<"Network'>;
`0.053
`Service Profile:
`0054 Message="Wake up WLAN”
`0055) Originator=<“Terminal">
`0056 Receiver-k"Terminal'>
`0057 Action=<Activate WLAN interface 14A upon
`receiving this message>.
`0.058. In this case the SSO 22 is resident in the MT 14. If
`the off-line Service Creation function is used the resulting
`SSO 22 is forwarded via the network 3 to the MT 14. This
`case is useful to preserve privacy of Service. In this case, if
`the location tracking via periodic push from network to MT
`14 is used, a push request is registered with network Server
`20 or the third party application server 1.
`
`Case (iii): MT 14 Based Location Tracking and
`Message Generation
`
`0059) Tag:
`0060. Location=<''This">/<Coordinates>/<Seman
`tica, RadiuS=<valued;
`0061 The value “This” is used when the service creation
`is performed when the MT 14 is physically present at the
`location. In this case the MT 14 automatically replaces the
`value "This” with appropriate coordinates of the location, as
`determined locally by the GPS receiver function 14E. The
`value of “Semantic' is replaced by appropriate location
`coordinates stored in the MT 14 or obtained from the
`network server 20 or third party server 1.
`
`Google, Exhibit 1012
`IPR2022-00742
`Page 9 of 12
`
`

`

`US 2004/0081120 A1
`
`Apr. 29, 2004
`
`0062 Location Tracker:
`0063) Tracker=<"Terminal'>;
`0064.) Service Profile:
`0065 Message=“Wake up WLAN”
`Originator=<"Terminal's
`0.066)
`0067
`Receiver-C"Terminal’s
`0068 Action=<Activate WLAN interface 14 upon
`receiving this message>.
`0069. As for case (ii), the SSO 22 is assumed to be stored
`in the MT 14. If the off-line Service Creation function is
`used the resulting SSO 22 can be forwarded via the Internet
`10 and network 3 to the MT 14.
`0070) Notification Procedure:
`Case (i): Network Based Location Tracking and
`Message Generation
`0071. The network server 20 or third party server 1
`compares the current location (cell ID or another appropriate
`parameter depending upon the location tracking technology
`used) of the MT 14 with the Location tags of the user's
`stored SSO 22 or SSOs (as a plurality of different SSOs may
`be present). When the current location matches a Location
`Specified in a tag, the user-programmed message (e.g.,
`“Wake up WLAN”) is generated by the network server 20 or
`third party server 1. This message is sent to the MT 14, as
`the user process of activating the WLAN interface 14A
`resides in the MT 14 in this case. Upon receiving this
`message, the control unit 14C of the MT 14 maps the
`message to pre-programmed actions and activates the
`WLAN interface 14A.
`
`Case (ii): Network Based Location Tracking and
`MT 14 Based Message Generation
`0072 The MT 14 requests the network 3 to provide the
`MT 14 location information (e.g., based on cell ID, or
`triangulation). Alternatively, the network 3 can periodically
`push the location information to the MT 14. The MT 14
`compares the network 3 derived location information with
`the tags of the user's SSOs. When the current location
`matches the tag, the user-programmed message (“Wake up
`WLAN”) is generated. Upon the generation of this message,
`the pre-programmed action of activating WLAN interface
`14A is performed.
`0073. Note with regard to case (ii) that if the user process
`that is intended to act on the message resides in the network
`3, or in another network Such as the Internet 10, then the MT
`14 transmits the message to the appropriate process in the
`network 3 or in the Internet 10 (via the network3). Note also
`with regard to case (i), that if the process that is intended to
`act on the message resides elsewhere than the MT 14, then
`the network server 20 or third party application server 1
`Sends the message to the remotely located user process.
`Case (iii): MT 14 Based Location Tracking and
`Message Generation
`0074 The MT 14 compares the current GPS-derived
`coordinates with the tags (within the specified radius) of the
`SSOS Stored in the MT 14. When the current GPS coordi
`
`nates match the tag, the user-programmed message (e.g.,
`“Wake up WLAN”) is generated. Upon the generation of this
`message, the associated user-programmed actions (activat
`ing the WLAN interface 14A) are performed. As for case
`(ii), if the user process that is intended to act on this message
`resides in the network 3, then the MT 14 transmits the
`message to the appropriate proceSS in the network 3. If it
`resides elsewhere in the Internet 10, the MT14 transmits the
`message to that process over the network 3 and over the
`Internet 10.
`0075 For the forgoing cases an application can be run in
`the MT14 (e.g., one based on JAVA) to facilitate the Service
`Creation procedure. Web-based Service Creation sessions
`may also be employed. The application, if run in the MT14,
`may use the control unit 14C and the UI 14D to prompt the
`user to enter the required values for Location, Location
`Tracker, Message, etc. If the web-based interface is used, the
`web server can prompt the user for this information. The
`format and operation of the data entry application can
`assume many forms, as should occur to those skilled in the
`art when guided by the foregoing teachings. Intelligence
`may reside in control unit 14C or web server(s) to check the
`consistency of the information entered by user. For example,
`a user with an MT 14 that lacks a self-locate capability
`cannot enter the value "terminal” as the location tracker.
`0076. The transfer of the various messages, including the
`Notification message(s) between the MT 14 and the user
`process, or between server 20 (server 1) and the user
`process, may use Short Message Service (SMS) messages,
`or IP messages Such as the Internet Control Messaging
`Protocol (ICMP), the User Datagram Protocol (UDP), the
`Transmission Control Protocol (TCP), or any other standard
`method of message transfer between two nodes in an IP
`network, including higher level message protocols Such as