App authentication system and method

Abstract

A system and method for a web-based portal for certification of application software (apps). A draft app is created by an app developer and submitted to a web-based portal where a mediation manager reviews and approves or rejects the draft app based on a set of goals established by the app provider. The mediation manager communicates the rejection of the draft app to the developer. The mediation manager communicates the approval of the draft app to the developer and to one or more providers. The provider or providers can perform their own app review and modify the approved app with further goal attributes. The approved app is published by the developer. The approved and / or modified approved app can be provided to a user via the in-vehicle infotainment system.

Description

[Technical field]

[0001] cross reference This application claims priority to provisional applications 63 / 295352, 63 / 295368, and 63 / 295399, filed on December 30, 2021, and are incorporated by reference herein in their entireties.

[0002] The present disclosure relates to a system and method for authenticating application software, also known as apps, using a web-based portal. [Background technology]

[0003] When developing application software, hereafter referred to as an app, developers submit a draft version to an app provider, such as an app store, for certification by the provider before the app is made available for purchase (published) by users. The provider can test the app and make recommendations on changes for the developer to implement. After the app version is certified by the provider, the developer can publish the app and make it available for users to purchase through the provider. The process of the provider certifying the app version prior to the developer's publication typically involves several interactions before the provider gives final approval (certification) and the developer finally publishes the app.

[0004] Vehicles may be equipped with technology that connects the vehicle in a way that allows two-way communication with systems outside the vehicle, such as internet access, cloud services, and data sharing, typically running on the in-vehicle infotainment unit, providing a means for users to access providers from the vehicle. Original Equipment Manufacturers (OEMs) of such connected vehicles may provide their own version of an app store that can be accessed by the vehicle for users to access. OEMs may also provide apps to users by pre-installing the apps on the vehicle. Users may access free, for-sale, or pre-installed apps through the infotainment unit of the connected vehicle.

[0005] A vehicle-based app is an app that provides a user with the ability to control the basic operation of a vehicle. When multiple OEMs offer a developer's app, especially for vehicle-based apps, each OEM will have their own requirements or limitations for the app based on the vehicle's capabilities and limitations, such as the country in which the vehicle will operate, the vehicle make / model, the infotainment unit make / model, CPU type, application programming interface (API) level, etc. Working with multiple OEMs to determine the target attributes for so many different targets can be very cumbersome for an app developer. Similarly, it can also be unnecessarily complicated for an OEM if they are responsible for reviewing submissions from multiple different app developers.

[0006] An intermediary manager is needed to facilitate the submission and certification of apps submitted by app developers to OEMs and ensure that the apps are supported by the OEM's existing technology in the vehicle. Summary of the Invention [Means for solving the problem]

[0007] A system and method for a web-based portal for certification of application software (apps). A draft app is created by an app developer and sent to a web-based portal where an intermediary manager reviews and approves or rejects the draft app based on a set of target attributes set by the app provider. The intermediary manager communicates the rejection of the draft app with a reason to the developer. The intermediary manager communicates the approval of the draft app to the developer and to one or more providers. Notification of approval may be made to one or more providers simultaneously. One or more providers may perform their own app review and modify the approved app with further target attributes. One or more providers may review each approved draft app from multiple developers from the web-based portal. The approved app is published by the developer. The approved and / or modified approved app may be provided to the user by the provider through the in-vehicle infotainment system. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram illustrating the overall flow of app submission, certification, and publishing.

[0009] [Figure 2A] A screenshot of the developer's landing page.

[0010] [Figure 2B] A screenshot of the intermediary manager or provider / OEM landing page.

[0011] [Figure 2C] A screenshot of the landing page for comments from intermediary administrators to developers.

[0012] [Diagram 3] FIG. 1 is a flow diagram of the developer role.

[0013] [Figure 4] FIG. 13 is a flow diagram of the role of the intermediary manager.

[0014] [Diagram 5] FIG. 1 is a flow diagram of the OEM's role.

[0015] [Figure 6] FIG. 2 is a block diagram of a validation engine.

[0016] [Figure 7] FIG. 1 is a flow diagram of a verification method.

[0017] [Figure 8A] 1 is an example report of an acceptability analysis of an app used in a vehicle.

[0018] [Figure 8B] 1 is an example report of an acceptability analysis of an app used in a vehicle.

[0019] [Figure 9A] This is an example report of a security analysis of apps used in vehicles.

[0020] [Figure 9B] This is an example report of a security analysis of apps used in vehicles.

[0021] [Figure 10A] 1 is an example report of distraction analysis for an app used in a vehicle.

[0022] [Figure 10B] 1 is an example report of distraction analysis for an app used in a vehicle.

[0023] [Figure 11A] An example report of a privacy analysis of apps used in a vehicle.

[0024] [Figure 11B] An example report of a privacy analysis of apps used in a vehicle.

[0025] [Figure 12A] This is an example report of a malicious intent analysis of an app used in a vehicle.

[0026] [Figure 12B] This is an example report of a malicious intent analysis of an app used in a vehicle.

[0027] [Figure 13A] This is an example report of performance analysis of apps used in a vehicle.

[0028] [Figure 13B] This is an example report of performance analysis of apps used in a vehicle.

[0029] Elements and steps in the figures are illustrated for simplicity and clarity and do not necessarily have to be performed in any order, for example, steps that may be performed simultaneously or in different orders are illustrated in the figures to help improve understanding of embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] Although various aspects of the present disclosure have been described with reference to systems and methods for app authentication, the present disclosure is not limited to such embodiments, and additional modifications, applications, and embodiments may be implemented without departing from the present disclosure. In the figures, like reference numbers are used to indicate identical components. Those skilled in the art will appreciate that the various components shown herein may be modified without departing from the scope of the present disclosure.

[0031] FIG. 1 is a diagram 100 illustrating the course of action that an app takes within a web-based portal managed by an intermediary manager 108. App developers 104 design, create, deploy, and update custom software programs that are made available to the public through download or purchase and download by providers 112. In the following general description, the providers 112 that make the apps accessible are automotive OEMs that make the apps created by the app developers 104 available to the public. The apps can be used in vehicle-based systems and can be purchased, downloaded, or otherwise accessed from the infotainment system within the vehicle. There are three main participants in this process: the developers 104, the intermediary manager 108, and the OEM 112. The process 116 of developing and ultimately releasing an app is overhauled by the subject matter to streamline the process for both the app developers 104 and the OEM 112.

[0032] An app goes through a process from its creation, submission 102 by a developer 104, certification 106 by an intermediary administrator 108, review 110 by one or more providers 112, also referred to as automotive OEMs or OEMs 112, publication 114 by the app developer 104, and finally release 116 of a live version of the app available to the public via a platform supported by multiple OEMs 112.

[0033] The unique nature of apps accessible from a vehicle raises a variety of concerns that the developer 104 may not be immediately aware of, such as driver distraction, safety, and privacy. Also, from the perspective of the OEM 112 providing the apps to the public, there may be a large number of apps and a large number of developers 104 submitting apps to the OEM 112. The role of the intermediary administrator 108 in the subject matter of the present invention is to simplify the process for each developer 104 and each OEM 112 by jointly handling the certification details after the app is submitted by the developer 104. Details include, but are not limited to, quality assurance and testing to ensure that the app is suitable for use in a vehicle and that the app meets the target standards set by each OEM 112.

[0034] Typically, communications between developers 104 and OEMs 112 are handled confidentially through an intermediary administrator 108. In this process, the intermediary administrator 108 is familiar with the requirements from each OEM 112 and manages developers 104 to ensure that the developers develop apps that meet the specifications of each OEM 112, particularly those required for the use of the app in a vehicle. The knowledge base that the intermediary administrator 108 has for each OEM allows the intermediary administrator to handle multiple developers 104 and multiple OEMs 112, relieving the developer 104 of the burden of sifting through all the details for each OEM and relieving the OEM 112 of the burden of handling communications with each developer 104.

[0035] The benefit that the intermediary manager 108 provides to the developer 104 is that the developer's app, once published, can be offered by multiple OEMs 112 simultaneously. Similarly, the OEM 112 does not need to process multiple drafts of app submissions from multiple developers individually. The intermediary manager 108 pre-screens the draft apps to ensure that they meet the goals and specifications required by the OEM. Without the intermediary manager 108, each OEM 112 would be responsible for processing each app submission individually from a very early stage. Acting as an intermediary, the intermediary manager 108 handles the many behind-the-scenes steps required between the time a draft app is submitted 102 and when it is approved and made accessible to the user in the vehicle.

[0036] Figure 2A is a screenshot of an example developer landing page. After a developer is onboarded and given access to the web-based portal, draft apps are created and submitted through the web-based portal. The landing page provides a way for the developer to navigate the portal. An activity log allows the developer to view activity related to submitted apps, including but not limited to releases, approvals, pending draft apps, draft apps in review, published draft apps, etc.

[0037] FIG. 2B is a screenshot of an example landing page for an intermediary manager. A similar landing page is provided for providers. The landing pages are similar because the intermediary manager and provider each perform a similar review of the draft apps submitted by developers. For the sake of brevity, only the intermediary manager landing page is shown. The landing page shown in FIG. 2B provides an overview of the draft apps submitted by one or more developers. An overview of several in-progress draft apps and their status may be displayed, such as "Submitted," "Verifying," "Final Review," "Approved," "Published," and "Deleted." The list of "Submitted" apps is shown in FIG. 2B and may be organized or listed by the name of the app, the developer's company name (identified as the publisher in FIG. 2B), an identification of the version under review, and the date the app was submitted. Also displayed is the name of the app reviewer responsible for analyzing and reviewing the app (discussed in more detail below).

[0038] Figure 2C is a screenshot of an example landing page for a mediation manager to view the status of one of the apps under review. In the example shown in Figure 2C, the status includes an activity log listing each version. The mediation manager can leave comments and / or attach files related to the validation of the draft app submission.

[0039] 3 is a diagram 300 illustrating the role of a developer 104 in the process. The developer 104 on-boards 302 with an intermediary administrator 108. On-boarding may be performed via a web-based portal where the developer 104 applies for or is invited to access an app submission and certification system for an OEM to offer in-vehicle use (or purchase) of the app by an in-vehicle user.

[0040] After the developer 104 is onboarded, access to the portal is granted by the intermediary administrator 108, and the developer 104 has access to a landing page (see FIG. 2A ) that provides links to tools and guidelines the developer 104 needs to develop a draft app according to the target attributes set by the provider 112. The target attributes obtained from the OEM 112 may be specific to a particular OEM 112, set by a particular country, and / or set by a particular type of CPU or operating system. The draft app is typically designed around the target attributes 120. Some attributes may be known to the developer, e.g., metadata, OS version, etc. However, some attributes may be specific to a particular OEM, e.g., vehicle make / model, vehicle features, vehicle processing power, country, etc.

[0041] The attributes of every OEM, every country, and every CPU / OS are known by the intermediary manager 108 and presented to the developer 104 via the portal so that the developer can select which OEMs, which makes / models, and which countries are applicable to the app, thus providing immediate access to the target attributes required for designing the app, without the back and forth that would be required if the developer 104 had to contact each OEM 112, country, etc. directly.

[0042] As discussed above, the goal attributes may be restricted by technical characteristics (e.g., CPU architecture, OS version, feature availability, etc.) or commercial characteristics (e.g., specific car manufacturers, model years, etc.). For example, the developer 102 may allow an app to run only in vehicles of a particular manufacturer, or only in vehicles with a driver-facing camera, or to stream video on an infotainment display unit. Some restrictions may be due to the application itself, for example, if the application includes metadata indicating that an OS version, such as Android 10 or later, is required. For vehicles or OS versions restricted by the goal attributes, the intermediary manager 104 restricts the user's ability to view and download apps that are incompatible and cannot be used in the vehicle.

[0043] Once the developer 102 has completed the draft app, the draft app is submitted 306 via the portal to the intermediary administrator 108 to begin the certification process that is carried out by the intermediary administrator 108 (see point A in Figures 3 and 4). Figure 4 is a diagram 400 illustrating the role of the intermediary administrator in the certification process.

[0044] Draft apps submitted by developers 104 undergo a certification process in which a series of procedures and tests are performed on the draft app where an intermediary administrator 108 evaluates the draft app to ensure it meets the target attributes required by the provider. The certification process may include quality assurance 402. Quality assurance 402 may include, but is not limited to, bench testing to evaluate the draft app for factors related to each OEM's head unit and the functionality of the draft app, such as screen size, screen orientation, SSD capacity, OS version, and CPU / chipset.

[0045] Other examples of tests 404 may include automated tests tailored to evaluate interoperability, objectionable content, level of information collected, system privilege access, stability of app performance, and responsiveness of app performance. The tests described here are exemplary, as they are too numerous to list in their entirety. Tests and evaluations may be performed, for example, by the following systems and methods:

[0046] In one example, a validation engine determines whether an app is suitable for use in a vehicle. FIG. 6 is a block diagram of a validation engine 600 that determines whether an app is suitable for use in an in-car setting, such as whether a driver is suitable to use the app from the in-car infotainment, particularly while operating the vehicle. The validation engine 600 runs a number of tests on the app, analyzes the results, and issues a decision on what the impact of using the app in a vehicle is.

[0047] The validation engine 600 may determine whether the app causes driver distraction. The validation engine may determine whether the app, or a portion thereof, is malicious in nature. The validation engine 600 may determine whether the app poses a cybersecurity risk to the vehicle. The validation engine 600 may determine whether the app may put personal information of a user at risk. The validation engine 600 may determine how the app affects the performance of the device running the app, such as processor usage, memory usage, and flash wear of the infotainment unit.

[0048] To achieve this, the validation engine 600 performs static, dynamic, and external analysis of the app, which is aggregated, scored into categories, and a report is issued detailing how the app may affect the performance of the device on which it is running.

[0049] Static analysis is performed by a static verifier 602. The static verifier 602 performs static analysis of the decompiled code 604 and native libraries 606 associated with the app. Static analysis may include, but is not limited to, code extraction, reverse engineering, performing permission checks, etc.

[0050] Dynamic analysis is performed by a dynamic verifier 702. The dynamic verifier 702 performs analysis of hooks 704 within the app, performs analysis of app performance 706, and performs analysis of data logs 708. Dynamic analysis includes, but is not limited to, sandbox emulation, traffic capture, and resource usage monitoring.

[0051] Hooks 704 in apps are data and executable commands sent from one app to another over HTTP. Hooks 704 are functions that extend or modify the behavior of an app or the operating system. Typically, hooks are used for debugging or enhancement purposes. However, hooks can also be used by malicious code to adversely affect the output of an application programming interface. Analysis of hooks 704 determines their purpose in the app.

[0052] Analysis of the data log 708 may identify suspicious events or threats to sensitive data. Analysis of the data log searches the data to identify anomalies that may be causing problems. Examples of anomalies may include error codes, login issues such as unauthorized logins or password changes, threats from sources outside the vehicle network, exporting data, renaming files, etc.

[0053] The external validator 802 performs a malicious scan 804 and an open source scan 806. The malicious scan 804 is performed against the source code to flag malicious links, malware, etc. The open source scan 806 may include, but is not limited to, scanning open source software to identify common vulnerabilities and exposures (CVEs), use of outdated libraries, license compliance of open source components, etc.

[0054] The decision maker 902 aggregates 904 the results of the static verifier 602, the dynamic verifier 702, and the external verifier 802 to determine a score for each category evaluated. In this example, five categories are evaluated to verify whether the app is suitable for use in a vehicle. The categories may include, but are not limited to, privacy, performance, distraction, security, maliciousness, etc. The decision maker 902 applies a score 906 to each category and runs a final report 908 of the decision stage. The final report summarizes the apps, the scores, and the results of the analysis. The final report is prepared by an analyst (not shown in FIG. 6 ).

[0055] A score 908 is determined and assigned for each of the following categories: privacy, performance, distraction, security, and malicious intent. Scores are assigned based on the aggregate results for each category. Each score is used to assign an overall grade score for the vehicle. The overall grade score for the vehicle is the average of the scores for each category.

[0056] A report is generated that identifies and summarizes the apps, outlines the analysis results for each category, and can include technical details used by the validation engine.

[0057] Figure 7 is a flow diagram of a method 1000 performed by the validation engine of Figure 6. One or more application software packages, hereafter apps, may be stored in a backend database. The apps are submitted for validation 1002. Three verifiers, which may run in parallel, perform the analysis: a static verifier performs static analysis 1004 and an external verifier performs external analysis 1006. The static and external analysis may begin as soon as the app is submitted 1002.

[0058] After a snapshot of the virtual device is taken 1010 and sent 1012 to the dynamic verifier, the dynamic verifier begins performing 1008 dynamic analysis. A virtual device is a configuration that defines the characteristics of a device, tablet, or car device that is being simulated for analysis by the dynamic verifier. A snapshot is a saved image of a virtual device that preserves the entire state of the device at the time it was saved.

[0059] After all three stages of validation 1004, 1006, and 1008 have been fully performed, the decision maker performs a decision 1014 for each category. Once the decision 1014 is complete, the analyst is notified 1016. The analyst creates 1018 a final report 1020. A database, such as a universal artifact repository, stores 522 the decisions output by the decision maker.

[0060] Example reports are shown in Figures 8A to 13B. Figures 8A, 9A, 10A, 11A, 12A, and 13A are example reports for apps with scores indicating that they are suitable for use in a car. Figures 8B, 9B, 10B, 11B, 12B, and 13B are example reports for apps with scores indicating that they are not suitable for use in a car.

[0061] 8A and 8B are examples of a summary 1100 of the analysis performed by the verifier 602, 702, 802. The report may include an app summary 1102. The summary may include the name 1102a, logo 1102b, description 1102c, subject 1102d, version 1102e, and date of the app being verified. An overall grade score 1104 of the car is also displayed. This is the average of the scores assigned to each category. An analyst summary 1106 may be provided to provide a brief description of categories that may or may not be suitable for the car. For example, in FIG. 8A, the categories of privacy and driver distraction are considered compatible with the car, but the app's performance is not suitable for an in-car infotainment system. Failed tests 1108 may be identified. In the example of FIG. 8B, the overall score 1104 is 0 out of a maximum of 5 stars. This may indicate that the app is not suitable for an in-car infotainment system. Failed tests 1108 are identified.

[0062] Each category may be treated separately in the report. Figures 9A and 9B are examples of security analysis 1200 of two apps. The security analysis analyzes the impact of the app on the security posture of the device, which is an in-vehicle infotainment unit. Based on the analysis results, a score 1202 is assigned. Several features of the app are analyzed, including but not limited to HTTP communication 1204, autostart 1206, root 1208, Bluetooth control 1210, Wi-Fi control 1212, static IP 1214, vehicle application programming interface (API) (for Android apps) 1216, ports 1218, minimum SDK version 1220, launcher 1222, affinity 1224, and installation of another app 1226.

[0063] By analyzing the HTTP communication 1204, it is possible to determine whether the communication is secure. For example, if HTTP allows an intruder to tamper with the application's communication, there is a risk that the intruder may include a deliberately malicious attacker or a legitimate but intrusive company such as an ISP that injects advertisements into the page.

[0064] Autostart 1206 may indicate that the app will start automatically on boot. Apps registered for the BOOT_COMPLETE event have the permission to execute code after reboot without the user activating the app. Autostart can be problematic for in-car infotainment units, as they have very specific boot loading requirements associated with safety features in the vehicle, such as the rearview camera and other sensors in the vehicle.

[0065] Root 1208 can be analyzed to determine if the app is attempting to elevate privileges by attempting to become “root”, a privileged super user in the system. Bluetooth control 1210 can be analyzed to determine if the app is attempting to control Bluetooth power. Wi-Fi control 1212 can be analyzed to determine if the app is attempting to control Wi-Fi power. Static IP 1214 can be analyzed to determine if the app is querying a domain name. Vehicle API 1216 can be analyzed to determine if the app is using a vehicle API. Port 1218 can be analyzed to determine if the app opens a listening port. Minimum API version 1220 can be analyzed to determine if the app is using a minimum API level at which the app can run. Launcher 1222 can be analyzed to determine if the app is registered as the default launcher. Affinity 1224 can be analyzed to determine if the app is attempting to hijack another app. Install 1226 can be analyzed to determine if the app is attempting to install another app.

[0066] Based on the analysis, the analyst assigns a score to the category. For example, in Figure 9A, Security is assigned an overall score 1202 of 4 out of 5 stars. In Figure 9B, Security is assigned an overall score 1202 of 2 out of 5 stars.

[0067] 10A and 10B are examples of app distraction analysis 1300. Automotive apps should avoid unnecessary distraction of the driver from the road. App features that may lead to driver distraction are analyzed and assigned an overall score 1302. Volume 1304 can be analyzed to determine if the app uses volume control. Malicious apps can exploit volume control to affect the driver, for example ransomware can affect the driver by causing sudden volume changes. Screen hijack 1306 can be analyzed to determine if the app is attempting to hijack the screen. Intrusive ads 1308 can be analyzed to determine if the app uses ads, car-friendly ads, or no ads at all. Ads using videos, animations, and auto-scrolling can be considered as disruptive to the driver's control as they tempt the driver to interact with the app and cause them to take their eyes off the road for longer than a certain period of time.

[0068] 11A and 11B are examples of app privacy analysis 1400, where a score 1402 is assigned to a category by an analyst when the analyst reviews the verifier results. Car apps should minimize access to privacy data assigned to the driver. Tracker 1404 can be analyzed to determine if the app uses a tracker. A tracker is software intended to collect data about a user or app usage. Tracker 1404 is typically used for analysis. However, driver and vehicle personal data may also be used for marketing purposes. User identifier 1406 can be analyzed to determine if the app reads a user-specific identifier. Hardware identifier 1408 can be analyzed to determine if the app reads a hardware-specific identifier. Paired devices 1410 can be analyzed to determine if the app queries the history of paired devices. Bluetooth® Short Message Service (SMS) 1412 can be analyzed to determine if the app accesses SMS messages. Bluetooth® phonebook 1414 can be analyzed to determine if the app accesses the phonebook. The Bluetooth® call log 1416 can be analyzed to determine whether an app has access to the call log.

[0069] 12A and 12B are example malicious analysis 1500. Signature-based detection of an app can be analyzed to determine if the app is malicious by major antivirus engines. FIG. 12A is an example score 1502 for an app that was not detected as malicious. FIG. 12B is an example score 1504 for an app that was detected as malicious.

[0070] 13A and 13B are examples of performance analysis 1600, where categories are assigned scores 1602 by an analyst when the analyst reviews the results from the verifier. Resource consumption such as CPU usage, memory usage, and disk writes can be analyzed at various stages, such as at startup 1604, when the app is activated 1606, and when the app is in use 1608.

[0071] The reports described with reference to Figures 3A-13B are just a few examples of the analyses that may be performed during the intermediary administrator's review. The information generated in the reports, along with other comparisons related to the target attributes assigned by the provider / OEM, may be used by the intermediary administrator to ultimately determine whether to approve or reject the draft app.

[0072] 4, after quality assurance 402 and testing 404 are completed, the draft app is ready for review 406, which is also completed by the intermediary administrator 108. During the review 406, any test failures or changes / comments from the intermediary administrator 106 that cause the intermediary administrator 108 to reject 408 the draft app are compiled into a report. The draft app is returned 410 to the developer 104 (see FIGS. 3 and 4B) along with the test results and any comments from the intermediary administrator 104 reflecting any edits required to approve the draft app.

[0073] Referring again to FIG. 3, the developer 104 must consider the test results and comments provided by the intermediary administrator and proceed to edit 308 the draft app as recommended by the intermediary administrator. The developer edits 308 the draft app and submits the edited draft app again to the intermediary administrator for another go through the certification process. The submission and certification process is repeated as many times as necessary until the draft app is pre-approved for review by the intermediary administrator. Submission and review is also required if the developer 104 initiates edits 145 to an approved version of the app that have not been initiated by either the intermediary administrator 108 or the OEM 112.

[0074] 4, once the intermediary administrator approves 410 the draft app, the approved app is returned 414 to the developer, who may then publish 310 the approved app (see FIGS. 3 and 4C). Concurrently, the intermediary administrator submits 416 the approved app to the OEM 112, where it is submitted for final approval by the OEM (see FIGS. 4 and 5D).

[0075] Figure 5 is a diagram 500 showing the OEM's role in the process. Approved apps have already been quality assured, tested, and edited for approval by the intermediary manager. Because the intermediary manager is responsible for reviewing the app from the draft version to the approved version, the OEM can be confident that approval of the app by the intermediary manager means that the app meets the target requirements set by the OEM and meets the requirements necessary to operate successfully on the OEM's equipment in the vehicle.

[0076] The OEM's independent review of apps approved by the intermediary administrator allows the OEM to perform its own review 502 as a final check that the target attributes actually meet the OEM's standards. This app approval stage is significantly simpler than what the OEM would have to do without the intermediary administrator's work.

[0077] During this review stage 502, the OEM has the opportunity to apply additional constraints 504 to the target attributes that the OEM may determine are necessary for desired accessibility within the vehicle.

[0078] OEMs can also pre-install 506 apps in vehicles, making them available in the car without the user having to initiate a download. OEMs can also approve 508 approved apps, making them available for users to download and access once the developer publishes the app, i.e., goes live.

[0079] If an update to the app is necessary or desirable by either the OEM 112 or the developer 104, the app can also be unpublished 312 (see FIG. 3). A revised or updated version of the app is then submitted 306 through the certification process described above. Unpublished apps, such as draft apps or apps that were once published but unpublished for editing, can also be edited 308 or created 304 as updated versions of a previously published app. Editing an app before publication requires the developer to submit 306 a draft app to the intermediary manager 108. However, unpublishing 310 an app for revision after release requires an entirely new version of the draft app to be created 304 and submitted 306 to the intermediary manager 108 for certification and approval.

[0080] The description of the embodiments has been presented for purposes of illustration and description. Suitable modifications and variations to the embodiments may be implemented in light of the above description or may result from practicing the methods. For example, unless otherwise noted, one or more of the described methods may be performed by a suitable device and / or combination of devices, such as the embodiments described above with respect to FIGS. 1-13B. The methods may be performed by executing stored instructions in combination with one or more logic devices (e.g., processors) and one or more additional hardware elements, such as storage devices, memories, hardware network interfaces / antennas, switches, clock circuits, etc. The described methods and related operations may also be performed in various orders, in parallel, and / or simultaneously in addition to the order described in this application. The described systems are exemplary in nature and may include additional elements and / or omit elements. The subject matter of the present disclosure includes all novel and non-obvious combinations and subcombinations of the various disclosed systems and configurations, as well as other disclosed features, functions, and / or properties.

[0081] In the foregoing specification, the present disclosure has been described with reference to certain exemplary embodiments. The specification and drawings are illustrative rather than restrictive, and variations are intended to be included within the scope of the present disclosure. Thus, the scope of the present disclosure should be determined by the claims and their legal equivalents, and not merely by the examples described.

[0082] For example, the steps recited in any method or process claim may be performed in any order or repeated and are not limited to the particular order presented in the claims. Additionally, the components and / or elements recited in any apparatus claim may be assembled or otherwise configured to operate in various permutations and thus are not limited to the particular configuration recited in the claims. Any method or process described may be performed by executing instructions using one or more devices such as a processor or controller, memory (including non-transitory), sensors, network interfaces, antennas, switches, actuators, just to name a few.

[0083] In the foregoing specification, the present disclosure has been described with reference to certain exemplary embodiments. The specification and drawings are illustrative rather than restrictive, and variations are intended to be included within the scope of the present disclosure. Thus, the scope of the present disclosure should be determined by the claims and their legal equivalents, and not merely by the examples described.

[0084] For example, the steps recited in any method or process claim may be performed in any order or repeated and are not limited to the particular order presented in the claims. Additionally, the components and / or elements recited in any apparatus claim may be assembled or otherwise configured to operate in various permutations and thus are not limited to the particular configuration recited in the claims. Any method or process described may be performed by executing instructions using one or more devices such as a processor or controller, memory (including non-transitory), sensors, network interfaces, antennas, switches, actuators, just to name a few.

[0085] Although benefits, other advantages, and solutions to problems have been described above in connection with the embodiments, any benefit, advantage, solution to a problem, or any element that may give rise to or make more apparent any particular benefit, advantage, or solution, is not to be construed as a critical, required, or essential feature or component of any or all of the claims.

[0086] The terms "comprise," "comprises," "comprising," "having," "including," "includes," or any variation thereof, are intended to refer to a non-exclusive inclusion, such that a process, method, article, composition, or apparatus that includes a list of elements may include not only those elements described, but also other elements not expressly listed or specific to such process, method, article, composition, or apparatus. In addition to those not specifically described, other combinations and / or modifications of the above-described structure, arrangement, application, proportions, elements, materials, or components used in the practice of the present disclosure may be varied or otherwise specifically adapted to particular environments, manufacturing specifications, design parameters, or other operating requirements without departing from the general principles thereof.

Claims

1. 1. A web-based portal for authentication of application software (apps), comprising: A developer landing page where developers submit their draft apps for certification; a mediation manager landing page for a mediation manager to receive the draft app, review the draft app, approve or reject the app, and communicate with the developer; and a provider landing page for a provider to communicate with the intermediary manager, receive approved apps from the intermediary manager, apply restrictions to the approved apps, and approve the approved apps.

2. 2. The web-based portal of claim 1, wherein the intermediary manager landing page for rejecting the draft app further comprises an intermediary manager landing page for the intermediary manager to contact the developer with a report highlighting defects in the rejected app.

3. The web-based portal of claim 1 , wherein the developer landing page further comprises a developer landing page for the developer to access a template for creating the draft app prior to submitting the draft app.

4. The web-based portal of claim 2 , wherein the developer landing page further comprises a developer landing page for the developer to edit the rejected app and submit an edited draft app.

5. 10. The web-based portal of claim 1, wherein the provider is an automotive OEM and the approved apps can be provided to users via an in-vehicle infotainment system.

6. The web-based portal of claim 1 , wherein the intermediary manager communicates approval of a draft app to multiple providers.

7. The web-based portal of claim 1 , wherein the provider can review and modify draft apps from multiple developers.

8. A method for authenticating application software (app), comprising: granting developers and providers access to a web-based portal, said web-based portal being managed by an intermediary administrator; creating a draft app on the web-based portal, the draft app being created by the developer; submitting the draft app to the intermediary manager via the web-based portal; reviewing the draft app against quality, safety, and usability criteria for use in a vehicle environment, the review being performed by the intermediary manager via the web-based portal; issuing an approval or rejection of the draft app based on results of the reviewing, the approval of the draft app being communicated from the intermediary administrator to the developer and from the intermediary administrator to one or more providers via the web-based portal, and the rejection being communicated from the intermediary administrator to the developer via the web-based portal; reviewing the approved draft app, wherein reviewing the approved draft app is performed by the one or more providers on the web-based portal, and provider approval is communicated to the intermediary administrator and the developer; signing the approved draft app, wherein signing the approved draft is performed by the one or more providers; and publishing the approved draft app, wherein publishing the approved draft app is performed by the developer.

9. 10. The method of claim 8, wherein approving the approved draft app further comprises, at the web-based portal, the one or more providers modifying the approved draft app by applying provider-defined restrictions to the approved draft app prior to signing the approved draft app.

10. The method of claim 8 , wherein issuing a rejection of the draft app further comprises the intermediary administrator contacting the app developer with a comment explaining the rejection of the draft app.

11. The method of claim 10 , wherein communicating the approval to the developer and the one or more providers further comprises simultaneously communicating the approval to the one or more providers.

12. 10. The method of claim 8, wherein reviewing the approved draft apps by one or more providers on the web-based portal further comprises the providers reviewing each approved draft app submitted for certification from a plurality of developers.

Images