Invented by Ajinkya Apte, Bruce Sherrod, Matthew Leventi, Suryaveer Singh Lodha, Matthew John Alberts, Tim Sullivan, Zynga Inc
Multitenancy refers to the ability of a software application to serve multiple customers, or tenants, from a single instance of the software. In the context of gaming services, this means that developers can create and deploy their games on a single platform, which can then be accessed by multiple players simultaneously.
One of the key advantages of a multitenancy gaming services platform is its scalability. Game developers can easily scale their games to accommodate a growing number of players without the need for additional infrastructure or resources. This allows for seamless gameplay experiences, even during peak usage periods.
Furthermore, multitenancy platforms offer cost savings for developers. By utilizing a shared infrastructure, developers can reduce their operational costs and focus more on creating engaging and immersive gaming experiences. This is particularly beneficial for independent game developers who may have limited resources.
For players, multitenancy gaming services platforms provide a wide range of games to choose from. With a single platform hosting multiple games, players have access to a diverse library of titles, catering to different genres, themes, and gameplay styles. This variety enhances the overall gaming experience and ensures that players can always find something that suits their preferences.
Additionally, multitenancy platforms often incorporate social features, allowing players to connect and interact with each other. This fosters a sense of community and encourages multiplayer gameplay, which is becoming increasingly popular in the gaming industry. Players can compete against each other, form teams, and engage in cooperative gameplay, enhancing the overall enjoyment and longevity of the gaming experience.
The market for multitenancy gaming services platforms is expected to grow due to several factors. Firstly, the increasing popularity of online gaming and the rise of mobile gaming have created a demand for platforms that can support a large number of players simultaneously. Multitenancy platforms are well-suited to meet this demand, providing a seamless and scalable solution.
Furthermore, the ongoing advancements in technology, such as cloud computing and improved internet connectivity, have made it easier for developers to create and deploy games on multitenancy platforms. This has further fueled the growth of the market, as more developers recognize the benefits of utilizing such platforms.
In conclusion, the market for multitenancy gaming services platforms is thriving and is expected to continue its growth in the coming years. The scalability, cost savings, and variety of games offered by these platforms make them highly attractive to both game developers and players. With the increasing popularity of online and mobile gaming, multitenancy platforms are well-positioned to meet the demands of the evolving gaming industry.
The Zynga Inc invention works as follows
The presenters have presented systems and methods of providing multitenancy gaming platforms services. In one embodiment, a method of providing multitenancy platform services includes receiving, at a computer server, a request for an operation from one of several applications, where the request contains a token, application data, and an identifier of a target user. Decoding the token is also part of the method to obtain an application identifier, and a target user identifier. The method also includes determining the service from a number of multitenancy gaming platforms that is requested and sending data related to an application to a server computer for the service. The method also comprises receiving a reply from the second computer that is responsible for the service indicating the status of the operation.
Background for Multitenancy Gaming Services Platform
There are many inefficiencies with the way resources and components are developed and maintained for games and applications. Game A, for example, may have its team of engineers and servers to store the game state, as well as its own solution to keep track of scores or alliances in the game. Game B could also have its team of engineers and its set of servers for storing game states. It may even have its solutions to alliances in the game, or ways of keeping score. It is impossible to develop or maintain an application or game using similar components or resources.
As described above, the current development of games and applications is rife with technical inefficiencies. The games are either developed individually, using components and resources specific to the game or they must be downloaded as a Software Development Kit (SDK), which may contain many unnecessary features. A developer might want to utilize functionality from a third-party SDK. The developer will need to download the SDKs for each of the development systems (e.g. Unity, Unreal etc.). or operating system (e.g., Android, iOS, Windows, etc.) The developer intends to use or support in the application that he develops. After downloading the SDK, he must integrate the SDK in his development environment. To use the SDK he will need to compile it and include it in his application. Not only is this a lengthy process, it also increases the size of code and applications. “The size of an application can be a problem for devices with limited storage.
Also, whenever there is an SDK update, the developer will need to download the latest version and update his code to conform to the new SDK version. The developer will also need to recompile the code and perform a new quality assurance process in order to test his application using the new SDK. In the event of any problems, he will need to troubleshoot them, contact a third party, etc. The developer does not have any control or insight into the SDK code, so he has to rely on a third-party to fix any issues. Since he cannot control the SDK’s development cycle, he has to do a whole new version development process and QA every time there is a change in the SDK.
Furthermore the SDK can provide any number functionality.” The SDK might provide fifty features of functionality, but a developer may need only one. The SDK is not under the control of the developer.
The systems and methods described in this document relate to multitenancy platform services that provide common services to multiple entities to develop a variety of games. These entities can be legal entities that are separate (e.g. different companies, individual developers, etc.). There may be different types of game developed by different companies, developers, etc. In order to address the inefficiencies of current development and management models, systems are described that provide an interface for a plurality common services which can be used for game or application maintenance and development for multiple games and/or apps. Developers (e.g. a company or an individual developer) can start using services in their game without having to download and maintain SDKs. A developer can, for example, obtain an application ID and begin calling his application through an API to store game state, create and maintain leaderboards and scores, manage purchasing and selling assets in a game, or manage the core aspects of a group or guild of users. No SDK or other SDKs are required. A developer can choose which services to use in each game. The developer can choose which services to use in their application and how they want it developed (e.g. new version, QA process etc.). The developer can control the services he wants to use in his application, as well as the development process (e.g., new version, QA process). The system is also platform-independent.
The systems and methods described in this document enable developers or game/application providers to use application services without owning their own dedicated infrastructure. It allows developers to release and implement an application or game quickly with minimal infrastructure and development costs.
In one embodiment, “a method of providing multitenancy gaming platforms services” comprises receiving at a first computer a request for an operation from one of the plurality of applications. The request includes a token, application-related data, and an identifier of the target user. The method also comprises decoding the token by the server computer to determine an application and a target user ID, authenticating the application and user ID by the server computer and authorizing the operation by the server computer based on user identifiers and target user IDs. The method also comprises determining by the server computer which of a plurality multitenancy gaming platforms services is being requested, sending the data related to an application to a server computer that is responsible for this service and receiving a response by the server computer.
In another embodiment, the first request and the first application can be the same. The method can further include receiving a request for an operation from a secondary application in a plurality, which includes a token, data relating to the second app, and a target user identifier. The method can further include decoding the token by the server computer to determine a user identifier as well as a second application ID, authenticating the user identifier by the server computer and authorizing the operation by the server computer based on both the user identifiers and the target user identifier. The method may also include determining by the server, which of a number of multitenancy gaming platforms services is being requested, sending the data relating to the second application by the server, to the third server responsible for that service, and receiving a response by the server, from the third server responsible for that service, informing the status of the operation.
FIG. According to certain embodiments, FIG. 1 is a diagram showing a system 100 that can be configured for gaming services with multiple tenants. The system 100 can include one or multiple client devices, such as client device(s). The client device(s), 110 can include, but not be limited to, mobile phones, desktop computers, laptops and laptops with ultrabooks, laptops or netbooks. It may also comprise a multi-processor system, consumer electronics based on microprocessors or programmable, gaming consoles, set top boxes, vehicles or other communication devices that users may use to access the networked 100. In some embodiments the client device(s), 110 may include a display module to display information, such as user interfaces. In other embodiments, client device(s), 110 can include one or more touch screens, accelerometers and gyroscopes as well as cameras, microphones and GPS devices.
The client device(s), 110 can be a device used by a user 106 such as a developer of games or apps, or an end-user or player who uses the device to play games or apps, or develop them. In one embodiment, system 100 is a gaming platform with multiple tenants that receives service requests from a plurality client devices 110. The terms “user” and “player? The terms?user? “Player” and “player?
One or more user 106 can be a human, a machine or another means of interaction with the client device 110. In some embodiments, a user 106 is not part of the system, but can interact with it via the client device(s). The user 106, for example, may input data (e.g. touch screen input, alphanumeric entry) into the client device(s), and this input can be sent to other entities within the system 100, e.g. server system 102, via the network 104. The other entities of the system 100 may, upon receiving input from the users 106, communicate information via the network to the client devices 110 to be displayed to the users 106. The user 106 can interact with various entities within the system 100 by using the client device(s).
The system 100 can further include a wireless network 104.” “One or more portions may be an ad hoc, intranet, extranet, virtual private network (VPN), local area network(LAN), wireless LAN(WLAN), wide area network(WAN), wireless WAN (WWAN), metropolitan area network.
The server system 102 can provide server-side functionalities via the network (e.g. the Internet, or a wide area network (WAN), to one or more clients devices 110. According to some embodiments, the server system 102 can be a cloud computing platform.
The server system 102 can include an API server 120, one or multiple application servers 122 that are communicatively linked to one or several databases 126. The database(s) 126 can be storage devices for information like game states, scores and application identifiers. The server system 102 can interact with the client devices 110 in order to provide services for one or multiple client applications 114.
The API server 120 can receive multiple requests for services coming from different client devices 110. It will authenticate or authorize these services and then send them to the application server(s), 122 that are associated with the services.
The application server (s) 122 can include a plurality application servers that are related to specific services. In FIG. are some examples of application servers. 2. Storage application server 204 can be used to store games, e.g. save game functionality, for mobile and web-based games. A leaderboard server 206 can provide tools for managing scores and creating leaderboards. A trade application server may offer services related to user-to-user buying or trading items within a game or app. A guilds server 210 can provide core functionality for managing a group, clan or guild. “An auction application server 214 can be used to purchase and sell items in-game.
As explained above, the user doesn’t need to download a SDK or create and maintain separate components for every game he builds. The systems and methods described herein instead provide an interface for a multitude of common services which can be used to develop and maintain any game or application. The developer can use the services in his game without having to download or maintain an SDK. The SDK is not included in the application of the developer, and the application operates without the SDK. A developer can, for example, obtain an application ID and begin calling his application through an API to store game state, create and maintain leaderboards and scores, manage buying or selling assets in a game, and manage core aspects of guilds or groups of users.
FIG. According to certain example embodiments, FIG. 3 is a flowchart illustrating aspects of the method 300 for requesting an application identifier and generating it. To illustrate the method 300, it is described in relation to FIG. 100’s networked system. 1. “It is understood that the method 300 can be used with other configurations of system in other embodiments.
In operation 302, server system 102 could receive a request to create a new application identification. A game or application developer, for example, may wish to begin using the server system’s services. A developer can access an application or web portal to request a unique application identifier. The developer can provide the name of the application for which he wants a new app identifier. The server system 102 receives the request from the client device 110. As shown in operation 304, the server system 102 can then generate a unique application identifier, e.g. via an application server. As an example, the application server 122 can determine an application ID that has not been used (e.g. 5001341), and send it to the client device as shown in operation 306 The application server may store the application ID in one or multiple databases 126, along with other information (e.g. the name of the application associated with the app identifier). The developer can then start using services provided by server system 102, including calls to service(s) in the application.
Tokens can be used to authenticate client devices, application identifiers, user identifiers, etc. When an application or a game is first launched on a device client, it might send a request to obtain a new token. The request could include an identifier for the user who is playing or using the application. The request can also include an application identifier associated with the game or application. The server system may receive a request for a token and create a token that includes the user’s identifier. The server system may send the new token from the server device 102 to the client device. The server system 102 will then send the new token to the client device 110. The token can expire after a certain amount of time, e.g. duration of application or game use, 24 hours etc. The application or game can request a new token when a token has expired.
Click here to view the patent on Google Patents.
Leave a Reply