U.S. patent number 8,015,253 [Application Number 12/111,492] was granted by the patent office on 2011-09-06 for system and method for controlling inter-device media exchanges.
This patent grant is currently assigned to Photobucket Corporation. Invention is credited to Brian Schultz, Daniel J. Shapiro, Charles B. Zapata.
United States Patent |
8,015,253 |
Zapata , et al. |
September 6, 2011 |
**Please see images for:
( Certificate of Correction ) ** |
System and method for controlling inter-device media exchanges
Abstract
Systems and methods for enhancing the exchange of data,
particularly media data, among remote locations. In one embodiment,
instructions are added to a delivered media message. The
instructions are such as to control the processing of the media at
the receiving device as well as controlling response messages. This
then allows a sending device to enable a return connection from the
target location thereby facilitating the return to the sending
device of data. The retuned data can be specified by the sender, by
the target or by a combination of them. In one embodiment, a
intermediary server is used to control the data flow across the
network.
Inventors: |
Zapata; Charles B. (Redmond,
WA), Shapiro; Daniel J. (Seattle, WA), Schultz; Brian
(Redmond, WA) |
Assignee: |
Photobucket Corporation
(Denver, CO)
|
Family
ID: |
44513657 |
Appl.
No.: |
12/111,492 |
Filed: |
April 29, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
Issue Date |
|
|
11540497 |
Sep 28, 2006 |
7698392 |
|
|
|
12111492 |
|
|
|
|
|
11732508 |
Apr 2, 2007 |
7610056 |
|
|
|
60721262 |
Sep 28, 2005 |
|
|
|
|
60788171 |
Mar 31, 2007 |
|
|
|
|
Current U.S.
Class: |
709/206; 709/219;
709/218; 709/217 |
Current CPC
Class: |
H04L
67/1095 (20130101); H04L 63/08 (20130101); G06F
21/606 (20130101); H04L 67/34 (20130101); H04L
63/0442 (20130101); H04L 63/061 (20130101); H04L
67/06 (20130101); H04M 1/72439 (20210101); H04M
2250/64 (20130101) |
Current International
Class: |
G06F
15/16 (20060101) |
Field of
Search: |
;709/206,217-219 |
References Cited
[Referenced By]
U.S. Patent Documents
Foreign Patent Documents
|
|
|
|
|
|
|
WO-2007/038766 |
|
Apr 2007 |
|
WO |
|
Other References
International Search Report and Written Opinion issued for
PCT/US2006/038207; Dated: Jul. 31, 2008; 14 Pages. cited by other
.
International Search Report and the Written Opinion issued for the
International PCT Application No. PCT/US2008/77439, issued on Dec.
11, 2008; 10 pages. cited by other.
|
Primary Examiner: Wasel; Mohamed
Attorney, Agent or Firm: Fulbright & Jaworski L.L.P.
Parent Case Text
CROSS-REFERENCE TO RELATED APPLICATIONS
This is a continuation in part of U.S. patent application Ser. No.
11/540,497 filed Sep. 28, 2006 which is a Non-Provisional
Application claiming priority to U.S. Provisional Application No.
60/721,262 filed Sep. 28, 2005; and this application is also a
continuation in part of U.S. patent application Ser. No. 11/732,508
filed Apr. 2, 2007 which is a Non-Provisional Application claiming
priority to U.S. Provisional Application No. 60/788,171 filed Mar.
31, 2007, all of the disclosures of which are hereby incorporated
by reference herein.
Claims
What is claimed is:
1. A method for exchanging media data between communication
devices, said method comprising: sending a media burdened message
from a first device to a target device, said message containing
both media content and optional user controlled response
possibilities for presenting to a user at said target device
positioning on a display of said target device at least some of
said sent ones of said user controlled response possibilities in
conjunction with media sent to said target user; and conditioning
said target device to allow said target user to respond to said
display of user controlled response possibilities without requiring
said user to change said displayed presentations.
2. The method of claim 1 wherein said media burdened message
comprises a request from said first device to return to said first
device media captured by said target device.
3. The method of claim 1 wherein said media burdened message is a
request from said first device to said target device to grant
permission to said first device to allow said first device to send
additional media burdened messages to said second device.
4. The method of claim 3 wherein any additionally sent media
burdened messages are delivered under rules established by said
target user.
5. The method of claim 4 wherein said rules are selected from the
list of: number of media burdened messages allowed in a fixed
period of time; a type of media to be included in any said message;
redirection of said media burdened messages to at least one other
location.
6. The method of claim 1 wherein said positioned ones of said sent
user controlled response possibilities are determined in
cooperation with said target device and presented to said user upon
receipt of said message.
7. The method of claim 1 wherein said optional response
possibilities are added to said message by an intermediary control
point.
8. The method of claim 7 wherein said response possibilities are
modifiable from time to time by at least one of: a sending user;
said target user; a third party; time of day; prior activity with
respect to said sending user; prior activity with respect to said
target user.
9. The method of claim 1 wherein said media data is selected from
the list of: digital still images, video images; audio files.
10. The method of claim 1 wherein said message is sent first to a
server and said server coordinates sending of said message to said
target device.
11. A method of communicating media messages from a first location
to a second location, said method comprising: establishing at said
second location a set of rules for handling messages sent from said
first location, said set of rules uniquely associated with said
first location; sending a media message from said first location to
said second location for processing at said second location in
accordance with said pre-established rules pertaining to said first
location; and positioning received ones of said sent media messages
on a display of said second location in accordance with said first
location rules, wherein said first location pre-established rules
are delivered to said second location as part of a media message
sent from said first location.
12. The method of claim 11 wherein said second location handles
messages sent from a plurality of different first locations, each
first location having established its own unique set of rules.
13. The method of claim 12 wherein each sent message from a
particular one of said first locations contains at least a portion
of said rules pertaining to said particular first location.
14. The method of claim 13 wherein said rules for said particular
first location instructs said second location to forward said
message to a target location, said forwarded message containing, in
addition to said forwarded message, a set of temporary rules for
use with respect to said forwarded message at said target
location.
15. The method of claim 14 wherein said temporary rules comprise at
least one of the following rules: request for permission to send at
least one additional message of a similar type to said forwarded
message; a request to return a new message of a certain type; a
request to keep a data channel open for a period of time; an
instruction to perform some function with respect to said forwarded
message; a request to store said forwarded message at a particular
location; instructions to forward the message to a new target
together with at least some of said instructions; a request to
forward a different message to a new target together with at least
some of said instructions.
16. The method of claim 15 wherein any said returned message is
passed to said first location through said second location.
17. The method of claim 15 wherein any said returned message from
said new target is passed to said first location through said
second location and not through said first target.
Description
The above-referenced Provisional Applications are, as a result of
35 USC 119(e), incorporated by reference in their respective parent
applications. For convenience of the reader, applicant has copied
portions of the respective Provisional Applications into this
application in the section hereof titled GENERAL DESCRIPTION.
Because this application is being filed during the pendency of the
respective parent applications and because this application claims
priority from both parent applications and because the contents of
the respective Provisional Applications were incorporated by
reference in their respective parents, it follows that the contents
of the Provisional Applications are not new matter in this
application.
TECHNICAL FIELD
This disclosure relates to the control of inter-device media
exchanges and more particularly to systems and method for
establishing communication links for the exchange of media between
devices.
BACKGROUND OF THE INVENTION
Data gathering has now become widespread using digital techniques.
For example, digital cameras, video recorders and other digital
data capturing devices are prevalent in every aspect of human
endeavor. Digital documents are scanned, or created, almost without
exception during the course of every financial transaction,
especially in developed countries. Thus vast amounts of data are
being generated and presumably saved for future use. However, this
data is typically saved in association with the capturing device
which, in most instances, is not the best mode (or in the proper
location) for subsequent viewing or processing of the captured
data.
For example, cell phones equipped with digital cameras have been
widely adopted by consumers. Such phones allow for cell phone users
to communicate images, in addition to voice signals, over the phone
lines. Camera-equipped cell phones have facilitated news gathering
and event reporting, intimate personal communications, in which
pictures and images can elicit a wider range of emotional responses
than voice signals alone, and business-related and research-related
information transfer. However, currently, it is difficult for users
to transfer their digital pictures from camera-equipped cell phones
to personal computers or to other locations. Users, retailers, and
designers of both computer systems and camera-equipped cell phones
have recognized the need for easier, more intuitive, and more
robust methods for transferring digital images recorded on
camera-equipped cell phones to computers, including personal
computers and workstations.
BRIEF SUMMARY OF THE INVENTION
The present invention is directed to a system and method which
allows for enhanced exchange of data, particularly media data,
among remote locations. In one embodiment, instructions are added
to a delivered media message. The instructions are such as to
control the processing of the media at the receiving device as well
as controlling response messages. This then allows a sending device
to enable a return connection from the target location thereby
facilitating the return to the sending device of data. The retuned
data can be specified by the sender, by the target or by a
combination of them. In one embodiment, a intermediary server is
used to control the data flow across the network.
The foregoing has outlined rather broadly the features and
technical advantages of the present invention in order that the
detailed description of the invention that follows may be better
understood. Additional features and advantages of the invention
will be described hereinafter which form the subject of the claims
of the invention. It should be appreciated by those skilled in the
art that the conception and specific embodiment disclosed may be
readily utilized as a basis for modifying or designing other
structures for carrying out the same purposes of the present
invention. It should also be realized by those skilled in the art
that such equivalent constructions do not depart from the spirit
and scope of the invention as set forth in the appended claims. The
novel features which are believed to be characteristic of the
invention, both as to its organization and method of operation,
together with further objects and advantages will be better
understood from the following description when considered in
connection with the accompanying figures. It is to be expressly
understood, however, that each of the figures is provided for the
purpose of illustration and description only and is not intended as
a definition of the limits of the present invention.
BRIEF DESCRIPTION OF THE DRAWINGS
For a more complete understanding of the present invention,
reference is now made to the following descriptions taken in
conjunction with the accompanying drawings, in which:
FIGS. 1 and 2 show prior art systems in which the inventive
concepts discussed herein can be utilized;
FIG. 3 illustrates a high-level overview of one embodiment of the
present invention;
FIG. 4 illustrates the capture of a digital image and secure,
seamless transfer of the digital-image data from the cell phone to
the personal computer according to one embodiment of the present
invention;
FIG. 5 illustrates the conceptual, intercommunicating applications
that together comprise one view of the virtual communications
medium and network that represents one embodiment of the present
invention;
FIG. 6 illustrates intercommunication provided by the virtual
communications medium and network;
FIGS. 7A-D illustrate, at overview level, the steps involved in
creating the virtual communications medium and network (302 in FIG.
3) to allow for peer-to-peer interaction between PC applications
and cell phone applications;
FIG. 8 is a control-flow diagram for a routine "deploy" that
represents one embodiment of the present invention;
FIG. 9 is a control-flow diagram for the routine
"collectInformation," invoked in step 804 of the routine "deploy"
shown in FIG. 8;
FIGS. 10A-D describe one embodiment of the target-device
identification step 806 of the routine "deploy" shown in FIG.
8;
FIG. 11 is a control-flow diagram illustrating the routine
"createDCA," called from step 808 of FIG. 8;
FIGS. 12A-B include control-flow diagrams that describe the
delivery of DCAs to target devices invoked in step 810 of FIG.
8;
FIG. 13 shows a control-flow diagram for the routine "installDCAs"
invoked in step 812 of FIG. 8;
FIG. 14 illustrates the meaning of the terms "service application,"
"client," and "function" with respect to embodiments of the present
invention;
FIG. 15 illustrates a set of relational tables that may be used to
store information related to service-application and client
deployment installation on target devices according to one
embodiment of the present invention;
FIG. 16 is a control-flow diagram illustrating a routine that
determines the minimal set of clients to add to a target device in
the course of deploying a service application, called in step 1120
of the routine "createDCA" described in FIG. 11;
FIG. 17 provides a control-flow diagram for a remove-service
application routine;
FIG. 18 illustrates the concept of a link;
FIG. 19 illustrates implementation of the link shown in FIG.
18;
FIG. 20 illustrates, establishment of a link according to method
and system embodiments of the present invention;
FIG. 21 illustrates establishment of a secure link between a client
running on a device and a server according to one embodiment of the
present invention;
FIG. 22 illustrates a number of the possible methods by which
interprocess communication can be implemented in an electronic
hand-held device in communication with a server when the electronic
hand-held device does not offer native interprocess communications,
according to method and system embodiments of the present
invention;
FIG. 23 displays various methods for implementing persistent data
storage on an electronic hand-held device, when persistent data
storage facilities are not explicitly provided by the device
according to method and system embodiments of the present
invention;
FIG. 24 illustrates a number of mechanisms that can be used for
launching and reawakening processes within an electronic hand-held
device according to method and system embodiments of the present
invention;
FIG. 25 is a control-flow diagram illustrating process behavior on
an electronic hand-held device for processes that cooperate to
implement a robust, multi-tasking environment according to method
and system embodiments of the present invention;
FIG. 26 illustrates a digital-image-transfer service application
that represents one embodiment of the present invention;
FIG. 27 is a control-flow diagram illustrating operation of the
source-device portion of the digital-image-transfer service
application that represents one embodiment of the present
invention;
FIGS. 28 and 29 illustrate the server portion of the digital-image
transfer service that represents one embodiment of the present
invention;
FIG. 30 is a control-flow diagram illustrating the target-device
portion of the digital-image transfer service application that
represents one embodiment of the present invention;
FIG. 31 shows one embodiment of a method of operation of an
intermediary server in accordance with one aspect of the invention;
and
FIG. 32 shows one embodiment of a method of operation of a target
storage device in accordance with one aspect of the invention.
FIG. 33 shows one embodiment of a method of operation in accordance
with one aspect of the invention.
GENERAL DESCRIPTION
Upon installation on the phone, the image-transfer phone software
is generally configured with the address of the fileserver, plus
any additional configuration parameters necessary for the
image-transfer phone software to operate. The image-transfer
software may come with a set of options predefined, including the
location of the fileserver as well as an FTP account and password
for that user.
The image-transfer phone software may be automatically started when
the user powers on the phone. After turning on the phone, the user
can generate an image, for example by taking a picture with the
camera-equipped phone. When the picture is taken, it is usually
written to the file system located on the phone's internal
persistent memory (internal or on a memory card). The
image-transfer phone software running on the camera becomes aware
of the new image, for example by regularly polling the file system
on the camera-equipped phone looking for new images. When a new
image is detected, the Photosync Phone Client software opens its
connection to the fileserver over one of the network access systems
available on the phone.
After opening the connection, for example via FTP, the
image-transfer phone software transfers the image onto the
fileserver. The file may be stored in a directory named by the
camera-equipped phone's phone number (by storing the images in a
unique directory, there are no collisions between the files
uploaded by one camera-equipped phone and the files uploaded by
another camera-equipped phone). When the transfer is complete, the
file may be deleted from the camera-equipped phone, leaving room
for more images. Images uploaded onto the server may be persisted
until deleted by the PC client software.
On both the server and the client, unique filenames can prevent
collisions or race conditions resulting in data loss. To provide
this, the image-transfer phone software can upload the image file
with a new name. The file name of the new file created on the
fileserver can be created by concatenating the following text
strings:
The original image file name as recorded on the phone,
The precise date and time of the photo's creation;
An additional index (like a "(2)" or ".sub.--2") to account for
existing duplicate files;
The string ".transfer"
The final suffix string ".transfer" may be used to indicate to any
other clients on the fileserver that the file is still being
uploaded by the client. When the file is completely uploaded, the
file may be renamed on the file server by the image-transfer phone
software to remove the ".transfer" suffix.
The personal-computer image-transfer software is then able to
download the files. The personal-computer image-transfer software
may be started when the PC is powered on, or when the user is
logged into the PC. To download the files, the personal-computer
image-transfer software connects to the fileserver, for example via
FTP. The personal-computer image-transfer software need not be
running simultaneously with the arrival of the photos on the
server, but it can be. The personal-computer image-transfer
software typically polls the fileserver periodically, checking for
new images in its configured directory, named by the
camera-equipped phone's phone number.
When the FTP file upload from the image-transfer phone software is
complete, and the file renamed to remove the ".transfer" suffix,
the personal-computer image-transfer software can assert the file
has completed transfer to the file server and can begin download of
the file to the PC. The personal-computer image-transfer software
may download the file using standard binary FTP protocol, and then
place it in a known spot on the user's hard drive, for example the
user's My Pictures folder. It may then delete it from the
fileserver.
The above describes only one possible implementation. Many
alternative implementations are possible:
Data files other than images can be transferred by this system. In
any case in this document in which images are described, data other
than photos may be substituted. Examples include videos, text
notes, or address book records. Note that in this document
"photos", "images", etc. may be described, but any type of file may
be used.
Image transfer may be made in either direction. The PC can upload
photos to 30 the fileserver, and the image-transfer phone software
can download them. Consequently, any time a image-transfer phone
software and personal-computer image-transfer software are
specified in this document, the scenario may be reversed.
Additionally, transfers may be made from personal-computer
image-transfer software to personal-computer image-transfer
software or image-transfer phone software to image-transfer phone
software. Consequently, the personal-computer image-transfer
software and image-transfer phone software are interchangeable.
There are different ways the linkage between the image-transfer
phone software and personal-computer image-transfer software can be
configured or declared by the user. For example, the pairing
between the image-transfer phone software and the personal-computer
image-transfer software could be contingent on the user entering a
passcode into both the phone and the client, thereby proving that
they have physical access to both.
The linkage between the image-transfer phone software and
personal-computer image-transfer software may be automatically
configured without specific action from the user. Instead of
forcing the user to indicate the pairing between the image-transfer
phone software and personal-computer image-transfer software, the
user may download software for the phone and client that have been
paired before delivery. For example, the user might enter their
phone number on a website. The website would then add the user's
phone number to the phone software installer and then send it
directly to the phone, ready for use. Likewise, it would add the
user's phone number to the client software installer and then
initiate a download of it.
The file to be transferred may be generated from different programs
or hardware. The standard camera-equipped phone software may be
used to generate an image, or the image-transfer phone software
might cause the onboard camera to take a picture to generate an
image, or a third party program may generate an image from code or
from the camera or another hardware device. Files may come from any
conceivable source, including user input, additional hardware, or
transfers from other devices.
The file might not be written to persistent storage on the phone.
For example, pictures may be transferred directly from the camera
chip to the server, and never written to local phone storage.
Polling may be replaced with notification. Instead of requiring the
image-transfer phone software to poll the phone's file system to
detect a new image, for example, an event, interrupt, or message
may be generated by the software that creates the file (e.g. the
onboard camera application). This would trigger the file transfer
to begin.
The image-transfer phone software or personal-computer
image-transfer software may be turned on or off by a variety of
means. It could be controlled by the phone's ringing profile,
explicit request by the user, or any other method that is used to
control software startup/ending.
The image-transfer phone software, personal-computer image-transfer
software, and fileserver may delete files according to any policy.
For example, the image-transfer phone software may delete pictures
as soon as they are taken, or leave them on the phone. The
personal-computer image-transfer software may delete files
smaller/larger than a certain size. The server may delete photos
after the personal-computer image-transfer software has downloaded
them, or it may wait for a deletion instruction from the
personal-computer image-transfer software, or it may leave them in
place for 30 days so a user could view them with a web browser in
the interim.
The image-transfer phone software may store files on different
storage media. For example, the camera-equipped phone may be
physically attached to a third party storage device, or may be
mapping a remote network storage device as local phone storage. In
either event, the files could still be uploaded to the fileserver.
Alternately, the device might act as the fileserver.
The image-transfer phone software might be connected to the
fileserver through alternate means. For example, the phone might be
connected by USB cable or by an 802.11 network connection, instead
of by the phone data network.
The fileserver might not write the files to disk. For example, the
files may be kept in memory in part, transfer parts of the file to
the client as is possible, or may be kept in memory wholly, with
the system functioning identically as before.
The usage of a unique directory may be made transparent to the
software. This may be accomplished by configuring the FTP user
login to use a specific directory as its root.
Multiple clients can transfer images to each other. One or more
image-transfer phone softwares belonging to one or more users may
transfer images to one or more personal-computer image-transfer
softwares belong to one or more users (which may or may not be the
same set of users as the first).
Multiple servers may be used. A variety of servers can accomplish
load balancing, enhanced security, and other goals. All servers may
serve a single transaction, or each transaction may be assigned to
one or more servers, or any other such combination. Servers may be
assigned based on any criteria, such as geographical proximity,
network proximity, type of file being transferred, or identity of
user.
Transfers could be only file metadata, not the entire file. The
image-transfer phone software may upload information about files
(e.g. filenames) to the fileserver instead of the actual files. The
personal-computer image-transfer software can then select pictures
to download, either programmatically or with end-user input.
The personal-computer image-transfer software may deposit the files
in one or more different locations on the PC. For example, it might
both place them in the My Pictures folder and archive them to tape
backup.
The personal-computer image-transfer software may signal the
arrival of files to the user. An icon on the screen may change
appearance, a dialog box may display a thumbnail of the file, or a
sound may be played, for example.
A variety of coping strategies exist when the fileserver goes
offline. The image-transfer phone software may resend later, store
the files without resending them, or delete the files, for example.
The personal-computer image-transfer software may notify the user
or not, retry download or not, or fail over to another server, for
example.
A variety of coping strategies exist when the personal-computer
image-transfer software goes offline. The server may hold the files
indefinitely or for a finite length of time before deleting them.
The server may transfer them to an alternate client. The server may
notify the user.
Roundtrip confirmation is possible. The image-transfer phone
software may receive acknowledgement of a successful transaction.
For example, when the file has been successfully written the
personal-computer image-transfer software and its checksum
verified, the personal-computer image-transfer software may inform
the fileserver, which would in turn notify the image-transfer phone
software. The image-transfer phone software could then choose to,
for example, delete the file, knowing it had been safely
transferred.
Files may be transferred to a third party server instead of the
fileserver or the personal-computer image-transfer software. For
example, photos might be transferred to an internet-based
third-party photo hosting service. The transfer could occur
directly from the phone, bypassing the fileserver; it could occur
from the fileserver, bypassing the personal-computer image-transfer
software, or it could occur once the files had been sent to the
personal-computer image-transfer software, as examples.
Any part of the system can configure any other. For example, a user
could configure the image-transfer phone software, fileserver, or
personal-computer image-transfer software behavior from the
image-transfer phone software, the fileserver (via, for example, a
web page), or from the personal-computer image-transfer software.
This would allow the user to, for example, indicate from her phone
that she intends the files to be stored in the "My Pictures" folder
on her PC.
Files transferred may be routed selectively. For example, the files
can be routed to different locations based on the file type as
determined by the three letter file extension, MIME type, or other
metadata. This can happen at the image-transfer phone software,
fileserver, or personal-computer image-transfer software level.
Files may be acted on immediately. Files may be routed to specific
applications for immediate handling, instead of being saved to
disk. For example, a sound might be routed to a media player for
immediate playback when it is received at the personal-computer
image-transfer software.
Different mechanisms may be used to track the state of the
transfer. Instead of changing the file name to indicate the state
of the file transfer, a secondary file may record the state of the
transfer process, or an altogether separate communication channel
using the Phone, fileserver, and/or personal-computer
image-transfer software may be used to send transfer status. It is
also possible to not record transfer status at all, and have the PC
transfer whatever is available immediately, or to have the
personal-computer image-transfer software infer when transfer is
done (for example when less bits are transferred than the stated
JPG image size, the file is not complete).
File transfer may occur before the file has completely arrived at
the phone or file server. For example, a video might be streamed
over the network instead of storing it locally, or it might be
stored in part locally, possibly with the local data deleted as it
is sent off to the fileserver I personal-computer image-transfer
software.
The system may transfer files in discrete parts. The image-transfer
phone software may transfer an image file in segments, to be
reassembled into the complete image file, either on the file server
or on the personal-computer image-transfer software. XXX
The fileserver may push the images to the client without being
requested. The personal-computer image-transfer software may
maintain a connection to the file server, over which the fileserver
pushes files as they arrive on the system. For example, the
personal-computer image-transfer software's drive might simply be
mapped to the fileserver so it can write the files to it using
standard network protocols.
The image-transfer phone software may be polled by the file server
to request photos. The Photo PC may maintain an open connection to
the file server, over which the file server may send the request to
send photos present on the phone.
The image-transfer phone software may send photos to the fileserver
which were created before the image-transfer phone software was
started. Before the image-transfer phone software is
initialized/installed, files may be created (e.g. pictures taken)
by the user. These are stored in the normal fashion, When the
image-transfer phone software is installed/initialized, these files
can be transferred. Similarly, files queued up on the fileserver
may be transferred to a new or newly-active personal-computer
image-transfer software.
Different network protocols and systems may be used to transmit the
data. The server may use something other than FTP as the file
transfer protocol for transmitting files to the client. Any
protocol that allows the transfer of files would be sufficient. For
example, the phone may send the picture via the MMS protocol. In
this case, the server would receive the MMS message, decode the
attachment, and then proceed as if it had been conventionally
uploaded. Or, the files may be sent as E-mail, in which case the
server can receive and forward email as per a standard e-mail
server.
A proprietary piece of software may serve as the file server. The
server may be running specialized software that does not allow the
client or the phone to have direct access to its file system, as
FTP, does. It may have specialized software that supports any of
the following features:
1) It can recognize authorized image-transfer phone softwares, for
example using a proprietary interface to retrieve a unique
identifier from the phone and verifying the validity of the
identifier against a master lookup table.
2) It can recognize authorized software, for example by exchanging
secret keys that are stored in the program.
3) When new image-transfer phone softwares or personal-computer
image-transfer softwares connect to the server, it may create a new
user-account for the user of these devices and/or prompt for an
existing user account (including username and password) to properly
associate the devices.
4) When the personal-computer image-transfer software first
attempts to specify the image-transfer phone software that it
wishes to be "paired" with, the fileserver may issue a verification
request to the image-transfer phone software, and only allow the
pairing if the request is successful. For example, it may transmit
a message to the image-transfer phone software via SMS asking the
user to agree to the pairing. The user agrees by opening a link
contained in the SMS message in the phone's browser. That link
leads the phone back to the fileserver, verifying for the server
that the pairing will be allowed.
5) The server may "pass through" the data directly to the client,
without ever storing it.
The connection may be additionally secured. The image-transfer
phone software may allow the user to specify a password, which the
fileserver software would require of any personal-computer
image-transfer softwares before allowing a successful connection.
Various security and cryptographic systems may be used to secure
the connection further.
A fee may be charged for some or all aspects of this service. Fees
could be monthly, per-kb, or using any other pricing scheme.
Additional fees may be charged by service providers, for example
bandwidth charges billed through the phone carrier.
Files on the server may be accessible through other means. The user
may be able to access the photos while they reside on the server
using an alternate means, such as a web browser.
Data may be transformed at any point in the transfer process. The
image-transfer phone software, fileserver, or personal-computer
image-transfer software may encode, decode, or otherwise modify the
file automatically. For example, the image-transfer phone software
might lower the resolution of the picture before transferring it to
the fileserver, and the fileserver might re-encode the picture to a
file format compatible with the personal-computer image-transfer
software before transferring it to the personal-computer
image-transfer software.
Additional actions may occur as a result of the file transfers. For
example, the file 15 server may record how often files are
delivered by a user, how often they are downloaded by the client,
or how large the image are.
The image-transfer phone software and personal-computer
image-transfer softwares may send diagnostic information to the
fileservers. If a client on either device encounters an error or
exception, it may send a message to the fileserver (in the form a
file in the image directory, or by an altogether separate
communication mechanism).
The image-transfer phone software, fileserver, and
personal-computer image-transfer software may update themselves.
For example, the image-transfer phone software might poll the
fileserver to find a new version of itself, and if found, download
and install it.
The user may configure which personal-computer image-transfer
softwares receive files. For example, a user might indicate to the
image-transfer phone software software that a particular file is to
go to a home PC instead of the default work PC.
Installation
The software may be preinstalled on the phone, or deployed to the
phone as described in "Dynamic Program Creation and Deployment with
Embedded User-Specific Data." Upon installation on the phone, the
image-transfer phone software is generally configured with the
address of the server, plus any additional configuration parameters
necessary for the image-transfer phone software to operate. The
image-transfer software may come with a set of options predefined
or precompiled into the code, including the location of the server
as well as security credentials for that user, as defined in
"Dynamic Program Creation and Deployment with Embedded
User-Specific Data."
Acquisition
The image-transfer phone software may be automatically started when
the user powers on the phone. (The software may also be started,
stopped and restarted by the user). After turning on the phone, the
user may generate an image, for example by taking a picture with
the camera-equipped phone. When the picture is taken, it is usually
written to the file system located on the phone's internal
persistent memory (internal or on a memory card). The
image-transfer phone software running on the camera becomes aware
of the new image, for example by regularly polling the file system
on the camera-equipped phone looking for new images. When a new
image is detected, the phone opens its connection to the central
server over one of the network access systems available on the
phone.
After opening the connection (using either an industry standard
such as FTP, SMTP, WAP or HTTP, or a completely proprietary
standard) the image-transfer phone software transfers the image
onto the server. The file may be stored directly using file-system
semantics, in a directory named by the camera-equipped phone's
phone number (by storing the images in a unique directory, there
are no collisions between the files uploaded by one camera-equipped
phone and the files uploaded by another camera-equipped phone). The
file may also be stored via HTTP verbs (POST or GET), or a
completely private API altogether (which might reuse or depend upon
components from other protocols). When the transfer is complete,
the file may be deleted from the camera-equipped phone, leaving
room for more images. Images uploaded onto the server may be
persisted until deleted by the image-transfer personal-computer
software or the server.
The server may use filesystem semantics to describe the file on the
server and clients. On both the server and the client, unique
filenames may prevent collisions or race conditions resulting in
data loss. To provide this, the image-transfer phone software may
specify a new name for the image file. One possible naming
convention may be applied by concatenating the following text
strings: The original image file name as recorded on the phone;
This precise date and time of the photo's creation; An additional
index (like a "(2)" or a ".sub.--2") to account for existing
duplicate files; and A suffix string ".transfer" The final suffix
string ".transfer" may be used to indicate to any other clients on
the server that the file is still being uploaded by the client.
When the file is completely uploaded, the file may be renamed on
the server by the image-transfer phone software to remove the
".transfer" suffix.
The server may also use separate data-driven methods for naming
files on the server. The server may allocate unique identifiers to
identify files on the image-transfer phone software. A unique
identifier may be generated may several different methods (i.e.
Microsoft's GUID algorithm, or any of several mathematically
sophisticated random number generation algorithms like the Mersenne
Twister). The phone may then send to the server a set of data (the
phone file image name plus other identifying criteria like file
size, file creation date, and resolution) and receive a unique
identifier for that set of data. The file might then be referred to
by that identifier for the remainder of the image transfer
transaction.
Delivery
After the image-transfer phone software has delivered the images to
the server, the image-transfer personal-computer software is then
able to download the files. The image-transfer personal-computer
software may be started when the PC is powered on, or when the user
is logged into the PC. It may also be actively started, stopped and
restarted by the user. To download the files, the image-transfer
personal-computer software connects to the server. The
image-transfer personal-computer software may or may not be running
simultaneously with the arrival of the photos on the server.
The image-transfer personal-computer software may communicate with
the server via standard industry protocols such as FTP or HTTP. It
may also communicate via a completely proprietary protocol. The
image-transfer personal-computer software may operate
synchronously, where the software polls the server (FIG. 1, "B")
periodically, checking for new images in its configured directory
and named by the camera equipped phone's phone number. Or the
image-transfer personal-computer software may have set up an
asynchronous alert messaging system with the server, so that it may
be called by the server at the precise moment that the server wants
to inform the image-transfer personal-computer software about the
existence of new images. This messaging connection may be initiated
by either the server or the client, depending on the addressability
and security surrounding the two entities.
When the image file has been received from the server, the
image-transfer personal-computer software may store the file on the
PC in a standard location in the filesystem, such as the "CA" or
the "My Pictures" folder. It may also store the image in a private
data store or database, accessible by public or private APIs, or it
may also store the images in a third party media storage program or
device. For each option, the storage may be local or remote to the
machine.
The above describes only one possible implementation. Many
alternative implementations are possible.
Extensions: Data
Transfers could be only file metadata, not the entire file. The
image-transfer phone software may upload information about files
(e.g. filenames) to the server instead of the actual files. The
image-transfer personal-computer software may then select pictures
to download, either programmatically or with end-user input.
The image-transfer phone software, image-transfer personal-computer
software, and server may delete files according to any policy. For
example, the image-transfer phone software may delete pictures as
soon as they are taken, or leave them on the phone. The
image-transfer personal-computer software may delete files
smaller/larger than a certain size. The server may delete photos
after the image-transfer personal-computer software has downloaded
them, or it may wait for a deletion instruction from the
image-transfer personal-computer software, or it may leave them in
place for 30 days so a user could view them with a web browser in
the interim. It may also delete the files if free space on the
local storage falls below a given threshold.
Data files other than images may be transferred by this system. In
any case in this document in which images are described, data other
than photos may be substituted. Examples include voice dictation
recordings, videos, text notes, or address book records. Any
facility or operation in this document referring to images also
applies to all other data formats as well.
Data may be transformed at any point in the transfer process. The
image-transfer phone software, server, or image-transfer
personal-computer software may encode, decode, or otherwise modify
the file automatically. For example, the image-transfer phone
software might lower the resolution of the picture before
transferring it to the server, and the server might re-encode the
picture to a file format compatible with the image-transfer
personal-computer software before transferring it to the
image-transfer personal-computer software.
Extensions: Configuration
The user may configure which personal computer or image-transfer
personal-computer software programs should receive files. For
example, a user might indicate to the image-transfer phone software
that a particular file is to go to a home PC instead of the default
work PC.
The linkage between the image-transfer phone software and
image-transfer personal-computer software may be automatically
configured and/or deployed without specific action from the user as
described in sections "Dynamic Program Creation and Deployment with
Embedded User-Specific Data, Platform Specific Code Deployment
Process", "Authentication and unique naming of remote software
clients", and "Communication method for local inter-application
communication on mobile devices."
There are different ways the linkage between the image-transfer
phone software and image-transfer personal-computer software may be
configured or declared by the user. For example, the pairing
between the image-transfer phone software and the image-transfer
personal-computer software could be contingent on the user entering
a passcode into both the phone and the client, thereby proving that
they have physical access to both. The data may be represented as
in section "Communication Relationship Management Process" or may
extended to store additional data about the linkage.
Instead of forcing the user to indicate the pairing between the
image-transfer phone software and image-transfer personal-computer
software, the user may download software for the phone and client
that have been paired before delivery, as described in sections
"Dynamic Program Creation and Deployment with Embedded
User-Specific Data," "Platform-Specific Code Deployment Process,"
and "Authentication and unique naming of remote software clients."
For example, the user might enter their phone number on a website.
The website would then add the users phone number to the phone
software installer and then send it directly to the phone, ready
for use. Likewise, it would add the users phone number to the
client software installer and then initiate a download of it.
Any part of the system may configure any other. For example, a user
could configure the image-transfer phone software, server, or
image-transfer personal-computer software behavior from the
image-transfer phone software, the server (via, for example, a web
page), or from the image-transfer personal-computer software. This
would allow the user, for example, to indicate from her phone that
she intends the files to be stored in the "My Pictures" folder on
her PC.
Extensions: Storage
The file may or may not be written to persistent storage on the
phone. For example, pictures may be transferred directly from the
camera chip to the server, and never written to local phone
storage.
The image-transfer personal-computer software may deposit the files
in one or more different locations on the PC. For example, it might
both place them in the My Pictures folder and archive them to tape
backup.
The server might not write the files to disk. For example, the
files may be kept in memory in part, transfer parts of the file to
the client as is possible, or may be kept in memory wholly, with
the system functioning identically as before.
The usage of a unique directory or unique media representation may
be made transparent to the client software. This may be
accomplished by configuring the FTP user login to use a specific
directory as its root.
The image-transfer phone software may store files on different
storage media. For example, the camera-equipped phone may be
physically attached to a third party storage device, or may be
mapping a remote network storage device as local phone storage. In
either event, the files could still be uploaded to the server
Alternately, the device might act as the server.
Extensions: Client Software
The image-transfer phone software or image-transfer
personal-computer software may be turned on or off by a variety of
means. It could be controlled by the phone's ringing profile,
explicit request by the user, or any other method that is used to
control software startup/ending.
The image-transfer phone software or image-transfer
personal-computer software may come pre-installed on a given
platform. The pre-installed versions of the software may be stored
in a different format or location than its installable counterpart.
The pre-installed software may be part of the operating system or
firmware of the platform, and it may have some different
pre-installed data (security keys, etc). as the installable
version.
Multiple versions of the software may be installed on the same
platform, which may operate independently or cooperatively. Each
software program may refer to different server platforms, or may be
decorated or branded differently to the user.
The image-transfer phone software may send photos that were created
before the image-transfer phone software was started. Before the
image-transfer phone software is installed, files may be created
(e.g. pictures taken) by the user. These are stored in the normal
fashion. When the image-transfer phone software is initialized,
these files may be transferred. Similarly, files queued up on the
server may be transferred to a new or newly-active image-transfer
personal-computer software.
The image-transfer personal-computer software may signal the
arrival of files to the user. An icon on the screen may change
appearance, a dialog box may display a thumbnail of the file, or a
sound may be played, for example.
A variety of coping strategies exist when the server goes offline.
The image-transfer phone software may resend later, store the files
without reseeding them, or delete the files, for example. The
image-transfer personal-computer software may notify the user or
not, retry download or not, or fail over to another server, for
example.
The image-transfer phone software and image-transfer
personal-computer software may send diagnostic information to the
servers. If a client on either device encounters an error or
exception, it may send a message to the server (in the form of a
file in the image directory, or by an altogether separate
communication mechanism).
When new image-transfer phone software or image-transfer
personal-computer software connects to the server, it may create a
new user-account for the user of these devices and/or prompt for an
existing user account (including username and password) to properly
associate the devices.
When the image-transfer personal-computer software first attempts
to specify the image-transfer phone software that it wishes to be
"paired" with, the server may issue a verification request to the
image-transfer phone software, and only allow the pairing if the
request is successful. For example, it may transmit a message to
the image-transfer phone software via SMS asking the user to agree
to the pairing. The user agrees by opening a link contained in the
SMS message in the phone's browser. That link leads the phone back
to the server, verifying for the server that the pairing will be
allowed.
Extensions: Senior Software
The server may be configured to receive data from as-then unknown
phone and image-transfer personal-computer software. The server may
choose to discard the data, or store it for later transfer. If a
later client connects to the server and identifies itself, the
server may elect to forward the stored data from the first unknown
client to the second unknown client. At this point, both clients
might be considered to be "known" to the server.
The image-transfer phone software, server, and image-transfer
personal-computer software may update themselves. For example, the
image-transfer phone software might poll the server to find a new
version of itself, and if found, download and install it.
A variety of coping strategies exist when the image-transfer
personal-computer software goes offline. The server may hold the
files indefinitely or for a finite length of time before deleting
them. The server may transfer them to an alternate client. The
server may notify the user.
The image-transfer phone software may be polled by the server to
request photos. The image-transfer phone software may maintain an
open connection to the server, over which the server may send the
request to send photos present on the phone.
The server may push the images to the client without being
requested. The image-transfer personal-computer software may
maintain a connection to the server, over which the server pushes
files as they arrive on the system. For example, the image-transfer
personal-computer software's drive might simply be mapped to the
server so it may write the files to it using standard network
protocols.
The server may "pass through" the data directly to the client,
without ever storing it.
A fee may be charged for some or all aspects of this service. Fees
could be monthly, per-kb, or using any other pricing scheme.
Additional fees may be charged by service providers, for example
bandwidth charges billed through the phone carrier.
Files on the server may be accessible through other means. The user
may be able to access the photos while they reside on the server
using an alternate means, such as a web browser.
Extensions: Connections and Transfers
Media transfer may be made in either direction. The PC may upload
photos to the server, and the image-transfer phone software may
download them. Consequently, any time an image-transfer phone
software and image-transfer personal-computer software are
specified in this document, the scenario may be reversed.
Additionally, transfers may be made from image-transfer
personal-computer software to image-transfer personal-computer
software or image-transfer phone software to image-transfer phone
software. Consequently, the image-transfer personal-computer
software and image-transfer phone software are interchangeable.
The image-transfer phone software might be connected to the server
through alternate means. For example, the phone might be connected
by USB cable or by an 802.11 network connection, instead of by the
phone data network. The image-transfer phone software,
image-transfer personal-computer software, and/or server may
communicate over a given network to reach a different network
(i.e., an Internet bridge to the GSM network and vice versa) in
order to communicate.
The system may transfer files in discrete parts. The image-transfer
phone software may transfer an image file in segments, to be
reassembled into the complete image file, either on the server or
in the image-transfer personal-computer software.
Roundtrip confirmation is possible. The image-transfer phone
software may receive acknowledgment of a successful transaction.
For example, when the file has been successfully written, the
image-transfer personal-computer software and its checksum
verified, the image-transfer personal-computer software may inform
the server, which would in turn notify the image-transfer phone
software. The image-transfer phone software could then choose to,
for example, delete the file, knowing it had been safely
transferred.
Files may be transferred to a third party server instead of the
server or the image-transfer personal computer software. For
example, photos might be transferred to an internet-based
third-party photo hosting service. The transfer could occur
directly from the phone, bypassing the server, or from the server,
bypassing the image-transfer personal-computer software, or it
could occur once the files had been sent to the image-transfer
personal-computer software, as examples.
Files transferred may be routed selectively. For example the files
may be routed to different locations by the based on the file type
as determined by the three letter file extension, MIME type, or
other metadata. Images may also be routed based on content (for
example pictures which are inferred to be of landscapes may go to
one destination while images of people go to another). This may
happen at the image-transfer phone software, server, or
image-transfer personal-computer software level.
Files may be acted on immediately. Files may be routed to specific
applications for immediate handling, instead of being saved to
disk. For example, a sound might be routed to a media player for
immediate playback when it is received at the image-transfer
personal-computer software.
Different mechanisms may be used to track the state of the
transfer. Instead of changing the file name to indicate the state
of the file transfer, a secondary file may record the state of the
transfer process, or an altogether separate communication channel
using the phone, server, and/or image-transfer personal-computer
software may be used to send transfer status. It is also possible
to not record transfer status at all, and have the PC transfer
whatever is available immediately, or to have the image-transfer
personal-computer software infer when transfer is done (for
example, when less bits are transferred than the stated JPG image
size, the file is not complete).
File transfer may occur before the file has completely arrived at
the phone or server. For example, a video might be streamed over
the network instead of storing it locally, or it might be stored in
part locally, possibly with the local data deleted as it is sent
off to the server/image-transfer personal-computer software.
Different network protocols and systems may be used to transmit the
data. The server may use something other than FTP as the file
transfer protocol for transmitting files to the client. Any
protocol that allows the transfer of files would be sufficient. For
example, the phone may send the picture via the MMS protocol. In
this case, the server would receive the MMS message, decode the
attachment, and then proceed as if it had been conventionally
uploaded. The files may also be sent as E-mail, in which case the
server may receive and forward email as per a standard e-mail
server.
A proprietary piece of software may serve as the server. The server
may be running specialized software that does not allow the client
or the phone to have direct access to its file system, as FTP does.
It may have specialized software that supports any of the following
features: (1) it may authorized image-transfer phone software
programs, for example, using a proprietary interface to retrieve a
unique identifier from the phone and verifying the validity of the
identifier against a master lookup table, or (2) it may recognize
authorized software, for example by exchanging secret keys that are
stored in the program
Additional actions may occur as a result of the file transfers. For
example, the server may record how often files are delivered by a
user, how often they are downloaded by the client, or how large the
image is.
Extensions: Security
Image-transfer phone software programs, image-transfer
personal-computer software programs and server clients may exchange
keys with each other to authenticate or secure media transfers
between each other. A single entity may contain one or more keys
for one or more entities.
Linkage between phone and personal-computer programs may be
accomplished through a physical connection, then forwarded to the
server for validation. The user may not be required to input any
data at all to initiate the linkage between the two if, for
example, the physical connection has facilities to alert program
when such a physical connection is made.
The connection may be additionally secured. The image-transfer
phone software may allow the user to specify a password, which the
server software would require of any image-transfer
personal-computer software programs before allowing a successful
connection. Various security and cryptographic systems may be used
to further secure the connection.
The clients may come preinstalled with a set of encryption keys to
authenticate the server. These keys may be exchanged with new keys
from the server.
The phone and image-transfer personal-computer software programs
may choose to encrypt and decrypt media such that it is
unintelligible to the server. The server would store and forward
the encrypted data, but the data would only exist in unencrypted
form on the endpoint clients. The image-transfer personal-computer
software may decide to decrypt the data and send it back to the
server, so that the server may perform additional services on
behalf of the client (such as forwarding the unencrypted data to
other clients). The image-transfer personal-computer software may
also decide to act as "the server" and carry out many of the server
activities itself, without informing the server.
Extensions: Multiple Parties
Multiple clients may transfer images to each other. One or more
image-transfer phone software programs belonging to one or more
users may transfer images to one or more image-transfer
personal-computer software programs belonging to one or more users
(which may or may not be the same set of users as the first).
Multiple servers may be used. A variety of servers may accomplish
load balancing, enhanced security, and other goals. All servers may
serve a single transaction, or each transaction may be assigned to
one or more servers, or any other such combination. Servers may be
assigned based on any criteria, such as geographical proximity,
network proximity, type of file being transferred, or identity of
user.
The file to be transferred may be generated from different programs
or hardware. The standard camera-equipped phone software may be
used to generate an image, or the image-transfer phone software
might cause the onboard camera to take a picture to generate an
image, or a third party program may generate an image from code or
from the camera or another hardware device. Files may come from any
conceivable source, including user input, additional hardware, or
transfers from other devices.
The client or server software (the "system") may publicly or
privately make available APIs, ports, web services or other
programmatic access points for use by external or third party
devices or services. These parties may be permitted to route user
data into their service for additional processing. The system may
negotiate or mediate any or all communication between the third
party service and the user. The user may be required to grant
permission before the service is permitted to route the data as
such, or the data may be routed without the user's awareness. The
user may also instruct the system to cease communication with one
or more third parties. The system may provide a listing of third
party services to the user or alert users to the existence of new
third parties. The system may provide a different representation of
that user to each third party service (for example, a new unique ID
used only by that third party service to identify that particular
user as defined in a particular database) or it may provide
publicly identifying information about that user to the third party
(such as the user's phone number). A fee may be charged to the user
or to the third party service for accessing this functionality.
Extensions: Analysis
The system may generate new data by transforming or analyzing data
acquired by the system. This new data may be a new representation
of the existing data (for example, images may be scanned for text
and transferred into standard machine text formats by existing
character recognition methods). Or, the new data may only be
related to the existing data though nonobvious methods (for
example, a sound clip may be generated by converting each pixel in
an image into a musical note). The data may be used for an
additional chain of actions (for example, a picture of a bar code
may be converted into the UPC number, which is sent to an online
shopping center, which returns product record, which is converted
into a machine viewable layout of the product offering). This new
data may or may not be sent back to the user at the originating
device, another device, a PC, a designated web page, or any other
appropriate location. The data may be acted upon immediately by
some device, for example, a whiteboard is marked with a glyph such
that every picture of the whiteboard with the glyph drawn on it or
stuck to it via adhesive is automatically printed. Multiple methods
of creating new data may be applied to a single image acquired by
the system (for example, a single image may be analyzed for face
recognition, extracting street addresses, or picture color
content). A prefilter may be used to determine which analysis is
most appropriate for the picture; for example, a "bar code
detector" routes pictures with bar codes in them to the "bar code
reader" for further analysis. Additional examples of extraction and
analysis:
Scanning an image of a receipt to find expense and purchase data.
The extracted data can then be automatically inserted into a
database, bookkeeping, expense reporting or other financial system.
The original images can be collected and organized, for example by
date, for printing together.
An image containing contact information (such as a business card or
business letter) can be analyzed for business contact data, which
is then automatically inserted into a contact management system or
database present on one or more devices.
An image containing a car license plate can be scanned for license
plate information to be cross referenced against a state database
of automobile information.
An image of a commercial product is used to determine the product
and produces relevant information about the product, for example
showtimes and ticket purchasing for a movie poster, ringtones and
music downloads for a CD, and movie clips for a DVD. Alternately,
the picture may have a commercial product only incidentally
visible, for example a picture with a Mercedes in the background
results in an advertisement for a Mercedes.
An image (for example of a whiteboard) is automatically sent to the
printer if someone writes the word "print" on it in legible
handwriting.
An image has a steganographic code embedded in it which causes an
action to happen, e.g. a printed advertisement has a steganographic
code in it which causes the user to be emailed a copy of the
advertisement when a picture is taken of it.
An image of a logo of a commercial product is recognized as such
and causes any of the aforementioned actions to occur.
A person's face is recognized and causes additional actions to
happen.
Text is converted to machine-readable form and acted upon according
to its content, e.g. translated if it's French, faxed if it has the
word "fax" followed by a phone number, etc.
Any of the above interpretations of pictures cause someone to be
charged a fee, for example taking a picture of a particular coke
machine causes a coke to be dispensed and the user to be
debited.
A picture of an object causes the object to be validated, for
example a photo of a drivers license is analyzed and the user is
sent a message as to whether or not it is valid.
Multiple actions may be taken in the pursuit of commerce, for
example a picture of a product causes the user to be charged and
the inventory count of the item to be reduced by 1.
A picture of a physical credit card may be used to debit the
account as well as serve as evidence of the cards presence during
the transaction, for example by sending an image of the card's
signature to the authorizing company.
A vote may be tallied by photographing a glyph, image, text,
etc.
A paper form may be filled out and the user's entries extracted
from the general-purpose underlying form, then handled
separately.
Data may be queued up for later transmittal, for example a picture
may be showed to the picture-taker 5 years later as a "time
capsule."
The picture may be analyzed for predictive value for entertainment
purposes, such as a picture of a palm that is used to tell the
future.
The new data may also itself be analyzed for the purposes of
creating yet more data for the original user (for example, an image
may be scanned to identify a model of automobile, and that
information may be used to generate an advertisement for that
automobile, which is then forwarded to the user).
Data creating as described above may be returned to the user in
different formats across or across different communication
channels. The data may be returned to the user automatically or it
may be delivered only if the user requests the data. The data may
be added or inserted into databases or files known to belong to the
user (for example, a phone number extracted from an image may be
automatically added to the users contact list in her cell or that
data may be forwarded to third parties to perform additional
processing or storage on the user's behalf).
DETAILED DESCRIPTION OF THE INVENTION
The present invention is described, below, in the context of a
method and system for transferring digital-image data from cell
phones to personal computers, personal computers to cell phones,
and between cell phones, but the present invention is directed to a
much broader and more general transfer method for transferring many
different types of data between many different types of electronic
devices, as well as for establishing a service-application
environment and virtual communications medium and network to
support the data-transfer application. In a first subsection,
below, an overview of one approach to transferring data between
electronic hand-held devices and personal computers is provided. In
subsequent subsections, individual component methods and systems
that enable implementation of the data-transfer method and system
outlined in the first subsection are discussed, in detail, with
reference to control-flow diagrams and other technical
presentations.
In a final subsection, a more detailed discussion of the exemplary
data-transfer method and system outlined in the first subsection is
provided.
FIGS. 1 and 2 show prior art systems in which the inventive
concepts discussed herein can be utilized. FIG. 1 illustrates a
typical computer, hand-held-device, server, and communications
environment. In FIG. 1, a high-end server system 102 is
interconnected with a remote personal computer 104 via the
internet, or file transfer protocol (FTP) 106. The FTP 106
transfers data packets through various physical communications
media, including high-bandwidth optical lines, telephone lines, a
variety of routing computer systems, and other communications
media, including local networks and local wireless networks, using
a complex, hierarchically organized set of protocols. Cell phones
108 and 109 are connected through the phone network 110. The phone
network employs different protocols and different physical
communications media, although, as pointed out above, the phone
network and the Internet may share certain physical communications
media. Communication between cell phones 108 and 109 via the phone
network 110 is robust, user-friendly, and extremely economical,
just as data transfer by file-transfer protocols, email, and
Internet browser applications through the Internet is extremely
robust, user friendly, and economical. However, in many cases, data
transfer and communication between cell phones 108-109 and server
computers 102 and PCs 104 is difficult, not user friendly, time
consuming, and relatively expensive.
FIG. 2 shows the illustration conventions of FIG. 1, a scenario in
which economical and user-friendly data transfer from a cell phone
to a personal computer would be desirable. As shown in FIG. 2, the
cell phone 109 may be used to record a digital image of a scene 202
via a digital camera commonly included within cell phones. However,
most cell phones have only limited capacity for storing these
digital images, and currently, there are few practical services
available for transferring digital images from cell phones to other
devices and systems. It may be possible to physically transfer the
image from cell phone 109 to PC 104 via a removable memory device,
and it may also be possible to transfer the digital image from cell
phone 109 to PC 104 using a physical cable for electronically
interconnecting 204 the cell phone to the PC. Of course, while
direct electronic connection through cables requires that the cell
phone be brought to the location of the personal computer, or
vice-versa, it is often a relatively cumbersome, not-user friendly,
and slow procedure, involving loading special software, purchasing
cables compatible both with the cell phone and the personal
computer, and other such tasks. While removable memory-storage
devices can be used to store digital images transferred from the
cell phone until the removable storage devices can be, in turn,
physically transferred to the location of the personal computer,
purchasing removable storage devices with sufficient storage
capacity that are compatible both with the cell phone and the
personal computer may represent a challenge for many users, and
removable storage devices may be lost, damaged, or intermingled
with other removable storage devices containing other types of
data. It is also possible, in certain cases, to transmit digital
images from the cell phone 109 to the phone network 110, and from
the phone network to the Internet 106 for final transfer to a PC or
server using specialized multimedia messaging protocols. However,
acquiring access to such protocols may require installation of
applications on the cell phone and relatively cumbersome data entry
to the cell phone in order to install the transferred applications
and to direct transfer of digital images to a desired server or
personal computer. Moreover, in many cases, the transfer is not
secure, and may not be reliable. The occurrence of various types of
errors during transfer, for example, may result in loss of the
digital image.
FIG. 3 illustrates a high-level overview of one embodiment of the
present invention. FIG. 3 uses the same illustration conventions as
used in FIGS. 1 and 2. In FIG. 3, the server system 102, PC 104,
and cell phones 108 and 109 are shown to be linked, and in
communication with one another, through a virtual communications
medium and network 302. At the highest level, the present invention
is directed to creating a virtual communications medium and network
302 that allows personal computers, servers and main frame
computers, cell phones, and other electronic hand-held devices to
intercommunicate efficiently, reliably, economically, and securely.
At a second level, method and system embodiments of the present
invention are directed to service applications that execute in the
context of the virtual communications medium and network to provide
for data transfer, including transfer of digital images.
FIG. 4 illustrates the capture of a digital image and secure,
seamless transfer of the digital-image data from the cell phone to
the personal computer according to one embodiment of the present
invention. A user can transfer a digital image, for example, from
the user's cell phone to the user's personal computer
automatically, without user intervention, or via any number of user
interfaces as intuitive and easy to use as those employed to
connect a first cell phone to second cell phone through the phone
network.
The virtual communications medium and network (302 in FIG. 3)
created according to one embodiment of the present invention may
make use of the phone network, the Internet, a variety of different
physical communications media, protocols, and other complex layers
of software and hardware. It would be impossible to describe in
detail in this document, the organization and operation of all of
these communications media and software and hardware layers, and
such a description is unnecessary, since these communications
media, software layers, and hardware layers are generally well
known to those skilled in the art of communications, cell phones,
and computer systems. Rather than viewing the virtual
communications medium, or network, as a complex, multi-layered
combination of existing technologies, software, hardware, and
communications media, it is conceptually easier to view the virtual
communications medium as a collection of intercommunicating
applications or as one or more distributed applications.
FIG. 5 illustrates the conceptual, intercommunicating applications
that together comprise one view of the virtual communications
medium and network that represents one embodiment of the present
invention. As shown in FIG. 5, the virtual communications medium
302, and interfaces supported by the virtual communications medium,
can be viewed as a separate, intercommunicating server application
502, a PC application 504, and cell phone applications 506 and 508.
Alternatively, these separate, intercommunicating applications can
be viewed as a single distributed service application composed of
device-side and server-side service applications.
FIG. 6 illustrates intercommunication provided by the virtual
communications medium and network. As shown in FIG. 6, PC
applications, cell phone applications, and server applications can
transfer data among one another via the virtual communications
medium, with the server and server application 502 acting as a
central switch through which data transfers are routed. Unlike in
current environments, as shown in FIGS. 1 and 2 and described in a
previous section, the virtual communications medium created
according to the present invention allows PC applications and cell
phone applications to intercommunicate as peers, with both PC
applications and cell phone applications providing user-friendly
interfaces, when user-interfaces are desired.
FIGS. 7A-D illustrate, at overview level, the steps involved in
creating the virtual communications medium and network (302 in FIG.
3) to allow for peer-to-peer-like interaction between PC
applications and cell phone applications or within a distributed
service application. First, as shown in FIG. 7A, a PC user
interacts with a server application 502 running on a server system
to download the PC application to the PC. Once downloaded, as shown
in FIG. 7B, the PC can be viewed, at high level, as a PC
application 504. Next, as also shown in FIG. 7B, a PC user
interfaces with the PC application to direct the server application
to deploy a service on a particular cell phone 702. Then, as shown
in FIG. 7C, the server application 502 communications with the cell
phone 702 in order to determine the type of cell phone and other
parameters related to, and characteristics of, the cell phone.
Then, as shown in FIG. 7D, the server application 502 creates an
initial cell phone application and transfers the initial cell phone
application to the cell phone 704. The cell-phone application is
preconfigured with account credentials to facilitate subsequent
communication with the PC and server, so that subsequent
configuration of the cell-phone application is not necessary. The
initial cell phone application is launched, either automatically or
by a separate signal sent from the server application, and
transforms the cell phone into a multi-tasking cell phone
environment 706 in which the cell phone application can run as a
service application. Once the cell phone application is running as
a service application, the cell-phone application can communicate
with both the server application 502 and PC application 504 in a
peer-to-peer-like fashion, as illustrated in FIGS. 5 and 6.
As discussed in the previous section, with reference to FIGS. 7C-D,
an important step in configuring the virtual communications medium
and network (302 in FIG. 3) that allows for secure, robust, and
user-friendly intercommunication between cell phones, servers, and
PCs is deployment of a service application specifically tailored
for the hand-held electronic device, in the context of a
user-requested service related to.cndot.the electronic hand-held
device. Deployment of dynamically created service applications
("DCAs") is described in the current subsection. It should be noted
that, while a specific embodiment of the present invention is
discussed in this subsection, and in subsequent subsections, there
are a myriad of alternative embodiments that can be implemented
according to the present invention within the large variety of
different contexts for which service applications
intercommunicating through a virtual communications medium and
network can be crafted and configured. Although, in the following
discussions, the steps undertaken to accomplish various tasks and
subtasks are presented in particular orders, many of the steps may
be alternatively carried out in different orders, depending on
implementation strategies and the context of the problem domain
addressed by the implementations. A description of one or a few
embodiments of the present invention may address only a small
subset of the possible techniques and strategies for accomplishing
the set of tasks which together comprise the goals and
specification for an implementation of the present invention. Thus,
the following description of particular embodiments of the present
invention is in no way intended to limit the scope of
implementations and strategies that may be undertaken according to
the present invention.
FIG. 8 is a control-flow diagram for a routine deploy that 30
represents one embodiment of the present invention. The
control-flow diagram of FIG. 8 provides a highest-level overview of
a DCA creation and deployment method of the present invention. In
step 802, the routine "deploy," running on a server in the
described embodiment, receives a request from a user device,
typically a PC, to deploy a particular service to a different user
device, such as a cell phone. In general, a particular user
requests deployment of services to electronic devices owned and
controlled by the user, although, in more general cases, service
applications may be deployed to electronic devices automatically,
at the request of third parties, or in response to alternative
types of invocations. When deployment is requested to electronic
devices by third parties, or to electronic devices not owned or
controlled by the requester, various techniques and strategies may
be employed to ensure that services are deployed only with the
implicit or explicit permission and authorization of the device
owners and/or users.
In step 804, the routine "deploy" collects information from the
requester and, optionally, from additional users identified in the
request, needed for establishing and configuring the requested
service with respect to the target electronic devices. In step 806,
the routine "deploy" undertakes a process to identify and
characterize each target device to which the service application is
to be deployed. In step 808, the routine "deploy" creates a DCA for
each target device. Service applications are dynamically created
for each target device in order to, at the least, incorporate
target-device-specific information into each service application,
and, more generally, to tailor the service application for the
specific target device. In step 810, the routine "deploy" delivers
the DCAs created in step 808 to their respective target devices.
Finally, in step 812, the routine "deploy," when necessary,
undertakes installment of the delivered DCAs within their
respective target devices. These final two steps are commonly
combined and interleaved, but are shown separately in FIG. 8 for
conceptual clarity.
FIG. 9 is a control-flow diagram for the routine
"collectInformation," invoked in step 804 of the routine "deploy"
shown in FIG. 8. In step 902, the routine "collectInformation"
determines the users for which deployment of a service application
is undertaken. In the most common case, a single user requests
deployment of a service to one or more of the user's electronic
devices, but, in a more general case, the request may specify
deployment of a service for a set of users. The users may be fully
identified in the request received in step 802 of FIG. 8, or may be
only partially identified, requiring the routine "collect
information" to access additional information sources or to further
interact with the requester in order to fully identify all users of
devices to which the service application is to be deployed. In the
for-loop of steps 904-912, the routine "collectInformation"
collects needed user and user-device information for each user
identified in step 902. In step 905, the routine
"collectInformation" collects sufficient information to identify
the currently considered user. In this step, for example, the
routine "collectInformation" may query a user or application
running on a user's PC for information needed to identify that the
user or user application is the user for which deployment is
requested. Queries may involved request and receipt of passwords,
user identifiers, and other information that may be matched to
previously acquired information stored by the server on which the
routine "collectInformation" runs, and may alternatively involve a
wide variety of other user-identification techniques, including
biometric analysis of user-supplied data, or alternative methods of
identifying the user.
Next, in step 906, the routine "collectInformation" may collect
additional user-related information, including the PC network
address for the user's PC, the user's email address, billing
information, if the billing information has not been previously
stored, characteristics and capabilities of the user's PC or other
device, and other such information. If the user is not the entity
requesting deployment, as determined in step 907, then the routine
"collectInformation" may optionally request permission of a user
for deployment of the service application to the user's devices in
steps 908 and 909. Next, in step 910, the routine "collect
information" determines the target devices for the currently
considered user to which the service application is to be deployed.
This information may be included in the request received in step
802 of FIG. 8, or may involve additional queries or access to
previously stored information. In step 911, the information
collected for the user and for the user's target devices is stored
in a user/target list that directs creation and deployment of DCAs
in subsequent steps of the routine "deploy."
FIGS. 10A-D describe one embodiment of the target-device
identification step 806 of the routine "deploy" shown in FIG. 8.
FIG. 10A is a control-flow diagram for the routine
"identifyTargetDevices" called in step 806 of FIG. 8. The routine
"identifyTargetDevices" comprises a for-loop of steps 1002-1007 in
which each target device included in the user/target list prepared
in step 911 of FIG. 9 is identified and characterized. In step
1003, the user-supplied information characterizing the currently
considered target device is transformed into an address and
putative device type, generally by accessing stored information
concerning general device types, device-related information, and
perhaps specific information regarding the devices owned and used
by users previously collected and compiled by the server. Certain
data tables that can facilitate this step are discussed in a
subsequent subsection. Then, in step 1004, the routine
"identifyTargetDevices" sends a reference, such as a URL, to the
target device, in certain cases in the form of an installation
message. When the installation message is received by the target
device, a prompt may be displayed on the target device that, when
accepted or acknowledged by a user of the target device, or
automatically, generates a request directed to the reference, such
as a URL, that is received and processed by the server. The
device's response to the installation message is then used by the
server, as described below, to identity the type of device and
characterize the device. In step 1005, the routine
"identifyTargetDevices" notes that an installation message was sent
to the target device and sets a retry count for the target device
to 0. In general, the routine "identifyTargetDevices" stores a
record indicating that the installation message was sent in memory
or in a database. Then, in step 1006, the routine
"identifyTargetDevices" sets a timer for the installation message,
in order to detect failure of the target device to respond, as
described subsequently.
FIGS. 10B-C show a control-flow diagram for a handler that
continuously executes on the server to handle events associated
with the above described routine "identifyTargetDevices." In step
1010, the handler waits for a next event. When a next event occurs,
the handler awakens and, in step 1012, associates a particular
target device and stored state information related to that target
device with the event. If the event is a response to an
installation message sent in step 1004 of FIG. 10A, as determined
in step 1014, then, in step 1016, the handler invokes a routine to
determine the type of device and characterize the device from the
request/response message sent by the target device in response to
the installation message. If the device type can be determined and
the device frilly characterized from the request/response message,
as determined in step 1018, then the device type and device
characterization is stored in memory, and the state information
associated with the target device is deleted, in step 1020,
completing identification and characterization of the target
device.
Otherwise, in step 1022, the handler selects a probe application
for the device and transmits the probe application to the target
device. A probe application is selected based on the best guess as
to the type of device that cart be made based on the
response/request message received from the device and any other
device information previously accessed and associated with the
target device. If, in addition to sending the probe application, a
separate installation message or signal needs to be sent by the
handler in order to launch or invoke the probe application on the
target device, as determined in step 1024, then, in step 1026, the
handler transmits the installation message or signal to the target
device following a sufficient period of time for the transmitted
probe application to be received and processed by the target
device. Rather than waiting for the needed period of time, the
handler may simply transmit the probe application, in step 1022,
and then set a timer to subsequently reawaken the handler for
transmitting the installation message or signal. Next, in step
1028, the handler sets a timer associated with deployment of the
probe application to the target device and, in step 1029, records
the fact that the probe application was sent to the target device
and sets a retry counter to 0, in step 1029. If the event that
awakened the handler is a response to a probe installation, as
determined in step 1030, then, in step 1032, the handler invokes a
routine to determine the type of the target device and characterize
the target device based on a message received from the executing
probe application. If, as determined in step 1034, the type of
device is fully determined and the device sufficiently
characterized based on the probe-application message, then, in step
1036, the device type and characterization is stored in memory, and
state information associated with the target device is deleted.
Otherwise, in step 1038, the failure to identity the device from
the probe information is noted in memory. If, as determined in step
1040, there is another probe application that may be sent to the
target device to attempt to identify the type of the target device,
the next probe application is selected and transmitted to the
target device in step 1042, and control flows to previously
described step 1024 for installation of the transmitted probe
application and setting of a timer associated with transmission of
the probe application. If no additional probe application can be
sent to the target device, then, in step 1044, the failure to
identify or characterize the target device is recorded, and target
device information is removed from the user/target list to prevent
additional service-application-deployment steps directed to the
target device. Various different types of actions may be taken,
upon failure to identify and characterize the target device, in
different implementations of the DCA creation and deployment method
of the present invention.
If, as determined in step 1046, the event that wakened the handler
is an expiration of a timer associated with a transmission of a
first installation message, then, in step 1048, the handler
determines the number of times that target identification has been
tried. If the number of attempts to identify the device exceeds a
maximum threshold value, as determined in step 1050, then complete
failure to identify and characterize the device is noted in step
1052, and the target device is removed from the user/target list
prepared in step 911 in FIG. 9. Otherwise, a new message containing
a reference is sent to the target device in a new installation
message, in step 1054, the retry counter is incremented in step
1056, and the timer for the installation message is reset in step
1058. If the event that awakened the handler is expiration of a
timer associated with a probe application, as determined in step
1060, then in step 1062, the handler determines the number of times
that probe application has been tried on a target device. If the
number of times that the probe application has been tried exceeds a
maximum threshold value, as determined in step 1064, then a
complete failure is noted, and the target-device information is
removed from the user/target list in step 1066. Otherwise, the last
transmitted probe application is retransmitted to the target
device, in step 1066, and additional steps for launching the probe
application, resetting of the probe-application-related timer and
updating the retry counter are carried out in steps 1068-1071.
Otherwise, any other event that awakened the handler is handled in
a default handler routine of step 1072. In all cases, following
handling of the event that awakened the handler, control returns to
step 1010, where the handler waits for a next event.
The handler implementation is somewhat simplified, in FIGS. 10B-C,
to facilitate description of the present invention. In general,
handlers may be designed to handle multiple events that may occur
concurrently while the handler is active, rather than being
explicitly invoked for each separate event. However, general
construction and implementation of handlers is well known, and such
details would serve only to obscure the essence of the present
invention.
FIG. 10D is a control-flow diagram that generally describes
identification and characterization of a target device from a
request/response message received from an initial installation
message or from a probe application, in steps 1016 and 1032 of FIG.
10B. In certain embodiments of the present invention, separate
device-identification routines may be implemented for steps 1016
and 1032 of FIG. 10B, while in alternative embodiments, a common
device-identification routine may be invoked from either of steps
1016 and 1032. In step 1080, the routine "determineDeviceType"
determines whether the request/response message was returned by a
probe application. If so, then in step 1082, the routine
"determineDeviceType" determines whether an explicit type was
included in the message received from the probe application. If so,
then in step 1084, the explicit device type is returned, along with
any additional information related to characterization of the
device. Certain types of probe applications may invoke functions on
the target device to determine the device type. Alternatively,
probe applications may access various functions and features of a
target device and determine the type of the target device based on
the behavior of the target device. However, if the message is not
returned by a probe, or does not include explicit type information,
then, in step 1086, the routine "determineDeviceType" extracts
type-related information from the request/response message header
or headers. Often, headers in messages sent from a target device
include sufficient information to infer the type of the target
device. In step 1088, when necessary, the routine
"determineDeviceType" extracts any type-related information that
can be gleaned from the request/response message body. Then, in
step 1090, the routine "determineDeviceType" applies a set of rules
to the information extracted in steps 1086 and 1088 to determine
and characterize the target device based on the extracted
information. If application of the rules to the extracted
information unambiguously determines a device type, and further
characterizes the device, as determined in step 1092, then the
device type and additional characterization is returned in step
1094. Otherwise, failure to determine the device type is determined
in step 1096.
FIG. 11 is a control-flow diagram illustrating the routine
"createDCA" called from step 808 of FIG. 8. The routine "createDCA"
is essentially two nested for-loops, beginning in steps 1102 and
1104, in which a DCA is created for each target device for each
user described in the user/target list prepared in step 911 of FIG.
9. If source code needs to be compiled or assembly code assembled
for the DCA, as determined in step 1106, then the source code is
compiled and/or assembly code assembled in step 1108. Thus, dynamic
creation of a service application may involve on-the-fly
compilation or assembly, to enable particular source code or
assembly code suitable for the target device to be collected and
compiled and/or assembled with particular compiler flags and
assembler flags and parameters suitable for the target device. If,
as determined in step 1109, existing executables need to be
modified to create a DCA tailored for the target device, as
determined in step 1109, then the executables are accordingly
modified in step 1110. Modifications may include renaming the
executables, or it may include altering data sections contained in
the executables, changing headers of the executables, or other such
modifications. If, as determined in step 1112, additional
executables need to be identified and collected in order to prepare
a DCA specifically targeted to the currently considered target
device, as determined in step 1112, then the additional executables
are located and collected in step 1114. The executables, modified
executables, and on-the-fly compiled and/or assembled executable
code obtained in steps 1108, 1110, and 1114 are assembled together
to produce an executable service application tailored for the
currently considered target device in step 1116. The product of
step 1116 may be a single executable, a single executable with
additional library routines, a set of executables, or other forms
of executable service applications suitable for the currently
considered target device.
Next, in step 1118, the routine "createDCA" determines whether
additional clients need to be activated for provision of particular
functions on the target device, transmitted to, and installed on,
the target device, or otherwise invoked on the target device.
Clients are executables or libraries that provide a set of
well-defined functions that can be called by one or more service
applications, and may be separate entities or embedded in service
applications. If additional clients need to be transmitted to, or
activated on, the target device, then, in step 1120, the minimal
set of clients that need to be transmitted to, or activated on, the
target device is determined. The clients may be included in the DCA
or separately transmitted to, and installed on, the target
device.
Next, in step 1122, the routine "createDCA" determines whether
additional data needs to be included in the DCA. If so, then, in
step 1124, the routine "createDCA" determines whether any of the
additional data needs to be transformed into executable code. If
so, then that portion of the additional data that needs to be
transformed into executable code is so transformed in step 1126.
For example, the DCA may need to access data describing a screen
layout or menu that forms part of a user interface for the service
application on the target device. The data may be explicitly
included in the DCA, or executable code may be included in a DCA to
generate the data when executable code is executed on the target
device. In step 1128, the routine "createDCA" determines whether
any additional data needs to be appended to the DCA. If so, then
that additional data is appended to the DCA in step 1130. In step
1132, the routine "createDCA" determines whether the DCA requires
references, such as URLs, to data stored remotely from the target
device. If so, then those references to remotely stored data are
added to the DCA in step 1134. Thus, data needed by the service
application on the target device may be transmitted for storage on
the target device, generated by executables running on the target
device, or accessed by the service application from remote data
sources during execution of the service application on the target
device. In step 1136, the assembled executables generated in step
1116 are packaged together with the added references, data, and
data-generating executables produced in steps 1126, 1130, and 1134
to produce a final DCA. If the DCA needs to be signed and/or
encrypted, as determined in step 1138, then the DCA is digitally
signed and/or encrypted in step 1140. A wide variety of different
digital signing and encryption techniques, including public/private
encryption key-based techniques, can be employed to ensure that a
DCA created and tailored to a particular target device cannot be
intercepted and used by another device.
FIGS. 12A-B include control-flow diagrams that describe the
delivery of DCAs to target devices invoked in step 810 of FIG. 8.
FIG. 12A shows a control-flow diagram for a routine "deliverDCA."
The routine "deliverDCA is a for-loop, beginning with step 1202,
that delivers the DCA prepared for each target to its corresponding
target device. Note that, in the described embodiment, all DCAs are
prepared for target devices prior to delivery of the DCA to their
respective target devices, although in alternative embodiments,
steps 808 and 810 of FIG. 8 may be interleaved so that the DCA is
immediately delivered to its target device prior to preparation of
subsequent DCAs for subsequent target devices. In step 1204, the
DCA prepared for the currently considered target device is
selected. If the DCA is to be delivered electronically, as
determined in step 1206, then, in steps 1208-1212, a download
message is sent to the target device to direct the target device to
download the DCA from the server, in step 1210, in the case that a
pull paradigm is appropriate for the target device, or, otherwise,
the DCA is sent in one or more messages to the target device in
step 1211 and, in either case, download or transmission of the DCA
is noted, in memory in step 1212. If the DCA is not delivered
electronically, then the DCA may be physically delivered, in step
1214, with physical delivery of the DCA noted in memory in step
1216. Determination of whether or not to electronically deliver the
DCA, in step 1206, may be made based on characteristics of the
target device, pre-collected user preferences, or other such
information. Electronic delivery may occur through the phone
network, the Internet and the phone network, or through cables or
other direct connections between the target device and the server
or a PC in communication with the server. Physical delivery of the
DCA may occur by encoding the DCA on a data storage medium, such as
a CD, DVD, memory stick, or other such data-storage medium, and
physically transporting the data-storage medium to a user of the
target device via mail or package-delivery services.
FIG. 12B shows a handler associated with the routine "deliverDCA."
In step 1220, the handler waits for a next event associated with
DCA delivery. When that event occurs, the handler looks up DCA
information related to that event in step 1222. If the event is a
timer expiration, as determined in step 1224, then the handler
accesses retry counter information in the DCA information
associated with the event, in step 1126. If delivery has already
been tried a maximum number of times, as determined in step 1228,
then the DCA information is deleted from the server, and failure to
deliver is noted, in step 1230. Otherwise, the DCA is retransmitted
to the target device, in steps 1232-1234, the timer is reset in
step 1236, and the retry counter is updated in step 1238. If
installation is not automatic, as determined in step 1240, then in
step 1242, the handler sends an appropriate installation message or
signal to the target device. In alternative embodiments, sending of
installation messages and signals occur in response to an
additional event, such as expiration of a timer, set by the
handler, rather than a handler waiting for delivery of the DCA. If
the event is a reception of a delivery-complete message, as
determined in step 1244, then the DCA information associated with
the event is deleted from server memory, and installation data
tables are updated to reflect successful deployment of the DCA to
the target device, in step 1246.
If the event corresponds to reception of an improper installation
message, as determined in step 1248, then the improper installation
problem is diagnosed, in step 1250. In certain cases, as determined
in step 1252, installation may be retried, while in other cases,
DCA deployment is considered to have failed, and the DCA
information associated with the event is deleted from memory and
the failure noted, in step 1254. Any other events are handled by a
default event handler in step 1256. In the described embodiment,
the handler waits to receive a delivery-complete message from the
target device for considering the DCA to be successfully deployed.
In alternate embodiments, the "deliverDCA" routine may explicitly
inquire, via messaging or other means, whether the target device
has received and successfully deployed the DCA.
FIG. 13 shows a control-flow diagram for the routine "installDCAs"
invoked in step 812 of FIG. 8. This routine sends an explicit
installation message or signal to target devices that require
installation messages or signals to invoke installation of a
deployed DCA. The installation messages or signals may
alternatively be sent by the routine "deliverDCA" shown in FIG.
12A, or may be sent from the DCA handler, as shown in FIG. 12B,
following expiration of a timer set by the routine "deliverDCA" to
allow for a reasonable amount of time between transmission of the
DCA to the target device and installation.
Next, the method for determining the minimal set of clients to add
to a DCA, a routine for which is invoked in step 1120 of FIG. 11,
is described with reference to FIGS. 14 and 15, exemplary SQL-like
pseudocode, and two control-flow diagrams provided in FIGS. 16 and
17. FIG. 14 illustrates the meaning of the terms "service
application," "client," and "function" with respect to embodiments
of the present invention.
FIG. 14 illustrates a server 1402 and target device 1404 are shown
as blocks. A service application that provides for a service
accessed from the target device can be considered to be distributed
between the server and target device, with a server-side
service-application portion 1406 executing on a server and a
device-side service-application portion 1408 executing on the
target device. The device-side service application may invoke
functions provided by one or more clients that execute on the
target device. A client may be embedded within a service
application, such as embedded client 1410, may be independent
executable entities that run on the target device, such as client
1412, or may be embedded in a different service application from
the service application that invokes functions provided by the
client, such as embedded client 1414 in FIG. 14. Clients are
analogous to shared library routines accessed by programs executing
on a personal computer.
Many hand-held electronic devices have limited memories and limited
computational capacities. In these devices, it is important to
install only as many clients as needed by the services currently
deployed to the target device and by the native target-device
control program and application. Thus, when a DCA is deployed to a
target device, method and system embodiments of the present
invention endeavor, in step 1120 of FIG. 11, to deploy and activate
a minimal set of clients needed for deployment of a service
application to the target device.
There are many different ways to monitor deployment and activation
of clients and functions provided by clients on target devices, and
to determine a minimum set of additional clients and function
activations needed for deployment of a particular service
application. In one embodiment, information related to deployment
of service applications and clients to target devices is maintained
in a set of relational-database tables on a server, which are used
in order to determine a minimal set of client deployments and
client-function activations needed during deployment of a service
application, in step 1120 of FIG. 11.
FIG. 15 illustrates a set of relational tables that may be used to
store information related to service-application and client
deployment installation on target devices according to one
embodiment of the present invention. The table Services 1502 stores
information related to services deployed on target devices,
including a service ID, service type, and service_location field
for each deployed service application. Similarly, the table Clients
1504 and the table Functions 1506 store information regarding
deployed clients and functions provided by clients. The table
Functions Provided 1508 stores client_ID/function_ID pairs
indicating those functions provided by each client, and the table
Functions Needed 1510 stores service_ID/function_ID pairs that
indicate the particular functions needed by each different service
application. The table Service_Client_Compatibility 1512 stores
service ID/client ID pairs that indicate which clients are
compatible with which service applications, and the table Sharable
1514 stores service ID/client ID pairs that indicate clients that
may be sharable with respect to particular service applications.
The table Users 1516 includes information about each different
user, including a user_ID, user name, and additional user
information fields. The table Devices 1518 describes each device
controlled or owned by users known to the system. The table
Device_Client_Compatibility 1520 stores device type/client ID pairs
that indicate which clients are compatible with which device types,
and the table Device Service Compatibility 1522 stores
device_type/service_ID pairs that each indicates that a service is
compatible with a device type. The table Installed Services 1524
includes device_ID/service_ID pairs that describe which service
applications are installed on which devices, the table
Installed_Clients 1526 stores device_ID/client_ID pairs that
describe which clients are installed on the various devices known
to the system. Finally, the table Active_Functions 1528 stores
device_ID/client_ID/function_ID triples that describe functions
activated for each client on each target device.
FIG. 16 is a control-flow diagram illustrating a routine that
determines the minimal set of clients to add to a target device in
the course of deploying a service application, called in step 1120
of the routine "createDCA" described in FIG. 11. Various steps in
FIG. 16 are illustrated with SQL-like pseudocode. In the SQL-like
pseudocode, the variables S and T are defined as follows:
S=service ID of service to be installed
T=device_ID of target device
First, in step 1602, the routine determines the functions that are
needed by the service application to be deployed. SQL-like
pseudocode for this step, using the relational tables shown in FIG.
15, is next provided:
CREATE TABLE F
(function_ID INTEGER);
INSERT INTO F
SELECT DISTINCT function_ID
FROM Functions_Needed
WHERE service_ID=S;
If there are no functions needed, as determined in step 1604, then
an indication that no clients need to be added is returned, in step
1606. Next, in step 1608, the routine determines which of the
needed functions are provided by compatible clients already
installed on the target device. SQL-like pseudocode for this step
is next provided:
TABLE-US-00001 CREATE TABLE A (function_ID INTEGER); INSERT INTO A
SELECT Client_ID, function_ID FROM Installed_clients I,
Functions_Provided P, Service_Client_Compatibility C, Sharable SB,
F WHERE I.client_ID = P.client_ID AND I.device_ID = T AND
C.service_ID = S AND C.client_ID = P.client_ID AND SB.service_ID =
S AND SB.client_ID = P.client_ID AND P.function_ID IN (SELECT
function_ID FROM F) GROUP BY function_ID;
In step 1610, the functions already provided by compatible clients,
determined in step 1608, are subtracted from the functions needed
by the service application, determined 5 in 1602, to produce a
final list of functions needed on the target device for the service
application. SQL-like pseudocode for this step is next
provided:
DELETE
FROM F
WHERE function_ID IN
(SELECT DISTINCT function_ID
FROM A);
Next, in step 1612, the routine determines whether any of the
already-available functions, determined in step 1608, need
activation. Those functions needing activation are noted in a list
of needed function activations in step 1614 that are eventually
returned to the routine "createDCA." SQL-like pseudocode for
determining functions that need activation is next provided:
DELETE
FROM A
WHERE function_ID IN
(SELECT DISTINCT function_ID
FROM Active_Function
WHERE device_ID=T
AND client_ID IN
(SELECT DISTINCT client_ID
FROM A);
If functions are still needed on the target device, as determined
in step 1616, then, in step 1618, the routine determines a set of
candidate clients that provide the needed functions. SQL-like
pseudocode for this step is next provided:
TABLE-US-00002 CREATE TABLE CANDIDATES (client_ID INTEGER,
function_ID INTEGER); INSERT INTO CANDIDATES SELECT DISTINCT
client_ID, function_ID FROM Functions_Provided P,
Service_Client_Compatibility C, Device_Client_Compatibility D,
Devices DS, Sharable SB, F WHERE P.client = C.client_ID AND
C.service_ID = S AND D.device_type = DS.device_type AND D.client_ID
= P.client_ID AND DS.device_ID = T AND P.client_ID = SB.client_ID
AND SB.service_ID = S AND P.function_ID IN (SELECT function ID FROM
F) GROUP BY client_ID DESC
If a single candidate client can provide all the needed functions,
as determined in step 1620, then a single candidate client is
selected from all candidate clients that provide all the needed
functions in step 1622 and added to the return list. SQL-like
pseudocode for obtaining a list of candidate clients that provide
all of the needed functions is next provided:
SELECT COUNT (*)
FROM F
INTO Z;
SELECT CD.client_ID
FROM CANDIDATES CD
WHERE Z=
(Select Count (Distinct Function_ID)
From Candidates Ct
WHERE CT.client_ID=CD.client_ID)
Otherwise, in the for-loop of steps 1622-1625, possible
combinations of two, three, and greater numbers of candidate
clients are considered to determine the minimal number of candidate
clients necessary to provide all the needed functions. Once a
suitable candidate combination is found, that client combination is
returned in step 1624. If no combination of clients can be found to
provide the needed functions, then failure is returned in step
1626. The list returned by the routine to the routine "createDCA"
can then be used by the routine "createDCA" to include clients and
instructions for function activation of existing clients into the
DCA, to undertake 15 explicit function-activation steps with
respect to the target device, and/or other steps in order to ensure
that the minimal set of clients as needed by the service
application is installed on the target device and that the needed
functions are activated.
In certain embodiments of the present invention, a user may invoke
a method for removing a service application from a target device,
or the method may alternatively be automatically invoked by the
user's PC or the server under certain circumstances.
FIG. 17 provides a control-flow diagram for a
remove-service-application routine. In step 1702, the routine
determines those functions needed by the service application that
is to be removed. In step 1704, the routine determines which of
those functions needed by the service application to be removed are
needed by other applications that remain on the target device.
Using this information, the routine determines, in step 1706, the
functions that are no longer needed on the target device once the
service application to be removed is removed from the target device
and, in step 1708, deactivates those unneeded functions by whatever
techniques are appropriate for deactivating functions on the target
device. If, as determined in step 1710, any clients on the target
device have all functions provided by the clients deactivated, and
are therefore unneeded on the target device, then those clients are
deleted from the target device in step 1712. Finally, in step 1714,
the service application is marked for deletion or deleted from the
target device. Thus, by 10 maintaining only a minimal set of
clients on a target device needed by the service applications
currently deployed to that target device, the present invention
minimizes the memory and computational resources devoted to service
applications on target devices so that target-device performance is
minimally impacted by the service applications, and so that a
maximum number of service applications may be deployed to the
target device.
Link-Based Inter-device Communication
As discussed in previous subsections, with particular reference to
FIG. 6, method and system embodiments of the present invention
provide a virtual communications medium and network that allows
electronic hand-held devices, servers, and PCs to intercommunicate
securely and relatively seamlessly, from the standpoint of users.
This intercommunication, however, is implemented within the
currently existing environment, such as the communications
environment illustrated in FIG. 1. The virtual communications
medium and network provided by method and system embodiments of the
present invention is based on the establishment of links between
devices.
FIG. 18 illustrates the concept of a link. In FIG. 18, a first
device 1802 communicates with a second device 1804 via a link 1806.
The link is shown traversing the server 1808, since, as discussed
above, the server, or servers in multiple-server systems, acts as a
switch for routing messages and data between devices.
FIG. 19 illustrates implementation of the link shown in FIG. 18.
The link is composed of a first two-way secure connection 1902
between the first device 1802 and the server 1808 and a second
secure connection 1904 between a second device 1804 and the server
1808. The link is a logical entity, and may persist logically
despite destruction and re-establishment of secure connections.
Each device is associated with a global, unique ID 1906 and 1907
that allows devices to identify themselves to the server and to
other devices. The server maintains a mapping of devices to IDs
1908 as well as a link table 1910 that describes all currently
active links within the system. In FIG. 19, one embodiment of the
link table 1912 is shown as a relational table, although any of a
variety of different table implementations is possible. Each active
link is described by a row in the table, and each row includes the
following fields: (1) a link_ID that uniquely identifies the link
1914; (2) the ID of the device that initially requests the link
1916; (3) the ID of the device that is the target for the request
1918; (4) the ID of the device that serves as the source of
information during link operation 1920; (5) the ID of the device
that serves as a sink for information during operation of the link
1922; (6) an indication of the type of link 1924 that, in turn,
specifies the operations that may occur over the link; and (7) an
indication of the state of the link 1926, described below.
Although, in this discussion, links are generally considered
unidirectional, the may also be bidirectional. In image-transfer
applications, for example, information may be returned by a PC to a
cell-phone to alter the rate, timing, and type of images
subsequently sent to the PC by the cell phone over a link.
FIG. 20 illustrates establishment of a link according to method and
system embodiments of the present invention. In FIG. 20, actions
for the link-requesting device are shown in a first column 2002,
actions associated with a link carried out by the server shown in a
second column 2004, actions associated with the target of the link
request are shown in a third column 2006, and the current state of
the link is shown in column 2008. In a first step, the requesting
device sends a link request to the server indicating the target
device for the link request as well as the type of link requested
2010. Upon receiving the link request, the server enters a new
entry into the link table and forwards the link request to the
target device 2012. At this point, the state of the link is "link
requested" 2014. When the target device receives the link request
2016, the target device may either return a message to the server
indicating that the target device declines their request 2018 or
may return a message to the server indicating that the target
device accepts the link request 2020. When the target device
declines the link request, the server receives the refusal and
updates the link table entry for the link request to indicate that
the link has been refused 2022, then forwarding the refusal to the
requesting device. The requesting device 2024 receives that
refusal, and acknowledges receipt of the link refusal, at which
point the state of the link becomes "no link." At an appropriate
point in time, the entry for the link in the link table is deleted.
On the other hand, when the target device accepts the link, the
server receives the acceptance, updates the link table entry for
the link, and forwards the acceptance to the requesting device
2026. At this point, the state of the link is "link accepted." The
requesting device receives the acceptance and acknowledges the
acceptance to the server 2028, upon which the server updates the
link status to "link up" 2030. Thus, each link between devices must
be requested by a device, and the link request must be accepted by
the target device before the link is established. Messages and data
are sent over the link in a two-part process. The source device
sends messages and data to the server by whatever communications
medium interconnects the source device to the server, and the
server forwards the messages and data to the sink device by
whatever communications medium and method is used to transfer
messages and data between the server and the sink device. The link
is therefore a virtual communications link implemented using
several underlying, dissimilar communications media and methods and
message and data routing by the server. The secure connections
between devices and the server are implemented by clients deployed
to the device.
FIG. 21 illustrates establishment of a secure link between a client
running on a device and a server according to one embodiment of the
present invention. In FIG. 21, client actions are shown in a first
column 2102 and service actions are shown in a second column 2104.
In one embodiment, the client is compiled with a server
authentication key, or, in other words, a public encryption key. In
a first step, the client generates a public/private encryption-key
pair as well as a random ID 2106. In step 2108, the client sends
the public key of the encryption-key pair and the random ID to the
server, encrypted using the server public key included in the
client. In step 2110, the server receives the encrypted public key
and random ID and decrypts the public key and random ID. If the
server has seen the public key/random ID pair in the past, as
determined in step 2112, then the server rejects the random ID
generated by the client by sending a rejection message in step
2114. When the client receives the rejection message in 2116, the
client can either retry secure-connection establishment or can
consider establishment of the secure connection to the server to
have failed. When the public key/random ID pair has not been
previously observed by the server, as determined in step 2112, the
server returns the public key and random ID pair to the client, in
step 2118, signing the message with the servers private server key.
In step 2120, the client receives the public key/random ID pair
from the server and verifies that the server digitally signed the
message using the server authentication key that was compiled with
the client. The client can then use the random ID as the ID for the
client in future communications, in step 2122. In further
communications with the server, the client can encrypt messages and
data using the client's private key, and the server can decrypt the
communications and data using the public key transferred from the
client to the server. Thus, communications over a secure connection
between the device and the server cannot be intercepted or used by
other devices, including even other devices to which the device is
linked by a virtual link discussed above with reference to FIGS. 18
and 19.
Establishment of a Multi-Tasking Environment on an Electronic
Hand-Held Device
As discussed above, many electronic hand-held devices, including
many cell phones, lack the hardware and software to provide a
robust, multi-tasking environment for execution of service
applications. In general, service applications need to continuously
or intermittently execute on an electronic device, in order to
field and respond to a variety of events associated with service
provision, just as an operating system needs to continually execute
on a personal computer in order to respond to user commands,
incoming communications, and various interrupts and device-related
events. On a single-processor system, continuous execution is
simulated by running concurrently executing processes for small
periods of time, or time slices, and interleaving the time slices
of different processes to provide the illusion that all executing
processes are executing simultaneously. In other words, process
execution is time-multiplexed on the processor. Method and system
embodiments of the present invention establish a robust,
multi-tasking computing environment on electronic hand-held devices
prior to deployment of, or as part of the process of deploying,
service applications to the electronic hand-held devices. When the
devices are sufficiently sophisticated to offer a robust,
multi-tasking environment, method and system embodiments of the
present invention avail themselves of that functionality. However,
in the more common case that a robust, multi-tasking environment is
not provided by the electronic hand-held device, method and system
embodiments of the present invention use whatever tools that are
available within the electronic hand-held device, the network
interconnecting the electronic hand-held device with a server, and
the server to establish a computational environment in which
service applications can be deployed to, and execute on, the
electronic hand-held device.
Applications running in multi-tasking environments commonly need a
mechanism for interprocess communication. In computer systems,
interprocess communication is commonly implemented using shared
memory and/or interprocess messaging facilities. The electronic
hand-held device is shown as a first block 2202 and the server is
shown as a second block 2204. FIG. 22 illustrates a number of the
possible methods by which interprocess communication can be
implemented in an electronic hand-held device in communication with
a server when the electronic hand-held device does not offer native
interprocess communications, according to method and system
embodiments of the present invention. In FIG. 22, the electronic,
hand-held device is shown as a first block 2202 and the server is
shown as a second block 2204. One way to achieve interprocess
communication is to use local memory 2206 within the device for
storing messages and data forwarded by one process to another. For
example, queues or mailboxes may be implemented within the local
memory to allow messages and data to be stored for subsequent
delivery to other processes. Alternatively, in certain devices,
facilities may be provided for general transmission and reception
of messages. Those facilities may be used for transmitting messages
internally, between processes, when different processes can be
identified and addressed. For example, in certain systems,
processes may register to receive messages and notification of
incoming-message events. Alternatively, certain devices provide for
remote procedure calls ("RPCs"), which can be used to transfer data
and messages between processes. When no such facilities are
provided by the device, external messaging through the
communications medium connecting the device to the server may be
employed for sending messages between processes running on the
device. For example, a process may run on the server for receiving
messages from the device and forwarding the received messages back
to target processes on the device. Although relatively inefficient,
this latter technique is nonetheless commonly available for most
cell phones and other communications devices.
Processes running in multi-tasking environments generally need to
be able to persistently store data, so that the process can
continue to work on a task over a number of time slices and periods
of quiescence. FIG. 23 displays various methods for implementing
persistent data storage on an electronic hand-held device, when
persistent data storage facilities are not explicitly provided by
the device according to method and system embodiments of the
present invention. First, local memory 2302 within the device can
be partitioned among processes by memory allocation or by
convention. Alternatively, internal messaging facilities 2304 may
be used by a process to send messages to itself that include data,
for subsequent access, that the process may need to access during
subsequent time slices. In other words, a process may include the
data needed to be persistently stored in the message and send the
message to itself. The internal messaging service receives the
message and queues the message for delivery to the process. The
process may enter a quiescent state due, for example, to the
process relinquishing control of processing facilities to another
process upon expiration of the process time slice. Later, when the
process reawakens, the process may access the queued message to
recover the data. When internal messaging facilities are not
provided on the device, a process may use external messaging 2306
to store data within the server 2204. The data may be stored 30
within messaging queues 2308-2309, or may be stored in memory areas
2310 apart from messaging queues.
Processes running within multi-tasking systems in a
single-processor environment need to be able to quiesce, or
relinquish the processor, and then be automatically reawakened at a
later time to continue processing tasks.
FIG. 24 illustrates a number of mechanisms that can be used for
launching and reawakening processes within an electronic hand-held
device according to method and system embodiments of the present
invention. First, the device may include a native operating system
or control program 2402 that provides a multi-tasking environment,
including the ability to quiesce and reawaken processes in order to
provide concurrent processing for a number of processes within the
device. When the device does not include such a native operating
system or control program, the device may include a timer facility
2404 that allows a process to set a timer that, upon expiration,
generates an event that awakens or reawakens the process. Processes
can cooperate to implement a multi-tasking environment by setting
timers at the beginning of a current execution to a reasonable
time-slice value. When the timer expires, the process is notified,
and relinquishes control of the processor to another process.
Alternatively, the process can set a timer to a more distant,
future time corresponding to the beginning of a reasonable next
time slice for the process, so that other processes may execute in
the interim until the process is reawakened by expiration of the
timer. Thus, timers can be used in many different ways to implement
a multi-tasking environment among cooperating processes. Similarly,
a device may provide for event mechanisms 2406 that allow processes
to be awakened or reawakened on occurrence of different types of
events. Thus, a process may register to be awakened by an event
elicited by reception by the device of a particular type of message
from the server, and the server can implement multi-tasking by
continuously reawakening processes at reasonable intervals. This
can be implemented in a watchdog or monitor program 2408 running
within the server. Another technique may be to modify an existing
application native to the device 2410 to launch processes at
particular times using an event mechanism or timer facility, or a
special scheduling client or application may be installed on the
device in order to launch and quiesce processes in order to
implement a multi-tasking environment. When no other alternative is
available, processes may execute on the server 2412 in the server's
multi-tasking environment and exchange data with a device through
the communications medium connecting the device of the server in
order to simulate a multi-tasking environment on the device.
FIG. 25 is a control-flow diagram illustrating process behavior on
an electronic hand-held device for processes that cooperate to
implement a robust, multi-tasking environment according to method
and system embodiments of the present invention. FIG. 25
illustrates process activities during a single time slice of
process operation. In step 2502, the process awakens by any of the
methods described above with reference to FIG. 24. In step 2504,
the process employs any of a variety of techniques to monitor the
physical environment of the hand-held device to determine whether
or not the process should continue operating, or operate at a
reduced level of resource usage. In certain systems, the process
may use device-supplied functions for determining, for example, the
power level of the device, communications state of the device, and
other such device states and operational characteristics.
Alternatively, a process may indirectly detect power states and
communication states by monitoring the rate at which tasks are
executed, noting various features currently available to processes
running on the device, and other such characteristics of the
device. If as determined in step 2506, the current state of the
device is not conducive for process execution, the process may
configure the device, server, or device and server for reawakening
the process at a later time, in step 2508, and then quiesce, or
relinquish control of the processor within the device, in step
2510. Otherwise, if the state of the device is such that the
process needs to use fewer computational resources, or if the state
of the device is such that the process may safely use additional
computational resources, as determined in step 2512, then the
process may modify the length of the current time slice according
to the detected device state in step 2514. Next, in step 2516, the
process recovers persistent data needed by the process to continue
execution by any of the methods discussed above with reference to
FIG. 23. The process can then undertake execution of tasks in the
loop of steps 2517-2518 until either a timer expires or the process
detects, by other means, that its current time slice has ended.
When the time slice has ended, the process configures the device,
the device and the server, or the server to restart the process at
a subsequent time, in step 2520, by any of the methods discussed
above with reference to FIG. 24, and then quiesces, in step 2510.
Thus, by executing for a reasonable amount of time, and then
relinquishing the processor, processes running within an electronic
hand-held device can cooperate to achieve a multi-tasking
environment in which processes can continue to execute for long
periods of time by interleaving their execution with other
processes. Moreover, processes can detect certain device states or
characteristics that require processes to relinquish the processor
prior to the default time-out period, such as low power conditions,
or, in the case of cell phones, incoming or outgoing voice
communications.
A Digital-Image Service Application That Represents One Embodiment
of the Present Invention
One exemplary service application that can be deployed and executed
using the above-described component methods and systems of the
present invention is next described. The exemplary service
application allows for digital images captured by cell phone to be
easily, securely, and seamlessly transferred from the cell phone to
the cell phone users personal computer, other personal computers,
or third party systems.
FIG. 26 illustrates a digital-image-transfer service application
that represents one embodiment of the present invention. As shown
in FIG. 26, digital images captured and stored on a source device
2602 are transferred via the virtual communications medium or
network 2604 provided by method and system embodiments of the
present invention to a server 2608, where the digital images may be
stored in server memory 2610 and/or forwarded to any of various
target devices 2612 or to other, remote entities 2614. The
digital-image-transfer service application can be considered to be
distributed across the source device 2602, the server 2608, and the
target device 2612.
FIG. 27 is a control-flow diagram illustrating operation of the
source-device portion of the digital-image-transfer service
application. The service application runs continuously or
intermittently on the source device using the multi-tasking
environment discussed above in the previous subsection. In step
2702, 30 the service application determines whether any new data,
such as a digital image, is available for transfer. If not, the
application can return, or quiesce in step 2704. Otherwise, in step
2706, the application determines whether the newly available data
should be stored locally or transferred to the server. If the data
should be stored locally, then the application stores the data for
later retrieval, in step 2708, and quiesces. Otherwise, in step
2710, the application determines whether or not the data can and
should be specifically addressed to one or more target devices. If
so, then in step 2712, the application includes target addresses
by, for example, listing the target addresses in a message header.
Next, in step 2714, the application determines whether any
additional processing may be needed and, if so, processes the data
in step 2716. For example, in the case of digital images, the
application may crop the image, decrease the resolution of the
image, quantize the image, decrease the number of colors used in
the image, or compress the image. Then, in step 2718, the
application queues the image for transmission to the server. In
step 2720, the application determines whether any previously stored
data should also be sent to the server and, if so, retrieves the
stored data in step 2722 and returns to step 2710 to send the
retrieved data. Finally, in step 2724, the service application
undertakes transmission of data to 15 the server.
FIGS. 28 and 29 illustrate the server portion of the digital-image
transfer service that represents one embodiment of the present
invention. In step 2802, the application determines whether any new
data has been received from source devices. If not, the application
can quiesce, in step 2804. Otherwise in nested for-loops that begin
with steps 2806 and 2808, the server-side application processes
each received data item with respect to each target device listed
for the data item. In step 2810, the application determines whether
any processing is needed for the data item and, if so, processes
the data item in step 2812. As discussed above, this processing may
involve cropping, pressing, or otherwise changing and manipulating
the digital image for efficient transfer or for compatibility with
target-device capabilities. If the target device is currently
available, as determined in step 2814, then the data or
digital-image is queued for delivery to the target in step 2816. If
the digital image needs to also be locally stored within the server
for a period of time, as determined in step 2818, then if the
digital image is not already locally stored, the application stores
the digital image in step 2820. If the target is not available, as
determined in step 2814, the digital image is locally stored in
step 2822, if it is not already locally stored, and a task is
queued to a local queue within the server, in step 2824, to direct
subsequent delivery of the data to the target at a later time.
Queuing of the data may involve setting a timer. FIG. 29
illustrates a handler associated with the server-side digital-5
image transfer application. The handler waits, in step 2902, for a
next event to occur.
If the next event is expiration of a queued delivery timer, as
determined in step 2904, then the handler identifies the data
associated with the timer and transmits the data to the target
device, in step 2906, when possible. If the item is no longer
needed, as determined in step 2908, then the handler deletes the
data item, such as a digital image, from local storage in step
2910. Otherwise, if a failed transfer has been detected, in step
2912, such as by a message sent from a target device to the server
indicating failed transfer, then, in step 2914, the handler can
queue the data item for subsequent transfer to the target. A
default handler 2916 handles additional types of events.
FIG. 30 is a control-flow diagram illustrating the target-device
portion of the digital-image transfer service application that
represents one embodiment of the present invention. In step 3002,
the application determines whether new data, such as a digital
image, has been received. If not, then the process can return or
quiesce, in step 3004. Otherwise, the application extracts metadata
from the received data-bearing message or messages, in step 3006.
If processing of the received data is needed, as determined in step
3008, the data is processed in step 3010. Otherwise, in the
for-loop comprising steps 3012-3015, the application stores the
data at target locations within the target device, when the data
meets any of various criteria for storage. Thus, for example, the
target may elect to store only certain images, rather than all
images received from the source device depending on the frequency
of reception of images, time of day, or other such criteria.
FIG. 31 shows one embodiment of a method, such as method 3100, for
processing data at an intermediary server, such as server 2608
(FIG. 26) which server receives data sent from device 2602 destined
for target device 2612. Process 3101 determines if data has been
received at the intermediary server. When it has, process 3102
determines if there are operations to be performed on the received
data. As discussed above, these operations could be to repair such
things as red-eye, cropping, etc. of a digital image, or could be a
scan of the data to determine content or to determine document
type, etc. For example, a document type can be of a credit receipt
from a transaction, or a bar code, and the information contained on
such a document can be passed to an application, via process 3103,
appropriate for such information, either running locally on the
server or at a third party location as controlled by processes 3104
and 3105. Processes 3106 and 3107 determines if some third party is
to be notified of an event based on the type of data received by
the server or by content of the data. Process 3108 determines if
the data is to be sent to a pre-identified location for storage or
other processing. If so, process 3110 sends the data to the
appropriate location based either on the data type or more likely,
based on the device from which the data came. If the data is not to
be passed on, then process 3109 holds the data until the
appropriate time.
FIG. 32 shows one embodiment of a method, such as method 3200, for
processing data that has been received at the target device.
Process 3201 determines if data has been received at the target
location. If it has, then process 3202 determines if the received
data is to be delivered to an application for processing. If so,
then process 3203 processes the data and delivers the results in
accordance with that application (not shown). Then process 3204
determines if the data is to be sent to another location(s). If so,
process 3205 determines if additional data, for example, a digital
image, should be attached or substituted for the originally
received data. If so, process 3206 attaches the added data and
process 3207 handles the communication. This other location can be
subsequent storage locations or friends of the user at the sending
device. In such an situation, the originally sent data, such as a
digital image, can be sent to a friend and then forwarded, either
automatically or under the friend's direction, to subsequent
locations. In one embodiment, this system will allow a recipient to
send back to the sending device another piece of data, such as a
return digital image. This can be done without the necessity of
having the sender address the return data since it will return to
the server which will forward the data to the sending device.
Process 3208 determines if the data is to be stored. If so, process
3210 controls the storage of the received data at the appropriate
locations. These locations can be pre-identified by the user or
could be assigned based on the results of process 3203. Process
3209 or process 3211 report back to the server (for delivery to the
sending device) the results of the storage. If desired, the sending
device can then mark the data as delivered.
FIG. 33 shows one embodiment of a method, such as method, 3300 of
operation in accordance with one aspect of the invention in which a
message, such as a media burdened message having, for example, one
or more digital images attached thereto is received at a device.
This device is one that the message sending user has identified, at
least on a temporary basis, as a target device for receiving the
message type being sent. This could be a friend or family member,
or business colleague, with whom the sender wishes to exchange
media messages. Process 3301 determines at the recipient location
if such a media message has been received. When it has been
received, process 3302, either operating from an application
already loaded on the receiving device or from code included in the
received message, determines if the incoming data is to be handled
at all. If the incoming message is to be processed, then process
3303 begins the processing of the data and process 3304 takes the
appropriate action. For example, perhaps the sender has requested
permission to send additional images, music or other data. If so,
processes 3305, 3306 and 3307 obtain the recipient user's input and
passes it along to the system, for example via the intermediary
server. The user input could be spoken, key inputted, etc. In
another example, the sender could be requesting that the recipient
take a picture of him/herself, or of some other object, and return
the picture (or any other data) back to the sender. This is
accomplished, as will be seen without establishing a new link back,
but simply by sending the information back to the intermediate
server using data provided from the sender (or from the
intermediate server) along with the receipt of the incoming
message. This then facilitates the response back to the sender.
Process 3308 determines if the message is to be passed along to one
or more additional recipients. If so, process 3309 determines if
new instructions or information is to be added to the passed-along
message. If so, process 3315 adds the instructions and/or data and
process 3310 passes it along.
Process 3311 determines if the local device is to control any
processing of the data, such as, for example, printing, image
correction, sound enhancement, data analysis, etc. If so, such
processing is controlled by process 3312. Process 3313 determines
if any other action is to be taken locally by the recipient device
in accordance with instructions obtained with the incoming message
or in accordance with previously stored instructions. If so,
process 3314 attends to such processing.
Although the present invention and its advantages have been
described in detail, it should be understood that various changes,
substitutions and alterations can be made herein without departing
from the spirit and scope of the invention as defined by the
appended claims. Moreover, the scope of the present application is
not intended to be limited to the particular embodiments of the
process, machine, manufacture, composition of matter, means,
methods and steps described in the specification. As one of
ordinary skill in the art will readily appreciate from the
disclosure of the present invention, processes, machines,
manufacture, compositions of matter, means, methods, or steps,
presently existing or later to be developed that perform
substantially the same function or achieve substantially the same
result as the corresponding embodiments described herein may be
utilized according to the present invention. Accordingly, the
appended claims are intended to include within their scope such
processes, machines, manufacture, compositions of matter, means,
methods, or steps.
* * * * *