Surrogate Cache for Optimized Service Access with Compact User Objects and Offline Database Updates

Abstract

When a request to access a service is received, the user object may be stored in both a long-term data store and a short-term cache. The cache may be divided into a regular cache, which stores the full version of the user object, and a surrogate cache, which stores a compact version of the user object. The compact version of the user object may include a field derived from the full user object that indicates whether a subsequent request to access a particular service should be allowed. After access is granted / denied based on this value in the compact user object, the system may process updates to the full user object offline. The ability to approve / deny requests at high speed using this surrogate cache structure decouples 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 September 9, 2020, entitled "SURROGATE CACHE FOR OPTIMIZED SERVICE ACCESS WITH COMPACT USER OBJECTS AND OFFLINE DATABASE UPDATES," which is incorporated herein by reference in its entirety. [Background technology]

[0002] background Real-time request processing is a key element in many modern telecommunications and online services. When a request is received from a client device, the service may serve as the access control point for accessing any type of online service. A central service may also serve as the location of an administrative server that tracks all allowances or balances in real time. When a network request is received, the central service attempts to process the request as quickly as possible to avoid undesirable connection latency at the client device. However, determining whether access to a service should be granted can be a processing- and latency-intensive task. Numerous calculations may be performed, and data may need to be retrieved from a data storage system for a particular user. This information may then need to be processed to answer the question about whether access should be granted 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 may become too large. Therefore, improvements are needed in services that evaluate online access requests in real time. Summary of the Invention [Means for solving the problem]

[0003] Quick Overview A real-time request for approval may be received by the access service to establish a connection to a service provider. When a request is received in real time, the user expects a real-time result. Therefore, the process for approving a request for access or connection to a service should be processed as quickly as possible. When a request is received, the user object may be stored in both a long-term data store and a short-term cache. To separate the process for approving the request 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 subsections for each service to which the user has subscribed or to which the user has access. Each service subsection may contain multiple fields describing the type of access allowed, the balance of time, content, data, etc., usage limits, and / or other settings that may determine whether a particular request for that service should be allowed or denied.

[0004] In addition to the first cache, the system may include a second cache called a "surrogate" cache. The surrogate cache may contain compact user objects rather than full user objects. The compact user objects may include a field for each service that includes an indication of whether a request for the corresponding service should be granted. Rather than retrieving a full user object and processing multiple different fields in the full user object to approve a request, the system can instead access the compact user object in the surrogate cache and approve / deny the request based on the value of the field for the corresponding service. Fields in the compact user object may be derived from fields in the full user object using update logic that is performed offline before the request is received. Thus, a request does not have to wait for this processing to occur in response to receiving the request because it has already been performed offline. The request / denial can be granted without extensive retrieval and processing delays of the full user object. Furthermore, the size of the compact user object allows it to be stored in a surrogate cache for each user, so cache misses are unlikely and would normally result in a central data store of full user objects being accessed.

[0005] A field for each service in the compact user object may contain a binary yes / no value for approving the request. Other implementations may use a range of values, such as green, yellow, red, etc. An intermediate value (e.g., yellow) may allow access to the service in a limited capacity. For example, a field in the compact user object may be set to yellow if the user is on the verge of exceeding a time, data, storage, etc. quota. Access may then be allowed for requests that are unlikely to exceed the remaining quota, or with other content restrictions in place.

[0006] After the request is granted, the records of the usage 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 remaining resource balance in the full user object in both the first cache and the central storage. The update logic may then be executed again to generate new values ​​for the fields in the compact user object in the surrogate cache.

[0007] A further understanding of the nature and advantages of various embodiments can be realized by reference to the remaining portions of the specification and drawings, wherein like reference numerals are used throughout the several views to refer to like components. In some cases, a sub-label is associated with a reference numeral to indicate one of multiple similar components. When referring to a reference numeral without a designation to a current sub-label, it is intended to refer to all such multiple similar components. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates an architecture for processing real-time requests to a network service, according to some embodiments. [Figure 2] FIG. 10 illustrates an example of how an access service can process a request using a full user object from a cache, according to some embodiments. [Figure 3] FIG. 1 illustrates an example of a multi-level cache that may be used between the access authorization process and central storage, according to some embodiments. [Figure 4] FIG. 10 illustrates how the value of a field in a compact user object can be derived from multiple fields in a full user object, according to some embodiments. [Figure 5]FIG. 2 illustrates a flowchart of a method for optimizing a user object cache according to some embodiments. [Figure 6] FIG. 10 illustrates how a full user object may be updated after a request is granted using a second cache, according to some embodiments. [Figure 7] FIG. 1 illustrates a flowchart of a method for updating a surrogate cache according to some embodiments. [Figure 8] FIG. 1 is a data flow diagram for processing real-time requests according to some embodiments. [Figure 9] FIG. 1 is a simplified block diagram of a distributed system for implementing some of the embodiments. [Figure 10] FIG. 1 is a simplified block diagram of components of a system environment in which services provided by components of an embodiment system may be offered as cloud services. [Figure 11] FIG. 1 illustrates an exemplary computer system upon which various embodiments may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0009] Detailed Description This disclosure describes embodiments for evaluating requests for access to network services in real time. When a request is received, a user object may be stored in both a long-term data store and a short-term cache. The caches may include a first cache that stores a full version of the user object and a second or surrogate cache that stores a compact version of the user object. The compact version of the user object may include a field that indicates whether a subsequent request for access to a particular service should be granted. This field may be derived from multiple 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 granted, the remaining time balance for the user account, and / or other information related to a particular subscription to that service. To populate the fields in the compact user object in the first cache, the system may process all of this information and determine that the next request should be granted. For example, if the user object lists a particular service level with a sufficient remaining balance, the field in the first cache may be set to a value such as "green," indicating that a subsequent request should be granted immediately without 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 decouples the processing of real-time requests from the updating and evaluation of information in the user object.

[0010] 1 illustrates an architecture 100 for processing real-time requests for network services, according to some embodiments. In this example, a client system 102 may transmit a request over a network for a service 322 provided by a service provider 106. The client device may include any computing device, such as a phone, a smartphone, a personal digital assistant (PDA), a laptop computer, a notebook computer, a tablet computer, a desktop computer, a digital home assistant (e.g., Amazon Alexa®, Google Home®, etc.), networked home appliances in a smart home environment, a smartwatch, a virtual / augmented reality headset, a gateway or router, a server computer, and / or any other type of computing device. The 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 (“app”) running on a computing device, and / or any other service that may be provided over a network.

[0011] To secure a connection to or access a service 322, a client system may pass a request to access the service 322 through an 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. The access service 104 may act as a gatekeeper between the client system 102 and the service 322 and may grant or deny a connection or access to the service 322. In one embodiment, the access service 104 may be implemented by an Online Charging System (OCS), a system that enables communication service providers to monitor and charge customers based on service usage in real time. The OCS may handle user account balances, ratings, billing, control, correlation, etc. In some cases, the OCS may enable telecom operators 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 an OCS, may be operated by a cellular service network and may be responsible for monitoring, authorizing, and tracking balances for connections to the movie streaming service. Note that this example using an OCS is provided by way of 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 a client system 102 to be processed in real time. In this disclosure, the term “real time” may be used to refer to a response received by a user via a client system 102 without a delay of a few seconds (e.g., 5 seconds) or more when applied to online requests and responses. When a request is received by the access service 104, the access authorization process 110 may request a full user object 114 from the cache 112. This full user object 114 may then be used to establish or deny a connection 108 with the service 322. To process these requests in real time, the access service 104 may benefit from accessing the full user object 114, which describes many aspects of the user account. In the example of FIG. 1 , the full user object 114 may be stored in a central storage 116. The central storage 116 may be implemented as a database, a data store, an online repository, and / or other form of persistent storage. The central storage 116 may be relatively large and may have to store user objects for tens of millions of user accounts. In some cases, the central storage 116 may be located at and / or operated by the service provider 106. For example, the central storage 116 may store user objects representing user accounts of subscribers of the service provider 106. In some non-limiting examples, each user object may be 100 kB to 20 MB in size. Thus, substantial storage is often required to implement the central storage 116. Furthermore, while FIG. 1 illustrates the central storage 116 as being part of the service provider 106, this example is not intended to be limiting. Other embodiments may enable 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 for 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 include any information related to the service provider 106, the service 322, and / or how the client system 102 can access the service 322. The full user object 114 may include information for each service offered by the service provider 106. Thus, in addition to information about the service 322 shown in FIG. 1 , the full user object 114 may include information about multiple additional services offered 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 include information associated with additional services offered by other service providers 106. For each individual service, the full user object 114 may include the specific service type, subscription level, account information, purchased offerings, group membership, relationships between different groups and / or users, rate-over-time, voicemail, text, accessible media content, usage balance, balance logic that determines how the balance is adjusted / determined, and / or other information that may be associated with use of the 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 300 kB.

[0014] To determine whether a connection or access to a service 322 should be permitted or denied, the 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 a service 322 may trigger the access service 104 to check the accessible content, service level, subscriptions, remaining time balance, DRM restrictions, parental controls, geographic restrictions, available languages, and / or additional information that can be used to specifically determine whether a request for a particular portion of content from the service 322 should be permitted. Thus, the full user object 114 typically does not 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 have all the information necessary for the access service 104 to determine whether any request should be permitted or denied.

[0015] However, while the full user objects 114 may contain all the necessary information, the size of the full user objects 114, along with the number of full user objects that need to be stored by the central storage 116, presents technical challenges to using the full user objects 114 to grant or deny requests in real time. Specifically, the nature of the large central storage 116 (e.g., a database) and the size of the full user objects 114 can result in long latency in requesting, receiving, and processing relatively large full user objects 114 for real-time decision-making. The delay in retrieving and processing the full user objects 114 may be greater than a user who expects near-instant connection to the service 322 can tolerate. Furthermore, because millions of full user objects are stored by the central storage 116, the central storage 116 is typically not implemented in memory and may instead require a slower, more persistent storage mechanism.

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

[0017] 2 illustrates an example of how the access service 104 can process a request 202 using a full user object 114 from the cache 112, according to some embodiments. When a request is received by the access service 104, the access authorization process 110 can request the full user object 114 from the cache 112. This full user object 114 can then be used to establish or deny a connection 108 with the service 322. For example, the request itself may identify the user, a user identifier 204, a service type 206, information related to the particular content 208 requested from the service, and / or information related to the client system 102. Using this information, the access authorization process 110 can identify a particular 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 can be provided to the access authorization process 110. If the full user object 114 is not already in the cache 112, the cache may request the full user object 114 from the central storage 116 in a situation known as a "cache miss." To efficiently store full user objects so that they are available for real-time retrieval, the cache 112 may typically store fewer full user objects than are available in the central storage 116. Thus, only a subset of full user objects may be stored in the cache 112 at any one time. 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, which 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, along with the information in the request 202, may be used by the access authorization process 110 to determine whether access to a particular service should be granted. For example, a user identifier 204 may be used to locate a particular full user object 114. A service type 206 may be used to select one of the available services 210 (e.g., services for which the user may have a subscription or account) listed in the full user object 114. The request 202 may include a request for a particular type of content 208, which may be compared to multiple fields 212 related to the particular service to determine whether access should be granted. For example, if a request for content 208 includes a request for a particular movie to be streamed to a client device, the full user object 114 may search the user's account details for a streaming movie service to determine whether all of the account details in the plurality of fields 212 allow the particular movie specified by the content 208 to be streamed to the client device. In another example, a client device may send a request 202 to another user device to make a cellular or text connection. The user object 114 may access the text messaging plan, available times, in-network connection, out-of-network connection, and other information from the plurality of fields 212 about cellular service to determine whether a text messaging or cellular connection should be made in accordance with the request 202. Note 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 a remaining balance of time, value, items, or other amounts that can be used for service requests. For example, one of the fields 212 associated with a streaming movie service may include the remaining number of movies for a particular month that can be streamed by the user. In another example, one of the fields 212 may include the balance of time that can be used for a cellular phone connection. Another example may store the balance of data that can be downloaded for a particular month, etc. These balances may be processed in the request 202 to determine whether the request 202 can be granted. For example, if a 30-minute streaming balance remains in the full user object 114 and the request 202 includes a two-hour long movie as the requested content 208, the request may be denied 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 the request 202 may be granted.

[0020] While using cache 112 provides a solution for evaluating requests in real time, it also presents another set of technical challenges. For example, repeated requests from one user may be separated by thousands or millions of requests from other users. Thus, as the number of user accounts increases, maintaining a full user object in cache 112 between requests from the same user becomes increasingly unlikely. After an initial request is made and the full user object 114 is loaded into cache 112, thousands or millions of other requests are likely to 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 full user object 114, it is likely that cache 112 has already evicted the full user object 114 in favor of the full user object from a more recent request. Thus, a large number of requests will cause cache misses in cache 112, requiring longer delays to access central storage 116 upon each cache miss.

[0021] To solve these and other technical problems, some embodiments may implement the cache structure of the access service 104 using a special surrogate cache that acts as an intermediary between the 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 the cache 112. In some cases, the compact user objects in the surrogate cache may contain just one field for each service that indicates whether a subsequent request should be allowed. This allows the surrogate cache to have all the advantages of both the cache 112 and the central storage 116. Specifically, the surrogate cache may contain compact versions of most, if not all, full user objects in the central storage 116, while maintaining the small, fast, and in-memory advantages of the cache 112.

[0022] 3 illustrates an example of a multi-level cache that may be used between the access authorization process 110 and the central storage 116, according to some embodiments. For clarity, throughout the remainder of this disclosure, the cache 112 previously described in FIGS. 1-2 may be referred to as the "first" cache 112, and the surrogate cache previously described may be referred to as the "second" cache 302. Similarly, the full user object 114 stored in the first cache 112 may be referred to as the first user object 114, and the 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 ordering, importance, size, or other characteristics of the caches.

[0023] The second cache 302 may be constructed similarly to the first cache 112. The second cache 302 may be implemented in memory and may contain compact user objects that represent scaled-down or summarized versions of the full user objects in the first cache 112. In some cases, the compact user objects 304 may be several orders of magnitude smaller than the corresponding full user objects 114 in the first cache 112. For example, the full user objects 114 may be approximately 1 MB, whereas the compact user objects may be approximately 10-20 bytes. Because of this dramatic size reduction when transitioning from full user objects 114 to compact user objects 304, the second cache 302 may contain compact versions of more user objects than can be contained at one time 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 may be superior to that 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 contrasted with a traditional multi-level cache, such as an L1, L2, L3 cache structure. In a traditional multi-level cache, higher cache levels typically operate using faster hardware / software than lower cache levels. Cache transparency typically exists when lower levels of a cache contain all of the data within the higher levels of the cache. Furthermore, objects within the higher levels of a traditional cache are identical to objects within the lower levels of the cache, resulting in multiple identical copies of objects existing at various 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 a traditional cache. Furthermore, 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 the fields 212 in the full user object 114, the compact user object 304 may include new data fields that summarize or are derived from the information stored in the full user object 114. Thus, the second cache 302 generates a new type of information with the new data to store in the compact user object 304. This is possible and advantageous because the second cache 302 may be specially tailored to simply provide the access authorization process 110 with information to approve or deny a connection request. The second cache 302 may be specially designed for this purpose.

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

[0026] When a request for a particular 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 looking up the value of the field for that service and comparing it to a threshold for allowing 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 request authorization, even if the full user object 114 remains in the first cache 112. Furthermore, this dramatically reduces the likelihood of a cache miss in the second cache 302. Because compact user objects are much smaller than full user objects, the second cache 302 can often store all compact user objects for a user serving a request, whereas the first cache can only provide a very limited subset of full user objects that would otherwise be available.

[0027] In some embodiments, the surrogate cache 302 may act as a front end for a backend server or process. As a front end, the access service 104 may receive requests and establish connections to backend processes or services. Operating centrally, the access service 104 may track the balance and usage 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 quota assigned to the user account over the network.

[0028] 4 is a diagram illustrating how the value of a field 306 in a compact user object is derived from multiple fields 212 in a full user object 114, according to some embodiments. The access service 104 may use update logic 402 to update the value of a field 306 in a 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 the field 306. For example, a balance in the multiple fields 212 may be used to set the value of the field 306 compared to a threshold. In other cases, two or more fields, such as balance, service level, description type, etc., 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 include the update logic 402. This allows the full user object 114 to be a self-contained 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 the multiple fields 212 to generate a value for a field 306 in the compact user object 304. The details of each set of update logic 402 will vary for each specific service type, but some examples are provided here for illustrative purposes. In a first example, the update logic 402 may retrieve the remaining time, value, and / or item balance from the full user object 114 and apply various thresholds to assign a value to the field 306. It derives the value for the field 306 by determining the percentage of access or balance allowance remaining for the corresponding user object. Some 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 a second example, the update logic 402 may analyze content restrictions, parental permissions, and other settings in the full user object 114 to determine the content that may be streamed over the network. If the permissions / restrictions are very high, the value may be set to red, whereas if the permissions / restrictions are very low, the value may be set to green. In a third example, the update logic 402 may analyze the number of remaining text messages available under a text messaging plan and set the value based on the percentage of the remaining amount. In a 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 as the level of security threat increases, the value gradually increases from yellow to red. Note that the specific implementation is provided by way of example only and is 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 and derive a value indicating whether a subsequent request should be allowed.

[0030] In the above example, the values ​​of the fields 306 in the compact user object 304 associated with the services progress 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 allows the compact user object 304 to be very small, since it uses only one bit for each service. Some embodiments may use numeric values ​​in the fields 306, such as time, value, individual object, remaining balance of storage space, etc. Some embodiments may include a whitelist and / or blacklist of requests that should be allowed / rejected. For example, a field may be set to green if it has a blacklist of content items that should not be streamed. Alternatively, a field may be set to red if it has a whitelist of content items that should be allowed.

[0031] In the above example, a green field value allowed the request to be granted, and a red field value allowed the request to be denied. 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 granted with restrictions. For example, if 40%-60% of the available quota remains, the field value may be set to yellow. When a request is received, the request may be granted, but restrictions may be imposed, such as on the amount of content provided by service 322. For example, a 40MB download limit may be imposed. A maximum length may be imposed on calls. The service may only allow downloading a single movie, etc.

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

[0033] The method may also include deriving (504) fields in a second user object associated with the user account in the second cache. As previously described in FIG. 4, update logic may be used to derive values ​​for fields in the second user object from multiple fields in the first user object. The second user object may be a compact user object that may include only one field for each service. The second cache may also include a compact user object for each full user object in the first cache. The second cache may also include a compact user object for each full user object in a data store or central storage. The second cache may be specially configured to make a quick determination as to whether access or connection to a requested service should be granted without requiring extensive processing, calculation, or loading of multiple fields in the first user object.

[0034] The method may further include receiving (506) a request from a client device to access a service using the user account. As previously described in Figure 2, the request may identify the user account, a particular service, and a request / content associated with the 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, including telecom services, media services, communication services, data storage services, etc.

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

[0036] It should be understood that the specific steps illustrated in Figure 5 provide a particular method for optimizing caching and access services according to various embodiments. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments may perform the above steps in a different order. Furthermore, the individual steps illustrated in Figure 5 may include multiple sub-steps that may be performed in various sequences as appropriate for the individual step. Furthermore, additional steps may be added or removed depending on the particular application. Many modifications, variations, and alternatives are within the scope of the present disclosure.

[0037] 6 is a diagram illustrating how a full user object 114 may be updated after a request is granted using the second cache 302, according to some 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 may need to be adjusted. In another example, if a movie is downloaded from a service 322, the value owed may need to be updated. One of the technical advantages provided by the second cache 302 is the separation of the ability to grant / deny requests in real time from the remaining overhead associated with maintaining a full user object. Thus, processing the results of an granted access or connection can be done offline once the request is granted.

[0038] When a request is approved, a record 602 may be generated for the request. This record may be placed in an 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 granted or denied, a record 602 may be generated and added to the record storage queue 604. The record 602 may include the amount of resources provided or used by the connection to the service 322. For example, the record 602 may include the number of content objects streamed from the service 322, the time used for the service 322, the amount spent on the service 322, the number of messages sent through the service 322, etc. Records in the record storage queue 604 may not be processed upon receipt. Instead, they may be saved 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. An operation to update a 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 corresponding values ​​in multiple fields 212 of the full user object 114. For example, the record may include a user identifier that can be used to look up the full user object 114 corresponding to the record 602. The above information that may be stored in the record 602 may be used to update multiple fields 212 in the full user object 114. For example, the remaining amount of available resources or balance 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, and the corresponding full user object may be updated. This allows the record storage queue 604 to be processed as a batch operation if sufficient processing power is available to do so.

[0040] After the full user object 114 is updated, the process previously described in FIGS. 3-4 may be performed to update the values ​​stored in the fields 306 of the compact user object 304. For example, the update logic 406 may be executed against new values ​​in the fields 212 of the full user object 114 to generate new values ​​for the fields 306 in the corresponding compact user object 304. This operation may be performed for each full user object that changed. Furthermore, the update operation for each record in the record storage queue 604 need not be performed on the first cache 112. Instead, this operation may be performed on the central storage 116. The central storage may be updated and then push a new version of the full user object (or change event) 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] FIG. 7 illustrates a flowchart 700 of a method for updating a surrogate cache, according to some embodiments. The method may include granting access to a service (702). The method may begin execution when the method of FIG. 5 ends, thereby granting access or establishing a connection pursuant to a request for the service from a client device. The method may also include generating a record of access (704). The record may include the amount of resources used by accessing the service as previously described in FIG. 6. The record may be added to a record update queue (706). The record update queue may store records from granted requests until they are ready to be processed. The update process may be triggered if sufficient computing resources are available, after a 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, when a request that would fall within a threshold exceeding a quota is granted, etc.

[0042] The method may also include updating (708) a first user object in the first cache with the record. The first user object may include the full user object described above. Residual balances, such as time, date, item, and value, may be updated so that fields in the full user object reflect the results of granting access pursuant to the request. After the full user object is updated, the method may include updating (710) a second user object in the second cache. The 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 fields in the full user object using the update logic described above. In some cases, the method may also include updating the central storage with a new version of the full user object. These updates to the full user object in the central storage and / or the first cache may be performed using change events, as described below.

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

[0044] 8 is a data flow diagram for processing real-time requests, according to some embodiments. The request may be received in a request-response stream 804 by the real-time client 106. Each event in the request-response stream 804 may be processed sequentially by the real-time client 806. For example, an authorization and authentication process 802 may be performed for each request in the stream 804. As part of processing the real-time request, a surrogate cache 808 may be accessed. 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, real-time rating process 810 may receive the change in the remaining balance of the resource allocation assigned to the user account. Real-time logic 814 may execute to update the available balance (e.g., balance 3) and may generate an event that may be passed to rated event stream 816. Rated event processor 818 may perform an update to the corresponding full user object in central storage 820. To complete the update process, a change event 822 may be generated and passed to cache updater 824, which may update multiple fields in the full user object in the first cache. Values ​​in the second cache may then also be updated, as described above.

[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 be provided with input / output requiring a user. For example, a user may provide input for each step of the method, and each of these inputs may be provided in response to a particular 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, etc. Similarly, outputs may be provided to a user, provided as a data stream to another computer system, saved to a storage location, transmitted over a network, provided to a web service, etc. In short, each step of the methods described herein may be performed by a computer system and may require any number of inputs, outputs, and / or requests to the computer system, which may or may not require a user. Those steps that do not require a user are said to be performed automatically by the computer system without human intervention. Thus, in light of this disclosure, it will be understood that each step of each method described herein may be modified to include input and output to a user, or may be performed automatically by a computer system without human intervention, where some decisions are made by a processor. Additionally, some embodiments of each method described herein may be implemented as a set of instructions stored on a tangible, non-transitory storage medium to form a tangible software product.

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

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

[0049] In the illustrated configuration, 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 client computing devices 902, 904, 906, and / or 908. A user operating a client computing device then utilizes one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that a variety of different system configurations are possible and may differ from distributed system 900. Thus, the illustrated embodiment is an example of a distributed system for implementing the system of the embodiments and is not intended to be limiting.

[0050] Client computing devices 902, 904, 906, and / or 908 may be portable handheld devices (e.g., iPhones, mobile phones, iPads, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass head-mounted displays) running software such as Microsoft Windows Mobile and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 10, Palm OS, etc., and 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, by way of example, personal 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 capable of communicating over network 910, such as thin client computers, internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect® gesture input devices), and / or personal messaging devices.

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

[0052] Network 910 in distributed system 900 may be any type of network capable of supporting data communications using any of a variety of commercially available protocols, including, but not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internet Packet Exchange), AppleTalk, etc. By way of example only, network 910 may be a local area network (LAN), such as one based on Ethernet, token ring, etc. Network 910 may also be a wide area network and the Internet. It may also include virtual networks, including, but not limited to, virtual private networks (VPNs), intranets, extranets, public switched telephone networks (PSTNs), infrared networks, wireless networks (e.g., networks operating under the Institute of Electrical and Electronics Engineers (IEEE) 802.11 suite of protocols, Bluetooth, and / or other wireless protocols), and / or any combination of these and / or other networks.

[0053] Server(s) 912 may comprise one or more general-purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable configuration and / or combination. In various embodiments, server(s) 912 may be adapted to execute one or more services or software applications described in the above disclosure. For example, server(s) 912 may correspond to a server for executing the above-described processes according to one embodiment of the present disclosure.

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

[0055] In some implementations, server 912 may include one or more applications for analyzing and consolidating data feeds and / or event updates received from users of client computing devices 902, 904, 906, and 908. By way of example, the data feeds and / or event updates may include, but are not limited to, Twitter feeds, Facebook updates, or real-time updates received from one or more third-party sources and continuous data streams. 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, automobile traffic monitoring, etc. 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] Distributed system 900 may also include one or more databases 914 and 916. Databases 914 and 916 may be located in a variety of locations. By way of example, one or more of databases 914 and 916 may reside on non-transitory storage media local to (and / or within) server 912. Alternatively, databases 914 and 916 may be remote from server 912 and communicate with server 912 via a network-based or dedicated connection. In one set of embodiments, databases 914 and 916 may reside within a storage-area network (SAN). Similarly, any files necessary to perform the functions attributed to server 912 may be stored locally on server 912 and / or remotely from server 912, as appropriate. In one set of embodiments, databases 914 and 916 may include relational databases, such as those offered by Oracle Corporation, adapted to store, update, and retrieve data in response to SQL-formatted commands.

[0057] 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 an embodiment system may be offered as cloud services, according to one embodiment of the present disclosure. In the embodiment shown, system environment 1000 includes one or more client computing devices 1004, 1006, and 1008 that users can use to interact with a cloud infrastructure system 1002 that provides cloud services. These client computing devices may be configured to operate a client application, such as a web browser, a dedicated client application (e.g., Oracle Forms), or some other application that users of the client computing devices can use to interact with cloud infrastructure system 1002 and use services offered by cloud infrastructure system 1002.

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

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

[0060] Although the exemplary system environment 1000 is shown with three client computing devices, 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 communication and exchange of data between clients 1004, 1006, and 1008 and cloud infrastructure system 1002. Each network can be any type of network capable of supporting data communication using any of a variety of commercially available protocols, including those protocols described above for network 910.

[0062] Cloud infrastructure system 1002 may include one or more computers and / or servers, which may include those described above for server 912.

[0063] In particular embodiments, the services offered by a cloud infrastructure system may include numerous 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 offered by the cloud infrastructure system can be dynamically scaled to meet the needs of its users. A specific instantiation of a service offered by the cloud infrastructure system is referred to herein as a "service instance." In general, any service made available to users from a cloud service provider's system over a communications network such as the Internet is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems comprising the cloud service provider's system are distinct from the customer's own on-premises servers and systems. For example, the cloud service provider's system may host an application, which users can order and use on demand over a communications network such as the Internet.

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

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

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

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

[0068] In some embodiments, 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 suite 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 the SaaS services. By utilizing the services provided by the SaaS platform, customers can utilize applications that run on the cloud infrastructure system. Customers can obtain application services without the customer having to purchase separate licenses and support. A variety of different SaaS services may be offered. 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 provided 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 may include, but are not limited to, services that enable organizations (e.g., Oracle) to consolidate existing applications on a shared, common architecture and the ability to build new applications that leverage shared services provided by the platform. The PaaS platform may manage and control the underlying software and infrastructure for delivering the PaaS services. Customers may obtain PaaS services provided by a cloud infrastructure system without the customer having to purchase separate licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), etc.

[0070] By utilizing services provided by a PaaS platform, customers can utilize programming languages ​​and tools supported by the cloud infrastructure system and also 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 services may support a shared service deployment model that enables organizations to pool database resources and provide database-as-a-service services to customers in the form of a database cloud. The middleware cloud services may provide a platform for customers to develop and deploy various business applications in the cloud infrastructure system, and the Java cloud services may provide a platform for customers to deploy Java applications in the cloud infrastructure system.

[0071] In a cloud infrastructure system, a variety of different infrastructure services may be provided by the IaaS platform that facilitate the management and control of underlying computing resources, such as storage, network, and other fundamental computing resources, for customers using the services provided by the SaaS and PaaS platforms.

[0072] In particular embodiments, 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, infrastructure resources 1030 may include a pre-integrated and optimized combination of hardware such as servers, storage, and networking resources for running the services offered by the PaaS and SaaS platforms.

[0073] In some embodiments, resources in cloud infrastructure system 1002 may be shared by multiple users and dynamically reallocated per demand. Furthermore, resources may be allocated to users in various time zones. For example, cloud infrastructure system 1030 maximizes resource utilization by allowing a first set of users in a first time zone to utilize resources in the cloud infrastructure system for a particular period of time, and then allowing the same resources to be reallocated to another set of users in a different time zone.

[0074] In particular embodiments, several internal shared services 1032 may be provided that are shared by various components or modules of cloud infrastructure system 1002 and services provided by 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, etc.

[0075] In particular embodiments, cloud infrastructure system 1002 may provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in the cloud infrastructure system. In one embodiment, cloud management functions may include functions such as provisioning, managing, and tracking customer subscriptions received by cloud infrastructure system 1002.

[0076] In one embodiment, as shown in the figure, cloud management functionality may 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 or be provided using one or more computers and / or servers, which may be general-purpose computers, dedicated server computers, server farms, server clusters, or any other suitable configuration and / or combination.

[0077] In exemplary operation 1034, a customer may interact with cloud infrastructure system 1002 using a client device, such as client device 1004, 1006, or 1008, by requesting one or more services offered by cloud infrastructure system 1002 and placing an order for subscriptions to one or more services offered by cloud infrastructure system 1002. In particular embodiments, the 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 via these UIs. Order information received by cloud infrastructure system 1002 in response to the customer placing an order may include information identifying the customer and the one or more services offered by cloud infrastructure system 1002 for which the customer wishes to subscribe.

[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 an order database 1018. The order database 1018 may be one of several databases operated by the cloud infrastructure system 1018 and in coordination with other system elements.

[0080] At operation 1038, the order information is forwarded to the order management module 1020. In some cases, the order management module 1020 may be configured to perform billing and accounting functions related to the order, such as validating the order and booking the order upon validation.

[0081] At operation 1040, information regarding the order is communicated to the order orchestration module 1022. The order orchestration module 1022 may utilize 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 the service subscribed for using the services of the order provisioning module 1024.

[0082] In particular embodiments, the order orchestration module 1022 enables management of business processes associated with each order and applies business logic to determine whether the order should proceed to provisioning. At 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 services 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 the resources to provide the requested services. This allows the order orchestration module 1022 to be decoupled 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 upon request.

[0083] At 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 customer on the client device 1004 , 1006 and / or 1008 .

[0084] At operation 1046, the customer's subscription order 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 usage statistics for the services in the subscription order, such as the amount of storage used, the amount of data transferred, the number of users, and system up and down times.

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

[0086] 11 illustrates an exemplary computer system 1100 upon which various embodiments may be implemented. System 1100 may be used to implement any of the computer systems described above. As shown, 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. Storage subsystem 1118 includes a tangible computer-readable storage medium 1122 and a system memory 1110.

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

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

[0089] In various embodiments, processing unit 1104 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. Some or all of the program code being executed may reside within processor 1104 and / or storage subsystem 1118 at any one time. Through suitable programming, processor 1104 may provide the various functions described above. Additionally, computer system 1100 may include a processing acceleration unit 1106, which may include a digital signal processor (DSP), a special purpose processor, or 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 a keyboard, a pointing device such as a mouse or trackball, a touchpad or touchscreen integrated into a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, an audio input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may include, for example, a motion-sensing and / or gesture-recognition device such as a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and verbal commands. User interface input devices may also include an eye-gesture recognition device such as a Google Glass® blink detector that detects eye movements from a user (e.g., “blinking” while taking a picture and / or making a menu selection) and translates the eye gesture as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (e.g., the Siri® navigator) via voice commands.

[0091] User interface input devices may also include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphics 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 range finders, and eye-tracking devices. Furthermore, user interface input devices may include medical imaging input devices, such as, for example, computed tomography devices, magnetic resonance imaging devices, position emission tomography devices, medical ultrasound devices, and the like. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards, digital musical instruments, and the like.

[0092] User interface output devices may include display subsystems, indicator lights, or non-visual displays such as audio output devices. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), liquid crystal display (LCD), or plasma display, a projection device, a touch screen, etc. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1100 to a user or to another computer. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, automobile navigation systems, plotters, voice output devices, and modems.

[0093] Computer system 1100 may include a storage subsystem 1118 that includes software elements currently shown as located in system memory 1110. System memory 1110 may store program instructions that are loadable and executable on processing unit 1104, as well as data generated during the execution of these programs.

[0094] Depending on the configuration and type of 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), flash memory, etc.). Generally, RAM contains data and / or program modules that are immediately accessible to and / or presently being operated on and executed by the processing unit 1104. In some implementations, the system memory 1110 may include several different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within the computer system 1100, such as during start-up, may typically be stored in ROM. By way of example, system memory 1110 also shows application programs 1112, program data 1114, and an operating system 1116, which may include, but are not limited to, client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), and the like.By way of example, operating system 1116 may include Microsoft Windows®, Apple Macintosh® and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or various versions of mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 10 OS, and Palm® OS operating systems.

[0095] The storage subsystem 1118 may also provide a tangible computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by a processor, provide the above-described 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 in accordance with some embodiments.

[0096] Storage subsystem 1100 may also include a computer-readable storage medium reader 1120 further connectable to a computer-readable storage medium 1122. Along with, and optionally in combination with, system memory 1110, computer-readable storage medium 1122 may 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] The computer-readable storage medium 1122 containing the code or portions of code may include any suitable medium, including storage and communication media, such as, but not limited to, volatile and nonvolatile, removable and non-removable media, implemented in any method or technology 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 technology, CD-ROM, Digital Versatile Disk (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer-readable media. This may also include non-tangible computer-readable media, such as data signals, data transmissions, or other media usable to transmit the desired information and accessible by computing system 1100.

[0098] By way of example, the computer-readable storage medium 1122 may include a hard disk drive that reads from and writes to non-removable, non-volatile magnetic media, a magnetic disk drive that reads from and writes to removable, non-volatile magnetic disks, and an optical disk drive that reads from and writes to removable, non-volatile optical disks such as CD-ROMs, DVDs, Blu-Ray® disks or other optical media. The computer-readable storage medium 1122 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, etc. The computer-readable storage media 1122 may also include flash memory-based SSDs, enterprise flash drives, solid-state drives (SSDs) based on non-volatile memory such as solid-state ROM, SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM-based SSDs and flash memory-based SSDs. These disk drives and their associated computer-readable media can provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1100.

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

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

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

[0102] Additionally, the communications 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 updates 1130, which may be continuous or infinite in nature with no apparent end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

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

[0104] The computer system 1100 may be one of a variety of types, including a handheld portable device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or other data processing system.

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

[0106] In the above description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of various embodiments. However, it will be apparent that some embodiments may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.

[0107] The above description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the above description of various embodiments provides an enabling disclosure for implementing at least one embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the several embodiments as set forth in the appended claims.

[0108] Specific details are set forth in the above description to provide a thorough understanding of the embodiments. However, it will be understood that the embodiments can be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form so as not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail so as to avoid obscuring the embodiments.

[0109] Also, it should be noted that the particular embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. While a flowchart may describe operations as a sequential process, many of these operations may be performed in parallel or simultaneously. The order of these operations may also be rearranged. A process terminates when its operations are completed, but may have additional steps not included in the diagram. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the 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 retain instructions and / or data. A code segment or machine-executable instruction may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0111] Furthermore, the embodiments may be implemented in hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium. A processor may perform the necessary tasks.

[0112] In the foregoing specification, features have been described with reference to specific embodiments thereof, but it should be recognized that not all embodiments are limited thereto. Various features and aspects of the several embodiments may be used individually or together. Moreover, the embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive.

[0113] Furthermore, for illustrative purposes, the methods are described in a particular order. It should be understood that in alternative embodiments, the methods may be performed in an order different from that described. It should also be understood that the methods described above may be performed by hardware components or embodied in sequences of instructions that can be used to cause a machine, such as a general-purpose or special-purpose processor or logic circuitry programmed with machine-executable instructions, to perform the methods. These machine-executable instructions may be stored on 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 medium suitable for storing electronic instructions. Alternatively, the methods may be performed by a combination of hardware and software.

Claims

1. 1. A computer readable program for causing one or more processors to perform operations, said operations comprising: accessing a first cache that stores a first user object associated with a user account, the first user object including a plurality of fields associated with a service, the operation further comprising: deriving a value of a field in a second user object associated with the user account in a second cache, the value of the field of the second user object being derived from values ​​of the plurality of fields of the first user object, the value of the field of the second user object indicating whether access to the service is granted, the second user object being smaller than the first user object, the operation further comprising: receiving a request from a client device to access the service using the user account; accessing the field in the second user object in the second cache to determine whether to allow the client device to access the service; generating a record of access to the service indicating the amount of access used by the client device authorized to access the service; adding the record of the access to the service to an offline record storage queue.

2. 2. The computer-readable program of claim 1, wherein the second cache represents a compact version of the first cache, and the second cache maintains compact versions of user objects that have been evicted from the first cache.

3. 3. The computer readable program of claim 1, wherein the field in the second user object stores a value that is one of a plurality of values ​​that indicate different access levels.

4. The plurality of values ​​are: a first value indicating that access to the service is permitted; a second value indicating that limited access to the service is permitted; and and a third value indicating that access to the service is not permitted.

5. The computer-readable program of claim 4 , wherein the second value indicating that limited access to the service is permitted limits time or bandwidth during access.

6. the first user object includes a plurality of fields for each of a plurality of services; The computer-readable program of any one of claims 1 to 5, wherein the second user object includes a single field for each of the plurality of services.

7. 7. The computer-readable program of claim 1, wherein determining whether to allow the client device to access the service does not require accessing the first user object in the first cache.

8. 8. The computer-readable program of claim 1, wherein deriving a value for the field in the second user object comprises determining a percentage of an allowed amount of access remaining in the user account.

9. The operation further comprises:

9. The computer-readable program of claim 1, further comprising processing the record from the offline record storage queue to update the plurality of fields for the first user object in the first cache.

10. The operation further comprises: The computer readable program of any one of claims 1 to 9, further comprising processing the records from the offline record storage queue to update a database of user objects at the service.

11. The operation further comprises:

11. The computer-readable program of claim 9, further 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.

12. 12. The computer-readable program of claim 9, wherein when the request from the client device is received, a determination is made in real time as to whether to allow the client device to access the service, and the records from the offline record storage queue are processed after access is granted and the client device accesses the service.

13. The operation further comprises:

13. The computer readable program of claim 9, further comprising processing each of a plurality of records in the offline record storage queue, the plurality of records being received from a plurality of different requests to access a plurality of different services, and the plurality of records being processed together as a batch.

14. The computer readable program of any one of claims 1 to 13, wherein the service comprises a telecommunications service.

15. 1. A method for optimizing a user object cache, comprising: The method includes one or more processors accessing a first cache that stores a first user object associated with a user account, the first user object including a plurality of fields associated with a service, the method further comprising: the one or more processors deriving a value of a field in a second user object associated with the user account in a second cache, the value of the field of the second user object being derived from values ​​of the plurality of fields of the first user object, the value of the field of the second user object indicating whether access to the service is granted, the second user object being smaller than the first user object, the method further comprising: receiving, by the one or more processors, a request from a client device to access the service using the user account; the one or more processors accessing the field in the second user object in the second cache to determine whether to allow the client device to access the service; generating, by the one or more processors, a record of access to the service indicating an amount of access used by the client device authorized to access the service; the one or more processors adding the record of the access to the service to an offline record storage queue.

16. 1. A system comprising: one or more processors; and one or more memory devices storing a program for causing the one or more processors to perform operations, the operations including: accessing a first cache that stores a first user object associated with a user account, the first user object including a plurality of fields associated with a service, the operation further comprising: deriving a value of a field in a second user object associated with the user account in a second cache, the value of the field of the second user object being derived from values ​​of the plurality of fields of the first user object, the value of the field of the second user object indicating whether access to the service is granted, the second user object being smaller than the first user object, the operation further comprising: receiving a request from a client device to access the service using the user account; accessing the field in the second user object in the second cache to determine whether to allow the client device to access the service; generating a record of access to the service indicating the amount of access used by the client device authorized to access the service; adding the record of the access to the service to an offline record storage queue.

Images