Patent Grant
11477134
The present disclosure generally relates to the exchange of computer resource-related services, and specifically to a method and system for receiving access to a particular application or application feature in exchange for the performance of a processing transaction.
Various types of application programming interface (API) service providers may provide one or more online services and/or resources to users, merchants, and different entities. For example, the application services (also referred to herein as application features) may be associated with a social networking, mapping, video game, media playback, such as streaming services and/or downloading of digital media, or other types of applications. However, each online service requires processing power by the online service and data transfer capabilities between the online service and the user's computing device. In particular during times of high processing demand on the service provider, requests for processing by a client device to the service provider may expend a large amount of computing processing.
In view of these types of expenditures, many businesses and other organizations would benefit from mechanisms by which to reduce the transactional costs associated with the execution, operation, maintenance, and supporting of the services (for example, provided via various APIs) on the provider's own computers. For many business solutions, large numbers of end-users can often submit requests or ‘calls’ to applications that result in high-volume, or batch, transactions, rather than more infrequent interactive transactions. To combat these issues, API service providers may look for flexible and cost-effective ways to offer and maintain services for frequent consumer transactions.
There is a need in the art for a system and method that addresses the shortcomings discussed above.
In one aspect, a method of managing requests to an application programming interface (API) is disclosed. The method includes identifying, for a transaction processing task, a plurality of task units, and receiving, at a first time, from a user account, a first request to access a first service offered through the API. The method further includes determining that access to the first service is conditional upon performance of a first amount of the transaction processing task, and assigning, to the user account, a first set of task units from the plurality of task units equivalent to the first amount. Furthermore, the method includes receiving a first indication that at least the first set of task units has been performed, and granting to the user account, in response to receiving the first indication, a first access session of the first service.
In another aspect, a system for managing requests to an application programming interface (API) includes a processor and machine-readable media. The machine-readable media include instructions which, when executed by the processor, cause the processor to identify, for a transaction processing task, a plurality of task units, and to receive, at a first time, from a user account, a first request to access a first service offered through the API. The instructions also cause the processor to determine that access to the first service is conditional upon performance of a first amount of the transaction processing task, and assign, to the user account, a first set of task units from the plurality of task units equivalent to the first amount. In addition, the instructions cause the processor to receive a first indication that at least the first set of task units has been performed, and grant to the user account, in response to receiving the first indication, a first access session of the first service.
In another aspect, a system for managing requests to an application programming interface (API) includes means for means for identifying, for a transaction processing task, a plurality of task units, as well as means for receiving, at a first time, from a user account, a first request to access a first service offered through the API. The system also includes means for determining that access to the first service is conditional upon performance of a first amount of the transaction processing task, and means for assigning, to the user account, a first set of task units from the plurality of task units equivalent to the first amount. Furthermore, the system includes means for receiving a first indication that at least the first set of task units has been performed, and means for granting to the user account, in response to receiving the first indication, a first access session of the first service.
Other systems, methods, features, and advantages of the disclosure will be, or will become, apparent to one of ordinary skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description and this summary, be within the scope of the disclosure, and be protected by the following claims.
The invention can be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like reference numerals designate corresponding parts throughout the different views.
The embodiments provide a method and system for reducing and in some cases eliminating unwanted and overburdensome application programming interface (API) call requests. Specifically, when outside parties are requesting an API service or feature via an API call to a service provider server, the systems and methods describe a mechanism by which such parties must—in exchange for access to the desired API service—perform by the use of their own computing resources one or more computing tasks. The proposed systems facilitate the completion of various processing tasks that are traditionally computer resource intensive by delegating, allocating, or otherwise distributing such tasks to computer resources belonging to outside parties, therefore managing the distribution of low priority computing tasks to such transactional counter-parties. In addition, such an arrangement reduces the likelihood of fraud and abuse by unscrupulous counter-parties, for example by effectively screening API requests to only those companies with sufficient computing resources to complete the predetermined compute tasks. As will be discussed below, the proposed systems can further be configured to offload or ‘assign’ a specific number and/or type of computing tasks to the computing devices of an end-user that must be performed in order for the API to fulfill a specific API call request.
For purposes of this application, an Application Programming Interface (API) can generally be understood to include a library of program elements such as functions, routines, protocols, or processes associated with a particular operating system or computing platform. The program elements may be software-based functions and/or processes in the form of source code, scripts, and/or executable code. The computing platform may include software and/or hardware. For example, the hardware may include a type of processor or hardware system. The software may include a version of an operating system such as Apple® iOS, MacOS®, Microsoft Windows®, Android® OS, UNIX, LINUX, or like environments that allow for running or executing an application and/or program. An API allow application programmers or providers to develop an application program capable of interfacing with the specified computing platform by incorporation of programs from the API library into the application program. A programmer may use a software development kit (SDK) or other tool to develop application programs. A development tool may include APIs or may enable the developer to remotely access APIs for a particular computer platform. Currently, most APIs are either openly accessible or include access control capabilities as part of the API.
With respect to the proposed systems and methods, it may be appreciated that the vast majority of internet services or sites now offer user experiences that combine two or more web-based services. These combined web-based services are referred to as “mashups.” In some examples, a first web-based service may be configured to provide a web-based API to developers such that the first web-based service can be integrated with another, second web-based service. For example, an Internet website offering addresses and/or locations of retail stores may combine the Google Maps™ web-service with the store information in a particular area to present to users where the stores are available geographically. To integrate the Google Maps™ service, a user's web browser may support Javascript that then enables the user's browser to support the Google Maps™ API.
For purposes of clarity, an overview of one embodiment of the proposed systems and methods is illustrated with reference to
As a general matter, the API gateway or other API management module can be configured to distribute its ‘assignment’ of computational tasks to one or more computing nodes associated with a client or end-user. As used herein, the term “computational task unit” refers to a finite sized computational workload that must be processed using a CPU, GPU, or other processing unit. In some embodiments, computational tasks are generated by one or more application processes. Application processes may be running on one or more computing systems. In one embodiment, application processes could be located in a single computing system (such as a server or virtual machine). In other cases, application processes could be running on two or more different systems. In some cases, application processes could be processes running on distinct clients. Furthermore, an access window refers to a period of time or frequency in which an end-user is provided with and/or able to access an API service. During this access window, the end-user may engage with said service only once, or log in and use the service multiple times, where each occasion in which the user actively accesses the service corresponds to an access session. Thus, an access window may be limited to or refer to a single access session of a predefined duration, be configured to permit the user several access sessions over a longer duration (e.g., any number of access sessions for one week), or be configured to permit the user a specific number of access sessions (e.g., five access session granted for each task assignment performed).
An illustrative example of an environment in which application programming interfaces may be managed is shown in
In different embodiments, a request processor 236 associated with the API gateway 230 and supporting the API can be configured to receive the request 224. The request may be a variant of an API call. In different embodiments, the request processor 236 may include a group of computing resources that are configured to receive the request and, for example, convert the request into a request instance for further processing. In one embodiment, the request instance can be constructed based on the API call variant which includes metadata identifying an appropriate pre-processor to use for that variant. For example, a pre-processor can use the information contained in the request instance and/or the context of the API call variant to determine if the request instance should be processed.
In some embodiments, the request processor 236 may communicate with an authorization engine 240 to determine if the client system 220 has permission to use the API call variant. The request 224 can include additional information such as time of day, IP address, account type, origin of request, destination of request, hostname or other identifiers that may be extrinsically given or intrinsic to the request 224. In some embodiments, an API request can also contain a communication use protocol (e.g., SSL), a request token, a uniform resource locator, an authorization and authentication URL, an access token URL, a mobile application identifying information, and/or an application signature.
In some embodiments, the user 210 may be associated with a unique user account or profile 222 that can be accessed by the authorization engine 240 to determine whether the user 210 has been previously granted or linked to authorization to the selected service(s), previous access and/or usage history, how many access events or sessions (frequency) the user 210 has been granted to the particular service(s) and/or how many sessions remain, a duration of usage that may have been granted to the user 210, and/or whether the permissions have an expiration or other termination point that may have occurred. However, it should be understood that while the term “account” is used in this example in describing a specific user or entity with specific credentials, an account may also be used to more broadly refer to a source of the API request, such as the IP address from which the user generates the request. In addition, the user account can be one linked to a different API rather than the API from which the service is being requested, as would be expected in the multi-application ‘mashup’ scenarios noted above. In other words, a user with an account for one API may be permitted to rely on the same credentials when attempting to access a second, different API.
In some embodiments, the authorization engine 240 may be configured to permit the user 210 a free ‘trial’ access session to the requested service(s), or the user may have a paid subscription or other status that indicates to the authorization engine 240 that access to a requested API service(s) 234 should be provided to this user 210 (e.g., via an access manager 232) without requiring any additional ‘payment’ or other ‘compensation’ (i.e., performance of a computational task) in exchange for the service. In one embodiment, the authorization engine 240 can be configured to capture and displaying data on how the API is accessed, including who is accessing it, how they are accessing it, and where they are accessing it from, as well as limiting the number of times per second the API can be called from a given client system or IP address, and/or counting down to a maximum number of calls per day, week or month. Once the limit is reached, access can be turned off, or the user's/developer's account can be charged for access (e.g., via the service exchange process described herein), and/or a notification can take place.
For example, in some embodiments, the API gateway 230 can be configured to facilitate rate limiting for access to an API, such as specifying how many API calls per second that the API server will accept from a particular client system or where the API provider specifies how many calls the client system can make over a predetermined period of time (e.g., day, week, or month). If the client system exceeds the limit, the API gateway 230 may return a 403 error, issue a notification but continue to allow access, issue notification but allow access up to a certain high level of overage, and/or accept traffic up to a certain level for free, but charge for additional access that exceeds the free limit, where that charge may correspond to the performance of computational task assignments as described herein.
In cases where the authorization engine 240 determines the user 210 must ‘pay’ for the service by the performance of a computational task in order to be granted access to the service(s), a service exchange processor 250 can communicate with application processes 260. The application processes 260 can identify one or more computational tasks 262 that are in a task queue. These computational tasks 262 (also referred to as computational transactions) are sent to a task calculator 252. The task calculator 252 analyzes the computational tasks and determines the type and amount of one or more computational tasks that must be performed in order for the user 210 to be provided access to the requested service(s). The determination can vary based on user characteristics, user account status or membership, previous user activity, the type of access that is to be granted (e.g., recurring, extended duration, one-time only, etc.), and/or the computational resources available to or associated with the client system 220. Once the computational tasks 262 are received by the task calculator 252, the appropriately allocated amount of task units are sent to a task distributor or task distribution module 254, which can, via a network connection, transmit the ‘assignment’ to one or more client computing nodes 226 to process each of the tasks, as discussed further below. In addition, in some embodiments, computational tasks 262 may include one or more test tasks or test task units for which there is a known outcome or output value. These types of task units can facilitate the task performance verification processing. Test task units may also be referred to as verification tasks units, and test tasks can also be referred to as verification tasks throughout this application.
In some embodiments, the task distributor may function as a load balancer that acts to distribute computational workloads over a set of computing nodes to avoid overloading any particular node. In other embodiments, the task distributor may distribute tasks according to features such as “task similarity,” which may be different from conventional load balancers. In one embodiment, the task distribution module 254 sends tasks to one of multiple different computing nodes associated with the client system 220. As used herein, the term “computing node” may refer to a unit for processing computational tasks or workloads. Each node could comprise at least one processor along with memory. In some embodiments, each of these computing nodes comprises a single server with a single processor. The processor may itself comprise multiple processing cores, as described below. However, in other embodiments, each computing node could comprise multiple servers (and/or processors). In other embodiments, each node could comprise a server cluster.
In different embodiments, one or more application processes 260 may generate computational tasks 262 to be performed by one or more computing nodes. Specifically, the application processes 260 may be configured to generate computational tasks that are as small as possible. As an example, where it is feasible, an application could generate two tasks that require three processing cores each, rather than a single task that requires six processing cores. As another example, an application could generate three tasks that each only require one processing core, rather than a single task that requires three processing cores. For example, generating tasks that are smaller (that is, tasks that require fewer processing cores to be completed) may allow for greater processor utilization per clock cycle.
As noted above, the task calculator 252 may receive computational tasks to be completed and identify specifically an amount and/or type of tasks that are equivalent, correspond, or otherwise match the current request. In some embodiments, the task calculator 252 can coordinate with task distribution module 254 to organize the tasks into groups, where each group comprises tasks that are computationally similar. As an example of computational similarity, two tasks may be more similar if they rely on similar information stored in RAM during processing. This may allow RAM to be shared between processors, or between cores within a processor, when two similar tasks are processed simultaneously (or near simultaneously). In some embodiments, once the tasks have been grouped according to computational similarity, the tasks may be distributed to the computational nodes 226. Specifically, each group of tasks may be sent to a single node so that tasks that are computationally similar may all be processed at the same computational node, thereby increasing the amount of RAM can be shared among processors or cores, as compared to the amount of RAM that could be shared by unrelated tasks. In some cases, different groups of tasks are sent to different nodes. In other cases, different groups could be sent to the same node, but at different times. It may be appreciated that in addition to considering computational similarity, a task distributor may also consider other factors in forming groups and/or in allocating and distributing tasks to computational nodes. For example, if a group of tasks is too large, sending all the similar tasks to a single node may not be feasible. Therefore, other factors could also be considered in deciding where to distribute different workloads. These include any suitable factors used by conventional load balancers in distributing workloads among multiple computing nodes.
The client computing node(s) 226 may receive and process computational tasks that have been delivered by the task distribution module 254. In different embodiments, client computing node(s) 226 includes one or more processors and memory. The memory may comprise a non-transitory computer readable medium. Instructions stored on the non-transitory computer readable medium may be executed by the one or more processors. The memory may include any type of short-term and/or long-term memory (or storage), including Random Access Memory (RAM), micro-SD memory and Solid State Drives (SSD). When a computing node is a single processor, the memory could comprise one or more memory caches. Furthermore, some processors may be multicore processors. Multicore processors comprise a single computing component that includes two or more distinct processing units, referred to as cores. Using a multicore processor, multiple different tasks can be run simultaneously (multiprocessing), a single task can be completed using multiple cores processing in parallel (parallel processing), and/or a combination of multiprocessing and parallel processing can be accomplished.
In different embodiments, a task completion determination module 256 can be configured to determine whether the client system 250 has successfully performed the assigned tasks. If the task completion determination module 256 determines that the assigned tasks have not been performed, were partially performed but unfinished, and/or were performed but one or more items are invalid or incorrect, the request 224 may be denied or blocked. If the request is not allowed, the request processor 236 may then respond the same as with any invalid request.
If the task completion determination module 256 determines the assigned tasks were completed successfully, the service exchange processor 250 can communicate with authorization engine 240 to create, update, or otherwise modify the permissions to be provided to user 210. This information is shared with the access manager 232, which can enable an access token, generate an access record, access token, or permission, or otherwise provide the requested API services 234 to the client system 220.
For purposes of clarity, one example of an API service access management system is presented with reference to
Referring now to
As shown in
In
Once the job assignment has been completed, the client device 314 can transmit a signal representing performed task units 810 or other data indicating the performance of the job assignment back to the API gateway 330 for review by the transactional task manager 350, as shown in
For purposes of this disclosure, a test task unit refers to a computational task unit that has a known outcome or output. In some cases, this may be because the test task unit is an artificially generated task that can be inserted into the set of task units being assigned to the end-user and serves as a ‘dummy’ verification task. The outcome of the dummy task is predefined, and so the performance output or completion signal sent by the end-user system should include this predefined value in order to pass the verification step. In some other cases, the test task unit can represent a task unit that is repetitive in nature, but nevertheless needs to be performed frequently by the application processors. The API benefits from distributing this load of work to other systems, and can readily verify whether the tasks were correctly performed and/or successfully completed. In different embodiments, the test task units can be arranged to occur in the job assignment task queue at specific intervals (e.g., every 5th task unit), specific positions (e.g., 3rd task unit, 7th task unit), or specific proportions (e.g., 30% of the job assignment). The test task units can also be randomly distributed throughout the job assignment queue. In some embodiments, the job assignment may include not test task units, while in other embodiments, the entire job assignment may comprise test task units. For example, in cases where the goal of the service provider is to limit API calls to entities that have sufficient computing resources, the job assignment may only include test task units.
Once the performance has been verified and accepted, the transactional task manager 350 can generate or otherwise obtain access signal or permission token(s) 910 corresponding to a response to the API call, as shown in
In other embodiments, the method may include additional steps or aspects. In one embodiment, an access signal, access record, access token, or permission token granting a predetermined number of subsequent access sessions of the first service to the user account is generated in response to receiving the first indication. In some embodiments, the method can further include steps of receiving from the user account, at a second time after the first time, a second request to access the first service, determining that the user account is associated with the access record, and granting, in response to determining the user account is associated with the access record, a second access session of the first service. In another example, the method can also include steps of receiving, from the user account, a first number of requests to access the first service, determining the first number of requests exceeds the predetermined number, and assigning, to the user account, a second set of task units from the plurality of task units equivalent to the first amount.
In different embodiments, the method can also include steps of receiving, from the user account, a second request to access a second service offered through the API, determining that access to the second service is conditional upon performance of at least a second amount of the transaction processing task that differs from the first amount, assigning, to the user account, a second set of task units from the plurality of task units equivalent to the second amount, receiving a second indication that the second set of task units has been performed, and granting to the user account, in response to receiving the second indication, a second access session of the second service. In other words, the system can be configured to value one service higher than another service, and manifest this difference in the number of task units included in a task assignment. In some embodiments, the API receives an average of a first number of requests for the first service over a first period of time and a second number of requests for the second service over the first period of time, and the difference between the first amount and the second amount is proportional to a difference between the first number and second number. In other words, the average demand for a service over a period of time can be a factor in how much that service should be valued. In addition, a service can have a dynamic value that ebbs and flows with the increase and decrease of user demand for said service, which can in turn affect the amount of task units that will be assigned in order to ‘pay’ for access to the service.
In another example, the method may also include steps of assigning, to the user account, in addition to the first set of task units, one or more verification tasks, receiving, from the user account, a signal corresponding to a response to the assignment of the first set of task units and one or more verification tasks, verifying the one or more verification tasks were performed correctly, and generating the first indication in response to verifying the one or more verification tasks were performed correctly. In some cases, the method can further include receiving, at a second time before the first time, an initial request from the user account for trial access of the first service, determining that trial access to the first service is available to the user account, and then granting to the user account a trial access session of the first service prior to the granting of the first access session.
In different embodiments, the method may involve determining that granting the user account access to the first service is associated with a first transactional cost and granting the user account access to the second service is associated with a second transactional cost that is lower than the first transactional cost. In such cases, a calculation of the first amount can be based at least on the first transactional cost, a calculation of the second amount is based at least on the second transactional cost, where the first amount is greater than the second amount. In some other examples, the method may also include providing, to the user account, a program configured to execute the performance of the first set of task units.
The processes and methods of the embodiments described in this detailed description and shown in the figures can be implemented using any kind of computing system having one or more central processing units (CPUs) and/or graphics processing units (GPUs). The processes and methods of the embodiments could also be implemented using special purpose circuitry such as an application specific integrated circuit (ASIC). The processes and methods of the embodiments may also be implemented on computing systems including read only memory (ROM) and/or random access memory (RAM), which may be connected to one or more processing units. Examples of computing systems and devices include, but are not limited to: servers, cellular phones, smart phones, tablet computers, notebook computers, e-book readers, laptop or desktop computers, all-in-one computers, as well as various kinds of digital media players.
The processes and methods of the embodiments can be stored as instructions and/or data on non-transitory computer-readable media. The non-transitory computer readable medium may include any suitable computer readable medium, such as a memory, such as RAM, ROM, flash memory, or any other type of memory known in the art. In some embodiments, the non-transitory computer readable medium may include, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of such devices. More specific examples of the non-transitory computer readable medium may include a portable computer diskette, a floppy disk, a hard disk, magnetic disks or tapes, a read-only memory (ROM), a random access memory (RAM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memories (EEPROM), a digital versatile disk (DVD and DVD-ROM), a memory stick, other kinds of solid state drives, and any suitable combination of these exemplary media. A non-transitory computer readable medium, as used herein, is not to be construed as being transitory signals, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Instructions stored on the non-transitory computer readable medium for carrying out operations of the present invention may be instruction-set-architecture (ISA) instructions, assembler instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, configuration data for integrated circuitry, state-setting data, or source code or object code written in any of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or suitable language, and procedural programming languages, such as the “C” programming language or similar programming languages.
Aspects of the present disclosure are described in association with figures illustrating flowcharts and/or block diagrams of methods, apparatus (systems), and computing products. It will be understood that each block of the flowcharts and/or block diagrams can be implemented by computer readable instructions. The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of various disclosed embodiments. Accordingly, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions. In some implementations, the functions set forth in the figures and claims may occur in an alternative order than listed and/or illustrated.
The embodiments may utilize any kind of network for communication between separate computing systems. A network can comprise any combination of local area networks (LANs) and/or wide area networks (WANs), using both wired and wireless communication systems. A network may use various known communications technologies and/or protocols. Communication technologies can include, but are not limited to: Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), mobile broadband (such as CDMA, and LTE), digital subscriber line (DSL), cable internet access, satellite broadband, wireless ISP, fiber optic internet, as well as other wired and wireless technologies. Networking protocols used on a network may include transmission control protocol/Internet protocol (TCP/IP), multiprotocol label switching (MPLS), User Datagram Protocol (UDP), hypertext transport protocol (HTTP), hypertext transport protocol secure (HTTPS) and file transfer protocol (FTP) as well as other protocols.
Data exchanged over a network may be represented using technologies and/or formats including hypertext markup language (HTML), extensible markup language (XML), Atom, JavaScript Object Notation (JSON), YAML, as well as other data exchange formats. In addition, information transferred over a network can be encrypted using conventional encryption technologies such as secure sockets layer (SSL), transport layer security (TLS), and Internet Protocol security (Ipsec).
While various embodiments of the invention have been described, the description is intended to be exemplary, rather than limiting, and it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible that are within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents. Also, various modifications and changes may be made within the scope of the attached claims.
This application claims the benefit of U.S. Provisional Patent Application Ser. No. 63/002,940 filed on Mar. 31, 2020 and titled “Computer Resource-Based API Transaction Method and System”, the disclosure of which is incorporated by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 10599873 | Winstrom | Mar 2020 | B2 |
| 20120221955 | Raleigh | Aug 2012 | A1 |
| 20150213449 | Morrison | Jul 2015 | A1 |
| 20160248641 | Bhatia | Aug 2016 | A1 |
| 20180089465 | Winstrom | Mar 2018 | A1 |
| 20200195421 | Gagnon | Jun 2020 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 63002940 | Mar 2020 | US |
