HK1116872B - Upload security scheme - Google Patents

Description

Upload security scheme

Reference to the prior application

This application claims priority from U.S. patent application No. 10/934,645 entitled "load SECURITY procedure" filed on 9/2/2004 and the following U.S. provisional applications filed on 11/10/2003, which are incorporated herein by reference in their entirety: 60/518,898 entitled "Back BUTTON IN Mobile APPLICATION"; 60/518,858 entitled "NAVIGATION PATTERN ON A DIRECTORY TREE"; 60/518,857 entitled "BACKUP AND RESTORE IN Mobile APPLICATIONS"; 60/518,897 entitled "UPLOAD SECURITY SCHEME".

Technical Field

The present invention relates generally to wireless mobile devices, and more particularly to applications that provide upload security. One such application is a mobile photo application.

Background

Mobile-friendly technologies are being developed to provide rich multimedia environments and enhance the experience for wireless device users. One result of this development is the clear proximity between the wireless world and the internet domain, and the advent of wireless devices with multimedia capabilities. Recent versions of mobile wireless devices, such as digital mobile phones, pagers, Personal Digital Assistants (PDAs), cell phones, and any other wireless terminal, have multimedia capabilities, including being able to retrieve email, push and pull information via the internet.

One implementation of these capabilities allows sharing of content such as photos. Also, methods of managing such activities are needed. One reason for controlling content sharing is security. Generally, the need for security is due to unauthorized access to the data. In the case of content sharing, the need for security comes from the additional risk of unauthorized enforcement, where the sender (mobile user) uploads content that is unwanted or too much by the recipient without first obtaining permission from the recipient. The present invention thus provides a possible approach for addressing the risks associated with unauthorized enforcement activities.

Disclosure of Invention

The present invention is based in part on the following observations: there is a need for upload security and upload security can be improved, as described below. Thus, upload security concepts are implemented to allow content sharing without imposing undesirable or excessively frequent uploads.

For the purposes of the present invention, as embodied and broadly described herein, a method, computer-readable medium, and system are proposed as possible implementations of upload security concepts. These implementations generally include a server linked with a plurality of mobile devices with communication links. In the following example, the mobile device is typically a wireless device, such as a wireless camera phone, and the content is photo data (or just one or more photos).

In one embodiment, a method for providing upload security includes identifying a mobile device used by a sender of an upload message intended for a user in response to a server receiving the upload message from the mobile device via a network. The method also includes accessing, in the server, opt-in parameters predetermined by the user, determining whether an identification of the mobile device used by the sender is included in the opt-in parameters, and if so, allowing the content from the upload message to be uploaded to an account associated with the user. Otherwise the upload is blocked. The opt-in parameters include an identification of the mobile device authorized by the user to upload data to an account associated with the user on the server. Further optionally, the opt-in parameter includes a limit number of upload messages authorized by the user during a given time period, wherein the method further comprises determining whether the upload message exceeds the limit number of senders such that it is not permitted by the user and thus the upload is blocked. If the upload is blocked, the method optionally includes rerouting the upload message to the user's standard email address.

In this embodiment, the network includes a wireless carrier network and a networking service that provides security screening of the upload message before it reaches the server based on the identity of the wireless carrier network. The identification of the wireless carrier network includes an Internet Protocol (IP) address. The identity of the radiotelephone is the telephone number assigned to the radiotelephone by the carrier of the mobile operator network. In this example, the IP address is combined with the identification of the mobile device in the upload message, such that the method further comprises parsing the upload message to obtain the IP address and the identification of the mobile device.

Further, in the present method, the sender uses e-mail as a transmission mechanism for the upload message. The sender identifies to the server the user to whom the upload message is intended by indicating the user's email address. The server then correlates the user's email address with the account associated with the user. If capabilities exist, the method further includes establishing a communication link from the sender's mobile device to the user to prompt the user to indicate on the user's mobile device or personal computer whether the user wants to add the sender's mobile device identification to the opt-in parameters (to allow uploading).

The above-described method may be embodied in a computer-readable medium, wherein the computer-readable medium contains a computer program having program code for providing upload security. In this implementation, the computer program is divided into portions, one portion on the server side, a second portion on the client side, and a third portion at the networking service. A system for providing upload security includes a server, a plurality of mobile devices, and generally also a wireless network, the internet, and a gateway through which the server communicates with the mobile devices. The server has a processor and memory that implement a server-side program that is part of a computer application. The server program comprises program code for causing a processor in the server to perform the aforementioned identifying, accessing, determining and authorizing steps in response to the server receiving an upload message from such a mobile device.

As can be appreciated from these examples, by introducing upload security capabilities to the system, the present invention makes content sharing more useful, more secure, and more user friendly. Those of ordinary skill in the art will recognize that there are many other variations and modifications of the present invention that are possible in light of the above teachings.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description, help explain the principles of the invention. Wherever convenient, the same or similar reference numbers or designations are used throughout the drawings to refer to the same or like elements.

Fig. 1 illustrates a wireless interconnection model that utilizes one of many types of available bearer networks.

Fig. 1A illustrates another model of interaction between a third generation mobile communications (3G) enabled mobile device and a server, as well as other devices, via a carrier network.

Fig. 2 shows a mobile phone having features associated with the present invention.

FIG. 3 illustrates a user arriving at Yahoo! And (4) after photo logs in the page.

Fig. 4A-4D illustrate flow diagrams for PC-based and mobile-based registration and application purchase, respectively.

Fig. 5 shows the upload opt-in process.

Fig. 6A and 6B show screen flows of an online album and a mobile album, respectively.

Part (i) and part (ii) of fig. 6C describe the establishment of a mobile photo album slide show favorite.

FIG. 6D illustrates a flow chart for photo viewing, sharing, and saving.

FIG. 6E shows the flow of restoring the mobile album from the server backup.

Fig. 7 provides a simplified diagram to illustrate the return button feature.

Fig. 8A-8C illustrate details of an upload security scheme. The diagram in FIG. 8A illustrates the location of various system components in an upload security scheme, and the flow diagrams in FIGS. 8B-C illustrate various aspects of the process.

Detailed Description

The present invention contemplates upload security in mobile applications and implementation of this concept. One such application is a mobile photo, an example of which is called Yahoo! Photos^TMThe use of (1). Yahoo! And Yahoo! Photos are all Yahoo! A trademark of Sunnyvale, California, inc. Any other trademark is the property of their respective holders.

Although it may be implemented in a variety of applications, for purposes of clarity and illustration, it is referred to herein as Yahoo! The methods contemplated by the present invention are described in the context of Photos applications. The server side of the application is "Server Yahoo! Photos "and the client side of the application is the mobile client application, or" client Yahoo! Photos ". Client applications are generally considered downloadable applications; namely, J2ME^TM(Java, available from Sun Microsystsaems, Inc.)^TM2 platform, Micro Edition), Yahoo! Photos^TMOr any other application that may be downloaded to the mobile device. In the example herein, the client Yahoo! Photos runs on mobile devices, more specifically, mobile camera phones.

Wireless communication environment

A. Wireless communication protocol

Wireless protocols, as a standard governing data communications between wireless devices and the internet, take advantage of and support the enhanced capabilities of modern mobile wireless devices and internet content technologies. Hypertext transfer protocol (HTTP) is a commonly used standard, and other standards include Wireless Application Protocol (WAP), M-services, i-Mode, and Web tailoring. WAP appears to provide an appropriate framework for content sharing, although other protocols may be used. Accordingly, the use of standards such as WAP is suitable for the purposes of the present invention and will be discussed in detail below.

WAP is employed to build on existing internet standards and protocols applicable to wireless communication networks and addresses the unique characteristics of mobile wireless devices (with limited computing, storage, display, user interface and power). WAP is a specification suite that defines a set of protocols for the presentation and delivery of wireless information and telephony services on mobile wireless devices. The WAP service provides information access and delivery to WAP-enabled devices. WAP is designed to enable users to easily and instantly access information and interactive services. Thus, interoperability between WAP-enabled devices can be achieved through any WAP-compliant infrastructure to deliver information and accept transactions and queries in a timely manner.

WAP may be built on any operating system, including PalmOS, EPOC, Windows CE, FLEXOS, OS/9, JAVA OS, and the like. Since WAP is designed to be extensible to new networks as networks evolve, independent of the air interface, allowing for the development of a generic solution that enables bearer independence and inter-heterogeneous networks.

The term "WAP" is commonly used to refer to a Wireless Application Environment (WAE), although WAE includes WAP protocols and technology suites. The WAE provides a rich application environment that enables the delivery of information and interactive services to mobile wireless devices. An important aspect of the WAE is the WAP stack, i.e. the radio protocol layer, as illustrated by way of example in fig. 1. At the bottom of the WAP stack 11 is the network layer, above which are the transport layer, security layer, transaction layer and session layer.

Briefly, the network protocol layer supports network interface definitions, governing the interface with the wireless service provider's network (radio bearer), such as Short Message Service (SMS), Code Division Multiple Access (CDMA), Cellular Digital Packet Data (CDPD), General Packet Radio Service (GPRS), High Speed Circuit Switched Data (HSCSD), third generation mobile communications (3G), GSM (global system for mobile communications), and Unstructured Supplementary Service Data (USSD) channels. The wireless transport layer supports Wireless Datagram Protocol (WDP) and, when operating above the IP (internet protocol) network layer, WDP is replaced with user datagram protocol/IP (UDP/IP). WDP provides datagram services to upper protocol layers and transparent communication over lower-layer bearer network services. In other words, WDP provides a generic interface to the bearer wireless network to the upper protocol layers and provides the ability to operate independently of the bearer wireless network type. Wireless Transport Layer Security (WTLS) provides a secure transport service to maintain privacy, authentication, and data integrity of the transport service below this layer, as well as the ability to create and terminate secure connections between communication applications. The transaction protocol (WTP) layer provides transaction-oriented protocols for WAP datagram services, including, for example, request-response transactions. The Wireless Session Protocol (WSP) layer provides HTTP/1.1 functions and features such as session suspend/resume. The WSP provides an interface to the upper application layer of the WAE to connected and connectionless services operating at the transaction protocol and datagram transport layers, respectively.

The WAE (i.e., wireless application environment) is also structured with a Wireless Markup Language (WML) micro-browser, a WML script virtual machine, a WML script standard library, a Wireless Telephony Application Interface (TAI), and a WAP content type. WAP microbrowsers, also known as "WAP browsers," facilitate interaction between WAP/Web applications and WAP-enabled devices. The microbrowser is a tag-based wireless browser application that supports Wireless Markup Language (WML) and extensible transport hyperlink markup language (XTHML). The microbrowser uses a "card" metaphor (metaphor) for user interface, where user interactions are broken up into cards. The WAP card metaphor provides a common interface to which all applications can conform, much like the desktop metaphor in PCs. The micro-browser supports user actions defined at the tree level (deck, cards, and select and link options, i.e., ACCEPT, PREV, etc.) and default tasks (PREV, NOOP, etc.). For example, the deck is divided into navigation cards, variable cards, and input element cards. The navigation card is formed as a script encapsulated with a "card" tag. The following card examples include an interaction type (DOTYPE ═ ACCEPT ") and a link (GO URL ═ # eCARD).

B. Wireless communication infrastructure

Fig. 1 illustrates a wireless interconnection model 10 that utilizes one of many types of available bearer networks 12. It is assumed that the wireless mobile device 100 shown has sufficient local memory and internet access capability to allow a user to download programs from the server 18 over the internet 16 (and any other network, e.g., LAN, WAN, or ethernet) and store them in local memory. Thus, wireless subscribers can gain rapid access to content in these or other servers via the internet through various downloadable applications. Note that the server 18 shown may be the origin of the downloadable program, as well as the origin or destination of the content; although both the program and the content may originate from and be destined for different servers. For purposes of this illustration, web server 18 is Yahoo! The sources of the photo client side applications and are the source and destination of content, especially Photos (image data). Using downloaded programs (e.g., Yahoo | Photos) and multimedia capabilities (including the ability to get email via the internet, push and pull information), network operators (or more generally, service providers) add valuable goods beyond voice or text offerings.

Indeed, with this capability, users may capture photographic images in their mobile devices, store and manipulate the captured images, and upload data of the captured images to a server (e.g., server 18). Thus, the server 18 acts as a repository for data of photo images, and users can download data of previously captured photo images from the server to their mobile devices, and store and manipulate such images. Photos residing on one mobile device may be shared with another device via the server 18 and communication networks 12 and 16.

In the wireless interconnection model, download Yahoo! The mobile phone of the photo client side program is WAP enabled. As shown in fig. 1, the WAP-enabled device 10 supports the WAP protocol and the server 18 typically supports the www (world wide web) protocol. In particular, the wireless application environment at the mobile device side 11 includes a micro-browser, a WAP protocol suite at the network across the session layer, and a downloadable (client side) Yahoo! Photos application. A micro-browser defines how WML documents and WML script applets should be interpreted and presented to a mobile device user. The WTA (wireless telephony application) functionality of the microbrowser provides call control, phone book access and messaging within the WML script applet to allow selective call forwarding or other secure telephony. The wireless application environment at the server side 13 includes the server side Yahoo! Photos, and the standard web browser and WWW protocol stacks (HTTP and TCP/IP).

To enable web-based access to content, service providers deploy wireless data through the carrier network 12 while controlling data communications to their subscribers and tracking billable activity. In general, the role of the gateway 14 is to track subscriber activity, control access, and additionally act as a proxy for the mobile device 100 on the one hand and the server 18 on the other hand. The gateway 14 is built based on standard web proxy technology, implemented to interconnect services provided by wireless service providers to the HTTP protocol to permit access to content on the wired internet.

One model of interaction between WAP-enabled devices, WAP-enabled proxies/gateways, and servers is the hypertext transfer protocol (HTTP)1.1 response/request transaction, where HTTP1.1 is configured for the wireless environment. The gateways (13 and 14) convert the requests of the WAP protocol into those of the WWW protocol and vice versa; convert WML (/ HTML) documents to HTML (/ WML), resolve domain names in URLs, and provide control points to manage access. From a WAP-enabled gateway with an encoder/decoder, a URL request or WML document (possibly in encoded form) may be sent after encoding/decoding to add security to the user interaction. Note that unlike the flat structure of an HTML document, a WML document is divided into a set of user interaction units, i.e., a set of cards. Each user interaction unit is a card (or a page) and the user can navigate between cards in one or more WML documents.

Another model of interaction between a WAP-enabled device, a WAP-enabled proxy/gateway and a server is HTTP response/request transactions (a protocol running on top of the TCP/IP protocol suite of the internet). This model is applicable to the newer WAP 2.0 (with a protocol stack not shown in fig. 1). Unlike the WAP stack 11 described and shown above, the WAP 2.0 stack includes IP, TCP (transmission control protocol), TLS, HTTP and WAE layers on top of the network layer (all configured for the wireless environment). For example, the wireless profile of the TLS protocol will permit interoperability of secure transactions.

Yet another model of interaction between a third generation (3G) mobile communication enabled mobile device and a server or other device via a carrier network is shown in fig. 1A. As shown, the 3G terminal supports higher speed, wider bandwidth wireless cellular service communications based on various technologies, including wideband code division multiple access (W-CDMA), General Packet Radio Service (GPRS), global system for mobile communications (GSM), enhanced data rates for global evolution (EDGE), universal threat management system (UMTS), and High Speed Circuit Switched Data (HSCSD). The 3G terminal has a cordless connection for local short-range communication. The communication protocols in 3G terminals are comparable to the Open Systems Interconnection (OSI) protocols layered in the OSI stack.

These protocols support a variety of services including web browsing, Short Message Service (SMS), Multimedia Messaging Service (MMS), e-mailing, M-commerce, real-time video, and pre-paid. For example, MMS is a store and forward messaging service that is capable of adding multimedia elements to SMS, including images, text, audio clips, and video clips. MMS is synchronized on a common timeline, rather than being discrete as email and SMS; it resembles a presentation layer on an email and looks like a slide with images. On a compatible phone, an MMS message will appear with a new message alert. The picture message will open on the screen, the text will appear under the image, and the sound will automatically start playing.

Such as Yahoo! Downloadable applications such as Photos and network games are similarly supported in 3G terminals and interact with services such as MMS. The originator can easily create a multimedia message, which can be done with a built-in or additional camera, or can use images and sounds previously stored in the phone (and possibly downloaded from the web site). However, for simplicity, the following description assumes that the mobile device is a WAP-enabled camera phone for downloading content such as Yahoo! Photo applications such as Photos.

Fig. 2 illustrates a mobile phone 100, which mobile phone 100 is not necessarily associated with any particular manufacturer, but has features suitable for the purposes of the present invention. For example, to accommodate the Yahoo! The photo application, mobile phone 100, has a camera feature with a camera 112 exposed to capture images. The mobile phone 100 also has a 5-point navigation key (also referred to as a game key) 114 that has left, right, up, down, and select (or "OK") functions, substantially emulating the operation of a mouse. The main menu button 116 activates an on-screen menu display and the main OK button 118 activates a menu selection. The "back" button 110 is shown as a hardware key, the location of which is merely exemplary herein. That is, the physical placement of the "back" button is device dependent, where it is contemplated that the buttons may be arranged differently on different devices. The "back" soft key may also implement the "back" function of the WAP browser, which means that it may appear as an icon or menu item on the screen of the mobile phone.

As shown in FIG. 2, Yahoo! The telephone 100 supports wireless cellular service communications based on various technologies, such as GPRS and GSM. The device is configured to support the WAP communication protocol (at all layers of the WAP stack). Various services shown as supported by these protocols include web browsing, SMS, MMS, email, M-commerce, real-time video, and prepaid. Downloadable programs that are shown to interact with such services include network games and Yahoo! Photos.

The functionality of the mobile device is preferably utilized such as J2ME^TMPlatform implementation, such as a platformAre customized for a variety of embedded devices, including mobile phones. J2ME^TMThe platform includes a set of standard Java APIs (application programming interfaces) and provides a user interface, a security model, a built-in network protocol (e.g., WAP, as shown in fig. 1), and supports both connected and disconnected applications (Yahoo | Photos is a networked application).

Using J2ME^TMAnd the platform writes applications for various devices simultaneously. Applications that adjust the local capabilities of each device are then dynamically downloaded. J2ME^TMThe platform defines the configuration, configuration files and optional packages as elements for building a complete Java runtime environment. The configuration includes a minimal set of virtual machines and class libraries and provides basic functionality to a specific range of devices sharing similar characteristics. Current configurations include Connection Limited Device Configurations (CLDC) for devices with limited memory and processing capabilities (e.g., mobile phones, two-way pagers, and PDAs) and Connection Device Configurations (CDC) for devices with better memory, processing, and network bandwidth capabilities (e.g., TV set-top boxes, residential gateways, in-vehicle telematics systems, and high-end PDAs). However, in order to provide a complete runtime environment for a particular device class, these configurations must be combined with a set of high-level APIs or configuration files that further define the application lifecycle model, access to device-specific properties, and user interface.

One example of a profile is a Mobile Information Device Profile (MIDP), which is designed for use with mobile phones and entry level PDAs. MIDP provides core application functions required by mobile applications, including user interface, network connectivity, local data storage, and application management. J2ME can be further extended by combining various optional packages and their corresponding profiles^TMTo meet specific market requirements, e.g. Bluetooth^TMWeb services, wireless messaging, multimedia, and database connectivity.

Mobile Yahoo! Upload security in Photos contextProperty of (2)

Note that the examples herein focus on camera phones, but the principles of the present invention are not limited to camera phones. Any telephone or other wireless mobile device may implement variations of the present invention. When the mobile device is a smartphone, it is possible to both download applications and implement upload security schemes, even where communications with service providers may differ in characteristics.

It should be noted that although the manufacturer provides Yahoo!enabled with camera functionality (i.e., functionality for capturing images and saving, displaying, manipulating, sending and receiving image data)! The telephone 100, but the camera function is independent of the Yahoo | camera function! Photos program. That is, the data for the captured image resides in the Yahoo!of the mobile phone! External to the Photos environment until the time of the transfer by first uploading the data to Yahoo! The server then downloads it to a local (mobile) Yahoo! Photos album, and thus import to Yahoo! As will be explained later, up to a point in the photo environment.

On a mobile device, various client applications are provided to the user on a default launch screen or main menu screen, or on a manufacturer-installed virtual vending machine screen. Other selection items include, for example, menu items for setting sounds. These launch and sell screens show a menu with a list (or icons) of applications that the user can obtain by following the installation process. The menu provides links to various service web sites, including, for example, Yahoo! Photos site. Of course, these links are URLs (Uniform resource locators), i.e., world Wide Web addresses of sites on the Internet, and are available in Yahoo! At least one such menu item is for downloading Yahoo! Linking of photo applications.

FIG. 3 illustrates the flow after the user arrives at the mobile application site, which in this example is Yahoo! Photos landing page. The URL of the landing page is obtained from the promotional web page or from a bookmark (or favorites) via a link through a web search. The flow chart is shown asOriginating on the user's PC (personal computer), starting with program information presented at a landing page 302 on the PC display. Based on whether the user has purchased Yahoo! The photo programs, the contents 303 and 304 of the landing page, are presented to show the options available to the user. For example, the landing page presents the user with Yahoo! Photo program name with "how to get it now" 304 option, as well as upload information 306a, flash demo 306b, and pricing information 306d, such as "$ 2.99 monthly". To purchase an application, a user purchases the application under the application name Yahoo! Photos or click on "how to get it now". In registration 400_A-DThereafter, a query (e.g., "would you like to buy it for $ 2.99. The user is then prompted to set up an upload opt-in parameter 500 for upload security, as will be described later.

If the user accepts the bid to purchase the application, the order is confirmed 322 and the application is then downloaded into the mobile phone, becoming resident on the mobile phone. Fig. 4A-4D show flow charts for PC-based and mobile-based registration and purchase, respectively.

Incidentally, as shown in fig. 3 and 4A, if the user confirms the acceptance, assuming that the user has an account on the server that has been previously logged in, the user is prompted to provide the telephone number of the mobile phone. Using the phone number, the server sends a short message embedded with a link to the mobile phone, causing the mobile phone to vibrate or otherwise notify the user of the message requesting confirmation of the purchase 326. With this confirmation 426, the server starts sending the program to the mobile phone.

As shown in fig. 4B and 4C, registration may be initiated on a PC or on a mobile phone. In a PC-based registration process, once the list of compatible phones is viewed 450 and the phones are deemed compatible, registration may proceed from the user entering a 10 digit phone number 452. The service provider dials the 10 digit phone number and requests confirmation 456 from the user via the mobile phone. The user is also prompted to follow the purchase instructions 460 or follow the link to the vending machine 458. Once download has occurred, Yahoo! The photo client home page 268 is presented on the mobile screen. Alternatively, rather than indirectly via a PC, a purchase may be made directly via a mobile phone, such as the Yahoo! Photos, as shown in FIG. 4C. That is, the registration process from the mobile phone is initiated from a menu page (e.g., Yahoo | Home page 470 or 472). In addition, link 462 to the (virtual) vending machine page, download page 464, confirmation page 466, and home page 468 are similar to those in FIG. 4B.

FIG. 4D shows the flow of the first purchase. As can be seen from the figure, the purchase may be initiated from the PC or mobile phone, starting at the respective landing page. Note that in a PC-based process, the landing page 480 is obtained via a standard browser. In a mobile-based process, the landing page 482 presents a WAP site, assuming that the mobile phone is WAP-compliant and uses a micro-browser to link to this and subsequent pages. Then, for the first purchaser, product information (i.e., the Yahoo | Photos application) is imported along with the price and a link 486 to terms of use and buy/deselect buttons (icons). Download activation 488, process update 490, and confirmation 492 are provided at the same time as the application is downloaded. The application is then ready to launch upon exiting the microbrowser 494. After being invoked, Yahoo! The Photos home page 498 is displayed.

To achieve upload security, the registration and purchase process of FIG. 3 includes setting the upload opt-in 500 parameter, as described above. Fig. 5 shows an upload opt-in process 500 for setting the user's upload parameters that establish the user's upload preferences (once the upload opt-in module is invoked 502). Preferably, at the PC, the user is prompted to enter the telephone number of the service provider-published mobile phone that the user authorized to upload their photos to the user's Yahoo! Photo accounts (on the server) 506. The user is additionally prompted to enter one or more emails for the user, such as < user reg. # messaging.springpcs > or other emails, such as < jsmithprintpcs.com >, by which photos are uploaded to the user's account 506. The email is added to the approved list. Although not shown, the user may also pre-select the maximum number of upload messages the user wishes to receive during the day (or any other predetermined period of time). At the end of the selection process, the user is prompted to confirm 508 the entry before it is stored in the database for future reference.

Once Yahoo! After the photo programs reside on the mobile phone, the programs can be called from a landing page or menu page (using menu buttons on the phone to call up a menu, or using a default menu if Yahoo | photo is presented as one of the default menu options). To Yahoo! Invocation of the photo application allows the user to access and manipulate the user's mobile and online albums in the user account, and so on. Fig. 6A and 6B show screen flows for an online album and a mobile album, respectively.

To Yahoo! The invocation of Photos prompts the program to display a "Home" page 2.0 with two main options: mobile photo albums and online photo albums (as shown in fig. 6A and 6B). A mobile album is an album of photos stored locally on a mobile phone, which eliminates the need for the user to get them outside over a network. An online album is an album of photos stored in a user's account on a server. As previously described, the photographic image may be created by Yahoo! Mobile phone capture and manipulation outside the Photos environment. These photo images are not available at the mobile or online album until the photos are uploaded to the server, stored in the online album, and then downloaded to the server (either selectively or in batches), or vice versa. Thus, selecting "online album" allows the user to access and manipulate photo images that have been uploaded from the user's PC or mobile phone to the server and stored in the online album. Similarly, selecting "mobile album" allows the user to access and manipulate photo images that have been downloaded into the mobile album from the server.

Then, if from Yahoo! The photo client program's "home" page (2.0) selects the "online album" option, as shown in FIG. 6A, which prompts the program to display the next page, which is the "sign-in" page (1.0). This requires the user to follow a login process, which typically includes providing the Yahoo! An ID and a user password. The login process will bring up the user's account and associate the account with the user's online photo album, and so on. That is, the login process allows the user to access his account via the internet (and other proprietary networks, if applicable).

The next page is the "my online album" page (2.1). For a particular user, the online album page lists the photo album names available to the named user associated with the user's account. Of course, only the albums on the server are listed, and if the selected album is empty, the next page will display an indication of the effect (i.e., "this album is currently empty" at page 2.1.6). Alternatively, if the album is not empty, selecting the album will bring up the next page, i.e., the photo list page (2.1.2) of the album. In the "photo list" page, a photo may be selected to download the photo from the server onto the mobile phone. In addition, the selected photo may be opened, or other actions related to the photo may be invoked. Other actions are presented in a menu that is shown on the screen as a drop down menu, a pop up menu, or a menu superimposed on any part of the current page (in this example, the menu is shown as a drop down menu).

Such a menu (hereinafter referred to as a "photo options menu") provides a number of selection items, each of which represents an action, including: "save to mobile", "email photo", "screen saver", "thumbnail", "online albums", and "home". Each selection brings up a page corresponding to the selected action item. Two of these action items have been discussed above: "home" and "online album". Selecting the home page will guide the user back to the home page (2.0), while selecting the online album will guide the user to the aforementioned "myonline albums" page (2.1).

Selecting "thumbs" brings up "photo thumbnails" page 2.1.1, which shows a thumbnail of a group of photo images from the selected album. Note that the number of groups of photo thumbnails downloaded from the server depends on the memory size of the mobile phone (or any device used). With this feature, the user can then browse the thumbnails of all the groups of photos in the album. Groups of thumbnails of photo images in the album are each loaded from a server. The user can then move back and forth (scroll back and forth) between these images and select any one of the photos in the "thumbs" page. The selected thumbnail image will be enlarged in the next page ("onlinethoto" page (2.1.3)).

As can be seen, each of the pages "photo list" (2.1.2), "photo thumbs" (2.1.1), and "online photo" (2.1.3) includes a photo options menu feature. In these action items, when "save to mobile" is called from the "photo list" page, "photo thumbs" page, or "online photo" page, the selected photo image (previously downloaded from the server) is caused to be saved into the mobile album on the mobile phone. In this case, an "added to mobile" page (2.1.7) is called out to show the photograph being saved, and an indication is given that the saving is complete.

When the "email photo" action is invoked, the "share as email" (2.1.5) page appears. The page shows the photo selected to be emailed and prompts the user for the address of the email. In this implementation, the addresses of many recently used emails are provided. Incidentally, "email" is only one transport mechanism that has recently been used to send photos from camera phones. Other transport mechanisms may also be developed and employed for such applications. Then, after the photo is e-mailed from the mobile phone to the selected e-mail address, a pop-up message indicates that the e-mail has been sent, or if it fails to send, that an error has occurred. For example, if the user is not authorized to upload photos to the selected email, the transmission will fail. This error message is a product of the upload security scheme contemplated by the present invention, as described in Yahoo! Implemented in photo applications. More details regarding upload security will be provided below with reference to fig. 8 and 9.

When the "screen saver" action is invoked, the selected photo will be used to fill the screen when the phone is idle, standby, or on. The "screen saver" option is associated with the screen saver page (2.1.4) which shows the selected photo and requires the user to select "OK" or "cancel" to add the photo to the screen saver photo directory. A pop-up message then indicates the status of the photo download.

The photo option menu may be used to return to the mobile album via the "home" page using the "home" option described above. Another method to go to a mobile album or any other previous page is to use the "back" button to do so with a "back" action, as will be explained later. In addition, as described above, when Yahoo!is called from the login/menu page! Photo application, "home" page (2.0) presents "mobile album" as a choice. Thus, the mobile album can be accessed directly via the "home" page.

The mobile album screen flow shown in fig. 6B begins with the "home" page (2.0) and selection of the mobile album brings up the "mobile photo" list page (3.1.1). The page presents two action menus: "open" and "action". Thus, "open" or "action" may be selected upon selection of any of the listed photos. As previously described, when "open" is selected, the photo is shown on the screen in the "photo thumbs" page (3.1.2). When "action" is selected, a move photo action menu is provided. The menu includes action items such as "slide show", "move", "delete photo", "delete all", "movies", and "home".

The thumbnail feature associated with the "photo thumbs" page (3.1.2) works as described above with reference to the online album, except for the photos that are located locally (at the mobile album). The photo selected on the mobile "photos" page can be zoomed in, as shown on the next "mobile photo" page (3.1.3). The menus for "photo thumbs" and "mobile photo" include a subset of the aforementioned mobile photo action menus.

When a slide show is called from such a menu, a "mobile slide show" page appears. While this feature is activated, the slide show will scroll through the mobile album photos, displaying each photo for a period of time. The slide show will continue until the user selects "stop" at the bottom of the page. If the user selects "actions," the slide show menu gives the user the option of: "pause", "show", "normal", and "fast". Selecting the "pause" option for pausing the slide show; "slow" will slow the slide show; "speed" will speed up the slide show; normal will cause the slide show to be at normal speed. (parts (i) and (ii) of FIG. 6C describe the creation of favorites for a mobile photo album slide show; part (i) describes the process in the mobile device, and part (ii) describes the process originating at the PC).

As further shown in fig. 6B, a "move" page appears (3.2.1) when a "move" action (also referred to as a "reorder" action) is selected from any of the 3 pages (3.1.1, 3.1.2, and 3.1.3). In this page, the program displays a set of photos (thumbnails) and the user can rearrange the photos using the 5-point navigation key and can also choose to drop or save the photos (FIG. 6D shows a flow chart for viewing, sharing, and saving the photos). When the "delete" or "delete all" action is selected, the user will be able to select the delete or cancel delete action (as shown by pages 3.2.5 and 3.2.4). The "delete" page shows the photos selected for deletion, which allows the user to change ideas. When all photos are deleted, or when the mobile album is initially empty, a "mobile album empty" page (3.1.4) is displayed. This allows the user to select the main page, or to select a reply to any one of the queries, e.g., "where are my photos? (where do my photos)? (what is the mobile album). Selecting the latter will bring up an "about" page (3.1.4.1), and pressing "OK" in that page will provide the user with access to the online album. Selecting the former calls up a "restore album" page 3.1.4.2. The "restore" function will be described in more detail below.

Note that when the user logs in, the server associates the user's identification with its history record so that the application can record (backup) the photo in the server each time the user saves it to the mobile album. The history record acts as a backup, allowing for the creation of a backup in the Yahoo! The photo program is deleted from the memory of the mobile phone for any reason and the user restores his photo album if he reloads the program. This history feature is useful to reduce navigation for restoring the mobile album, as the server maintains this information in the user's client account.

It is important to note, though, that in Yahoo! The history feature is described in the context of the photo program, but it is useful in any mobile device application where a backup is required. Thus, although this feature is directed to Yahoo! Photos applications, but may also be implemented more generally for other applications.

In Yahoo! In the photo context, the server "remembers" each photo from the user's online album that was saved to the mobile album. Preferably, since the page round trip path is not predictable, the history is accurately and completely recorded. This may be accomplished by associating the user's Yahoo! The ID is implemented in association with the user's history on the server, which records all the photos the user saved to the mobile album. Furthermore, since each mobile telephone device is different and a user may have more than one device, in principle each device may have its own different history. However, it may also be arranged to have the user's Yahoo!when the user first establishes or later updates his account! The ID is associated with a plurality of mobile phones and after logging in, the user can access his history from any of these mobile phones. Thus, in Yahoo! In the case where the photo program is not known for what reason to delete or the Photos in the mobile album are deleted for some reason, the history provides a backup of the mobile album for restoring the album.

To do so, after the user reloads the application, the application will ask the user whether to restore any of the mobile album photos. That is, when the user selects the query "where are my lights? "(in page 3.1.4)," restore album "page is displayed (3.1.4.2). This page, like the previous page (3.1.4), allows the user to go to the "home" page (2.0) and, this time, via "OK", allows the user to go to the next mobile "restore album" page (3.1.4.2.1) to obtain a historical photo download list (of photos previously downloaded to the mobile phone).

FIG. 6E illustrates the flow of restoring the mobile album from the server backup in more detail. Specifically, after passing through the "home" and "mobile album empty" pages (2.0 and 3.1.4), the user arrives at the "restore album" page (3.1.4.2). After selecting the "OK" option, if the user is recorded, Yahoo! The photo server responds with a download history list of Photos (steps 33, 35). The response prompts the mobile device to bring up a "restore album" page (3.1.4.2.1) with a download history list of the last 20 (say) photos that have been added to the mobile album. From this history list, the photos may be picked (see, e.g., a selection box) and then restored to the mobile album using the save/cancel menu option. The selected photos are then downloaded from the server in batches (step 37). The user may then access the mobile album via the "mobile album" page (3.1.1).

Note that the pages shown in FIGS. 6A-6E and discussed herein are exemplary, rather than exhaustive, and do not necessarily include information such as Yahoo! Photo applications like photo apply all possible pages (or user interaction cards) presented. Further, the reference numbers (call-out numbers) generally refer to the pages themselves, and not to any portion of their content. Similar pages appear in different figures, with the same reference number, e.g., home page 2.0, as appropriate, although their respective contents may vary slightly.

As for navigation through pages on a mobile phone, the pages may be passed forward as described above, or backward using a "back button" feature. FIG. 7 provides a simplified diagram to illustrate the "back button" feature. As can be seen, the "back a level" mode allows for one level to be passed in reverse order in the hierarchy each time the "back" button is touch activated or clicked (hereinafter "clicked"). The "back in sequence" mode allows the sequence to return back one page each time the "back" button is pressed. For example, in a return to one level mode, returning one level causes the application to go up one level from the photo page (e.g., 6) to the photo list page (3); then from the page further up to the album list page (2) and further up to the main page (1). It can also be seen in this example that the sequential return mode acts to move the application from the current photo page (6) to the previous photo page (5) when the return button is touched, rather than up one level to (3). Additional activations of the back button will pass through all pages in reverse order.

There is no difference in using the "back button" feature in the online album or mobile album portion of the application. These principles apply equally to both cases. Either way, the steps (pages passed) are remembered and they may be recorded on the server side, locally, or both.

Has been faced above Yahoo! Photos application is described in its overview, now returning again to upload security, in Yahoo! This scheme is described in more detail in the context of Photos. As previously mentioned, the present invention is intended to provide a new solution for uploading photos to online accounts in a secure manner to prevent spam and unauthorized uploading. At the outset, the upload security scheme includes an opt-in process (500 in FIGS. 3 and 5) that prompts Yahoo! Photos users pre-register the phone numbers of camera phones that will be authorized to make calls to the user's Yahoo! Photos account uploads. The user may also pre-select the maximum number of upload messages the user wishes to receive during the day (or any other predetermined period of time) for each authorized phone. At the end of the selection process, the phone numbers, carriers and message restrictions are stored in a database for future reference. Anytime after the opt-in phase, when the photo is e-mailed from any camera phone to Yahoo! Photos user account, the upload security scheme references user pre-determined upload parameters for authorizing photo uploads via the email. In particular, when the user invokes the "email photo" action, a "share as email" page (2.1.5) appears on the user's mobile device and shows the photos selected to be uploaded by email. The page also prompts the user for an email address to upload.

In one possible implementation, a number of recently used destination email addresses are provided. The user may select one of these emails or enter a new destination email address. The user sends the photo to the address, but assuming the user is allowed to upload the photo to the destination user's Yahoo! Photo accounts.

FIGS. 8A-C illustrate a photograph being taken to a Yahoo! Photos upload the upload security scheme when uploading an email server. The diagram in FIG. 8A illustrates the location of various system components in an upload security scheme, and the flow diagrams in FIGS. 8B-C illustrate various aspects of the process, including uploading rules. While this example shows certain details, it is merely intended to illustrate the idea of the invention, and not to limit it to one implementation.

In this example, step 1 shown in fig. 8A includes taking a picture on a mobile camera phone. Step 2, which may be "sharing" or "sending" a photo from the mobile phone, varies from device to device. Step 3 includes prompting the user to enter a destination email address.

As described above, even though the address looks like a standard email address, the recipient is not at his or her Yahoo! The email is actually received in the Mail inbox. Instead, email is the transport mechanism, and email is sent to Yahoo! Photos uploads the email server. Each photo message utilizes a specific Yahoo! Photo user account identification. The email address takes the form:Yahoo！IDphotos.Yahoo.com. Suppose the destination Yahoo! ID is Jsmith, then the email is ("To (recipient:)")jsmithphotos.Yahoo.comAnd Yahoo! Photos upload email Server utilizes Jsmith's Yahoo! The photo account identifies the email. In a different version, the email includes, in addition to the photo, the name of the photo and the Yahoo! Destination album on photo server (album of Jsmith).

In this example, the email transport protocol is SMTP (simple mail transport protocol defined in STD10, RFC 821), which is commonly used to transfer email between computers. Further, MMS and SMS protocols may be alternatives. SMTP is typically a server-to-server protocol, so other protocols are used to access messages. The SMTP session is typically run in the background under the control of a messaging agent (e.g., sendmail), but may also interact with the SMTP server using telnet to connect to a conventional SMTP port. The local host (of the operator) is typically identified by the IP address of its gateway.

Once the destination is known, an email is sent from the mobile phone to the server, i.e., Yahoo! Photos uploads an email server 18 (note that Yahoo | email and Yahoo | Photos are known to be handled by the same server, but other configurations are possible). En route to the server, the photo email is transmitted via the carrier network (e.g., Sprint PCS network) 12 and is first transmitted to the carrier's SMTP server. The carrier SMTP server then forwards the message to Yahoo! Photos uploads the SMTP server.

At the operator's server (not specifically shown, but represented by the operator network 12), the e-mail sender's mobile phone number (mobile ID number) is identified and then combined with the operator's domain information to form an e-mail source ("From:") IP address, e.g.,408-555-555messaging.sprintpcs.com. Once the photo message reaches Yahoo! The network checks at the security layer the validity of the IP address of the SMTP server that originated the photo message (in step 1 at the destination party). The invalid carrier domain invalidates the IP address and, upon making such a determination, the security layer prevents further forwarding of the e-mail, wherein Yahoo! The Photos upload email server does not receive blocked emails. An IP address deemed valid by the security layer 15 is allowed to proceed to Yahoo! Photos uploads the email server 18.

When an e-mail message arrives at Yahoo! After Photos uploads the email server, the email server receives the email from the destination email address (i.e.,jsmithphotos.Yahoo.com) Extract Yahoo! ID, i.e., Jsmith (in step 2 of destination). The phone number and operator information are extracted from the source address of the photo message. The telephone number and the operator information are then used to check the extracted destination Yahoo |. Whether the ID is permitted to be directed to the destination user's Yahoo! Photos account uploads. As an example, assume that the extracted mobile phone number of the sender is 408-555 and the operator is springpscs. In addition, the extracted destination Yahoo! ID is Jsmith. The server then checks the database to see if the phone number and carrier are in Jsmith's approved upload list. This is to verify that Jsmith authorizes the sender(i.e., mobile phone 408-555 using SprintPCS) upload the photograph to Yahoo!of Jsmith! Photo accounts. Once it is determined that the upload is warranted, the server uploads the photo to Jsmith's Yahoo! Photo accounts. Otherwise, unauthorized uploads are discarded. In a different version, unauthorized emails are redirected to a standard email address.

Having established the role of the system components in uploading the security scheme, we turn now to the process diagram of FIG. 8B. Also, one way to establish upload security is through the use of access control using a mobile phone number. For each user, the scheme requires the user to enter an approved mobile phone number. The upload message is sent to Yahoo! Photos uploads the email server, the mobile phone number and operator domain information as "From: "part of an IP address. The phone number and carrier domain information is retrieved 802 from the upload email message, and the carrier domain information and mobile phone number are then checked to determine if the upload is authorized 806, 808, and 810.

Approval of the operator occurs at the security level even when the message reaches Yahoo! The same is true before Photos uploads the email server. Network layer filters are introduced to provide IP address based access control (using SMTP gateway lists). The filter blocks all messages 804, 806 that are not from the global Access Control List (ACL). In this example, the global access control list is provided by the user from Yahoo! Is constructed by collecting the IP addresses of the SMTP gateways for email photo sharing purposes. Messages sent from operators not in the access control list are blocked 806 at the network layer. Thus, Yahoo! The Photos upload email server only receives messages for uploading Photos from operators listed in the global ACL. Furthermore, ACLs improve efficiency because they ensure that servers do not need to process email messages from unauthorized carriers or spammers, and can focus their resources on processing email from authorized carriers.

Once the server receives the email, the phone number (of the sender) and the operator information are checked against a pre-authorized list in the database 22 associated with the destination user. If there is a phone number and carrier pair 808 in the list, the photo will be retrieved and inserted into the user's Yahoo! Photo account 810. Otherwise, the message will be discarded. This ensures that only photos sent from authorized mobile phones are inserted into the user's photo account.

Finally, turning to the flow diagram of FIG. 8C, an overview of the upload rules is shown. Is sent tojdoephotos.yahoo.com 902The email message is first filtered 904 at the network security layer. If the message passes the network security filtering, the message is routed to Yahoo! Photos uploads an email server for further verification including one or more steps. In one variation of this scheme, only premium users who have the right to selectively grant access to the uploaded Photos (who are Yahoo | users who have previously logged in and purchased the Yahoo | Photos application) can upload their email photo messages 906. Otherwise, the message is discarded 930, or optionally redirected to the (destination) user's standard Yahoo! Mail address (jdoeyahoo.com) 912. The recipient may proceed to accept the photograph, manually upload and store the selected photographs 914, 916, 918, and 920. Then, regardless of whether advanced user features are present or turned on/off, a next step 908 includes determining whether the sender's mobile phone number is on the user's approved list and is authorized to upload the photograph. If the sender's phone number is not on the approved list, the email message is discarded 930 or, alternatively, redirected to the destination user's standard email address 912.

One limit that a user may impose is the number of uploads permitted over a certain period of time (e.g., days, hours, or weeks). The limit is set during user registration. Thus, the next step includes determining whether the limit number of permitted uploads, x910, has been reached. If not, the upload may continue, else the message is discarded 930, or optionally redirected to the user's standard email address 912.

In one variation, if the sender is Yahoo! Owner of the photo account, an SMS message with an embedded URL can be pushed to the sender's mobile device. The sender then clicks on the link and then authorizes the upload via the WAP session.

After uploading the photo, the photo is stored in the user's account on the server 928. If the user's album is specifically identified, the photo is directed to the album. If the photo name is identified, the particular photo is uploaded and stored. It is envisioned that future photo programs will be designed with the ability to identify photos by name, and the ability to identify the particular album to which the photos are directed.

In view of the above, this upload security scheme improves efficiency and controls access to user accounts. With the growing problems of fraudulent broadcasts, spam, and parasitic programs, controlled access to upload security helps to block unwanted uploads.

Implementation details

Additional implementation details associated with the foregoing description are given below. These implementation details include the initial list of devices, softkey mappings, labels, and global elements and screen flow tables for online and mobile albums. These details are described below.

Possible mobile device

The visual interaction design described herein should accommodate various types of mobile devices, including, for example, the mobile devices listed in the following table.

Number of the seller	Available pixel size
		Audiovox 8450 Samsung A660 Sanyo RL2000(7200) Sanyo RL2500(5400) Sanyo 5500 Sony Ericsson T608 Toshiba 9950 Hitachi SH-P300 LG 5350 Samsung A500 Samsung N400 Samsung A600 Samsung VGA1000(A620) Sanyo 4900 Sanyo 5300 Sanyo 8100	128 × 112128 × 112 (without soft keys) 128 × 0131 (with soft keys: 15) 120 × 1112 (including soft keys) 132(W) × 2160(H), including soft keys 132(W) × 3160(H), including soft keys 128 × 4114 pixels 261 × 5240120W × 6130H 120 × 796128 × 8146 (without soft keys) 128 × 9131 (with soft keys: 15)128 × 114 (without soft keys) 128 × 0102 (with soft keys: 12) 128 × 1146 (without soft keys) 128 × 131 (with soft keys: 15)128 × 146 (without soft keys) 128 × 131 (with soft keys: 15) 120 × 112 including soft keys 132 × 160 (including soft keys) 128 × 120 (with keys) 120 × 112 (without soft keys)

Soft key mapping

For the purposes of the present invention, the following keys are available on a mobile device: up (Up); down (Down); left; right (to the Right); Select/OK; LeftSoft Key (left softkey); right Soft Key (Right softkey); and Back. If the device does not have a distinct selection key, then it is assumed that the MIDP (Mobile information device Profile) implementation will automatically provide a selection option at one of the soft keys or in one of the soft key menus.

Key mapping
	Scroll up the cursor or select the previous item in the list.
Scroll down the cursor or select the next item in the list.
	Left the cursor scrolls left if possible.
The cursor is scrolled to the right if possible.
	Selecting a link or button: go to the appropriate screen exclusion list (radio button): selection of radio button multiple list (check box): check or uncheck checkbox text boxes: bring the user to the text editor text string: performing no action
The function of the two soft keys varies greatly with the device. The ordering and positioning of the options cannot be controlled with any precision; the order shown only indicates the relative importance of the options. In the example given here, it is preferable that the options are assigned with the following layouts of the types (BACK, EXIT, and ITEM): item 1: main soft key item 2: if no other is present, the secondary soft key should have item 2 as its label. If there are other items available, they should be listed in the menu in order of priority and utilizedSoft key access. The main softkey should have the same function as the "enter"/"OK" button.
	The Back button links Back to the previous screen. A level is not linked up in the navigation tree unless the level is the previous screen. No acknowledgement or error pop-up is linked back. When technical limitations exist, data previously entered into the fields may not be shown when the user navigates back to the page. However, the actual implementation may vary with technical constraints.
Default selection in general, the first item on a page is a previously selected item (the default item) unless the user has performed some action, such as viewing or renaming an image.

[0109]

Soft keys and menu labels

In a representative implementation, the labels that may appear on a soft key are limited to 7 characters. Menu only items are limited to 14 characters.

Command marking

OK	A default action of the screen or selected item is performed. The user is moved forward in the task. (e.g., opening a photo album or photo).
		Cancel	Except for "Back", is used when an action is activated and can be cancelled. Cancellation typically performs the same action as returning, but is displayed to increase the confidence that the user is confident that the action has been cancelled.
Edit (Edit)	"Edit" links to the text box editing screen if available.
		Open (Open)	Open folders, messages, files, etc. Should not be used for links that are not associated with files, folders, etc.
Back	The "Back" flag should be used only for the return function described above. The return should always map only to the return button of the device, if possible.
		Home	Linked to the main screen of the MIDlet.

Global element

Confirmation pop-up

One type of global element is presented as a "Confirm Popup" screen for displaying confirmation to the user. The confirmation pop-up screen contains simple text such as "Done" or "Saved" and automatically disappears after a short time.

On-going screen

The "in progress" screen informs the user that the application is waiting for a response from the server or is processing a request. Each device has a default screen with text and motion graphics, or may be implemented using Yahoo! A Canvas screen replaces this screen.

Screen flow: online photo album

As described above, the online album page is available to the user in a forward or backward pass; each page has a default selection item associated with it. Of course, the forward pass starts from the main page (2.0). The following table summarizes the default selections available in each page of the screen flow for that page, respectively.

Left arrow head	Loop through all thumbnails (4) - (1) on the screen and then to the previous line. One row is added at a time, so the topmost row moves down when a new row is loaded.
		Arrow to the right	Looping through all thumbnails (1) - (4) on the screen and then to the next row. One row is added at a time, so the bottom-most row moves up when a new row is loaded.
Note	The list loops back to the beginning when the user reaches the last image. When looping to the beginning, full screen is refreshed with 2 lines of image. Each picture is surrounded by a 2-pixel white space. The selected photograph has a black border of 2 pixels.

Downward arrow head	-
		Left arrow head	-
Arrow to the right	-
		Note

Screen flow: mobile photo album

As with online albums, moving album pages are available to users in either a forward or backward pass; each page has a default selection item associated with it. Likewise, the forward pass starts of course from the main page (2.0). The following table summarizes the default selections available in each page of the screen flow for that page, respectively.

Upward arrow head	-
		Downward arrow head	-
Left arrow head	-
		Arrow to the right	-
Note

Although the present invention has been described in accordance with the embodiments shown, many variations to these embodiments will be apparent to those skilled in the art and are within the scope and spirit of the invention. Therefore, the illustrated and described embodiments should be considered exemplary only, with a true scope of the invention being indicated by the following claims and their equivalents.

Claims (35)

1. A method for providing upload security, comprising:

providing security screening for upload messages from a wireless carrier network and destined for an account associated with a user on a server, the security screening provided by another network that is not the wireless carrier network, the security screening of the other network provided by a security layer of the other network blocking the upload message based on carrier domain information of the wireless carrier network before the upload message reaches the server;

in the case where security screening performed by a security layer of the other network does not block the upload message, the server determines whether to block or allow upload of content from the upload message, the server:

identifying, in the server, the mobile device in response to the server receiving the upload message from a mobile device used by a sender of the upload message via the network that performed the security screening and the wireless carrier network;

accessing, in the server, information associated with the user, the information associated with the user specifying a mobile device authorized by the user to upload data to the account associated with the user on the server, and wherein the information associated with the user indicates a limit number of upload messages authorized by the user for receipt by the user during a given time period;

determining to allow content from the upload message to be uploaded to the account associated with the user if the mobile device used by the sender is one of the mobile devices specified in the information associated with the user and the upload does not exceed a limit number of upload messages authorized by the user for receipt by the user during a given time period; and

determining to block upload of content from the upload message to the account associated with the user in the event that the sender uses one of the mobile devices specified in the information associated with the user or the upload message exceeds a limit number of upload messages authorized by the user for receipt by the user during a given time period.

2. The method of claim 1, wherein the mobile device is a wireless device.

3. The method of claim 1, wherein the content is photo data.

4. The method of claim 1, wherein the gateway in the wireless carrier network is selected from the group consisting of: a Simple Mail Transfer Protocol (SMTP) gateway, a Multimedia Messaging Service (MMS) gateway, a Short Message Service (SMS) gateway.

5. The method of claim 1, wherein an IP address is specified in the upload message, and wherein providing security screening for the upload message further comprises parsing the upload message to obtain the IP address.

6. The method of claim 1, wherein the mobile device is a wireless telephone and the information associated with the user specifies a telephone number assigned to the wireless telephone by a carrier of the wireless carrier network.

7. The method of claim 1, wherein the sender uses email as a transport mechanism for the upload message, and wherein the upload message identifies the user to whom the upload message is intended by indicating the user's email address.

8. The method of claim 7, wherein the server correlates the user's email address with the account associated with the user.

9. The method of claim 1, further comprising, if the uploading is blocked, rerouting the upload message to the user's email address.

10. The method of claim 1, further comprising the sender establishing a communication link from the sender's mobile device to the user to prompt the user to indicate on the user's mobile device or personal computer whether the user is to add the sender's mobile device to a mobile device specified in the information associated with the user.

11. A system for providing upload security, comprising:

a server, the server associated with the user,

another network, which is not a wireless carrier network, operable to provide security screening of upload messages received by the other network from a gateway in the wireless carrier network destined for an account associated with the user on the server, a security layer of the other network operable to block the upload message based on carrier domain information of the wireless carrier network before the upload message reaches the server;

in the event that security screening performed by a security layer of the other network does not block the upload message, the server is operable to determine whether to block or allow upload of content from the upload message, the server being operable to:

identifying the mobile device in response to the server receiving the upload message from a mobile device used by a sender of the upload message via the other network and the wireless carrier network on which the security screening was performed;

accessing information associated with the user, the information associated with the user specifying a mobile device authorized by the user to upload data to the account associated with the user on the server, and wherein the information associated with the user indicates a limit number of upload messages authorized by the user for receipt by the user during a given time period;

determining to allow content from the upload message to be uploaded to the account associated with the user in the event that the identity of the mobile device used by the sender is one of the mobile devices specified in the information associated with the user and the upload does not exceed a limit number of upload messages authorized by the user for receipt by the user during a given time period; and

determining to block upload of content from the upload message to the account associated with the user in the event that the sender uses one of the mobile devices specified in the information associated with the user or the upload message exceeds a limit number of upload messages authorized by the user for receipt by the user during a given time period.

12. The system of claim 11, wherein the content is photo data and the mobile device is a wireless camera phone.

13. The system of claim 11, wherein the gateway is selected from the group consisting of: a Simple Mail Transfer Protocol (SMTP) gateway, a Multimedia Messaging Service (MMS) gateway, a Short Message Service (SMS) gateway.

14. The system of claim 11, wherein an IP address is specified in the upload message, and wherein the other network is further operable to parse the upload message to obtain the IP address.

15. The system of claim 11, wherein the mobile device is a wireless telephone and the information associated with the user specifies a telephone number assigned to the wireless telephone by a carrier of the wireless carrier network.

16. The system of claim 11, wherein the sender uses email as a transport mechanism for the upload message, and wherein the server is further operable to prompt the sender to identify the user to the server using the user's email address.

17. The system of claim 16, wherein the server is further operable to correlate the user's email address with the account associated with the user.

18. The system of claim 11, the server further operable to: if the upload is blocked, the upload message is rerouted to the user's standard email address.

19. The system of claim 11, the sender's mobile device operable to establish a communication link from the sender's mobile device to the user so as to prompt the user to indicate on the user's mobile device or personal computer whether the user is to add the sender's mobile device identification to a mobile device specified in the information associated with the user.

20. The system of claim 11, wherein the content from the upload message includes one or more photos selected by the sender for sharing with the user via the account associated with the user.

21. The system of claim 11, wherein each of the mobile devices is operable to capture, store, access, scroll, select, delete, and restore photos in a local photo album, and wherein the server is operable to store, access, scroll, select, and delete photos in an online photo album at the account associated with the user.

22. The system of claim 11, wherein the sender's mobile device is operable to: displaying a list of email addresses that the sender has recently used, receiving a selection of an email address from the list as the user's email address if the user's email address is included in the list, and prompting the sender to enter the user's email address if the user's email address is not included in the list.

23. A system for providing upload security, comprising:

a server;

a plurality of mobile devices communicatively linked with the server; and

another network that is not an operator network that includes a gateway and interfaces the plurality of mobile devices and connects each of the plurality of mobile devices with the gateway, the other network interfacing the gateway and the server to allow communication between the plurality of mobile devices and the server via the gateway;

wherein the further network comprises a security layer operable to provide security screening of upload messages from the operator network intended for a user, the security screening being provided before the upload messages reach the server and being based on operator domain information of the operator network;

in the event that security screening of the other network does not block the upload message, the server is operable to determine whether to block or allow upload of content from the upload message, the server being operable to:

identifying the mobile device in response to the server receiving the upload message from a mobile device used by a sender of the upload message via the other network and the carrier network on which the security screening was performed;

accessing information associated with the user, the information associated with the user specifying a mobile device authorized by the user to upload data to an account on the server associated with the user, wherein the information associated with the user indicates a limit number of upload messages authorized by the user for receipt by the user during a given time period;

determining to allow content from the upload message to be uploaded to the account associated with the user if the mobile device used by the sender is one of the mobile devices specified in the information associated with the user and the upload does not exceed a limit number of upload messages authorized by the user for receipt by the user during a given time period; and

determining to block upload of content from the upload message to the account associated with the user in the event that the sender uses one of the mobile devices specified in the information associated with the user or the upload message exceeds a limit number of upload messages authorized by the user for receipt by the user during a given time period.

24. The system of claim 23, wherein the plurality of mobile devices are WAP (wireless application protocol) enabled, and wherein the gateway is a proxy for the plurality of WAP-enabled mobile devices on the one hand and the server on the other hand.

25. The system of claim 23, wherein the plurality of mobile devices are wireless camera phones, and wherein the content is photo data.

26. The system of claim 23, wherein the gateway is selected from the group consisting of: a Simple Mail Transfer Protocol (SMTP) gateway, a Multimedia Messaging Service (MMS) gateway, a Short Message Service (SMS) gateway.

27. The system of claim 23, wherein an IP address is specified in the upload message, and wherein the security layer is further operable to parse the upload message to obtain the IP address.

28. The system of claim 23, wherein the mobile device used by the sender is a wireless telephone and the information associated with the user is a telephone number assigned to the wireless telephone by a carrier of the wireless carrier network.

29. The system of claim 23, further comprising an email as a transport mechanism for the upload message, and the upload message identifies the user to whom the upload message is intended by indicating the user's email address.

30. The system of claim 29, wherein the server is further operable to correlate the user's email address with the account associated with the user.

31. The system of claim 23, wherein the upload message is rerouted to a standard email address of the user if the upload message is blocked by the security screening and the upload message is rerouted to the standard email address of the user if the upload of the content is blocked by the server.

32. The system of claim 23, wherein each of the plurality of mobile devices is operable to establish a communication link from the sender's mobile device to the user to prompt the user to indicate on the user's mobile device or personal computer whether the user is to add the sender's mobile device identification to the mobile device specified in the information associated with the user.

33. The system of claim 23, wherein the sender's mobile device is operable to upload one or more photos the sender selects to share with the user to the account associated with the user.

34. The system of claim 23, wherein each of the plurality of mobile devices is operable to capture, store, access, scroll, select, delete, and restore photos in a local photo album, and wherein the server is operable to store, access, scroll, select, and delete photos in an online photo album at the account associated with the user.

35. The system of claim 23, wherein each of the plurality of mobile devices is operable to respond to the sender selecting the user's email address from the list if the user's email address to which the upload message is destined is included in the list of email addresses that the sender has recently used and to prompt the sender to enter the user's email address if the user's email address is not included in the list.