This application claims benefit under 35 U.S.C. §119(e) from U.S. Provisional Patent application No. 61/406,857, filed on Oct. 26, 2010, the entirety of which is incorporated by reference herein.
The present invention generally relates to systems and methods for lending digital content items, and more particularly to systems and methods for lending digital content items using a contact list or social networks.
Publishers have legitimate business and legal concerns regarding digital content lending systems. Unlike paper copies of their book content, copies of digital content are relatively easy to make and very easy to distribute. To meet business concerns, publishers require that a lending system ensures that only one user at a time has access to the ebook content purchased by a user. To meet legal concerns, publishers require that a lending system does not permit the duplication of multiple copies of ebook content in violation of copyright law.
There are library-based lending systems in use that allow an ebook to be lent from a library to a patron of the library (see for example the ebook lending system at the New York Public Library (ebooks.nypl.org)). A library-based lending system is not a consumer-to-consumer lending system and differs in several significant regards. In a library lending system, a library patron submits a request to the library for a book contained in the library. The requests for books are always between patrons and the library system itself. There is no lending between patrons of the library system. Current library-based lending systems do not have the technical capability to facilitate a lending process directly between one user and another user.
U.S. Pat. No. 6,901,386 describes a system by which corporations or other entities can manage their licenses to electronic assets, e.g., software. As is well known, software licenses, particularly licenses to enterprise software, can be very expensive. Corporations are therefore always looking for ways to maximize the use of their licenses across the organization. In the system described in this patent, the owner of a current license to an electronic asset “releases” its license to the license management system. This released license can be re-assigned other users in the organization.
U.S. Pat. No. 7,054,840 describes a clearinghouse for rights in digital material. If a user decides to sell or otherwise transfer her rights to some digital material, she transfers her rights to a clearinghouse server which posts the digital material as being for sale or other transfer. When a buyer or borrower sees the posting, he can buy or borrow the material through the clearinghouse.
U.S. Patent Publication US 2006/10543134 describes a licensing system in which a request for a license is received either directly from a borrower or indirectly through a licensing authority.
None of these systems of the prior art describe a consumer to consumer lending system that provides the technical safeguards required by authors and publishers to ensure unauthorized copies are not made. Further none of them teach a system in which a user's electronically stored contacts facilitate the lending and borrowing of digital content.
The lending system of the present invention enables a user to employ her contact list to facilitate the lending and borrowing of digital content. In a preferred embodiment, the digital content is electronic books. As a lender, the user can use her contact list to easily identify and send a lending notification to one of her contacts. On the borrowing side, a borrower can use the system to scan the books that her contacts have available for lending and make a lend request.
In order to initiate a loan of digital content, the lender, using her local device, generates a lending offer. The lending offer contains an identification of the lender, an identification of the contact and an identification of the digital content to be lent. Optionally, the lending offer can contain a personal message from the lender to the contact (potential lendee). The identification of the lendee can be the lendee's email address obtained from the lender's contact list. Optionally, it can be a user id at a social network such as a Facebook™. The lending offer is communicated from the lender's local device through a communication channel such as the Internet or a telephone (cellular) network to a server of the present invention. The server processes the lending offer from the lender and generates a lending offer email and, if the potential lendee is an authorized user of the system, a lending notification. The lending offer email is sent by traditional email methods, and the lending notification is transmitted to the potential lendee next time he logs connects to the system with his local device. The lending offer email contains a combination of a lending offer ID and an encrypted security hash code that uniquely identifies the lending offer. Similarly, the lending offer notification through the system is linked to the lending offer.
The potential lendee can click on the URL contained in the email or respond to the lending offer notification to accept the loan. The server processes this acceptance by the lendee and transfers the loaned copy of the digital content to the lendee. In a preferred embodiment, both the lending offer and period of loan of the digital content is time limited and expires after a predetermined time.
On the borrowing side, the system of the present invention allows a user to view the digital content, ebooks, that her contacts have available for loan. The user can search by contacts or by a title of a particular book she would like to borrow. If the user finds a book she would like to loan, she can select the contact and the book and her local device generates a loan request. The loan request is processed by the server and forwarded to the contact by email and/or notification. The recipient of the loan request is then able to execute the loan process as described above.
For the purposes of illustrating the present invention, there is shown in the drawings a form which is presently preferred, it being understood however, that the invention is not limited to the precise form shown by the drawing in which:
Associated with the lender's 105 account is the lender's 105 digital locker 120a located on the lending server 150. As further described below, in the preferred embodiment of the present invention, digital locker 120a contains links to copies of digital content 125 previously purchased (or otherwise legally acquired) by lender 105. Some of the digital content 125 purchased by lender 105 is digital content 125 with lending rights. For the digital content 125 with lending rights, lender 105 is allowed to lend lender's 105 copy of digital content 125 to another authorized user of lending system 100.
Indicia of rights to all copies of digital content 125 owned by lender 105, including digital content 125, is stored by reference in digital locker 120a. Digital locker 120a is a remote online repository that is uniquely associated with the lender's 105 account. As appreciated by those skilled in the art, the actual copies of the digital content 125 are not necessarily stored in the user's locker 120a, but rather the locker 120a stores an indication of the rights of the user to the particular content 125 and a link or other reference to the actual digital content 125. Typically, the actual copy of the digital content 125 is stored in another mass storage (not shown). The digital lockers 120 of all of the lenders 105 who have purchased a copy of a particular digital content 125 would point to this copy in mass storage. Of course, back up copies of all digital content 125 are maintained for disaster recovery purposes. Although only one example of digital content 125 is illustrated in this Figure, it is appreciated that the lending server 150 can contain millions of files 125 containing digital content. It is also contemplated that the lending server 150 can actually be comprised of several servers with access to a plurality of storage devices containing digital content 125. As further appreciated by those skilled in the art, in conventional licensing programs, the user does not own the actual copy of the digital content, but has a license to use it. Hereinafter, if reference is made to “owning” the digital content, it is understood what is meant is the license or right to use the content.
Also contained in the lender's digital locker 120a is her address book 121, i.e., her contacts list. As described further below in connection with
Lender 105 can access his or her digital locker 120a using a local device 130a. Local device 130a is an electronic device such as a personal computer, an e-book reader, a smart phone or other electronic device that the lender 105 can use to access the lending server 150. In a preferred embodiment, the local device has been previously associated (registered) with the lender's 105 account using lender's 105 account credentials. Local device 130a provides the capability for lender 105 to download lender's 105 copy of digital content 125 via his or her digital locker 120a. After digital content 125 is downloaded to local device 130a, lender 105 can engage with the downloaded content locally, e.g., read the book, listen to the music or watch the video.
In a preferred embodiment, local device 130a includes a non-browser based device lending interface that allows lender 105 to initiate the lending of digital content 125 to another authorized user of lending system 100 in a non-browser environment. Through the device lending interface, the lender 105 is automatically connected to the lending server 150 in a non-browser based environment. This connection to the lending server is a secure interface and can be through the telephone network 145, typically a cellular network for mobile devices. If lender 105 is accessing his or her digital locker 120a using the Internet 140, local device 130a also includes a web account interface. Web account interface provides lender 105 with browser-based access to his or her account and digital locker 120a over the Internet 140. The web account interface also includes web lending interface similar to the device lending interface of the non-browser embodiment. Web lending interface allows lender 105 to initiate the lending of digital content 125 to another authorized user of lending system 100 in a browser based environment.
Lendee 109 is also preferably an authorized user of lending system 100. As with lender 105, lendee 109 has an account with lending server 150, which authorizes lendee 109 to use lending system 100. Lendee 109 can be the recipient of a loaned copy of digital content 125 from lender 105. Indicia of rights to digital content 125 that is lent to lendee 109 and indicia of rights to any other copies of digital content owned by lendee 109 are stored by reference in her digital locker 120b. As with lender 105, lendee 109 can access his or her digital locker 120b using her local device 130b. In a preferred embodiment, local device 130b is a device that lendee 109 has previously associated (registered) with his or her account using lendee's 109 account credentials. Local device 130b allows lendee 109 to download a copy of loaned digital content 125 from digital locker 120b once the copy of digital content 125 is successfully lent from lender 105. Lendee 109 can engage with downloaded lent digital content 125 locally on local device 130b. Local device 130b also includes a device lending interface. Device lending interface allows lendee 109 to respond to lending offer notifications.
Lendee 109 can also access his or her digital locker 120b using a browser based web account interface. Web account interface provides lendee 109 with browser-based access to his or her account and digital locker 120b over the Internet 140. Web account interface also provides lendee 109 with access to web lending interface. Web lending interface allows lendee 109 to respond to lending offer emails as further described below.
As shown in
Although lender 105 can initiate the lending process from several applications in her local device 130a, a typical place is when the lender 105 is actually viewing particular book 125.
As shown in
Returning to
In the non-browser embodiment, email address 111 is used by the lending server 150 to identify the potential lendee 109 in order to deliver a lending offer notification 113 to lendee 109 on local device 130b. In order to receive lending offer notification 113, lendee 109 must be an authorized user of server 150. The lending offer notification 113 will be received by the lendee 109 the next time she logs onto her account on the lending server 150. Email address 111 is also used to deliver lending offer email 114 directly to lendee's 109 email account. Lending offer email 114 can be sent to either authorized user of lending server 150, or people who have never been affiliated with server 150. Lending offer notification 113 is an alert delivered by lending system 150 to lendee 109 which lendee 109 receives and can respond to using device lending interface in his or her local device 130b. Lending offer email 114 is an email delivered to email address 111 that lendee 109 receives via his or her email system. The lendee 109 can respond to the lending offer email 114 via a Uniform Resource Locator (URL) contained in the email offer 114.
Lending server 150 manages the receipt of the lending offer 110 from lender 105 and initiates the generation and delivery of lending offer notification 113, and lending offer email 114 to lendee 109. Lending server 150 is also capable of receiving lending offers 110 from lender 105 that are intended for a proposed lendee 109 that is not already an authorized user of the system (i.e. proposed lendee does not have an account established on lending server 150). In this embodiment of the present invention, lending server 150 only sends the lending offer email 114 to the proposed lendee. In order to accept the lending offer, the proposed lendee must log onto the system and register with the lending system and thus become an authorized lendee 109. As seen in
Similar to the email lending offer notification process described above, the system 100 of the present invention is able to communicate lending offers via other social networks. For example, if one of lender's 105 contacts is indicated in lender's address book as having a Facebook™ user ID, when the lender 105 selects this lendee to extend a lend offer via Facebook™, the system 100 is capable of creating a feed story on Facebook™ directed at the selected lendee. Prior to making the lending offer, the lendee 105 has authorized the system to act on her behalf when interacting with these social networks. When the lendee 105 makes the lending offer 110 and it is received by server 150, server 150 logs onto the applicable social network as the lender 105 (according to established protocol) and posts the lending offer 110. Specifically with respect to Facebook™, the lender 105 selects the potential lendee's Facebook™ user ID form her contacts list and her local device 130a incorporates the lendee's Facebook™ user ID into lending offer 110. Thus upon receipt of the lending offer 110 from lender 105, server 150 is able to post the lending offer 110 on the lendee's Facebook™ wall as a news feed from the lender.
The story/message posted on Facebook™ by lending server 150 contains the URL 115 as described above which allows the lendee to be directed back to server 150. In the case of a social network such as Facebook™ (in contrast to the URL 115 embedded in the ending offer email 114), the URL 115 will also be encrypted with the lendee's Facebook™ user ID. Server 150 is thus able to confirm that the URL 115 corresponds to the legitimate, unexpired lending offer 110 and the person responding to the offer (the one that clicked on the link) is the lendee. The server 150 confirms that person responding to the offer by clicking on the link on the Facebook™ wall is logged onto the social network with the user ID of the lendee. As most areas of the social networks are often publically accessible (e.g., the user's wall in Facebook™), this mechanism ensures that only the intended lendee, logged onto the social network under their user ID, was the one that activated the URL 115. Any other user clicking on the URL 115 while viewing the lendee's wall on Facebook™ will be rejected by server 150.
If the Facebook™ lendee is also a registered user of system 100, she merely logs on to server 150 to accept the loan offer 110. If she is not a registered user, she is invited to become a registered user as described above so that she can accept the loan offer 110.
Lending server 150 provides both the browser based web lending interface and non-browser based device lending interface as described above. Lender 105 may engage with web lending interface or device lending interface to initiate a lending offer 110. Lending server 150 uses web lending interface as a way to present lending offer 110 to lendee 109 over the Internet 140. Lending server 150 uses the device lending interface as a way to present lending offer notification 113 directly to lendee 109 on local device 130b. Lendee 109 may engage with web lending interface or device lending interface to accept or reject lending offer 110. Lendee 109 may also engage with web lending interface or device lending interface to return lent digital content 125 prior to the expiration of the lending period of digital content 125.
Lending server 150 provides access to a web account interface for lendee 109. Lendee 109 may log into his or her account in response to receipt of a lending offer email 114 delivered to email address 111. Lending server 150 also provides access to web account interface to a party with email address 111 who receives lending offer email 114, but does not have an account in lending system 100. The party may use web account interface to create an account. Creating the account establishes the party as lendee 109 with an account and a digital locker 120 in lending system 100.
Lending server 150 employs a web server 200 including interface software 205 to handle interactions between front-end components, such as device lending interface, web account interface, and web lending interface, and back-end database components of lending system 100. Web server 200 services include serving up the web pages 210 that comprise web account interface and web lending interface, and the underlying services associated with device lending interface. Interface software 205 include handling users' logins to their accounts and processing the initiation of and response to a lending offer 110.
Back-end database components of lending system 100 include customer accounts database 215, digital lockers database 220, lending offers database 225, Address Book database 250 and content metadata database 230. Records for users' accounts are stored and managed in customer accounts database 215. Records for digital lockers 120 are stored and managed in digital lockers database 220. Records for lending offers 110 are stored and managed in lending offers database 225. Content metadata database 230 serves as a source of metadata and lending rights information for individual digital content items 125 in lending system 100. Lending rights information in content metadata database 230 indicates whether any particular digital content 125 may be lent. The address books (contacts lists) for all users are stored in address book database 250.
Web services interface software 205 in the web server 200 interfaces with customer data services 235 to update customer accounts database 215, digital lockers database 220, and lending offers database 225. Customer data services 235 processes database updates such as maintaining and validating customer data in users' accounts, marking and unmarking digital content 125 as lent in digital lockers 120, creating and validating lending offers 110, and sending lending offer notifications 113 and lending offer emails 114.
Web services interface software 205 in the web server 205 also interfaces with content encryption services 240 to secure elements of lending offers 110 and to package digital content 125 for secure delivery to lender 105 and lendee 109. Web services interface software 205 provides an encrypted security hash code as a parameter for lending offer URL as described above. Content encryption services 240 processes digital content 125 to ensure that content 125 is packaged securely for lender 105 as owner and separately packaged securely for lendee 109 when lent.
Web services interface software 205 in the web server 200 further interfaces with Digital Rights Management (DRM) services 240 and lending offers database 235 to manage lending expirations. Web services interface software 205 manages expiration setting, checking, and enforcement for lending offers 110 and the lending period for digital content 125. DRM services 240 stamps an expiration date on digital content 125 when lent to lendee 109.
In the preferred embodiment of the invention, lending system 100 is a consumer-to-consumer ebook lending system. Although the ebook application is the preferred embodiment, as appreciated by those skilled in the art, the lending system 100 of the present invention is not limited to consumer lender 105 lending only an ebook to consumer lendee 109. Lending system 100 can be used for consumer-to-consumer lending of any digital content, such as digital movies, digital music, digital audio books, digital pictures, or other downloadable digital content.
In the preferred embodiment of the invention, local devices 130a and 130b are mobile electronic reader (eReader) devices. The embodiment of the invention is not intended to limit local device 130a or local device 130b to a mobile eReader device. Local device 130a or 130b may be a desktop personal computer or another type of mobile consumer electronic device, such as, for example, a cell phone, a laptop computer, a tablet computer or other mobile digital devices.
Another feature of the present invention is the ability of a registered user to discover books that are capable of being loaned by those of his contacts who are also registered users of system 100.
Interface 550 also has a selectable item 560 “Discover LendMe books from your friends here.” Tapping on item 560 launches a lending discovery application and user interface 570 as illustrated in
Tapping (clicking) on a particular contact's name 620 launches interface 630 as illustrated in
In an alternative embodiment of the present invention as illustrated in
The system also allows the searching user to type in the name of the book he is looking for, and similarly, it will show a list of matching titles and his friends that have that book. As appreciated by those skilled in the art, the searching user can also search by author or subject matter or other identifying data that is typically associated with book content.
To account for privacy concerns, the system of the present invention allows user to hide certain content from visibility to his contacts. A user can also completely opt out of the lending discoverability process. As shown in
Although the present invention has been described in relation to particular embodiments thereof, many other variations and other uses will be apparent to those skilled in the art. It is preferred, therefore, that the present invention be limited not by the specific disclosure herein, but only by the gist and scope of the disclosure.
Number | Name | Date | Kind |
---|---|---|---|
4855725 | Fernandez | Aug 1989 | A |
4899299 | MacPhail | Feb 1990 | A |
4924378 | Hershey et al. | May 1990 | A |
5014234 | Edwards, Jr. | May 1991 | A |
5109413 | Comerford et al. | Apr 1992 | A |
5457746 | Dolphin | Oct 1995 | A |
5598470 | Cooper et al. | Jan 1997 | A |
5734891 | Saigh | Mar 1998 | A |
5764972 | Crouse et al. | Jun 1998 | A |
6901386 | Dedrick et al. | May 2005 | B1 |
7054840 | Foth et al. | May 2006 | B1 |
7200575 | Hans et al. | Apr 2007 | B2 |
7231370 | Kapur | Jun 2007 | B1 |
7299498 | Lee et al. | Nov 2007 | B2 |
7299501 | Hendricks | Nov 2007 | B2 |
7814025 | Roever et al. | Oct 2010 | B2 |
7917965 | Manning et al. | Mar 2011 | B2 |
8364595 | Ringewald | Jan 2013 | B1 |
8627500 | Rogel et al. | Jan 2014 | B2 |
20020019943 | Cho et al. | Feb 2002 | A1 |
20020026445 | Chica et al. | Feb 2002 | A1 |
20020083178 | Brothers | Jun 2002 | A1 |
20020152173 | Rudd | Oct 2002 | A1 |
20030004885 | Banerjee et al. | Jan 2003 | A1 |
20030078888 | Lee et al. | Apr 2003 | A1 |
20040199471 | Hardjono | Oct 2004 | A1 |
20050137984 | Nguyen et al. | Jun 2005 | A1 |
20050219664 | Niwa | Oct 2005 | A1 |
20060036548 | Roever et al. | Feb 2006 | A1 |
20060143134 | So et al. | Jun 2006 | A1 |
20060253398 | Kim et al. | Nov 2006 | A1 |
20070112676 | Kontio et al. | May 2007 | A1 |
20070219917 | Liu et al. | Sep 2007 | A1 |
20070265977 | Read | Nov 2007 | A1 |
20070283420 | Rantalahti | Dec 2007 | A1 |
20080114729 | Raman et al. | May 2008 | A1 |
20080148069 | Tsuria et al. | Jun 2008 | A1 |
20080178001 | Kim et al. | Jul 2008 | A1 |
20090049556 | Vrielink et al. | Feb 2009 | A1 |
20090165124 | Spektor | Jun 2009 | A1 |
20090216623 | Hendricks et al. | Aug 2009 | A1 |
20090228395 | Wegner et al. | Sep 2009 | A1 |
20090260067 | Racabi | Oct 2009 | A1 |
20090281953 | Ruskowski | Nov 2009 | A1 |
20100067705 | Boccon-Gibod et al. | Mar 2010 | A1 |
20100106659 | Stefik et al. | Apr 2010 | A1 |
20100191770 | Cho et al. | Jul 2010 | A1 |
20100262515 | Brewer | Oct 2010 | A1 |
20100322373 | Churilla | Dec 2010 | A1 |
20110016182 | Harris | Jan 2011 | A1 |
20110143650 | Robinson | Jun 2011 | A1 |
20120090019 | Messerges et al. | Apr 2012 | A1 |
20120179753 | Welingkar et al. | Jul 2012 | A1 |
Number | Date | Country |
---|---|---|
09147029 | Jun 1997 | JP |
11039263 | Feb 1999 | JP |
2002189958 | Jul 2002 | JP |
2002259739 | Sep 2002 | JP |
2003186751 | Jul 2003 | JP |
2003186982 | Jul 2003 | JP |
2005316990 | Nov 2005 | JP |
2006134348 | May 2006 | JP |
2006522413 | Sep 2006 | JP |
200852663 | Mar 2008 | JP |
WO9301550 | Jan 1993 | WO |
WO9309490 | May 1993 | WO |
WO2004093062 | Oct 2004 | WO |
Entry |
---|
International Search Report and Written Opinion for PCT Application No. PCT/US2011/54651, dated Dec. 23, 2011. |
Web Article: Hugo Hallman, Rationalizing access checks with HMAC:ed URLs, http:/www.codeproject.com/Articles/8576/Rationalizing-access-checks-with-HMAC-ed-URLs, Oct. 16, 2004. |
U.S. Appl. No. 13/154,350, Non-Final Office Action, dated Nov. 8, 2012. |
U.S. Appl. No. 13/154,350, Final Office Action, dated Aug. 30, 2013. |
Number | Date | Country | |
---|---|---|---|
20120179753 A1 | Jul 2012 | US |
Number | Date | Country | |
---|---|---|---|
61406857 | Oct 2010 | US |