Proving file ownership

A robust digital fingerprint of a file ensures that one able to produce the robust digital fingerprint has possession of the file. A client obtains information that is unpredictable to the client and uses that information to modify the file and generate a robust digital fingerprint from the modified file. A server, with access to the same unpredictable information, verifies the generated robust digital fingerprint. An algorithm for generating the robust digital fingerprint has a property that different representations of the same content will produce matching digital fingerprints.

BACKGROUND

With the growing popularity of digital music and other media, various services have emerged accordingly. In the past, media enjoyment generally required a broadcast station or physical possession of a media file, such as on a vinyl record, cassette tape, compact disk, hard drive or other such medium. Various services, however, have emerged where media is provided as a service to provide substantial variety in how media is consumed. Users, for example, are able to stream media to mobile and other devices without those devices needing to store a local copy of the media. Some services are configured to act as extensions of users' personal media libraries. For example, some services are configured to allow users to prove ownership of media files to obtain access to additional services in connection with those media files. A user may, for instance, prove ownership of a media file to gain the ability to stream that media file from a server to a device, thereby removing the need to have a local copy of the media file present to enjoy the media file.

Conventional techniques for proving ownership of media files, however, have numerous drawbacks. For instance, some techniques for proving ownership of media files utilize information generated from the audio files as proof of ownership. Such information, however, is often easily transferable to other users who may present the information without having the audio files themselves. As another example, media files encoding the same media may vary greatly. The same music track, for instance, may be encoded at different bitrates, resulting in different information being stored and, consequently, information generated from the media file (e.g., a hash) to vary among different copies of the same media. Even information outside of the media itself (e.g., metadata) may cause different information to be generated for different copies of the same media.

DETAILED DESCRIPTION

Techniques described and suggested herein include systems and methods for securely proving ownership of audio and other files. In an embodiment, a service provider enables a customer to prove ownership of audio files by first providing a random number or information that is unpredictable to the customer. The customer may segment a media file to generate an ordered plurality of segments. For example, the audio file may be segmented into one-second portions of the audio file. The customer may then use the random number to determine a permutation of the segments. The permutation may be determined in a manner resulting in the properties that different random numbers result in different permutations and the customer cannot determine the permutation without the random number.

Once the permutation has been determined, the customer may apply the permutation to the ordered plurality of segments, thereby obtaining another ordered plurality of segments. The other ordered plurality of segments may then be used to construct another version of the audio portion of the audio file. An audio fingerprinting algorithm may be used to analyze the constructed other version of the audio portion of the file to determine an audio fingerprint of the audio. The audio fingerprinting algorithm may be configured to be unaffected by small variations that may occur in different copies of the audio. For example, the audio fingerprinting algorithm may utilize spectral analysis and be configured such that small variations in the audio file do not affect the resulting audio fingerprints. As an illustrative example, the audio fingerprinting algorithm may be configured such that, for a range of bitrates, audio recorded at different bitrates will result in the same audio fingerprint regardless of bitrate.

The customer may provide the audio fingerprint to the server to assert ownership of the corresponding audio file. The service provider, having recorded the random number, may access its own copy of the audio file, segment the audio portion of the audio file, reconstruct the segments to generate other audio, and compute an audio fingerprint of the reconstructed other audio in the same manner as computed by the customer. The service provider may then compare the audio fingerprint it generated itself with the audio fingerprint provided by the customer to determine if there is a match (e.g., if the two audio fingerprints are the same). If the service provider determines that there is a match, the service provider may enable consumption of one or more services in connection with the audio file. For instance, the service provider may enable the customer to stream the audio file to allow the customer to listen to the audio without having a local copy of the audio stored.

Numerous variations are considered as being within the scope of the present disclosure. For example, some audio fingerprinting algorithms include segmentation of audio. The segmentation of the audio may be performed so that the segments may be used for performance of an audio fingerprinting algorithm. In other words, the segments determined by performance of the audio fingerprinting algorithm may be permuted using the random number as part of the algorithm itself. In this manner, efficiency is gained as a single segmentation may be used both to permute the audio segments and to determine the fingerprints, obviating the need to determine an additional segmentation. As another example, the random number may also be used to combine the audio fingerprinting with additional operations, thereby creating a synergistic effect. As an illustrative example, the random number may be used to determine what information a customer provides as part of authentication for a system that utilizes the audio fingerprint. A user may have, for example, numerous possibilities of information to be provided for authentication and the random number may enable selection of some of the information usable for authentication. Other variations, some of which are described below, are also considered as being within the scope of the present disclosure.

FIG. 1shows a diagram100illustrating various aspects of the present disclosure. As shown inFIG. 1a music file102is combined with random information104and input into a fingerprint calculator106. The music file102may be, for example, an MP3 file or other encoding of digital music. Further, while the present disclosure uses music files for the purpose of illustration, and as discussed in more detail below, the techniques described herein are applicable to other types of information, including other types of media files and other encodings of content. The fingerprint calculator106may be a programming module configured to cause a computer system executing the programming module to utilize the music file102and the random information104to generate an acoustic fingerprint108(also referred to as simply a “fingerprint”) of the music file102.

The fingerprint calculator106may utilize a fingerprinting algorithm such as noted above and discussed in more detail below to generate the fingerprint108. Examples of fingerprinting algorithms include, but are not limited to, algorithms utilized by All Media Guide's LASSO service, Audible Magic Corporation, BMAT Vericast, Midomi, Moodagent, SoundHound, Shazam, Broadcasting Airplay System, Last.fm, and Tunatic. Others include, but are not limited to, AudioID, Broadcasting Airplay System (BAS), Trax IT, YouTube's Content ID, AudioPrint, Gracenote's MusicID, MusicBrainz, AcoustID and Echoprint. All such algorithms mentioned explicitly in the present disclosure are incorporated herein by reference. Further, as noted, fingerprinting algorithms for other types of content (e.g., video, electronic books, and other content) are also considered as being within the scope of the present disclosure, and techniques described herein in connection with audio may be adapted to other types of content.

The fingerprint108may be information that digitally summarizes audio encoded by the audio file102in a deterministic manner. In other words, the fingerprint108may be information that is dependent on the audio signal from which the fingerprint108was determined. The algorithm may have various properties such as described above and in more detail below such as properties that cause the same fingerprint108to be generated regardless of minor changes to the audio file102and different types of encodings of the same audio signal or of similar audio signals, especially changes that insignificantly change the audio file102or that do not change the audio encoded by the audio file102such as changes to metadata of the audio file102.

The fingerprint108output by the fingerprint calculator106may be provided to a music service110. The music service110may be a music system operated to provide one or more services related to music. As an illustrative example, the music service may provide music streaming services to enable users to listen to music from their corresponding devices without having to have a persistently stored copy of that music on their devices. While such services are provided for the purpose of illustration, variations are considered as being within the scope of the present disclosure. For instance, techniques described herein are applicable to any type of service whose operation is dependent on fingerprints provided to the service, such as services whose level of access is dependent on the ability to provide fingerprints in accordance with the various techniques discussed herein.

FIG. 2shows an illustrative example of an environment200in which various embodiments may be practiced. As illustrated inFIG. 2the environment200includes a customer202that communicates over a network204with a service provider front end206. With reference toFIG. 2and other figures of the present disclosure, the term “customer” is used interchangeably with a device used by a human customer. As such, a customer may also be referred to as a “client.” The customer may communicate over the network to access a service provided by a service provider where the service provider operates the service provider front end206. InFIG. 2the customer202is illustrated as a laptop (notebook) computer, although other devices are also considered as being within the scope of the present disclosure including devices discussed below. Generally, any computing device operable to perform calculations in accordance with the various techniques described herein is considered as being within the scope of the present disclosure.

The network204may be any suitable network over which information may be transmitted between the customer202and the service provider front end206. As an example, the network204may be the Internet. The network204also may be a combination of various different networks such as the Internet and one or more mobile communications networks. Generally, any network or combination of networks may be used to transmit data between customer202and the service provider front end206. Further, it should also be noted that in some embodiments communication over a network is not necessary such as when the customer202and service provider front end206are directly connected to one another or when information is transferred in ways that don't include a network, such as by transferring a computer-readable storage medium from one computer to the other.

The service provider front end206may be a computer system operated by a service provider for the purpose of providing an interface to customers of a service provided by the service provider. As an illustrative example, the service provider front end206may be a webserver such as described below. It should be noted at the service provider front end206may also be a distributed computer system comprising multiple server computer systems that collectively operate to provide services of the service provider and, generally, that computer systems may be single devices or distributed systems. Information transmitted between the customer202and the service provider front end206includes, but is not limited to, fingerprints transmitted from the customer202to the service provider front end206and information provided as part of consumption of the services provided by the service provider such as requests from the customer202to access services of the service provider and information such as information encoding audio from the service provider to the customer202.

To provide the various services of the service provider, the service provider may have an additional service provider back end208which may be a computer system (in many embodiments a distributed computer system) configured to provide services of the service provider and to employ various techniques described herein as part of providing the services. The service provider back end208may, for example, comprise one or more application servers such as described below. As part of providing its services to its customers, the service provider back end208may include various data stores that store information related to the services and its customers. As an illustrative example and as shown inFIG. 2, the service provider back end208may include a music database210and a music ownership database212.

In an embodiment, the music database210associates audio recording with various data about those audio recordings including acoustic fingerprints for the audio recordings. Generally, the music database210contains information that is used in generating reference acoustic fingerprints. In the example shown inFIG. 2, the music database210may utilize a table schema214in which a column represents identifiers of songs (referred to in the drawing as SongID) and another column for the music data. The music data may be an encoding of an audio signal for a corresponding audio recording. The music data may be, for example, a music file. In some embodiments, the music data is in a format that is suitable for input into an algorithm that generates acoustic fingerprints, which may differ from a format in which the same recording is available in an electronic or other marketplace. For example, the music data for a recording may comprise a 16 kbps WAV file, whereas audio files encoding higher bitrates may be more commonly consumed. The music data may also include other information, such as metadata about the audio recording including metadata about an artist associated with the audio recording, publishing information about the audio recording, licensing information about the audio recording, and other information. It should be noted that the schema214and other schemas described herein are provided as examples, and other schemas and ways of storing data in association with other data are also considered as being within the scope of the present disclosure.

The service provider back end208may utilize the music database210to determine whether fingerprints provided by the customer202to the service provider front end206match. The service provider back end208may utilize the music database210to determine whether an acoustic fingerprint provided by the customer202to the service provider through the service provider front end206(a purported acoustic fingerprint which, when applying to embodiments that are not necessarily limited to audio, may generally be referred to as a purported robust digital fingerprint) is valid. A purported acoustic fingerprint may be valid on a condition that the fingerprint matches an acoustic fingerprint generated by the service provider back end208based at least in part on the music data for a respective audio recording.

The music ownership database212may be a database that enables the service provider to track ownership of recordings by its various customers. Generally, the music ownership database212may enable the service provider back end to track recordings that customers have proven possession of, such as by utilizing techniques described herein or in other ways such as by purchasing audio recordings from the service provider. It should be noted that the term “ownership,” of content unless otherwise modified or clear from context, is intended to be broad, encompassing generally the right and/or ability to consume (e.g., listen to an audio recording and/or watch a video) the corresponding content and, in some embodiments, a right is not an exclusive right. For example, a customer may be said to “own” a particular recording if the customer has access to a copy of the recording, either locally, or in a remote storage location accessible to the customer. It should be noted, however, that the techniques described herein are applicable to embodiments where entities can prove exclusive ownership of a particular instance of content, such as when the techniques described herein are combined with digital rights management techniques, such as digital watermarks.

Returning to the illustrated example, the music ownership database212may be updated by the service provider back end208in various ways. For example, when a customer202proves, through various techniques described herein, possession of an audio recording, service provider back end208may update the music ownership database212accordingly. Similarly if the customer202purchases rights to an audio recording through an interface provided by service provider front end206, the service provider back end208may update the music ownership database212as a result of the purchase and without the customer202having to separately prove possession of the audio recording.

As illustrated inFIG. 2the music ownership database212may utilize a schema216that associates customers by customer identifiers with various recordings (files) for which the customers have proven possession. Each row in the music ownership database212may, for example, include a list of identifiers (SongIDs) of audio recordings for which the corresponding customer has proven ownership of or otherwise gained access to. As with the music database210, the schema216is provided for the purpose of illustration and other schemas and ways of storing data in association with other data are also considered as being within the scope of the present disclosure. For a customer, the music database210may include identifiers for audio recordings for which customer has proven ownership. In some embodiments, a single identifier may correspond to multiple versions of the same recording (e.g., multiple encodings with different bitrates and/or in different formats) although the scope of the present disclosure includes embodiments where identifiers are used at a finer granularity (e.g., different identifiers for different bitrate encodings of the same audio signal).

FIG. 3shows an illustrative example of a diagram showing a flow of information in accordance with an embodiment. In this example, the flow of information involves a customer302, a music ownership verification server304, a music database306, and a music ownership database308. The customer302may be, for example, the customer202described above in connection withFIG. 2. The music ownership verification server304may be a server computer system operating as part of either the service provider front end206or the service provider back end208depending on the particular computing architecture in which a service provider has configured its systems. It should be noted that whileFIG. 3shows the customer302communicating directly with the music ownership verification server304, such communications may be indirect such as when the music ownership verification server304is part of the service provider back end system and the customer302communicates through a server of a front end system of the service provider. The music database306and music ownership database308may be such as described above in connection withFIG. 2.

Turning to the specifics illustrated inFIG. 3, in an embodiment, the customer302transmits a request to prove file ownership to the music ownership verification server304. The request may be transmitted302as part of a user's interaction with the interface provided by the music ownership verification server304where the interface may be, for example, a website or a mobile application. The request may be transmitted as a result, for example, of a user having indicated to the interface a desire to access one or more services of the service provider. The request may be transmitted in accordance with various protocols such as described above including, but not limited to, hypertext transfer protocol (HTTP).

In response to proof of file ownership the music ownership verification server304provides to the customer302unpredictable information. The unpredictable information may be information that the customer302is unable to deterministically determine until received from the music ownership verification server304. As a result, the unpredictable information may be or otherwise comprise a random number generated by the music ownership verification server304or another computer system. Generally, the unpredictable information may be any information the customer302is unable to determine without having been provided the information. Other examples include values from a set of preselected values selected by the music ownership verification server304for other information. Further, in some embodiments, the customer302generates the unpredictable information itself. For example, the customer may execute code in a secure execution environment (e.g., a trusted platform module (TPM), an enclave of a Secure Guard Extensions (SGX)-enabled processor, or an ARM trust zone) and, as a result, generate unpredictable information (e.g., a random number) and information (e.g., a digitally signed certificate) that cryptographically proves that the code was executed in the secure execution environment. For example, a customer302or other system may execute code to generate the unpredictable information and use remote attestation to prove that the code was executed in an unmodified state. Proof may include other information, such as a timestamp, that can be verified and to which policy may be applied by a server verifying fingerprints (e.g., to determine that the generated fingerprint was generated in a sufficiently contemporaneous manner).

Using the unpredictable information, the customer302may calculate one or more fingerprints. In some examples, the customer302is requesting to prove file ownership for a batch of files. As an example, the customer302may communicate with the music ownership verification server302for the purpose of proving ownership of a library of audio recordings (e.g., a collection of mp3 files). The flow of information illustrated inFIG. 3, however, may also be performed for a single recording. Once the customer302has calculated the one or more fingerprints, the one or more fingerprints may then be provided by the customer302to the music ownership verification server304.

The music ownership verification server304may query the music database306to obtain music data for the files associated with the one or more fingerprints provided by the customer302. The music data may be or otherwise comprise, as discussed, encodings of audio such as MP3 files. The music database306may provide the music data in response to the query from the music ownership verification server304. The music ownership verification server304may then use the music data and the unpredictable information provided to the customer302to calculate one or more reference fingerprints and may verify whether the one or more fingerprints provided by the customer302match the one or more calculated reference fingerprints calculated by the music ownership verification server304.

After determining that the one or more fingerprints provided by the customer302match the one or more reference fingerprints calculated by the music ownership verification server304, the music ownership verification server304may transmit one or more communications to the music ownership database308to cause the music ownership database308to indicate ownership of the recordings associated with the fingerprints provided by the customer302.

Numerous variations are considered as being within the scope of the present disclosure. For instance, operations additional to those illustrated inFIG. 3may be performed. In some embodiments, the music ownership verification server304or another server of the same distributed system requires authentication by the customer302before being allowed to prove ownership of music files and/or otherwise accessing services. Additionally, communications between the customer302and a service provider with the music ownership verification server304may be encrypted, such as by using a secure sockets layer (SSL) or transport layer security (TSL) connection. In some embodiments, if some but not all fingerprints provided by the customer302match the reference fingerprints calculated by the music ownership verification server304, the music ownership database308may be updated only for those recordings associated with fingerprints that matched. As another example of a variation considered as being within the scope of the present disclosure, the music ownership verification server may query the music finger database306and begin calculation of the one or more reference fingerprints before the customer302provides the fingerprints. In this manner, the music ownership verification server304can more quickly determine if there is a match and whether the music ownership database308should be updated. As yet another example of variation considered as being within the scope of the present disclosure, operations performed by the music ownership verification server may be performed by different computer systems of a service provider. For example, the unpredictable information may be generated by and/or provided by a first server, and the reference fingerprints may be calculated by another server. Other variations are also considered as being within the scope of the present disclosure, including but not limited to, variations discussed above and below.

In various embodiments information unpredictable to a customer is used to modify an encoding of an audio signal to generate a fingerprint that corresponds to the information that is unpredictable.FIG. 4shows a diagram illustrating one example of a way by which unpredictable information may be used to modify an encoding of an audio signal such as an encoding of an audio signal in an MP3 file. In the diagram400an encoded audio signal402is obtained. The encoding may be, for example, a 16 kbps WAV file or other encoding of an audio signal that is suitable for being input into an acoustic fingerprinting algorithm.

The encoded audio signal402may be segmented to create a plurality of audio segments. Each audio segment may correspond to a duration of the audio signal of a specified amount of time. For example, each audio segment may correspond to one second of the audio signal or a longer duration. In some embodiments, the length of each segment may depend on the length of the audio signal. For example, longer audio signals may have longer individual segments although, in some embodiments, segment size is not dependent from the length of the audio signal. In this example, the audio segments for the purpose of illustration are labeled A through J. The audio segments are also enumerated 0 through 9, representing an initial slotting of the audio segments in slots represented by the numerals 0 through 9.

In an embodiment, information unpredictable to a client is a random number. In this example, the random number is 31,415,926. The random number may be used to determine a permutation of the segment of the encoded audio signal402. As noted, the numbers 0 through 9 in this example may be considered slots into which audio segments may be moved in and out of Thus the initial encoded audio signal402has the audio segment labeled A being in the0slot, the audio segment labeled B in the first slot (i.e., the slot labeled “1” and not the initial slot preceding all others), and audio segment labeled C in the second slot (labeled “2”), and so on. With the random number 31,415,926, the audio segment in the third slot is moved to the first slot, as indicated by the first digit of the random number being “3” and the next digit being “1.” Generally, in this example, the first of two consecutive digits in the random number indicates an origin from which a segment is taken and the second of the consecutive digits indicates a destination slot to which the segment is moved. For the last digit representing the source slot, the destination is represented by the first digit. When a segment gets moved to a slot, the segment that was in that slot gets moved in accordance with the random number.

In this example, therefore, the audio segment labeled as D gets moved to the first slot. The audio segment in the first slot gets moved to the fourth slot (slot labeled “4”). In this example, the audio segment labeled B gets moved to the fourth slot. Continuing with the permutation, the audio segment in the fourth slot gets moved to the first slot. The audio segment in the first slot gets moved to the sixth slot. The audio segment in the fifth slot gets moved to the ninth slot. The audio segment in the ninth slot gets moved to the second slot. The audio segment in the second slot gets moved to the sixth slot. The audio segment in the sixth slot gets moved to the third slot, which completes the permutation in this particular example. As a result of performing this permutation, the audio segments are ordered as A, E, J, G, B, D, C, H, I, F. It should be noted that, because the random number did not include a 0, the audio segment in the zero-eth slot (slot labeled “0”), which is labeled A in this example, did not move and therefore remained in the zero-eth slot in the permuted encoded audio signal404.

It should also be noted thatFIG. 4is provided for the purpose of illustration of one way a random number may be used to generate a permutation, and variations are considered as being within the scope of the present disclosure. Generally, any non-trivial mapping of information to a permutation may be used. For example, in some embodiments, encoded audio signals always have a uniform number of segments although, in other embodiments, encoded audio signals may have a number of segments that varies from one encoded audio signal to another (e.g., where the number of segments depends from the length of the encoded audio signal). The digits of a random number may be selected so as to account for there being more than 10 segments. As an illustrated example for numbers of audio segments up to 100, pairs of digits in the random number therefore may be used in the permutation.

In examples where the number of slots is less than the number of segments, various techniques may be used. For example, if there are 100 slots but an encoded audio signal only has 90 segments, 10 slots will remain empty after the permutation. The empty slots may be discarded and the remaining audio segments may be concatenated. As another example, the empty slots may simply be filled with an audio signal corresponding to silence or corresponding to a predetermined sound or signal for that segment. Other variations are also considered as being within the scope of the present disclosure, including other ways of generating permutations from random information.

In addition to the above, different modifications to an encoding of an audio signal may be used in addition to or instead of permutations. For example, information unpredictable to the client may be used to modify one or more characteristics of the encoding, such as bitrate, tone, and other characteristics of the encoding. The information unpredictable to the client may be used to indicate which portions (e.g., segments) of an encoding of an audio signal are to be modified and how the modifications are to be performed. Generally, the scope of the present disclosure extends to numerous embodiments where information unpredictable to a client is used to instruct the client how to modify an encoding of data in a way that results in a robust digital fingerprint, and such embodiments may or may not utilize permutations of segments of data.

FIG. 5shows an illustrative example of a process for generating an acoustic fingerprint in accordance with an embodiment. The process500may be performed by any suitable system such as by a client computer system of a customer of a service provider to prove ownership of an audio recording or by a server of a service provider to generate a reference audio fingerprint for comparison with an acoustic fingerprint provided by the customer. In an embodiment the process500includes obtaining502an encoded audio signal. The encoded audio signal may be obtained in various ways in accordance with various embodiments. In some examples the encoded audio signal is a file obtained from local or remote data storage. Obtaining502the encoded audio signal may also include various operations dependent on a source of the encoded audio signal. For example, obtaining502the encoded audio signal may include translating information from one format to another. For example, information contained in an MP3 file may be converted to a WAV file, possibly with a different bitrate, for the purpose of performing the process500. Further, the encoded audio signal may be obtained in a manner that results in an encoded audio signal that is usable by a fingerprinting algorithm to be utilized in performance of the process500.

In an embodiment the process500includes determining504a permutation of the encoded audio signal. The permutation may be determined, for example, by generating, receiving, or otherwise obtaining random information such as described above and utilizing that random information to determine the permutation. Further, the process500may include determining audio segments from the encoded audio signal. In an embodiment, the encoded audio signal is segmented into audio segments of equal size except perhaps for a terminal audio segment if the length of the encoded audio signal is not exactly equal to an integer multiple of a uniform segment size. In some examples, the audio segments are of uniform size while in other embodiments the sizes of the audio segments may vary in accordance with various embodiments. In some embodiments information unpredictable to a customer is used to determine sizes of audio segments for segmentation of the encoded audio signal. Referring toFIG. 4, for example, digits obtained from the random number may be used to determine audio segment sizes. As one illustrative example, the first segment may have a size of three seconds, the second segment may have a size of one second, the third segment may have a size of four seconds, the fourth segment may have a size of one second, the fifth segment may have a size of five seconds, and so on. One random number may be used for determining a permutation while another random number may be used for segment size. Other variations are also considered as being within the scope of the present disclosure.

Returning to the particular embodiment illustrated inFIG. 5the process500may include applying508, a permutation to the audio segment such as described in above in connection withFIG. 4. As a result of applying508the permutation to the audio segment a permutated encoded audio signal is generated. A fingerprinting algorithm may then be performed510to determine an acoustic fingerprint of the permutated encoded audio signal which serves as a fingerprint of the encoded audio signal corresponding to the unpredictable information used to determine the permutation and/or otherwise used to determine how to transform the encoded audio signal.

Numerous additional variations of the process500are considered as being within the scope of the present disclosure including variations discussed above. In addition operations illustrated as being performed in a particular order as with all processes described herein unless otherwise clear from context may be performed in another order. For example, determination of the audio segments may occur before determination of the permutation.

FIG. 6shows an illustrative example of a process for determining an acoustic fingerprint in accordance with an embodiment. In many respects the process600is similar to the process described above inFIG. 5and accordingly may be performed by any suitable system, including systems discussed as able to perform the process500discussed above. As illustrated inFIG. 6however techniques described above are more fully incorporated into an algorithm for determining an acoustic fingerprint. In particular, many acoustic fingerprinting algorithms segment encoded audio signal as part of their operation. The process600ofFIG. 6includes utilizing that segmentation in a way that provides advantages discussed above. In an embodiment the process600includes obtaining602an encoded audio signal such as described above in connection withFIG. 5. Further, a permutation may also be determined604such as described above. A fingerprinting algorithm may begin606and, as part of performance of the fingerprinting algorithm, the process600may include determining608audio segments.

The permutation that was determined604may be applied610to those audio segments, and the fingerprinting algorithm may be completed612. In this manner performance of the process600provides at least a technical advantage of efficiency as the segmentation of the fingerprinting algorithm is used, thereby avoiding segmenting an encoded audio signal twice to determine an acoustic fingerprint. In other words, the fingerprint may be calculated without resegmenting the modified encoding of the audio signal.

As noted above, various techniques described herein are usable by a service provider to obtain stronger assurances that customers purporting to have ownership of audio recordings actually do have such ownership.FIG. 7shows an illustrative example of a process700for utilizing techniques described herein for providing a service and more specifically for updating a music ownership data base such as described above. The process700may be performed by any suitable system such as by a music ownership verification server such as described above in connection withFIG. 3or any server of a service provider that the service provider has configured to perform this process. In an embodiment the process700includes receiving702, a request to prove ownership of one or more audio files from a client. The client may be, for example, a computer system associated with a customer of a service provider which may operate in accordance with a client application such as a web browser or an application on a mobile device.

To respond to a request, a system performing the process700may determine704information unpredictable to the client. In some embodiments the information unpredictable to the client is a set of random numbers which may be a single random number or multiple random numbers. It should be noted that the information unpredictable to the client may be other information, such as described above. Determining the information unpredictable to the client may include generating the information unpredictable to the client and accessing the information unpredictable to the client from local or a remote data storage by contacting a service that provides such information or otherwise. In some embodiments, a different instance of information unpredictable to the client (e.g., a different random number) is determined for each recording the client is to prove ownership of, although the same information may be used for multiple different recordings.

The information unpredictable to the client may be provided706to the client to enable the client to generate an acoustic fingerprint for each audio recording for which the client has requested to prove ownership. Accordingly, the process700may include receiving708one or more acoustic fingerprints from the client. The one or more acoustic fingerprints may be received708in one or more claims of possession from the client, where a claim of possession may be a structured collection of information that specifies an acoustic fingerprint and an identifier for an audio signal purportedly corresponding to the acoustic fingerprint. The acoustic fingerprints may be received, for example, over a network in the same manner by which the request was received702. The information unpredictable to the client may be used710to generate a set of reference fingerprints for checking one or more fingerprints received708from the client. It should be noted that, whileFIG. 7shows the information unpredictable to the client being used710to generate a set of reference fingerprints after having received708one or more fingerprints from the client, the system performing the process700may use the information unpredictable to the client to generate the set of reference fingerprints at an earlier time. In some embodiments the system performing the process700or another system generates the set of reference fingerprints using the information unpredictable to the client before the request is received702from the client. For example, random numbers may be pre-generated and used to regenerate acoustic fingerprints for the random numbers and the acoustic fingerprints may be stored.

Returning to the embodiment illustrated inFIG. 7, the process700may include comparing712the first received fingerprint to its corresponding reference fingerprint. The comparison may be made, for example, by determining whether the fingerprint received from the client matches the corresponding reference fingerprint by being equal to the corresponding reference fingerprint. It should be noted, however, that a reference fingerprint may match another acoustic fingerprint without necessarily being equal to the other acoustic fingerprint. A determination may be made714whether the received fingerprint matches the reference fingerprint. If it is determined714that the received fingerprint matches the reference fingerprint, the process700may include updating716a music ownership data base to indicate such ownership. One or more records corresponding to the client may, for example, be updated to indicate ownership.

If however it is determined714that the received fingerprint does not match the referenced fingerprint, the process700may include determining718whether there are additional fingerprints to check. If it is determined718that there are additional fingerprints to check, the process700may include comparing the next received fingerprint to its corresponding reference fingerprint determining whether the received fingerprint matches its corresponding reference fingerprint and updating or not updating the music ownership database accordingly. This process may repeat until it is determined718that there are no additional fingerprints. At this time, an indication of ownership verification may be provided720to the client. The indication of ownership verification may include information that indicates to the client how performance of the process700was completed. For example, if all acoustic fingerprints matched, the indication of ownership verification may indicate such a match. If one or more fingerprints provided by the client did not match the indication of ownership, verification may indicate recordings for which fingerprints did not match and may enable the client to perform corresponding operations such as by providing fingerprints again or otherwise proceeding.

As with all processes described herein, variations are considered as being within the scope of the present disclosure. For example,FIG. 7shows a process by which a set of fingerprints are sequentially checked. A variation of the process700includes a variation where some or all verifications are performed in parallel by other systems. For example, for a large set of acoustic fingerprints, subsets of a set of acoustic fingerprints may be set to different computer systems to enable the other computer systems to verify whether the acoustic fingerprints provided by the client are valid. As noted above, a service provider may also pre-generate acoustic fingerprints for audio files before a request to prove ownership is received.

Other variations are also considered as being within the scope of the present disclosure including variations where the techniques described herein are used with other techniques such as authentication. For example, in some embodiments, information unpredictable to the client is additionally used for authentication as well as proof of ownership. A user may, for example, have information corresponding to the user and information unpredictable to the client may be presented to the user in a manner that enables the user to demonstrate possession of the information corresponding to the user. The information unpredictable to the client may, for example, be used to instruct the user which portions of the information corresponding to the user to provide back (via user input into a user device). Such information may be maintained as a secret shared between the customer and the service provider. As an illustrative example, a user may have a set of information that is unique to the user or that is not shared among a large number of users. The information may be, for example, a grid of numbers, letters, or other information (e.g., pictures). Information unpredictable to the client may be used to generate a set of coordinates for which the user is to select corresponding values and/or an order of selection. A user may provide to his or her corresponding computer system through user input the corresponding values in order to prove the user's identity. A user without instructions corresponding to the information unpredictable to the client would not, other than by chance, be able to provide the information back to the server in a proper form. The server can use the same instructions to generate reference information that can be compared with that which was provided by the user. Generally, information unpredictable to the client in addition to being used to determine how to transfer an encoded audio signal may be used to indicate to a user's computer system how to authenticate.

Other variations are also considered as being within the scope of the present disclosure. For instance, as noted, while audio is used throughout for the purpose of illustration, the techniques discussed above are adaptable to other encodings of information. Techniques for generating acoustic fingerprints may be adapted to, for example, general robust digital fingerprints (of which acoustic fingerprints are an example). A robust digital fingerprint may be a digest of an instance of content (e.g., audio, video, text and or other types of content and combinations of types of content, which is not necessarily media content renderable for human consumption) calculated using an algorithm having the properties that performance of the algorithm on different digital representations of an instance of content result in the same calculated robust digital fingerprint and that performance of the algorithm on different instances of content result in different robust digital fingerprints. For example, a property of a robust digital fingerprint may be that there is a first set of changes to the digital representation of the instance of content that, if made, would result in the same reference robust digital fingerprint and such that there is a second set of changes to the digital representation that, if made, would result in a different robust digital fingerprint. With acoustic fingerprints, for instance, there is a set of bitrates of an audio recording that result in the same acoustic fingerprint, but reducing the bitrate too much may result in a different acoustic fingerprint. With video files, there may be ranges of audio resolution and video resolution within which an algorithm for calculating a robust digital fingerprint results in the same calculated robust digital fingerprint. A robust digital fingerprint may have other properties, such as the inability to obtain an instance of content from its robust digital fingerprint.

The data store810can include several separate data tables, databases, data documents, dynamic data storage schemes and/or other data storage mechanisms and media for storing data relating to a particular aspect of the present disclosure. For example, the data store illustrated may include mechanisms for storing production data812and user information816, which can be used to serve content for the production side. The data store also is shown to include a mechanism for storing log data814, which can be used for reporting, analysis or other such purposes. It should be understood that there can be many other aspects that may need to be stored in the data store, such as page image information and access rights information, which can be stored in any of the above listed mechanisms as appropriate or in additional mechanisms in the data store810. The data store810is operable, through logic associated therewith, to receive instructions from the application server808and obtain, update or otherwise process data in response thereto. The application server808may provide static, dynamic or a combination of static and dynamic data in response to the received instructions. Dynamic data, such as data used in web logs (blogs), shopping applications, news services and other such applications may be generated by server-side structured languages as described herein or may be provided by a content management system (“CMS”) operating on, or under the control of, the application server. In one example, a user, through a device operated by the user, might submit a search request for a certain type of item. In this case, the data store might access the user information to verify the identity of the user and can access the catalog detail information to obtain information about items of that type. The information then can be returned to the user, such as in a results listing on a web page that the user is able to view via a browser on the user device802. Information for a particular item of interest can be viewed in a dedicated page or window of the browser. It should be noted, however, that embodiments of the present disclosure are not necessarily limited to the context of web pages, but may be more generally applicable to processing requests in general, where the requests are not necessarily requests for content.