DETAILED ACTION
This Action is responsive to the RCE filed on 12/22/2025.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Status
Claims 1-21 are amended. Claims 1-21 are pending and have been examined.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/22/2025 has been entered.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5, 7, 9-10, 13, 16, and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over Morris et al. (US 20070220009 A1)(cited by examiner in previous action)(hereafter referred to as Morris) further in view of Hauck et al. (US 20090144341 A1)(hereafter referred to as Hauck).
Regarding Claim 1,
Morris discloses the following limitations:
A method comprising:
at an electronic device (Client Device 108, Fig. 1) configured to communicate (Shared Network 110, Fig. 1 // ¶0032) with a storage device (Trusted Data Store 102, Fig. 1) separate from the electronic device:
…
receiving (Fig. 6, step 604), from the storage device, information (“a message” [0071] // “authentication information” [0011]) about characteristics (“identity of the owner” [0011]) of the storage device, including one or more first characteristics (“trusted” [0073]) describing capability of the storage device to isolate first data (¶0036) received from the electronic device from other data stored on the storage device (“At block 604, client device 108 may wait to receive a message from … trusted data store 102 … the received message may be tested to determine if it originated at trusted data store 102” [0071-73]) – As shown in Fig. 6 and detailed in ¶¶0071-73, a message received by client device 108 at step 604 is tested to determine if it originated at a “trusted” data store. As clarified in ¶0011, “authentication information” is used by all devices to verify device identity. As clarified in ¶0036, trusted data stores maintain “separate storage areas” for application data “with no overlap”. Accordingly, examiner considers the message received at step 604 of Fig. 6 as at least containing “information” indicating a first “characteristic” (i.e., an identity) describing a “capability” (i.e., “trusted” or not) of a storage device to “isolate first data” for client device 108.--;
and in response to receiving the information (Fig. 6): in accordance with a determination (Fig. 6, step 606) that the information about characteristics of the storage device satisfies (Fig. 6, step 606 ‘Yes’ branch) one or more criteria, sending (Fig. 7, steps 706 + 718) the first data to the storage device for isolated storage on the storage device (“all application data elements collected by application server 104 … may be written to trusted data store 102” [0091] // Fig. 6, steps 606 + 618 + 612 // ¶0076; 0079 // Fig. 7 // ¶¶0085; 0091) – As shown in Fig. 6 step 606, client device determines whether the received message originated from trusted data store 102. In this case, examiner considers a message being verified as originating from trusted data store 102 as “satisf[ying]” “one or more criteria”. As shown in Fig. 6 step 618 and detailed in ¶0079, client device 108 provides an application server 104 with “authorization” to process client requests after an affirmative determination in step 606. As shown in Fig. 7 step 706 and detailed in ¶0085, an authorized application server receives “one or more application data elements” (i.e., “first data”) from client device 108 (see also Fig. 6, step 612 // ¶0076). As shown in Fig. 7 step 718 and detailed in ¶0091, client application data is written into trusted data store 102 (i.e., “the storage device”)--; and
in accordance with a determination that the information about characteristics of the storage device does not satisfy the one or more criteria (Fig. 6, step 606 ‘No’ branch // ¶¶0073-74), forgoing (Fig. 6, step 620) the sending of the first data to the storage device (“At block 620 client device 108 may terminate all processing associated with the request message … upon detection of a messaging error in any of the message parsing procedures invoked in process 600” [0080]) – As shown in Fig. 6 step 620 and detailed in ¶0080, a client device “terminate[s]” a session after receiving a message (step 604) and determining (step 606) that the message does not originate from a trusted data store. Examiner considers a client device 108 terminating a session as “forgoing” sending of application data elements to trusted data store 102.
While Morris Figs. 6-7 and ¶0082 generally discloses the client device 108 sending a request to the application server 104 in order to establish a session prior to receiving a message from trusted data store 102 (see Fig. 6, step 602); Morris does not disclose separate detection and establishment of communication steps performed specifically by the client 108. In addition, Morris is silent regarding a specific step whereby communication is explicitly established between the client 108 and the trusted data store 102. Specifically, Morris does not explicitly disclose the following limitations:
detecting the storage device;
establishing communication between the storage device and the electronic device;
after establishing communication between the storage device and the electronic device, receiving, from the storage device, information about characteristics of the storage device
However, Hauck discloses the following limitations:
detecting (Fig. 2, step 204) the storage device (Archiving Device 102b, Fig. 1);
establishing communication (¶0029) between the storage device and the electronic device (Data Creation Device 102a, Fig. 1)(“The process 200 detects archiving devices on a network that are available to receive data backup (204)” [0034] // “the data creation device 102a can detect the archiving device 102b on the network 106 and establish a communication session” [0029] // Figs. 1 + 2) – As shown in Hauck Figs. 1-2, a data creation device 102a transmits backup data to an archiving device 102b (Fig. 2, step 212) after the data creation device authenticates the archiving device (Fig. 2, step 206), similar to how the client device 108 of Morris Fig. 1 sends application data to trusted data store 102 after the client device tests a message received from the trusted data store and verifies the identity of the trusted data store. Examiner accordingly considers data creation device 102a and archiving device 102b depicted in Hauck Fig. 1 as analogous to the claimed “electronic device” and “storage device”, respectively. As taught in Hauck, data creation device 102a establishes a communication session with archiving device 102b after detecting archiving device 102b--;
after establishing communication between the storage device and the electronic device, receiving (Fig. 2, step 206 // ¶0025), from the storage device, information (“signatures” [0025]) about characteristics of the storage device (“If an archive device is detected, a backup application can authenticate the archiving device and determine if the archiving device is authorized to receive data backup (206).” [0034] // “the data creation device 102a … can sign or resign and exchange signatures with one or more of the archiving devices 102b, 102c, and 102d, to facilitate authentication at the archiving devices” [0025]) – As shown in Fig. 2, after the archiving device is detected, the data creating device authenticates the archiving device prior to sending backup data. As clarified in ¶0025, in order to authenticate an archiving device, a data creating device exchanges signatures with (i.e., at least “receiv[es], from the storage device, information”) the archiving device.
Morris and Hauck are considered analogous to the claimed invention because they all relate to the same field of an electronic device performing authentication of a remote storage device. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Morris with the teachings of Hauck and realize a method of detecting and establishing communication with a storage device prior to sending data to the storage device. Doing so would improve data safety by ensuring secure communication channels and databases for storing user data, amounting to an improvement over traditional offsite backup services, as disclosed in Hauck ¶¶0004-05: “Offsite backup services also have disadvantages … Finally, sending user data over a public network can put the data at risk if the offsite backup service has not properly secured its communication channels or its databases for storing user data. The disadvantages above can be overcome by the disclosed implementations of simple offsite backup of user data. One or more devices on a network (e.g., a personal computer network) are detected by an offsite data backup system. Upon detection of a given device, the data backup system authenticates the device and determines whether the device is authorized and capable to receive backup data.” [0004-05]
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1, wherein the sending (Morris, Fig. 7, steps 706 + 718) of the first data occurs during a first communication session (Morris, “at block 702, application server 104 may receive a request for a session” [0082]), the method further comprising:
during a second communication, different from the first communication session (Morris, Fig. 7, step 720 ‘Yes’ branch + step 726 + step 702 // ¶¶0082; 0092-95): sending (Morris, Fig. 7, step 712) a request for the first data (Morris, “one or more application data elements” [0089]) to the storage device (Morris, “At block 712, application server 104 may transmit a message to trusted data store 102 requesting access to one or more application data storage locations” [0088]); and
receiving (Morris, Fig. 7, step 714) the first data from the storage device, wherein the receiving is based on the request for the first data (Morris, “At block 714, application server 104 may wait to receive a response with one or more application data elements requested at block 712” [0089]) – As shown in Morris Fig. 7 steps 720 + 702 and detailed in ¶¶0092-95, clients establish and delete sessions with application server 104. As shown in Fig. 7, during step 718 (i.e., of “a first communication session”), first data is sent to trusted data store 102, after which a session is deleted (step 726). As further shown in Fig. 7, after step 726, a client establishes a new session (e.g., during “a second communication”) (step 702; see also ¶0082), after which first data is requested from (step 712) and is received from (step 714) trusted data store 102.
Regarding Claim 3,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 3. The combined teachings of Morris and Hauck disclose the following limitations: The method of claim 1 (see Claim 1 limitation mappings above), wherein the sending (Morris, Fig. 7, steps 706 + 718) of the first data occurs during a first communication session (Morris, “at block 702, application server 104 may receive a request for a session” [0082]), the method further comprising:
during a second communication session, different from the first communication session (Morris, Fig. 6, steps 602 + 620 // Fig. 7, steps 702 + 720 // ¶0070) – As shown in Figs. 6 and 7, a client device can establish and end a session. One of ordinary skill in the art would accordingly understand that the method of Fig. 6 at least takes place during ‘a first communication session’ and also during “a second communication session, different from the first communication session”--:
in accordance with the determination (Morris, Fig. 6, step 606) that the information about characteristics of the storage device satisfies the one or more criteria (Morris, Fig. 6, step 606, ‘yes’ branch), sending (Morris, Fig. 7, steps 706 + 718 + 722) second data (Morris, “one or more data usage policies” [0032]), different from the first data (Morris, ¶¶0032; 0057), to the storage device for isolated storage (¶0036) — As detailed in Morris ¶0032, trusted data store 102 stores both application data elements (i.e., “first data”) and data usage policies (i.e., “second data, different from the first data”) for client devices--.; and
in accordance with the determination that the information about characteristics of the storage device does not satisfy the one or more criteria (Morris, Fig. 6, step 606 ‘No’ branch // ¶¶0073-74), forgoing (Morris, Fig. 6, step 620) the sending of the second data to the storage device.
Regarding Claim 5,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 3. The combined teachings of Morris and Hauck disclose the following limitations: The method of claim 1 (see Claim 1 limitation mappings above),
wherein the information about characteristics of the storage device further comprises one or more second characteristics (Hauck, Fig. 2, step 208 // ¶0035) indicative of capability of the storage device to store the first data (Hauck, “unused storage capacity” [0035]), and the one or more criteria include a first criterion that is satisfied when the one or more second characteristics indicate the storage device is capable of storing the first data (Hauck, “Once a given archiving device is authenticated and authorized, then the application can determine the unused storage capacity of the archiving device that is allocated for data backup (208). Such information can be obtained through, for example, a request to a file system, operating system (OS), driver, or the like, running on the archiving device … the backup application identifies the data to be backed up and the archiving device(s) that will receive the data backup based on the combined unused storage capacity” [0035-36]) – As taught in Hauck, after the data creation device authenticates the archiving device, the data creation device requests the “unused storage capacity” of the archiving device from the archiving device to determine whether or not the archiving device should receive the backup data.
Regarding Claim 7,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 7. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1, wherein the electronic device is a portable device (“a cell phone” [0035])
Regarding Claim 9,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 9. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1, the method further comprising: after detecting the storage device, sending (Hauck, Fig. 2, step 206 // ¶0025) information (“signatures” [0025]) about characteristics of the electronic device (“the data creation device 102a … can sign or resign and exchange signatures with one or more of the archiving devices 102b, 102c, and 102d, to facilitate authentication at the archiving devices” [0025]) – As previously discussed (see Claim 1 limitation mappings above) and as taught in Hauck, as part of authentication of archiving device 102b, data creation device 102a exchanges signatures with (i.e., at least provides “information about characteristics of the electronic device” to) archiving device 102b.
Regarding Claim 10,
The method of claim 1, wherein the one or more criteria include a criterion that is satisfied when the electronic device and the storage device are communicatively coupled using a shared wireless network (Morris, Shared network 110, Fig. 1 // ¶0032 // Fig. 6, step 606) – As shown in Morris Fig. 1 and detailed in ¶0032, client device 108 and trusted data store 102 communicate over a shared network 110 (i.e., “a shared wireless network”). As previously discussed (see Claim 1 limitation mappings above) and as shown in Fig. 6, after client device 108 verifies the identity of the message in step 606 (i.e., after determining “one or more criteria” are “satisfied”), client device authorizes (step 618) an application server to access data from trusted data store 102. One of ordinary skill in the art would accordingly understand that the aforementioned “one or more criteria” at least is “satisfied” when client device 108 and trusted data store 102 are coupled over a shared wireless network because all communication in exemplary system 100 takes place over a shared network 110.
Regarding Claim 13,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 13. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1, wherein the information about characteristics of the storage device is verified with an authority entity (Morris, Trust Authority 106, Fig. 1) other than the electronic device and the storage device (Morris, “Alternatively, client device 108 may forward credentials … to a trust authority 106 for certification of trust.” [0034] // ¶0081)
Regarding Claim 16,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 16. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1, further comprising:
sending (Morris, Fig. 6, step 602) a request (Morris, “Application Session Request” [Fig. 6]) for information associated with the one or more first characteristics describing capability of the storage device to isolate the first data from other data stored on the storage device (Morris, “at block 602, the client device 108 may send a message … to initiate an executable instance 506, providing appropriate client credentials in the request message” [0070]); and
after sending the request for information, receiving (Morris, Fig. 6, step 604) the information (Morris, “the received message” [0071]) associated with the one or more first characteristics based on the request for information (Morris, ¶¶0071-73).
Regarding Claim 18,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 18. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1, further comprising:
sending (Morris, Fig. 7, step 712) a request for the first data (Morris, “At block 712, application server 104 may transmit a message to trusted data store 102 requesting access to one or more application data element storage locations specified … by client device 108” [0088]); and
receiving (Morris, Fig. 7, step 722) the first data from a second electronic device (Morris, Trusted Application Server 104, Fig. 1) in communication with (Morris, Shared Network 110, Fig. 1 // ¶0032) the storage device via the storage device (Morris, “At block 722 … Application server 104 may also transfer one or more application data elements including application-generated data elements to client device 108.” [0093] // Fig. 7, step 714 // ¶0089) – As detailed in ¶0093, during step 722, client device receives application data elements from Application server 104 (i.e., “a second electronic device”). As shown in Fig. 7, step 714 and clarified in ¶0089, application server 104 receives the application data elements directly from (i.e., at least “via”) trusted data store 102.
Regarding Claim 21,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 21. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1, wherein the detecting the storage device includes the electronic device detecting that the storage device is in the vicinity of the electronic device. (Hauck, “when an archiving device 102b … is in the proximity of a wireless network (e.g., the user’s home wireless network), then an application running on the data creation device 102a can detect the archiving device 102b” [0029])
Regarding Claim 19,
Morris discloses the following information:
An electronic device (Client Device 108, Fig. 1) comprising:
memory storing instructions (¶0016); and
one or more processors coupled to the memory (¶0035), the one or more processors configured to:
…
receive (Fig. 6, step 604), from the storage device (Trusted Data Store 102, Fig. 1), information (“a message” [0071] // “authentication information” [0011]) about characteristics (“identity of the owner” [0011]) of the storage device, including one or more first characteristics (“trusted” [0073]) describing capability of the storage device to isolate first data (¶0036) received from the electronic device from other data stored on the storage device (“At block 604, client device 108 may wait to receive a message from … trusted data store 102 … the received message may be tested to determine if it originated at trusted data store 102” [0071-73]) – As shown in Fig. 6 and detailed in ¶¶0071-73, a message received by client device 108 at step 604 is tested to determine if it originated at a “trusted” data store. As clarified in ¶0011, “authentication information” is used by all devices to verify device identity. As clarified in ¶0036, trusted data stores maintain “separate storage areas” for application data “with no overlap”. Accordingly, examiner considers the message received at step 604 of Fig. 6 as at least containing “information” indicating a first “characteristic” (i.e., an identity) describing a “capability” (i.e., “trusted” or not) of a storage device to “isolate first data” for client device 108.--;
and in response to receiving the information (Fig. 6): in accordance with a determination (Fig. 6, step 606) that the information about characteristics of the storage device satisfies (Fig. 6, step 606 ‘Yes’ branch) one or more criteria, send (Fig. 7, steps 706 + 718) the first data to the storage device for isolated storage on the storage device (“all application data elements collected by application server 104 … may be written to trusted data store 102” [0091] // Fig. 6, steps 606 + 618 + 612 // ¶0076; 0079 // Fig. 7 // ¶¶0085; 0091) – As shown in Fig. 6 step 606, client device determines whether the received message originated from trusted data store 102. In this case, examiner considers a message being verified as originating from trusted data store 102 as “satisf[ying]” “one or more criteria”. As shown in Fig. 6 step 618 and detailed in ¶0079, client device 108 provides an application server 104 with “authorization” to process client requests after an affirmative determination in step 606. As shown in Fig. 7 step 706 and detailed in ¶0085, an authorized application server receives “one or more application data elements” (i.e., “first data”) from client device 108 (see also Fig. 6, step 612 // ¶0076). As shown in Fig. 7 step 718 and detailed in ¶0091, client application data is written into trusted data store 102 (i.e., “the storage device”)—and
in accordance with a determination that the information about characteristics of the storage device does not satisfy the one or more criteria (Fig. 6, step 606 ‘No’ branch // ¶¶0073-74), forgo (Fig. 6, step 620) the sending of the first data to the storage device (“At block 620 client device 108 may terminate all processing associated with the request message … upon detection of a messaging error in any of the message parsing procedures invoked in process 600” [0080]) – As shown in Fig. 6 step 620 and detailed in ¶0080, a client device “terminate[s]” a session after receiving a message (step 604) and determining (step 606) that the message does not originate from a trusted data store. Examiner considers a client device 108 terminating a session as “forgo[ing]” sending of application data elements to trusted data store 102.
While Morris Figs. 6-7 and ¶0082 generally discloses the client device 108 sending a request to the application server 104 in order to establish a session prior to receiving a message from trusted data store 102 (see Fig. 6, step 602); Morris does not disclose separate detection and establishment of communication steps performed specifically by the client 108. In addition, Morris is silent regarding a specific step whereby communication is explicitly established between the client 108 and the trusted data store 102. Specifically, Morris does not explicitly disclose the following limitations:
establish communication between a storage device and the electronic device;
detect the storage device;
after establishing communication between the storage device and the electronic device, receive, from the storage device, information about characteristics of the storage device
However, Hauck discloses the following limitations:
establish communication (¶0029) between a storage device (Archiving Device 102b, Fig. 1) and the electronic device (Data Creation Device 102a, Fig. 1);
detecting (Fig. 2, step 204) the storage device(“The process 200 detects archiving devices on a network that are available to receive data backup (204)” [0034] // “the data creation device 102a can detect the archiving device 102b on the network 106 and establish a communication session” [0029] // Figs. 1 + 2) – As shown in Hauck Figs. 1-2, a data creation device 102a transmits backup data to an archiving device 102b (Fig. 2, step 212) after the data creation device authenticates the archiving device (Fig. 2, step 206), similar to how the client device 108 of Morris Fig. 1 sends application data to trusted data store 102 after the client device tests a message received from the trusted data store and verifies the identity of the trusted data store. Examiner accordingly considers data creation device 102a and archiving device 102b depicted in Hauck Fig. 1 as analogous to the claimed “electronic device” and “storage device”, respectively. As taught in Hauck, data creation device 102a establishes a communication session with archiving device 102b after detecting archiving device 102b--;
after establishing communication between the storage device and the electronic device, receive (Fig. 2, step 206 // ¶0025), from the storage device, information (“signatures” [0025]) about characteristics of the storage device (“If an archive device is detected, a backup application can authenticate the archiving device and determine if the archiving device is authorized to receive data backup (206).” [0034] // “the data creation device 102a … can sign or resign and exchange signatures with one or more of the archiving devices 102b, 102c, and 102d, to facilitate authentication at the archiving devices” [0025]) – As shown in Fig. 2, after the archiving device is detected, the data creating device authenticates the archiving device prior to sending backup data. As clarified in ¶0025, in order to authenticate an archiving device, a data creating device exchanges signatures with (i.e., at least “receiv[es], from the storage device, information”) the archiving device.
Morris and Hauck are considered analogous to the claimed invention because they all relate to the same field of an electronic device performing authentication of a remote storage device. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Morris with the teachings of Hauck and realize a method of detecting and establishing communication with a storage device prior to sending data to the storage device. Doing so would improve data safety by ensuring secure communication channels and databases for storing user data, amounting to an improvement over traditional offsite backup services, as disclosed in Hauck ¶¶0004-05: “Offsite backup services also have disadvantages … Finally, sending user data over a public network can put the data at risk if the offsite backup service has not properly secured its communication channels or its databases for storing user data. The disadvantages above can be overcome by the disclosed implementations of simple offsite backup of user data. One or more devices on a network (e.g., a personal computer network) are detected by an offsite data backup system. Upon detection of a given device, the data backup system authenticates the device and determines whether the device is authorized and capable to receive backup data.” [0004-05]
Regarding Claim 20,
Morris discloses the following limitations:
A non-transitory computer readable storage medium storing instructions(¶0016) that, when executed at an electronic device (Client Device 108, Fig. 1) including memory storing instructions and including one or more processors coupled to the memory(¶0036), causes the electronic device to:
…
receive (Fig. 6, step 604), from the storage device, information (“a message” [0071] // “authentication information” [0011]) about characteristics (“identity of the owner” [0011]) of the storage device, including one or more first characteristics (“trusted” [0073]) describing capability of the storage device to isolate first data (¶0036) received from the electronic device from other data stored on the storage device (“At block 604, client device 108 may wait to receive a message from … trusted data store 102 … the received message may be tested to determine if it originated at trusted data store 102” [0071-73]) – As shown in Fig. 6 and detailed in ¶¶0071-73, a message received by client device 108 at step 604 is tested to determine if it originated at a “trusted” data store. As clarified in ¶0011, “authentication information” is used by all devices to verify device identity. As clarified in ¶0036, trusted data stores maintain “separate storage areas” for application data “with no overlap”. Accordingly, examiner considers the message received at step 604 of Fig. 6 as at least containing “information” indicating a first “characteristic” (i.e., an identity) describing a “capability” (i.e., “trusted” or not) of a storage device to “isolate first data” for client device 108.--;
and in response to receiving the information (Fig. 6): in accordance with a determination (Fig. 6, step 606) that the information about characteristics of the storage device satisfies (Fig. 6, step 606 ‘Yes’ branch) one or more criteria, send (Fig. 7, steps 706 + 718) the first data to the storage device for isolated storage on the storage device (“all application data elements collected by application server 104 … may be written to trusted data store 102” [0091] // Fig. 6, steps 606 + 618 + 612 // ¶0076; 0079 // Fig. 7 // ¶¶0085; 0091) – As shown in Fig. 6 step 606, client device determines whether the received message originated from trusted data store 102. In this case, examiner considers a message being verified as originating from trusted data store 102 as “satisf[ying]” “one or more criteria”. As shown in Fig. 6 step 618 and detailed in ¶0079, client device 108 provides an application server 104 with “authorization” to process client requests after an affirmative determination in step 606. As shown in Fig. 7 step 706 and detailed in ¶0085, an authorized application server receives “one or more application data elements” (i.e., “first data”) from client device 108 (see also Fig. 6, step 612 // ¶0076). As shown in Fig. 7 steps 718 and detailed in ¶0091, client application data is written into trusted data store 102 (i.e., “the storage device”)—and
in accordance with a determination that the information about characteristics of the storage device does not satisfy the one or more criteria (Fig. 6, step 606 ‘No’ branch // ¶¶0073-74), forgo (Fig. 6, step 620) the sending of the first data to the storage device (“At block 620 client device 108 may terminate all processing associated with the request message … upon detection of a messaging error in any of the message parsing procedures invoked in process 600” [0080]) – As shown in Fig. 6 step 620 and detailed in ¶0080, a client device “terminate[s]” a session after receiving a message (step 604) and determining (step 606) that the message does not originate from a trusted data store. Examiner considers a client device 108 terminating a session as “forgo[ing]” sending of application data elements to trusted data store 102.
While Morris Figs. 6-7 and ¶0082 generally discloses the client device 108 sending a request to the application server 104 in order to establish a session prior to receiving a message from trusted data store 102 (see Fig. 6, step 602); Morris does not disclose separate detection and establishment of communication steps performed specifically by the client 108. In addition, Morris is silent regarding a specific step whereby communication is explicitly established between the client 108 and the trusted data store 102. Specifically, Morris does not explicitly disclose the following limitations:
establish communication between a storage device and the electronic device;
detect the storage device;
after establishing communication between the storage device and the electronic device, receive, from the storage device, information about characteristics of the storage device
However, Hauck discloses the following limitations:
establish communication (¶0029) between a storage device (Archiving Device 102b, Fig. 1) and the electronic device (Data Creation Device 102a, Fig. 1);
detecting (Fig. 2, step 204) the storage device(“The process 200 detects archiving devices on a network that are available to receive data backup (204)” [0034] // “the data creation device 102a can detect the archiving device 102b on the network 106 and establish a communication session” [0029] // Figs. 1 + 2) – As shown in Hauck Figs. 1-2, a data creation device 102a transmits backup data to an archiving device 102b (Fig. 2, step 212) after the data creation device authenticates the archiving device (Fig. 2, step 206), similar to how the client device 108 of Morris Fig. 1 sends application data to trusted data store 102 after the client device tests a message received from the trusted data store and verifies the identity of the trusted data store. Examiner accordingly considers data creation device 102a and archiving device 102b depicted in Hauck Fig. 1 as analogous to the claimed “electronic device” and “storage device”, respectively. As taught in Hauck, data creation device 102a establishes a communication session with archiving device 102b after detecting archiving device 102b--;
after establishing communication between the storage device and the electronic device, receive (Fig. 2, step 206 // ¶0025), from the storage device, information (“signatures” [0025]) about characteristics of the storage device (“If an archive device is detected, a backup application can authenticate the archiving device and determine if the archiving device is authorized to receive data backup (206).” [0034] // “the data creation device 102a … can sign or resign and exchange signatures with one or more of the archiving devices 102b, 102c, and 102d, to facilitate authentication at the archiving devices” [0025]) – As shown in Fig. 2, after the archiving device is detected, the data creating device authenticates the archiving device prior to sending backup data. As clarified in ¶0025, in order to authenticate an archiving device, a data creating device exchanges signatures with (i.e., at least “receiv[es], from the storage device, information”) the archiving device.
Morris and Hauck are considered analogous to the claimed invention because they all relate to the same field of an electronic device performing authentication of a remote storage device. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Morris with the teachings of Hauck and realize a method of detecting and establishing communication with a storage device prior to sending data to the storage device. Doing so would improve data safety by ensuring secure communication channels and databases for storing user data, amounting to an improvement over traditional offsite backup services, as disclosed in Hauck ¶¶0004-05: “Offsite backup services also have disadvantages … Finally, sending user data over a public network can put the data at risk if the offsite backup service has not properly secured its communication channels or its databases for storing user data. The disadvantages above can be overcome by the disclosed implementations of simple offsite backup of user data. One or more devices on a network (e.g., a personal computer network) are detected by an offsite data backup system. Upon detection of a given device, the data backup system authenticates the device and determines whether the device is authorized and capable to receive backup data.” [0004-05]
Claims 4 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Morris further in view of Hauck and Perlman et al. (US 20220237148 A1)(cited by examiner in previous action)(hereafter referred to as Perlman).
Regarding Claim 4,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), further comprising: sending a request (Morris, “storage requests” [0057]) for second data (“one or more data usage policies” [0032]), different from the first data (Morris, ¶0032), wherein the second data is stored at the storage device (Morris, “In FIG. 1, trusted data store 102 … may include one or more application data elements and one or more data usage policies” [0032] // “For … storage requests, database manager 310 may extract a copy of … one or more application data elements, as well as any data usage policies stored in application data element store 112” [0057] // Figs. 1 + 3) – As detailed in Morris ¶0032, trusted data store 102 stores both application data elements (i.e., “first data”) and data usage policies (i.e., “second data, different from the first data”). As clarified in ¶0052, a database manager requests data usage policies from trusted data store 102.;
The combined teachings of Morris and Hauck are silent regarding the following limitations:
receiving an indication that the second data is not accessible to the electronic device from the storage device
However, Perlman discloses the following limitations:
receiving an indication (“error” [0052]) that the second data is not accessible to the electronic device from the storage device (“In general, a client may issue a read request to a server … In the event the client is asking for data for which the retention time has passed and the server has deleted the data, the read request will fail with a corresponding error.” [0052] // Fig. 1 // ¶¶0027; 0033) – As shown in Fig. 1, client devices (Clients 102, Fig. 1) running applications send (¶0027) application data to a remote storage device (Storage System 300, Fig. 1) and later request (¶0052) the data from a server (Backup/Restore Server 202, Fig. 1). Examiner accordingly considers environment 100 disclosed in Perlman Fig. 1 as analogous to exemplary system 100 disclosed in Morris Fig. 1. As detailed in Perlman ¶0052, an error (i.e., “an indication that the second data is not accessible”) is sent (to a client; see ¶0033) when “retention time” for requested data has passed.
Morris, Hauck, and Perlman are both considered analogous to the claimed invention because they all relate to the same field of sending and receiving user application data to a remote storage system through a server. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Morris and Hauck with the teachings of Perlman and realize a method of indicating that data is not available after a predetermined retention time has elapsed. Doing so would enable a storage system to know when client data can be erased without requiring action from the client, improving the storage system’s ability to perform garbage collection in environments when clients are unable or unwilling to perform garbage collection themselves, as disclosed in Perlman ¶¶0010-11: “In general, example embodiments of the invention may enable a client to assign a “retention date” to client data that is to be stored at a storage server … it is useful for the block storage back end system to be able to know when blocks can be deleted, that is, when all copies of that block have reached their retention date … In this way, the storage server may be able to discard blocks even if some clients are not online, or are not bothering to garbage-collect the file system to delete data that has reached its retention date.” [0010-11].
Regarding Claim 17,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 17. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), further comprising:
sending (Morris, Fig. 7, step 712) a request for the first data (Morris, “At block 712, application server 104 may transmit a message to trusted data store 102 requesting access to one or more application data element storage locations specified … by client device 108” [0088]), wherein the first data is sent (Morris, Fig. 7, step 718) at a first time – As previously discussed (see Claim 1 limitation mappings above), first data is sent to trusted data store 102 during step 718. One of ordinary skill in the art would understand that step 718 at least takes place “at a first time”—and the request is sent (Morris, Fig. 7, step 712) at a second time, after the first time (Morris, Fig. 7, step 720 ‘Yes’ branch + step 726 + step 702 // ¶¶0082; 0092-95) – As shown in Morris Fig. 7, after first data is sent to trusted data store 102 (step 712), a session is deleted (step 726), a client establishes a new session (step 702, see also ¶0082), and application server 104 requests application data elements (step 718). One of ordinary skill in the art would therefore understand that step 718 at least takes place at “a second time, after the first time”--; and
The combined teachings of Morris and Hauck are silent regarding the following limitations:
receiving an indication that the first data is not available, wherein the indication is based on a third time corresponding to time elapsed from the first time to the second time
However, Perlman discloses the following limitations:
receiving an indication (“error” [0052]) that the first data is not available, wherein the indication is based on a third time (“the retention time” [0052]) corresponding to time elapsed from the first time to the second time (“In general, a client may issue a read request to a server … In the event the client is asking for data for which the retention time has passed and the server has deleted the data, the read request will fail with a corresponding error.” [0052] // Fig. 1 // ¶¶0027; 0033) – As shown in Fig. 1, client devices (Clients 102, Fig. 1) running applications send (¶0027) application data to a remote storage device (Storage System 300, Fig. 1) and later request (¶0052) the data from a server (Backup/Restore Server 202, Fig. 1). Examiner accordingly considers environment 100 disclosed in Perlman Fig. 1 as analogous to exemplary system 100 disclosed in Morris Fig. 1. As clarified in Perlman ¶0033, “retention” corresponds to an amount of time data will be retained in storage, after which it may be deleted. Examiner accordingly considers the concept of “retention time” disclosed in Perlman ¶0052 as representing an amount of time elapsed from when data is sent to storage to when data is requested from a server (i.e., “time elapsed from the first time to the second time”). As detailed in Perlman ¶0052, an error (i.e., “an indication that the first data is not available”) is sent (to a client; see ¶0033) when “retention time” for requested data has passed.
Morris, Hauck, and Perlman are both considered analogous to the claimed invention because they all relate to the same field of sending and receiving user application data to a remote storage system through a server. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Morris and Hauck with the teachings of Perlman and realize a method of indicating that data is not available after a predetermined retention time has elapsed. Doing so would enable a storage system to know when client data can be erased without requiring action from the client, improving the storage system’s ability to perform garbage collection in environments when clients are unable or unwilling to perform garbage collection themselves, as disclosed in Perlman ¶¶0010-11: “In general, example embodiments of the invention may enable a client to assign a “retention date” to client data that is to be stored at a storage server … it is useful for the block storage back end system to be able to know when blocks can be deleted, that is, when all copies of that block have reached their retention date … In this way, the storage server may be able to discard blocks even if some clients are not online, or are not bothering to garbage-collect the file system to delete data that has reached its retention date.” [0010-11].
Claims 6 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Morris further in view of Hauck and Bender et al. (US 20110276803 A1)(hereafter referred to as Bender).
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), wherein the information about characteristics of the storage device further comprises one or more … characteristics indicative of a level of trust (Morris, “trusted” [0073]) associated with the storage device – As previously discussed (see Claim 1 limitation mappings above), authentication information enables client device 108 to determine that a received message originated at trusted data store 102. Accordingly, examiner considers the authentication information received by client device 108 as at least “indicative of a level of trust” for an originator of a message.-- ,
and the one or more criteria include a first criterion that is satisfied when the one or more … characteristics include an indication of verification of an identity of the storage device (Morris, Fig. 6, step 606) – As previously discussed and as shown in Fig. 6, authentication information enables client device 108 to verify the identity of trusted data store 102.
Although Morris ¶0011 discloses that “any form” of authentication information can be used, the combined teachings of Morris and Hauck do not appear to explicitly disclose the following limitations:
wherein the information about characteristics of the storage device further comprises one or more second characteristics
However, Bender discloses within the context of generating device certificates for identity verification that a “manufacturing certificate” can include both hardware and software characteristics of a device.
Bender discloses the following limitations:
wherein the information about characteristics of the storage device further comprises one or more second characteristics (“During the manufacturing process … the manufacturing certificate authority 12 obtains the identity information or the device ID … the device ID can include one or more types of information … hardware characteristics or capabilities and a MAC address … the manufacturing certificate authority 12 binds the device ID and the public key to form a manufacturing certificate” [0067-68] // Fig. 5) – As disclosed in ¶¶0067-68, a “manufacturing” type of device certificate includes both hardware (i.e., first) characteristics and a MAC address (i.e., a “second” characteristic).
Morris, Hauck, and Bender are both considered analogous to the claimed invention because they all relate to the same field of verification of mobile device identities using certificates. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Morris and Hauck with the teachings of Bender and realize a method of providing both hardware and software information about a device as information which describes an overall capability of the device. Doing so enables device manufacturers to create manufacturing certificates for devices based on information which does not change over time, allowing devices to verify authenticity of origin while simultaneously enabling a manufacturer to maintain a separate certificate authority for devices, as disclosed in Bender ¶¶0024-27: “throughout the operational life of the device, there may be different owners or users. Therefore, it is difficult to obtain the identity of the device … It can be understood that there are no means to query a device for authenticity of its origins. It may also be desirable for a manufacturer to control an external entity’s level of access or use of certain operations or functions of the device … It has been recognized that in order to address the above problems, a multi-certificate strategy and certificate authority strategy should be established during the manufacturing of the device.” [0024-27]
Regarding Claim 11,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 11. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above),
Although Morris ¶0011 discloses that “any form” of authentication information can be used, the combined teachings of Morris and Hauck do not explicitly disclose the following limitations:
wherein the information about characteristics of the storage device includes hardware characteristics of the storage device.
However, Bender discloses within the context of generating device certificates for identity verification that a “manufacturing certificate” can include both hardware and software characteristics of a device.
Bender discloses the following limitations:
wherein the information about characteristics of the storage device includes hardware characteristics of the storage device (“During the manufacturing process … the manufacturing certificate authority 12 obtains the identity information or the device ID … the device ID can include one or more types of information … hardware characteristics or capabilities and a MAC address … the manufacturing certificate authority 12 binds the device ID and the public key to form a manufacturing certificate” [0067-68] // Fig. 5) – As disclosed in ¶¶0067-68, a “manufacturing” type of device certificate includes both hardware characteristics and a MAC address.
Morris, Hauck, and Bender are both considered analogous to the claimed invention because they all relate to the same field of verification of mobile device identities using certificates. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Morris and Hauck with the teachings of Bender and realize a method of providing both hardware and software information about a device as information which describes an overall capability of the device. Doing so enables device manufacturers to create manufacturing certificates for devices based on information which does not change over time, allowing devices to verify authenticity of origin while simultaneously enabling a manufacturer to maintain a separate certificate authority for devices, as disclosed in Bender ¶¶0024-27: “throughout the operational life of the device, there may be different owners or users. Therefore, it is difficult to obtain the identity of the device … It can be understood that there are no means to query a device for authenticity of its origins. It may also be desirable for a manufacturer to control an external entity’s level of access or use of certain operations or functions of the device … It has been recognized that in order to address the above problems, a multi-certificate strategy and certificate authority strategy should be established during the manufacturing of the device.” [0024-27]
Regarding Claim 12,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 12. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above),
Although Morris ¶0011 discloses that “any form” of authentication information can be used, the combined teachings of Morris and Hauck do not explicitly disclose the following limitations:
wherein the information about characteristics of the storage device includes software characteristics of the storage device
However, Bender discloses within the context of generating device certificates for identity verification that a “manufacturing certificate” can include both hardware and software characteristics of a device.
Bender discloses the following limitations:
wherein the information about characteristics of the storage device includes software characteristics of the storage device (“During the manufacturing process … the manufacturing certificate authority 12 obtains the identity information or the device ID … the device ID can include one or more types of information … hardware characteristics or capabilities and a MAC address … the manufacturing certificate authority 12 binds the device ID and the public key to form a manufacturing certificate” [0067-68] // Fig. 5) – As disclosed in ¶¶0067-68, a “manufacturing” type of device certificate includes both hardware characteristics and a MAC address. Examiner considers a MAC address as a “software characteristic” of a device.
Morris, Hauck, and Bender are both considered analogous to the claimed invention because they all relate to the same field of verification of mobile device identities using certificates. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Morris and Hauck with the teachings of Bender and realize a method of providing both hardware and software information about a device as information which describes an overall capability of the device. Doing so enables device manufacturers to create manufacturing certificates for devices based on information which does not change over time, allowing devices to verify authenticity of origin while simultaneously enabling a manufacturer to maintain a separate certificate authority for devices, as disclosed in Bender ¶¶0024-27: “throughout the operational life of the device, there may be different owners or users. Therefore, it is difficult to obtain the identity of the device … It can be understood that there are no means to query a device for authenticity of its origins. It may also be desirable for a manufacturer to control an external entity’s level of access or use of certain operations or functions of the device … It has been recognized that in order to address the above problems, a multi-certificate strategy and certificate authority strategy should be established during the manufacturing of the device.” [0024-27]
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Morris further in view of Hauck and Salgaonkar et al. (US 20200021567 A1)(cited by examiner in previous action)(hereafter referred to as Salgaonkar).
Regarding Claim 8,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 12. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), further comprising:
after detecting the storage device (Hauck, ¶0029), establishing a …communication channel with the storage device (Hauck, “the data creation device 102a can detect the archiving device … and establish a communication session” [0029])
The combined teachings of Morris and Hauck do not explicitly disclose the following limitations:
establishing a secure communication channel
However, Salgaonkar discloses the following limitations:
establishing a secure communication channel (“In an example scenario, … the client device 102 access the application 110 to initiate a payment transaction. Accessing the application 110 may redirect the client device 102 to establish a communication/session with the application server 106 for data communication under a secure network communication channel” [0039]) – Examiner considers environment 100 disclosed in Salgaonkar Fig. 1 as analogous to exemplary system 100 disclosed in Morris Fig. 1. As taught in Salgaonkar ¶0039, a client device can establish a secure communication channel with an application server.
Morris, Hauck, and Salgaonkar are both considered analogous to the claimed invention because they all relate to the same field of sending and receiving user application data to a remote storage system through a server. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Morris and Hauck with the teachings of Salgaonkar and realize a method of establishing a secure communication channel with a storage device. Doing so would enable sensitive user information, such as payment card numbers, to be safely communicated to a remote server, reducing the risk of data breach of sensitive user information, as disclosed in Salgaonkar ¶¶0039-40: “the payment transaction application may be configured to display various form fields … to be filled by the user such as a payment card number … and the like which may need extra layer of protection under SSL based transmission … Since there is an extra layer of protection for data communication between the application 110 and the application server 106, the risk of data … breaches reduces tremendously.” [0039-40]
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Morris further in view of Hauck and Smith et al. (US 20150079933 A1)(cited by examiner in previous action)(hereafter referred to as Smith).
Regarding Claim 14,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 14. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above),
Although Morris ¶0012 discloses that any type of application data can be sent by client 108 to trusted data store 102, Morris and Hauck do not explicitly disclose the following limitations:
wherein the first data includes spatial data associated with a physical environment of the electronic device and the storage device
However, Smith discloses the following limitations:
wherein the first data includes spatial data (“LTS location data” [0011]) associated with a physical environment of the electronic device and the storage device (“a trusted execution environment (TEE) arranged to … provide the LTS location data to mobile device applications along with the GPS location” [0011] // ¶0004; 0027) – Examiner considers the environment shown in System 200 of Smith Fig. 2 as analogous to exemplary system 100 disclosed in Morris Fig. 1. As taught in Smith ¶0011, “LTS location data” used by mobile device applications is stored in a trusted execution environment (see also ¶0027). As clarified in ¶0004, LTS location data enables mobile devices to be located within pre-defined coverage areas. Accordingly, examiner considers LTS location data as “spatial data” which is associated with “a physical environment” of both the mobile device and the trusted execution environment.
Morris, Hauck, and Smith are both considered analogous to the claimed invention because they all relate to the same field of sending and receiving mobile device user application data from isolated storage. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Morris and Hauck with the teachings of Smith and realize a method of sending spatial data associated with a physical environment to a storage device for isolated storage. Doing so would enable sensitive user information, such as location information, to be safely communicated to a remote server, improving privacy of sensitive information, as disclosed in Smith ¶¶0010-11: “because LTS services determine locations of mobile devices outside of the mobile device, a privacy issue arises as to whom may be provided this data. The above problems may be addressed by a trusted execution environment (TEE) … by using a TEE, the LTS may be assured of the originating environment from with location requests are made and thus trust the information thus provided to identify the mobile device and assure that location privacy is maintained.” [0010-11]
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Morris further in view of Hauck and Obaidi (US 20200367054 A1)(cited by examiner in previous action)(hereafter referred to as Obaidi).
Regarding Claim 15,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 15. The combined teachings of Morris and Hauck disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), further comprising:
… receiving (Morris, Fig. 6 ,step 604) the information about characteristics of the storage device, sending a request to verify the information about characteristics of the storage device to a second electronic device (Morris, Trust Authority 106, Fig. 1), different from the storage device (Morris, Fig. 1), wherein the one or more or criteria include a criterion that is satisfied when the information about the characteristics of the storage device is verified by the second electronic device (Morris, “In addition to processing messages received from trusted data store 102 and trusted application server 104, client device may receive messages from trust authority 106” [0081] // “Verification may require communication with a trust authority server 106” [0053])
Morris and Hauck do not explicitly disclose the following limitations:
in response to receiving the information about characteristics of the storage device, sending a request to verify the information about characteristics of the storage device to a second electronic device
However, Obaidi discloses the following limitations:
in response to receiving (Fig. 4, step 405) the information about characteristics of the storage device (Provider 120, Fig. 1), sending (Fig. 4, step 415) a request to verify the information about characteristics of the storage device to a second electronic device (Distributed Ledger Node 110, Fig. 1)(“At 415, the UE 130 requests an attestation of the provider 120 from distributed ledger node 110.” [0042] // ¶¶0039-45 // Figs. 1 + 4) – Examiner considers system environment 100 depicted in Obaidi Fig. 1 as analogous to exemplary system 100 depicted in Morris Fig. 1.
Morris, Hauck, and Obaidi are both considered analogous to the claimed invention because they all relate to the same field of verification of mobile device identities using certificates. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Morris and Hauck with the teachings of Obaidi and realize a method of remote attestation of a provider identity using second, separate electronic devices. Doing so improves security of cellular devices in environments including both known and unknown entities by enabling establishment of mutual trust between a provider and cellular device, as disclosed in Obaidi ¶¶0003-04: “To extend cellular coverage over a large geography, cellular providers utilize each other’s network nodes. Since a UE must utilize access points available at a given location whether controlled by a known entity (e.g., a cellular provider to which the UE subscribes) or not (e.g., third-party connection point), the UE must be able to establish trust with both known and unknown/unknowable systems dynamically. Relying on Cas subjects the UE to a significant risk of connecting to a compromised system. Accordingly, there is a need for improved systems and methods of establishing trust between remote devices. … By providing distributed security attestation, over-reliance on the centralized attestation of a CA may be avoided.” [0003-04]
Response to Arguments
The previous 35 U.S.C. 101 rejections of Claims 1-21 are withdrawn in view of the instant claim amendments.
In the final paragraph of the 1st page of remarks (numbered as page 8), applicant requests reconsideration of the claims as amended in view of 35 U.S.C. 101. Upon further consideration of the claims as amended, examiner determines that the outstanding 35 U.S.C. 101 rejections of Claims 1-21 should be withdrawn.
Examiner notes that the independent claims as amended recite the limitations “establishing communication between the storage device and the electronic device; after establishing communication between the storage device and the electronic device, receiving, from the storage device, information about characteristics of the storage device”, which do not recite a judicial exception and are thus considered additional elements of the independent claim. In addition, the claims as amended link the determination and forgoing sending of data steps (Claim 1, lines 14-16) to the aforementioned additional elements of the claim by establishing that lines 14-16 are performed “in response to receiving the information”.
Therefore, the preponderance of evidence of record suggests that the limitations “establishing communication between the storage device and the electronic device; after establishing communication between the storage device and the electronic device, receiving, from the storage device, information about characteristics of the storage device … in response to receiving the information” amount to additional elements which meaningfully limit the claim by integrating the judicial exception into practical application and/or amount to significantly more than the judicial exception (see MPEP 2106.05(e)); as opposed to reciting well-understood, routine, and conventional activity in the field (MPEP 2106.05(d)) and/or insignificant extra-solution activity (MPEP 2106.05(g)). Therefore, the previous 35 U.S.C. 101 rejections of Claims 1-21 are withdrawn.
Applicant’s arguments with respect to the prior art rejections of Claims 1-21 have been considered but are moot in view of the newly-identified Hauck reference because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
With respect to applicant’s arguments located within the 1st paragraph of the 3rd page of remarks (numbered as page 10) continuing through the 4th page of remarks (numbered as page 11), which recites:
“Morris fails to disclose the recitations required by claim 1. The Office Action maps
detecting of a storage device to a contract between a client and a trusted data store as disclosed by Morris. Amended claim 1 further recites establishing communication between the storage device and electronic device, and that the information about characteristics of the storage device is received after the establishing of communication. The rejection set forth in the Office Action, however, is erroneous at least for the reasons described herein.
Morris fails to disclose the limitations that establishing communication between the
claimed electronic device and the claimed storage device, and after that establishing, receiving information about characteristics of the storage device …
The Office Action erroneously relies upon Morris when mapping to recitations of
"detecting the storage device" in claim 1 … Therefore, Morris fails to disclose "detecting the storage device" as recited in amended claim 1.”
Examiner has fully considered the aforementioned argument but finds it moot in view of the newly-identified Hauck reference.
With respect to applicant’s argument located within the 2nd paragraph of the 4th page of remarks (numbered as page 11), which recites:
“The Office Action maps disclosure of credentials by Morris to the "information about characteristics of the storage device" as recited in claim 1. Such a mapping, however, is erroneous. The information recited in claim 1 corresponds to information about the claimed storage device, which is not disclosed by Morris. Morris instead discloses credentials which are authentication information for a client device - mapped to the claimed electronic device - or for an application server, and Morris does not disclose credentials which are authentication information for a data store - mapped to the storage device recited in claim 1. Indeed, Morris discloses, "As used herein, the term "credential" refers to authentication information enabling the verification of the identity of the owner or provider of the credentials. For example, a credential can be a signature or certificate that may originate from a client device or application server and be validated by the receiving client device, application server, or a third-party trust authority" (see Morris at [0011], emphasis added). Notably, Morris does not disclose that a credential corresponds to the identify of a data store. The terms "owner" and "provider" of credentials are only described in two instances: "application server owners" at paragraph [0003] and "application service provider 104" at paragraph [0069] respectively. Both terms, however, refer to an application server, and never to a data store. Thus, the Examiner's assertion that credentials as described in the context of FIG. 6 correspond to credentials of a data store is unfounded. Therefore, Morris fails to disclose recitations of "information about characteristics of the storage device" as recited in claim 1.”
Examiner has fully considered the aforementioned argument but does not find it to be persuasive. Applicant appears to argue that examiner’s mapping of credentials received by a client device (see Morris, Fig. 6) to the claimed concept of “information about characteristics of the storage device” is erroneous at least because Morris does not disclose credentials which identify a data store; and instead merely discloses credentials which can identify a client device or an application server (as evidenced by Morris ¶¶0011; 0003; and 0069). Examiner respectfully disagrees with applicant’s characterization of the teachings of Morris, particularly that Morris does not disclose credentials of a data store.
As taught in Morris ¶0011, a credential received by a client device “enables the verification of the identity of the owner or provider of the credentials” (Emphasis added). While the credential received by the client “may originate from a client device or application server” (Morris ¶0011; Emphasis added); Morris ¶0011 does not limit the concept of a credential as solely being provided from a client device or an application server. As shown in Morris Fig. 6 and detailed in ¶¶0071-74, a client device receives messages (Fig. 6, step 606) both from application server 104 (¶¶0071, 0074) and from trusted data store 102 (¶¶0071, 0073; i.e., from the claimed “storage device”). The client device tests each received message in order to verify the source of the received message (Fig. 6, steps 606 and 608). A ‘Yes’ determination in step 606 corresponds to a message received from trusted data store 102 (¶0073; i.e., a data store credential); whereas a ‘Yes’ determination in step 608 corresponds to a message received from application server 104 (¶0074; i.e., an application server credential). Applying the teachings of Morris ¶0011 to Morris Fig. 6, as would be understood by one of ordinary skill in the art, trusted data store 102 is the provider of a received message causing a ’Yes’ determination during step 606 (i.e., the trusted data store provides the message to the client). Therefore, examiner considers a message received by a client device which causes a ‘Yes’ determination during step 606 as reading on the claimed concept of “information about characteristics of the storage device” under the Broadest Reasonable Interpretation (BRI) of the claimed language. Nothing the claims as currently presented precludes such an interpretation of Claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Fasoli et al. (US 20180069871 A1) – Discloses a user device which validates both ‘validation content’ and fingerprint information from a remote server prior to sending secure data to the remote server (see Fig. 1; ¶0027)
Lashkari et al. (US 20130238711 A1) – Discloses a discovery process whereby an electronic device detects and then establishes communication with a storage device (see Fig. 5)
Vaishampayan et al. (US 20200382616 A1) – Discloses a method whereby first and second electronic devices advertise services and request connections when in proximity (see Figs. 7A/B)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rocío del Mar Pérez-Vélez can be reached on 571-270-5935. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.S.M./Examiner, Art Unit 2133
/RYAN F PITARO/Supervisory Patent Examiner, Art Unit 2188