WO2009111825A1

WO2009111825A1 - A system and method for facilitating multiple user interaction

Info

Publication number: WO2009111825A1
Application number: PCT/AU2009/000284
Authority: WO
Inventors: David Bolliger; Tony Schofield; Greg Mcintyre
Original assignee: Tilefile Ltd
Priority date: 2008-03-10
Filing date: 2009-03-10
Publication date: 2009-09-17

Abstract

The present invention relates to a method, system and computer program for facilitating interaction between a plurality of users. In one embodiment, the method comprises the steps of providing a server arranged to receive, from a user, a request to collate disparate media, the server providing the user with a unique identification code capable of identifying the media, and wherein, on the server receiving media associated with the unique identification code, the server associates the media with a collection.

Description

A SYSTEM AND METHOD FOR FACILITATING MULTIPLE USER

INTERACTION

Field of the Invention

The present invention broadly relates to a system and method for facilitating multiple user interaction.

Background of the Invention

The Internet and mobile communications have matured to a point where many users use these communication mediums for not only research and work, but also for entertainment, social interaction and marketing. The inclusion of cameras (both still and video) into mobile communication devices has caused an explosion in the amount of user generated content. Moreover, multimedia services which are deployed over a telecommunications network (e.g. video streaming to mobile (cell) phones) have grown exponentially.

However, while these communication mediums promote a new level of social interaction, they continue to be inherently limited, in that they either promote "one to one" communication (e.g. a message sent to a mobile (cell) phone), or "one to many" communication (e.g. a message sent to a website) .

Applications which allow for true collaboration and information sharing are still in their infancy. Furthermore, businesses have struggled to develop a model which delivers advertising and/or branding over a telecommunications network in a non-invasive and socially acceptable manner. In the context of the present specification, the terms "Content" and "Media" are intended to include within their definition any form of information, including user generated photos, videos or text or audio clips as well as professionally generated content such as movies, songs or software applications, including video games. Furthermore, the term "Branding" is utilised to describe the "look and feel" of a company's marketing get-up.

Summary of the Invention

In a first aspect, the present invention provides a method of utilising a telecommunications network to collate disparate media from a plurality of sources, comprising the steps of providing a server arranged to receive, from a user, a request to collate disparate media, the server providing the user with a unique identification code capable of identifying the media, wherein, on the server receiving media associated with the unique identification code, the server placing the media into a collection.

The unique identification code may be a telephone number or may include part or all of a telephone number.

The unique identification code may be provided to a plurality of other users, wherein the plurality of users may be pre-chosen by the user.

Media received by the server from at least one of the plurality of users may only be added to the collection if at least one of the plurality of users is authorised by the user.

On receiving media from a non-authorised user, the server may send a message to the user to alert the user of the receipt of media from a non-authorised user. The user may authorise a non-authorised user by sending a message to the server to add the non-authorised user to the list of authorised users.

The server may set a time limit for the receipt of media from the user and/or the plurality of users, such that, on expiration of the time limit, no further media received will be added to the collection. The time limit may also be set by the user.

In a second aspect, the present invention provides a computer program arranged to be operable on a mobile device, comprising communication means arranged to connect with a remote server via an available communications channel, and send media tagged with a unique identification code to the server, so that the server may associate the media with a collection.

In a third aspect, the present invention provides a computer program including instructions for controlling a computing apparatus to implement a method in accordance with a first aspect of the invention. In a fourth aspect, the present invention provides a computer readable medium providing a computer program in accordance with a third aspect of the invention.

Brief Description of the Drawings

Notwithstanding any other forms which may fall within the scope of the present invention, an embodiment of the present invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Figure 1 is a block diagram of a system arranged to carry out an embodiment of the present invention;

Figure 2 is an example computing system arranged to be utilised to carry out a method in accordance with an embodiment of the present invention;

Figure 3 is a flowchart illustrating the method steps of a user utilising a method in accordance with an embodiment of the present invention;

Figures 4 to 6 are flowcharts illustrating different example interactions with a system in accordance with an embodiment of the present invention; and

Figures 7 to 14 are example sσreenshots of an integrated application (computer program) for a mobile communications device in accordance with an embodiment of the present invention.

Detailed Description of Embodiments

Overview

The embodiment described herein provides a system and method for a group of associated users to contribute user generated content to a central repository or collection of media, for easy retrieval at a later time.

In the context of the embodiment described herein, each collection of user generated content will be referred to as a "story" . The process of each user contributing generated content into a collection will be referred to as "building a story" .

In the context of the broader invention described herein, a "story" is a collection of user generated content (generated by either one or more users) which may include images, sounds, video, text, links, other types of metadata, or other types of information or data.

With reference to Figure 1 there is shown a system, which in the embodiment describes includes one or more computing systems linked via a communication network. The system is further linked to a mobile tele-communication network (not shown) . The system as a whole allows mobile communication devices to interact (either directly or indirectly) with the one or more computing systems.

The system is arranged to allow for seamless interaction between multiple users and also serves as an aggregation, sorting and storage service for user generated content, such as text messages, images, sounds, videos and other user generated content. Third party content may also be aggregated, sorted and stored in the system.

In more detail, the telecommunications network delivers Multimedia Messages (MMS) via a MMS gateway 100 to a mail service 102. The mail service 102 interacts with a number of components, and serves as a "hub" for interaction between the external MMS gateway and other services .

In more detail, the mail service 102 also connects to a MMS media extractor service 104, which is arranged to extract media from the received MMS messages . Once media is extracted by the MMS media extractor service 104, the extracted media is sent to a "Storyz" service 106, which collects the media and stores the media in association with other collected media in a "Storyz" database 108. It will be understood that "Storyz" is a trade mark of Storyz.com (an Australian Private Company) and is utilised in the present specification as a convenient descriptor for the exemplary embodiment described herein. The term "Storyz" is not to be taken as a generic term to describe the broader invention described and defined herein, nor is it intended that the broader invention described herein be limited to the embodiment described. It will be understood that media may also be sent in one of a number of different manners. For example, in one embodiment, the Storyz service provides the end user with a customised application which is arranged to integrate with the functionality of their mobile device. That is, the user may download onto their mobile phone an application which is capable of retrieving media from a storage device within the mobile telephone, package the media in an appropriate manner, and send the media to the Storyz service. In the embodiment described above, the media is sent in a MMS format. However, where the user has a mobile device with other capabilities (e.g. the ability to connect to an Internet service utilising an Internet Protocol) , the application may choose to use an Internet path to send media to the Storyz service 106. Similarly, the application may also receive information from the Storyz service 106 via any one of a plurality of path ways .

Once the media is received at the Storyz service 106 and saved in the database 108, the media may then be sent, forwarded or accessed via other portals, which may be proprietary and/or third party. For example, depending on the wishes of the user or the preconfigured setup of the user's account, the content may be accessed via a proprietary website operated by Storyz, or may be accessed from a third party website, such as Facebook™ (a social networking website operated by Facebook Inc . , a US company) 110. Concurrently, media may also be delivered to other users via an SMS service 112 (for users who do not have a MMS capable mobile (cell) phone) . The Storyz service 106 also interfaces with an existing TiIeFiIe service (a method of aggregating, displaying and manipulating media, devised by TiIeFiIe Limited, a publicly listed Australian company) .

The Storyz service 106 is connected to a TiIeFiIe server 114 via the Paris encoding service (a proprietary encoding service developed by TiIeFiIe Ltd, and integrated with Amazon Web Services, a service supplied by Amazon Inc., a US corporation) . The TiIeFiIe server 114 also includes one or more TiIeFiIe databases 116, which are arranged to hold information regarding each user's TileFiles.

To achieve the aforementioned functionality, each of the servers (e.g. the MMS Gateway 100, the Mail Server 102, the MMS Media Extractor Service 104, the Storyz server 106 and the TiIeFiIe server 116) comprises computer hardware such as the example computer hardware shown in Figure 2. The example computer hardware of Figure 2 includes a motherboard 200, central processing unit (CPU) 202, graphics processing unit (GPU) 204, read-only memory (ROM) , primary storage 206 such as random access memory (RAM) , registers cache and secondary storage 208 such as disk drives, hard disk, non-volatile memory modules 210. There are also provided a plurality of communications links 212 which connect to one or more other computer devices such as external computers, personal computers, terminals, wireless or handheld computing devices. Each of the plurality of communication links, when in use, is connected to an external communications network such as the Internet or a telecommunications network such as a 3G network . In addition to the hardware the computer includes an operating system 214 such a Microsoft™ Advance Server or Linux™ that resides on the hard disk or other storage device and which co-operates with the hardware to provide an environment in which one or more software applications can be executed. In this regard the computer also has software 216 arranged to provide part or all of the functionality described herein.

How a User Interacts with the System

The "building of a story" (i.e. the process flow in accordance with an embodiment of the present invention) is shown in the flow chart (300) at Figure 3. At first instance, a user wishes to start a story (302) .

The user firstly initiates a story by sending a request to the Storyz service (304) . The request may be initiated via a conventional web interface (306) , or it may be initiated via a mobile (cell) telephone (308) . As stated above, the interaction between a mobile (cell) telephone may be at a superficial level (e.g. a user sends a conventional SMS or MMS message to a unique telephone number) , or it may be at a deep, embedded level (e.g. the user's mobile (cell) telephone contains a dedicated software application, where the channel or manner of communication is not explicitly shown to the user) . When requesting a new story, the user will be prompted to select other users that are allowed to access and/or contribute to the story (310) . That is, the initiating user selects a group of people who can view and contribute to the story in a relationship that is potentially many to many. That is, a plurality of both contributors and viewers, where the contributors and viewers may or may not be the same people. The user may, if they wish, make the story "public", in which case any user of the Storyz service may be able to view and/or contribute to the story. Once the story has been initiated, the user will be given a unique telephone number. If desired, the selected other users will receive a SMS, MMS or email message alerting them to the initiation of the story. In the case where the Storyz application is more deeply integrated into a phone or other operating system, the user may never explicitly see or be aware of the "phone number" , as it ■ will be automatically received and stored by the Storyz application. It will be understood that the term "phone number" is utilized broadly, and may include a portion of a phone number, or an alphanumeric identifier that allows the user to connect and uniquely identify themselves to a remotely hosted server (e.g. the phone number, in one embodiment, is akin to a "user ID", but is specific to a story.

Moreover, when using a deeply integrated Storyz application, the user may elect to receive notifications as a Storyz-specific audio alert (akin to an SMS alert, but specific to the Storyz service) . Once the story is initiated, users may contribute to the story by providing media, comments, or any other information (312) . Users without a Storyz client application loaded on their phones may contribute by sending content, via their mobile (cell) phone, to the unique phone number (312) . Users with a Storyz client application loaded on their phone may do so the same way, or the client application may handle the sending of content in a seamless manner, such as via use of the hypertext transfer protocol (HTTP) . In this manner, a user does not have to remember a complex set of instructions, or need special or proprietary technology to contribute to the story. As content is added to the story, users can choose to be notified of the addition of content (314) . In this manner, a user can see how content is being "built up" to form a coherent and interesting collection of media that can be used to describe an event . Where the user does not have a specific Storyz client loaded on their phone, this content may be viewed in the phone's web browser (as HTML or WAP) .

After a certain amount of time has elapsed, the initiator of the story may then choose to "close" the story (i.e. no longer allow more content to be added to the story) , or alternatively, the story may automatically close off at a certain time (316) .

Once the story has been closed, the user may review the story, either via their mobile (cell) phone, or alternatively, through a conventional web interface.

Examples of particular process flows are shown at Figures 4, 5 and 6. At 402, the user takes a photograph with the camera that has built into their mobile (cell) telephone. Once the picture is taken, the user is given the option to start a new story (404) . If the user elects to start a new story, the user is asked to provide some basic details (e.g. a title) (406) . The user is then prompted to invite users to the story (408) . Once the basic information and the other users have been selected, a new story is initiated (410) . Users may then submit further posts (412) by creating a new post (416) , which once submitted, becomes part of the same story (418) .

At Figure 5 there is shown a process flowchart from the point of view of a user who is asked to join a story initiated by another user. At 500, the user receives an SMS (or other alert) . If this is the first time the user has used the Storyz application, the user is prompted to set-up a new account (502) . Once the new account is set-up, the user is taken directly to their "invited" story (504) . The user may then post entries (506) , including the addition of suitable media (for example, images produced by their mobile (cell) telephone) 508. Once the new post is composed (510) , it is sent to the Storyz application and becomes part of a story (512) .

At Figure 6, there is shown an example of a Storyz application where the user does not have an embedded Storyz software application, but rather, is using a conventional mobile (cell) telephone. At 600, the user receives an SMS alert. The SMS alert provides a link to a webpage (602) . The user can interact in the story in one of two ways. If the user does not want to use a web-browser or connect to the Internet, the user can reply utilising a conventional SMS message (604) . The SMS, once sent, is sent and becomes part of the story (606) . Alternatively, if the user has access to a web-browser on their mobile device, the user can follow a link to an Internet site (608) . Once the user follows the link, they are asked to sign-up to the Storyz service (610) . Once the user has signed-up, they may compose any suitable message, and include media or content, if desired (612) . Once the user provides the media, the media provided by the user is incorporated into the story (614) . In a similar way, a user can respond to a story through email. When one user invites another using his/her email address, the invited user receives a selection of the messages in the story in the email, with the media embedded, and can type his/her response directly in the email and click a "Send" button within that email.

Figures 7 to 14 illustrate example embodiments of various interfaces utilised by an embodiment of the present invention. Figure 7 is a conventional web-page interface, which provides one method of access to the Storyz application. Figure 8 illustrates a series of stories in preview mode on a conventional mobile phone interface. Figure 9 illustrates an entry screen, into the Storyz application, when accessed via a mobile phone.

Figure 10 illustrates a part of a story, as displayed on a mobile phone interface. The figure also illustrates how Branding is integrated into the Storyz messages and application, while Figures 11 and 12 show an example of the branding on other interfaces. Figures 13 displays how the users can add images to a story through the phone camera on various mobile phones, while Figure 14 shows how users can add friends from their phone book contact list or the Storyz contact list.

Insertion of proprietary "third party" content

The embodiment described herein also allows for third party proprietary content to be shared by users of the Storyz service. A third party service (such as iTunes™, an online media content provider operated by Apple Inc., a US corporation) can provide content in a manner that is limited, such that only authorised users may view the content . A user is able to select content to be added to a specific story. The user does so by browsing (using a web browser, or alternatively, clicking though to a dedicated section in the Storyz application) to a site which contains the media. After viewing a preview, the user may select the content, at which time the user is taken to a site hosted by the content provider. At the site hosted by the content provider, the user may take any necessary steps to purchase the content. In one embodiment, the purchase may be automatically effected (e.g. an amount is automatically charged to the user's mobile (cell) telephone account) . Once the user has undertaken the necessary steps, the content is downloaded and displayed on the device of the user. If the user wishes to incorporate the content into a story, the embedded application only forwards the preview and the link to the story. In this way, the copyrighted or proprietary content is not distributed to all users of the story, thereby preventing the unauthorised copying or distribution of copyrighted content.

However, as the link and preview are forwarded to the story, other users can view and interact with the content, and subsequently purchase the content, if they wish. In other words, content can be spread "virally" between users, without infringing copyright or other intellectual property laws.

In order to effect the system, content providers are given access to the Storyz system via means of an API (Application Programming Interface) and/or an Administrative interface. The content provider places a link to the content in the Storyz system, a link to thumbnails and a link to a preview (so that a user may preview the content before making a decision to purchase the content) . The thumbnails, link and preview are re-encoded so that they may be easily displayed, in a recognisable format, on the user's mobile device.

Third party content may also be made available through the proprietary web portal provided by the Storyz service . Widgets and their use

In order to assist in the viral spread of a story, users are given standard tools which assist them to ^xxpost" Storyz on websites or other electronic portals or interfaces .

Widgets enable users to connect to a remote service, so that the user may display or interact with content from that service . The service may be a remotely hosted software application, or may be a Uniform Resource Link, or a Device (e.g. a storage device) . Users can make use of widgets by copying sections of code and pasting the code into a HTML webpage or into the source code of a locally hosted software application. A widget is far simpler for a non programmer user to utilize in a suitable manner. The Storyz system provides a series of widgets to enable users to copy and paste aspects of the interface to third party locations (e.g. a user's personal website or a third party application developed or customised for the user) to enable the user to display part or all of the content from the Storyz service to users of that third party location.

The Storyz system also provides a widget framework to enable the construction of such widgets; the framework includes ready to use code that may be used by a software developer.

By providing widgets, a user can interact with the content of Storyz in different locations. That is, while the display of a story may vary due to different device capabilities, different bandwidth, etc., the actual content (e.g. comments, linkages and users who interact) remains the same across all platforms. Widgets represent another implantation of a "client side" application that allows users to interact with the Storyz system, irrespective of the type of device they are using (e.g. a 2GSM mobile (cell) phone, a 3GSM mobile (cell) phone, a wireless Internet connection, a conventional computing system, etc.)

Facebook™ (external website) Integration

Storyz may also be displayed on third party websites, subject to the third party allowing such content (and optionally providing the tools to integrate a story into their site) . The example given herein relates to Facebook, a well-known social networking site (http : //www . facebook . com) . However, it will be understood that other websites may also provide similar functionality.

Story alerts and notifications may also be handled by applications or frameworks such as Yahoo! One Connect system, which is operated by Yahoo!, a US based corporation.

A user of the Storyz website may also have a Facebook profile, on which they wish to display one or more Storyz . They may access their Facebook account without storing their username and password. This process is endorsed by Facebook, even for separate .com products. It requires the user to request a permanent session key, which they must copy and paste into the Storyz web site. This is saved with their account information and can be used as the session key for updating their feed.

The user then installs a Storyz application into their Facebook account . This allows the Facebook site to retrieve content from the user's Storyz account, for display on the user's Facebook profile.

Branding, incentives and analytics

Every activity the user undertakes results in certain points ( "Pointz") being given to the user as a measure of their activity. Users can at any given time see their total points, and more points result in more prominent listing as an active user on the Storyz.com website. The point structure can also be used in campaigns posed by companies wanting to promote their brand or product ("Brands") . The companies may entice users of the Storyz service to disseminate their brand by organising competitions or campaigns, where a user who wins the competition or participates in the campaign is rewarded with points. The points achieved while participating in a competition/campaign then become a measure of the activity of a user, which in turn allows administrators of the service to rank users.

When a user signs up for a competition, all their messages become "branded" . Branding a message may be as simple as superimposing a logo or slogan on every image or video sent by the user. Alternatively, branding may be more subtle, in that the branding may automatically set the "look and feel" of a message, such that recipients of the message associate the message, either consciously or subconsciously, with a particular brand.

Example functions of the system

In order to achieve the functionality described above, Storyz can be implemented as a series of functions/procedures/libraries in the Storyz server, such that a programmer may call on the function when constructing a front end interface for an application. The functions listed below are an example of the types of functions available within an embodiment of the present invention.

EmailContributeRequests

When another user attempts to contribute an item to a collection of media, and they are not preauthorised as a contributor for an event collection, the user is sent an email notification which can be used to accept another user's contribution.

EmaiIWatcher An event collection can have contributors (analogous to an administrator for the collection) and watchers. Watchers are simply notified whenever new content appears for an event .

FacebookFeedEntry Facebook feed entries are used to help notify people using the web of activity, which they can choose in preference or addition to receiving email notifications. MobActiveDestination

As a user take photos and videos, they automatically become part of a specific story (set as the active destination for that user's phone media) . Either 1-at-a-time or in a bulk upload once the user is finished, the media is sent to the Storyz system and appears in the system in the appropriate specific story. MobNewDefault

The default name for the story of a new event is the date at which the event is created. MobNewPrompt

Each new day begins, by default, at 5am (customisable) . Therefore, mobile (Cell) phones time out at 5am. When a user attempts to take a photo or video with the mobile phone, the user is prompted with a question: "Do you want to continue adding media to <active destinations" If the active destination is an event (story) that has now finished, the user can select "no" . MobSocialFeed This is a search-like function arranged to determine whether friends have already created an event (eg "The Wedding" ) , so that a user can contribute to the same collection from the start and avoid duplication, or having to go through the contributions process later. WebCollectionSections

Other user's contributions can appear clumped together with your content, or separated out under the other user's sections. Separating their content out is useful if a user doesn't approve of the content, or if a user simply wants to view all the content generated by a particular user.

WebContributeAccept

Clicking a link in an email to accept a contribution leads to a web page confirming the action and then displaying the now-bigger collection. WebContributeCollection

This function allows a user to contribute their collection to another user's collection (i.e. an aggregation function) . WebContributeFlickr

Contribute a single Flickr image, or a Flickr album, to a collection. WebContributeHTTP

Contribute a single image, served on an HTTP web server, to a collection.

WebContributePhotobucket Contribute a Photobucket album to a collection.

WebContributeRequest

To avoid people contributing spam, a user must accept other users as a contributor to a collection. By doing so, the other users can add further content to the collection, which will always appear in the user's collection under a section with their user name. The need to accept contributors can be avoided by setting a collection as public, or by adding contributors beforehand on the web site. WebContributeYouTu.be

Contribute a YouTube video (or set of videos) to a collection.

WebPermalink

Creates a short and easily remembered URL (Uniform Resource Locator) for a collection on the web.

WebRSS

Each event has an RSS feed that can be used instead of email or Facebook feed notifications. WebViewCollection View a collection on the web site. Viewing is generally done with Flash, so that images and video can be presented seamlessly in slideshows and grid layouts.

WebWatchersAdd

When adding watchers/contributors to an event, previously added watchers/contributors may be selected through an interface akin to an email address book. Each entry in the list is marked as either being a registered user, or not. If not, an email address or mobile phone number must be specified, as a mechanism to notify the user by email or SMS respectively. Both registered and non-registered users are stored in the address book.

Example

The embodiment described herein will now be described with reference to a simple example of an event, and how it is managed. As each action is described, the function invoked by the embodiment is provided in parenthesis .

It's the day of the company Christmas party. Everybody is wearing eye patches. David takes out his phone and takes a picture. His phone prompts him to tell it whether he wants to start a new story today. (MobNewPrompt)

He selects "yes" and replaces the default name "14 Dec 2007" with "Tilefile Christmas Party" (MobNewDefault) . This is now his phone's "active destination", i.e. the active story. (MobActiveDestination) He then snaps happily away and every photo he takes is automatically uploaded to the system and stored under David' s story "Tilefile Christmas Party" . (MobActiveDestination) Greg takes out his mobile phone. Instead of snapping away, he checks the Tilefile web site or application on his phone. He immediately sees a list of what his friends are up to (social feed) . (MobSocialFeed) He sees that David has just created an event called "Tilefile Christmas Party" . Greg selects this as his "active destination" . (MobActiveDestination) He takes photos with his phone and they are automatically uploaded to the system under David's event "Tilefile Christmas Party" . (MobActiveDestination) This builds up a shared photo/video album for this event.

Jenny also has a camera phone at the party. She starts snapping away without checking her social feed first. She decides to start a collection called "Tilefile Xmas Party" and this is her active destination throughout the evening. All her photos go there during the night. It's the next day. Two albums have been created, one by David and one by Jenny. i Jenny logs into her Facebook account and sees in her mini -feed that David created an event last night called "Tilefile Christmas Party" . (FacebookFeedEntry) She follows the link off Facebook and onto the Storyz web site where she looks at the photos he took during the night . (WebViewCollection) She decides that she would like to contribute her collection of photos to his collection of photos for the event. She clicks a button below David's collection and elects to merge her "Tilefile Xmas Party" event into this one. (WebContributeCollection) A request is sent to David via email. (WebContributeRequest)

Punya took his digital camera to the party and took photos. Now that it's the following day, he uploads his photos to Flickr to share them with other people. When he checks his Facebook account, he notices that David and Jenny have created Tilefile events. (FacebookFeedEntry) He looks at Jenny's album first, and then at David's album. (WebViewCollection) Punya wants to add his photos to David's collection. He clicks a button under the view of the collection and copies and pastes his Flickr album URL. (WebContributeFlickr)

Once David accepts, there will be a section in David's "Tilefile Christmas Party" album with Punya' s name on it and all of Punya' s Flickr photos. David receives a few emails about some requests. (EmailContributeRequests) He follows the link in his email and logs on to the event product web site and accepts several offers to add media to this collection from attendees. (WebContributeAccept)

Jenny and Punya's images are added before he views the collection of photos. Jenny's photos are still stored in her account but they appear in David' s "Tilefile Christmas Party" event (story) under a section with her name. (WebCollectionSections)

Punya's photos are still stored on Flickr but they appear in David's story. He decides the Tilefile staff should see this. He clicks the share button and marks all those in his contact list that attended with one click each. (WebWatchersAdd)

Jude is a newer staff member who is not on the list so Punya adds Jude's email address and clicks send. (WebWatchersAdd) An email notification is sent to all of newly added people containing a link to this story, with an easily understood, permanent URL. (EmailWatcher)

Each staff member visits the story and sees in one place all the collected media that exists on the Internet that was taken of that event . Several staff members have uploaded images of the event to public web servers, Photobucket, videos to YouTube, etc. Each one clicks a button and offers to add their media to David's story. (WebContributeYouTube) , (WebContributePhotobucket) , (WebContributeHTTP)

David receives one email for each contributor. That is, he only has to accept once for each person, which makes them a contributor for this story and auto-accepts all their future contributions to this story. (EmailContributeRequests) Each time David accepts a contribution, the collection grows and all interested parties are notified via email (EmailWatcher) and via Facebook mini-feed entries (FacebookFeedEntry) that there are new photos available in this event (story) .

Now that the collection is definitive and impressive, David decides to show his family. Instead of adding his family member email addresses as watchers, he copies the URL from the address bar and emails it to his family members. He writes a nice email to accompany this link, which he feels will be nicer than an automated message. (WebPermalink)

The family members do not have Tilefile accounts, or Facebook accounts, but they appreciate seeing all the photos and videos, taken by multiple contributors, but aggregated all in one place. Because they are not watchers, they will not receive notifications on updates to this collection.

Advantages

Existing services and online applications have struggled with the development of a system that makes it easy to receive, aggregate, order, display, and send information between a group of users on a common telecommunications network. While GSM and 3GSM (3^rd generation GSM) networks provide the capability to send Short Messages (via SMS) , and Multimedia Messages (via MMS) , such mediums are designed to send content in a "one-to-one" fashion or a "one-to-many" fashion. Such devices are not capable of easily and intuitively creating a "conversation" between a number of different users, potentially using different mobile (cell) telephones and/or platforms, with different capabilities and different networks.

The embodiment described herein is platform neutral, in that a user does not need to be concerned about the technology of their mobile (cell) telephone or the inherent capabilities of their network. The embodiment is arranged to interact with any type of mobile telecommunications network, so that even users on obsolete networks can enjoy a reasonable level of interaction in the conversation between different users.

Moreover, as the embodiment aggregates content in a central location, the content may be easily accessed at a later date. This cannot be achieved with conventional technology, where different content may reside across the personal mobile (cell) telephones of a number of different users, or in multiple accounts of disparate services.

The embodiments described herein allow users of mobile communications devices to associate content (such as images, videos, text, etc.) with a particular event or category, store the content (or metadata pointing to this content) in a central location, and ensure that all users interested in the content can contribute and/or keep informed about updates to the content .

The Storyz system provides the capability of providing and distributing both user generated content and "premium" proprietary content over the same network. In other words, a user can mix self-authored content with third party copyright content in a manner that does not infringe the Intellectual Property rights of the third party content owner.

Lastly, the Storyz system allows for Brands to run competitions/campaigns across web and mobile platforms, while integrating the Brand's look and feel into the messaging flow between users. This allows for consistency in the look and feel of online campaigns across digital platforms. Furthermore, Storyz applications can utilise access points so that in a marketing campaign, a link can be drawn between the Brand and the user' s involvement with the campaign.

Any reference to prior art contained herein is not to be taken as an admission that the information is common general knowledge, unless otherwise indicated. Finally, it is to be appreciated that various alterations or additions may be made to the parts previously described without departing the spirit or ambient of the present invention.

Claims

CLAIMS :

1. A method of utilising a telecommunications network to collate disparate media from a plurality of sources, comprises the steps of: providing a server arranged to receive, from a user, a request to collate disparate media; the server providing the user with a unique identification code capable of identifying the media, and wherein, on the server receiving media associated with the unique identification code, the server associates the media with a collection.

2. A method as claimed in Claim 1, whereby the unique identification code is one of a telephone number or a portion of a telephone number.

3. A method in accordance with Claim 1 or Claim 2 , comprising the further step of providing the unique identification code to a plurality of other users.

4. A method in accordance with Claim 3 , wherein the plurality of users are pre-chosen by the user.

5. A method in accordance with Claim 4, wherein media received by the server from at least one of the plurality of users is only added to the collection if the at least one of the plurality of users is authorised by the user.

6. A method in accordance with Claim 5, comprising the further step of, on receiving media from a non-authorised user, sending a message to the user to alert the user of the receipt of media from a non-authorised user.

7. A method in accordance with claim 6, wherein the user may authorise a non-authorised user by sending a message to the server to add the non-authorised user to the list of authorised users.

8. A method in accordance with Claim 7, comprising the further step of the server setting a time limit for the receipt of media from the user and/or the plurality of users, such that, on expiration of the time limit, no further media received will be added to the collection.

9. A method in accordance with claim 8 , wherein the time limit is set by the user.

10. A method in accordance with any one of the preceding claims, wherein the media is sent to the server utilising a Multimedia Message Service.

11. A method in accordance with any one of the preceding claims, wherein the media is sent to the server utilising a telecommunications network protocol .

12. A computer program arranged to be operable on a mobile device, comprising communication means arranged to connect with a remote server via an available communications channel, and send media tagged with a unique identification code to the server, so that the server may associate the media with a collection.

13. A computer program in accordance with claim 12, wherein the means is capable of sending a request to the server to collate disparate media.

14. A computer program in accordance with claim 12 or claim 13, comprising identification means arranged to uniquely identify the user of the mobile device, wherein, on request, the unique identification is provided to the server, to identify one of the mobile device and media sent by the mobile device.

15. A computer program in accordance with claim 14, wherein the unique identifier is a telephone number associated with the mobile device.

16. A computer program in accordance with any one of claims 12 to 15, wherein the means are integrated with other computer programs residing on the mobile device.

17. A computer program in accordance with claim 16, wherein the other computer programs include at least one of an address book application, a multimedia message service application, a short message service application and a wireless Internet Protocol application.

18. A computer program including instructions for controlling a computing apparatus to implement a method in accordance with any one of Claims 1 to 17.

19. A computer readable medium providing a computer program in accordance with Claim 18.