Note: Descriptions are shown in the official language in which they were submitted.
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
APPLICATION ACCESS UTILIZING A MESSAGE LINK
BACKGROUND OF THE INVENTION
The mobile nature of today's workforce makes it often difficult to securely
take
5- advantage of internal network resources and applications when workers are
away from their
desks. One common communication technique may be email. Used throughout the
enterprise
and across organizational boundaries, email is used to communicate and request
information
or action.
Much like the telephone for voice communication, email has been adopted as a
primary application for business, in particular for both remote and mobile
access. In the
enterprise, email tends to be the primary business communication platform and,
hence, is
almost always open on a user's desktop. It also tends to be the primary
application for
wireless users.
Email was originally developed as an electronic extension to regular physical
mail,
and as such is principally asynchronous and freeform. Asynchronous generally
means that a
process (e.g., sending an email) operates independently of other processes
(e.g. receiving an
email), whereas synchronous means that the process runs only as a result of
some other
process being completed or handing off operation (e.g., voice telephone
conversation). An
email message is generally composed by a first user, and sent to a second
user, where it is
queued in the second user's inbox to be subsequently read and possibly
responded to at a later
time. Freeform refers to the relatively small amount of standardized
information in an email
message. That is, aside from a few fixed fields (e.g., destination address,
origin address, and
subject etc.), the majority of the email document itself comprises the content
or body. This is
comparable to a physical mail message which generally only requires the
destination address.
The person-to-person nature of email generally makes it not useful for access
network
resources (e.g., databases, sales tools, etc.) that require more sophisticated
client applications
with morerobust user interfaces, such as a Web browser. That is, errors are
generally
indicated by human readable text that is relatively freeform and not
standardized, making it
hard for program to program communication. In addition; many mobile wireless
devices
(e.g., cell phone, PDA, etc.) are relatively small, and hence problematic for
the remote access
of internal network resources. Current enterprise software platforms were not
originally
1
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
deployed for this type of access, and so often require significant
development,
implementation and management expenditures to support access from these
wireless devices.
Mobile devices generally present the user with a relatively poor user
interface for
applications other than voice, because of both battery duration and form-
factor requirements.
Although receiving messages is easy, with the exception of voice, small
displays and
keyboards make transmitting messages awkward and problematic. For example,
sending a
text message may take a substantial effort because of the relatively small
size mobile
keyboards. In addition, devices without full keyboards (such as the numeric
keypads on most
cell phones) practically restrict data transmission to short messages (e.g.,
SMS, etc.).
Screen size also tends to limit the use of conventional client/server
applications and
browsers. Existing applications and Web-sites generally do not work with the
small screens
on mobile devices despite attempts at screen panning or automatic conversion
from HTML to
WML. Some vendors have chosen to write new versions of their applications or
Web-sites
especially for the mobile worker but this is non-trivial (one screen must
become many
mobile-screens) and therefore expensive to implement. Also, there is a lack of
portability
standards for mobile software and given the variety and rapid development of
devices at the
present time we should not expect to see this situation improve soon.
SUMMARY OF THE INVENTION
The invention relates, in one or more embodiments to a method for effecting
the
execution of an application function on an application server from a client
device. The client
device is coupled to a proxy server, the proxy server being further coupled to
the application
server that executes an application implementing the application function. The
method
includes selecting a request to execute the application function from a set of
application
function requests on the client device. The method further includes
transmitting a first text
message pertaining to the request to the proxy server, the first text message
including a text
message destination address and a text message origination address, the first
text message
pertaining to a request to execute the application function. The method
additionally includes
autlzenticating a user associated with the first text message origination
address by sending an
authentication message to the user at a text message confirm.ation address
that is different
from the text message origination address and receiving confirmation from the
user
responsive to the authentication message. If the user is authenticated by the
authenticating,
the method also includes executing the application function at the application
server as
2
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
specified by the first text message, whereby the first application function is
ascertained based
at least on the text message destination address.
One or more embodiments of the present invention involve a system for
facilitating a
user to access one or more applications residing on one or more servers. The
system may
include a message module configured to receive a first user message from the
user and, in
response to the first user message, create an authentication address and send
a first request to
a confirmation address. The authentication address may be configured to expire
within a
predetermined period of time (e.g., 3 minutes) after the temporary address is
created or after a
first request is sent. The system may also include a parser configured to
extract an instruction
from at least one of a second user message from the user and the first user
message, if a
positive reply message originated from the confirmation address is received at
the temporary
address. The system may further include a connector configured to communicate
the
instruction to the one or more servers for triggering one or more responses to
be generated by
the one or more applications and to be sent to a client device, if the
instruction is extracted.
These and other features of the present invention will be described in more
detail
below in the detailed description of the invention and in conjunction with the
following
figures.
BRIEF DESCRIPTION OF THE DRAWING
The present invention is illustrated by way of example, and not by way of
limitation,
in the figures of the accompanying drawings and in which like reference
numerals refer to
similar elements and in which:
FIG. 1 shows a simplified block diagram of an application/information access
arrangement in according to one or more embodiments of the present invention.
FIG. 2 shows a simplified block diagram illustrating an authentication
mechanism
processing a user request according to one or more embodiments of the
invention.
FIG. 3 shows a simplified block diagram illustrating the authentication
mechanism of
FIG. 2 processing a rogue request according to one or more embodiments of the
invention.
FIG. 4 shows a simplified block diagram illustrating scalability of the access
arrangement according to one or more embodiments of the invention.
FIG. 5 shows a simplified block diagram illustrating a message protection
mechanism
according to one or more embodiments of the invention.
3
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
FIG. 6 illustrates application/information access types according to one or
more
embodiments of the current invention.
FIG. 7 shows a simplified block diagram illustrating a configuration of an
access
system according to one or more embodiments of the invention.
FIG. 8 shows a simplified block diagram illustrating administration of an
access
system according to one or more embodiments of the invention.
FIG. 9 shows a simplified block diagram illustrating the use of Web services
with the
access arrangement according to one or more embodiments of the invention.
FIG. 10 shows a flowchart of a method for executing an application utilizing
the
access arrangement according to one or more embodiments of the invention.
FIG. 11 shows 'a simplified block diagram of an access server according to one
or
more embodiments of the invention.
DETAILED DESCRIPTION
The present invention will now be described in detail with reference to a few
preferred embodiments thereof as illustrated in the accompanying drawings. In
the following
description, numerous specific details are set forth in order to provide a
thorough
understanding of the present invention. It will be apparent, however, to one
skilled in the art,
that the present invention may be practiced without some or all of these
specific details. In
other instances, well known process steps and/or structures have not been
described in detail
in order not to unnecessarily obscure the present invention. The features and
advantages of
the present invention may be better understood with reference to the drawings
and
discussions that follow.
Various embodiments are described herein below, including methods and
techniques.
It should be kept in mind that the invention might also cover an article of
manufacture that
includes a computer readable medium on which computer-readable instructions
for carrying
out embodiments of the inventive technique are stored. The computer readable
medium may
include, for example, semiconductor, magnetic, opto-magnetic, optical, or
other forms of
computer readable medium for storing computer readable code. Further, the
invention may
also cover apparatuses for practicing embodiments of the invention. Such
apparatus may
include circuits, dedicated and/or programmable, to carry out operations
pertaining to
embodiments of the invention. Examples of such apparatus include a general
purpose
computer and/or a dedicated computing device when appropriately programmed and
may
4
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
include a combination of a computer/computing device and
dedicated/programmable circuits
adapted for the various operations pertaining to embodiments of the invention.
In accordance with one embodiment of the present invention, an application
and/or
information access arrangement, hereinafter access arrangement, is
advantageously employed
to facilitate enhanced information access and retrieval. In a non-obvious
fashion, text-based
messaging (e.g., email, SMS, etc.) may be extended beyond the person to person
communication form, providing both a platform and service directed access to
"things" such
as transactions, application data or resources on the Web. Information access
and retrieval
can generally be either trusted or non-trusted. Trust generally refers to the
degree of
confidence that a first party has as to a second party's intent to abide by
stated system of rules
(e.g., privileges, restrictions, rights, etc.).
In general, the access arrangement generally distinguishes between three types
of
requests: non trusted, trusted origin, and highly trusted. If the information
being transferred
between two parties is not particularly valuable in comparison to its general
disclosure, or is
generally non sensitive in nature, a non-trusted relationship is generally
established. Non
trusted request may be accepted from anyone/anywhere and results are returned
to the sender.
This is the simple open or public type of transaction. In one embodiment, the
access
arrangement may be employed to create non-trusted services in which a text-
based messaging
address returns non-sensitive information (e.g., news, weather, traffic,
etc.). For example, by
sending an email message to an email address, such as cmNews@ClairMail com,
with a
news topic as the subject of the email, a response may be received containing
news on that
topic.
Trusted origin requests may be accepted only from a provisioned user
(including a set
of trusted user addresses) maintained on a registered user list, or derived
from an external
source (e.g., LDAP, MS Active Directory, etc.). Any request not properly
authenticated is
subsequently rejected (e.g., spam, etc.), and any reply may only be returned
to the appropriate
trusted address (and not necessarily to the sender). An SMS address is
particularly useful as a
reply address since it is unique to the device.
In that way, an unregistered intruder attempting to spoof the access
arrangement as a
registered user will be detected, and hence not be able to receive
confidential information in a
reply. In addition, a trusted user address scheme is also resistant to a man-
in-the-middle
attack. That is, a situation in which a third party, unknown to the other
parties, intercepts a
message from one party and forwards the message to a second party.
5
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
Highly trusted requests are trusted origin requests that require further
sender
authentication of transaction confirmation. For example, a highly trusted
request may be used
to transfer funds between bank accounts. A confirmation message may initially
be sent to the
pre-arranged 'authentication address.' As in a trusted request, a registered
user defines an
address where these confirmation messages are sent, which is not necessarily
the same device
or protocol from which the request originated.
A confirmation message or authentication token (including a timestamp) that is
valid
for a short period of time may then be encrypted. Generally, a duration is
chosen such that the
time required to break the encryption is substantially larger than the time
window in which
the message is valid. The user may then reply to the confirmation message,
perhaps adding
some additional information, a personal identification number (PIN) for
example, again
making the system more secure. That is, if the encrypted message were
intercepted and
returned without the PIN, the transaction would not be authorized. Once the
reply is received
by the access arrangement (and the PIN checked appropriately) the transaction
is
authenticated and executed and 'marked complete'. As described before, this
final step is used
to secure against a man-in-the-middle attacks, since a transaction may only be
executed once.
For example, by typing an email address, such as cmTransfer@ClairMail.com,
with a
transfer amount as the subject of the email, and replying to a confirmation, a
user can initiate
a transfer of funds between two pre-specified accounts.
In addition, a robust authentication mechanism also helps to substantially
reduce spam
(e.g., unsolicited bulk messages, etc.). Spam has unfortunately encouraged
fraudulent
advertising and solicitation using electronic messages, since virtually anyone
can transmit a
substantial number of emails at virtually no cost. Rising to a significant
level of concern,
most businesses must now protect their messaging systems from floods of spam,
as well as
avoiding becoming a source of spam themselves, by bouncing bad messages to
wrong places.
For example, in an attempt to find a way to connect to the network from which
a
spammer is blocked, the spammer may send a message with a forged but valid
sender address
to an invalid destination address at a third site. Consequently, the third
site's email server,
unable to deliver the message, may in turn send a copy of the undelivered
(spam) message
back to who it believes is the sender, which in this case is to the forged
sender address.
In addition, an invalid destination address may be used in order to execute a
denial of
service attack. For example, a message from an attacker may be sent to an
email server with
both an invalid destination address and an invalid return address. As before,
since the
6
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
message cannot be delivered, the email server replies to the non-existent
sender, which in
turn causes the message to bounce back to the original email server.
Consequently, a message
transmission loop may be created, eventually consuming sufficient network
resources such
that legitimate traffic can not be transmitted.
The access arrangement also uses authentication techniques to ensure that
information
is accessed and transactions executed on behalf of genuine users only. In
particular, the
access arrangement may utilize an encrypted token which is sent to the client
device. The
user must reply or submit the token quickly and correctly. The token expires
within a few
minutes, so an eavesdropper does not have time to decrypt. Once the user
replies (optionally
with additional password or PIN) the token is canceled, so an eavesdropper
cannot use a
replicated message to affect a transaction. This technique assures autlientic
operations using
only a simple device, without the need for encryption/decryption in the mobile
device. In
general, relatively low performance processors are often used in mobile
devices in order to
increase battery life. Consequently, mobile devices tend not to be optimized
for
computationally intensive encryption/decryption tasks.
In addition, the access arrangement may allow hosted access infrastructure for
managed enterprise access to both internal and external sources. It further
may provide a
manageable infrastructure for directed transactional access to applications
and Web services
allowing enhanced productivity and owner (total cost of ownership) TCO. In one
embodiment, a simple request access (SRA) protocol gives secure directed text-
based
messaging access to applications and information, enhancing user productivity
and reducing
support and training costs. That is, no additional software need be installed
on the user's
desktop computer, laptop computer, mobile device, PDA, smart-phone, wireless-
email-
device, etc.
Typically, text-based messaging addresses can be created for "actions" or
"transactions" within a platform that enables complex actions to be performed
from a simple
directed request. A single request or message may span multiple applications
and provide a
consolidated or coordinated result In addition, the results of multiple
application queries, each
using the same or disparate access credentials, may be consolidated into a
unified result.
Text-based messaging addresses stored in the users address book can now define
request types. In addition, the requester associated information may come from
the profile
database at an information/application access server (access server), such as
a simple request
access (SRA) server, and history of requests can be logged.
7
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
In general, there are two methods of logging. In a first type, a client log
may be
maintained at a client device inbox, where copies of all the sent and received
messages are
stored, to be accessed and searched later. In a second type, a server log may
be maintained at
the access server. In general, the server log records transaction information
such as the user
name, the task, the time, etc. Consequently the access server may provide a
substantially high
level of auditability that is often required by corporate governance
guidelines and regulations,
such as the Sarbanes-Oxley Act.
The access arrangement optimizes traditional text-based messaging applications
(e.g.,
email, SMS, etc.) with a SRA (simple request access) addresses, avoiding the
limitations of
many other approaches such as synchronization, mini-browsers and expensive
specialized
client applications. Access functions traditionally missing in text-based
messaging may be
provided as simple alphanumeric text messages (or other sets of indicia) sent
to the access
server which, in turn, acts upon the messages and returns the required results
using a simple
electronic message. That is, a ClairMail server may act as the user's personal
assistant, by
acting as a proxy on the user's behalf.
In a non-obvious way, each SRA message has its own unique address. Commonly
used SRAs may be kept with the other traditional text-based messaging
addresses in an
address book for quick access with minimum key strokes. For example, a request
might be
"What is the credit limit for customer XYZ?", "Get a quote for stock symbol
XXX?", "Place
order for 100 units of YYY for customer XYZ?", or "Sell 100 shares of stock
XXX?".
In one embodiment, each of these requests could be sent to an appropriate
address
such as, for example, address@server.com along with additional appropriate
parameters (e.g.,
customer number/name XYZ, Stock Symbol XXX, number of units or shares to
buy/sell,
item number/name YYY, etc.). The structure of email, in particular, generally
offers a large
set of addresses which, in turn, provides a large namespace for transaction
names.
In addition, although this approach may be optimized for a mobile device, it
may be
also used from any email-enabled or other messaging capable device. In one or
more
embodiments, the request can be sent as a SMS message. In one or more
embodiments, the
request can be sent as a Web service message. In one or more embodiments, the
request can
be sent as IM (instant message). In one or more embodiments, a Web interface
may be used
to send a detailed request. In one or more embodiments, multiple protocols may
be combined
for a given request. In one or more embodiments, the request may utilize a
given protocol for
a request, and a different protocol to return the results of the request. A
URL (Universal
8
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
Resource Locator) pertaining to the request may then be bookmarked as a
bookmark URL for
easy retrieval.
In addition, SRA provides a relatively powerful yet simple secure user
interface. In
general, enterprise applications demand security and authenticity. Security
requires that
confidential information be kept private and away from eavesdroppers. Whereas
authenticity
requires that the message is from who it purports to be from. The access
arrangement enables
substantially robust message authentication by generally accepting messages
that contain
trusted addresses. That is, unwanted messages or rogue senders can be detected
and avoided.
Common message protocols (SMS, SMTP) are generally not secure, and thus can be
easily intercepted and falsely replied to. One solution has been the use of
public key
infrastructure (PKI) techniques, wherein messages are encrypted at the source
using a private
key then decrypted at the destination using the sender's public key. Although
today's mobile
devices may have sufficient memory and compute power to use PKI , they
generally do not
provide mechanism for the secure keeping of private keys.
For example, since a private key (which may be very hard to guess) also tends
to be
relatively long and hard to remember, it is often secured on a mobile device
with a relatively
short and memorable PIN or personal identification number (which may be
relatively easy to
guess). Thus, the local storage of a relatively strong private key with a
relatively weak PIN
may inadvertently expose the rights and privileges of the device owner to
anyone using the
device who correctly guesses the PIN.
The access arrangement may obviate problems of key management in the mobile
devices and may obviate problems associated with differences between devices
such as, for
example, different memory sizes (e.g., some have a lot of memory and some only
little),
different programming languages (e.g., some are programmed with C/C++ and some
with
Java), different components (e.g., some have SIM cards and some do not), etc.
The access
arrangement may build upon a simple message protocol (such as SMTP) with a
message
exchange that passes an encrypted token with the option of using a PIN as well
to secure
requests. Consequently, computationally intensive encryption may be done at an
access
server (which may have powerful sets of processors) instead of at the client
device (which
may have a relatively weak processor).
The access arrangement also comprises a hardware/software combination that may
be
delivered either as a managed service or as an enterprise appliance installed
within a firewall.
The "front-end" of the access arrangement may be a message server (or message
module) that
9
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
receives and responds to requests from clients. The "back-end" of the access
arrangement
comprises a request server (or request module), which processes the requests,
and accesses
the appropriate applications on behalf of the requestor. The combination of
the message
server and the response server in general may function as a proxy server for
each client. That
is, the application may not necessarily be aware that it is interacting with
the access
arrangement, as opposed to directly interacting with the client itself.
In one embodiment, the message server is the gateway between the external and
internal system components, in addition to running message services, e.g., one
or more of
SMTP, SMS, MMS, IM, XMPP, Web service, SOAP, XML, WAP, WML, HTTPS, HTTP,
etc. In another embodiinent it also runs the secure-Web servers for remote-
administration and
a firewall. For maximum security, no other ports or network connections may be
generally
made available to the outside world. Message servers can be replicated for
scalability and
availability. The message server may run the authentication system using data
stored in the
profile database. Invalid messages are discarded or rejected. Valid messages
may be acted
upon immediately however, most messages are added to one of the persistent
message
queues, also stored in the database or on the file system.
In general, within the access arrangement, message queues may be spread across
different nodes of a computer cluster in a manner that is optimized for both
data consistency
and performance. That is, a particular message queue may be simultaneously
modified from
more than one source (e.g., add, delete, etc.), and yet still maintain a
consistent state within
the access arrangement.
The request server takes messages from the persistent queues, extracts the
input
data/parameters from the message, adds profile information such as user
credentials, and
passes them to the client application. That is, the request server makes the
desired
information-access or executes the transaction specified by the request and
returns results.
The request server formats the results into a simple message and returns them
to the user.
Request servers can be replicated for scalability and availability. Each
server takes the next
message from the queue, and does not interfere with others.
Request servers can often use one or more client application machines to run
the
applications. Client machines can also specialized to run only one or a few
applications. This
is useful when the client applications need a lot of computing resources, or
perhaps need
dedicated access to external network connections or databases. In these cases,
different queue
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
are used. The message servers direct messages to the appropriate queue and
only that set of
request servers take messages from that queue.
The resulting system is substantially scalable in all aspects (e.g., message
servers,
request server and client application machines can all be replicated) ensuring
substantially
high availability, substantial scalability (from low-cost to high-capacity at
the right price)
with substantially easy maintenance and upgrade paths. In general, small, low-
cost systems
are needed for organizations with a small mobile workforce, yet large
enterprises will exceed
the capacity of a single computer.
The access arrangement also enables substantially parallel operations. For
example,
the message server can be run on a single computer or a set of parallel
computers. Additional
computers can be added simply, at any time. A single logical database is used
to hold the
user-profile data and conventional database replication is employed to scale
the capacity and
performance as required. The request servers can run alongside the database in
small
installations or can be distributed across a set of servers to meet the needs
of the largest.
Client applications may be added to meet the workload and response times
required.
The access arrangement also enables 24-by-7 availability. By enabling inherent
redundancy, access arrangement allows both scalability and system availability
in the event
of failure of any one component. Messages can be processed by any of the
message servers.
For exainple, should any request server or client application machine fail,
others will be
available to continue the service. If one fails while processing a request, a
timeout will occur
and the next request server will take over automatically.
The access arrangement may also be reliable. Reliability is a measure of the
difference between expected system behavior and actual system behavior,
including un-
expected system input. The access arrangement enables false messages to be
rejected by for
example, forward and reverse DNS lookup checking to ascertain whether the
sender's IP
address and domain match. Also, false message detection may be accomplished
using modern
techniques such as Sender Policy Framework (SPF) where valid sending IP
addresses are
listed in the domain DNS. In addition, since open systems are susceptible to
denial-of-service
attacks (DoS), the access arrangement has special techniques to detect and
respond to such
attacks. Early identification of bad senders ensures that little computer
resources (CPU time,
memory, log files) are wasted and "tarpit" techniques are used to slow down
multiple inputs
from one place. Although genuine users are generally unaffected, rogue users
are slowed
down to a rate that cannot cause loss of service.
11
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
System monitoring and administration is also automated in order to keep costs
low.
When required, these monitoring and administration functions are available
remotely using
secure-Web access. Suitably authorized users can manage the access server
(including the
message server and the request server according to one or more embodiments)
from any Web
browser.
The features and advantages of the present invention may be better understood
with
reference to the figures and discussions that follow.
FIG. 1 shows a simplified block diagram of an application/information access
arrangement in according to one or more embodiments of the present invention.
A user may
operate a client device 102. Client device 102 may represent a mobile device
such as a
mobile phone, mobile email device (e.g., Blackberry), PDA, or laptop computer.
Client
device 102 may also represent a non-mobile computer. A mobile phone,
especially one of
today's smart-phones, may be fast becoming the mobile device of choice.
Client device 102 connects to a simple request access server 106 (SRA server
106)
through a network, such as wide area network 104, which may represent a
combination of a
wireless network and the Internet. SRA server 106 may represent a proxy
server. SRA server
106 may include a message server [described below] and a request server
[described below].
SRA messages are used to communicate the request much like a remote procedure
call (RPC)
mechanism that is used with client APIs.
In order to take maximum advantage of the wide variety of devices and networks
and
to avoid the complexity of RPC protocols like CORBA, the access arrangement
may use
human readable addresses and text for these messages. This substantially
ensures access from
all devices, since a simple messaging capability is all that may be required
for security and
authenticity.
SRA server 106 may maintain a user profile database 108 which is used for user
authentication, request augmentation, and personalization, wherein information
such as user
preferences, default values, and credentials may be stored and encrypted. For
example, non-
trusted requests, like "Get a quote for Stock with Ticker Symbol XXX" or "Look
up a phone
number" do not require authentication. Trusted request are verified against
registered user
list. Highly trusted requests, as previously described, usually require both
verification against
a registered user list, as well as a confirmation message or authentication
token may initially
be sent to the pre-arran.ged'authentication address,' optionally with an
additional PIN. Once
SRA server 106 receives a request message (authenticated if required), it may
act upon it
12
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
directly, it may connect over a WAN (wide area network) 111 (e.g., Internet,
etc.) to publicly
available internet servers 11 6a-b or it may pass the request on via LAN
(local area network)
114 or a wireless network (not shown) to one or more application servers 120,
which may in
turn be coupled to a persistent data store, such as database 112. For many
requests, the SRA
server will act upon behalf of the requestor and uses data from the user
profile database to
access private information over the Internet or login to a client application
110 on behalf of
the user. In one or more embodiments, access to client application 110 is done
through the
user interface, as the user themselves would do. For example, SRA server 106
may intercept
GUI (graphical user interface) based transactions (e.g., text, mouse movement
and clicks,
etc.) that would normally be used by client application 110 to interact with a
human user.
The requesters profile contains user names and optionally, passwords for each
request, ensuring that private information (e.g., user names, passwords, etc.)
may not be sent
over the public WAN 111. In addition, the user profile database may be secured
behind
appropriate firewalls. In one embodiment, SRA server 106 may only have three
or four ports
open to the WAN (e.g. for one or more of SMTP SMTP, SMS, MMS, IM, XMPP, Web
service, SOAP, XML, WAP, WML, HTTPS, HTTP, etc.) in order to maintain
security. In
another embodiment, the client application is part of a typical client/server
enterprise
application; the client connects over a local area network, probably inside
the enterprise
firewall, to the application servers and databases.
FIG. 2 shows a simplified block diagram illustrating an authentication
mechanism
processing a user request according to one or more embodiments of the
invention. Client
device 102 may send a SRA message (a first user message) to get permission for
the access
or transaction at step 211. SRA server 106 may use the name of the message
sender to look
up the user's profile in a database 108 at step 212. Part of the user's
profile is the user's
address used to get permission. The address may be the client device 102.
Alternatively or
additionally, the address may represent a different device. The different
device and SRA
server 106 may utilize the same messaging protocol or different messaging
protocols.
SRA server 106 may then create an encrypted token and an associated temporary
mailbox (temporary address, e.g., an email address, phone number, Web address
or URL, or
instant messaging address) using that token. The system may then send an
authentication
request back to the user at step 213. In one or more embodiments, this mailbox
address may
never existed before and may expire in a few minutes, so an eavesdropper may
not be able to
learn about this beforehand and may have only a few minutes to try to crack
the encrypted
13
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
token. The choice of token key length and short time-to-expire substantially
ensures security.
Client device 102 (the user) may reply positively (in a second user message)
to the
authentication request (adding an additional identification information such
as a PIN,
personal identification number, for more secure requests) at step 214. Once
SRA server 106
receives the authentication reply at step 214, the temporary mailbox may be
destroyed and
the original request is generally marked as authentic. SRA. server 106 may
then pass the
request on to the appropriate client application 110 at step 215. Client
application 110 may
return results from client application 110 to the SRA server 106 at 216. SRA
server 106 may
send the results to client device (and the user) at 217.
FIG. 3 shows a simplified block diagram illustrating the authentication
mechanism of
FIG. 2 processing a rogue request according to one or more embodiments of the
invention. A
rogue client 302 may attempt to penetrate the access arrangement by sending a
(fake) request
to SRA server 106 with a forged "From:" address at step 311. SRA server 106
may then look
up the address in database 108 for authentication. An encrypted token and a
temporary
mailbox may then be created.
Subsequently, the authentication request is forwarded to one of the trusted
addresses
of a genuine client 304 (genuine user 304) at step 313. That is, genuine user
304 may receive
a spurious authentication request and sending address. Genuine user 304 may
simply ignore
it. Genuine user 304 miay also reply negatively at 314, and subsequently
receive a
confirmation message from SRA server 106 indicating that client application
110 is protected
at step 315. This negative reply may be used to identify and block rogue
client 302 from
further access. As previously described, the use of a set of trusted address
allows SRA server
106 to operate as a spam-free message server, particularly when used with
common internet
protocols, such as SMTP, that can easily be forged.
FIG. 4 shows a simplified block diagram illustrating scalability of the access
arrangement according to one or more embodiments of the invention. One or more
components of SRA server 106 (shown in FIG. 1), such as message servers and
request
servers, may be scaled up to meet arbitrary demands for performance and
availability. The
scalability may be important not only to meet the needs of a large enterprise
but also to
deploy the right-sized system at the lowest cost with simple growth paths.
Message servers (e.g., SMTP servers 402a-c) may distribute load with
conventional
IP-spraying techniques such as round-robin DNS or other load balance solutions
or
equipment, such as Local Director available from Cisco Systems, Inc.
(www.cisco.com).
14
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
Database 108 may store message queues that may be designed for multiple-
readers
and writers accessing over a network at the same time, with the minimum of
necessary
locking. This ensures high performance with high reliability. Capacity can be
expanded by
storing different queues on different systems.
Request servers 404a-c may take messages from their designated message queues,
process them in turn, and subsequently forward the messages to appropriate
client
applications, such as one or more of client applications 406a-b. As soon as
one request is
finished, the next message is processed, the load may be naturally
distributed. Fewer request
servers may offer a lower-cost system that may have higher latency in response
times when
the system is busy. More request servers 404a-c may keep latency to the
minimum even when
systems are busy, at additional cost. In addition, it may be easy to add
request servers on-the-
fly (in real time), so systems can be scaled to meet the processing and
performance needs.
FIG. 5 shows a simplified block diagram illustrating a message protection
mechanism
according to one or more embodiments of the invention. Incoming messages may
be screened
so that minimal computing resources are wasted on rogue or error messages. The
message
protection mechanism may help to prevent Denial of Service (DoS) attacks as
well. The
message protection mechanism may be implemented in a message server, such as
SMTP
server 402a.
At logic 511, the source addresses (e.g., IP addresses) of the incoming
messages may
be compared against blacklist 508 of known spam sources, and those messages
shown on
blacklist 508 are dropped immediately without even accepting the messages into
the system.
At logic 512, several additional checks are made on the message protocol and
header
information for items that are often wrong in forged messages, such as no DNS
MX record
for the source IP address, no DNS entry for the source, etc., and those
messages detected as
forged messages are immediately rejected.
The access arrangement (or SMTP server 402a) may be configured to send'bounce'
messages back to the source - yet when the source is forged, the bounce
message 'bounces'
again. These double-bounce messages are generally errors (sometimes transient
errors) so
they are logged but processed no further. These early checks may reduce the
load on
components in the access arrangement and help protect the components from DoS
attacks.
Each check may be enabled or disabled for every source address, for one or
more specific IP
addresses, or one or more ranges of IP addresses. The early checks may be
especially
important where organizations fail to set up message sending servers correctly
(e.g. missing
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
DNS entries, no reverse DNS, missing MX entries), yet the organizations are
genuine
message sources and need to be accepted. An administrator of the access
arrangement may
enable and/or disable checks dynamically. Additional spam filtering may also
be utilized.
At logic 3, authentication messages from previously unknown users (sources)
may be
checked. If a message is addressed to a specific mailbox with an encrypted
name and, if it is a
valid response (within timeout, with PIN if required, etc.), that user is
'authenticated' and the
user's profile is added/updated in database 108.
At logic 514, an "authenticated" confirmation message may be returned to the
client
device [not shown] of the user. The particular details of who may be
authenticated may vary
from system to system: A system open to the public may authenticate all users
(unless
blacklisted). A private system might only allow users known in some other
database/directory
(e.g., LDAP, MS Active Directory, etc.) and may not need to utilize
"authenticated"
confirmation messages.
At logic 515, if the message is not an "authenticated" message, the message
may be
checked to see if the user is known (i.e., the source address of the message
matches one in the
user profile database) and if non-trusted access to this request is allowed.
If the user is not
known, control is transferred to logic 516; if the user is known or non-
trusted access is
allowed, control is transferred to logic 517.
At logic 516, an authentication (welcome) message may be generated (with an
encrypted key) and returned to the user. If the source address is forged or
and invalid, this
authentication message might be queued, lost or will bounce, so the source
address remains
unknown.
At logic 517, the message/request may be parsed and dispatched for appropriate
processing. Some requests may cause an immediate reply at logic 518, while
others may be
placed on a persistent queue 510, where they may be deferred for furtlier
action.
FIG. 6 illustrates application/information access types (request types) and
request
processing according to one or more embodiments of the current invention. The
request
processing may be implemented in a request server, such as request server 404a
shown in
FIG. 4. The request server may take the next request from a request queue 602
and process
the request according to the type of the request.
The access arrangement may utilize rapid development techniques, usually in
the
form of simple scripts that match input and output parameters from the request
message with
the application interface. Coinplex requests may be built up from combinations
of simple
16
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
scripts. For example, "lookup product from UPC" and "get price quote for
product" may be
combined to create a new request "get price quote from UPC". Note that the
access
arrangement may be configured to allow multiple request servers running in
parallel. Parallel
processing may be important for scaling systems to meet capacity requirements.
In addition, individual request servers may be specialized to handle specific
requests
which are important when special software or hardware installations are
required.
A Type 611 request may represent a request for one or more modern Web services
that require structured requests. The request server may match the
unstructured input
parameters from the Type 611 request message and copy the unstructured input
parameters
into a structured XML document as defined by the WSDL (Web Service Definition
Language) parameters. Results from the XML document returned from the Web
Service
request may be extracted using the WSDL output parameters, formatted into text
appropriately using XSLT, and put into the reply message for the user. A
script may be used
for this parameter matching and formatting permitting rapid script development
and simple
maintenance.
A Type 612 request may represent a request for one or more IP services that
accept
unstructured or less structured requests such as fetching a Web page. The
request server may
copy input parameters from the Type 612 request into an appropriate request
(such as an
HTTP GET or POST, for instance) and may also direct the extractions of
returned results.
Wherever possible, the HTML results are converted into XML, and the same
structured
extraction and formatting techniques of Type 611 may be used. Type 612 scripts
may be a
little more complex than Type 611 scripts in order to deal with variations
inherent in using
less structured requests and replies. Nevertheless, the Type 612 scripts may
be simpler than
Type 3 requests (discussed below) and may still offer the benefits of the
Rapid Development
techniques.
A Type 613 request may represent a conventional way to access application data
from
a new application--write a new client program. A program is written to take
the input
parameters from the request and pass them to the application using the API
provided by
vendor and then return the results. It is generally known that development and
maintenance
of new client programs may be substantially expensive, and so Type 613
requests may
usually be avoided in the access arrangement. Nevertheless, they may be made
available as
and when required, for example, if Type 611 and Type 612 are not available.
17
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
A Type 4 request may represent a new, rapid-development approach to solve the
problem of application access. It may use a novel "Visual API" using screen-
scraping, cut
and paste, and OCR techniques. A script may direct the matching of input and
output
parameters to the input and output fields on the screens of an existing
application. The
request server may paste the input parameters into the input fields and
extracts output
parameters as directed by the script. Type 4 requests may be used to access
existing and
legacy applications without the need for expensive programming. Type 4
requests may
leverage browser based or terminal session applications including one or more
of Citrix,
VNC, MS Terminal Server, VT 100, etc. Type 4 scripts are generally simple,
quick to write,
and easy to maintain.
FIG. 7 shows a simplified block diagrain illustrating a configuration of an
access
system 700 according to one or more embodiments of the invention. The front
end (facing
communication network 790, e.g., the Internet) of access system 700 may
comprise one or
more computers, such as SMTP servers 702a-b, running message software (e.g.,
SMTP, etc.).
The one or more computers may run the firewall and may run Web servers for
administration.
A minimum of two servers may be preferred for continuous availability in the
event of failure
or during maintenance.
The back end (facing the internal network) may run database server 708 and/or
RAID
(redundant array of independent disks) file system 704. Large access systems
may duplicate
the database server 708 and replicate the associated database using
conventional database
techniques for high availability, such as RAID file system 704. Additional
machines may be
included as required to run the client applications. Some of these client
applications may
require access to the enterprise servers. The access may usually be done using
a private
network connection, or perhaps via a virtual private network (VPN), over the
public internet.
The front end and back end of the access system may run on a well-known
operating system,
such as Linux or Microsoft Windows . the Linux operating system, client
application 110
may also run on a well-known operating system, such as Linux or Microsoft
Windows ,
that may be the same as or different from the operating system that the front
end and/or the
back end of the access systein runs on.
FIG. 8 shows a simplified block diagram illustrating administration of an
access
system according to one or more embodiments of the invention. One or more
server functions
of the access system may have remote administration built-in. A secure network
interface
(e.g., HTTPS, SSH, etc.) may be hosted on the message servers of the access
system and may
18
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
be utilized to access the Web server administration applications 802a-b, which
may be
configured for managing a simple request access database, the message queues,
system logs,
blacklists, etc. stored, for example, in database server 708 and/or RAID file
system 704. In
addition, client application 804 may also have integrated remote control
functionality.
Remote administration of these machines may be implemented, for example,
utilizing a
remote control client application or via the Web utilizing a remote control
applet. One or
more of the message servers and request servers of the access system may run
un-attended.
For example, log file rollover may be automatic, and message queues may grow
and shrink as
required. When it is required, system monitoring and administration functions
may be easily
performed by any suitable authorized administrator from a Web browser or
management
console.
An access service provider may run a public access service which is open to
the
public and registered users. An enterprise may also adopt an access system for
providing
application access to users of the enterprise, and the access system may be
operated by the
access service provider on behalf of the enterprise as a managed service.
Alternatively or
additionally, the access system may be installed at a site of the enterprise
and may be
operated by the enterprise.
FIG. 9 shows a simplified block diagram illustrating the use of Web services
with the
access arrangement according to one or more embodiments of the invention.
Generally, a
Web service may represent a standardized way of integrating applications into
a SOA
(services oriented architecture) utilizing one or more of XML, SOAP, WSDL and
UDDI
open standards over an Internet protocol backbone. XML may be utilized to tag
the data,
SOAP may be utilized to transfer the data, WSDL may be utilized for describing
the services
available, and UDDI may be utilized for listing what services are available.
Web services allow different applications from different sources to
communicate with
each other without time-consuming custom coding, and because all communication
is in
XML, Web services are not tied to any one operating system or programming
language. For
example, Java can talk with Perl, Windows applications can talk with UNIX
applications,
without special prograinming.
In the example of FIG. 9, access server 906a-b may be represent one or more
SRA
servers, such as SRA server 106 shown in FIG. 1. Access server 906a-bmay allow
users
902a-c to access Web services from Web service providers 908a-c. In one or
more
embodiments, access server 906a-bmay be configured to translate incoming text
messages
19
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
from users 902a-c into the appropriate Web service protocol. As shown in the
example of
FIG. 9, an access service, such as access service 906b, may enable a user,
such as user 902c,
to access multiple Web services (or service providers), such as service
providers 908a and
908c through one request.
Access server 906a-bmay be configured to process a variety of input message
types
and protocols (SMTP, SMS, etc) from users 902a-c. Access server 906a-bmay also
be
configured to process XML messages in the form of Web Service calls from
service
providers 908a-c. Access server 906a-bmay also be configured to publish the
availability of
associated Web services (e.g., service providers 908a and 908c associated with
access service
906b) in a standard way utilizing UDDI.
Fig. 9 shows multi-tier services where users 902a-c send a message to access
server
906a-b, which in turn access one or more of service providers 908a-c.
The access arrangement may provide significant advantages for the both users
902a-c
and service providers 908a-c, such as user profile caching. For example, user
902a may have
registered with access server 906a, and necessary profile and preference
information of user
902a may have been stored in a user profile database 108a. Access server 906a
can in turn
access a Web service from service provider 908b, and subsequently transfer a
copy of the
profile of user 902a from user profile database 108a to service provider 908b
and user profile
database 910b. The protocol between the access servers 906a-b may be secure
and trusted.
Once authenticated, the message may be passed securely (e.g. encrypted using
SSL
connections) to another server which can trust the user's authenticity.
Should user 902a want to add access to a new service provider, user 902a may
direct
access server 906a to connect to a new service provider using a Web service
protocol, and
again transfer the profile of user 902a from user profile database 108a to the
new service
provider. Benefits to the user include avoidance of re-entering the same
registration
information, as well as maintaining a single copy of a user's profile (i.e.,
names, preferences,
passwords, etc.). Benefits to the Web service provider include a simplified
security interface
in which to interact with users.
Another advantage that the access arrangement provides may be the creation of
a
"control point", a single place where user's access can be monitored, managed
and logged.
The control point might used for billing or reporting or auditing, for
example.
FIG. 10 shows a flowchart of a method for executing an application utilizing
the
access arrangement according to one or more embodiments of the invention. The
method may
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
be implemented for effecting the execution of an application function on an
application
server from a client device. The client device may be coupled to a proxy
server. The proxy
server may be coupled to the application server that executes an application
implementing the
application function. At step 1002, a text message is received at a text
message destination
address at the proxy server from the client device. In one or more
embodiments, the client
device is coupled to the proxy server via a first network, and proxy server is
coupled to the
application server via a second network. In one or more embodiments, the first
network is
one of a wide area network, and a wireless network. In one or more
embodiments, the second
network is one of a wide area network, a wireless network, and a local area
network. Next, at
step 1004, an authentication message is sent to a user (e.g., genuine client
304 shown in the
example of FIG. 3 or client device 102 shown in the example of FIG. 2) at a
text message
confirmation address that is different from the text message origination
address (e.g., rogue
client 302 shown in FIG. 3). In one or more embodiments, the authentication
message is
transmitted to the user using a first protocol that is different from a second
protocol employed
to transmit the text message from the user.
In one or more embodiments, the first protocol and the second protocol
includes at
least one of SMTP, SMS, MMS, IM, Web service, SOAP, XML, HTTPS, and HTTP. In
one
or more embodiments, the text message confirmation address represents a non-
persistent text
message address that is configured to be inactivated after said
authenticating. In one or more
embodiments, the text 'message destination address is stored in a messaging
address book on
the client device. Finally, at step 1006, if the user is authenticated,
executing the application
function at the application server. For example, the application function may
include
checking a credit limit, getting a stock quote, placing an order, selling
shares of a stock,
looking up a product from a UPC code, and getting a price quote for a product.
FIG. 11 shows a simplified block diagram of an SRA server 106, e.g., SRA
server
106; according to one or more embodiments of the invention. As previously
described, a user
may operate client device 102, such as a mobile device (i.e., mobile phone,
Blackberry, or
PDA), laptop computer, or non-mobile computer. SRA server 106 may connect to
client
devices 102 over a wide area network 104 (e.g., wireless network, Internet,
etc.) to a set of
applications and services 1124a-d. SRA server 106 may include a set of logical
modules, as
discussed below.
Service guard module 1104 may protect SRA server 106 from intrusion and denial-
of-
service attack from hostile devices on wide area network 104. An intrusion may
represent a
21
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
set of actions that attempt to compromise the integrity, confidentiality, or
availability of a
residing resource on or coupled to SRA server 106. A denial-of-service attack
may represent
a type of attack designed to substantially incapacitate SRA server 106 by
flooding it with
useless traffic.
In one or more embodiments, service guard module 1104 may function as a
firewall
for preventing unauthorized access to or from wide area network 104, to (and
from) SRA
server 106. All messages to or from client devices 102 are generally filtered
by service guard
module 1104. For example, service guard module 1104 may use a packet filtering
technique,
in which each packet entering or leaving the wide area network 104 is accepted
or rejected
based on a set of defined rules. In addition, service guard module 1104 may
further include
sub-modules, such as email guard 1104a, SMS guard 1104b, IM guard 1104c, HTML
guard
11 04d. Email guard 11 04a may be configured to protect SRA server 106 from
electronic
mail. In general, because email allows a message to be broadcast to a large
group or
recipients at once, email messages are often used to transport viruses between
computers,
commonly as "attachment" to the message that contains a malicious program
which executes
when opened.
SMS guard 1104b may be configured to protect SRA server 106 from potentially
hostile SMS messages. SMS, or short message service, allows short text
messages to be sent
to mobile phones, fax machines, and/or IP addresses. In general, short
messages may be no
longer than 160 alpha-numerical characters and contain no images or graphics.
IM guard 1104c may be configured to protect against IM messages. IM, or
instant
message, is a type of communications service that enables substantially real
time
communication over the Internet.
HTML guard 1104d may be configured to protect against message containing HTML
code. HTML, or HyperText Markup Language, is commonly an authoring language
used to
create documents on the World Wide Web. HTML generally defines the structure
and layout
of a Web document by using a variety of tags and attributes.
Service guard module 1104 may be coupled to request parser module 1106.
Request
parser module 1106 may include email parser 1106a, SMS parser 1106b, IM parser
1106c,
and HTML parser 1106d to parse email, SMS, IM, and HTML messages,
respectively.
Depending on the message type (e.g., email, SMS, IM, and HTML), request parser
module1106 may divide the text of a request from client device 102 into small
components
that can be analyzed. For example, a request may be structured in the format
instruction-
22
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
variable@server. com, where instruction may represent the request to be
executed by SRA
server 106, such as the location of nearest restaurant, the current weather,
or the transfer of
funds; variable may represent additional information, such as a location,
name, account
number, encrypted tokens as previously described, etc.; and ser=ver=. com is
the name of the
particular SRA server 106 upon which the user wishes to execute the
instruction. Parsing
may be divided into lexical analysis and semantic parsing. Lexical analysis
may concentrate
on dividing strings into components, called tokens, based on punctuation and
other keys.
Semantic parsing may then attempt to determine the meaning of the string or
instruction.
Access control manager module1108 may be coupled to request parser module
1106,
and may control the mechanisms and policies that restrict access to computer
resources on
SRA server 106 (and/or applications and services 1124a-d). In one or more
embodiments, an
ACL, or access control list may be used. An ACL may represent a set of data
that informs
the SRA server 106 which permissions, or access rights, that each user or
group has to a
specific system object, such as one or more of applications and services 1124a-
d. Each
object may have a unique security attribute that identifies which users have
access to it, and
the ACL may represent a list of each object and user access privileges (such
as read, write, or
execute).
Request action bus module 1110 may couple access control manager module 1108
to
service connector module 1112. Once users are authenticated by access control
manager
module 1108, user requests may be queued in request action bus module 1110,
where they
may be pulled off by service connector module 1112, based on scripts in
service scripts
module1132, when the appropriate application(s) or service(s), for example,
one or more of
applications and services 1124, becomes available. A script may represent a
macro or batch
file with a list of SRA server 106 commands that can be executed without user
interaction. In
'one or more embodiments, a particular script language may be employed to
write scripts for
service scripts 1132. In one or more embodiments, the order in which SRA
server 106
executes user requests on request action bus module 1110 may be the same order
that they
were placed on the queue. In one or more embodiments, some user requests may
be given
higher priority than others.
Inbound messages from a user may be augmented with user profile information,
such
as one or more of credentials, preferences, default values, trusted reply
path, reply protocol,
response formatting, authentication method required, etc. This may allow
concise requests to
minimize user typing yet provides rich data for the processing which may
perform complex
23
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
operations. This method avoids the need to send credentials over the network
or even to put
the credentials at risk to malicious software or the sending device.
Service connector module 1112 may include a set of connectors and/or adapters
for
connecting to applications and services 1124a-d. For example, WSDL connector
11 12a may
enable SRA server 106 to connect to one or more of Web services 1124a. WSDL is
generally
an XML-formatted language used to describe a Web service's capabilities as
collections of
communication endpoints capable of exchanging messages. In one or more
embodiments,
WSDL connector 11 12a may connect to a UDDI directory. UDDI, or universal
description,
discovery and integration, is generally a Web-based distributed directory that
enables
businesses to list themselves on the Internet and discover each other, similar
to a traditional
phone book's yellow and white pages.
HTML connector 1112b may enable SRA server 106 to connect to one or more of
Web applications 1124b. As previously described, HTML is commonly an authoring
language used to create documents on the World Wide Web. HTML connector 11 12b
may
allow portions of previously created Web pages to be extracted and delivered
to client
devices 102.
UI connector 1112c may enable SRA server 106 to connect to one or more of
client
applications 1124c through a UI, or user interface. The UI may represent an
interface with a
set of commands or menus through which a human user communicates with a
program. In
order to substantially reduce the need for additional programming, UI
connector 11 12c may
be configured to mimic a human user, automatically querying and extracting
relevant
information from remote user applications, such as a CDROM encyclopedia or map
program.
API connector 11 12d may enable SRA server 106 to connect to one or more of
application servers 1124d. API, or application program interface, may
represent a set of
routines, protocols, and tools for building software applications. An app
server, or application
server, is generally a program that handles application operations between
users and backend
applications or databases. App servers are typically used for complex
transaction-based
applications. For example, API connector 11 12d may connect SRA server 106 to
a SAP
application server, allowing a user to query customer order status from client
device 102.
Service admin module 1114 may enable a SRA server 106 administrator to
securely
manage a collection of networks, computers, and databases.
24
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
Profile management module 1116 may enable SRA server 106 to maintain a set of
service and resource profiles for each user. For example, a user may desire
requests to be
customized depending on the type client device 102 through which the request
is made.
Service provisioning module 1118 may enable a SRA server 106 administrator to
provide users with access to one or more of services and applications 1124a-d.
In general,
provisioning comprises allowing a particular user access to one or more
particular services
and/or applications, based on user identity and a particular profile stored in
profile
management module 1116.
Service monitoring module 1120 may enable a SRA server 106 administrator to
create an inventory of all the hardware and software on the network and to
perform
diagnostic tests.
Usage reporting module 1122 may monitor and report resource utilization within
SRA
server 106, as well as user access to services and applications 1124.
In one or more embodiments, transaction state may be maintained through the
use of
temporal mailboxes. Commonly on the Internet, transaction state is often
maintained through
the use of browser cookies. A cookie is typically a small message given to a
Web browser by
a Web server. The browser stores the message in a text file, and sends the
message back to
the server each time the browser requests a page from the server. By allowing
the Web
server to identify a particular browser (or user) between successive Web page
requests,
cookies may provide a rudimentary form of transaction security. That is, the
particular
browser that begins the transaction (i.e., a user purchasing a book from
Amazon.com) should
be the same browser that completes the transaction.
However, unlike browsers, mobile device applications are generally optimized
for
communication and not transactions. That is, although mobile devices are
fairly good at
sending and receiving voice and text messages, such as email and SMS, the
physical size and
computational capabilities of many mobile devices may make them less effective
as a user
interface to Internet applications, such as Web servers. Subsequently, there
is generally no
equivalent to a cookie for maintaining transaction state in mobile device
messaging
applications.
In a non-obvious way, a service mailbox (service address) may be used as a
substitute
for a cookie in order to maintain transaction state, in one or more
embodiments. That is,
instead of locally storing a cookie, the client device is granted a set of
unique return address
or service mailbox es. A response to a specific service mailbox signals a
particular change in
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
state for a particular client device to the SRA server 106. For example, for a
transaction that
may involve multiple requests, such as selecting a path through a menu tree,
responding to a
particular service mailbox corresponds to a specific menu choice, which may
cause the next
level of choices to be transmitted to the client device. A menu may include
authentication
queries in one or more embodiments.
Compare this with Web pages and hyperlinks. Navigation is made simple by
clicking
the links. Service mailboxes are used in messages as simple links to click.
The state
information associated with the particular service mailbox conveys all the
necessary
navigation and transaction information. Using service mailboxes in the manner
makes the
messaging system as easy to use as the Web.
For example, a user may wish to access a SAP application through a SRA server
106,
in order to view the total amount of the most recent order for a particular
customer. Once the
user has been authenticated by access control manager 1108, the user may be
able to send a
first text message to a particular email address at the SRA server 106, which
subsequently
instructs the SRA server 106 to communicate with the SAP application, based on
previously
defined profile information and scripts. For instance, the server address
(service address)
may be entered as cm-SAP @seNver.com, with a subject of name-customername,
where
customername is the name of the particular customer of interest, and server.
com is the name
of the particular SRA server 106 upon which the user wishes to execute the
instruction.
The SRA server 106 would then return a text message to the client device with
a
simplified menu in the body of the message:
Invoices: cm-SAP-10000 @server.com
Current Orders: cm-SAP-20000 @server. com
Back Orders: cm-SAP-30000 @senver.com
Other: cm-SAP-40000 @server.com
Return: cm-SAP-50000 @server.com
Each menu item includes service identification information, such as SAP-10000,
SAP-
20000, SAP-30000, etc. By sending a text message to cm-SAP-20000 @server. com,
a new
message will be transmitted with a simplified sub-menu in the body of the
message:
total order amount to date: cm-SAP-11000 @server.com
quarterly order am.ount to date: cm-SAP-22000 @sey ver. com
monthly order amount to date: cm-SAP-33000 @server. com
last order amount: cm-SAP-44000 @server. com
26
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
Other: cm-SAP-55000 @server. com
Return: cm-SAP-66000 @server.com
Sending a text message to cm-SAP-44000 @server.com, will instruct the SRA
server
106 to transmit the total amount of the last order for customer customer name.
Note that the service mailbox name may be encrypted for added security. Since
the
user can click the link and does not need to type the address, a long
encrypted key can be
used if such is desired.
In one or more embodiments, two-factor authentication may be used with the
access
arrangement. As previously described, highly trusted requests may require the
sender to
confirm the transaction, such as with a confirmation message or authentication
token.
However, if the communication channel or path is compromised, an intruder may
intercept
the confirmation message or authentication token and correctly respond,
causing the SRA
server 106 to believe that the real user has properly confirmed the
transaction. In order to
increase the level of security, at least two communication channels may be
used, a primary
transaction channel and a secondary confirmation channel.
For example, a bank may have an access server coupled to an ATM machine for
authentication purposes. A customer wanting to withdraw above a fixed amount
from an
ATM (i.e., > $300) will receive a SMS message with one-time identification
information,
such as a particular OTP (one time PIN), on the user's client device (i.e.,
mobile phone, PDA,
etc.) which will need to be entered into the ATM within a short period of time
(e.g., three
minutes after the OTP is sent) in order to complete the transaction.
In another example, a customer using a browser and wanting to transfer money
from
the bank's Website to a third-party account would receive the SMS message with
an OTP
that would need to be entered into the browser window. In another example, the
ATM
machine or bank Website generates the security serial number that must be
transmitted from
the client device to the access server via SMS or email, before the
transaction is authorized.
In one or more embodiments, the serial number or token is generated by a smart
card,
such as a RSA SecurlD Authenticator device. A smart card may represent a small
electronic
device about the size of a credit card that contains electronic memory, and
possibly an
embedded integrated circuit (IC). Smart cards containing an IC are sometimes
called
Integrated Circuit Cards (ICCs). When the user wishes to withdraw or transfer
funds, a
message may be received on the client device requesting the then current
token. In one or
more embodiments, the confirmation message is sent to a user other than the
user who is
27
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
making the access server request. For example, before an employee can transfer
or withdraw
funds, a confirmation message is sent to the employee's supervisor for
authorization.
In one or more embodiments, an access arrangement can use a mobile device SIM
for
transaction authorization. Short for subscriber identity module, a SIM is
generally, a smart
card inside of a GSM cellular phone that encrypts voice and data transmissions
and stores
data about the specific user so that the user can be identified and
authenticated to the network
supplying the phone service. The SIM also stores data such as personal phone
settings
specific to the user and phone numbers. A SIM can be moved from one phone to
another
and/or different SIMs can be inserted into any GSM phone. Since identity
information on
each SIM is generally unique, a transaction may be securely authorized by
first transmitting a
confirmation message to the mobile device, encrypting the confirmation message
with the
SIM card, and returning the confirmation (or a cryptographic hash of the
confirmation) to the
access server.
In one or more embodiments, an access server may provide single signon
functionality. An authentication process in a client/server relationship,
single signon allows
the user, or client, to enter one name and password and have access to more
than one
application or access to a number of resources within an enterprise. Single
signon generally
reduces the need for the user to enter further authentications when switching
from one
application to another.
In one or more embodiments, an access server may connect with client devices
that
are enabled with XForms, a W3C standard. Unlike standard HTML Web forms which
generally require that each form be transmitted to the Web server after data
entry, XForms
enabled applications may allow a set of forms to be processed locally and then
subsequently
transmitted to a Web server as an XML document. In addition, by using XML for
data
definition and HTML or XHTML for data display, XForms enabled applications may
be
customized for different user interfaces, such as mobile phones, handheld
devices, and Braille
readers for the blind.
In one or more embodiments, an access sever may communicate with a RFID-
enabled
mobile device. Short for radio frequency identification, an RFID system
generally consists of
an antenna and a transceiver, which radiates the radio frequency and transfer
the information
to a processing device, and a transponder, or tag, which is an integrated
circuit containing the
RF circuitry and information to be transmitted. Unlike bar coding
technologies, RFID
eliminates the need for line-of-sight reading and can be done at greater
distances. There is
28
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
significant advantage for the user who would otherwise have to type the
information. There
may be also significant advantage for the mobile RFID device; it needs to
communicate with
some server, and access arrangement according to one or more embodiments of
the present
invention may offer a simple, low cost and effective solution to this problem.
For example, if a user wants drug interaction information between two
medicines, an
RFID-enabled mobile device may first read RFID information on or in each
medicine
container. This RFID information is then be transmitted to the access server
which, in turn,
queries a drug interaction database service. The access server may then send
the specific
drug interaction information as a reply to the mobile device as a customized
text message.
In one or more embodiments, an access sever may communicate with a GPS-enabled
mobile device. Short for Global Positioning System, GPS is generally a
worldwide satellite
navigational system formed by 24 satellites orbiting the earth and their
corresponding
receivers on the earth. The GPS satellites continuously transmit digital radio
signals that
contain data on the satellites location and the exact time to the earth-bound
receivers. By
using three satellites, GPS can calculate the longitude and latitude of the
receiver based on
where the three spheres intersect. By using four satellites, GPS can also
determine altitude.
For example, if a user wants location specific information, such as the
location of a
restaurant, the user's current location may be automatically transmitted to
the access server
by the GPS-enabled mobile device, instead of manually entered by the user. The
access
server may then respond with a text message including directions to the
desired address from
the current address. As with the mobile RFID reader, this may represent a
significant
advantage to the user, who does not to enter the location information
manually, which tends
to be tedious and error prone.
In one or more embodiments, address book entries in the mobile device may be
used
for command syntax help and/or hints. For example, a user can query an access
server for a
general help menu by sending a message to a help address, such as
cmhelp@server.com ,
where cmhelp is the particular help request, and server. com is the name of
the particular
access server at which the user wishes to execute the help instruction. For
example, upon
receipt, the following simplified general help menu may be returned as the
body of a text
message:
mailto:cmCurrency@server.com
Lookup currency at GoCurrency.com
29
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
mailto:cmDictionary@server.com
Lookup words at www.dictionary.com
mailto:cmDirections@server.com
Driving Directions from www.mapquest.com
mailto:cmFroogle@server.com
Froogle search for products froogle.google.com
mailto:cmGoo@server.com
Google search for PDA display google.com/palm
More specific help can be obtained, for example, by sending a particular
request with
the word "Help" in the subject.
In one or more embodiments, a set of abbreviations may be used in order to
reduce
the amount of user typing. For example, a user can query an access server for
a set of
abbreviations by sending a message to cmkeyget@server.com , where cmkeyget is
the
abbreviation or key request, and server. com is the name of the particular
access server at
which the user wishes to execute the help instruction. For example, upon
receipt, the
following simplified general help menu may be returned as the body of a text
message:
SFO - address 1
LAX - address 2
HOME - address 3
A user can then modify existing keys, or add new ones, and then transmit the
text to
cmkey@server.com. Subsequently, the user can request directions from his home
to the San
Francisco Airport by sending a text message to
cmdirection:HOME:SFO@server.com.
In one or more embodiments, the key of LOCN may be assumed to be the default
key
for requests that involve location, when a required key is missing. In one or
more
embodiments, the user's present location if known (i.e., by a GPS-enabled user
device,
previously entered by the user, etc.) may be assumed to be the current
location key for
requests that involve location. For example, sending a message to
crostarbucks@server=. com ,
with no subject, will generally cause the access server to return directions
to the nearest
Starbucks from what it believes is the user's current location.
CA 02627534 2008-04-28
WO 2007/059183 PCT/US2006/044284
While this invention has been described in terms of several preferred
embodiments,
there are alterations, permutations, and equivalents which fall within the
scope of this
invention. The titles and abstracts are provided herein for convenience and
should not be
used to interpret the invention in a manner so as to limit the scope of the
claims herein.
Advantages of the invention include architecture for general purpose trusted
personal
access system and methods therefore. Additional advantages include a hosted
access
infrastructure for managed enterprise access to both internal and external
sources, a
manageable infrastructure for directed transactional access to applications
and Web services,
and enhanced productivity and lower total cost of ownership (TCO).
Having disclosed exemplary embodiments and the best mode, modifications and
variations may be made to the disclosed embodiments while remaining within the
subject and
spirit of the invention as defined by the following claims.
31
