BACKGROUND

[0001] Users of mobile devices are able to download music, movies and application software to their mobile device. Application stores may be used to download or purchase application software. Such application stores may permit users to browse different categories and genres of applications (e.g., productivity, multimedia, games etc.) and automatically download and install a chosen application.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] FIG. 1 is a block diagram of an example system in accordance with aspects of the present disclosure.

[0003] FIG. 2 is a flow diagram of an example method in accordance with aspects of the present disclosure.

[0004] FIG. 3 is a working example in accordance with aspects of the present disclosure.

[0005] FIG. 4 is a further working example in accordance with aspects of the present disclosure.

DETAILED DESCRIPTION

[0006] As noted above, application stores may be used to download or purchase application software to a device (e.g. , laptops, personal computers, smart phone, tablets, etc.). Application stores may be provided as a component of a device's operating system. In turn, the operating system may work closely with the device's hardware. Thus, application developers may have to develop and compile multiple versions of their applications and cater to the assortment of devices in the market. Furthermore, developers may need to publish their applications to each type of application store available in the various operating system environments.

[0007] Developing and publishing applications for each type of hardware and each type of application store may be a burdensome and tedious task. Each application store may have its own publishing protocol that developers need to observe. Furthermore, application developers may need to have different source code and compilers that generate applications executable in each device. Such limitations may impede the progress of application distribution. For example, bring-your-own- device ("BYOD") initiatives may be difficult to implement, since it may be difficult to securely distribute sensitive corporate applications to the various employee devices. BYOD is a policy in which employees of a company use their own device at work rather than using a device supplied by their employer.

[0008] In view of the foregoing, disclosed herein are a system, non-transitory computer readable medium, and method to transfer applications to devices. In one example, an application is compiled into a file executable in a device, if the device is permitted to receive the application. In another example, an address from which the application may be obtained may be broadcast. In yet a further example, meta-data associated with the application may be adjusted in accordance with a protocol of each application store to which the address is broadcast. Thus, rather than compiling source code for various devices, developers may use, for example, a unified modeling language ("UML"), or variation thereof, to define a source code template of the application. Such source code template may be used to automatically compile applications executable in various devices. The aspects, features and advantages of the present disclosure will be appreciated when considered with reference to the following description of examples and accompanying figures. The following description does not limit the application; rather, the scope of the disclosure is defined by the appended claims and equivalents thereof.

[0009] FIG. 1 presents a schematic diagram of an illustrative computer apparatus 100 depicting various components in accordance with aspects of the present disclosure. The computer apparatus 100 may include all the components normally used in connection with a computer. For example, it may have a keyboard and mouse and/or various other types of input devices such as pen-inputs, joysticks, buttons, touch screens, etc., as well as a display, which could include, for instance, a CRT, LCD, plasma screen monitor, TV, projector, etc. Computer apparatus 100 may also comprise a network interface (not shown) to communicate with other devices over a network using conventional protocols (e.g., Ethernet, Wi-Fi, Bluetooth, etc.). [0010] The computer apparatus 100 may also contain a processor 1 10, which may be any number of well known processors, such as processors from Intel ® Corporation. In another example, processor 1 10 may be an application specific integrated circuit ("ASIC"). Non-transitory computer readable medium ("CRM") 1 12 may store instructions that may be retrieved and executed by processor 1 10. As will be discussed in more detail below, the instructions may include an app-provider module 1 14. Non-transitory CRM 1 12 may be used by or in connection with any instruction execution system that can fetch or obtain the logic from non-transitory CRM 1 12 and execute the instructions contained therein.

[0011] Non-transitory computer readable media may comprise any one of many physical media such as, for example, electronic, magnetic, optical, electromagnetic, or semiconductor media. More specific examples of suitable non-transitory computer-readable media include, but are not limited to, a portable magnetic computer diskette such as floppy diskettes or hard drives, a read-only memory ("ROM"), an erasable programmable read-only memory, a portable compact disc or other storage devices that may be coupled to computer apparatus 100 directly or indirectly. Alternatively, non-transitory CRM 1 12 may be a random access memory ("RAM") device or may be divided into multiple memory segments organized as dual in-line memory modules ("DIMMs"). The non-transitory CRM 1 12 may also include any combination of one or more of the foregoing and/or other devices as well. While only one processor and one non-transitory CRM are shown in FIG. 1 , computer apparatus 100 may actually comprise additional processors and memories that may or may not be stored within the same physical housing or location.

[0012] The instructions residing in non-transitory CRM 1 12 may comprise any set of instructions to be executed directly (such as machine code) or indirectly (such as scripts) by processor 1 10. In this regard, the terms "instructions," "scripts," and "applications" may be used interchangeably herein. The computer executable instructions may be stored in any computer language or format, such as in object code or modules of source code. Furthermore, it is understood that the instructions may be implemented in the form of hardware, software, or a combination of hardware and software and that the examples herein are merely illustrative. [0013] In one example, app-provider module 1 14 may instruct processor 1 10 to broadcast an address from which an application can be obtained. In a further example, app-provider module 1 14 may instruct processor 1 10 to read a request by a remote device to access an application. In another aspect, app-provider module 1 14 may instruct processor 1 10 to determine whether the remote device has permission to receive the application. If the remote device has permission to receive the application, app-provider module 1 14 may instruct processor 1 10 to compile the application into a file that is executable in the remote device and transfer the application thereto.

[0014] Working examples of the system, method, and non-transitory computer- readable medium are shown in FIGS. 2-4. In particular, FIG. 2 illustrates a flow diagram of an example method 200 for transferring applications. FIGS. 3-4 each show a working example in accordance with the techniques disclosed herein. The actions shown in FIGS. 3-4 will be discussed below with regard to the flow diagram of FIG. 2.

[0015] Referring to FIG. 2, it may be determined whether a remote device has permission to receive an application, as shown in block 202. After broadcasting the location or logical address of the application, a remote device may send a request for the application. The request may be sent directly to app-provider module 1 14. Alternatively, the request may be received via an application store installed on the device. In one example, a user account associated with the remote device may be read to determine if the remote device has permission to receive the application. Referring now to FIG. 3, app-provider module 302 is shown broadcasting meta-data 314 to a plurality of application stores 304, 306, 308, and 310. Each application store may be configured for a particular operating system (e.g., iTunes, Android market place, Mac Apple Store etc.) In this example, meta-data 314 resides in repository 312, which may store source code of various applications and the metadata associated therewith. Repository 312 may comprises a relational database with tables having a plurality of different fields and records, XML documents or flat files. In another example, repository 312 may be a non-volatile storage device that may include, but is not limited to, a hard drive, phase change memory ("PCM"), spin- torque transfer RAM ("STT-RAM"), or flash memory. [0016] Broadcasting the location or logical address of the application may also include broadcasting meta-data associated with the application. Thus, rather than compiling and publishing an executable file for each type of device, the meta-data associated with the application may be broadcast and the source code may be compiled for a particular device upon request. The meta-data for the application may also include, but is not limited to, the list of components that make up the application, provisioning instructions, or configuration instructions. In one example, the meta-data may be provided by the developer in some standard format. In another example, the meta-data may be adjusted to comply with the protocol of each application store in which the meta-data is to be broadcast. The adjustment may include, for example, adjusting the meta-data into a format suitable for each application store. For example, in FIG. 3, meta-data 314 may be adjusted in accordance with a protocol of application stores 304, 306, 308, and 310. Such adjustment may take place automatically and may be abstracted from the application developer. The adjustment may be carried out by instructions in app-provider module 302 or by instructions in a separate module.

[0017] The permissions of a particular device may be contained in a user account associated with the remote device. The user account permissions may specify if payment was received for the application or if the user has permission to receive the application in view of some security policy. For example, if a corporation has a BYOD policy, certain applications may be made available to different types of employees. Each employee may register his or her device with the corporation in order to determine which corporate applications the employee can access. In another example, the permissions may specify whether the source code can be compiled into a file executable in the hardware of the remote device. As new hardware types are introduced into the market and other types of hardware fall out of favor, the administrators of the system may take time to adjust to changes in the hardware market.

[0018] Referring back to FIG. 2, source code may be compiled into a file executable in the remote device, as shown in block 204. Furthermore, the application may be transferred to the remote device, as shown in block 206. Referring now to FIG. 4, app-provider module 302 is shown initiating the compilation of source code 404 into executable file 408. In this example, the device 402 is a tablet and executable file 408 is executable in the tablet. While the example of FIG. 4 shows a tablet as the requesting device, it is understood that the requesting device may be of any type (e.g., smart phone, desktop, laptop, etc.). App-provider module 302 may transfer executable file 408 to device 402 via application store 304. As noted earlier, in another example, device 402 may download executable file 408 directly from app-provider module 302. Thus, in another example, app-provider module 302 may also behave as an application store. While the source code may be compiled upon request, in another example, a copy of the executable file 408 may be stored such that it can be resent to another requesting device with the same hardware profile as device 402. Executable file 408 may contain all the components necessary to execute the application in the remote device. In another example, executable file 408 may contain some of the necessary components and may also contain links to additional components residing in a remote location.

[0019] Advantageously, the foregoing computer apparatus, non-transitory computer readable medium, and method permit applications to be transmitted from a unified location regardless of the operating system or hardware of the devices requesting the application. In this regard, developers may program applications using UML tools without worrying about the different hardware and operating systems used by consumers. Instead, the system may automatically account for the differences by adjusting meta-data associated with the application in accordance with the protocol of each application store and by automatically compiling source code for each particular hardware type. In turn, application developers can easily reach more users than before and corporations may easily adopt a BYOD policy.

[0020] Although the disclosure herein has been described with reference to particular examples, it is to be understood that these examples are merely illustrative of the principles of the disclosure. It is therefore to be understood that numerous modifications may be made to the examples and that other arrangements may be devised without departing from the spirit and scope of the disclosure as defined by the appended claims. Furthermore, while particular processes are shown in a specific order in the appended drawings, such processes are not limited to any particular order unless such order is expressly set forth herein. Rather, processes may be performed in a different order or concurrently and steps may be added or omitted.