WO2001057724A1 - Interactive agent for mobile device - Google Patents

Abstract

A system for providing an intelligent agent which is arranged to carry out tasks in response to instructions from a user, the tasks being actioned in a network environment, the system comprising agent interface means arranged to provide an agent interface at a user terminal for interaction with a user, and agent implementation means for implementing tasks instructed to the agent interface by the user, the user terminal typically comprising a mobile communications device utilising a mobile communications network for communications.

Description

INTERACTIVE AGENT FOR MOBILE DEVICE

Field of Invention

The present invention relates to a system for providing an intelligent agent in a network environment, and, particularly, but not exclusively, to a system for providing an intelligent agent for use with mobile communications devices .

Background of Invention

Mobile communications networks are well known. They include cellular telephone networks, satellite based networks, etc. Communication is most usually voice to voice although message services, such as SMS are becoming more prevalent with mobile telephones. In addition, computing devices capable of utilising mobile telephone networks for communications are available. These include, in particular, "small computing devices", including laptop computers, palm-top type computers. Mobile telephones also fall within the definition of small computing device.

These types of small computing devices may use the mobile communications networks to interface with other types of networks, such as the Internet to eg. download information. Communication networks which enable different types of devices (not necessarily compatible devices) to communicate with each other are also known, utilising such technologies as BLUETOOTH™.

Communications via mobile networks require direct "on-line" operation by a user. That is, for voice to voice communications a user must dial a number (or hit an auto-dial button) and then converse with the called party in real time. Message services in mobile network, such as SMS also require operation of an interface to enter a

Substitute Sheet ⁽Rule 26) RO/ATJ message and respond to a message. Similarly, accessing other networks such as the Internet requires the user to operate an interface in real time to access the required Website and download the required information. Intelligent agents, which do not require real-time user operation to carry out tasks instructed by a user, are known but are primitive. These include "Webbots" and "Crawlers" which can locate information on the Internet in accordance with instructions provided by a user^'. They are not known for use with small computing devices communicating via mobile communications networks, such as mobile telephones.

Summary of Invention . From a first aspect, the present invention provides a system for providing an intelligent agent which is arranged to carry out tasks in response to instructions from a user, the tasks being actioned in a network environment, the system comprising agent interface means arranged to provide an agent interface at a user terminal for interaction with the user, and agent implementation means for implementing tasks instructed to the agent interface by the user.

An "intelligent agent" in its broadest sense, as intended in the present specification, is a separate entity (software or hardware or a combination of software and hardware) which is able to operate to carry out instructions of a user or operator. An intelligent agent does not require real-time control by a user in order to carry out a task that has been instructed.

The network environment may be any network environment. Preferably, the network environment is a public access network such as a mobile communications

Substitute Sheet ⁽Rule 26) RO/AU network. The mobile communications network may interface with other networks such as the Internet and the intelligent agent can preferably access any interfaced networks to carry out tasks utilising those networks. The user terminal is preferably a small computing device, and is preferably a palm-top computing device or mobile telephone type device. The user terminal is preferably a mobile device, such as palm-top computer having mobile communications facility, or a mobile telephone.

The agent implementation means can preferably enable tasks to be carried out by the intelligent agent such as taking part in competitions. A mobile telephone user having access to an intelligent agent, therefore, could enter and take part in a competition implemented by the system, such as a quiz*. In return for success in the competition, the mobile user may win prizes. Such a use of the intelligent agent has the commercial effect of promoting network usage and therefore increasing revenue to the mobile network owner.

The intelligent agent is preferably able to carry out tasks other than taking part in competitions. Other tasks include obtaining information requested by the user (for example by "trawling" the Internet for the information) ; ordering tickets to entertainment venues (for example, ordering theatre tickets) - this particularly illustrates the advantages of using an intelligent agent in accordance with the present invention. Much time can be spent by a user on a telephone ordering tickets for entertainment venues. With the present invention, the intelligent agent does all the "work" in ordering the tickets without, any intervention required by the user apart from the original instructions (and perhaps confirmation of an order once

Substitute Sheet ⁽Rule 26) RO/ATJ the intelligent agent has placed it) ; electronic commerce transactions on behalf of the user (this could include purchasing goods on behalf of user from, for example, Internet sites) . Preferably, the intelligent agent becomes associated with a particular user. In other words, the intelligent agent becomes "personalised" . It acts as the users "helper" and stays with the user for a long period of time. The idea of an intelligent agent which is associated with a particular user and in a sense "belongs" to the user is a novel one.

Preferably, the user terminal is a personal device which belongs to the user only. This is usually the case with palm-top type computers and certainly the case with mobile telephones. Such a personal device usually incorporates facilities to ensure security. Preferably, security means are provided on the user terminal preventing unauthorised persons from accessing the intelligent agent. The agent therefore becomes a "trusted" agent, personal to the user ("a personal trusted agent") . In mobile telephones, for example, a key set (eg. RSA) and a digital certificate (eg. X509) may exist on the mobile to allow it to act as a secure device and perform secure transactions. The intelligent agent may utilise this key set and be verified via the use of a digital signature.

Preferably, therefore, the intelligent agent is securely associated with a particular user, preventing other persons from using the intelligent agent associated with the user, or impersonating the intelligent agent.

The system of the present invention also preferably comprises attribute implementation means, arranged to

Substitute Sheet ⁽Rule 26) RO/AU implement the provision of attributes to the intelligent agent .

The attributes are preferably arranged to determine the functionality of the intelligent agent in carrying out tasks. For example, one attribute may determine how

"good" an intelligent agent is at competitions, and could be termed "IQ". If a particular intelligent agent has a high IQ it may have a particular facility for competitions or particular types of competitions . The intelligent agent may have other types of attributes which determine its functionality in different ways .

Preferably, the attribute implementation means is arranged to affect changes in the attributes of the intelligent agent in accordance with predetermined criteria.

The predetermined criteria may include operation of the intelligent agent in carrying out tasks, preferably historical operation. For example, if an intelligent agent has entered a number of competitions and has done well in them, this may automatically (implemented by the attribute implementation means) lead to an increase in the IQ of the agent . Another option is that a user may purchase new attributes (such as the facility, for eg. to obtain theatre tickets) from the system. Preferably, the intelligent agent is arranged to "learn" as it is carrying out tasks for the user, the intelligent agent will pick up information while it is carrying out these tasks which can assist it in future tasks. In particular, the intelligent agent can acquire more knowledge about the user as it performs tasks. Preferably, the system provides a plurality of intelligent agents for use by a plurality of associated users. The users are preferably identified to the system.

Substitute Sheet ⁽Rule 26) RO/AU This need not be by actual name, but could be by an identity number, for example.

Preferably, the system also includes an agent interaction means which is arranged to enable interaction between intelligent agents. For example, a user's intelligent agent may carry a message for delivery to other user's intelligent agents.

Preferably, where the system also includes an attribute implementation means for providing attributes to the intelligent agent, interaction between intelligent agents may depend on the respective attributes of the intelligent agents. For example, "compatible" intelligent agents may interact whereas "non-compatible" intelligent agents will not interact. Compatibility can be determined by attributes both learned (as discussed above) or provided by a user, such as "appearance", "personality", "nationality" etc . These attributes may reflect attributes of the user (or may not) as may be determined by the user. Compatibility between intelligent agents may eventually lead to the users communicating with each other, eg. by exchanging mobile telephone numbers. An advantage of this method of communication is that in the initial stages of intelligent agent interaction it is not necessary to divulge any personal details of the user, such as telephone number. Interaction can proceed to a level where the users decide they actually want to talk to each other before the exchange of telephone numbers is required. The system preferably further includes user "mood" determination means which is arranged to determine the mood of the user and affect the operation of the intelligent agent accordingly. Mood can be determined in

Substitute Sheet ⁽Rule 26) RO/ATJ relation to any aspect of the user's behaviour. For example, if the user is busy, they may not wish to be "bothered" by interaction with the intelligent agent and the intelligent agent's behaviour will be adjusted accordingly. The assessment of whether or not the user is busy could be determined monitoring a number of factors including actual information input by the user to the user terminal, use of the user terminal (if use is frequent, it is likely that the user is busy) . Also, if the user has been put into "silent" mode it is likely that the user is busy.

The system preferably further includes push content provision means for providing push content to the user terminal in association with the operation of the intelligent agent. It is therefore possible for third party originating information to be provided to the user via the intelligent agent, which can include advertising, for example. Revenue can thus be earned from the system and it may not even be necessary to charge the user for the intelligent agent, which makes the system very attractive to a user. Further, push content can be "targeted" taking account of the attributes of the particular intelligent agent (particularly where these may reflect the personality of the user) and operation of the intelligent agent (eg. monitoring the type of tasks that the user puts the intelligent agent to) . Advertising information therefore becomes less intrusive, as it is targeted towards the particular user ie. the user actually wishes to receive this type of advertising information. The user may indicate what type of information he wants to receive by input to the user terminal .

Preferably, the system further includes means arranged to determine the location of a user terminal

Substitute Sheet ⁽Rule 26) RO/AU associated with an intelligent agent. Where the user terminals are mobile terminals, such as mobile telephones, this system can preferably locate the mobile telephone physically. The agent implementation means is preferably arranged to affect operation of the intelligent agent in accordance with the- physical location of the user terminal. It may detect, for example, that the location of the intelligent agent is proximate a particular retail location, enabling push content to be broadcast to the user terminal via the intelligent agent, relevant to the particular retail location.'

The agent interface is preferably arranged to represent the intelligent agent at the user terminal as a characterisation, eg. as a type of "creature", having attributes as discussed above. The "creature" essentially "lives" on the user terminal and carries out tasks for the' user. Over time it becomes the user's "friend". This type of personalised intelligent agent is particularly novel. In particular, with the security means discussed above, the user can completely trust the intelligent agent

(as other parties are prevented from fraudulently using or impersonating the intelligent agent) . The intelligent agent becomes the user's "trusted intelligent agent".

The user terminal may be arranged to interface with a number of networks. For example, one interface may be with a mobile communications network via a mobile communications network operator. The agent implementation means may at least in part be provided by the network operator or a system connected to or associated with the network operator. A first network interface means is provided at the mobile user terminal to interface with the mobile network (e.g. a wireless transceiver for transmission/reception with mobile network base stations) .

Substitute Sheet ⁽Rule 26) RO/ATJ Preferably, the user terminal may in addition be provided with further network interface means, for interfacing with further networks. For example, a transceiver may be provided for interfacing with a micro-network in, for example, a retail store or restaurant. The agent may, therefore, obtain information via the micro-network and carry out a task by the micro-network e.g. with a BLUETOOTH server m a restaurant or retail store.

Preferably, the system is also arranged to provide transient agents which include a transient agent interface means arranged to provide a transient agent interface at a user terminal and transient agent implementation means for implementing transient agent tasks. A transient agent may be broadcast, for example, to a plurality of user terminals as push content e.g. to provide a retail offer. For example, a transient agent representing RONALD MCDONALD™ may be transmitted to a plurality of user phones via the network, advertising a special offer relating to MCDONALDS™ restaurants. The transient agent may, at least in part, reside in a storage means on the user terminal. When the user enters a MCDONALDS™ restaurant they can download the transient agent to a MCDONALDS™ portal to obtain the benefit of the special offer. Alternatively, a micro-network in a MCDONALDS™ restaurant could be accessed so that the transient agent can implement the offer over the micro-network. Transient agents may be utilised to implement any number of tasks . They may exist as a "voucher" relating to a special offer, as discussed above. They may also assist or implement other push content, such as straight forward advertising.

From a second aspect, the present invention provides a method of enabling a user of a user terminal in a network environment to carry out tasks , the tasks being

Substitute Sheet ⁽Rule 26) RO/AU actioned in the network environment, comprising the steps of implementing in the network environment an intelligent agent which is arranged to carry out the tasks instructed by the user via the network terminal. The method of this aspect of the invention may employ the system discussed above.

From a third aspect, the present invention provides a user terminal arranged to facilitate implementation of an intelligent agent which is arranged to carry out tasks in response to instructions from a user, the tasks being actioned in a network environment, the user terminal including network interface means for interfacing with a network environment, and agent interface means arranged to provide an agent interface at a user terminal for interaction with the user. The agent interface being arranged to interface with agent implementation means for implementing tasks instructed to the agent interface by the user.

Preferably, the agent implementation means resides at least in part elsewhere in the network environment .

Preferably, the user terminal is a mobile terminal for use with a mobile communications network.

Preferably, the user terminal is arranged to be used with a system as discussed above in relation to the first aspect of the present invention, and may have any or all of the features of the user terminal of that system.

From a fourth aspect, the present invention provides a computer program arranged when loaded into a computing system connected in a network environment, to control the computing system to implement an agent implementation means for implementing at least in part an intelligent agent arranged to carry out tasks to be

Substitute Sheet ⁽Rule 26) RO/ATJ actioned in the network environment in response to instructions from a user of a user terminal.

Preferably, the computer program is arranged to implement any or all of the features of the agent implementation means of the intelligent agent discussed above in relation to the first aspect of the present invention.

From a fifth aspect, the present invention provides a computer readable medium providing instructions arranged, when loaded into a computer system connected in a network environment, to control the computing system to provide an agent implementation means for at least in part implementing an intelligent agent- which is arranged to carry out tasks to be actioned in a network environment in response to instructions from a user.

Preferably, the agent implementation means is implemented in accordance with the agent implementation means discussed above in relation to the first aspect of the present invention. From sixth aspect, the present invention provides a computer program arranged, when loaded into a user terminal arranged to be connected within a network environment, to implement an agent interface means arranged to provide an agent interface at the user terminal for interaction with the user, and arranged to interact with an agent implementation means in order to implement an intelligent agent arranged to carry out tasks within the network environment in response to instructions from the user. Preferably, the user terminal is a mobile terminal arranged to be connected within a mobile communications network.

Substitute Sheet ⁽Rule 26) RO/ATJ Preferably, the user terminal may have any or all of the features of the user terminal discussed above in relation to the first aspect of the present invention. From a seventh aspect, the present invention provides a computer readable medium, providing instructions for controlling a user terminal arranged to be connected in a network environment, to cause the user terminal to implement an agent interface means arranged to provide an agent interface for interaction with the user, and for interaction with an agent implementation means, for implementing an intelligent agent arranged to carry out tasks within the network environment in response to instructions from the user.

The user terminal is preferably a terminal for use with a mobile communications network.

Preferably, the instructions may implement a user terminal having any or all of the features of the user terminal discussed above in relation to the first aspect of the present invention.

Brief Description of the Drawings

Features and advantages of the present invention will become apparent from the following description of embodiments thereof, by way of example only, with reference to the accompanying drawings, in which;

Figure 1 is a schematic diagram illustrating a high level topology of a system in accordance with an embodiment of the present invention;

Figure 2 is a schematic diagram illustrating a topology of the "home" server of Figure 1;

Figure 3 is a schematic diagram illustrating a topology of the "distributor" server of Figure 1;

Substitute Sheet ⁽Rule 26) RO/AU Figure 4 is a schematic diagram illustrating an architecture of an intelligent agent utilised according to the system of the embodiment of Figures 1 to 3;

Figure 5 is a schematic flow chart showing operation of an intelligent agent in accordance with the embodiment of Figures 1 to 5;

Figure 6 A and B are screen displays illustrating user interface representations for systems in accordance with further alternative embodiments of the present invention;

Figure 7 is an illustration of the topology of a system "gateway" in accordance with a further embodiment of the present invention;

Figure 8 is a diagram illustrating the general architecture of the embodiment of figure 7 ;

Figure 9 illustrates the architecture of a JAZZ server utilised to realise the architecture of figure 8;

Figure 10 is a diagram illustrating on-demand RMS provided by the JAZZ implementation; Figure 11 is a diagram illustrating the connections of the system of the embodiment of figure 7;

Figure 12 illustrates the communication pathway between the agent container and agent gateway of the embodiment of figure 7; Figure 13 is a diagram illustrating the run time environment of an embodiment in accordance with the embodiment of figure 7 utilising JAVA card SIM;

Figure 14 is a diagram illustrating a menu structure of the user interface in accordance with an embodiment of the present invention;

Figure 15 is a diagram illustrating the object classes of an agent container in accordance with an embodiment of the present invention;

Substitute Sheet ⁽Rule 26) RO/ATJ Figure 16 is a diagram illustrating the architecture of an agent container in accordance with a further embodiment of the present invention, utilising J2ME MIDP; Figure 17 is a diagram illustrating the run time environment of the J2ME MIDP agent container, and

Figure 18 is a further diagram illustrating the agent container implemented by J2ME MIDP .

Detailed Description of a Preferred Embodiments The following descriptions are of examples of applications of the system in accordance with the present invention, utilising example embodiment systems in accordance" with particular preferred architectures. It will be appreciated that other architectures could be used to implement the system of the present embodiment. It will also be appreciated that a skilled software engineer will be able to implement the "means" of the invention (eg. agent implementation means, agent interface, agent interaction means, attribute implementation means, user mood determination means, push content provision means, means arranged to determine the location of the user terminals, agent containers, transient agents), using known software/hardware technology, and a detailed description of their implementation is not given in the following. The following examples particularly relate to an intelligent agent or "creature" implemented by a system in accordance with the present invention, for mobile telephone networks . The particular example given in the first embodiment (Figures 1 to 5) of the tasks the intelligent agent can carry out is taking part in competitions . It will be appreciated that other tasks can be carried out, as discussed above.

Substitute Sheet ⁽Rule 26) RO/AU A first embodiment of the present invention will now be described with reference to Figures 1 to 5.

The system of this embodiment is implemented as an online service for mobile telephone network customers . It provides operators with the ability to quickly devise and deploy new competitions designed to foster customer loyalty to the network operator and generate increased traffic levels across their networks by utilising the power of Java Card and wireless terminal technology (eg. SMS, IR, BLUETOOTH etc.).

The system implements an intelligent agent which is in the form of a "creature" which appears as a characterisation implemented by the agent interface on the mobile telephone of the user. It may appear as a cartoon type character on the mobile display, for example, and have various attributes, such as nationality, personality, IQ, some of which can be determined by the user and others of which may be determined by operation of the intelligent agent. The intelligent agent can enter competitions in accordance with instructions from the user.

Long term customer loyalty to a network is fostered because:

Competitors know that by using their mobile terminals, they can be rewarded by winning prizes or accepting special offers/discounts and can have fun by solving puzzles and socialising.

Competitions result in the evolution of a virtual creature, (the intelligent agent) that represents the mobile phone .user within the world of the wireless network .

Over time, the creature will take^' on a persona, increased attributes and have the ability to perform tasks

Substitute Sheet ⁽Rule 26) RO/ATJ for and on behalf of the network user. Moving from one network to another may result in loss of the character.

Ultimately, the objective is to ensure that the consumer forms an emotional attachment to the character compelling them to support its development and life cycle on a specific operator network.

The network user can inform their creature of what sort of mood they are in (via the mood determination means) . This allows the creature to adjust the content it delivers to its owner as well as its style and frequency interaction. Note that mood can be determined in a number of ways . One example is by monitoring the voice of the user. Voice patterns can indicate moods and voice activation/recognition facilities are known and being developed all the time.

For the scenario outlined below, let's call our mobile subscriber "Tony" (the user) . • Let ' s play... Tony decides to register for a competition Tony has 3 ways of registering:

The preferred way is for the system (being an on-line service) to send a message for broadcasting to all of the associated operator's subscribers' mobile phones asking if they would like to register. All Tony would need to do is respond to the broadcast message.

He may call his network operator's competition support line and ask the operator to enrol him for the competition.

Tony may send a message from his mobile phone to a dedicated number for competition registration.

Tony decides to register by creating a message on his mobile phone that reads "Register Tony" , enters the number

Substitute Sheet ⁽Rule 26) RO/AU he was given for competition registration and sending the message Tony is now registered

• Hi Moby!

Tony receives a message on his mobile phone - the agent interface is downloaded by the system to the mobile phone, in this example the agent interface is downloaded in the form of a Java Applet which can be downloaded to the SIM Card of the mobile phone. The Applet provides a characterisation of the "creature" on Tony's phone as well as an interface via which Tony may communicate with the creature .

The creature is now on Tony's phone. It lives there, it represents him, it works for him, it moves in the wireless network - it's Tony's friend!

• Inseparable...

Tony and his creature are now partners learning, playing and socialising together

• Learning together

Tony selects the "Learning" option

Tony can now provide the creature with various attributes. Tony can now personalise his creature - he gives it a name

He can give it a personality - he gives it an age, selects the type of creature he wants, its nature, selects a nationality and a star sign. These attributes are used by the creature to meet with other creatures when it is socialising.

• Playing together

Tony selects the "Play" option

Substitute Sheet ⁽Rule 26) RO/ATJ He picks the "Find Competitions" option. The creature is then dispatched to the network to find out what competitions are available for Tony to enter in. the creature returns to Tony's phone and presents him with the available competitions .

Tony selects an option to join an available competition. The creature goes up to the network and enrols him into the competition. It brings back the options for the competition. In this case, the only option is to solve a puzzle.

Tony selects this option. A message is presented to Tony asking him when the Sydney Opera House was opened.

Tony enters "1974" into the entry field provided and selects "enter" .

Tony receives a message telling him that he is correct, that he has scored 10 IQ points and that he needs 50 more points to enter the competition draw. "IQ" is in this case a further attribute of the creature which can be adjusted during creature carrying out tasks such as entering competitions (as in this case) . If the IQ attributes keeps increasing, until it reaches 60 points, the creature will then enable Tony to enter a competition draw. Tony selects "Next"

A promotional message comes up saying:

That puzzle was brought to you by City Honda - your one stop shop for Honda cars". Push content provision means (which could be a connection to an advertising server) provides such promotional messages. • Socialising together

Tony can send his creature away to meet other creatures (mobile users) in the virtual world..

Substitute Sheet ⁽Rule 26) RO/ATJ Tony can attach messages for his creature to give to other creatures (mobile users)

Tony can tell his creature what sort of creature his creature should try to meet. In this way, Tony can meet with users on the mobile network and can exchange messages with them via their creatures or, on request from the creatures he meets them (similar to a party line style of environment) , by exchanging mobile phone numbers and calling each other. The creatures may select whether or not they are "compatible" by comparing their attributes.

• Winning together

The system broadcasts advertising and promotional messages to creatures . Tony's creature passes on advertising and promotional messages it has received to him.

Tony chooses to reply to a promotional message that interests him allowing him to go onto the promoter's mailing list or call the promoter directly.

While the above example is one example of a possible competition that can be run by an operator, the creatures developed by contestants live longer than any one competition. In this way, the more competitions that a contestant enters, the more valuable their creature becomes (by changes in attributes) and the greater chance they have of winning.

New competitions may be designed to enhance different attributes of the creature. The first is IQ, another may be related to appearance, nature etc.

A creature may be able to interact in a way that takes its owner's personal preferences and current mood

Substitute Sheet ⁽Rule 26) RO/ATJ into account thus making the creature even more valuable to its owner at a more personal level .

These creatures may become virtual, personal companions that live on the mobile terminal. The user's terminal is provided with a security means, utilising technology such as RSA and X509, ensuring that the device is secure and also ensuring that operation of the intelligent agent is secure. The intelligent agent becomes a trusted personal companion associated with the particular user.

One of the key concerns for wireless network operators today is network churn, that is, the proportion of the operator's subscribers who switch over to a competitor. Research has shown that the average churn for an operator is 30% per year and the cost of acquiring a new subscriber is $300. If an operator with 2 million subscribers could drop their churn rate from, say, 30% to 25%, this would save them $30 million annually.

The system in accordance with the -present embodiment may offer personalised over the air promotions that foster customer loyalty and lower network churn.

This embodiment is attractive to GSM operators as its primary focus is on operating and managing a personalised marketing activity that has the potential to create long term customer loyalty and lower network churn for the operator.

The web is an integrated part of the competition environment allowing the operator to use the web as a marketing vehicle as competitions are promoted and then run.

In addition, cross promotional activities can be run by attaching "advertisements" to puzzles as they are delivered (by the creature) to the competitor. The

Substitute Sheet ⁽Rule 26) RO/ATJ competitor may also be given the option of responding to advertisements (eg. go onto a mailing list) . In this way, it may be free for a consumer to participate in a competition if the advertising is used as a revenue generation activity for the operator.

Through the development of strongly branded "creatures", the operator can leverage the marketing appeal of these creatures through related activity (eg. games, character branded products, advertising etc.).

With the system of this embodiment:

• Advertisements and promotions are more effective as they are delivered to the mobile user directly on their phone, users can respond to them easily and they are delivered in the context of a fun and rewarding environment (a competition via their creature) .

• It provides an environment where direct and one-to-one marketing techniques can be applied much more effectively.

The system may also appeal to subscribers who register for competitions as they will:

• Have fun with their mobile terminal in new, innovative ways • Be rewarded for using their mobile terminal by winning prizes

• Be able to socialise with other competitors by: sending their creature into the competition space to meet other creatures of a specific type (eg. common interests) and exchange attached messages or exchanging mobile numbers (optionally enabled by a competitor to protect their privacy)

Substitute Sheet ⁽Rule 26) RO/AU • Feel comfortable that their creature will interact with them in a way that suits their personal preferences and current mood.

The system of this embodiment is designed from the outset to be as user friendly as possible for the mobile subscriber. The level of user friendliness is obviously constrained by the mobile terminal's screen size, functional capabilities and user input options. From their first interaction with the service, the. subscriber need only reply to a simple broadcast SMS message to register for a competition. The process for selecting a creature is again very straightforward requiring minimal input . The subscriber then interacts with their creature through their mobile terminal using a simple and intuitive' menu system, predefined option lists and minimal field input. The user friendliness is raised to a new level by providing the subscriber with the option of telling their creature what sort of mood they're in. The creature is therefore more "user aware" and can adjust its interaction style accordingly eg. using less/more aggressive approaches to informing the subscriber of special offers, increasing/reducing the frequency of advertisements, screening/passing messages from particular types of creatures .

Technical implementation of the system in accordance with the present embodiment is designed to promote the "mobile" code aspect of Java (eg. through the mobility of the creature in the competition environment) and the value of this aspect when Java is available on a mobile terminal via a SIM Card. It is also designed to promote the evolutionary nature (eg. via progressively evolving

Substitute Sheet ⁽Rule 26) RO/AU creatures) that Java applications can take in a deployed, large-scaled networked environment.

Referring to figure 1, the system in accordance with this embodiment of the present invention comprises three key components. Namely, a home portal server 1, a distributor 2 and the creature Applet which is resident on the user's Java SIM enabled mobile phone.

The Distributor 2 resides at the GSM operator's premises 5 and is responsible for connecting the mobile network 6 (via an OTA server 7) to the home server 1. The connection (optionally VPN-based) from the Distributor 2 to the home server 1 carries HTTP traffic back and forth. The home server 1 is responsible for hosting the competitions and also the operator's portal where competitors can get access to the competition web pages .

In essence, a Creature is routed up and down the line from the consumer's mobile phone 4, to the home server 1, via the Distributor.2.

The home system 1 is a Java server-based web service that hosts multiple competitions for one or more network service providers . They are able to run/manage their competitions from their web browser by accessing the Site Administration Console 8. The home system 1 also allows network service providers to store and manage the promotional content developed with and/or provided by their advertising, promotion and direct marketing partners .

The home system 1 provides secure HTTP connections to multiple Distributors over which traffic (such as serialised creatures and advertisements) flows back and forth. It also provides a http connection for general web traffic, primarily for mobile subscriber access to their

Substitute Sheet ⁽Rule 26) RO/AU network service provider's web portal (which also resides on home system 1) .

The Distributor 2 is a Java server component that sits on a server at the operator's premises connecting the consumer, via the operator, to the competition's hosted at the home system 1. It does this by connection to the OTA server, converting and then forwarding objects (such as serialised Creatures) back and forth between the consumer's mobile phone - 4 and the relevant competition on the home server 1. The Distributor 2, is managed from home server 4 via the Distributor Administration Console.

Due to the fact that there are objects roaming the network (mobile phone to Distributor to home server and visa versa) , a synchronous architecture has been developed. This architecture is also well suited to an SMS bearer. Two mechanisms exist at the heart of the architecture :

• HTTP based delivery of serialised objects between Distributor at a network operator and home system • A queue-based system in the distributor to enable object

(Creatures) to be collected and dispatched (synced) as required to and from the mobile.

Because a queue-based system is employed, load balancing can be easily effected when distributors are deployed. Multiple OTA services can be run to process objects held in the Object Dispatcher, each attached to different OTA Servers (SMSCs) . Given that the Distributor acts as gateway between the consumer and the home server, it can interface with the network service provider's subscriber management and billing functions.

The Creature Applet 3 is a Java SIM Toolkit compliant Java Card applet that resides on the consumer's Java SIM

Substitute Sheet ⁽Rule 26) RO/AU enabled mobile phone. It works by sending and receiving requests/responses packaged up as SMSPP commands to and from the OTA service. Since most of the intelligence is built into the Creatures, Advertisements, Puzzles and other objects that move backwards and forwards between the Distributor and the home server, the Creatures Applet is simple in its design and quite small in size.

All objects that are distributed between the mobile, distributor and home are transportable, syncable objects. This means that they have the ability to move from the distributor to home and visa versa, and in the course of moving over the network, collect information that needs to be provided to the applet on the phone. When an object (eg. a Creature) collects information, each element of information is recorded as a transaction. Once the object has finished collecting it is queued in the distributor's object dispatcher. An OTA service then polls the distributor's object dispatcher looking for objects to dispatch back to the mobile. When one is found, the OTA service tells the object to "sync" itself with the applet on the mobile. The object then goes through its transaction queue and sends each transaction to the applet to be processed.

Advertisements can be broadcast from home to all mobiles that have the Creatures Applet on them. Advertisements are broadcast as follows: When a distributor starts, it registers with home When an advertisement is to be broadcast, an Advertisement Object is dispatched to all registered distributors A distributor then iterates through each OTA Service running on it, instructing each service to put the object (advertisement) in a broadcast queue

Substitute Sheet ⁽Rule 26) RO/AU When an OTA Service is "polling" for new objects to dispatch (sync) to the mobile, it periodically looks in the broadcast queue to see if there are nay objects to be dispatched (synced) to all mobiles. If there are, then the OTA service will iterate through all mobile numbers for which it is responsible and ask the broadcast object to sync with that number

In this way, 1 advertisement can be sent from home to a single distributor and then that advertisement can be broadcast from the distributor to all mobiles connected to it.

The compactness of applets that will reside on a Java SIM is a very important design and implementation consideration given the small footprint and dynamic nature of applets that will reside on the SIM at any one time. We were able to keep the size of the Creatures Applet small by:

• Ensuring most of the required Creature and attachment

(eg. puzzles, advertisements) intelligence relating to how they worked, how they were collected and dispatched resides on the Distributor and/or the home portal server and not in the applet

• Storing most of the required data regarding a Creature on the home server.

In fact the Creature Applet is no more than a presentation of what happens in the network and holds very little information. The approach also provides more flexibility as none of the Creature (or attachment) behaviour is hard coded into the Creature Applet. This removes the need for costly, time consuming and bothersome downloads of new applet/class versions to the mobile phone to support new creature/attachment capabilities.

Substitute Sheet ⁽Rule 26) RO/AU While security is not of paramount importance to our application (primarily a simple broadcast environment with mobile users sending and receiving messages) , security is still quite a prominent feature of the system service from the home server to the Dispatcher to the consumer's mobile phone and back again.

First and foremost, the Distributor resides at the operator's secured premises enabling the Distributor to safely connect and communicate with the operator's OTA server. The operator has the option of a VPN connection to the location where the competition is hosted and the related competition content resides. It is also possible for us to encrypt the objects that are shuttled back and forth hence adding another layer of security over an already secure connection.

Security in the applet loading process is achieved by the encryption and signing of the applet code (using the Triple DES algorithm in the case of the Bull SIM Rock'n Lab/Rock'n Tree card) prior to having it loaded onto the consumer's mobile phone.

Security is also provided, as discussed above, by the security means ensuring that there is little chance of another person being able to use the intelligent agent. Although in the above architecture the majority of the "intelligence" of the Agent does not reside on the phone, it will be appreciated as mobile technology progresses, it may well be possible to provide a more distributed system having far more intelligence resident on the user's terminal. The particular embodiment described but relates to a system from filing an intelligent agent particularly for use with mobile communication devices . This preferably include mobile telephones or small computing devices such

Substitute Sheet ⁽Rule 26) RO/AU as palm-top computers which have a facility for communicating via a mobile network.

It will be appreciated, however, that the system of the present invention may be implemented for stationary devices such as PCs utilising land-line communications to networks .

In the embodiment described above, the main task for the intelligent agent is to enter into and take part in competitions . As discussed in the preamble of the application, there are many other tasks in which the system of the present invention can carry out, however, the system is not limited to competitions.

As discussed above, the intelligent agent can carry out many tasks apart from taking part in competitions . For example, the intelligent may interact with systems installed in retail locations. For example, an intelligent agent user is walking down the street and passes a coffee shop. There is a particular coffee type that the user likes and the user wonders if the shop has it. The intelligent agent understands that the user enjoys this particular type of coffee because he has been told this by the user previously. The intelligent agent goes from the mobile telephone (using low power RF network, such as BLUETOOTH™, and a micro-server in the coffee store) to the coffee shop and enquires about the coffee. When the intelligent agent returns to the mobile, he tells the user that the shop has the desired brand of coffee, and, in addition, he has a voucher for the user that says that "if you buy a coffee today, you will get a free muffin".

The intelligent agent is therefore preferably able to move over such close proximity networks (preferably it may move over many different types of networks) , as discussed

Substitute Sheet ⁽Rule 26) RO/AU above, interacting with other systems, such as servers in retail locations.

A further embodiment of the present invention will now be described with reference to figures 6 through 18. This embodiment is a modified embodiment in which the functionality of the home portal server and distributor (figure 1 of the above embodiment) are combined into a single "agent gateway" under control of the network operator. Further, in this embodiment, the system can operate with a number of different "clients" having different facilities on their mobile devices e.g. SMS, WAP, etc.

The heart of the system of this embodiment resides in the server technology, called "Agent Gateway" . The client technology (the Agent Containers) exists to allow agents to "appear" visually on a handset.

The agents ("creatures") are the best friend of the wireless consumer. They live on and move around the mobile network performing tasks on behalf of their owner, the consumer.

Creatures have a personality and in the case of a Java enabled phone, a visual appearance.

The user uses their mobile phone to communicate with the creature via the agent gateway. In some cases, it is possible for creatures to live on the consumer's mobile device. This is possible if the mobile device is Java Card SIM or J2ME enabled. For a creature to reside on a mobile device, the device must support the system agent container. In the case of a Java Card SIM mobile, the agent container is an operator certified Java Card SIM Applet. In the case of J2ME, the container is an operator certified midlet that is permanently resident on the mobile device. The agent

Substitute Sheet ⁽Rule 26) RO/AU container may be installed by the operator "over the air" when the consumer subscribes to the operator's agent service.

In the case of an SMS, WAP, HTML or email deployment of the agent gateway, the consumer's creature lives completely within the agent gateway.

However, even in the case of the Java Card SIM and J2ME forms, the vast majority of the agent functionality resides at the gateway. The Java Card SIM and J2ME agent containers are mechanisms to allow the agent to be presented as "living" on the mobile device. Accordingly, in the first instance, the agent container should be seen as an "agent browser" that has the capability to graphically display the state of a creature to the consumer.

Figure 6 illustrates screen representations driven by the Java Card SIM and J2ME agent containers (reference numerals 100 and 101 respectively) .

Consumers "talk" to their agent. Currently this is via text entry. In the future, consumers may talk to their agent using voice.

In the case of an SMS deployment, consumers talk to their agent by sending SMS messages to a phone number that represents their agent . The agent responds by sending SMS messages back to the consumer.

There are two types in this embodiment - personal and transient. The personal agent is the consumer's "best friend" . Only one exists per mobile and it only expires if the consumer leaves the operator network. Alternatively, transient agents have a short life span and are collected by the consumer using their agent container. Transient agents can be broadcast over the network to using the Talking Point Agent Broadcaster. As transient

Substitute Sheet ⁽Rule 26) RO/AU agents are held in the agent container, and therefore, are only possible in the Java Card SIM and J2ME deployment formats .

A transient agent in one example is a discount voucher, which can broadcast over the wireless network to the mobile device. The voucher appears in the agent container as a "branded" voucher (e.g. one of the characters that MCDONALDS™ is promoting at the time i.e. A toy Story character if they are promoting Toy Story Happy Meals) . The consumer can redeem the voucher over a micro network e.g. a BLUETOOTH connection at a store using their mobile and the agent container. The transaction is kept secure and is managed using the facilities of the container and the agent gateway. Agent implementation is via the agent gateway which is connected to the operator network and located at the operator's premises.

The agent gateway delivers the functionality necessary for an operator to create agent-based services and deliver those services over its network using

"character" based agents.

Figure 1 illustrates the key components of the agent gateway 103, client connectors 104, core services 105, content actions 106. When an operator deploys the system they determine the ways in which they wan their consumers to be able to "talk" to their agents. The system supports a number of "conversation" options. Each deployment option is termed a "connector" .as it facilitates a connection between the consumer and their personal agent. The default connectors provided are :

Short Message Service (SMS) consumers talk to their agent by sending/receiving SMS messages .

Substitute Sheet ⁽Rule 26) RO/AU Java Card SIM - the creature appears in the phone menu system. Consumers talk to their creature by selecting the actions from the menu, conversing with the agent in the same way as they converse with a friend over SMS.

Java 2 Micro Edition MIDP - the creature appears on the phone in a fully graphical manner. They are animated and converse with the consumer in a textual manner. They may converse using direct speech entry and generation. WAP browser - consumers access a WAP page to converse with their creature. They converse via text entry.

Web browser - consumers access a HTML page to converse with their creature. They converse via text entry. In the future, an applet version of the creature will be supported to allow the consumer to interact with their creature in the same way as they would with a J2ME MIDP creature.

Internet based email - consumers converse with their creature by sending/receiving emails . The creature can also initiate a conversation with their user by sending the user an email. iMode/iAppli - consumers converse with their creature on an iMode and/or iMode + J2ME enabled phone (planned) .

Desktop - consumers place a version of their creature on their desktop and converse with it as an interactive application (planned) .

The core services gateway 103 provide an environment where the agents live and interact (MorphenCentral) , allow the agent environment to be managed (administration) and ensure that data cached on J2ME MIDP devices is seamlessly backed up and restored on demand ensuring that the data is not lost when the handset is lost.

Substitute Sheet ⁽Rule 26) RO/AU However, without contents actions 106, the agent environment would not provide a compelling experience for the consumer. The connectors and core services do allow the consumer to talk with their agent but the agent could not perform more meaningful tasks if it didn't have access to content actions .

Content actions are the mechanism by which an operator integrates specific "content", leveraging the existing and developing relationships for their wireless portal.

For example, one content action 106 may be ticket master 107. The agent can utilise the ticket master 107 content action in order to purchase tickets from a designated venue. For example, if a user wishes to purchase tickets from a particular cinema, ticket master would be employed together with an application program interface (API) at the theatre box office in order to enable the agent to obtain the tickets. Any number of content actions may be included and some examples are shown in figure 7. For example, with a "phone book" 108 can provide a list of phone numbers which the agent can fetch when queried by the user asking for a particular name (i.e. the agent fetches the right phone number) .

If the user is using SMS to talk with their creature, the creature does not have a visual appearance - it is perceived by the user to be living on the wireless network. Java Card SIM helps create the appearance that the creature lives on the wireless device by supporting access tot he creature through the phone menu structure, but it is not until J2ME MIDP devices are in play that the user will believe that the creature is a living creature on the device.

Substitute Sheet ⁽Rule 26) RO/AU Ultimately, the best way to interact with a creature is using voice commands and response through the wireless handset. This will be possible using the evolving voice recognition capabilities of the handsets, and server side technology such as Motorola's VOXML gateway.

In one preferred embodiment, the system is implemented in Java. The server platform can be run in any environment supports the Java 2 Runtime Environment (J2RE) , versions 1.2.2. or later. The client technology requires either:

A Java Card SIM enabled handset, or a

Java 2 Micro-Edition (J2ME) Micro Information Device

Profile (MIDP) enabled wireless appliance.

To support the various connectors, a number of 3^rd party technologies are packaged with the distribution:

SMS - a portable Short Message Server is provided to support SMS connectivity over the air. To run the portable SMSC, a Nokia phone card and a BTI CardAPTOR⁸ is required. Java Card SIM - to support over the air connectivity with a Java Card SIM enabled device, a Java Card SIM connector for the AU Systems OTA server is provided. Due to the constraints bf the underlying AU Systems interface, this connector may only be run on Windows NT or Solaris . Internet Email - to support connectivity with an

Internet email server a POP email connector is provided using the Java Mail API.

Figure 8 presents the technical architecture for the system of this embodiment. The system is build using an internal Java Wireless Application Server, called Jazz. This application server provides the basic building blocks to realise the "service" based architecture for the agent environment.

Substitute Sheet ⁽Rule 26) RO/AU There are two sides to the System product suite: Wireless Client Technology and Agent Service Platform.

The client technology is the agent container that can be installed on J2ME MIDP and Java Card SIM clients . The service platform is an Agent Gateway that uses • a natural language engine NLE, an agent broadcaster (which can send transient agents to the agent containers) , a set of agent tools to help construct agent services and a set of pre-packaged agent services that help an operator to get up and running quickly.

The system has been developed using an internal Java wireless application server. This application server is called "Jazz". It's architecture is illustrated in Figure 9. Features of Jazz include:

^•A service based distributed application architecture; An inbuilt lightweight HTTP server;

Support for MIDP client/server application deployment (a lightweight windowing framework, a persistence framework support on-demand caching/backup of RMS MIDP data and a high level framework supporting HTTP based client connections from MIDP devices) ;

A content framework designed to support delivery of content of varying types (text, HTML, WML) ; A set of general utility classes (e.g. to support loading and saving of configuration data etc.), and A set of general widget classes to simplify GUI development (e.g. an Outlook style bar).

Jazz promotes the use of a "distributed service- based" architecture. This means that server side applications are developed as "services" that are run in a Jazz Server. Multiple serves may be run across processors, each executing different services that

Substitute Sheet ⁽Rule 26) RO/AU inherent have the ability to communicate between each other (using RMI) .

To illustrate how a wireless server application is constructed using Jazz, let's walk through an example. Consider the following:

We are building a simple Stock Market client/server application. The server side application will support wireless web (HTML and WAP) browsers and a standalone MIDP application (on a wireless J2ME MIDP device) . For the sake of simplicity, we will illustrate how a "stock quote" function may be implemented using Jazz (e.g. get current price for Nokia (NOK) ) .

The first step to creating this wireless application is to design how the service will work. The key design points for our example are:

Both the browser and the MIDP applications can use exactly the same interface on the service to get a quote on a stock. That interface could be: getQuote (String stockcode) . In the case of a WAP client, this function should return a WML page that displays the stock code and the current price. For a web browser, it should return a HTML page, while a MIDP application will just require a text string with the price which it will then display using the graphical components of Java (e.g. as a label in a panel) . To help the service understand the type of content it is to return, an extra parameter will be passed to the getQuote method, one that will specify the content type to return. So the final interface could be: getQuote (String contentType, String stockcode) .

To support the concept of different content types being returned from a Jazz service, Jazz supports the notion of a content set, which is a set of classes that

Substitute Sheet ⁽Rule 26) RO/AU support streaming various content types back to a client application.

Implementing a Jazz service is very similar to implementing an RMI service the only exception is the classes that are used. To implement a server side service to support the Stock Market application, the following steps are taken:

Implement a service interface;

Implement the service itself. To implement the service, the following code will be placed in a file called StockMarketServicelnterface . Java ; import com. cardventures . jazz . content . *; public interface StockMarketServicelnterface implements com. cardventures .jazz . service . RemoteServicelnter face { public TextStream getQuote (String contentType, String stockCode) throws RemoteExeption;

}

The points to note in this interface definition are our getQuote method is defined to return a TextStream, which is the base content type for all content types (WML,

HTML, HTTP etc.). As is the case in RMI, all public methods in a Jazz service throw a RemoteException that will need to be caught by the application calling the Jazz service . To implement this interface, we will define StockMarketService. Java as follows: import com. cardventures . jazz . content . *; public class StockMarketService extends com . cardventures . jazz . service . RemoteService implements StockMarketServicelnterface { public StockMarketService () {

Super ( ) ;

SetName ( "Stock Market Example") ;

Substitute Sheet ⁽Rule 26) RO/AU SetVersion ("2.0 ") ; SetBuild ( "1 ") ;

; public voice startService () ; throws RemoteException { super. startService ( ) ; } public void stopService ( ) throws RemoteExceptio { super. stopService ( ) ;

} public TextStream getQuote (String contentType, String stockCode) throws RemoteException { try {

TextStream content -

ContentFactory . createStream (contentType) ; content , add ( "NOK 41 .25 ") ; // static example

} catch (ContentCreationExcept ion e) { trace *e . getMessage ( ) ) ;

When implementing a Jazz service, the following standard methods must be implemented:

Constructor: always call super () as .the first thing in the constructor. After that, initialise your service, and it is recommended that part of this initialisation process include setting the service name, version number and build identifier using setName(), setVersion() and setBuild() respectively. startService: (optional) - startService is always called when the Jazz Server starts the service. If you override the default, always call the standard implementation first. Place any service initialisation statement in here, especially if you need access to the

Substitute Sheet ⁽Rule 26) RO/AU service configuration data (via getConfigO) as it will be available at this time. stopService: (optional) - stopService is always called when the Jazz Server stops _.the service. If you override the default, always call the standard implementation first before executing any local cleanup code.

Within the getQuote method, we create an instance of the content stream that we require using the ContentFactory class.

To add information to a content stream, the add method is used on a content class . This results in the new information being appended to the data currently held by that content class. The respective content classes will add the required headers to the content data to ensure that the content is safely transmitted over the wire to the client application.

The Jazz server will first construct an instance of the service, then it will force the service configuration data to be loaded, before registering the service with the RMI registry. Once this process is complete, it will then call startService ( ) to allow the localised service initialisation process to be completed. When a service is stopped, stopService ( ) is called first by the Jazz server before deregistering the service with the RMI Registry.

Once the service has been implemented, it needs to be compiled before it can be run in the Jazz server. To compile a Jazz service, RMIC needs to be used to create the RMI stubs and skeletons for the service. Remember, all Jazz services are implemented as RMI services.

Substitute Sheet ⁽Rule 26) RO/AU To compile a Jazz service using RMIC, use the following commands : javac -d $ (OUTPUT)

-classpath "$ (OUTPUT) : $ (JAZZ) : . " * . Java rmic -d $ (ROOTDIR) classes

-classpath "$ (OUTPUT) : $ (JAZZ) : . " -sourcepath $ (PROJECT) StockMarke tServi ce Where:

$ (OUTPUT) is set to the directory where the compiled classes are to be placed;

$ (SOURCE)- is the directory where the source files are located; $(JAZZ) is the location of the Jazz distribution archive (jazz. jar).

Building a J2ME MIDP Application using Jazz

Jazz includes a number of packages designed specifically to support seamless applications development on a J2ME MIDP device. These packages include a lightweight windowing framework mirroring AWT and a simple frame work to support on-demand back-up/retrieval of RMS cached data (the data is backed up and retrieved from the a server side service) .

All wireless J2ME MIDP devices face a similar problem - when the device is lost, data stored locally by a MIDP application within it's Record Management System (RMS) will be lost, unless it is backed up onto the network in some way.

The Jazz On-Demand Record Management System API provides a seamless mechanism to backup all local data to a server accessible via the wireless network.

Substitute Sheet ⁽Rule 26) RO/AU When designing the API, the following requirements are taken into account :

The process of accessing data that is backed up must be seamless to a MIDP application in that it must be just as easy to get a piece of data from the standard MIDP RMS as it is to get it from the On-Demand RMS;

A MIDP Application must be able to specify if a piece of data to be held in the RMS is to be backed-up or not;

A MIDP Application must be capable of getting a piece of data directly from the back-up store on the network, bypassing the local store, but the API must be the same;

If the value of a data item stored in the back-up RMS changes and is specified to be up-to-date with any copy cached on the handset, the change is to be propagated back to the handset.

Figure 10 illustrates the On-Demand RMS.

Jazz provides an enhanced RMS class on the handset that extends the standard RMS to provide connectivity to a network bound, backup RMS server. A MIDP application requests a data item from this extended RMS. IF the data item is available locally because it is being held in the local RMS. IF the data item is available locally because it is being held in the local RMS, it is returned immediately. If it is not available, it is retrieved from the data warehouse on the network and cached before being returned. The application can specify that the data item should not to be cached if retrieved from the data warehouse. Additionally, when a data item is cached, the data warehouse can be told to keep the data item up to date if the value changes in the data warehouse while it is cached.

The standard MIDP RMS has a very restricted capacity on the handset. This means that data will be moved in and

Substitute Sheet ⁽Rule 26) RO/AU out of the RMS as the capacity is reached. The On-Demand RMS uses a FIFO (First In, First Out) strategy to determine which data items should be removed from the cache to make room for more recently requested data items .

The Agent Gateway

The agent gateway is the heart of the system service environment . It provides a home for talking point creatures, allowing them to live and move. It also provides the intelligence for creatures in the form of a natural language engine and integrated agent content . The gateway is built using the Jazz Application Server, and as such, adopts the service model that it promotes . As illustrated by figure 11, the gateway connects users to their creatures .

Users send natural language requests to their creatures . If the user has a wireless device supporting ■ J2ME MIDP or Java Card SIM, it will appear to the user that their creature lives on the device, but in reality, the creature resides in the gateway. The container simply provides the perception that the creature is on the phone while in the background the container formats and passes instructions to the creature living in the gateway. When a creature performs an action it completes a transaction.

The gateway supports three types of creature transaction - immediate, delayed and uninitiated.

An immediate transaction is one that is initiated by the user (by instructing their creature to perform an activity) that results in the creature completing the request before returning the response immediately - for example, "what price is NOK trading at?".

Substitute Sheet ⁽Rule 26) RO/AU Alternatively, a delayed transaction is one where an instruction is issued triggering the creature to think a while before it can reply - for example, "tell me when NOK trades above 50". An uninitiated transaction does not involve the user instructing the agent. The creature performs the action itself and updates the user accordingly - for example the creature asking the user "How are you feeling today?".

Agent Containers

While it is possible for a wireless client to communicate with a creature without the aid of any additional software on the client, the use of an agent container on the client has the capability to enhance the experience for the user.

Additionally the use of an agent container introduces the user to the notion that the agent actually lives on the wireless appliance; .

In the case of the Java container, it allows the agent to take on a dynamic visual form.

Over time, the agent container can be extended into a secure container that has the capability to store redeemable vouchers (called Transient Agents) and other "collectible" items. Two types of agent container are supported - Java Card SIM and Java 2 Micro-Edition Mobile Information Device Profile (J2ME MIDP) .

An agent container can be viewed as a simple browser for an agent - it provides the ability for an agent to display itself on the handset.

The container to gateway communication pathway is illustrated in figure 2.

Substitute Sheet ⁽Rule 26) RO/AU Regardless of how complex that display facility may be, the connection between the agent container and the gateway is a simple one. All communication between the agent container and the agent gateway is centred on the transfer of "natural language requests" (e.g. how are you today?) so it is a primary responsibility of an agent container to get the conversation from a user and transfer it to the gateway for processing by the creature (and NLI) that runs there .

Java Card SIM Container

The Java Card SIM Agent Container is a Java Card SIM Toolkit application.

To deploy the application, the Java Card SIM container requires a Java Card SIM Applet that is installed onto a Java Card SIM in the wireless handset, and a Java Card SIM Connector that supports a line of communication between the gateway and the Applet on the SIM in the handset . The Java Card SIM container is compliant with the

Java Card SIM standard, and the SIM application toolkit standards (complying to GSM release 11.14, 11.11; 3.40 and 3.48) .

From an architectural perspective, figure 13 illustrates the runtime environment components on a Java Card SIM handset.

The components of this environment include and operating system compliant to ETSI 11.11;

A Java Virtual Machine compliant to the Java Card 2.1 specification;

The Java Card API to provide support for the implementation and runtime execution of the Java Card compliant applets;

Substitute Sheet ⁽Rule 26) RO/AU An API to support the implementation of SIM Toolkit oriented Java Card Applets . This API is compliant to the ETSI 03.19 standard, and

The Java Card SIM applets. In this case, the agent container.

When the Java Card SIM agent container is installed, it appears as an integrated element in the wireless applicant's menu system. A user accesses their Java Card SIM creature by navigating the menu system, selecting "My creature" and then the desired function. -An example menu is illustrated in Figure 14.

There are several advantages to the Java Card SIM creature over a standard SMS based creature. The Java Card SIM creature : appears to live on the phone because it is an integrated part of the phone menu system. Menu driven operation enhances the user experience by improving useability, principally speed of operation via menu driven operations that short-cut the laborious process of SMS style text entry; has access to information stored locally on the wireless application - principally contact and calendar information, along with ring tones. This allows the creature to behave in a more intelligent manner, appearing to "know" details about the user. It also reinforces the view that the creature "lives" on the phone.

The Java Card SIM applet is designed to enhance the experience for the user as they "converse" with their creature. To achieve this, the container provides the following functionality:

Talk: Provides a mechanism for the user to "converse" with their creature. This mechanism operates in an identical manner to sending/receiving short messages on a mobile . History: To provide quick access to the last five conversation points, a history is maintained. Conversations maintained in history may be accessed and

Substitute Sheet ⁽Rule 26) RO/AU sent to the creature, reducing the amount of text entry required to converse with the agent.

Favourites: In a similar vein to the history option, certain types of conversations will occur frequently between the user and their creature. This option records the "top 5" conversation points, allowing easy access to the text so that it can be quickly sent to the creature for processing.

Socialise: creatures can meet other creatures and exchange messages, and they can help organise events for their owner by sending invitations (by SMS) and processing replies (SMS messages) .

Play: creatures are fun - they can play games and enter competitions . This function reinforces that view, allowing the user to increase the value of their creature by accumulating loyalty points. Loyalty points may also be accumulated in the course of a conversation using the "talk" function.

The Java Card SIM Agent Container is a reasonably simple application. It is primarily responsible for providing a menu system, some input functions and sending/receiving messages.

Figure 15 presents the classes that make up the container. Chatterbox is the main class, derived from the sim. toolkit . ToolkitApplet .

Implementing a Function

Each function provided by the Agent Container is an implementation of the Function class. The function class provides the basic mechanisms needed for a function to operate :

Executing a function by sending and processing short messages sent to and from the gateway; Holding a menu name and sub-menus;

Processing a menu select request;

Displaying text;

Substitute Sheet ⁽Rule 26) RO/AU Processing text input;

Obtaining the location and time identifiers .

Location and Time Sensitivity The Function class provides methods to obtain the location and time identifiers and stamp those identifiers in a conversation instruction when it is sent to the Agent Gateway. This allows the creature to identify the location of the user and the time that the conversation is taking place.

The methods provided by the Function class are: getLocation ( ) - obtains identifier from the wireless appliance. At this time, it is the cell ID, which is mapped to a location by the gateway; and getTime ( ) - obtains the date/time from the wireless device.

When an instruction is processed and dispatched by a Function to the gateway, the location and time information is always prepended to the instruction. This location and time information can be used when executing content actions. For example, the user could ask for the location of the closest movie theatre and, utilising the geographical information provided, ? could provide that location. When a creature processes and instruction on the gateway, it may result in a change to the level of loyalty points that a creature may have. The <loyalty value="change"> tag in MAIML supports this type of operation. As the Java Card SIM agent container holds the loyalty total, this total needs to be updated if a change occurs . When an instruction is dispatched from the Gateway to the Agent Container, the instruction takes the form: [FUNCTION ID] [DATE] where FUNCTION ID is the identifier for the function that this response is applicable to, while DATA is the data to

Substitute Sheet ⁽Rule 26) RO/AU apply to the function.

The first element of the DATA block is always a [LOYALTY COUNTER] which is processed by the container to ensure that the loyalty total is up to date.

J2ME MIDP Container

The Java 2 Micro-Edition (J2ME) Micro Information Device Profile (MIDP) Agent Container is a Java application that runs on a wireless handset. To deploy the application, the container requires .a handset that supports the J2ME Java Virtual Machine and MIDP classes.

Figure 16 presents the software for a J2ME MIDP environment . Within this diagram, the Agent Container is considered to be an OEM Application. The Agent Container uses a number of J2ME MIDP APIs provided by the Jazz Wireless Application Server. These APIs are considered to be OEM Specific APIs and include: a lightweight windowing system based on AWT; and an on-demand record management system that provides support for seamless backup and retrieval of data to and from the Agent Gateway.

The runtime environment for a MIDP Agent Container is web-like in that communication between the container and the Agent Gateway is based on the use of HTTP.

Figure 17 illustrates the runtime environment. The Agent Container is both a client and a server application:

As a client , the container sends messages from the container to the gateway. The most common message is a Conversation. Messages that are a description of a conversation between the user and a creature utilise the Conversation Protocol .

As a server, it accepts messages from the gateway. Messages can be: visi ting agents that are sent to the container to be presented to the user;

Substitute Sheet ⁽Rule 26) RO/AU collectibles that are broadcast to the container for redemption by the user.

The J2ME MIDP Agent Container is really a simple browser that allows an agent to be visually presented (rendered) on a small wireless, graphical (and most likely colour) display.

Figure 18 illustrates the container running on the Sun J2ME MIDP Simulator:

The container has 5 basic elements: The Agent View

The Talking Bubble

Supporting Agent Functions

The Waiting Room

The Secure Inventory The Agent View is the main view in the browser. It is the component where the creature is animated in accordance.

The Talking Bubble is attached to the Agent View. When the creature talks with their user and visa versa, the text of the conversation is displayed in this bubble.

The attributes of the creature can be changed using the Agent Functions .

When other agents visit a user, they arrive in the Wai ting Room . The user can view the waiting room and see select to converse with a visiting agent waiting there.

When a user activates a visiting agent, it appears in the Agent View and the user can converse with that agent using the Talking Bubble.

The concept of a Secure Agent Container adds a new dimension to the Agent Services that an operator can offer their subscribers .

A Secure Agent Container is one in which transient agents can be "securely" stored and processed (eg as a payment given that the transient agent is a voucher of some form) .

The Secure Inventory provides the functionality required to realise the concept of the Secure Agent

Substitute Sheet ⁽Rule 26) RO/AU Container. The Secure Inventory: ensures that a copy of all transient agents being held on the wireless device are backed up to the Agent Gateway. This alleviates the issue of a consumer "losing their collectives" when they lose their handset. When a new handset is obtained and the agent container reloaded, the state of the container (and the collectibles) is retrieved from the gateway; can utilise any network connection type from the handset to a connection point to redeem collectible, or transfer them from one container to another. The different connection types include: the primary wireless connection protocol - GPRS/3G etc; low power, localised network connection types -

BLUETOOTH, IR etc; can retrieve and store collectibles broadcast from an Agent Broadcaster to the handset via the Agent Gateway.

The MIDP Agent Container provides location and time information to the Gateway in the same manner as the Java

Card SIM Agent Container .

Loyalty Points

Unlike the Java Card SIM container, a local copy of the Loyalty Point total for a user and their creature is not maintained in the MIDP Agent Container. The total is always obtained from the Agent Gateway. This is possible because the underlying transport for the connectivity between the MIDP container and the gateway is the more time responsive HTTP, not SMS.

The Agent Container makes Loyalty Points available to the user as Collectibles within the Secure Inventory. This means that the user/creature can redeem the points at any stage using the facilities of the Secure Container.

The Agent Broadcaster

The Agent Broadcaster and Secure Agent Container.

Substitute Sheet ⁽Rule 26) RO/AU Together, these products promote the development of secure, personal transactions using Transient Agents.

The Agent Broadcaster is a server technology that can be licensed to content providers to allow them to broadcast transient agents over the operator network via the Agent Gateway to J2ME enabled mobile devices (running the J2ME Secure Agent Container) . For example, Ticket Master, McDonalds, Retail Stores etc may use an Agent Broadcaster to broadcast promotions or redeemable vouchers as "transient" agents to consumers.

Using the Secure Agent Container, consumers can then redeem/manipulate the received vouchers using their mobile device, and possibly a Bluetooth connection between the mobile device and a redemption point (eg point of sale terminal) .

This technology proactively demonstrates how Operators can position themselves a keepers of "secure payment transactions" over the wireless network through the deployment of an Agent Container to their consumers . To realise this product concept, the following technologies are required:

J2ME enabled mobile phones; and

BLUETOOTH enabled mobile phones (for localised redemption of vouchers) . Java Card SIM for cryptography operations within the

J2ME Secure Agent Container, and/or STIP to support the notion of a secure payment mechanism on a J2ME device. (Talking Point is exploring the possibility of working together with Cardsoft to develop a Secure Agent Container that will run on their J2ME STIP implementation) .

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are,

Substitute Sheet ⁽Rule 26) RO/AU therefore, to be considered in all respects as illustrative and not restrictive:

Substitute Sheet ⁽Rule 26) RO/AU

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A system for providing an intelligent agent which is arranged to carry out tasks in response to instructions from a user, the tasks being actioned in a network environment, the system comprising agent interface means arranged to provide an agent interface at a user terminal for interaction with a user, and agent implementation means for implementing tasks instructed to the agent interface by the user, the user terminal comprising a mobile communications device utilising a mobile communications network for communications .

2. A system in accordance with claim 1, further comprising attribute implementation means arranged to implement the provision of attributes to the intelligent agent, wherein the attributes are arranged to determine the functionality of the intelligent agent in carrying out tasks.

3. A system in accordance with claim 1 or claim 2, the system including user mood determination means arranged to determine the mood of the user and effect the operation of the intelligent agent accordingly.

4. A system for providing an intelligent agent which is arranged to carry out tasks in response to instructions from a user, the tasks being actioned in a network environment, the system comprising agent interface means arranged to provide an agent interface at a user terminal for interaction with the

Substitute Sheet ⁽Rule 26) RO/AU user, and agent implementation means for implementing tasks instructed to the agent interface by the user.

5. A system in accordance with claim 4, wherein the user terminal is a mobile communications device .

6. A system in accordance with claim 5 wherein the mobile communications device is a small computing device .

7. A system in accordance with claim 6, wherein the small computing device is a mobile telephone.

8. A system in accordance with any one of claims 4 to 7 , wherein network communications with the user terminal are by wireless.

9 . A system in accordance with claim 8, wherein the network communications with the user terminal are by way of a mobile telephone network.

10. A system in accordance with any one of claims 4 to 9 , wherein security means are provided oh the user terminal, to prevent unauthorised persons from utilising the intelligent agent.

11. A system in accordance with any one of claims 4 to 10, wherein the agent implementations means enables tasks such as taking part in competitions or obtaining information requested by a user, or ordering tickets to entertainment venues, or electronic commerce transactions on behalf of users .

Substitute Sheet ⁽Rule 26) RO/AU

12. A system in accordance with any one 'of claims 4 to

11, wherein the agent implementation means enables a task to be carried out over a close proximity network interacting with a system located in, for example, retail locations.

13. A system in accordance with any one of claims 4 to

12, wherein there are a plurality of intelligent agents each of which is associated with an identified user.

14. A system in accordance with claim 13, further including agent interaction means, arranged to enable interaction between intelligent agents of users.

15. A system in accordance with claim 14, wherein the agent interaction means enables interaction between agents such as the giving and receiving of messages .

16. A system in accordance with any one of claims 4 to 15, further comprising attribute implementation means , arranged to implement the provision of attributes to the intelligent agent.

17. A system in accordance with claim 16, wherein the attributes are arranged to determine the functionality of the intelligent agent in carrying out tasks .

18. A system in accordance with claims 16 or 17, wherein the attribute implementation is arranged to affect changes to the attributes of the intelligent agent in accordance with predetermined criteria.

Substitute Sheet ⁽Rule 26) RO/AU

19. A system in accordance with claim 18, wherein the predetermined criteria includes operation of the intelligent agent in carrying out tasks .

20. A system in accordance with any one of the claims 16 to 19 , wherein the agent interface is arranged to enable the user to determine the attributes to be provided to the intelligent agent via the attribute implementation means.

21. A system in accordance with any one of the claims 16 to 20, wherein the agent interface is arranged to enable the user to affect changes in the attributes of the intelligent agent via the attribute implementation means .

22. A system in accordance with any one of claims 16 to 21 when read back onto claim 14 or 15, wherein interaction between intelligent agents depends on the respective attributes of the intelligent agents.

23. A system in accordance with any one of claims 4 to 22, the system including user mood determination means arranged to determine the mood of the user and affect the operation of the intelligent agent accordingly.

24. A system in accordance with claim 23, the mood determination means being arranged to determine the mood of the user from information input to the user terminal by the user.

Substitute Sheet ⁽Rule 26) RO/AU

25. A system in accordance with claim 23 or 24, the mood determination means being arranged to determine the mood of the user from the manner of the interaction of the user with the user terminal.

26. A system in accordance with any one of claims 4 to 25 including push content provisions means for providing push content to the user terminal in association with operation of the intelligent agent.

27. A system in accordance with claim 26, wherein the push content contains information chosen according to operation of the intelligent agent by the user.

28. A system in accordance with claim 27, wherein the push content information is chosen according to the history of the operation of the intelligent agent by the user.

29. A system in accordance with any one of claims 4 to 28 including means arranged to determine location of user terminals associated with intelligent agents .

30. A system in accordance with claim 29, wherein the agent implementation means is arranged to affect operation of the intelligent agent in accordance with the physical location of the user terminal.

31. A system in accordance with any one of claims 4 to 30, wherein the agent interface is arranged to represent the intelligent agent at the user terminal as a characterisation.

Substitute Sheet ⁽Rule 26) RO/AU

32. A method of enabling a user of a user terminal in a network environment to carry out tasks , the tasks being actioned in the network environment, comprising the steps of implementing in the network environment an intelligent agent which is arranged to carry out the tasks instructed by the user via the network terminal .

33. A method in accordance with claim 32, employing the system of any one of the claims 4 to 31.

34. A system in accordance with any one of claims 4 to 31, the system further comprising transient agent interface means implementation means of implementing transient agent.

35. A system in accordance with claim 34, wherein the system is arranged to broadcast transient agent interface means to a plurality of user terminals.

36. A system in accordance with claim 34 or claim 35, the user terminal including an agent container for storing transient agent interface means.

37. A system in accordance with any one of claims 34 to 36, further including transient agent implementation means for implementing tasks instructed to the transient agent.

38. A system in accordance with claim 34 to 38, wherein a transient agent includes a voucher for a product or service .

Substitute Sheet ⁽Rule 26) RO/AU

39. A system in accordance with any one of claims 4 to 38, the user terminal including means for interacting with the network environment, a further means for interacting with a further network environment, the interactive agent being arranged to operate in the further network environment .

40. A system in accordance with claim 39, wherein the further network environment is a micro network.

41. A system in accordance with any one of claims 4 to 40, the user terminal including a client, and the agent implementation means being arranged to interface with a plurality of different types of client.

42. A system in accordance with any one of claims 4 to 40, the user terminal including an agent container arranged to store an agent interface implementation means for implementing the agent interface.

Dated this 1^st Day of February, 2000 NEXTGEN PTY LIMITED By its Patent Attorney GRIFFITH HACK

Substitute Sheet ⁽Rule 26) RO/AU