Patent Application
20200302413
The invention generally relates to the field of monetization of digital content and services, and more specifically to restricting and allowing a user to access protected web resources.
As online advertising revenue decreases, providers of digital content and services are looking to augment or move their revenue stream to a paywall-based model. Paywalls can vary in design. Some experts refer to “hard” or “soft” paywalls that are more or less restrictive to users. Some hard paywalls are set up so that users cannot gain any access to a site without payment. Soft paywalls, on the other hand, may allow for limited viewing free of charge. Some paywalls offer only daily, weekly, monthly, or yearly subscriptions to entire web sites (e.g. domains). Such subscriptions usually allow users to access unlimited amount of web resources over the lifetime of the subscription. Other paywalls offer metered access to individual pieces of content, such as pay per view, pay per multiple views, etc.
Development of a coherent paywall solution represents a significant challenge, and requires a large capital investment and deep technical expertise. For a majority of providers of digital content and services these factors represent a high barrier to entry.
Furthermore, user experience might be significantly degraded, if most web publishers successfully implement individual paywall solutions. It is highly possible that a user will have to register, share sensitive financial data, and manage subscription or metered access with each individual publisher of digital content and services.
Accordingly, there is a need for systems, methods, and computer readable media that provide publishers of digital content and services with a convenient way of restricting access and monetizing web resources, and allow users to access these web resources with minimal effort.
The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention.
A “web resource,” as the term is used herein, is to be broadly interpreted any machine-readable and machine-storable digital content or service. A web resource is typically uniquely addressed by a Uniform Resource Locator (URL). A web resource may include, for example, a file, a web page, image, video, audio, or a document. In the context of the Internet, a common document is a web page. Documents often include textual information and may include embedded information (such as meta information, images, hyperlinks, etc.) and/or embedded instructions (such as JavaScript, etc.). A “hyperlink,” as the term is used herein, is to be broadly interpreted to include any reference to/from a document from/to another document or another part of same document. A web resource may also represent a digital service, for example, computation, data transformation, data storage or retrieval, or a request to another digital service. A “protected web resource,” as the term used herein, is to be broadly interpreted as a web resource that can be accessed only after successful authorization.
Consistent with the principles of the invention, publishers of digital content and services may register protected web resources in a cloud paywall system (i.e. third-party paywall). After registration, cloud paywall system itself can access protected web resource hosted on publisher servers. Publishers of digital content and services may receive a code snippet, which they may include in other documents that embed (e.g. hyperlink) the protected web resource registered in the cloud paywall system. The code snippet allows users to retrieve information about the fee charged for accessing a particular protected web resource and access the web resource with minimal effort. In some embodiments, the protected web resource can be accessed directly without the code snippet by using a customized client code interacting with the cloud paywall system.
In one embodiment, client 110 is a computing system. In other embodiments, client 110 is any computing system configured to communicate data across network 120. One example of client 110 is computing system 200, shown in
In one embodiment, web publisher server 140 is a computing system (e.g., computing system 200, shown in
Generally, some embodiments of web publisher server 140 monitor network 120 for messages sent from client 110 relating to protected resource 150. When a message is received, web publisher server 140 determines whether the message contains a request that requires the authorization of client 110. Authorization of client 110 is necessary prior to permitting client 110 to access protected resource 150, and to control access to protected resource 150. In some embodiments, web publisher server 140 rejects any request from client 110 that does not carry valid authorization data. In other embodiments, web publisher server 140 might direct client 110 to cloud paywall server 130, if web publisher server 140 determines that authorization is necessary.
In the illustrated embodiment, web publisher server 140 includes protected resource 150. Protected resources include, for example, functions performed by a web publisher server 140 and data stored by web publisher server 140 that can only be accessed, used, or modified by an authorized client. For example, if web publisher server 140 provides the service of distributing real-time financial market data, the service's endpoint (i.e. URL) is a protected resource that can only be accessed, used, or modified by an authorized client. As another example, protected resource 150 is an entry in a directory. In another embodiment, protected resource 150 is a record in a database. In another embodiment, protected resource 150 is a file or part of a file stored on a memory storage device. Other embodiments use other forms of protected resources 150.
In one embodiment, cloud paywall server 130 is a computing system (e.g., computing system 200, shown in
If client 110 is authorized to perform the request contained in its message to protected resource 150, web publisher server 140 communicates the results of the requested operation to client 110. However, in other possible embodiments, cloud paywall server 130 communicates directly with web publisher server 140, across network 120, such as to receive a request for authorization from web publisher server 140, or to send a proof of authorization to web publisher server 140.
Processing unit 230 may represent any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations. Main memory 235 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processing unit 230. ROM 210 may include a ROM device or another type of static storage device that may store static information and instructions for execution by processing unit 230. Storage device 220 may include magnetic media and solid state media. Input device 205 may include a mechanism that permits an operator to input information to the client/server entity, such as a keyboard, a mouse, a touch detection and processing circuitry, a microphone, and so on. Output device 215 may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. Communication interface 225 may include mechanisms for communicating with another device or system via a network, such as network 120.
The client/server entity, consistent with the principles of the invention, may perform certain operations or processes, as will be described in detail below. The client/server entity may perform these operations in response to processing unit 230 executing software instructions contained in a computer-readable medium, such as memory 235. A computer-readable medium may be defined as a physical or logical memory device and/or carrier wave.
The software instructions may be read into memory 235 from another computer-readable medium, such as data storage device 220, or from another device via communication interface 225. The software instructions contained in the memory 235 may cause processing unit 230 to perform operations or processes that will be described in this disclosure. Alternatively, hard-wired circuitry may be used in place of or in combination with the principles of the invention. Thus, implementations consistent with the invention are not limited to any specific combination of hardware circuitry and software.
Chipset 275 can also interface with one or more communication interfaces 280 that can have different physical interfaces. Such communication interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks. Some applications of the methods for generating, displaying and using the GUI disclosed herein can include receiving ordered datasets over the physical interface or be generated by the machine itself by processor 285 analyzing data stored in storage 260 or 290. Further, the machine can receive inputs from a user via user interface components 255 and execute appropriate functions, such as browsing functions by interpreting these inputs using processor 285.
It can be appreciated that exemplary systems 200 and 250 can have more than one processor 230 or 285, respectively, or be part of a group or cluster of computing devices networked together to provide greater processing capability.
Operations 310, 320, 330, 340, 350 can either be performed directly by the user or through automated means, such as with pre-filed data fields, user histories and default preference settings. Pre-filed data fields include, for instance, data stored using cookie-based favorites. In addition, operations 310, 320, 330, 340, 350 can be performed through web-based application programming interface (API).
According to some embodiments, the current technology can be configured to allow web publishers to register new protected web resources and manage the account along with existing registrations using cloud paywall publisher user interface 580 and publisher module 540 through network 550. Publisher module 540 comprises publisher information database 541, protected web resource registration module 542, and publisher authentication module 543. Publisher authentication module 543 allows web publishers to create an account in the cloud paywall system and log in to it at any time. In some embodiments, publisher information database 541 stores and provides access to information associated with a particular publisher account, such as payment information, list of verified web domain ownerships, etc. In other embodiments, publisher information database 541 stores and provides access to information associated with individual web domains, such as domain level subscription pricing information, domain level promotions and allowances for users of protected web resources. Publisher information database 541 might also store telemetry and analytics for the registered protected web resources. In some embodiments, protected web resource registration module 542 performs operations shown in
According to some embodiments, the current technology can be configured to allow clients to access protected web resources and manage the account using cloud paywall client user interface 560 and client module 520 through network 550. Client module 520 comprises client information database 521, billing module 522, and client authentication module 523. Client authentication module 523 allows clients to create an account in the cloud paywall system, log in to it at any time and preserve long-term sessions with client module 520 and URL access module 530 using web cookies. In some embodiments, client information database 521 stores and provides access to information associated with a particular client account, such as current account balance, billing information, price limits at which protected web content is purchased automatically without additional confirmation from the user, etc. In other embodiments, client information database 521 stores and provides access to information about past purchases of protected web resources, such as time of purchase, cost of purchase, etc. In some embodiments, client information database 521 stores the list of domain level subscriptions, domain level promotions and allowances for protected web resources. Billing module 522 puts charges and adds credit to the user account.
According to some embodiments, the current technology can be configured to allow clients to retrieve pricing information and access protected web resources using cloud paywall client-side script 570 and URL access module 530 through network 550. In some cases, cloud paywall client-side script 570 queries URL pricing analytics module 535, which performs actions 720-725 shown in
URL authorization module 533 uses URL access lookup module 534 to query authorization information for a particular URL from URL Access Database (UAD) cache 532 and URL Access Database (UAD) persistent storage 531.
URL pricing analytics module 535 uses URL access lookup module 534 to query pricing for a particular URL from URL Access Database (UAD) cache 532 and URL Access Database (UAD) persistent storage 531. In some embodiments, in order to further determine final price of a protected web resource for a particular user, URL pricing analytics module 535 queries publisher information database 541 for domain level subscription pricing information, domain level promotions and allowances for protected web resources. In some embodiments, in order to further determine final price of a protected web resource for a particular user URL pricing analytics module 535 queries client information database 521 for domain level promotions and allowances for protected web resources and past purchases of protected web resources.
According to some embodiments, data in URL Access Database (UAD) cache 532 might be completely synchronized with data in URL Access Database (UAD) persistent storage 531. According to other embodiments, URL Access Database (UAD) cache 532 might contain only a subset of data present in URL Access Database (UAD) persistent storage 531.
At step 720, cloud paywall server 130 attempts to authenticate cloud paywall user. In case of authentication failure, at step 724, URL pricing analytics module 535 retrieves prices for all requested URLs using URL access lookup module 534.
In case of authentication success, at step 721, URL pricing analytics module 535 matches requested URLs to domain-level subscriptions purchased by the user and stored in client information database 521. At step 722, URL pricing analytics module 535 matches requested URLs to URLs purchased by the user and stored in client information database 521. In some embodiments, if matching at steps 721 or 722 is successful then protected web resource can be accessed at no additional cost. At step 723, URL pricing analytics module 535 retrieves prices for all other requested URLs using URL access lookup module 534.
At step 725, URL pricing analytics module 535 transmits one or multiple responses 740 to client 110. At step 712, client 110 stores retrieved prices for future display.
At step 830, cloud paywall server 130 attempts to authenticate cloud paywall user using client authentication module 523. In case of authentication failure, at step 832, the request is rejected and response message 821 is transmitted to client 110.
In case of authentication success, at step 831, price and authorization information for requested protected web resource 150 is retrieved. Price retrieval may include steps 721, 722, 723 shown in
In case of sufficient funds, the flowchart continues with step 834, at which URL authorization module 533 transmits a request message 840 to web publisher server 140. At step 860, web publisher server 140 generates www-authenticate header which may contain such values as nonce, opaque and realm, and transmits response message 841 to cloud paywall server 130. Flowchart continues with step 835, at which purchase is recorded and user may be charged a fee for accessing the web resource. At step 836, URL authorization module 533 generates authorization header using the information from response message 841 and authorization data retrieved at step 831. In some embodiments, step 836 may use cryptographic operations such as MD-5, SHA-256, or other type of digest computation. At step 837, cloud paywall server 130 transmits authorization response message 821 containing fully formed authorization header to client 110. Flowchart continues with step 811, at which client includes authorization header from authorization response message 821 in request message 851 and transmits request message 851 to web publisher server 140 to retrieve protected web resource 150.
At step 861, web publisher server 140 verifies authorization header. In some embodiments, authorization header is verified by computing MD-5 digest, or SHA-256 digest, or other type of digest and matching that digest to the digest from authorization header of request message 851. In other embodiments, authorization header is verified by matching login and password information from authorization header of request message 851 to login and password information stored at web publisher server 140. If verification of authorization header is successful, web publisher server 140 transmits response message 852 which contains requested web resource. If verification of authorization header is unsuccessful, web publisher server 140 transmits response message 852 which contains an error code.
At step 930, cloud paywall server 130 attempts to authenticate cloud paywall user using client authentication module 523. In case of authentication failure, at step 932, request is rejected and response message 921 is transmitted to client 110.
In case of authentication success, at step 931, price and authorization information for requested protected web resource is retrieved. Price retrieval may include steps 721, 722, 723. The flowchart continues with the step 933, at which billing module 522 ensures that client account in client information database 521 has sufficient funds for purchase of request web resource 150. In case of insufficient funds, billing module 522 may reject request 920 and transmit response message 921 to client 110.
In case of sufficient funds, the flowchart continues with step 934, at which URL authorization module 533 transmits request message 940 to web publisher server 140. At step 960, web publisher server 140 generates www-authenticate header which may contain such values as nonce, opaque and realm, and transmits response message 941 to cloud paywall server 130. Flowchart continues with step 935, at which purchase is recorded and user may be charged a fee for accessing the web resource. At step 936, URL authorization module 533 generates authorization header using the information from response message 941 and authorization data retrieved at step 931. In some embodiments, step 936 may use cryptographic operations such as MD-5, SHA-256, or other type of digest computation. In other embodiments, step 936 may pass authorization information such as login and password in plain text without MD-5, SHA-256, or other type of digest computation.
At step 937, cloud paywall server 130 includes authorization header from previous step in request message 951 and transmits request message 951 to web publisher server 140. At step 961, web publisher server 140 verifies authorization header. In some embodiments, authorization header is verified by computing MD-5 digest, or SHA-256 digest, or other type of digest and matching that digest to the digest from authorization header of request message 951. In other embodiments, authorization header is verified by matching login and password information from authorization header of request message 951 to login and password information stored at web publisher server 140. If verification of authorization header is successful, web publisher server 140 transmits response message 952 which contains requested web resource. If verification of authorization header is unsuccessful, web publisher server 140 transmits response message 952 which contains an error code. The flowchart continues with step 938, at which cloud paywall 130 receives response message 952 and passes it to client 110 in response message 921.
Note that in this Specification, references to various features (e.g., elements, structures, nodes, modules, components, logic, steps, operations, functions, characteristics, etc.) included in “one embodiment”, “example embodiment”, “an embodiment”, “another embodiment”, “certain embodiments”, “some embodiments”, “various embodiments”, “other embodiments”, “alternative embodiments”, and the like are intended to mean that any such features are included in one or more embodiments of the present disclosure, but may or may not necessarily be combined in the same embodiments. Note that a module, engine, client, controller, function, logic, or the like as used herein this Specification, can be inclusive of an executable file comprising instructions that can be understood and processed on a computer, processor, machine, compute node, combinations thereof, or the like and may further include library modules loaded during execution, object files, system files, hardware logic, software logic, and/or any other executable modules.
It is also important to note that the operations and steps described with reference to the preceding FIGURES illustrate only some of the possible scenarios that may be executed by, or within, the communication system 100. Some of these operations may be deleted or removed where appropriate, or these steps may be modified or changed considerably without departing from the scope of the discussed concepts. In addition, the timing of these operations may be altered considerably and still achieve the results taught in this disclosure. The preceding operational flows have been offered for purposes of example and discussion. Substantial flexibility is provided by the system in that any suitable arrangements, chronologies, configurations, and timing mechanisms may be provided without departing from the teachings of the discussed concepts.
Note that with the examples provided above, as well as numerous other examples provided herein, interactions may be described in terms of one, two, three, or four network elements. However, this has been done for purposes of clarity and example only. In certain cases, it may be easier to describe one or more of the functionalities by only referencing a limited number of network elements. It should be appreciated that communication system 100 (and its teachings) are readily scalable and can accommodate a large number of components, as well as more complicated/sophisticated arrangements and configurations. Accordingly, the examples provided should not limit the scope or inhibit the broad teachings of communication system 100 as potentially applied to a myriad of other architectures.
As used herein, unless expressly stated to the contrary, use of the phrase “at least one of”, “one or more of”, “and/or”, variations thereof, or the like are open ended expressions that are both conjunctive and disjunctive in operation for any combination of named elements, conditions, or activities. For example, each of the expressions “at least one of X, Y, and Z”, “at least one of X, Y, or Z”, “one or more of X, Y, and Z”, “one or more of X, Y, or Z”, and “A, B, and/or C” can mean any of the following: 1) X, but not Y and not Z; 2) Y, but not X and not Z; 3) Z, but not X and not Y; 4) X and Y, but not Z; 5) X and Z, but not Y; 6) Y and Z, but not X; or 7) X, Y, and Z. Additionally, unless expressly stated to the contrary, the use of these terms is not intended to indicate any type of order, rank, importance, temporal sequence, or hierarchy of the modified noun. For example, “first X” and “second X” are intended to designate two X elements that are not necessarily limited by any order, rank, importance, temporal sequence, or hierarchy of the two elements. As referred herein, “at least one of” and “one or more of” can be represented using the “(s)” nomenclature (e.g., one or more elements(s)).
Although the present disclosure has been described in detail with reference to particular arrangements and configurations, these example configurations and arrangements may be changed significantly without departing from the scope of the present disclosure. Moreover, certain components may be combined, separated, eliminated, or added based on particular needs and implementations. Additionally, although embodiments herein have been illustrated with reference to particular elements and protocols, these elements and protocols may be replaced by any suitable architecture, protocols, and/or processes that achieve the intended functionality of accessing protected web resources using cloud paywall system as disclosed herein.
Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained to one skilled in the art and it is intended that the present disclosure encompass all such changes, substitutions, variations, alterations, and modifications as falling within the scope of the appended claims. In order to assist the United States Patent and Trademark Office (USPTO) and, additionally, any readers of any patent issued on this application in interpreting the claims appended hereto, Applicant wishes to note that the Applicant: (1) does not intend any of the appended claims to invoke paragraph (f) of 35 U.S.C. Section 112 as it exists on the date of the filing hereof unless the words “means for” or “step for” are specifically used in the particular claims; and (2) does not intend, by any statement in the specification, to limit this disclosure in any way that is not otherwise reflected in the appended claims.
