HK1194172B - Private and public applications - Google Patents

Description

Private and public applications

Technical Field

The present disclosure relates generally to designating an application for public access or private access on a computing device.

Background

Computing devices often employ security measures to prevent unwanted or accidental access to information, applications, or features provided by the computing device. Computing devices often store sensitive information that users may not wish other users to view. Generally, as a personal preference, a user may also generally wish to limit access to their computing device by other users. Example security measures employed on a computing device to prevent unwanted access include enforcing a security wall to prevent access to applications on the computing device unless a particular security input is received. Typically, when a security wall is employed on a device, a security code, password, or some other input sequence is required as a security input to access an application on the computing device.

While enforcement of the security wall limits unwanted access to applications on the computing device, the security wall also prevents the owner of the computing device from easily accessing applications on the computing device. In most cases, the user attempting to access the computing device is the owner or authorized user of the computing device. Further, some applications on a computing device may be associated with private information, while other applications have little or no privacy aspect.

Disclosure of Invention

In a first general aspect, a method for designating an application for public or private access on a computing device is disclosed. Applications on a computing device are designated for private or public functionality. Enforcing a security wall for an application if the application is designated for private functionality, wherein enforcing the security wall includes preventing access to the application until a security input is received. Providing access to an application if the application is designated for public functionality, wherein providing access to the application comprises allowing a user to access the application without receiving security input from the user.

Implementations may include any or all of the following features. Providing access to the application includes requiring a second input from the user prior to allowing the user access to the application, the second input being different from the security input. The second input includes a predefined sequence of multiple inputs associated with a tactile button on the computer system, the tactile button associated with receiving input for a function of the computer system, the function different from a function provided by the application. The application is specified based on a request received from a user. The application is automatically specified based on at least one of an application type associated with the application, a time since the application was previously accessed, or a frequency of use of the application.

Providing access to an application includes generating for display a visual indicator indicating that the application is available in a public mode of a computer system. Generating the visual indicator for display includes displaying a particular visual indicator for each application in a group of applications, wherein each application in the group of applications is designated for public functionality. The application group is a subset of all applications designated for public functionality, and the displayed application group is displayed based on at least one of a geographic location of the computer system, a current date or time of day, a context associated with the user, a most recently performed operation by the user, or a degree of importance of information associated with a particular application.

Specifying applications for public or private functions includes: at least one of a plurality of functions of the application is designated for public functions, and a remaining portion of the plurality of functions of the application is designated for private functions. The enforcement safety wall includes: preventing access to the remaining portion of the plurality of functions designated for private functions until a security input is received, and allowing a user to access at least one function of an application designated for public functions without receiving a security input. The method further includes automatically designating the particular application for the privacy function after a certain period of time has elapsed since the previous use of the particular application.

In a second general aspect, a computer program product is tangibly embodied in a computer-readable storage medium and includes instructions that, when executed, determine that a first function of an application is designated for a public function and a second function of the application is designated for a private function. Providing access to a first function of an application, wherein providing access to the first function of the application comprises allowing a user to access the first function of the application without receiving security input from the user. Enforcing the security wall for the second function of the application, wherein enforcing the security wall includes preventing access to the second function of the application until a security input is received.

Implementations may include any or all of the following features. Providing access to a first function of an application includes requiring a second input from the user prior to allowing the user to access the application, the second input being different from the security input. The second function of the application includes a purchase function that allows a user to make a purchase through the application. Automatically determining that a first function of the application is designated for a public function based on a function type associated with the first function, and automatically determining that the first function of the application is designated for a private function based on a function type associated with the second function.

The details of one or more implementations of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

Drawings

FIG. 1 is a block diagram of an example mobile device.

FIG. 2 is a block diagram of an example network operating environment for the mobile device of FIG. 1.

Fig. 3A is a block diagram of an example implementation of the mobile device of fig. 1in standby mode having a security wall.

Fig. 3B is another block diagram of an example implementation of the mobile device of fig. 1in standby mode having a security wall.

FIG. 3C is a block diagram of an example implementation of the mobile device of FIG. 1in the disclosure mode.

FIG. 3D is another block diagram of an example implementation of the mobile device of FIG. 1in the disclosure mode.

FIG. 3E is yet another block diagram of an example implementation of the mobile device of FIG. 1in the public mode.

FIG. 4 is a flow diagram illustrating one example process for specifying an application for public access or private access on a computing device.

FIG. 5 is a flow diagram illustrating another example process for specifying an application for public access or private access on a computing device.

FIG. 6 is a block diagram of an exemplary hardware architecture for implementing the user interfaces and processes described with reference to FIGS. 1-5.

Like reference numbers and designations in the various drawings indicate like elements.

Detailed Description

The computing device may employ a security wall to inhibit unwanted users from accessing functionality provided by the computing device. Instead of applying a security wall to all functions of the computing device, the computing device may apply the security wall only to functions designated as private while allowing the user to access functions designated as public. Thus, access to the public functionality on the computing device does not require the security inputs normally required to bypass the security wall. Whether a particular function in a computing device is public or private may be determined based on various factors including a designation received from a user or a context of the computing device. Further, other inputs than the security input may still be required to access the disclosed functionality.

Fig. 1 is a block diagram of an example mobile device 100. The mobile device 100 may be, for example, a handheld computer, a personal digital assistant, a cellular telephone, a network appliance, a camera, a smartphone, an Enhanced General Packet Radio Service (EGPRS) mobile telephone, a network base station, a media player, a navigation device, an email device, a game console or other electronic device, or a combination of any two or more of these or other data processing devices. Although the following description generally refers to the mobile device 100, any computing device, including a personal computer, notebook computer, or tablet computer, may be used in accordance with the features described in this disclosure.

Overview of Mobile devices

In some implementations, the mobile device 100 includes a touch-sensitive display 102. The touch sensitive display 102 may employ Liquid Crystal Display (LCD) technology, light emitting polymer display (LPD) technology, or some other display technology. The touch-sensitive display 102 may be sensitive to tactile and/or haptic contact with a user.

In some implementations, the touch-sensitive display 102 can include a multi-touch-sensitive display 102. The multi-touch-sensitive display 102 can, for example, process multiple simultaneous touch points, including processing data related to the pressure, extent, and/or location of each touch point. Such processing facilitates gestures and interactions with multiple fingers, chording (chording), and other interactions. Other touch sensitive display technologies may also be used, such as a display that uses a stylus or other pointing device to make contact. Examples of multi-touch sensitive display technologies are described in U.S. patent nos. 6323846, 6570557, 6677932 and U.S. patent publication No. 2002/0015024a1, each of which is incorporated herein by reference in its entirety.

In some implementations, the mobile device 100 can display one or more graphical user interfaces on the touch-sensitive display 102 for providing user access to various system objects and for communicating information to the user. In some implementations, the graphical user interface can include one or more display objects 104, 106. Each display object 104, 106 may be a graphical representation of a system object. Some examples of system objects include device functions, applications, windows, files, alarms, events, or other identifiable system objects.

Example Mobile device functionality

In some implementations, mobile device 100 can implement multiple device functions, such as a telephony device indicated by telephony object 110, an email device indicated by email object 112, a network data communications device indicated by Web object 114, a Wi-Fi base station device (not shown), and a media processing device indicated by media player object 116. In some implementations, certain device objects 104, such as phone object 110, email object 112, Web object 114, and media player object 116, may be displayed in menu bar 118. In some implementations, each device function can be accessed from a top-level graphical user interface, such as the graphical user interface shown in fig. 1. Objects 110, 112, 114, and 116 represent visual indicators of applications on mobile device 100. Touching one of the objects 110, 112, 114 or 116 may, for example, invoke a corresponding function.

In some implementations, the mobile device 100 can implement network distribution functionality. For example, the functionality may enable a user to carry the mobile device 100 and a network associated therewith while on the road. In particular, the mobile device 100 may extend internet access (e.g., over Wi-Fi) to other wireless devices in the vicinity. For example, mobile device 100 may be configured as a base station for one or more devices. Thus, the mobile device 100 may grant or deny network access to other wireless devices.

In some embodiments, upon invocation of a particular device function, the graphical user interface of mobile device 100 is changed, or enhanced, or replaced with another user interface or user interface element to facilitate user access to the particular function associated with the corresponding device function. For example, in response to a user touching a phone object 110, the graphical user interface of the touch-sensitive display 102 can present display objects related to various phone functions; likewise, touching email object 112 may cause the graphical user interface to present display objects related to various email functions; touching the Web object 114 may cause the graphical user interface to present display objects related to various Web surfing functions; touching the media player object 116 may cause the graphical user interface to present display objects related to various media processing functions.

In some implementations, the top-level graphical user interface environment or state of FIG. 1 can be restored by pressing a button 120 located near the bottom of the mobile device 100. In some implementations, each respective device function can have a respective "home" display object displayed on the touch-sensitive display 102, and the graphical user interface environment of fig. 1 can be restored by pressing the "home" display object.

In some implementations, the top-level graphical user interface can include additional display objects 106, such as a Short Message Service (SMS) object 130, a calendar object 132, a photos object 134, a camera object 136, a calculator object 138, a stocks object 140, a weather object 142, a maps object 144, a notes object 146, a clocks object 148, an address book object 150, and a settings object 152. Touching the SMS display object 130 may, for example, invoke an SMS message environment and support functions. Likewise, each selection of a display object 132, 134, 136, 138, 140, 142, 144, 146, 148, 150, and 152 may invoke a corresponding object environment and functionality.

Additional and/or different display objects may also be displayed in the graphical user interface of fig. 1. For example, if the device 100 is functioning as a base station for other devices, one or more "connection" objects may appear in the graphical user interface to indicate a connection. In some implementations, the display objects 106 can be configured by a user, for example, the user can specify which display objects 106 to display, and/or can download other software or additional applications that provide other functionality and corresponding display objects.

In some implementations, the mobile device 100 can include one or more input/output (I/O) devices and/or sensor devices. For example, a speaker 160 and microphone 162 may be included to facilitate voice-enabled functions such as telephone and voicemail functions. In some embodiments, a microphone 164 may be included to facilitate hands-free voice functionality, such as speakerphone functionality. An audio jack 166 may also be included for using a headset and/or a microphone.

In some implementations, a proximity sensor 168 can be included to facilitate detection of a user placing the mobile device 100 proximate to the user's ear and, in response, to deactivate (disconnect) the touch-sensitive display 102 to prevent accidental function calls. In some implementations, the touch-sensitive display 102 can be turned off when the mobile device 100 is near the user's ear to save additional power consumption.

Other sensors may also be used. For example, in some implementations, the ambient light sensor 170 can be utilized to facilitate adjusting the brightness of the touch-sensitive display 102. In some implementations, the accelerometer 172 can be utilized to detect movement of the mobile device 100, as indicated by directional arrow 174. Thus, display objects and/or media may be rendered according to a detected orientation (e.g., portrait or landscape). In some implementations, the mobile device 100 can include circuitry and sensors to support location determination capabilities such as provided by a Global Positioning System (GPS) or other positioning system (e.g., systems using Wi-Fi access points, television signals, cellular grids, Uniform Resource Locators (URLs)). In some implementations, a positioning system (e.g., a GPS receiver) can be integrated into the mobile device 100 or provided as a separate device that can be coupled to the mobile device 100 through an interface (e.g., the port device 190) to provide access to location-based services.

The mobile device 100 may also include a camera lens and sensor 180. In some implementations, the camera lens and sensor 180 can be located on the rear surface of the mobile device 100. The camera may capture still images and/or video.

Mobile device 100 may also include one or more wireless communication subsystems, such as 802.11b/g communication device 186 and/or Bluetooth^TMA communication device 188. Other communication protocols may also be supported, including other 802.X communication protocols (e.g., WiMax and Wi-Fi), Code Division Multiple Access (CDMA), Global System for Mobile communications (GSM), Enhanced Data GSM Environment (EDGE), 3G (e.g., EV-DO, UMTS, HSDPA), and so forth.

In some embodiments, a port device 190, such as a Universal Serial Bus (USB) port or a docking station port, or some other wired port connection, may be included. The port device 190 may, for example, be utilized to establish a wired connection to other computing devices, such as other communication devices 100, personal computers, printers, or other processing devices capable of receiving and/or transmitting data. In some embodiments, the port device 190 allows the mobile device 100 to synchronize with a host device using one or more protocols.

Network operating environment

FIG. 2 is a block diagram of an example network operating environment 200 for the mobile device 100 of FIG. 1. The mobile device 100 of fig. 1 may communicate over one or more wired and/or wireless networks 210, for example, in a data communication manner. For example, a wireless network 212, such as a cellular network, may communicate with a Wide Area Network (WAN) 214, such as the internet, through the use of a gateway 216. Likewise, an access point 218, such as an 802.11g wireless access point, may provide communication access to the wide area network 214. In some implementations, both voice and data communications can be established over the wireless network 212 and the access point 218. For example, the mobile device 100a may place and receive phone calls (e.g., using VoIP protocols), send and receive e-mail messages (e.g., using POP3 protocol), and retrieve electronic documents and/or streams, such as web pages, photographs, and videos, over the wireless network 212, the gateway 216, and the wide area network 214 (e.g., using TCP/IP or UDP protocols). Likewise, the mobile device 100b may place and receive telephone calls, send and receive e-mail messages, and retrieve electronic documents over the access point 218 and the wide area network 214. In some implementations, the mobile device 100 can be physically connected to the access point 218 using one or more cables, and the access point 218 can be a personal computer. In this configuration, the mobile device 100 may be referred to as a "tethered" device.

The mobile devices 100a and 100b may establish communication in other manners as well. For example, wireless device 100a may communicate with other wireless devices (e.g., other wireless devices 100, cell phones, etc.) via wireless network 212. Likewise, mobile devices 100a and 100b may pass throughUsing Bluetooth such as that shown in figure 1^TMOne or more communication subsystems of the communication device 188 establish point-to-point communications 220 (e.g., a personal area network). Other communication protocols and topologies may also be employed.

The mobile device 100 may communicate with one or more services 230, 240, 250, 255, 260 and/or one or more content publishers 270, for example, over one or more wired and/or wireless networks 210. For example, the navigation service 230 may provide navigation information, such as map information, location information, route information, and other information to the mobile device 100. In the illustrated example, a user of the mobile device 100b invokes a map function, for example, by touching a map object 144 on the top-level graphical user interface shown in FIG. 1, and requests and receives a map for the location "1 Infinite Loop, Cupertino, CA".

The messaging service 240 may, for example, provide email and/or other messaging services. The media service 250 may, for example, provide access to media files such as song files, movie files, video clips, and other media data. The location-based service 255 may provide data or content based on, for example, the current location of the mobile device 100. One or more other services 260 may also be utilized by the mobile device 100, the other services 260 including a synchronization service, an activation service, and a software update service that automatically determines whether a software update for software on the mobile device 100 is available and then downloads the software update to the mobile device 100 where the update may be manually or automatically unpacked and/or installed.

The mobile device 100 may also access other data over one or more wired and/or wireless networks 210. For example, content publishers 270 such as news sites, RSS subscriptions, websites, blogs, social sites, developer networks, and the like can be accessed through the mobile device 100. Such access may be provided by invoking a Web browsing function or application (e.g., a browser) in response to a user touching the Web object 114.

Exemplary display of public and private applications

3A-3E depict example displays that provide varying degrees of access to different applications on a computing device. Computing devices may generally be configured to implement security walls to limit unwanted or accidental access to functionality provided by the computing device. FIG. 3A illustrates an implementation of example security measures for restricting access to applications on a mobile device 300. The mobile device 300 may enter a "standby" or "locked" mode as depicted in fig. 3A. In the standby mode, the mobile device 300 may enforce a security wall to prevent access to functions, applications, and information typically provided by the mobile device 300. In some cases, limited features may be present during the standby mode of the mobile device 300, such as the current time and date, remaining battery life indicator, or cellular received signal strength. However, the remaining functionality provided by the mobile device 300 may be limited until the mobile device 300 receives a security input.

The mobile device 300 may require different security inputs before the user is given access to the functionality of the mobile device 300. In fig. 3A, a sliding action performed by a user in contact with the touch-sensitive display 302 may trigger unlocking the mobile device 300. Generally, the slide action input prevents accidental unlocking of the mobile device 300. A different input may also be required to unlock the mobile device 300, such as entering a security code as depicted in fig. 3B. This prevents a user who does not have access to an application on the mobile device 300 from gaining access to the application.

In some cases, the owner of the mobile device 300 may not be aware of unwanted access to certain applications on the mobile device 300. For example, some applications may not contain personal information that any owner wishes to keep private. Furthermore, the owner may prefer easy access to some applications and may be willing to assume the risk of unwanted access to these applications, even if personal information is accessible through these applications. However, applying a security wall uniformly to all applications on the mobile device 300 as depicted in fig. 3A and 3B may slow the owner from accessing certain applications due to the need for additional security input.

Fig. 3C illustrates a display of applications on the mobile device 300 that are usable by the user without requiring secure input from the user. In display 302, applications that a user may use are represented as display objects 330, 332, 338, 340, 342, 344, 346, and 348. The display object in fig. 3C is presented in the "public mode" of the mobile device 300. In the public mode, the mobile device 300 may only present objects designated as public applications and allow access to these applications without forcing a security wall for these applications. In contrast, in the private mode, the mobile device 300 may require a secure input, such as those depicted in fig. 3A and 3B, before allowing access to applications designated for private functionality. In some cases, applications designated for public functionality may be accessed in both a public mode and a private mode. Further, during the public mode, the mobile device 300 may present only a subset of all applications designated for public access at a time. Depending on the context, different groups of published applications may be presented in the display. Touching one of the objects 330, 332, 338, 340, 342, 344, 346, or 348 displayed in the public mode may invoke a corresponding function associated with the displayed object without first entering a security input such as described with respect to fig. 3A or 3B.

Various inputs may trigger the public mode of the mobile device 300 and transition the mobile device 300 from the standby mode to the public mode. For example, a predefined sequence of multiple inputs associated with the tactile button 384 on the mobile device 300 can trigger an overt mode of the mobile device 300, such as pressing the button 384 twice in quick succession or pressing the button 384 in a particular mode.

In some implementations, in addition to being associated with triggering the public mode of the mobile device 300, the tactile button 384 can be associated with receiving input for a function of the mobile device 300. For example, tactile button 384 may be associated with receiving an input for changing the volume of a speaker on mobile device 300, or for switching mobile device 300 into a standby mode. In other words, the tactile button 384 may be used to enter a particular input to trigger the public mode of the mobile device 300 as well as other functions of the mobile device 300. In some examples, a dual button for increasing or decreasing the volume of the mobile device 300 may also be used to trigger the public mode of the mobile device 300. For example, a particular combination of inputs for increasing and/or decreasing the volume, such as pressing the "volume up" button twice followed by pressing the "volume down" button once, may trigger the disclosure mode. In other cases, a particular input on the touch-sensitive display 302 of the mobile device 300 may switch the mobile device 300 into the public mode. Other inputs for triggering activation of the public mode of the mobile device 300 are also within the scope of the present disclosure.

In some implementations, the application is designated for public access based on a user selection. For example, a user may select an individual application for public access by designating certain applications provided by mobile device 300 as public applications. The selected application may then be available to the user in the public mode of the mobile device 300 without requiring entry of a security code. In some cases, an application developer may specify an application for private or public functionality. For example, an application developer may mark a particular application as public or private during application development, or a developer or user may designate an application as public or private through an Application Programming Interface (API) of an operating system on the mobile device 300. In some implementations, a developer may create an application for distribution, for example, through an online store, and may post an application designation as public or private in the online store to notify such developer of the designated potential user. Different aspects of the same application may be designated as public or private, such as described below with respect to fig. 3E.

In some cases, the mobile device 300 may support different modes, some of which automatically designate certain applications as public based on a particular context associated with the mobile device 300 or a user of the mobile device 300. For example, an application may be automatically designated as public based on how recently the application was last used. Further, among the plurality of public applications, the public application displayed in the display area 302 of the mobile device 300 may be determined based on when the application was previously used. The designation or display of applications in the public mode may also be based on other factors, such as the frequency of use or type of application for a particular application. For example, applications with personal information, such as address book applications or online banking applications, may be designated for private access to prevent unwanted access, while certain applications, such as music players or computer games, may be designated for public access, since the user may not be interested in public access to these types of applications.

The designation of the application can also be based on a context associated with the mobile device. In some implementations, applications associated with a particular context are grouped together and displayed in the public mode of the mobile device 300. FIG. 3D illustrates an example embodiment in which certain applications are grouped together and displayed to a user based on the geographic location of the mobile device 300. For example, the mobile device may include a navigation system or other feature that may determine a particular current location of the mobile device. In some implementations, the mobile device 300 uses GPS or any other positioning system to determine its current location. In some implementations, the current location determined using GPS may be represented by latitude/longitude. In some implementations, the mobile device 300 can optionally convert the latitude/longitude of the current location to an address (e.g., street, city, country) by, for example, referencing a database of latitude/longitude and location stored in memory. The mobile device 300 may also obtain its geographic location in other ways. For example, the mobile device 300 may use cellular phone tower triangulation, Wi-Fi positioning, a combination of GPS and other signals, differential GPS, and any other suitable techniques and techniques to obtain its location.

Given a particular current location, the mobile device may automatically specify applications that are likely to be used. For example, if the navigation system of the mobile device 300 determines that the user is located in a particular foreign country based on the location of the mobile device 300, applications that are helpful to the user may be automatically designated as public applications and displayed in a public mode of the mobile device 300, as shown in FIG. 3D. In the illustrated example, objects associated with translation application 346, currency converter application 348, and weather application 330 are displayed in the public mode of mobile device 300. The user may view and access the functionality associated with the displayed application without entering a security code.

In another example, the mobile device 300 may determine a particular activity that the user is currently performing based on the relative motion of the mobile device at a particular time. Accelerometer 372 of mobile device 300 may be used to detect motion of mobile device 300, allowing a determination of the current activity of the user based on salient features of the motion. If the motion of the mobile device 300 indicates that the user is, for example, running, an application related to casual running may be automatically designated as a public application and displayed in the mobile device 300 in a public mode.

Applications may be grouped based on other contexts associated with certain applications or with the mobile device 300. For example, based on the current date or time of day, applications may be designated for public functions and grouped together for display in a public mode of the mobile device 300. In the morning, applications associated with tasks performed in the morning, such as daily news, weather, traffic, or radio, are automatically grouped together and displayed in the public mode of the mobile device 300. At other times of the day, other applications may be designated for public functions, depending on the application function. In some implementations, the designation and grouping of applications can be tied to a calendar application on the mobile device 300. Thus, as a particular calendar date approaches, applications associated with, for example, an approaching deadline, event, or holiday may be automatically designated for the exposure function.

The automatic specification of the application may be dynamic. In some cases, applications may be designated for disclosing functionality, but over time or when a particular context changes, the designation of an application may change automatically. For example, frequent use of a particular application may automatically trigger automatic designation of the application for public functionality. After a period of time, the application may be used less frequently, and after a certain period of time has elapsed, the application may be automatically designated for privacy functions.

FIG. 3E illustrates a display of particular functions of an application that have been designated for public access. In some implementations, certain features or portions of an application may be designated for public access while the remaining portions are still designated for private access. For example, in general, an email application may be designated for private access, but specific functions in the email application, such as a calendar feature associated with the email application or the ability to read email, may be used for public access. In some cases, certain less sensitive features in an application may be designated for use in disclosing functionality. Features that are generally considered more important may be designated for disclosing functionality. As shown in fig. 3E, certain contacts, such as an emergency number 334 or a personal home number 332, may be publicly accessible in the address book 330 of the mobile device 300. However, the remaining contacts in address book 330 are still designated for private functionality and are only accessible after entry of the security code.

In another example, a camera application on the mobile device 300 may generally take a photograph and present the user with the photograph taken using the camera application. The camera application may specify certain functions for public access, such as allowing a user to take pictures in public mode, but only allowing viewing of pictures taken in public mode. Viewing other photos in a camera application may be limited to private access. In some implementations, functionality associated with the purchase in the application may be automatically designated for private access. For example, a video game application on the mobile device 300 may allow a user to make in-game purchases, such as purchasing additional life or money in a game. The in-game purchase functionality may be limited to private access such that a user of the mobile device 300 in the public mode may play the video game application but is prohibited from making purchases in the game unless the user enters the private mode of the mobile device 300.

Example Process for specifying and displaying public and private applications

FIG. 4 is a flow diagram of an exemplary process 400 for specifying and displaying public and private applications. In the exemplary process 400, an application is designated for private or public functionality (402). Specifying an application for public or private functionality may be determined automatically based on user input, or based on context or application type associated with the application. Certain types of applications may be designated for disclosing functionality. In some cases, certain applications are designated for public functionality based on frequency of use. If the application is designated as private, a security wall is enforced for the application (404). To access the functionality of an application designated as private, a user may be required to enter a security code. If the application is designated as public, access is provided to the application (406). The user may be given access to applications designated as public without entering a security code.

FIG. 5 is a flow diagram of an exemplary process 500 for determining a group of applications for display on a device. In the exemplary process 500, a published application on a device is identified (502). The public applications are grouped based on association with different contexts (504). The context may be any factor associated with an application or with a device executing the application that is shared between certain applications. Examples of context may be geographic location, application type, current activity associated with a user of a device executing the application, demographic or personal information associated with the user, or other attributes associated with different applications on the device. Thus, applications associated with the same context may be grouped together.

A request to display a published application is received (506). A context associated with a user of the device is determined (508). The determination of the context associated with the user may include determining a geographic location of the user or a current activity of the user based on various signals received on the device. Based on the context, a particular group of published applications is generated for display (510).

The above procedure is merely an example. Various combinations of the above processes are possible.

Exemplary device architecture

Fig. 6 is a block diagram 600 of an example implementation of the mobile device 100 of fig. 1. The mobile device 100 may include a memory interface 602, one or more data processors, image processors, and/or central processing units 604, and a peripheral interface 606. The memory interface 602, the one or more processors 604, and/or the peripherals interface 606 can be separate components or can be integrated in one or more integrated circuits. The various components in the mobile device 100 may be coupled by one or more communication buses or signal lines.

Sensors, devices, and subsystems can be coupled to peripherals interface 606 to facilitate multiple functions. For example, motion sensor 610, light sensor 612, and proximity sensor 614 may be coupled to peripherals interface 606 to facilitate the orientation, lighting, and proximity functions described with reference to fig. 1. Other sensors 616 may also be connected to the peripheral interface 606, such as a GPS receiver, temperature sensor, biosensor, or other sensing device to facilitate related functions.

A camera subsystem 620 and an optical sensor 622, such as a Charge Coupled Device (CCD) or Complementary Metal Oxide Semiconductor (CMOS) optical sensor, may be utilized to facilitate camera functions such as recording photographs and video clips.

Communication functions may be facilitated by one or more wireless communication subsystems 624, which may include radio frequency receivers and transmitters and/or optical (e.g., infrared) receivers and transmitters. The specific design and implementation of the communication subsystem 624 may depend upon the communication network through which the mobile device 100 is intended to operate. For example, mobile device 100 may include a network designed to communicate over a GSM network, GPRS network, EDGE network, 3G network, or4G network, Wi-Fi or WiMax network, Bluetooth^TMA network communications subsystem 624 for network operations. In particular, wireless communication subsystem 624 may include a host protocol such that device 100 may be configured as a base station for other wireless devices.

An audio subsystem 626 may be coupled to a speaker 628 and a microphone 630 to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and telephony functions.

The I/O subsystem 640 may include a touchscreen controller 642 and/or other input controllers 644. The touch screen controller 642 may be coupled to a touch screen 646. The touch screen 646 and touch screen controller 642 may, for example, detect contact and movement or break thereof using any of a variety of touch sensitive technologies including, but not limited to, capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch screen 646.

Other input controllers 644 may be coupled to other input/control devices 648 such as one or more buttons, rocker switches, a thumb wheel, an infrared port, a USB port, and/or a pointing device (such as a stylus). The one or more buttons (not shown) may include up/down buttons for volume control of the speaker 628 and/or the microphone 630.

In one embodiment, pressing the button for a first duration may unlock the touch screen 646; pressing the button for a second duration longer than the first duration may turn power to the mobile device 100 on or off. The user may be able to customize the functionality of one or more of the buttons. The touch screen 646 may also be used, for example, to implement virtual or soft buttons and/or a keyboard.

In some implementations, the mobile device 100 can present recorded audio and/or video files, such as MP3, AAC, and MPEG files. In some implementations, the mobile device 100 can include a mobile device such as an iPod^TMMP3 playerCan be used. Accordingly, the mobile device 100 may include a 36-pin connector that is compatible with the iPod. Other input/output and control devices may also be used.

The memory interface 602 may be coupled to a memory 650. Memory 650 may include high-speed random access memory and/or non-volatile memory, such as one or more magnetic disk storage devices, one or more optical storage devices, and/or flash memory (e.g., NAND, NOR). The memory 650 may store an operating system 652, such as Darwin, RTXC, LINUX, UNIX, OSX, WINDOWS, or an embedded operating system (such as VxWorks). Operating system 652 may include instructions for handling basic system services and for performing hardware-related tasks. In some implementations, the operating system 652 processes time management tasks, including keeping a date and time (e.g., a clock) on the mobile device 100. In some implementations, the operating system 652 can be a kernel (e.g., UNIX kernel).

Memory 650 may also store communication instructions 654 to facilitate communication with one or more additional devices, one or more computers, and/or one or more servers. Memory 650 may include graphical user interface instructions 656 to facilitate graphical user interface processing; sensor processing instructions 658 to facilitate sensor-related processing and functions; phone instructions 660 to facilitate phone-related processes and functions; message instructions 662 to facilitate electronic message related processing and functions; web browsing instructions 664 to facilitate web browsing-related processes and functions; media processing instructions 666 to facilitate media processing-related processes and functions; facilitate GPS and navigation-related processing and instruction-related GPS/navigation instructions 668; camera instructions 670 to facilitate camera-related processing and functions; other software instructions 672 to facilitate other related processes and functions; and/or security instructions 674 that implement the features and processes of fig. 1-5, along with graphical user interface instructions 656.

The memory 650 may also store data including, but not limited to, documents, images, video files, audio files, and other data.

In some implementations, the mobile device 100 includes a positioning system 618. In various embodiments, the positioning system 618 may be provided by a separate device coupled to the mobile device 100 or may be provided internal to the mobile device. In some implementations, the location system 618 can employ location technologies including GPS, cellular grids, URIs, or any other technology for determining the geographic location of a device. In some implementations, the positioning system 618 may employ services provided by positioning services such as, for example, Skyhook Wireless (Skyhook Wireless of Boston, MA) or Rosum Corporation of Mountain View, Calif. (Rosum Corporation of Mountain View, CA). In other implementations, the positioning system 618 may be provided by a compass and an accelerometer using dead reckoning techniques. In such embodiments, the user may occasionally reset the positioning system by marking the presence of the mobile device at a known location (e.g., a landmark or intersection). In still other implementations, the user may enter a set of location coordinates (e.g., latitude, longitude) for the mobile device. For example, the location coordinates may be entered into the phone (e.g., using a virtual keyboard), or selected by touching a point on a map. The location coordinates may also be obtained from other devices by synchronizing or connecting with the other devices (e.g., a car navigation system). In other embodiments, the positioning system 618 may be provided by using one or more locations of known wireless signal sources and wireless signal strengths to provide a current location. The wireless signal source may include an access point and/or a cell tower. Other techniques may be used to determine the current location of the mobile device 100, and other configurations of the positioning system 618 are possible.

Each of the above-mentioned instructions and applications may correspond to a set of instructions for performing one or more of the functions described above. These instructions need not be implemented as separate software programs, procedures or modules. Memory 650 may include additional instructions or fewer instructions. Further, various functions of the mobile device 100 may be implemented in hardware and/or software included in one or more signal processing and/or application specific integrated circuits.

The functional operations described in this specification and other embodiments disclosed may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. The disclosed and other embodiments may be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The term "data processing apparatus" includes all devices, apparatus, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.

A computer program (also known as a program, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that stores other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from and/or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, the disclosed embodiments can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); input from the user may be received in any form, including acoustic, speech, or tactile input.

The disclosed embodiments can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation disclosed herein), or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN") and a wide area network ("WAN"), such as the Internet.

The computing system may include clients and servers. In general, a client and server are remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

While this specification contains many specifics, these should not be construed as limitations on the scope of what may be claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, but rather it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Thus, particular embodiments have been described. Other embodiments are within the scope of the following claims.

Claims (16)

1. A method for accessing an application on a computer system, the method comprising:

designating an application on the computer system for private or public functionality, wherein the computer system has a public mode and a private mode of operation, and wherein the designation is made by the application through an Application Programming Interface (API) of an operating system of the computer system;

enforcing, by the operating system, a security wall for the application when the application is designated for private functionality, wherein enforcing the security wall includes presenting only objects that can be selected to invoke a public application in a public mode until a security input is received; and

in response to receiving the security input, switching from a public mode to a private mode of the computer system and presenting objects that can be selected to invoke the public and private applications when in the private mode.

2. The method of claim 1, wherein the application is specified based on a request received from a user.

3. The method of claim 1, wherein the application is further automatically specified based on at least one of: an application type associated with the application, a time since the application was previously accessed, or a location of the computer system.

4. The method of claim 1, wherein accessing the application comprises: generating for display a visual indicator indicating that the application is available in a public mode of the computer system.

5. The method of claim 4, wherein generating the visual indicator for display comprises: a particular visual indicator is displayed for each application in a group of applications, wherein each application in the group of applications is designated for disclosing functionality.

6. The method of claim 5, wherein the application group is a subset of all applications designated for disclosing functionality, and the displayed application group is displayed based on at least one of: a geographic location of the computer system, a current date or time of day, a context associated with the user, a most recently performed operation by the user, or a degree of importance of information associated with a particular application.

7. The method of claim 1, wherein specifying an application comprises: at least one of a plurality of functions of the application is designated for public functions and a remainder of the plurality of functions of the application is designated for private functions.

8. The method of claim 7, wherein enforcing the security wall comprises: preventing access to the remaining portion of the plurality of functions designated for private functions until a security input is received, and allowing a user to access at least one function of an application designated for public functions without receiving a security input.

9. The method of claim 1, further comprising: automatically designating the application for a private function after a certain period of time has elapsed since the application was previously used.

10. A computer system, comprising:

means for determining that a first function of an application on a mobile device is designated for public functionality and a second function of the application is designated for private functionality, wherein the application is accessible in both a public mode and a private mode of the mobile device and the first function is different from the second function, and wherein the designation is by the application through an Application Programming Interface (API) of an operating system of the mobile device;

means for allowing, by the operating system, a user to interact with a first function of the application in the public mode without receiving a secure input from the user; and

means for enforcing, by the operating system, a security wall for a second function of the application, wherein enforcing the security wall comprises: switching from a public mode of the mobile device to a private mode of the mobile device in response to receiving the security input, and allowing the user to interact with the second function of the application only when in the private mode of the mobile device.

11. The computer system of claim 10, wherein allowing the user to interact with the first function of the application comprises: a second input from the user is required before allowing the user to interact with the application, the second input being different from the security input.

12. The computer system of claim 10, wherein the second functionality of the application comprises a purchase functionality that allows a user to make a purchase through the application.

13. The computer system of claim 10, wherein the first function of the application is automatically determined to be designated for public functions based on a function type associated with the first function, and the second function of the application is automatically determined to be designated for private functions based on a function type associated with the second function.

14. A system for accessing applications on a computer system, comprising:

means for designating an application on the computer system for public or private functionality, wherein the computer system has a public mode and a private mode of operation, and wherein the designation is made by the application through an Application Programming Interface (API) of an operating system of the computer system;

means for enforcing, by the operating system, a security wall for the application when the application is designated for private functionality, wherein enforcing the security wall includes presenting only objects that can be selected to invoke a public application in a public mode until a security input is received; and

means for switching from a public mode to a private mode of the computer system and presenting objects that can be selected to invoke public and private applications when in the private mode in response to receiving the security input.

15. The system of claim 14, wherein providing access to the application comprises: a particular visual indicator is displayed for each application in a group of applications, wherein each application in the group of applications is designated for disclosing functionality.

16. The system of claim 15, wherein the application group is a subset of all applications designated for public functionality, and the displayed application group is displayed based on at least one of: a geographic location of the computer system, a current date or time of day, a context associated with the user, a most recently performed operation by the user, or a degree of importance of information associated with a particular application.