Case Nos. IPR2015-01470, -01471, -01472, -01473, -01474 and -01475 19 40. Thus, if the “social template” for “do-not-disturb-due-to-Mother-andbaby-sleeping” is selected in the above example, any communication requests would be handled according to the operations and authorizations set forth in Table 2. (Id.) VIII. The Combination of Miluzzo and Robarts A. Miluzzo 41. Miluzzo does not explicitly disclose specifics of how it infers a user’s status from sensor data, however, contrary to Mr. Williams’ assertion, it does teach where to store, and how to organize and retrieve, a users' status or privacy settings. 42. Miluzzo is concerned with sharing presence sensing, (e.g., determining a user’s location in conjunction with a keyboard’s activity). (Ex. GOOG 1007, ¶ [0002].) Miluzzo states “location is a key function in any sensing system.” (Id. ¶ [0044].) Miluzzo wants to update presence more frequently and allow more people to see the presence and to inject the presence into social networks. (Id. ¶¶ [0003]-[0004].) 43. Miluzzo suggests that it would be useful to sense the presence of a user like “outside of work.” (Id. ¶ [0012].) Miluzzo mentions analyzing sensed data (id. ¶ [0025]), but does not say how user activity classification (e.g., the inference engine) is accomplished. e.Digital Corporation Exhibit 2015 - Page 21 Case Nos. IPR2015-01470, -01471, -01472, -01473, -01474 and -01475 20 44. The architecture of Miluzzo is best expressed in Fig. 3 shown below. There, like the subject patents, the system starts with sensor data that, in the case of Miluzzo, is associated with a user. 45. Next, an inference engine is used to “infer the presence status of the user” from the received sensor data. 46. Miluzzo then stores the sensor data and inferred presence status for later use and distributes the presence status based on the “user’s preferences.” Basically, the distribution is along the lines of privacy policies set by the user. B. Robarts 47. Robarts, on the other hand, teaches an approach that starts with the selection of “themes” as opposed to data collected from sensors. Robarts’ process e.Digital Corporation Exhibit 2015 - Page 22 Case Nos. IPR2015-01470, -01471, -01472, -01473, -01474 and -01475 21 is expressed in Fig. 4, depicted below, which begins with a “theme” at step 402. (See also, Ex. GOOG 1008 at ¶ [0080].) 48. Themes in Robarts include “related sets of attributes that reflect the context of the user, including: (1) the user’s mental state, emotional state, and physical or health condition; (2) the user’s setting, car.” (GOOG 1008, ¶ [0040].) Attributes in Robarts are the product of the Context Server as described in Fig. 7, shown below. e.Digital Corporation Exhibit 2015 - Page 23 Case Nos. IPR2015-01470, -01471, -01472, -01473, -01474 and -01475 22 49. Robarts’ Fig. 7 discloses that data enters the Context Server at step 702 and is processed by Logic at step 704 before becoming attributes. 50. However, Robarts does not disclose the process that occurs in the Logic (704) that results in the creation of an attribute. (See Ex. GOOG 1001 passim). 51. Looking at Fig. 15 (shown below) of Robarts, at step 1505, Robarts determines the availability of themes first, before applying any attributes to them (step 1510). Robarts then determines which themes match the current context (step 1515). These themes may have been created by the user or may have even been e.Digital Corporation Exhibit 2015 - Page 24