Surrogate caching for optimized service access using compact user objects and offline database updates

Abstract

When an access service receives a request to access the service, it stores the user object in a long-term data store and a short-term cache, dividing the cache into a regular cache that stores the full version of the user object and a surrogate cache that stores a compact version of the user object. The compact version of the user object includes a field derived from the full user object that indicates whether subsequent requests for access to a particular service should be permitted, and after access is permitted / denied based on this value in the compact user object, updates to the full user object are processed offline. [Effect] This surrogate cache structure allows for fast approval / rejection of requests, thus decoupling this procedure from processing related to the full user object.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims priority to U.S. Patent Application No. 17 / 015,697, filed on September 9, 2020, entitled "SURROGATE CACHE FOR OPTIMIZED SERVICE ACCESS WITH COMPACT USER OBJECTS AND OFFLINE DATABASE UPDATES", the entire content of which is incorporated herein by reference.

Background Art

[0002] Background Real-time request processing is a crucial element in many modern telecom and online services. When a request is received from a client device, the service can act as an access control point for accessing any type of online service. Alternatively, a central service can serve as a management server location, tracking all capacities or balances in real time. Upon receiving a network request, the central service attempts to process it as close to real-time as possible to avoid undesirable connection latency on client devices. However, determining whether access to a service should be permitted can be a computationally and latency-intensive task. A significant amount of computation may be performed, requiring the retrieval of data from data storage systems for a specific user. This information then needs to be processed to answer the question of whether access should be permitted in this particular case. Processing access requests in real time can strain the capacity of some systems to handle millions of different user accounts. As the number of users increases, feasible caching systems can become excessively large. Therefore, services that evaluate online access requests in real time require improvement. [Overview of the project] [Means for solving the problem]

[0003] Brief Overview To establish a connection to a service provider, real-time requests may be received by the access service seeking authorization. When requests are received in real time, users expect real-time results. Therefore, the process of authorizing requests for access to or connection to a service should be processed as quickly as possible. Once a request is received, the user object may be stored in both a long-term data store and a short-term cache. To decouple the process of authorizing requests from the process of processing, updating, and manipulating the full user object, the cache may be subdivided into two different levels. The first cache may contain the full user object. The full user object may contain subcategories for each service that the user has applied for or is entitled to access. Each service subcategory may contain multiple fields describing the type of access allowed, the balance of content, data, usage restrictions, and / or other settings that may determine whether a particular request for that service should be permitted or denied.

[0004] In addition to the first cache, the system may include a second cache called a "surrogate" cache. The surrogate cache contains not full user objects but A compact user object may be included. The compact user object may include a field for each service, which may indicate whether a request for the corresponding service should be permitted. Instead of searching the full user object and processing multiple different fields within it to approve a request, the system can instead access the compact user object in the surrogate cache and approve / reject the request based on the values ​​of the fields for the corresponding service. The fields in the compact user object may be derived from the fields in the full user object using update logic that runs offline before the request is received. Therefore, the request does not have to wait for this processing to occur in response to the request being received, because it has already been done offline. Requests / rejections can be permitted without the extensive searching and processing delays associated with the full user object. Furthermore, the size of the compact user object allows it to be stored in the surrogate cache for each user, making cache misses unlikely, and typically the central datastore of the full user object will be accessed.

[0005] The fields for each service in the compact user object may contain binary yes / no values ​​to approve requests. Other implementations may use a range of values ​​such as green, yellow, and red. Intermediate values ​​(e.g., yellow) may allow access to a service with limited capacity. For example, a field in the compact user object may be set to yellow when it is about to exceed its allocation for time, data, storage, etc. Access may then be granted for requests that are unlikely to exceed the remaining allocation, or when other content restrictions are in place.

[0006] After a request is granted, the usage record may be stored offline and processed asynchronously. For example, records of granted access requests may be stored together in a queue that is processed as a batch by the system. A change event may be generated that updates the residual resource balance in the full user object in both the first cache and central storage. The update logic may then be executed again to generate new values ​​for fields in the compact user object in the surrogate cache.

[0007] A further understanding of the nature and merits of the various embodiments can be achieved by referring to the remainder of the specification and drawings, where similar reference numbers are used across several drawings to refer to similar components. In some cases, a sublabel is associated with the reference number to indicate one of several similar components. Where a reference number does not have a current sublabel designation, it is intended to refer to all such multiple similar components. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows an architecture for processing real-time requests to network services, according to several embodiments. [Figure 2] This figure shows an example of how an access service, according to several embodiments, can process a request using a full user object from the cache. [Figure 3] This figure shows an example of a multilevel cache that may be used between an access authorization process and central storage, according to several embodiments. [Figure 4] This figure shows how the values ​​of fields in a compact user object can be derived from multiple fields in a full user object, according to several embodiments. [Figure 5]This figure shows a flowchart of a method for optimizing the user object cache according to several embodiments. [Figure 6] This figure shows how a full user object may be updated after a request is granted using a second cache, according to some embodiments. [Figure 7] This figure shows a flowchart of a method for updating a surrogate cache according to several embodiments. [Figure 8] This is a data flow diagram for processing real-time requests, according to several embodiments. [Figure 9] This is a simplified block diagram of a distributed system for realizing some of the embodiments. [Figure 10] This is a simplified block diagram of the components of a system environment in which the services provided by the components of the system of the embodiment may be provided as cloud services. [Figure 11] This figure shows an exemplary computer system that can realize various embodiments. [Modes for carrying out the invention]

[0009] Detailed explanation This disclosure describes embodiments for evaluating requests for access to network services in real time. When a request is received, the user object may be stored in both a long-term data store and a short-term cache. The cache may include a first cache that stores the full version of the user object and a second cache or surrogate cache that stores a compact version of the user object. The compact version of the user object may include a field indicating whether subsequent requests for access to a particular service should be permitted. This field may be derived from several other fields in the full user object in the first cache. For example, prior to requesting access to a service, the full user object may include the service level, the type of access permitted, the remaining time balance for the user account, and / or other information related to a particular subscription to the service. To populate the field in the compact user object in the first cache, the system may process all this information to determine whether the subsequent request should be permitted. For example, if the user object describes a particular service level with a sufficient remaining balance, the field in the first cache may be set to a value such as "green" to indicate that the subsequent request should be permitted immediately without requiring further processing. After access is granted / denied based on this value in the compact user object, the system can process updates to the balance or value in the full user object offline. For example, the residual balance may be updated in the full user object after access is granted. This effectively separates the processing of real-time requests from the updating and evaluation of information in the user object.

[0010] Figure 1 shows an architecture 100 for processing real-time requests to network services according to several embodiments. In this example, a client system 102 may send requests for services 322 provided by a service provider 106 over the network. Client devices include telephones, smartphones, personal digital assistants (PDAs), laptop computers, notebook computers, tablet computers, desktop computers, digital home assistants (e.g., Amazon Alexa®, Google Home®, etc.), networked home devices in a smart home environment, smartwatches, virtual / augmented reality headsets, gateways or routers, server computers, and / or other types of computing devices. Service provider 106 may include any computing device. Service provider 106 may include any type of online service, such as an online movie provider, a cellular service provider, a streaming music provider, a news provider, a chat provider, an SMS or text provider, a distributor or server associated with an application running on a computing device ("App"), and / or other services that may be provided over a network.

[0011] To ensure a connection to or access to service 322, the client system may pass a request to access service 322 through access service 104. The term access service 104 is used generically to refer to an intermediate system between the client system 102 and the service provider 106. Access service 104 may act as a gatekeeper between the client system 102 and service 322, allowing or denying connection to or access to service 322. In one embodiment, access service 104 may be implemented by an Online Charging System (OCS), which is a system that enables a telecommunications service provider to monitor and charge customers in real time based on service usage. The OCS may handle user account balancing, rating, billing, control, correlation, etc. In some cases, the OCS may enable a telecom operator to ensure that balance limits are enforced and resources are authorized per transaction. In this example, the client system 102 may include a smartphone operating over a cellular service network. The service provider 106 may include a movie streaming service. The access service 104, implemented by the OCS, may be operated by a cellular service network and may be responsible for monitoring, authorizing, and tracking the balance for connections to the movie streaming service. This example using the OCS is provided as an example only and is not intended to be limiting. In this disclosure, the term access service 104 may apply to any service that is independent of the client system 102 and processes requests to access the service provider 106 in real time.

[0012] Generally speaking, users expect requests sent from client system 102 to be processed in real time. In this disclosure, the term “real time” may be used to describe responses received by the user via client system 102 without a delay of more than a few seconds (e.g., 5 seconds) when applied to online requests and responses. When a request is received by access service 104, access authorization process 110 may request a full user object 114 from cache 112. Using this full user object 114, access service 104 may establish or deny a connection 108 with service 322. To process these requests in real time, access service 104 can benefit from accessing a full user object 114 that describes many aspects of a user account. In the example in Figure 1, the full user object 114 may be stored in central storage 116. Central storage 116 may be implemented as a database, data store, online repository, and / or other form of persistent storage. Central storage 116 may be relatively large and may need to store user objects for tens of millions of user accounts. In some cases, the central storage 116 may be located in and / or operated by the service provider 106. For example, the central storage 116 may store user objects representing the user accounts of the service provider 106's subscribers. In some non-limiting examples, each user object may be 100kB to 20MB in size. Therefore, a considerable amount of storage is often required to implement the central storage 116. Furthermore, in Figure 1, the central storage 116 may be part of the service provider 106, but this example is limiting. It is not intended to be so. Other embodiments may allow the access service 104 to operate the central storage 116. In other embodiments, the central storage 116 may be operated by another third-party provider that manages accounts or user objects on behalf of the service provider 106.

[0013] The full user object 114 may contain a large amount of information. For example, the full user object 114 may contain any information relating to the service provider 106, service 322, and / or how the client system 102 can access service 322. The full user object 114 may contain information for individual services provided by the service provider 106. Thus, in addition to the information about service 322 shown in Figure 1, the full user object 114 may contain information about several further services provided by the service provider 106. If the central storage 116 is not operated by the service provider 106, the full user object 114 may also contain information associated with further services provided by other service providers 106. For each individual service, the full user object 114 may include specific service types, subscription levels, account information, purchased offerings, group memberships, relationships between different groups and / or users, rate overtime, voicemail, texts, accessible media content, usage balance, balance logic determining how the balance is adjusted / determined, and / or other information that may be associated with the use of service 322. The full user object 114 may be implemented as a live Java® object, and in one example, the full user object 114 may have a size of approximately 300kB.

[0014] To determine whether a connection to or access to service 322 should be permitted or denied, access service 104 may use information in the full user object 114 to determine whether a particular request should be permitted. For example, a request to stream content from service 322 may trigger access service 104 to check for further information that can be used to specifically determine whether a request for a particular portion of the content from service 322 should be permitted, such as the accessible content, service level, subscription, balance of remaining time, DRM restrictions, parental controls, geographical restrictions, available languages, and / or a specific portion of the content from service 322. Thus, the full user object 114 does not typically contain a single field that can be queried to determine whether access should be permitted. Instead, the full user object 114 may contain multiple fields that are processed by computing logic to determine whether a particular request should be permitted. The full user object 114 may contain all the information necessary for access service 104 to determine whether any request should be permitted or denied.

[0015] However, although the full user object 114 may contain all the necessary information, the size of the full user object 114 presents a technical challenge in permitting or denying requests in real time along with the number of full user objects that need to be stored by the central storage 116. Specifically, the nature of the large central storage 116 (e.g., a database) and the size of the full user object 114 may introduce long latency in requesting, receiving, and processing a relatively large full user object 114 for real-time decision-making. The latency in searching and processing the full user object 114 may be greater than what is acceptable to a user who expects a nearly instantaneous connection to the service 322. Further, since millions of full user objects are stored by the central storage 116, the central storage 116 is not normally implemented in memory and instead may require a slower and more persistent storage mechanism. and may require a slower and more persistent storage mechanism.

[0016] Instead of using the central storage 116 and the full collection of user objects stored by the central storage 116, the access service 104 may implement a cache 112 that stores a subset of a set of full user objects from the central storage 116. The cache 112 may be implemented using a memory structure that is faster and smaller than the central storage 116. For example, the cache 112 may be stored in memory and may enable fast access to the full user objects stored in the cache 112. This allows the full user object 114 to be utilized via the cache 112 without the significant latency that would otherwise be associated with retrieving the full user object 114 from the central storage 116.

[0017] Figure 2 shows an example of how an access service 104 may process a request 202 using a full user object 114 from a cache 112, according to several embodiments. When a request is received by the access service 104, the access authorization process 110 may request the full user object 114 from the cache 112. Using this full user object 114, it may establish or deny a connection 108 to the service 322. For example, the request itself may identify a user, a user identifier 204, a service type 206, information related to a specific content 208 requested from the service, and / or information related to the client system 102. Using this information, the access authorization process 110 may identify a specific user account and request the full user object 114 associated with that user account from the cache 112. If the full user object 114 is already available in the cache 112, this can be considered a "cache hit," and the full user object 114 may be provided to the access authorization process 110. If the full user object 114 is not yet in the cache 112, in a situation called a "cache miss," the cache may request the full user object 114 from the central storage 116. To efficiently store full user objects for real-time retrieval, the cache 112 can typically store fewer full user objects than are available in the central storage 116. Therefore, only a subset of full user objects may always be stored in the cache 112. As new requests are made for various full user objects, the cache 112 may evict existing user objects and replace them with new user objects from the central storage 116.

[0018] The cache 112 may include a full user object 114, and the full user object 114 may further include any and / or all information related to one or more services associated with the user account. The information in the full user object 114, together with the information in the request 202, can be used by the access authorization process 110 to determine whether access to a specific service should be permitted. For example, a user identifier 204 may be used to identify the location of a specific full user object 114. A service type 206 may be used to select one of the available services 210 (e.g., services that a user may have a subscription or account for) described in the full user object 114. The request 202 may include a request for a specific type of content 208, and this request can be compared with a plurality of fields 212 related to the specific service to determine whether access should be permitted. For example, if the request for content 208 includes a request for a specific movie to be streamed to the client device, the full user object 114 may search for user account details for the streaming movie service and determine whether all the account details in the plurality of fields 212 enable the specific movie specified by the content 208 to be streamed to the client device. In another example, the client device may send a request 202 for a cellular connection or a text connection to another user device. The user object 114 can access the text messaging plan, available time, in-network connection, out-of-network connection, and other information from the plurality of fields 212 for the cellular service to determine whether a text message connection or a cellular connection should be made according to the request 202. It should be noted that these examples are not intended to be limiting, and any type of service request may be used.

[0019] In many cases, the access authorization process 110 may look at the balance stored in the full user object 114 to determine whether to grant access according to the request 202. The full user object 114 may store the remaining balance of time, value, item, or other quantities that can be used for service requests. For example, one of several fields 212 related to a streaming movie service may contain the remaining number of movies that can be streamed by the user in a particular month. In another example, one of several fields 212 may contain the balance of time that can be used for cellular phone connections. Another example is storing the balance of data that can be downloaded in a particular month, and so on. These balances may be processed in the request 202 to determine whether the request 202 can be granted. For example, if the full user object 114 has a balance of 30 minutes of streaming remaining, and the request 202 includes a 2-hour movie as the requested content 208, the request may be rejected based on the remaining balance and the expected usage required for the request 202. In another example, a cellular connection may be requested, and there may be 100 minutes of available balance remaining in the full user object 114, in which case request 202 can be permitted.

[0020] Using cache 112 provides a solution for evaluating requests in real time, but it also presents another set of technical challenges. For example, a recurring request from one user may be separated by thousands or even millions of requests from other users. Therefore, as the number of user accounts increases, it becomes increasingly unlikely that cache 112 will maintain a full user object between requests from the same user. After the initial request is made and the full user object 114 is loaded into cache 112, it is likely that thousands or millions of other requests will be received from other users before another request is made from the same user. By the time a second request is received from the same user account associated with the full user object 114, cache 112 has likely already evicted the full user object 114 to favor the full user object from more recent requests. Therefore, a large number of requests will cause cache misses in cache 112, requiring longer delays to access central storage 116 with each cache miss.

[0021] To solve these and other technical problems, some embodiments can implement a caching structure for access services 104 using a special surrogate cache that acts as an intermediate between cache 112 and the access authorization process 110. This surrogate cache may contain "compact" user objects that are significantly smaller than the full user objects stored in cache 112. In some cases, the compact user objects in the surrogate cache may contain only one field for each service indicating whether a subsequent request should be permitted. This allows the surrogate cache to have all the advantages of both cache 112 and central storage 116. Specifically, the surrogate cache contains most, if not all, compact versions of full user objects in central storage 116 while maintaining the advantages of cache 112 being small, fast, and in-memory. It is possible.

[0022] Figure 3 shows an example of a multilevel cache that may be used between the access authorization process 110 and the central storage 116 according to several embodiments. For clarity, throughout the remainder of this disclosure, the cache 112 described earlier in Figures 1 and 2 may be referred to as the “first” cache 112, and the surrogate cache described earlier may be referred to as the “second” cache 302. Similarly, a full user object 114 stored in the first cache 112 may be referred to as the first user object 114, and a compact user object stored in the second cache 302 may be referred to as the second user object 304. The terms first, last, and second are used merely to distinguish one cache from the other and do not necessarily imply any order, importance, size, or other characteristics of the caches.

[0023] The second cache 302 can be constructed similarly to the first cache 112. The second cache 302 can be implemented in memory and may contain compact user objects that represent scaled-down or summarized versions of full user objects in the first cache 112. In some cases, the compact user object 304 may be several orders of magnitude smaller than the corresponding full user object 114 in the first cache 112. For example, the full user object 114 may be approximately 1 MB, while the compact user object may be approximately 10 to 20 bytes. Due to this dramatic reduction in size when transitioning from the full user object 114 to the compact user object 304, the second cache 302 can contain compact versions of more user objects than can be contained at once as full user objects in the first cache 112. This allows the second cache 302 to cover most, if not all, of the users in the central storage 116 while still maintaining speed and efficiency that would be superior to the speed and efficiency of the first cache 112.

[0024] The relationship between the second cache 302, which acts as a surrogate, and the first cache 112 can be compared to conventional multilevel caches such as L1, L2, and L3 cache structures. In conventional multilevel caches, higher cache levels typically operate using faster hardware / software than lower cache levels. Cache transparency exists when the lower levels of a cache typically contain all the data within its higher levels. Furthermore, since objects in the higher levels of a conventional cache are identical to objects in the lower levels of those caches, multiple identical copies of objects exist at different levels of the cache. In contrast, these embodiments use a second cache 302 that contains more user objects than the lower-level first cache 112, which is the opposite of conventional caches. Moreover, compact user objects stored in the second cache 302 are fundamentally different from full user objects stored in the first cache 112. Instead of including only a subset of multiple fields 212 within the full user object 114, the compact user object 304 may include new data fields that summarize the information stored in the full user object 114 or are derived from such information. Therefore, the second cache 302 generates a new type of information with new data and stores it in the compact user object 304. This is possible and beneficial because the second cache 302 can be specifically designed to provide the access authorization process 110 with information to approve or reject connection requests. The second cache 302 can be specifically designed for this purpose.

[0025] The compact user object 304 in the second cache 302 may include at least one field for each service that is accessible by the user account. Each field may be populated with a value indicating whether subsequent requests for that particular service should be allowed. Since a user may be allowed to access services at different times, different values ​​may be stored in different fields. For example, the first field for the first service may contain a green value indicating that subsequent requests for the first service should be allowed immediately. The second field for the second service may contain a red value indicating that subsequent requests for the second service should be denied.

[0026] When a request for a specific service is received, the access authorization process 110 may query the second cache 302 to retrieve the corresponding field for that service from the compact user object 304. This process may simply involve examining the value of the field for that service and comparing it to a threshold to enable authorization. For example, the access authorization process 110 may receive a green value from the compact user object 304 and immediately grant the service. This can be done without querying other fields in the full user object 114 or performing any processing on multiple fields 212 in the full user object 114. Thus, the use of the second cache 302 can reduce the overall latency of authorization of the request, even if the full user object 114 remains in the first cache 112. Furthermore, this dramatically reduces the possibility of a cache miss in the second cache 302. Since compact user objects are much smaller than full user objects, the second cache 302 can often store all compact user objects for the user making the request, whereas the first cache can only provide a very limited subset of full user objects that might otherwise be available.

[0027] In some embodiments, the surrogate cache 302 may act as a front-end for a back-end server or process. The access service 104 may receive requests as a front-end and establish a connection to the back-end process or service. When operating centrally, the access service 104 may track the balance and utilization of services across various service providers. For example, a cellular network may allow a certain amount of data to be downloaded over the network. A user may connect to many different service providers, and all downloads from those service providers may reflect a single download volume allocation assigned to the user account over the network.

[0028] Figure 4 shows how the value of field 306 in a compact user object is derived from multiple fields 212 in a full user object 114, according to several embodiments. The access service 104 may use update logic 402 to update the value of field 306 in the compact user object 304 using some of the multiple fields 212 in the full user object 114. In some cases, a single field from the multiple fields 212 may be used to generate the value of field 306. For example, the balance among the multiple fields 212 may be used to set the value of field 306 by comparing it to a threshold. In other cases, two or more fields such as balance, service level, and description type may be used.

[0029] The update logic 402 can be specific to each type of service. In some embodiments, the full user object 114 itself may contain the update logic 402. This allows the full user object 114 to be a self-sufficient concept that provides its own update logic 402. In other embodiments, the update logic 402 may be provided by the access service 104. The update logic may include mathematical and / or logical operations that combine one or more of several fields 212 to produce a value for field 306 in the compact user object 304. The details of each set of update logic 402 will differ for each specific service type, but several examples are provided here for illustrative purposes. In the first example, the update logic 402 may look up the remaining time, value and / or item balance from the full user object 114 and assign a value to field 306 by applying various thresholds. This derives the value of field 306 by determining the percentage of the allowance of access or balance remaining in the corresponding user object. Several implementations may use the 40-60 rule. If the available allocation is greater than 40%, the value may be set to green. If the available allocation is greater than 40% but less than 60%, the value may be set to yellow. If the available allocation is less than 60%, the value may be set to red. In the second example, the update logic 402 may analyze content restrictions, parent permissions, and other settings in the full user object 114 to determine what content can be streamed over the network. If permissions / restrictions are very high, the value may be set to red, while if permissions / restrictions are very low, the value may be set to green. In the third example, the update logic 402 may analyze some remaining text messages available under the text messaging plan and set a value based on the percentage of remaining. In the fourth example, the update logic 402 may analyze security settings and / or security events associated with the full user object 114. If the security threat is low, the value may be set to green, and the value will progressively increase from yellow to red as the level of security threat increases. Note that these specific implementation examples are provided as examples only and are not intended to be limiting.Any type of update logic 402 may be programmed to retrieve multiple fields 212 from the full user object 114 to derive a value indicating whether the subsequent request should be permitted.

[0030] In the example above, the value of field 306 in the compact user object 304 related to the service progresses through an enumerated list of values ​​such as green, yellow, and red. However, apart from this example, other types of values ​​may be used. For example, some embodiments may use a single Boolean value for each field that provides a simple yes / no evaluation for each service. This can make the compact user object 304 very small, as it uses only one bit for each service. Some embodiments may use a numerical value in field 306, such as time, value, individual object, residual balance such as storage space. Some embodiments may include a whitelist and / or blacklist of requests that should be allowed / denied. For example, the field may be set to green if it has a blacklist of content items that should not be streamed. Alternatively, the field may be set to red if it has a whitelist of content items that should be allowed.

[0031] In the example above, a green field value allowed the request to be allowed, and a red field value allowed the request to be rejected. In addition to these yes / no values, some embodiments may allow one or more intermediate values ​​(e.g., yellow). When an intermediate value is stored in field 306 of compact user object 304, the request may be allowed with limitations. For example, if 40% to 60% of the available allocation remains, the field value may be set to yellow. Once the request is received, it may be allowed, but with limitations imposed, such as on the amount of content provided by service 322. For example, a download limit of 40MB may be imposed for the call. A maximum length may be imposed. The service may only allow the download of a single movie, etc.

[0032] Figure 5 shows a flowchart 500 of a method for optimizing a user object cache according to several embodiments. This method may include a step (502) of accessing a first cache containing a first user object associated with a user account. The first cache may be the cache 112 described earlier in Figures 1 to 4, which stores full user objects. The first user object may be the full user object 114 described above. The first user object may include several fields associated with a service. The first user object may also include several further fields associated with other services. Overall, the first user object may be relatively large, such as 100kB or more, or 1MB or more. The first cache may be communicatively coupled to a datastore that stores a full list of full user objects for various services processed by an access service, such as the central storage 116 described above. The central storage 116 may be located at a service provider, access service, third-party provider, etc. The first cache may receive the first user object from the datastore as a result of a cache miss and maintain a subset of the full user objects compared to the full set of user objects found in the datastore.

[0033] This method may also include the step (504) of deriving fields in a second user object associated with a user account in the second cache. As previously illustrated in Figure 4, update logic may be used to derive the values ​​of fields in the second user object from multiple fields in the first user object. The second user object may be a compact user object containing only one field for each service. The second cache may also contain a compact user object for each full user object in the first cache. The second cache may also contain a compact user object for each full user object in the datastore or central storage. The second cache may be specifically configured to make a quick determination of whether access to or connection to a requested service should be permitted without requiring extensive processing, calculation, or loading of multiple fields in the first user object.

[0034] This method may further include the step (506) of receiving a request from a client device to access a service using a user account. As previously described in Figure 2, this request may identify a user account, a specific service, and a request / content associated with that service. The request may be received from any type of client device, and the service may include any type of service available over a network connection, such as telecom services, media services, communication services, and data storage services.

[0035] This method may further include the step (508) of accessing a field in a second user object in a second cache to determine whether the client device should be allowed to access the service. As previously described in Figures 3 and 4, the value of the field may be used to provide a quick decision on whether the request should be allowed, resulting in a real-time response from the access service. For example, some embodiments evaluate the field to allow / deny access within three seconds.

[0036] The specific steps shown in Figure 5 are performed according to various embodiments of the cache and It should be understood that this provides a specific method for optimizing access services. Other sequences of steps may be performed according to alternative embodiments. For example, alternative embodiments may perform the above steps in a different order. Furthermore, the individual steps shown in Figure 5 may include multiple substeps that can be performed in various sequences as appropriate for each individual step. Furthermore, additional steps may be added or removed depending on the specific application. Many modifications, variations, and alternatives are also included within the scope of this disclosure.

[0037] Figure 6 shows how the full user object 114 may be updated after a request is granted using the second cache 302, according to several embodiments. After a request is granted, some of the fields 212 in the full user object 114 may need to be updated. For example, if a request to send a text message is granted, the balance of the remaining text messages would need to be adjusted. In another example, if a movie is downloaded from service 322, the value of the payment obligation would need to be updated. One of the technical advantages provided by the second cache 302 is the ability to separate the ability to grant / deny requests in real time from the rest of the overhead associated with maintaining the full user object. Thus, the processing of the results of a granted access or connection can be done offline at once after the request is granted.

[0038] When a request is approved, a record 602 for this request may be generated. This record may be placed in the offline record storage queue 604. The record storage queue 604 may contain records from multiple different requests from multiple different user accounts. Each time a request is allowed or denied, a record 602 may be generated and added to the record storage queue 604. Record 602 may include the amount of resources provided or used by the connection to service 322. For example, record 602 may include the number of content objects streamed from service 322, the time spent on service 322, the amount spent on service 322, the number of messages sent through service 322, etc. Records in the record storage queue 604 do not have to be processed upon receipt. Instead, they may be stored for subsequent offline processing operations.

[0039] As described above, the second cache 302 allows the system to separate the approval of a request from the actual processing related to that request. The operation to update the full user object 114 may be stored until the system has sufficient processing power, bandwidth, memory availability, and / or other computing resources available to perform the operation. Each record in the record storage queue 604 may be processed sequentially to update the corresponding values ​​in several fields 212 of the full user object 114. For example, a record may contain a user identifier that can be used to retrieve the full user object 114 corresponding to that record 602. The above information that may be stored in record 602 may be used to update several fields 212 of the full user object 114. For example, the available resources or balance remaining may be adjusted or calculated to reflect the usage resulting from approving the request. Each record in the record storage queue 604 may be processed to update the corresponding full user object. This allows the record storage queue 604 to be processed as a batch operation when sufficient processing power is available to do so.

[0040] After the full user object 114 is updated, the process described earlier in Figures 3 and 4 may be executed to update the value stored in field 306 of the compact user object 304. For example, multiple fields 212 in the full user object 114 Update logic 406 may be executed on the new value in to generate a new value for field 306 in the corresponding compact user object 304. This operation may be performed for each changed full user object. Furthermore, the update operation for each record in the record storage queue 604 does not have to be performed in the first cache 112. Instead, this operation may be performed on the central storage 116. The central storage may be updated, and then the new version (or change event) of the full user object may be pushed back to the first cache 112. Alternatively, the object in the first cache 112 may be updated, and the new version of the full user object may be pushed back to the central storage 116 for updating.

[0041] Figure 7 shows a flowchart 700 of a method for updating a surrogate cache according to several embodiments. This method may include a step of granting access to the service (702). This method may begin execution when access is granted or a connection is established in accordance with a request for the service from a client device, as a result of the method in Figure 5 completing. This method may also include a step of generating a record of access (704). This record may include the amount of resources used by accessing the service, as previously described in Figure 6. This record may be added to a record update queue (706). This record update queue may store records from granted requests until they are ready to be processed. The update process may be triggered when sufficient computing resources are available, after the time limit has expired, after a threshold number of records have been received in the queue, when a request with a yellow status is granted, or when a request that is likely to fall within a threshold range exceeding the allocation is granted.

[0042] This method may also include the step (708) of updating the first user object in the first cache with records. This first user object may include the full user object described above. The remaining balances, such as time, data, items, and values, may be updated to reflect the result of granting access to multiple fields in the full user object in accordance with the above request. After the full user object has been updated, this method may include the step (710) of updating the second user object in the second cache. This second user object may represent a compact user object corresponding to the full user object. The compact user object may include fields that store values ​​derived from the fields in the full user object using the above update logic. In some cases, this method may also include the step of updating central storage with the new version of the full user object. These updates to the full user object in central storage and / or in the first cache may be performed using change events as described below.

[0043] It should be understood that the specific steps shown in Figure 7 provide a particular method for updating a surrogate cache according to various embodiments. Other sequences of steps may be performed according to alternative embodiments. For example, alternative embodiments may perform the above steps in a different order. Furthermore, the individual steps shown in Figure 7 may include multiple substeps that can be performed in various sequences as appropriate for each individual step. Furthermore, additional steps may be added or removed depending on the particular application. Many modifications, variations, and alternatives are also included within the scope of this disclosure.

[0044] Figure 8 is a data flow diagram for processing real-time requests according to several embodiments. Requests may be received by a real-time client 106 in a request-response stream 804. Each event in the request-response stream 804 may be processed sequentially by the real-time client 806. For example, authorization and authentication processes Stream 802 may be executed for each request in Stream 804. As part of processing real-time requests, access to the surrogate cache 808 is possible. For example, subscriber 1 may send a request to download content from a service provider. The surrogate cache 808 may return a green value to the real-time client 806 indicating that the request can be approved.

[0045] After approval, the real-time rating process 810 may receive changes in the remaining balance of resource allocations assigned to the user account. The real-time logic 814 may be executed to update the available balance (e.g., balance 3) and generate an event that can be passed to the rated event stream 816. The rated event processor 818 may perform updates on the corresponding full user object in the central storage 820. To complete the update process, a change event 822 may be generated and passed to the cache updater 824, which may update several fields in the full user object in the first cache. Then, as described above, the values ​​in the second cache may also be updated.

[0046] Each of the methods described herein can be implemented by a computer system. Each step of these methods may be performed automatically by the computer system and / or may require user inputs / outputs. For example, a user may provide inputs for each step of the method, each of which may be provided in response to a specific output generated by the computer system that requests such input. Each input may be received in response to a corresponding requested output. Furthermore, inputs may be received from a user, received as a data stream from another computer system, retrieved from a storage location, retrieved over a network, requested from a web service, and so on. Similarly, outputs may be provided to a user, provided as a data stream to another computer system, stored in a storage location, transmitted over a network, provided to a web service, and so on. In short, each step of the methods described herein may be performed by a computer system and may or may not require a user, and may require any number of inputs, outputs, and / or requests to the computer system. Those steps that do not require a user can be said to be performed automatically by the computer system without human intervention. Accordingly, in view of this disclosure, it will be understood that each step of each method described herein may be modified to include inputs and outputs to a user, or may be performed automatically by a computer system without human intervention, if any determination is made by the processor. Furthermore, some embodiments of each method described herein may be implemented as a set of instructions stored on a tangible, non-temporary storage medium to form a tangible software product.

[0047] Figure 9 is a simplified diagram of a distributed system 900 for realizing one of the embodiments. In the embodiment shown, the distributed system 900 includes one or more client computing devices 902, 904, 906, and 908, which are configured to run and operate client applications such as web browsers and dedicated clients (e.g., Oracle Forms) via one or more networks 910. A server 912 may be coupled to communicate with the remote client computing devices 902, 904, 906, and 908 via the network 910.

[0048] In various embodiments, the server 912 is one of the components of the system. They can be adapted to run one or more services or software applications provided by one or more entities. In some embodiments, these services may be web-based services or cloud services, or under a Software as a Service (SaaS) model, with client access This can be provided to users of computing devices 902, 904, 906, and / or 908. As a result, users operating client computing devices 902, 904, 906, and / or 908 can interact with server 912 using one or more client applications and take advantage of the services provided by these components.

[0049] In the configuration shown in the figure, the software components 918, 920, and 922 of system 900 are shown as being implemented on server 912. In other embodiments, one or more of the components of system 900 and / or the services provided by these components may also be implemented by one or more of the client computing devices 902, 904, 906, and / or 908. In that case, a user operating the client computing device can use one or more client applications to access the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that various different system configurations are possible, and these configurations may differ from the distributed system 900. Therefore, the embodiment shown in the figure is an example of a distributed system for implementing the system of the embodiment and is not intended to be limiting.

[0050] Client computing devices 902, 904, 906 and / or 908 may be portable handheld devices (e.g., iPhone®, mobile phones, iPad®, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass® head-mounted displays) that run software such as Microsoft Windows Mobile® and / or various mobile operating systems such as iOS®, Windows Phone, Android, BlackBerry 10, Palm OS, and are capable of connecting to the Internet, email, Short Message Service (SMS), Blackberry®, or other communication protocols. Client computing devices may also be general-purpose personal computers, including, for example, personal computers and / or laptop computers running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. Client computing devices may also be workstation computers running any of the various UNIX® or UNIX-like operating systems available on the market, including but not limited to various GNU / Linux operating systems such as Google Chrome OS. Alternatively or additionally, client computing devices 902, 904, 906, and 908 may be other electronic devices that can communicate via network 910, such as thin client computers, internet-connected gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect® gesture input devices), and / or personal messaging devices.

[0051] The exemplary distributed system 900 is shown with four client computing devices, but any number of client computing devices may be supported. Other devices, such as devices with sensors, may also interact with the server 912. good.

[0052] The network 910 in the distributed system 900 includes, but is not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (System Network Architecture), IPX (Internet Packet Switching), AppleTalk, etc. It may be any type of network that can support data communication using any of the various protocols available on the market. For example, network 910 may be a local area network (LAN), such as one based on Ethernet®, Token Ring, etc. Network 910 may be a wide area network or the internet. It may also be a virtual private network (VPN). ), intranet, extranet, public switched telephone network (PSTN), infrared network, wireless network (for example, US Electrical Electrical This may include virtual networks that operate under any of the following: the IEEE 802.11 protocol suite, Bluetooth®, and / or other wireless protocols, and / or any combination of these and / or other networks.

[0053] Server 912 may consist of one or more general-purpose computers, dedicated server computers (including, for example, PC (personal computer) servers, UNIX® servers, midrange servers, mainframe computers, rack-mount servers, etc.), server farms, server clusters, or other appropriate configurations and / or combinations. In various embodiments, Server 912 may be adapted to run one or more services or software applications described in the above disclosure. For example, Server 912 may correspond to a server for performing the above processing according to one embodiment of this disclosure.

[0054] Server 912 may run an operating system including any of the above operating systems and any server operating system available on the market. Server 912 may also run any of a variety of further server applications and / or middle-tier applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, Java® servers, and database servers. Exemplary database servers include, but are not limited to, those available on the market from Oracle, Microsoft, Sybase, IBM (International Business Machines), and others.

[0055] In some implementations, server 912 may include one or more applications for analyzing and organizing data feeds and / or event update information received from users of client computing devices 902, 904, 906, and 908. For example, the data feeds and / or event update information may be received from one or more third-party sources and continuous data streams, such as Twitter (registered trademark). This may include, but is not limited to, feeds, Facebook® updates, or real-time updates. These may include real-time events related to sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, and automotive traffic monitoring. Server 912 may also include one or more applications for displaying these data feeds and / or real-time events via one or more display devices of client computing devices 902, 904, 906, and 908.

[0056] The distributed system 900 may also include one or more databases 914 and 916. Databases 914 and 916 may be located in various locations. For example, one or more of databases 914 and 916 may reside on a non-temporary storage medium local to (and / or located within) server 912. Alternatively, databases 914 and 916 may be remote from server 912 and communicate with server 912 via a network-based connection or a dedicated connection. In one embodiment, databases 914 and 916 may reside within a Storage Area Network (SAN). Similarly, any files necessary to perform functions attributed to server 912 may be stored locally on and / or remotely from server 912, as appropriate. In one embodiment, databases 914 and 916 may include relational databases, such as those provided by Oracle, adapted to store, update, and retrieve data in response to SQL-formatted commands.

[0057] Figure 10 is a simplified block diagram of one or more components of a system environment 1000 in which services provided by one or more components of the system of the embodiment may be provided as cloud services, according to one embodiment of the present disclosure. In the embodiment shown, the system environment 1000 includes one or more client computing devices 1004, 1006, and 1008 that a user can use to interact with a cloud infrastructure system 1002 that provides cloud services. These client computing devices may be configured to operate client applications, such as a web browser, a dedicated client application (e.g., Oracle Forms), or any other application that a user of the client computing device can use to interact with the cloud infrastructure system 1002 and use services provided by the cloud infrastructure system 1002.

[0058] It should be understood that the cloud infrastructure system 1002 shown in the figure may have components other than those shown. Furthermore, the system shown in the figure is only one example of a cloud infrastructure system that can incorporate several embodiments. In some other embodiments, the cloud infrastructure system 1002 may have more or fewer components than shown in the figure, may combine two or more components, or may have different configurations or arrangements of components.

[0059] Client computing devices 1004, 1006, and 1008 may be similar to the client computing devices described above for 902, 904, 906, and 908.

[0060] An exemplary system environment 1000 is shown with three client computing devices, but any number of client computing devices may be supported. Other devices, such as devices with sensors, may interact with the cloud infrastructure system 1002.

[0061] Network 1010 can facilitate data communication and exchange between clients 1004, 1006, and 1008 and the cloud infrastructure system 1002. Each network supports data communication using one of the various protocols available on the market, including the protocol described above for network 910. It may be any type of network that can be connected.

[0062] The cloud infrastructure system 1002 may include one or more computers and / or servers that may include the above-described components for server 912.

[0063] In certain embodiments, the services provided by the cloud infrastructure system may include a number of services made available on demand to users of the cloud infrastructure system, such as online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, and managed technical support services. The services provided by the cloud infrastructure system can be dynamically scaled to meet the needs of its users. A specific instance of a service provided by the cloud infrastructure system is referred to herein as a “service instance.” Generally, any service made available to users from a cloud service provider’s system via a communication network such as the Internet is referred to as a “cloud service.” Typically, in a public cloud environment, the servers and systems that make up the cloud service provider’s system are different from the customer’s own on-premises servers and systems. For example, the cloud service provider’s system can host applications, and users can order and use these applications on demand via a communication network such as the Internet.

[0064] In some examples, services in a computer network cloud infrastructure may include secure computer network access to storage, hosted databases, hosted web servers, software applications, or other services provided to users by the cloud vendor. For example, a service may include password-protected access to remote storage on the cloud over the internet. Another example is a service that may include a web service-based hosted relational database and scripting language middleware engine for private use by networked developers. Yet another example is a service that may include access to an email software application hosted on the cloud vendor's website.

[0065] In certain embodiments, the cloud infrastructure system 1002 may include a set of applications, middleware, and database service offerings delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such a cloud infrastructure system is the Oracle Public Cloud offered by the assignee.

[0066] In various embodiments, the cloud infrastructure system 1002 may be adapted to automatically provision, manage, and track customer subscriptions to services provided by the cloud infrastructure system 1002. The cloud infrastructure system 1002 can provide cloud services through various deployment models. For example, the services may be provided under a public cloud model in which the cloud infrastructure system 1002 is owned by an organization that sells cloud services (e.g., owned by Oracle), and the services are made available to the general public or companies in different industries. As another example, the services may be provided in which the cloud infrastructure system 1002 is operated exclusively for a single organization, and services are provided to one or more entities within that organization. Cloud services may be provided under a private cloud model that can provide services. Alternatively, cloud services may be provided under a community cloud model in which the cloud infrastructure system 1002 and the services provided by the cloud infrastructure system 1002 are shared by several organizations within the relevant community. Alternatively, cloud services may be provided under a hybrid cloud model that is a combination of two or more different models.

[0067] In some embodiments, the services provided by the cloud infrastructure system 1002 fall into the categories of Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS) This may include one or more services offered under the category of ) or other service categories, including hybrid services. Customers can order one or more services offered by the cloud infrastructure system 1002 through a subscription order. The cloud infrastructure system 1002 then performs processing to provide the services of this customer's subscription order.

[0068] In some embodiments, the services provided by the cloud infrastructure system 1002 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that fall under the SaaS category. For example, the SaaS platform may provide the ability to build and deliver a set of on-demand applications on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure for providing SaaS services. By using the services provided by the SaaS platform, customers can utilize applications that run on the cloud infrastructure system. Customers can obtain application services without having to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration, and business flexibility for large organizations.

[0069] In some embodiments, platform services may be delivered by a cloud infrastructure system via a PaaS platform. The PaaS platform may be configured to provide cloud services that fall under the PaaS category. Examples of platform services include, but are not limited to, services that enable organizations (such as Oracle) to organize and consolidate existing applications on a shared, common architecture, and the ability to build new applications that leverage the shared services provided by the platform. The PaaS platform can manage and control the underlying software and infrastructure for providing PaaS services. Customers can obtain PaaS services provided by the cloud infrastructure system without having to purchase separate licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS) and Oracle Database Cloud Service (DBCS).

[0070] By utilizing the services provided by the PaaS platform, customers can leverage programming languages ​​and tools supported by the cloud infrastructure system and control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (e.g., Oracle Fusion middleware services), and Java cloud services. In one embodiment, the database cloud service may support a shared service deployment model that enables an organization to pool database resources and provide customers with a database-as-a-service in the form of a database cloud. The middleware cloud service may provide a platform for customers to develop and deploy various business applications on the cloud infrastructure system, and the Java cloud service may provide a platform for customers to deploy Java applications on the cloud infrastructure system.

[0071] In cloud infrastructure systems, various different infrastructure services can be provided by IaaS platforms. These infrastructure services facilitate the management and control of underlying computing resources, such as storage, networking, and other basic computing resources, for customers using services provided by SaaS and PaaS platforms.

[0072] In certain embodiments, the cloud infrastructure system 1002 may also include infrastructure resources 1030 for providing resources used to provide various services to customers of the cloud infrastructure system. In one embodiment, the infrastructure resources 1030 may include a pre-integrated and optimized combination of hardware such as servers, storage, and networking resources for running services provided by the PaaS platform and SaaS platform.

[0073] In some embodiments, resources in the cloud infrastructure system 1002 may be shared by multiple users and dynamically reallocated on a request basis. Furthermore, resources may be allocated to users in different time zones. For example, the cloud infrastructure system 1030 maximizes resource utilization by enabling a first group of users in a first time zone to utilize resources in the cloud infrastructure system over a specific period of time, and then reallocating the same resources to another group of users in a different time zone.

[0074] In certain embodiments, several internal shared services 1032 may be provided that are shared by various components or modules of the cloud infrastructure system 1002 and by services provided by the cloud infrastructure system 1002. These internal shared services may include, but are not limited to, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, services to enable cloud support, email services, notification services, file transfer services, and the like.

[0075] In certain embodiments, the cloud infrastructure system 1002 can provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) within the cloud infrastructure system. The cloud management functionality may include, for example, the ability to provision, manage, and track customer subscriptions received by the cloud infrastructure system 1002.

[0076] In one embodiment, as shown in the figure, the cloud management functionality can be provided by one or more modules, such as an order management module 1020, an order orchestration module 1022, an order provisioning module 1024, an order management and monitoring module 1026, and an identity management module 1028. These modules may include one or more computers and / or servers, or may be provided using such computers and / or servers, which may be general-purpose computers, dedicated server computers, server farms, server clusters, or other appropriate configurations and / or combinations.

[0077] In exemplary operation 1034, a customer may interact with the cloud infrastructure system 1002 using a client device such as client device 1004, 1006, or 1008 by requesting one or more services provided by the cloud infrastructure system 1002 and placing an order for a subscription to one or more services provided by the cloud infrastructure system 1002. In certain embodiments, a customer may access a cloud user interface (UI), i.e., cloud UI 1012, cloud UI 1014, and / or cloud UI 1016, and place a subscription order through these UIs. The order information received by the cloud infrastructure system 1002 in response to the customer's order may include information identifying the customer and one or more services provided by the cloud infrastructure system 1002 that the customer intends to subscribe to.

[0078] After a customer places an order, the order information is received via the cloud UI 1012, 1014, and / or 1016.

[0079] In operation 1036, the order is stored in the order database 1018. The order database 1018 may be one of several databases operated by the cloud infrastructure system 1018 and operated in conjunction with other system elements.

[0080] In operation 1038, order information is transferred to the order management module 1020. In some cases, the order management module 1020 may be configured to perform billing and charging functions related to the order, such as verifying the order and reserving the order at the same time as verification.

[0081] In operation 1040, information about the order is communicated to the order orchestration module 1022. The order orchestration module 1022 may use this order information to orchestrate the provisioning of services and resources for the order placed by the customer. In some cases, the order orchestration module 1022 may orchestrate the provisioning of resources to support services requested using the services of the order provisioning module 1024.

[0082] In a particular embodiment, the order orchestration module 1022 enables the management of the business processes associated with each order, so that the order is provisioned Business logic is applied to determine whether to proceed with the order. In operation 1042, upon receiving an order for a new subscription, the order orchestration module 1022 sends a request to the order provisioning module 1024 to allocate and configure the resources necessary to fulfill the subscription order. The order provisioning module 1024 enables the allocation of resources for the service ordered by the customer. The order provisioning module 1024 provides a level of abstraction between the cloud services provided by the cloud infrastructure system 1000 and the physical implementation layer used to provision resources to provide the requested service. This allows the order orchestration module 1022 to be isolated from implementation details such as whether services and resources are actually provisioned on the fly or whether services and resources are pre-provisioned and only allocated / assigned when requested.

[0083] In operation 1044, once the services and resources are provisioned, a notification of the provided services may be sent by the order provisioning module 1024 of the cloud infrastructure system 1002 to the customers on client devices 1004, 1006 and / or 1008.

[0084] In operation 1046, customer subscription orders may be managed and tracked by the order management and monitoring module 1026. In some cases, the order management and monitoring module 1026 may be configured to collect service utilization statistics for subscription orders, such as the amount of storage used, the amount of data transferred, the number of users, and system uptime and system downtime.

[0085] In certain embodiments, the cloud infrastructure system 1000 may include an identity management module 1028. The identity management module 1028 may be configured to provide identity services in the cloud infrastructure system 1000, such as access management and authorization services. In some embodiments, the identity management module 1028 may control information about customers who wish to use the services provided by the cloud infrastructure system 1002. Such information may include information that authenticates the identity of such customers and information that describes what actions those customers are authorized to perform on various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). The identity management module 1028 may also include managing descriptive information about each customer and information about who can access and modify such descriptive information and how.

[0086] Figure 11 shows an exemplary computer system 1100 that can implement various embodiments. System 1100 can be used to implement any of the computer systems described above. As shown in the figure, computer system 1100 includes a processing unit 1104, which communicates with several peripheral subsystems via a bus subsystem 1102. These peripheral subsystems may include a processing acceleration unit 1106, an I / O subsystem 1108, a storage subsystem 1118, and a communication subsystem 1124. The storage subsystem 1118 includes a tangible computer-readable storage medium 1122 and system memory 1110.

[0087] The bus subsystem 1102 connects various components of the computer system 1100. It provides a mechanism for the terminal and subsystems to communicate with each other as intended. Although the bus subsystem 1102 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 1102 may be one of several types of bus structures, including a memory bus or memory controller, peripheral bus and local bus, using any of the various bus architectures. For example, such architectures include the Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus and IEEE P1386 This may include peripheral component interconnect (PCI) buses, which can be implemented as a mezzanine bus manufactured in accordance with the .1 standard.

[0088] A processing unit 1104, which can be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 1100. One or more processors may be included in the processing unit 1104. These processors may include single-core or multi-core processors. In certain embodiments, the processing unit 1104 may be implemented as one or more independent processing units 1132 and / or 1134, each containing a single or multi-core processor. In other embodiments, the processing unit 1104 may be implemented as a quad-core processing unit formed by integrating two dual-core processors onto a single chip.

[0089] In various embodiments, the processing unit 1104 can execute various programs in response to program code and can maintain multiple concurrently running programs or processes. Some or all of the program code to be executed may always reside within the processor 1104 and / or the storage subsystem 1118. Through suitable programming, the processor 1104 can provide the various functions described above. Furthermore, the computer system 1100 may include a processing acceleration unit 1106, which may include a digital signal processor (DSP), a special-purpose processor, and the like.

[0090] The I / O subsystem 1108 may include user interface input devices and user interface output devices. User interface input devices may include pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may also include motion sensing and / or gesture recognition devices such as Microsoft Kinect® motion sensors, which enable users to interact with input devices, such as Microsoft Xbox® 360 game controllers, by controlling them through a natural user interface using gestures and verbal commands. User interface input devices may also include eye gesture recognition devices such as Google Glass® blink detectors, which detect eye movements from the user (e.g., blinks while taking pictures and / or making menu selections) and translate eye gestures into input to an input device (e.g., Google Glass®). Furthermore, the user interface input device may include a voice recognition sensing device that enables the user to interact with a voice recognition system (e.g., Siri® Navigator) via voice commands.

[0091] User interface input devices may include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic tablets, audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. Furthermore, user interface input devices may include medical imaging input devices such as computed tomography devices, magnetic resonance imaging devices, positional emission tomography devices, and medical ultrasound devices. User interface input devices may also include audio input devices such as MIDI keyboards and digital musical instruments.

[0092] User interface output devices may include non-visual displays such as display subsystems, indicator lights, or audio output devices. Display subsystems may also include flat panel devices such as those using cathode ray tubes (CRTs), liquid crystal displays (LCDs), or plasma displays, projection devices, and touchscreens. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from the computer system 1100 to a user or another computer. For example, user interface output devices may include, but are not limited to, a variety of display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, audio output devices, and modems.

[0093] The computer system 1100 may include a storage subsystem 1118 containing software elements, which are currently shown to be located in the system memory 1110. The system memory 1110 may store program instructions that are loadable and executable on the processing unit 1104, and data generated during the execution of these programs.

[0094] Depending on the configuration and type of the computer system 1100, the system memory 1110 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM) or flash memory). Generally, RAM is readily accessible by the processing unit 1104 and / or contains data and / or program modules currently being operated and executed by the processing unit 1104. In some implementations, the system memory 1110 is static random access memory (SRAM). It may include several different types of memory, such as Random Access Memory (RRAM) or Dynamic Random Access Memory (DRAM). In the implementation example, a Basic Input / Output System (BIOS), which includes basic routines that help transfer information between elements within the computer system 1100 during startup, may typically be stored in ROM. As an example, system memory 1110 may include application programs such as client applications, web browsers, middle-tier applications, and relational database management systems (RDBMS). 1112, program data 1114, and operating systems 1116 are also shown, but are not limited to them. For example, operating systems 1116 include Microsoft Windows®, Apple Macintosh® and / or Linux operating systems, UNIX® or UNIX-like operating systems available on various markets (various GNU / Linux operating systems, Google This includes, but is not limited to, Chrome® OS, as well as / or iOS, Windows® Phone, Android® OS, and BlackBerry® This may include various versions of mobile operating systems, such as the trademarked 10 OS and Palm® OS operating system.

[0095] The storage subsystem 1118 may also provide a tangible computer-readable storage medium for storing basic programming and data structures that provide the functionality of several embodiments. Software (programs, code modules, instructions) that, when executed by the processor, provides the above functionality may be stored in the storage subsystem 1118. These software modules or instructions may be executed by the processing unit 1104. The storage subsystem 1118 may also provide a repository for storing data used according to several embodiments.

[0096] The storage subsystem 1100 may also include a computer-readable storage medium reader 1120 that can be further connected to the computer-readable storage medium 1122. Together with the system memory 1110, and optionally in combination with the system memory 1110, the computer-readable storage medium 1122 can comprehensively represent a combination of remote, local, fixed, and / or removable storage devices and storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information.

[0097] Computer-readable storage media 1122, including code or a portion of code, may also include any suitable media, including volatile and non-volatile, removable and non-removable media, and other storage and communication media, which are implemented in any way or technique for storing and / or transmitting information. This may include tangible computer-readable storage media such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer-readable media. This may also include intangible computer-readable media such as data signals, data transmissions or other media, which can be used to transmit desired information and are accessible by the computing system 1100.

[0098] As an example, the computer-readable storage medium 1122 includes a hard disk drive that reads and writes to a non-removable non-volatile magnetic medium, a magnetic disk drive that reads and writes to a removable non-volatile magnetic disk, and a removable non-volatile magnetic disk such as a CD-ROM, DVD, or Blu-ray® disc or other optical media. It may include an optical disc drive that reads and writes to an optical disc. The computer-readable storage medium 1122 may include a Zip® drive, a flash memory card, or a universal Computer-readable storage media 1122 may include, but are not limited to, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD discs, and digital videotapes. This may include memory-based SSDs, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM-based and flash memory-based SSDs. These disk drives and their associated computer-readable media are computer-readable life The computer system 1100 can be provided with non-volatile storage for data structures, program modules, and other data.

[0099] The communication subsystem 1124 provides an interface with other computer systems and networks. The communication subsystem 1124 acts as an interface for receiving data from other systems and transmitting data from computer system 1100 to other systems. For example, the communication subsystem 1124 may enable computer system 1100 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 1124 includes radio frequency (RF) transceiver components for accessing wireless voice and / or data networks (e.g., using cellular telephone technology, 3G, 4G, or advanced data network technologies such as EDGE (Enhanced Data Rate for Global Evolution), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof). Global Positioning System (GPS) receiver The components and / or other components may be included. In some embodiments, the communication subsystem 1124 may provide a wired network connection (e.g., Ethernet) in addition to, or instead of, the wireless interface.

[0100] In some embodiments, the communication subsystem 1124 can also receive input communications in the form of structured and / or unstructured data feeds 1126, event streams 1128, event update information 1130, etc., on behalf of one or more users who may be using the computer system 1100.

[0101] As an example, the communication subsystem 1124 handles Twitter® feeds and Facebook (Registered Trademark) Update information, Rich Site Summary (RSS) feed, and / or may be configured to receive in real time data feeds 1126 from users of social networks and / or other communication services, such as real-time updates from one or more third-party sources.

[0102] Furthermore, the communication subsystem 1124 may be configured to receive data in the form of a continuous data stream, which may include an event stream 1128 of real-time events and / or event update information 1130 that may be inherently continuous or infinite, without a clear end. Examples of applications that generate continuous data include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, and automotive traffic monitoring.

[0103] Furthermore, the communication subsystem 1124 may be configured to output structured and / or unstructured data feeds 1126, event streams 1128, event update information 1130, etc., to one or more databases that can communicate with one or more streaming data source computers coupled to the computer system 1100.

[0104] The computer system 1100 may be one of various types, including handheld portable devices (e.g., iPhone® mobile phones, iPad® computing tablets, PDAs), wearable devices (e.g., Google Glass® head-mounted displays), PCs, workstations, mainframes, kiosks, server racks, or other data processing systems.

[0105] Due to the ever-changing nature of computers and networks, the description of the computer system 1100 shown in the figure is intended only as an example. Many other configurations are possible, having more or fewer components than the system shown in the figure. For example, customized hardware may be used, and / or certain elements may be implemented in hardware, firmware, software (including applets) or a combination thereof. Furthermore, connectivity to other computing devices, such as network input / output devices, may be utilized. Based on the disclosures and teachings provided herein, other ways and / or methods for implementing various embodiments should be apparent.

[0106] The above description includes numerous specific details to ensure a thorough understanding of the various embodiments. However, it will be apparent that some embodiments can be implemented without some of these specific details. In other examples, well-known structures and devices are shown in block diagram form.

[0107] The above description provides only illustrative embodiments and is not intended to limit the scope, application, or configuration of this disclosure. Rather, the above description of various embodiments provides a practical degree of disclosure for realizing at least one embodiment. It should be understood that various modifications may be made in terms of the function and arrangement of elements without departing from the spirit and scope of some embodiments described in the appended claims.

[0108] Specific details are provided in the above description to ensure a full understanding of the embodiments. However, it is understood that embodiments can be implemented even without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in the form of block diagrams so as not to obscure the embodiments with unnecessary details. In other examples, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary details to avoid obscuring the embodiments.

[0109] Furthermore, note that individual embodiments may be described as processes shown as flowcharts, flow diagrams, data flow diagrams, structural diagrams, or block diagrams. While flowcharts may describe operations as sequential processes, many of these operations can be performed in parallel or simultaneously. The order of these operations may also be reordered. A process terminates when its operations are complete, but it may have additional steps not shown in the diagram. A process can correspond to a method, function, procedure, subroutine, subprogram, etc. If a process corresponds to a function, its termination may correspond to the function returning to the calling function or main function.

[0110] The term “computer-readable medium” includes, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, and various other media that can store, contain, or hold instructions and / or data. A code segment or machine-executable instruction may represent a procedure, function, subprogram, program, routine, subroutine, module, software package, class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory content. Information, arguments, parameters, data, etc., may be passed, transferred, or transmitted via any preferred means, including memory sharing, message passing, token passing, network transmission, etc.

[0111] Furthermore, the embodiments can be implemented by hardware, software, firmware, middleware, microcode, a hardware description language, or any combination thereof. When implemented by software, firmware, middleware, or microcode, the program code or code segments for performing the required tasks may be stored on a machine-readable medium. The processor can then perform the required tasks.

[0112] While features are described in the above specification with reference to their specific embodiments, it should be recognized that not all embodiments are limited thereto. Various features and aspects of some embodiments may be used individually or in combination. Furthermore, embodiments can be used in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Therefore, the specification and drawings should be considered illustrative rather than restrictive.

[0113] Furthermore, for illustrative purposes, the methods are described in a specific order. It should be understood that in alternative embodiments, these methods may be performed in a different order than described. It should also be understood that the above methods may be performed by hardware components, or by a sequence of instructions that can be used to cause a machine, such as a general-purpose or special-purpose processor or logic circuit programmed with machine-executable instructions, to perform these methods. These machine-executable instructions may be stored in one or more machine-readable media, such as a CD-ROM or other type of optical disk, a floppy diskette, ROM, RAM, EPROM, EEPROM, magnetic or optical card, flash memory, or other type of machine-readable media suitable for storing electronic instructions. Alternatively, these methods may be performed by a combination of hardware and software.

Claims

1. A non-temporary computer-readable medium having instructions, wherein, when executed by one or more processors, the instructions cause the one or more processors to perform an operation, and the operation is The operation further includes accessing a first cache containing a first user object associated with a user account, wherein the first user object contains a plurality of fields associated with the service, and the operation further includes: The operation further comprises deriving a field in a second user object associated with the user account in a second cache, wherein the field in the second user object is derived from the plurality of fields of the first user object, the field indicates whether access to the service is permitted, the second user object is smaller than the first user object, and the operation further comprises Receiving a request from a client device to access the service using the aforementioned user account, A non-temporary computer-readable medium comprising accessing the field in the second user object in the second cache to determine whether the client device is able to access the service.

2. The non-temporary computer-readable medium according to claim 1, wherein the second cache corresponds to a compact version of the first cache, and the second cache maintains a compact version of user objects evicted from the first cache.

3. The non-temporary computer-readable medium according to claim 2, wherein the second user object is approximately 10 times smaller than the first user object.

4. The non-temporary computer-readable medium according to claim 2, wherein the second user object is located next to an indicator of whether access to the service is permitted.

5. The non-temporary computer-readable medium according to claim 1, wherein the field in the second user object stores a value that is one of a plurality of values ​​indicating different access levels.

6. The aforementioned multiple values ​​are, A first value indicating that access to the aforementioned service is permitted, A second value indicating that restricted access to the aforementioned service is permitted, A non-temporary computer-readable medium according to claim 5, comprising a third value indicating that access to the aforementioned service is not permitted.

7. The non-transient computer-readable medium according to claim 6, wherein the second value indicating that restricted access to the service is permitted limits time or bandwidth during access.

8. The first user object includes multiple fields for multiple services, The non-temporary computer-readable medium according to claim 1, wherein the second user object includes a single field for each of the plurality of services.

9. Determining whether the client device is able to access the service is to access the first user object in the first cache. A non-temporary computer-readable medium according to claim 1, which does not require the following:

10. The non-temporary computer-readable medium according to claim 1, wherein deriving the field in the second user object includes determining the percentage of allowed access remaining in the user account.

11. The aforementioned operation further, A non-temporary computer-readable medium according to claim 1, comprising generating a record of access to the service indicating the amount of access used by the client device.

12. The aforementioned operation further, A non-temporary computer-readable medium according to claim 11, comprising adding the record of the access to the service to an offline record storage queue.

13. The aforementioned operation further, A non-temporary computer-readable medium according to claim 12, comprising processing the records from the offline record storage queue and updating the plurality of fields for the first user object in the first cache.

14. The aforementioned operation further, A non-temporary computer-readable medium according to claim 12, comprising processing the records from the offline record storage queue to update the database of user objects in the service.

15. The aforementioned operation further, A non-temporary computer-readable medium according to claim 13, comprising updating the field in the second user object in the second cache based on the updated field in the first user object in the first cache, to process a subsequent request to access the service.

16. The non-transient computer-readable medium according to claim 13, wherein when the request is received from the client device, a decision is made in real time as to whether to allow the client device to access the service, and the record from the offline record storage queue is processed after the client device is granted access to access the service.

17. The aforementioned operation further, A non-transient computer-readable medium according to claim 13, comprising processing each of a plurality of records in the offline record storage queue, wherein the plurality of records are received from a plurality of different requests accessing a plurality of different services, and the plurality of records are processed together as a batch.

18. The service is a non-temporary computer-readable medium according to claim 1, including a telecom service.

19. A method for optimizing the user object cache, The method further includes the step of accessing a first cache containing a first user object associated with a user account, wherein the first user object contains a plurality of fields associated with a service, and the method further includes The method further comprises the step of deriving a field in a second user object associated with the user account in a second cache, wherein the field in the second user object is derived from the plurality of fields of the first user object, the field indicates whether access to the service is permitted, the second user object is smaller than the first user object, and the method further The steps include receiving a request from a client device to access the service using the user account, A method comprising the steps of accessing the field in the second user object in the second cache to determine whether the client device can access the service.

20. It is a system, One or more processors, The system comprises one or more memory devices having instructions, and when the instructions are executed by the one or more processors, they cause the one or more processors to perform an operation, and the operation is The operation further includes accessing a first cache containing a first user object associated with a user account, wherein the first user object contains a plurality of fields associated with the service, and the operation further includes: The operation further comprises deriving a field in a second user object associated with the user account in a second cache, wherein the field in the second user object is derived from the plurality of fields of the first user object, the field indicates whether access to the service is permitted, the second user object is smaller than the first user object, and the operation further comprises Receiving a request from a client device to access the service using the aforementioned user account, A system comprising accessing the field in the second user object in the second cache to determine whether the client device is allowed to access the service.

Images