Invention for Personalized mobile device application presentation using photograph-based capability detection

Invented by Sunbir Gill, Kenley B. Capps, David R. Sodt, Mekka C. Okereke, Matthew A. Jones, Amazon Technologies Inc

The market for personalized mobile device application presentation using photograph-based capability detection is rapidly growing. With the increasing popularity of mobile devices and the advancements in technology, users are seeking more personalized and interactive experiences. This has led to the development of applications that can detect the capabilities of a mobile device through photographs and present customized content accordingly.

Photograph-based capability detection is a technology that allows mobile applications to analyze the capabilities of a device by capturing and analyzing photographs taken by the user. This includes features such as camera quality, screen resolution, processing power, and available sensors. By understanding the capabilities of a device, applications can optimize their presentation and provide a tailored experience to the user.

One of the key advantages of photograph-based capability detection is the ability to deliver personalized content. For example, if a user has a high-resolution camera, an application can present high-quality images or videos that take full advantage of the device’s capabilities. On the other hand, if a user has a device with limited processing power, the application can adjust its graphics and animations to ensure smooth performance.

Another benefit of this technology is the ability to optimize resource usage. By understanding the capabilities of a device, applications can allocate resources more efficiently. For example, if a device has limited memory, an application can reduce the size of cached data or prioritize the loading of essential resources. This not only improves the overall performance of the application but also enhances the user experience by minimizing resource-intensive operations.

Furthermore, photograph-based capability detection can also enable augmented reality (AR) experiences. By analyzing the device’s camera capabilities, applications can overlay virtual objects onto the real world in a more accurate and realistic manner. This opens up a wide range of possibilities for interactive and immersive experiences, such as virtual try-on for fashion or furniture shopping, interactive gaming, or educational applications.

The market for personalized mobile device application presentation using photograph-based capability detection is expected to grow significantly in the coming years. As more users demand personalized and interactive experiences, developers will continue to innovate and create applications that can adapt to the capabilities of different devices. This technology has the potential to revolutionize the way we interact with mobile applications, providing a more tailored and engaging experience for users.

However, there are also challenges that need to be addressed. Privacy and security concerns arise when applications have access to a user’s device capabilities through photographs. Developers must ensure that user data is handled securely and that proper consent is obtained before accessing device capabilities. Additionally, the accuracy and reliability of capability detection algorithms need to be improved to provide consistent and reliable results across different devices.

In conclusion, the market for personalized mobile device application presentation using photograph-based capability detection is an exciting and rapidly growing field. This technology has the potential to revolutionize the way we interact with mobile applications, providing personalized and interactive experiences tailored to the capabilities of each device. As technology continues to advance, we can expect to see more innovative applications that leverage photograph-based capability detection to enhance the user experience.

The Amazon Technologies Inc invention works as follows

A network application provides mobile devices personalized recommendations of apps based, at least in part, on the device resource of the mobile devices. Device resources can be detected by an interrogation performed on the device by a client of a mobile app store, or by metadata contained in a photo file taken by the device and sent to the network system. In order to detect incompatibilities, the network application system collects crash data from mobile device crashes. The system can then update the application requirements so that users do not see applications likely to crash their mobile devices. The system can also notify an application’s developers of detected incompatibility, so that users may receive a new version quickly.

Background for Personalized mobile device application presentation using photograph-based capability detection

Mobile devices such as tablets and smart phones are gaining in popularity. They come in different models, with varying hardware and software resources, operating systems and mobile carriers. Mobile devices are becoming more popular and there is an increasing demand for apps to run on them. A mobile device may need certain resources to run an application. “For example, the minimum requirements for a particular application may include a certain operating system or version, a touch screen, an accelerometer and/or additional resources.

Mobile application stores are available to help users find and download apps for their mobile devices. These mobile app stores can be accessed by a mobile connected to a wireless network. They offer applications for download and/or purchase. It can be beneficial to not allow users to download or purchase an application that is incompatible with their mobile device. It may be possible to keep a list of all mobile devices that are approved or not for a specific application if the number of models is small. As the number of models and their variety increases, and as new models are released more frequently, list-based compatibility becomes less accurate and burdensome. Users may also change the resources of their mobile device, such as changing the operating system or the mobile carrier that their mobile device accesses.

A new version of the popular mobile operating system could cause an app that ran stable under the previous version to crash in the new version. By detecting a correlation between the use of new operating systems on mobile devices and the increased frequency at which an application crashes, it may be possible to avoid frustration from users and accelerate a response by the application’s developers.

FIG. The figure 1 shows one embodiment of the system and method where a network application 104 helps a mobile device 103 user to obtain applications compatible with their device. This is done based on resources of the device. The network application system may be associated with an online storefront where users can browse, search, view descriptions, buy, and download mobile apps. In order to interrogate a mobile device, a mobile client application is installed on the user’s device 103. A mobile device may need a different version of the mobile application due to compatibility issues with operating systems, so a preliminary determination may be required. In case 1, the mobile application system 104 receives a photo file 1 from the mobile device. The user may be prompted to do this via the user interface of the application network system 104 by asking them to take a picture with their mobile device and then text or email it to a specific number or address. In event 2, network application system extracts metadata to determine mobile device model and performs model lookups to determine expected resources for the mobile device. In event 3, network application system provides the mobile client with an application compatible for mobile clients, such as a?app. store? App that allows users to buy applications through an app. Store of the network-based application system. The mobile application can include an interrogation code to be used for interrogating the device. FIG. does not show the model number. The model number can be provided to the user via a display page sent to the mobile device. In embodiments where the network application system supports only a certain class of mobile devices, such as Android devices, events 1 and 2 can be omitted and a “one size fits all” approach is preferred. In event 3, a mobile client application will be provided to the device.

In the event 4 the mobile client application runs an interrogation code to query the specific resources of the mobile device. The information provided may not be the same as the model number of the device (for instance, if the user has upgraded their operating system or switched to another mobile carrier). In event 5, mobile device 103 transmits the resources of the mobile devices, as determined by the interrogation to the network application systems 104. This information may be recorded by the network application system 104, along with the model number of the mobile device, and in conjunction with an existing account that the user has with the app store. The network application system has access to data on application requirements, which define, for each app, the minimum resources required by a device 103 in order to run that application. In event 6, the network application system receives a request from the mobile device, for example, a request to open an app store. In event 7, the application network performs a personalized application compatibility match, though in some embodiments this matching may be performed before receiving a store-request. This personalized application compatibility match compares the resources of the mobile devices to the resources needed by applications to determine which apps are compatible with mobile device 103. In the event 8, the application store page will reflect or indicate the compatibility between the applications and the mobile devices of the user. This personalization may be done when the user is accessing the application store via a device other than a mobile phone, such as a computer. In case 9, the mobile phone 103 transmits a request for an application purchase, but other requests can be made to download free applications that do not require a purchase. In case 10, the mobile phone 103 receives an application from the app store of the network system application.

The sample scenario in FIG. The system can also improve compatibility information through crash detection. The mobile device runs the application 11 downloaded from the network application systems and, if it crashes, the mobile application on the device 103 detects this crash. The crash report 12 contains information about the crash and is sent to network application system 104. The network application system analyzes and aggregates crash reports from multiple mobile devices. The system can detect correlations between resource usage and increased incidences of application crashes. A newly released version may cause an app that was stable in the previous version to crash frequently. This could lead to a lot of frustration among users, which can result in them leaving negative reviews about the application. It could harm the reputation of both the developer and the application. This is true even if the application was thoroughly tested at the time it was released. In one embodiment, system 104 reduces frustration significantly by updating the application requirements data in response the crash correlation detected. The application requirements data can describe the mobile device resources that are necessary, recommended or otherwise related to running a mobile app. This update could prevent other users from accessing the application if their device resources indicate an unacceptable high risk of instability. The network application system 104 may inform the developer or publisher of the application, by email, once it detects the crash correlation. This automated, quick alert to a detected incompatibility enables the developer of the application to quickly create a new release of the app that resolves the incompatibility with the newly released version of operating system. In another embodiment, users who downloaded the application previously, or users whose devices may not be compatible with the application are notified of the detected incompatibility.

Referring to FIG. In FIG. 2, a system embodiment is described more in detail, focusing on specific components that may be included within the system. A network application system is included in the described embodiment. Users systems 102 (such as general-purpose computers) access the network through the network, and communicate with the servers 110 of the network application 104. In one embodiment, servers 104 are web servers that provide network resources to user systems 102. These network resources can include, for example, web pages that provide users with access to an electronic catalogue through which they are able to purchase items. This includes mobile applications. Users may also be able to rent, lease, or bid on items such as music and movies. The servers 110 communicate with a catalog service 112. This service provides information about items that are available in the electronic catalog. This information can be stored in item data 113 and include, for instance, item descriptions and prices, item specifications and availability, as well as the identity of an author, manufacturer or developer. The item data 113 can include mobile applications.

Applications may include various types of code that can be executed on a device or accessed from one, including programs, applets and applications accessible through network browsers. (For example, HTML5 applications or Flash applications). These applications can be developed using a wide variety of programming language, including Java, Javascript HTML, XML CSS, Ruby C++ C# Visual Basic Pascal Object Pascal ActionScript XHTML WML and any combination thereof. Some embodiments categorize applications according to their general functionality. For example, navigation, games and multimedia, entertainment, system utilities or communication.

An application may be requested by a user of an user system 102 from a server. In this embodiment, server 110 queries catalog service 112 to retrieve item data 113 relating to the application. The server 110 also communicates with templates data 112, which provide predefined formats to present item data to users. The server formats the item data according at least to one template selected and transmits it to the user system.

In some embodiments mobile devices 103 can be a specific type of user system. Mobile devices 103 can include mobile phones and tablets, slate computers, laptops, netbooks, personal digital assistants, or any other electronic device. Recent advances in consumer electronic include embedded operating systems associated with mobile devices as well as their applications in a wide variety of devices including televisions and media devices. In certain embodiments, some of these devices can act as mobile devices. The methods and systems described in this document can be used to apply to other devices including general-purpose computers.

The network application systems 104 may be able to provide personalized information for different users, mobile devices 103, or user systems 102. Personalization services 114 may perform this personalization in conjunction with servers 110 of the network application system. Personalization can take many forms, including personalized search results, personalized recommendations, and personalized browsing through the applications that are available via the network application system. Personalization can be based on compatibility of resources between a user’s mobile device and resources recommended or required by mobile applications. The type of customization performed can depend on the computing device that is used to access an application store. As an example, let’s say a user registers 2 mobile devices with different capabilities in the application store using the process shown in FIG. 1 or another method. If the user browses through the store on a PC later, the system may customize pages to reflect compatibility between the applications and both mobile devices. 3-5). If, however, the system 104 detects the user browsing the store using one of these mobile devices only, it may personalize the pages of the app store to reflect or indicate the compatibility of applications with this particular mobile device.

The following are examples: the mobile device’s operating system (such as Google’s Android, Apple’s iOS, Microsoft Windows Phone, Research in Motion?s Blackberry OS or other operating systems), the particular version of the operating system and cellular carrier that is used by this device. The following are examples: the mobile device’s operating system (such as Google’s Android, Apple’s iOS, Microsoft’s Windows Phone, Research in Motion’s Blackberry OS, Hewlett-Packard/Palm’s webOS, Nokia’s Symbian, Hewlett-Packard/Palm’s Palm OS, or other operating systems), the particular version of the operating system, the cellular carrier which the mobile device uses, the central processing unit, graphical processing unit, quantity of random access memory, data storage capacity, display resolution, display density, display color range, display size, and/or presence of a number of other resources such as a touch-sensitive screen, virtual keyboard, physical keyboard, trackball, D-pad, microphone, speaker, Bluetooth radio, 802.11a/b/g/n radio, infrared port, display output, headphone output, particular device driver, software library, application, or other hardware or software resource which may be present on or available to the mobile device.

The example above describes one way to use requirement data, application compatibility logic, and user data. In another example data structures relating to application requirements can represent a specific set of requirements using a tree of logic operations. This tree is represented by a root node and sub-nodes. You can also link requirements using?AND? It can also be represented by linking requirements through?AND? A AND (B OR) C. “In another embodiment, the application requirements data include requirements specific to different versions, such as version 1.0 and version 1.1.

Alternatively or in addition, an application or version of the application may have multiple sets application requirements data. One set of requirements may be the minimum resources needed for a device to be compatible with an application. Another set defines the minimum resources required for the device to optimize for the application. The application can be displayed on a mobile device that has a higher resolution than the native application resolution. This may happen by, for example, displaying it only in part of the display or stretching/upscaling to match the resolution of the device. However, this may not result in the best experience. A mobile device that matches the native resolution of the application may be considered the optimal device, while one with a higher resolution than the application may only be compatible. Other examples include a mobile phone with a lower resolution than the application resolution that can downscale the resolution of the application, which is also compatible but not optimal.

Another embodiment provides a non boolean evaluation of compatibility of a mobile device with an application. The application compatibility matching logic may predict or determine the degree of compatibility of the mobile device and the application instead of determining if the mobile is compatible. The application compatibility matching logic can, for example, calculate a mobile device compatibility score based on application requirements. For example, the compatibility score can be calculated starting with a compatibility of 0, and then adding or removing points depending on the resources of the mobile device. A 600 megahertz CPU could add 20 to the compatibility score, while an 800 megahertz would add 30 and a dual core 1 gigahertz would add 50. A touch-sensitive display could earn you 30 points. However, if it lacks multi-touch capabilities, then 10 points could be deducted. Other logic for matching application compatibility, including alternative scoring methods and other compatibility classifications than “compatible” ?incompatible? Both?incompatible? It is possible to use?optimized? In another embodiment, Boolean and non-Boolean assessments are combined. “For example, one set of requirements may require that certain device resources be present, so a device will not be considered if they are missing, but may also have other device resource which may affect the degree compatibility.

User Data 120 can associate one or multiple mobile devices to a user account. A mobile device can also be linked to a temporary identification instead of a preexisting user account. A temporary user ID may be used, for example, when a device is detected and only stored during the session of the user and the account associated with the user has not been created. In the illustrated embodiment of user data 120, a report service is used in communication with a service for interrogation that is part of mobile application store client 15 running on mobile device 103. Installing the mobile application store 150 on a device 103 allows the user to interact with the network system 104 to download applications. This storefront functionality can be provided by a mobile store service 152. It allows the user to browse applications, search applications, read reviews, details, and receive personalized recommendations based on the personalization methods used by the network application systems personalization services. Users may have the option to purchase applications, rent them, or use them for a trial period. The network application system can store information about the user’s account, including payment information. This helps with purchasing mobile applications.

The system 104 can accept applications from developers or publishers. It may then split the sales revenue with the developer and/or publisher. Store client service 152 can be used as an alternative way to interact with the network system application 104. The network system application 104 is accessible via other means such as a web-browser installed on the user system 102. The store client service may communicate with the network application systems 104 via a network, and connect to a server (110), which could be a web-server or another server that is specialized in interacting with mobile application store customers 150. Server 110 that serves mobile application store clients may listen on ports associated with the Hypertext Transport Protocol (such as 8080 or 80) and/or use another protocol or port number.

The embodiment shown in FIG. The mobile application store 150 client includes an interrogation 153. The interrogation services 153 interrogates the mobile devices, for example by directly or indirectly interrogating its resources. This interrogation can occur when the mobile app store client 150 first installs on the mobile device 103, or at regular intervals after installation. It may also take place at the user?s request, without user input, or in the background. The interrogation service may perform an interrogation to determine what resources are available or present on the mobile device, 103. The interrogation service may, for example, check registry values or system information settings and/or attempt function calls to determine if such resources are available on the mobile device. These interrogations can involve direct interaction with the device resources 160 or system setting lookups in order to reveal their presence. In one embodiment, the interrogation services 153 is configured to perform a series interrogation steps for each group of resources that it tries to identify and detect. The interrogation system expects some interrogation requests to attempt to access device resources 160 that are not present, and it is designed to handle any errors or exceptions caused by these attempts. In some embodiments the interrogation 153 can also be used to perform a benchmarking test that may provide a value for the cumulative performance of the mobile device. In some embodiments the interrogation services may be part an applet or script, plug-in, application and/or a plug, which can be accessed via a webpage on the network application system.

The interrogation results may be sent by the interrogation services 153 to the report service 133, which is part the application store components 130 that make up the Network Application System 104. The results can be presented as an interrogation document, which is formatted in a markup language, such as XML, and sent over a TCP/IP network to the report service 133. In one embodiment, the client of the mobile application store 150 is configured to cache the interrogation reports in the event the mobile device cannot connect to the network system at the time the report is ready to be transmitted. The mobile application store 150 can then transmit the interrogation to the network system 104 later at a different time.

The report service may update the user data 120 upon receiving an interrogation report by the interrogation services 153. The report service can add data to a mobile device that the system 104 did not have previously. The report service can also replace or add old data to a mobile device. In another embodiment, a report service can maintain information about the resource data that the mobile 103 device previously had while updating user data so it reflects the resources of the mobile 103 device at the time the latest interrogation. This information can show how resources on a mobile device have changed over the years. This information can be used for analysis, particularly when aggregated to analyze statistical trends across a grouping of mobile devices. In other embodiments the report service sends a message to the mobile devices interrogation service to initiate an inquiry of the mobile device resources 160. The interrogation can be partial, comprehensive, or supplemental.

Click here to view the patent on Google Patents.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *