WO2009076242A1

WO2009076242A1 - Method for providing content-related services for individual texts, files and other data

Info

Publication number: WO2009076242A1
Application number: PCT/US2008/085759
Authority: WO
Inventors: Patrik Hedmalm
Original assignee: Fileride Inc.
Priority date: 2007-12-10
Filing date: 2008-12-06
Publication date: 2009-06-18

Abstract

The method is for providing services directly related to specific text or binary data such as files on a computer Client software is provided for any number of client devices All the client devices are in communication with a common server, or a network of comput providing server-like functionality Each client device has any number of files, texts and data items A server or network of computer provides services via the client software, related to specific files, texts and data that reside on any or all of the client devices The services may be shared between a first client device and a second client device as a result of both the first and second client device having the same file or text and running some version of the client software

Description

METHOD FOR PROVIDING CONTENT-RELATED SERVICES FOR INDIVIDUAL TEXTS, FILES AND OTHER DATA

Technical Field

The present invention relates to a method for providing content-related services. More particularly, the method consistently turns the contents of any file, text or binary data into a unique location where users may access a requested service in the context of that file, text or data.

Background of Invention

Today's global and digital society contains a large amount of information in the form of binary files, texts and different kinds of media. Each piece of information may be scattered around the globe in many millions of copies. However, there is no framework for providing services related to each unique piece of data. There is no convenient way for the consumers of a particular piece of data to gather, sharing services in the context of that data. For example, there is no way to globally discuss a particular mp3 file or a specific portion of a text regardless of how it is labeled, where it is stored or from where it was obtained. Users are limited to local web forums or communities related to roughly the same subject. There is a need for a global infrastructure that provides services that are directly related to specific text, files or binary data.

Summary of Invention The method of the present invention provides a solution to the above-outlined problems. More particularly, the method of the present invention is for providing content- related services. The services may be directly related to specific text or binary data such as a file on a computer. The client may select any file, text or data as a key to start using a particular service related to it. A forum service could therefore be used to discuss a particular written text or media file by all its owners. A rating service could provide a way for consumers of a particular media file to globally gather and rate the service. The services of the present invention may not only be for exchanging information between users such as chat, voice communication, polling and voting. The services may also be used for providing content related information, downloads and customer support. Client software is provided for any number of client devices such as computers and mobile phones. Preferably, all the client devices are in communication with a server in common or a network of computers providing server-like functionality. Each client device may have any number of files, texts and data items. The server or network of computers provides locations of content-related services via the client software. The services related to any file, text or data may reside on any or all of the client devices. The services may also be shared between a first client device and a second client device as a result of both the first and second client devices having a copy of the same file or text and running some version of the client software.

Brief Description of Drawings Fig. 1 is a schematic overview of the system of the present invention;

Fig. 2 is a schematic view of a client side ownership request using the system of the present invention;

Fig. 3 is a schematic view of a client side service request (including a context key request) using the system of the present invention;

Fig. 4 is a schematic view of a client side update request using the system of the present invention;

Fig. 5 is a schematic view of a server side ownership request using the system of the present invention;

Fig. 6 is a schematic view of a server side context key request using the system of the present invention;

Fig. 7 is a schematic view of a server side service request using the system of the present invention; and - A -

Fig. 8 is a schematic view of a server side update request using the system of the present invention.

Detailed Description

Fig. 1 is a schematic overview of the system 10 of the present invention. The system is different from conventional information services in that instead of requiring the user to specify a particular address or location to access a service, the contents of any data file or text 20 of the present invention functions as a link to content-related services such as discussion forum, wiki, chat and voting. Any number of services may be provided by any number of service providers 30, 31. In other words, the system of the present invention does not require that users type in a particular web address to discuss a particular text or media file. Rather, the present invention requires that the users merely use the client software 27 in combination with any file or text 20 to be discussed. In this way, a user may simply mark, for example, text on a website and proceed to discuss it globally with other readers of the same text, as described in detail below.

With reference to Fig. 1, the client devices 24, 25 and others client devices 26 are in communication with a server 32 that has a database 34. Preferably, the server 32 is common for all the client devices 24, 25 and 26. The client device may be a computer, mobile telephone or any other electronic client device.

The local files 20, such as mp3 files or any other type of files, may be automatically detected by the client software 27 by an automated scanning and monitoring process. The files 20 may also be activated manually by, for example, dragging and dropping the file into the client software 27.

The users may activate the text content 20 by using a web browser or other text source so that the selected text is activated in the client software 27.

For each file, text or data 20, the client software 27 analyzes its contents to create corresponding information identification packages (IIPs) or fingerprints 22. The IIPs are packets of data that consistently identify the contents of a certain data file or text. An important feature is that each IIP is consistently the same for all files and texts containing the same information. Furthermore, the IIPs will never be the same for two files or texts where the contents differ. Each IIP generally includes a hash code that is generated from the contents of the text or file. Each IIP may also include a type tag that identifies the type of the original data. The type may be extracted from the contents of the data and not by looking at the file name. The IIPs may also include information about the size of the original data and may also include metadata such as artist, title, album et cetera if the file is an mp3 music file.

With reference to Fig. 2, files detected manually or automatically may be reported as owned by the client. This may be done by initiating an ownership request. To initiate an ownership request, the client preferably needs an IIP 22 to identify the file, text or data 20 to report ownership thereof. Preferably, the client software generates the IIP 22 in a generation step 50, as described above. As soon as the IIP 22 is generated from the contents of a file or a text 20, the client software 27 performs a local lookup step 52 to see if ownership has already been reported for the data 20 in question. If so, the ownership request is aborted 54 as the server 32 already knows about the client having the file or data 20. If the client has not yet reported ownership of the file or text 20, the IIP 22 and client identification (CID) 37 is sent in a sending step 56 to the server in an ownership request.

In a determining step 57, the server determines the result of the request. The server 32 may respond with a simple acknowledgement in which case the client software 27 makes a local record in a recording step 58 indicating that ownership has been reported for the file or text 20.

In case the file or text 20 was already activated and used by another client, the server 32 may also return the context key (CK) 36 corresponding to the IIP 22 in which case the client software 27 may store in a storing step 60 the CK along with its IIP locally for future reference.

With reference to Fig. 3, a user may request a service in a requesting step 62 for any file or text using client software 27. The IIP 22 of the file or text 20 is used to look up a context key (CK) 36. In a determining step 66 it is determined whether the CK is stored locally for the IIP. If the CK was found locally in a looking up step 68 there is generally no need to request the CK from the server 32. If the client does not have a CK for the IIP 22, the CK may be requested in a request step 70 from the server 32. Once the CK 36 is returned from the server 32, the CK may be stored in a storing step 72 along with the IIP 22 for future reference. Each service has a unique identifier called service identifier (SID) 64. Preferably, the SID 54 along with the CK 36 of the file or text 20 may be sent to the server 32 in a service request step 74.

Upon success, the server 32 responds by returning a location, such as a url, of the requested service in the context of the requested file, text or data 20. The client software 27 may then use this location to start/open 76 the requested service on the client device (24, 25 or 26) .

With reference to Fig. 4, the client software 27 may periodically ask the server 32 if services related to any of the files 20 owned by the server has been updated. This may be done by initiating 78 and sending the client identifier (CID) 37 to the server 32 in an update request 80. In a determining step 82 it is determined if there are updates available. The server 32 returns a list of CKs 36 owned by the client that have been updated since the client last sent an update request. If there were no updated CKs 36 the client does not do anything and the process is done 84. If updates are available, the updates are stored locally in a storing step 86. If one or more CKs 36 were returned, the client software 27 may mark the CKs 36 as updated and notifies the user in a notification step 88.

With reference to Fig. 5, the client 24 may initiate an ownership request in an initiation step 90. At the server 32 end of the ownership request, the IIP 22 and client identifier 37 are received from the client 24 in a receiving step 92. In a determining step 94, the server checks to see if a CK 36 has previously been created for the IIP 22. If so, the CK 36 (effectively the original file or text) is looked up 96 and associated with the requesting client by inserting and storing 98 an entry that may contain both CK 36 and CID 37, into the database 34. The CK 36 is then returned in a returning step 100 to the requesting client 24, 25 or 26 in an acknowledgement response. If there was no CK 36 previously created for the IIP 22, the requesting client 24, 25 or 26 is associated and stored 102 with the IIP 22 itself by inserting an entry into the database 34 containing IIP 22 and CID 37. An acknowledgement is then returned in a returning step 104 to the requesting client 24, 25 or 26.

With reference to Fig. 6, the client 24 may initiate a context key request 106. The server 32 handles a context key request by first receiving the IIP 22 in a receiving step 108 from the requesting client 24, 25 or 26. In a determining step 110, the server then tries to find a CK 36 for that IIP 22. If there was a CK 36, the CK 36 is looked up 112 for the IIP and is immediately returned in a returning step 114 to the requesting client 24, 25 or 26.

If there was no previously stored CK 36 for the IIP 22 in question, a new CK is generated in a generation step 116 and associated with the IIP 22 by storing 118 an entry in the database. Then all ownership entries referring to that IIP 22 are updated in an updating step 120 to refer to the CK 36 instead. Finally, the CK 36 may be returned in the returning step 114 to the requesting client 24, 25 or 26.

With reference to Fig. 7, the client may initiate a service request in an initiation step 122. A service request is handled by first receiving 124 a context key CK 36 along with the service identifier (SID) 64. The SID 64 may then be used to look up in a looking up step 126 the correct url format for that service 30, 31. The server 32 then turns the url format into a complete url in a generating step 128 by combining it with the CK 36. The full url is returned in a returning step 130 to the requesting client 24, 25 or 26. With reference to Fig. 8, the client may initiate an update request in an initiation step 132. The server 32 may handle an update request by starting to determine the client identifier (CID) 37 of the requesting client in a determining step 134. The database 34 may then be then scanned in a scanning step 136 for context keys CKs 36 owned by the requesting client 24, 25 or 26. For each of the CKs 36 the server 32 checks if any services linked to that CK 36 have been updated 138 since the clients last update request. For each updated CK 36, the server builds a list of what services (SIDs) have been updated. The complete list of updates may then be returned in a returning step 140 to the client and the clients update status may be reset so that the next update request will only return what was changed since this update request . While the present invention has been described in accordance with preferred compositions and embodiments, it is to be understood that certain substitutions and alterations may be made thereto without departing from the spirit and scope of the following claims.

Claims

Claims :

1. A method for providing content-related services to users of client devices, comprising: a client software (27) running on any number of client devices (24, 25, 26); all client devices being in communication with a common server (32), or a network of computers providing a server-like functionality; each client device (24, 25, 26) having any number of files, texts and data items (20); and a server (32), or network of computers, providing services (30, 31) via the client software (27), related to specific files, texts and data (20) residing on any or all of the client devices (24, 25, 26) .

2. The method according to claim 1 wherein services are shared between a first client device (24) and a second client device

(25) as a result of both the first and second client devices having the same file or text (20) and running the client software (27) .

3. The method according to claim 2 wherein the method further comprises the client software (27) analyzing a file (20) and generating an identifying key (22) based on contents of the file (20) .

4. The method according to claim 3 wherein the method further comprises the client device (24) sending the identifying key (22) to the server (32) that generates a shorter key (36) which is then associated with the original key (22) and thus identifies the first file (20) .

5. The method according to claim 4 wherein the method further comprises the server (32) sending the shorter key (36) to the client software (27) in the client device (24) .

6. The method according to claim 3 wherein the method further comprises the client software (27) of the client device (24) sending a content identifying key (22 or 36) to the server (32) in order to receive a location of a service related to the file, text or data (20) associated with the content identifying key.

7. The method according to claim 6 wherein the method further comprises the server (32) generating a uniform resource locator (url) and returning the url to the client device (24) as a location of a service.

8. The method according to claim 7 wherein the method further comprises the client device (24) accessing the service at a url with a web browser.

9. The method according to claim 3 wherein the method further comprises the client software (27) automatically scanning the client device (24) for files, text and data, and generating identifying keys for each file found.