REVISION LOCKING

• US 20160092189A1
• Filed: 03/06/2015
• Published: 03/31/2016
• Est. Priority Date: 09/30/2014
• Status: Active Grant

• Current Assignee: Apple Inc.
• Original Assignee: Apple Inc.
• Inventors: Pollack, Daniel B., Novick, Gregory B., Hawkins, Tyler D., Brown, Eric S., Chinn, Paul W., Donley, David C., Poumailloux, Julien A.
• Granted Patent: US 10,095,500 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 8/65 Updates security arrangements therefor G06F21/57
• CPC Class Codes: G06F 8/71 Version control security arrangements therefor G06F21/57; Configuration management
• CPC Class Codes: G06F 9/546 Message passing systems or structures, e.g. queues

Abstract

When a new version of a first program is to be installed on a first device, metadata supplied to that device specifies which versions of a second program stored on a second device are compatible with the new version. The first device uses this metadata to determine a compatibility classification that indicates how compatible the current version of the second program and the new version of the first program are, and transitions to a state representative of this compatibility classification. A process executing on the first device receives messages from applications executing on the first device. The process reads mappings between these applications and the message types these applications send. The process forwards an application'"'"'s message to the second device if the application sends a message type allowable in the first device'"'"'s state. Otherwise, the process queues that message at least until the first device transitions to a different state.

Claims

1. A method of varying delivery of different types of messages based on device state and message origin, the method comprising:

at a first device having one or more processors, performing, by a filter executing on the first device;

receiving a first message from a first application executing on the first device;

reading a set of stored mappings that includes a first mapping and a second mapping, wherein the first mapping maps the first application to a first set of message types;

determining, based on the first mapping, that the first application sends messages having message types that are members of the first set of message types, the first message being of one of the first set of message types;

determining a first state of the first device;

determining whether a first message type corresponding to the first state is a member of the first set of message types;

in response to determining that the first message type is a member of a second set of message types, holding the first message in a queue until the first device transitions to a state corresponding to a message type that is contained in the first set of message types.

2. The method of claim 1, further comprising, at the first device:

determining that the first device has transitioned from the first state to a second state different from the first state;

determining whether a second message type corresponding to the second state is a member of the first set of message types; and

in response to determining that the second message type is a member of the first set of message types, removing the first message from the queue and sending the first message from the first device to a second device separate from the first device,

wherein the second set of message types is a set of types of messages that the first application is incapable of sending.

3. The method of claim 1, further comprising, at the first device:

receiving a second message from a second application executing on the first device separately from the first application, wherein the second mapping maps the second application to a third set of message types different from the first set of message types;

determining, based on the second mapping, that the second application sends messages having message types that are members of the third set of message types;

determining whether the first message type corresponding to the first state is a member of the third set of message types; and

in response to determining that the first message type is a member of the third set of message types, sending the second message from the first device to a second device separate from the first device.

4. The method of claim 1, wherein the first message type is a configuration message type or an update message type.

5. The method of claim 1, further comprising, at the first device:

receiving compatibility data that indicates a set of compatibility classifications that indicate how compatible versions of a second program are with a particular version of a first program that is to be installed on the first device;

determining, based on the compatibility data, a particular compatibility classification that indicates how compatible a current version of the second program stored on a second device separate from the first device is with the particular version of the first program;

determining that the particular compatibility classification indicates that the current version of the second program is compatible with the particular version of the first program but requires a user configuration of the second program on the second device;

transitioning the first device to a configuration state in which transmission of messages of a configuration message type from the first device to the second device is permitted;

transmitting the first message from the first device to the second device;

determining that the user configuration of the second program has been performed on the second device;

in response determining that the user configuration of the second program has been performed, installing the particular version of the first program on the first device and transitioning the first device from the configuration state to a general state in which transmission of messages of all message types from the first device is permitted.

6. The method of claim 5, wherein determining that the user configuration of the second program has been performed on the second device comprises:

receiving user input that confirms that a user has set values of one or more parameters used by the second program.

7. The method of claim 1, further comprising, at the first device:

receiving compatibility data that indicates a set of compatibility classifications that indicate how compatible versions of a second program are with a particular version of a first program that is to be installed on the first device;

determining, based on the compatibility data, a particular compatibility classification that indicates how compatible a current version of the second program stored on a second device separate from the first device is with the particular version of the first program;

determining that the particular compatibility classification indicates that the current version of the second program is incompatible with the particular version of the first program;

transitioning the first device to an update state in which transmission of messages of an update message type from the first device to the second device is permitted;

transmitting the first message from the first device to the second device;

determining that an update of the second program has been performed on the second device; and

in response determining that the update of the second program has been performed on the second device, rebooting the first device.

8. The method of claim 1, further comprising, at the first device:

receiving compatibility data that indicates a set of compatibility classifications that indicate how compatible versions of a second program are with a particular version of a first program that is to be installed on the first device;

determining, based on the compatibility data, a particular compatibility classification that indicates how compatible a current version of the second program stored on a second device separate from the first device is with the particular version of the first program; and

determining that the particular compatibility classification indicates that the current version of the second program is compatible with the particular version of the first program;

installing the particular version of the first program on the first device; and

transitioning the first device to a general state in which transmission of messages of all message types from the first device is permitted.

9. A non-transitory computer-readable storage memory storing instructions which, when executed by one or more processors of a first device, cause the one or more processors to perform operations comprising:

receiving a first message from a first application executing on the first device;

reading a set of stored mappings that includes a first mapping and a second mapping, wherein the first mapping maps the first application to a first set of message types;

determining, based on the first mapping, that the first application sends messages having message types that are members of the first set of message types, the first message being of one of the first set of message types;

determining a first state of the first device;

determining whether a first message type corresponding to the first state is a member of the first set of message types;

in response to determining that the first message type is a member of a second set of message types, holding the first message in a queue until the first device transitions to a state corresponding to a message type that is contained in the first set of message types.

10. The non-transitory computer-readable storage memory of claim 9, wherein the operations further comprise:

determining that the first device has transitioned from the first state to a second state different from the first state;

determining whether a second message type corresponding to the second state is a member of the first set of message types; and

in response to determining that the second message type is a member of the first set of message types, removing the first message from the queue and sending the first message from the first device to a second device separate from the first device, wherein the second set of message types is a set of types of messages that the first application is incapable of sending.

11. The non-transitory computer-readable storage memory of claim 9, wherein the operations further comprise:

receiving a second message from a second application executing on the first device separately from the first application;

wherein the second mapping maps the second application to a third set of message types different from the first set of message types;

determining, based on the second mapping, that the second application sends messages having message types that are members of the third set of message types;

determining whether the first message type corresponding to the first state is a member of the third set of message types;

in response to determining that the first message type is a member of the third set of message types, sending the second message from the first device to a second device separate from the first device.

12. The non-transitory computer-readable storage memory of claim 9, wherein the first message type is a configuration message type or an update message type.

13. The non-transitory computer-readable storage memory of claim 9, wherein the operations further comprise:

receiving compatibility data that indicates a set of compatibility classifications that indicate how compatible versions of a second program are with a particular version of a first program that is to be installed on the first device;

determining, based on the compatibility data, a particular compatibility classification that indicates how compatible a current version of the second program stored on a second device separate from the first device is with the particular version of the first program;

determining that the particular compatibility classification indicates that the current version of the second program is compatible with the particular version of the first program but requires a user configuration of the second program on the second device;

transitioning the first device to a configuration state in which transmission of messages of a configuration message type from the first device to the second device is permitted;

transmitting the first message from the first device to the second device;

determining that the user configuration of the second program has been performed on the second device; and

in response determining that the user configuration of the second program has been performed, installing the particular version of the first program on the first device and transitioning the first device from the configuration state to a general state in which transmission of messages of all message types from the first device is permitted.

14. The non-transitory computer-readable storage memory of claim 13, wherein determining that the user configuration of the second program has been performed on the second device comprises:

receiving user input that confirms that a user has set values of one or more parameters used by the second program.

15. The non-transitory computer-readable storage memory of claim 9, wherein the operations further comprise:

receiving compatibility data that indicates a set of compatibility classifications that indicate how compatible versions of a second program are with a particular version of a first program that is to be installed on the first device;

determining, based on the compatibility data, a particular compatibility classification that indicates how compatible a current version of the second program stored on a second device separate from the first device is with the particular version of the first program;

determining that the particular compatibility classification indicates that the current version of the second program is incompatible with the particular version of the first program;

transitioning the first device to an update state in which transmission of messages of an update message type from the first device to the second device is permitted;

transmitting the first message from the first device to the second device;

determining that an update of the second program has been performed on the second device; and

in response determining that the update of the second program has been performed on the second device, rebooting the first device.

16. The non-transitory computer-readable storage memory of claim 9, wherein the operations further comprise:

receiving compatibility data that indicates a set of compatibility classifications that indicate how compatible versions of a second program are with a particular version of a first program that is to be installed on the first device;

determining, based on the compatibility data, a particular compatibility classification that indicates how compatible a current version of the second program stored on a second device separate from the first device is with the particular version of the first program; and

determining that the particular compatibility classification indicates that the current version of the second program is compatible with the particular version of the first program;

installing the particular version of the first program on the first device; and

transitioning the first device to a general state in which transmission of messages of all message types from the first device is permitted.

17. A first device comprising:

one or more processors; and

a non-transitory computer-readable storage memory coupled to the one or more processors and storing instructions which, when executed by the one or more processors, cause the one or more processors to perform operations comprising;

receiving a first message from a first application executing on the first device;

reading a set of stored mappings that includes a first mapping and a second mapping, wherein the first mapping maps the first application to a first set of message types;

determining, based on the first mapping, that the first application sends messages having message types that are members of the first set of message types, the first message being of one of the first set of message types;

determining a first state of the first device;

determining whether a first message type corresponding to the first state is a member of the first set of message types;

in response to determining that the first message type is a member of a second set of message types, holding the first message in a queue until the first device transitions to a state corresponding to a message type that is contained in the first set of message types.

18. The first device of claim 17, wherein the operations further comprise:

determining that the first device has transitioned from the first state to a second state different from the first state;

determining whether a second message type corresponding to the second state is a member of the first set of message types; and

in response to determining that the second message type is a member of the first set of message types, removing the first message from the queue and sending the first message from the first device to a second device separate from the first device, wherein the second set of message types is a set of types of messages that the first application is incapable of sending.

19. The first device of claim 17, wherein the operations further comprise:

receiving a second message from a second application executing on the first device separately from the first application;

wherein the second mapping maps the second application to a third set of message types different from the first set of message types;

determining, based on the second mapping, that the second application sends messages having message types that are members of the third set of message types;

determining whether the first message type corresponding to the first state is a member of the third set of message types;

in response to determining that the first message type is a member of the third set of message types, sending the second message from the first device to a second device separate from the first device.

20. The first device of claim 17, wherein the first message type is a configuration message type or an update message type.

21. The first device of claim 17, wherein the operations further comprise:

receiving compatibility data that indicates a set of compatibility classifications that indicate how compatible versions of a second program are with a particular version of a first program that is to be installed on the first device;

determining, based on the compatibility data, a particular compatibility classification that indicates how compatible a current version of the second program stored on a second device separate from the first device is with the particular version of the first program;

determining that the particular compatibility classification indicates that the current version of the second program is compatible with the particular version of the first program but requires a user configuration of the second program on the second device;

transitioning the first device to a configuration state in which transmission of messages of a configuration message type from the first device to the second device is permitted;

transmitting the first message from the first device to the second device;

determining that the user configuration of the second program has been performed on the second device; and

in response determining that the user configuration of the second program has been performed, installing the particular version of the first program on the first device and transitioning the first device from the configuration state to a general state in which transmission of messages of all message types from the first device is permitted.

22. The first device of claim 21, wherein determining that the user configuration of the second program has been performed on the second device comprises:

receiving user input that confirms that a user has set values of one or more parameters used by the second program.

23. The first device of claim 17, wherein the operations further comprise:

receiving compatibility data that indicates a set of compatibility classifications that indicate how compatible versions of a second program are with a particular version of a first program that is to be installed on the first device;

determining, based on the compatibility data, a particular compatibility classification that indicates how compatible a current version of the second program stored on a second device separate from the first device is with the particular version of the first program;

determining that the particular compatibility classification indicates that the current version of the second program is incompatible with the particular version of the first program;

transitioning the first device to an update state in which transmission of messages of an update message type from the first device to the second device is permitted;

transmitting the first message from the first device to the second device;

determining that an update of the second program has been performed on the second device; and

in response determining that the update of the second program has been performed on the second device, rebooting the first device.

24. The first device of claim 17, wherein the operations further comprise:

receiving compatibility data that indicates a set of compatibility classifications that indicate how compatible versions of a second program are with a particular version of a first program that is to be installed on the first device;

determining, based on the compatibility data, a particular compatibility classification that indicates how compatible a current version of the second program stored on a second device separate from the first device is with the particular version of the first program; and

determining that the particular compatibility classification indicates that the current version of the second program is compatible with the particular version of the first program;

installing the particular version of the first program on the first device; and

transitioning the first device to a general state in which transmission of messages of all message types from the first device is permitted.

25. A method of facilitating an update of software on an accessory device using a companion device, the method comprising:

at the companion device having one or more processors;

receiving, from the accessory device, an install message that a new version of the software is ready to install on the accessory device, the install message identifying an expected build number of the new version;

storing the expected build number in a memory of the companion device;

receiving input from a user to perform an installation of the new version of the software on the accessory device;

receiving a confirmation message from the accessory device, the confirmation message including an actual build number of a current version of the software running on the accessory device;

retrieving the expected build number from the memory; and

comparing the actual build number to the expected build number to determine whether the installation of the new version of the software was successful.

26. The method of claim 25, wherein the install message includes the expected build number.

27. The method of claim 25, wherein the expected build number is stored in association with an identifier of the software.

28. The method of claim 25, further comprising, at the companion device:

determining an error in the installation of the new version of the software when the actual build number does not match the expected build number; and

providing an error message to the user.

29. The method of claim 25, further comprising, at the companion device:

storing a previous build number of a previous version of the software running on the accessory device; and

determining an error in the installation of the new version of the software when the actual build number is a match for the previous build number.

30. The method of claim 29, further comprising, at the companion device:

providing an error message to the user, the error message indicating that the new version of the software was not installed and that the previous version is still running on the accessory device.

31. The method of claim 25, further comprising, at the companion device:

starting a timer when the input is received from the user; and

providing an error message to the user if the confirmation message is not received after a specified amount of time.

32. The method of claim 25, further comprising, at the companion device:

providing a notification that the installation was successful to the user.

33. The method of claim 25, further comprising, at the companion device:

after receiving input from the user to perform the installation, losing a connection to the accessory device;

re-establishing the connection to the accessory device; and

receiving the confirmation message after re-establishing the connection to the accessory device.

34. The method of claim 25, wherein the software is an operating system of the accessory device.