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 .
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 09/12/2025 has been entered.
Response to Arguments
Applicant arguments filed 09/12/2025, with respect to objections to the claims have been fully considered, and those respective objections have been withdrawn. However, additional claim objections and 112(b) rejections arise in view of the amendments.
Applicant’s arguments filed 09/12/2025, with respect to the rejections of claims 1-20 under 35 USC 101 have been fully considered, but they are not persuasive. Examiner respectfully submits that, as amended, the claims do not appear to provide an improvement to the technology or integrate the judicial exception into a practical application. The argument on P. 9 of Applicant Arguments points to the amended limitation “selectively transmit the original value or one representation value based on an access type” to emphasize an integration of the judicial exception into a practical application. However, the amended limitation does not add patentable weight with regard to subject matter eligibility because the claim does not associate the original value with an access type. The recited limitations introducing the claimed access types read: “receiving, from a second device, data including an original value generated by the second device; obtaining a plurality of representation values corresponding to the original value, wherein the plurality of representation values includes a same type of information as the original value, wherein each of the plurality of representation values is distinctly associated with one of a plurality of access types”. The transmitting step later in the claim adds: “selectively transmitting, based on one of the access types the original value or one representation value, wherein the one representation value to be transmitted is determined based on the access type of a device requesting retrieval of data”. Therefore, in view of the amendments, only the representation values are determined to be transmitted based on their distinctly associated access types. It is unclear how the original value would be determined to be transmitted to a requesting device based on an access type of the device, except in the absence of an access type for the device. Thus, the claims, as amended, could substantially amount to: receiving an original value, obtaining representation values of the original value, storing the values in a resource, and transmitting the original value. It is respectfully submitted that this combination of limitations may still be reasonably interpreted as being performable in the human mind except for the aid of generic computing components.
In addition, regarding Applicant’s argument also on P. 9 of Applicant Arguments that the additional elements are linked to a particular technological environment, MPEP 2106.05(h) states “limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application”. Therefore, in view of the explanation above and the MPEP, the additional elements of the claim do not amount to significantly more than the judicial exception.
Applicant’s arguments filed 09/12/2025, with respect to the rejections of independent claims 1 and 11 and their corresponding dependent claims under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new grounds of rejection are made in view of previously applied references from Ninglekhu and Samuel, in addition to a newly applied reference from Nakhjiri et al. (US 20150186635 A1), hereinafter Nakhjiri. Specifically, Nakhjiri teaches the newly added limitations “wherein each of the plurality of representation values is distinctly associated with one of a plurality of access types” and “wherein the one representation value to be transmitted is determined based on an access type of a device requesting retrieval of data”.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
In line 11-12 of Claim 1, the limitation “selectively transmitting, based on one of the access types, the original value or one representation value” is unclear. There is no access type associated with the original value, so it is unclear in which case the original value would be selectively transmitted. Therefore, the scope of the claim is unclear. For examination purposes, the claim limitation will be interpreted to indicate that the original value will be selectively transmitted when there is no access type for the device requesting retrieval. For example, the limitation could read: “selectively transmitting the original value or transmitting one representation value based on one of the access types, wherein the one representation value to be transmitted is determined based on the access type of a device requesting retrieval of data”. Alternatively, the claim language could be clarified to additionally associate the original value with an access type. The above interpretations/suggestions represent Examiner’s suggestion for compliance with 35 USC 112(b).
In line 13 of Claim 1, the limitation “an access type of a device requesting retrieval of data” is unclear because it is not expressly clear whether “an access type” is to be interpreted as one of the “plurality of access types” or “one of the access types” established in line 8 and 11 of the claim, respectively, or as some other access type. Therefore, the scope of the claim is unclear. For examination purposes the claim limitation will be interpreted as “the access type of a device requesting retrieval of data” to clarify that the access type of the requesting device is one of the access types with which the representation values are associated. This interpretation also represents Examiner’s suggestion for compliance with 35 USC 112(b).
In line 13-14 of Claim 1, the limitation “a device requesting retrieval of data” is unclear because it is not expressly clear whether the data to be retrieved is intended to represent the same “data” as that established in line 3 of the claim, or some different data. Therefore, the scope of the claim is unclear. For examination purposes the claim limitation will be interpreted as “a device requesting retrieval of the data” to clarify that the requested data is the same as that which is generated by the second device and stored in the resource. This interpretation also represents Examiner’s suggestion for compliance with 35 USC 112(b).
Claim 11 is a device claim with limitations corresponding to those of method Claim 1, and is therefore rejected under 35 USC 112(b) for the same reasons as Claim 1 listed above
In line 2 of Claim 5, the limitation “a retrieval request for data stored in the resource from a third device” is unclear because it is not expressly clear whether the “retrieval request for data … from a third” is intended to represent the same request and device as those reflected in the Claim 1 limitation “a device requesting retrieval of data” or some other request/device. It is additionally unclear whether the “data stored in the resource” is intended to represent the same “data generated by the second device” as that established in Claim 1 or some other data. Therefore, the scope of the claim is unclear. For examination purposes the claim limitation will be interpreted as “in response to the device requesting retrieval of the data, confirming that the device … (etc.)” to clarify that the request, device, and data are the same as those presented in Claim 1. This interpretation also represents Examiner’s suggestion for compliance with 35 USC 112(b).
Claim 15 is a device claim with limitations corresponding to those of method Claim 5, and is therefore rejected under 35 USC 112(b) for the same reasons as Claim 5 listed above
Claim 7 is unclear in a similar manner to Claim 5 in the similar limitation “a retrieval request for data stored in the resource from a fourth device” for the same reasons as those highlighted in the rejection of Claim 5
Claim 17 is a device claim with limitations corresponding to those of method Claim 7, and is therefore rejected under 35 USC 112(b) for the same reasons as Claim 7
In line 2 of Claim 6, the limitation “based on the access type of the … device” is unclear because it is not expressly clear whether the “access type” is intended to represent the same “access type of (the) device requesting retrieval of data” as recited in Claim 1, or some other access type. It is additionally unclear whether the third device is to be interpreted as the same “a device requesting retrieval of data”, or some other device. Therefore, the scope of the claim is unclear. For examination purposes the claim limitation will be interpreted as “based on the access type of the device requesting retrieval of the data” to clarify that the request, device, and data are the same as those presented in Claim 1. This interpretation also represents Examiner’s suggestion for compliance with 35 USC 112(b).
Claim 16 is a device claim with limitations corresponding to those of method Claim 6, and is therefore rejected under 35 USC 112(b) for the same reasons as Claim 6 listed above
Claim 8 is unclear in a similar manner to Claim 6 in the similar limitation “based on the access type of the fourth device” for the same reasons as those highlighted in the rejection of Claim 6
Claim 18 is a device claim with limitations corresponding to those of method Claim 8, and is therefore rejected under 35 USC 112(b) for the same reasons as Claim 8
Claims 2-10 and 12-20 are also rejected due to their respective dependence on Claims 1 and 11
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 USC 101 because the claimed invention is directed to abstract ideas without significantly more.
Claim 1 is directed to an operating method of a device in a machine-to-machine system including steps of receiving, obtaining, storing, and transmitting various information. The recited method is a process which falls within one of the statutory categories.
Claim 1 recites judicial exceptions in the receiving, obtaining, storing, and transmitting steps of the method. These processes, under broadest reasonable interpretation, cover performance of the limitations in the mind except for the recitation of generic computer components. That is, the recited limitations “receiving, from a second device, data including an original value generated by the second device” and “selectively transmitting, based on one of the access types, the original value …” are merely data communicating recited at a high level of generality, and thus are insignificant extra-solution activity. The recited steps of “obtaining a plurality of representation values corresponding to the original value …” and “storing the original value and the plurality of representation values in a resource …” merely describe how to generally apply the concept of obtaining/gathering and storing an original data value and representations of the corresponding data value in a computer environment. Therefore, the claim, as a whole, represents an abstract idea as it only covers performance of the data gathering and storing processes except for the recitation of generic computer components.
These judicial exceptions are not integrated into a practical application. Additional elements of the claim include the aforementioned first device, M2M system, a second device, a resource, and a device. All of the hardware elements are recited at a high level of generality. Therefore, these additional elements do not serve to integrate the abstract ideas into a practical application because they do not serve to impose any meaningful limits on practicing the abstract ideas.
The claim does not incorporate the additional elements in a manner that is sufficient to amount to significantly more than the judicial exceptions. The additional elements, as stated above, are recited at a high level of generality—the claim language does not meaningfully connect the abstract receiving and obtaining steps to the operation of the first device as a whole, nor to the storing step of the received and obtained values in a resource for storing the data, nor the transmitting step of the original value. Therefore, nothing in the claim adds significantly more than the abstract ideas, and the claim is ineligible.
A similar rejection applies to corresponding device claim 11, which includes further additional elements of a transceiver and a processor. However, these elements are also recited at a high level of generality and do not serve to integrate the abstract ideas into a practical application.
Claims 2-10 and 12-20 are also rejected due to their respective dependence on claims 1 and 11.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ninglekhu et al. (US 20210256159 A1), hereinafter Ninglekhu, in view of Samuel et al. (US 20170177798 A1) and Nakhjiri et al. (US 20150186635 A1), hereinafter Nakhjiri.
Regarding Claim 1:
Ninglekhu teaches a method for operating a first device in a machine-to-machine (M2M) system, the method comprising (Ninglekhu – Paragraph [0034]: From a deployment perspective, an M2M/IoT SL can be deployed on various types of network nodes including servers, gateways and devices, as shown in FIG. 1.; and Figure 1): receiving … data including an original value … (Ninglekhu – Paragraph [0144]: At step 3, a user creates their user profile in the IoT service layer via a Subscriber Management Portal (SMP). The Subscriber Management Portal may be accessed using RESTful protocols. The items that are configured during the user profile creation and are provided in the message are listed in Table 2; and Table 2: various original data elements submitted by user device during user profile creation); obtaining a plurality of representation values corresponding to the original value (Ninglekhu – Paragraph [0144]: At step 3, a user creates their user profile in the IoT service layer via a Subscriber Management Portal (SMP). The Subscriber Management Portal may be accessed using RESTful protocols. The items that are configured during the user profile creation … are listed in Table 2; Table 2: Alias - A user profile may have one or more alias(s) associated with it. An alias may be used when anonymizing the data. For example, a user name alias may be used by the DAS to replace identifying information. Aliasing may be performed on fields other than the user name. For example, aliasing maybe performed on the user's home address; and Paragraph [0182]: User data can be anonymized using a combination of one or more anonymization techniques. Example techniques used to anonymize user data may include one or more of the following; and Paragraphs [0183]-[0189]: Various techniques for anonymizing data including hiding/masking, abbreviation, substitution, shuffling, encryption), wherein the plurality of representation values include a same type of information as the original value (Ninglekhu – Table 2: Alias - A user profile may have one or more alias(s) associated with it. An alias may be used when anonymizing the data. For example, a user name alias may be used by the DAS to replace identifying information. Aliasing may be performed on fields other than the user name. For example, aliasing maybe performed on the user's home address; and Paragraph [0340]: An example of aliasing is reassigning names to entities (e.g., user Bob is changed to User-A, device door-lock is changed to device-1)); and a resource … for … the data (Ninglekhu – Paragraph [0225]: When a user profile is created, the result may be the creation of a resource. The resource may have a <userPrivacyProfile> child resource. The name of the resource may be set to the Subscriber-ID and the attributes that are associated with the resource may be the same fields that are listed in Table 2; and Table 2: original data values and representation values (aliases) configured during user profile creation); and selectively transmitting, based on one of the access types, the original value or one representation value (Ninglekhu – Figure 22: flow chart illustrating the provision of anonymized data to a requesting device; and Paragraph [0268]: At step 8, the CSE sends the anonymized version of user data to its requesting AE via a RESTful communication. Note that the reply may include an indication that the data has been anonymized; and Tables 2 and 3: Table 2 lists the fields included in the User Profile resource, and Table 3 highlights the Privacy Protection Rules of the user profile, which include categories of requesting users and the accesses they are allowed; and Paragraph [0119]: Methods and systems are disclosed for how the service layer can be configured with polices to determine when to limit access to parts of data sets, modified data sets, and/or sanitized data sets. In doing so, the Service Layer may allow users/subscribers with options to select parts of data not to be shared, share user data completely or, completely preserve (protect) user data from being shared with the third party data consumers), wherein the one representation value to be transmitted is determined based on an access type (Ningleku – Tables 2 and 3: Table 2 lists the fields included in the User Profile resource, and Table 3 highlights the Privacy Protection Rules (policies) of the user profile, which include categories of requesting users and the accesses they are allowed; and Paragraph [0180]: The policies may indicate if the data should be aliased, sanitized, masked, etc., as described in more detail below. Furthermore, the policy may indicate that the data should only be anonymized, or anonymized differently, if certain conditions are met).
Ninglekhu does not expressly teach receiving, from a second device, data … generated by the second device; storing the original value and the plurality of representation values in a resource, wherein the resource is used for storing the data generated by the second device.
However, Samuel teaches receiving, from a second device, data … generated by the second device (Samuel – Paragraph [0033]: At step 402, the process begins with client device 110 collecting constituent, patient, or user 102 health-oriented data. Constituent health oriented data is securely collected locally to the user through IoT sensors 110-2, sensors on IoT devices 110-1, or sensors on user device 110-3 based on a constituent or user profile; and Paragraph [0034]: At step 404, the client device 110 associates the collected data with the profile of user 102 and securely transmits the collected data to the IoT server 112); and storing the original value and the [plurality of] representation value[s] in a resource, wherein the resource is used for storing the data generated by the second device (Samuel – Figure 5: flow diagram of collection and storage of user data; and Paragraph [0048]: At step 510, the storage services 116 stores the pseudonym with the member-identifiable data in the database 124 as user data 122. Alongside the pseudonym and member-identifiable data, the storage services 116 also stores the map function created at step 508 as user data 122).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ninglekhu, further incorporating Samuel to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Samuel’s teaching to receive data generated by a device and store the data along with accompanying pseudonymizing data in a resource into Ninglekhu’s method for operating a device to protect data in a M2M system. This combined functionality would enhance Ninglekhu’s method by establishing a more efficiently structured system for receiving, storing, and protecting data.
The combination of Ninglekhu and Samuel does not expressly teach wherein each of the plurality of representation values is distinctly associated with one of a plurality of access types; and the one representation value to be transmitted is determined based on an access type of a device requesting retrieval of data.
However, Nakhjiri teaches wherein each of the plurality of representation [values] is distinctly associated with one of a plurality of access types (Nakhjiri – Paragraph [0040]: In many cases, some or all data within a resource 202 can be sensitive, private, critical, and/or be subject to secrecy requirements. Data of different sensitivity levels can sometimes be included within a single resource 202, such as data that is considered unrestricted, low sensitivity, normal sensitivity, or high sensitivity; and Paragraph [0041]: In addition, different clients 102 or users of clients 102 can have different levels of authority. By way of a non-limiting example, a doctor in a hospital can have more authority than a nurse. In some situations, clients 102 having higher authorization levels can be granted access to data that is more sensitive than clients 102 with lower authorization levels. In these cases, access to data within a resource 202 that is tagged with a particular sensitivity level can be granted to only those clients 102 that have been authorized to view, edit, or subscribe to the data of that sensitivity level. Because various data within a single resource 202 can have different sensitivity levels, clients 102 of different authorization levels can have authority to view different portions of the same resource 202; and Paragraph [0047]: In some embodiments, the number of authorization levels 404 can be equal to the number of redaction levels 402, as shown in FIG. 4A. In alternate embodiments, the number of authorization levels 404 can be different than the number of redaction levels 402, with each individual authorization level 404 corresponding to a particular range of redaction levels 402, or indicating a maximum allowed redaction level 402. By way of a non-limiting example, FIG. 4B depicts an embodiment in which the redaction levels 402 can range from 0 to 5, while the authorization levels can be 1 (low authority), 2 (medium authority), or 3 (high authority)); and the one representation [value] to be transmitted is determined based on an access type of a device requesting retrieval of data (Nakhjiri – Paragraph [0052]: When a client 102 sends a request 208 for a resource 202, the server 104 can provide the client 102 with the representation 204 of the resource 202 that contains only the data within the resource 202 that has a redaction level 402 that is equal to or lower than the redaction level 402 the client 102 is authorized to access, as indicated by the client's authorization level 404; and Paragraph [0003]: In many networked systems, such as those that have a Representational State Transfer (REST) architectural style, client devices can send requests to servers for data stored as abstract resources on the servers).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ninglekhu and Samuel, further incorporating Nakhjiri to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Nakhjiri’s teaching to provide varying levels of resource/data access to requesting devices based on access permissions/types of the devices into Ninglekhu and Samuel’s method for operating a device to protect data in a M2M system. This addition enhances the method by providing more convenience of data access without sacrificing the security of sensitive data within the system.
Regarding Claim 2:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the method of claim 1.
Ninglekhu further teaches further comprising generating the resource (Ninglekhu – Paragraph [0225]: When a user profile is created, the result may be the creation of a resource), wherein the resource includes at least one of first information on generation [and storage] of the plurality of representation values (Ninglekhu – Paragraph [0340]: Examples of data anonymization and sanitization techniques include but are not limited to shuffling, filtering, masking, and aliasing … An example of aliasing is reassigning names to entities (e.g., user Bob is changed to User-A, device door-lock is changed to device-1); Table 2: Alias - A user profile may have one or more alias(s) associated with it. An alias may be used when anonymizing the data. For example, a user name alias may be used by the DAS to replace identifying information. Aliasing may be performed on fields other than the user name. For example, aliasing maybe performed on the user's home address) and second information on provision of the plurality of representation values (Ninglekhu – Paragraph [0225]: When a user profile is created, the result may be the creation of a resource. The resource may have a <userPrivacyProfile> child resource; and Table 11: Attributes of <userPrivacyProfile> resource detailing values to protect, how to protect them, and what entities to allow/limit access to them).
Samuel further teaches wherein the resource includes … first information on … storage of the [plurality of] representation value[s] (Samuel – Paragraph [0048]: At step 510, the storage services 116 stores the pseudonym with the member-identifiable data in the database 124 as user data 122. Alongside the pseudonym and member-identifiable data, the storage services 116 also stores the map function created at step 508 as user data 122).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 3:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the method of claim 2.
Ninglekhu further teaches wherein the resource is generated during a registration procedure [for the second device] (Ninglekhu – Paragraph [0134]: A user profile, such as the one shown in Table 2, may be created when a user registers herself to an IoT service layer platform via IoT Service Layer's subscriber management portal; and Paragraph [0225]: When a user profile is created, the result may be the creation of a resource).
Samuel further teaches the second device (Samuel – Paragraph [0063]: a registered member 102 may request access to data from his/her client device 110 through, for example, a web portal … Once a request is received, the IoT server 112 will first verify credentials to make sure the requestor is authenticated to access entire data including member-identifiable data. The IoT server 112 will then perform the de-pseudonymization step 602 to then re-identify member data (both member-identifiable and medical data) at steps 604 and 606, and then disseminate the contents of the data to the requestor at step 608).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 4:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the method of claim 2.
Ninglekhu further teaches wherein the second information is information for identifying a data request (Ninglekhu – Table 11: Attributes of <userPrivacyProfile> resource detailing values to protect, how to protect them, and what entities to allow/limit access to them; Examiner’s Comment: Specification paragraph [0080] defines information for identifying a data request as “a device, a device type, an access type”. Allowed Third Parties, Restricted Third Parties, and Disallowed Third Parties are interpreted as access types), which is configured to be responded with the plurality of representation values (Ninglekhu – Paragraph [0262]: At step 2, as the oneM2M system identifies the request from an AE, the CSE asks for data anonymization policies applicable to the request received from the AE; and Paragraph [0266]: At step 6, the DAS acts as a PEP/PDP in the oneM2M system. Anonymization policies are applied over the raw user data. Thus, an anonymized/privatized version of user data is produced; and Paragraph [0268]: At step 8, the CSE sends the anonymized version of user data to its requesting AE via a RESTful communication. Note that the reply may include an indication that the data has been anonymized. Furthermore, the reply may indicate what anonymization techniques were applied to the data), and indicates the access types (Ninglekhu – Table 11: Attributes of <userPrivacyProfile> resource detailing values to protect, how to protect them, and what entities to allow/limit access to them; Examiner’s Comment: Specification paragraph [0080] defines information for identifying a data request as “a device, a device type, an access type”. Allowed Third Parties, Restricted Third Parties, and Disallowed Third Parties are interpreted as access types).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 5:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the method of claim 1.
Ninglekhu further teaches further comprising: receiving a retrieval request for data [stored in the resource] from a third device (Ninglekhu – Figure 22: data anonymization procedure in a oneM2M/IoT system; and Paragraph [0261]: At step 1, an AE that represents an ASP may send a RESTful read request to a oneM2M system via an Mca interface. As the request is received by the oneM2M system, the request for user data is identified); confirming that the third device has no right to read the original value (Ninglekhu – Paragraph [0262]: At step 2, as the oneM2M system identifies the request from an AE, the CSE asks for data anonymization policies applicable to the request received from the AE; and Paragraph [0266]: At step 6, the DAS acts as a PEP/PDP in the oneM2M system. Anonymization policies are applied over the raw user data. Thus, an anonymized/privatized version of user data is produced. Paragraph [0273]: The user profile may include a <userPrivacyProfile> sub-resource. The <userPrivacyProfile> sub-resource may a list of what third parties (IN-AE's) are permitted to access data that is associated with the user. Furthermore, the <userPrivacyProfile> sub-resource may further describe how requests from each third party (IN-AE) should be treated. For example, it may specify that one IN-AE is an Allowed Third Party and can see all data and that another IN-AE is a Restricted Third Party. The policy may further describe how to restrict data access (e.g., whether the IN-AE can only see certain types of data or should not be allowed to see certain types of data).); and transmitting, in response to the retrieval request (Ninglekhu – Paragraph [0261]: At step 1, an AE that represents an ASP may send a RESTful read request to a oneM2M system via an Mca interface. As the request is received by the oneM2M system, the request for user data is identified), the one representation value of the plurality of representation values to the third device (Ninglekhu – Paragraph [0268]: At step 8, the CSE sends the anonymized version of user data to its requesting AE via a RESTful communication. Note that the reply may include an indication that the data has been anonymized. Furthermore, the reply may indicate what anonymization techniques were applied to the data).
Samuel further teaches data stored in the resource (Samuel – Paragraph [0048]: At step 510, the storage services 116 stores the pseudonym with the member-identifiable data in the database 124 as user data 122. Alongside the pseudonym and member-identifiable data, the storage services 116 also stores the map function created at step 508 as user data 122).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 6:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the method of claim 5.
Ninglekhu further teaches wherein the confirming that the third device has no right to read the original value (Ninglekhu – Paragraph [0262]: At step 2, as the oneM2M system identifies the request from an AE, the CSE asks for data anonymization policies applicable to the request received from the AE; and Paragraph [0266]: At step 6, the DAS acts as a PEP/PDP in the oneM2M system. Anonymization policies are applied over the raw user data. Thus, an anonymized/privatized version of user data is produced) comprises confirming, based on the access type of the third device (Ninglekhu – Table 11: user-specified privacy preferences including lists of third parties that are allowed, restricted, or disallowed from accessing user data. Paragraph [0273]: The user profile may include a <userPrivacyProfile> sub-resource. The <userPrivacyProfile> sub-resource may a list of what third parties (IN-AE's) are permitted to access data that is associated with the user. Furthermore, the <userPrivacyProfile> sub-resource may further describe how requests from each third party (IN-AE) should be treated. For example, it may specify that one IN-AE is an Allowed Third Party and can see all data and that another IN-AE is a Restricted Third Party. The policy may further describe how to restrict data access (e.g., whether the IN-AE can only see certain types of data or should not be allowed to see certain types of data).), that the third device is a device irrelevant to an owner of the second device (Ninglekhu – Table 11: Disallowed Third Parties - Description: Third Parties (other entities) that are not allowed to consume data related to this user; Examiner’s Comment: Examiner respectfully submits that this category would include devices irrelevant to the user who established the privacy profile (owner of the second device)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 7:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the method of claim 1.
Ninglekhu further teaches further comprising: receiving a retrieval request for data [stored in the resource] from a fourth device (Ninglekhu – Paragraph [0275]: One of the third party IN-AE's may be a health monitoring application that allows the owner of the smart watch to view his activity summary. This IN-AE may request to read the data as shown in FIG. 16, where the IN-AE is the ASP) confirming that the fourth device has right to read the original value (Ninglekhu – Paragraph [0275]: In step 2, when the IN-CSE invokes the Privacy Policy Service, the policies in the <userPrivacyProfile> may be provided to the Privacy Policy Service and used to determine that the health monitoring system is permitted to see all of the owner's data); and transmitting, in response to the retrieval request, the original value to the fourth device (Ninglekhu – Paragraph [0275]: In step 7, the Data Anonymization service may provide the IN-CSE with a data set that represents all of the user's activity. This data is then provided to the IN-AE).
Samuel further teaches data stored in the resource (Samuel – Paragraph [0048]: At step 510, the storage services 116 stores the pseudonym with the member-identifiable data in the database 124 as user data 122. Alongside the pseudonym and member-identifiable data, the storage services 116 also stores the map function created at step 508 as user data 122).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 8:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the method of claim 7.
Ninglekhu further teaches wherein the confirming that the fourth device has right to read the original value (Ninglekhu – Paragraph [0275]: In step 2, when the IN-CSE invokes the Privacy Policy Service, the policies in the <userPrivacyProfile> may be provided to the Privacy Policy Service and used to determine that the health monitoring system is permitted to see all of the owner's data) comprises confirming, based on the access type of the fourth device (Ninglekhu – Table 11: user-specified privacy preferences including lists of third parties that are allowed, restricted, or disallowed from accessing user data) that the fourth device is a device related to an owner of the second device (Ninglekhu – Table 11: Allowed Third Parties - Description: Third Parties (other entities) that are allowed to consume data related to this user; Examiner’s Comment: Examiner respectfully submits that this category would include devices related to the user who established the privacy profile (owner of the second device)).
Regarding Claim 9:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the method of claim 1.
Ninglekhu further teaches wherein the resource includes a sub-resource for storing the original value (Ninglekhu – Paragraph [0273]: The user profile may include a <userPrivacyProfile> sub-resource; and Table 11: Elements of userPrivacyProfile sub-resource including Name/Street Address/Associated identifiers all interpretable as original value), and wherein the sub-resource includes an attribute for storing the original value (Ninglekhu – Table 11: Elements of userPrivacyProfile sub-resource including Name/Street Address/Associated identifiers all interpretable as original value) and an attribute for storing the plurality of representation values (Ninglekhu – Table 11: Elements Name/Street Address/Associated identifiers also include policies on how to protect (representation value(s)) the data (original value(s)); and Paragraph [0340]: Examples of data anonymization and sanitization techniques include but are not limited to shuffling, filtering, masking, and aliasing. An example of filtering is removing data. An example of masking is removing part of a data set (e.g., 6789 3rd Ave. is masked to XXXX 3rd Ave.). An example of aliasing is reassigning names to entities (e.g., user Bob is changed to User-A, device door-lock is changed to device-1)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 10:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the method of claim 1.
Ninglekhu further teaches wherein the resource includes a sub-resource for storing the original value (Ninglekhu – Table 2: Name/Associated Identifiers - authorized users of the subscription and their associated identifiers (original value(s)); Examiner’s Comment: Examiner respectfully submits that a field of a user profile resource may be considered a sub-resource of the user profile resource) and a sub-resource for storing the plurality of representation values (Ninglekhu – Table 2: Alias - A user profile may have one or more alias(s) associated with it. An alias may be used when anonymizing the data. For example, a user name alias may be used by the DAS to replace identifying information. Aliasing may be performed on field; Examiner’s Comment: Examiner respectfully submits that a field of a user profile resource may be considered a sub-resource of the user profile resource).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 11:
Ninglekhu teaches a first device in a machine-to-machine (M2M) system (Ninglekhu – Paragraph [0034]: From a deployment perspective, an M2M/IoT SL can be deployed on various types of network nodes including servers, gateways and devices, as shown in FIG. 1.; and Figure 1), comprising: a transceiver (Ninglekhu – Paragraph [0310]: FIG. 25C is a block diagram of an example hardware/software architecture of an apparatus of a network, such as one of the entities illustrated in FIGS. 1-24, which may operate as an M2M server, gateway, device, or other network apparatus in an M2M network such as that illustrated in FIGS. 25A and 25B … The network apparatus 30 may also include communication circuitry, such as a transceiver 34 and a transmit/receive element 36); and a processor coupled with the transceiver (Ninglekhu – Paragraph [0312]: As shown in FIG. 25C, the processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit/receive element 36)), wherein the processor is configured to (Ninglekhu – Paragraph [0311]: the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the network apparatus in order to perform the various required functions of the network apparatus): receive … data including an original value (Ninglekhu – Paragraph [0144]: At step 3, a user creates their user profile in the IoT service layer via a Subscriber Management Portal (SMP). The Subscriber Management Portal may be accessed using RESTful protocols. The items that are configured during the user profile creation and are provided in the message are listed in Table 2; and Table 2: various original data elements submitted by user device during user profile creation); obtain a plurality of representation values corresponding to the original value (Ninglekhu – Paragraph [0144]: At step 3, a user creates their user profile in the IoT service layer via a Subscriber Management Portal (SMP). The Subscriber Management Portal may be accessed using RESTful protocols. The items that are configured during the user profile creation … are listed in Table 2; Table 2: Alias - A user profile may have one or more alias(s) associated with it. An alias may be used when anonymizing the data. For example, a user name alias may be used by the DAS to replace identifying information. Aliasing may be performed on fields other than the user name. For example, aliasing maybe performed on the user's home address; and Paragraph [0182]: User data can be anonymized using a combination of one or more anonymization techniques. Example techniques used to anonymize user data may include one or more of the following; and Paragraphs [0183]-[0189]: Various techniques for anonymizing data including hiding/masking, abbreviation, substitution, shuffling, encryption) wherein the plurality of representation values includes a same type of information as the original value (Ninglekhu – Table 2: Alias - A user profile may have one or more alias(s) associated with it. An alias may be used when anonymizing the data. For example, a user name alias may be used by the DAS to replace identifying information. Aliasing may be performed on fields other than the user name. For example, aliasing maybe performed on the user's home address; and Paragraph [0340]: An example of aliasing is reassigning names to entities (e.g., user Bob is changed to User-A, device door-lock is changed to device-1)); and a resource … for … the data (Ninglekhu – Paragraph [0225]: When a user profile is created, the result may be the creation of a resource. The resource may have a <userPrivacyProfile> child resource. The name of the resource may be set to the Subscriber-ID and the attributes that are associated with the resource may be the same fields that are listed in Table 2; and Table 2: original data values and representation values (aliases) configured during user profile creation), and selectively transmit, based on one of the access types, the original value or one representation value (Ninglekhu – Figure 22: flow chart illustrating the provision of anonymized data to a requesting device; and Paragraph [0268]: At step 8, the CSE sends the anonymized version of user data to its requesting AE via a RESTful communication. Note that the reply may include an indication that the data has been anonymized; and Tables 2 and 3: Table 2 lists the fields included in the User Profile resource, and Table 3 highlights the Privacy Protection Rules of the user profile, which include categories of requesting users and the accesses they are allowed; and Paragraph [0119]: Methods and systems are disclosed for how the service layer can be configured with polices to determine when to limit access to parts of data sets, modified data sets, and/or sanitized data sets. In doing so, the Service Layer may allow users/subscribers with options to select parts of data not to be shared, share user data completely or, completely preserve (protect) user data from being shared with the third party data consumers), wherein the one representation value to be transmitted is determined based on an access type (Ningleku – Tables 2 and 3: Table 2 lists the fields included in the User Profile resource, and Table 3 highlights the Privacy Protection Rules (policies) of the user profile, which include categories of requesting users and the accesses they are allowed; and Paragraph [0180]: The policies may indicate if the data should be aliased, sanitized, masked, etc., as described in more detail below. Furthermore, the policy may indicate that the data should only be anonymized, or anonymized differently, if certain conditions are met).
Ninglekhu does not expressly teach receive, from a second device, data … generated by the second device; and store the original value and the plurality of representation values in a resource, wherein the resource is used for storing the data generated by the second device.
However, Samuel teaches receive, from a second device, data … generated by the second device (Samuel – Paragraph [0033]: At step 402, the process begins with client device 110 collecting constituent, patient, or user 102 health-oriented data. Constituent health oriented data is securely collected locally to the user through IoT sensors 110-2, sensors on IoT devices 110-1, or sensors on user device 110-3 based on a constituent or user profile; and Paragraph [0034]: At step 404, the client device 110 associates the collected data with the profile of user 102 and securely transmits the collected data to the IoT server 112); and store the original value and the [plurality of] representation value[s] in a resource, wherein the resource is used for storing the data generated by the second device (Samuel – Figure 5: flow diagram of collection and storage of user data; and Paragraph [0048]: At step 510, the storage services 116 stores the pseudonym with the member-identifiable data in the database 124 as user data 122. Alongside the pseudonym and member-identifiable data, the storage services 116 also stores the map function created at step 508 as user data 122).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ninglekhu, further incorporating Samuel to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Samuel’s teaching to receive data generated by a device and store the data along with accompanying pseudonymizing data in a resource into Ninglekhu’s device for protecting data in a M2M system. This combined functionality would enhance Ninglekhu’s device by establishing a more efficiently structured system for receiving, storing, and protecting data.
The combination of Ninglekhu and Samuel does not expressly teach wherein each of the plurality of representation values is distinctly associated with one of a plurality of access types; and the one representation value to be transmitted is determined based on an access type of a device requesting retrieval of data.
However, Nakhjiri teaches wherein each of the plurality of representation [values] is distinctly associated with one of a plurality of access types (Nakhjiri – Paragraph [0040]: In many cases, some or all data within a resource 202 can be sensitive, private, critical, and/or be subject to secrecy requirements. Data of different sensitivity levels can sometimes be included within a single resource 202, such as data that is considered unrestricted, low sensitivity, normal sensitivity, or high sensitivity; and Paragraph [0041]: In addition, different clients 102 or users of clients 102 can have different levels of authority. By way of a non-limiting example, a doctor in a hospital can have more authority than a nurse. In some situations, clients 102 having higher authorization levels can be granted access to data that is more sensitive than clients 102 with lower authorization levels. In these cases, access to data within a resource 202 that is tagged with a particular sensitivity level can be granted to only those clients 102 that have been authorized to view, edit, or subscribe to the data of that sensitivity level. Because various data within a single resource 202 can have different sensitivity levels, clients 102 of different authorization levels can have authority to view different portions of the same resource 202; and Paragraph [0047]: In some embodiments, the number of authorization levels 404 can be equal to the number of redaction levels 402, as shown in FIG. 4A. In alternate embodiments, the number of authorization levels 404 can be different than the number of redaction levels 402, with each individual authorization level 404 corresponding to a particular range of redaction levels 402, or indicating a maximum allowed redaction level 402. By way of a non-limiting example, FIG. 4B depicts an embodiment in which the redaction levels 402 can range from 0 to 5, while the authorization levels can be 1 (low authority), 2 (medium authority), or 3 (high authority)); and the one representation [value] to be transmitted is determined based on an access type of a device requesting retrieval of data (Nakhjiri – Paragraph [0052]: When a client 102 sends a request 208 for a resource 202, the server 104 can provide the client 102 with the representation 204 of the resource 202 that contains only the data within the resource 202 that has a redaction level 402 that is equal to or lower than the redaction level 402 the client 102 is authorized to access, as indicated by the client's authorization level 404; and Paragraph [0003]: In many networked systems, such as those that have a Representational State Transfer (REST) architectural style, client devices can send requests to servers for data stored as abstract resources on the servers).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Ninglekhu and Samuel, further incorporating Nakhjiri to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Nakhjiri’s teaching to provide varying levels of resource/data access to requesting devices based on access permissions/types of the devices into Ninglekhu and Samuel’s method for operating a device to protect data in a M2M system. This addition enhances the method by providing more convenience of data access without sacrificing the security of sensitive data within the system.
Regarding Claim 12:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the first device of claim 11.
Ninglekhu further teaches wherein the processor is further configured to (Ninglekhu – Paragraph [0311]: the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the network apparatus in order to perform the various required functions of the network apparatus) generate the resource (Ninglekhu – Paragraph [0225]: When a user profile is created, the result may be the creation of a resource), and wherein the resource includes at least one of first information on generation [and storage] of the plurality of representation values (Ninglekhu – Paragraph [0340]: Examples of data anonymization and sanitization techniques include but are not limited to shuffling, filtering, masking, and aliasing … An example of aliasing is reassigning names to entities (e.g., user Bob is changed to User-A, device door-lock is changed to device-1); Table 2: Alias - A user profile may have one or more alias(s) associated with it. An alias may be used when anonymizing the data. For example, a user name alias may be used by the DAS to replace identifying information. Aliasing may be performed on fields other than the user name. For example, aliasing maybe performed on the user's home address) and second information on provision of the plurality of representation values (Ninglekhu – Paragraph [0225]: When a user profile is created, the result may be the creation of a resource. The resource may have a <userPrivacyProfile> child resource; and Table 11: Attributes of <userPrivacyProfile> resource detailing values to protect, how to protect them, and what entities to allow/limit access to them).
Samuel further teaches wherein the resource includes … first information on … storage of a representation value (Samuel – Paragraph [0048]: At step 510, the storage services 116 stores the pseudonym with the member-identifiable data in the database 124 as user data 122. Alongside the pseudonym and member-identifiable data, the storage services 116 also stores the map function created at step 508 as user data 122).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 13:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the first device of claim 12.
Ninglekhu further teaches wherein the resource is configured to be generated during a registration procedure [for the second device] (Ninglekhu – Paragraph [0134]: A user profile, such as the one shown in Table 2, may be created when a user registers herself to an IoT service layer platform via IoT Service Layer's subscriber management portal; and Paragraph [0225]: When a user profile is created, the result may be the creation of a resource).
Samuel teaches the second device (Samuel – Paragraph [0063]: a registered member 102 may request access to data from his/her client device 110 through, for example, a web portal … Once a request is received, the IoT server 112 will first verify credentials to make sure the requestor is authenticated to access entire data including member-identifiable data. The IoT server 112 will then perform the de-pseudonymization step 602 to then re-identify member data (both member-identifiable and medical data) at steps 604 and 606, and then disseminate the contents of the data to the requestor at step 608).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 14:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the first device of claim 12.
Ninglekhu further teaches wherein the second information is information for identifying a data request (Ninglekhu – Table 11: Attributes of <userPrivacyProfile> resource detailing values to protect, how to protect them, and what entities to allow/limit access to them; Examiner’s Comment: Specification paragraph [0080] defines information for identifying a data request as “a device, a device type, an access type”. Allowed Third Parties, Restricted Third Parties, and Disallowed Third Parties are interpreted as access types), which is to be responded with the plurality of representation values (Ninglekhu – Paragraph [0262]: At step 2, as the oneM2M system identifies the request from an AE, the CSE asks for data anonymization policies applicable to the request received from the AE; and Paragraph [0266]: At step 6, the DAS acts as a PEP/PDP in the oneM2M system. Anonymization policies are applied over the raw user data. Thus, an anonymized/privatized version of user data is produced; and Paragraph [0268]: At step 8, the CSE sends the anonymized version of user data to its requesting AE via a RESTful communication. Note that the reply may include an indication that the data has been anonymized. Furthermore, the reply may indicate what anonymization techniques were applied to the data), and indicates the access type (Ninglekhu – Table 11: Attributes of <userPrivacyProfile> resource detailing values to protect, how to protect them, and what entities to allow/limit access to them; Examiner’s Comment: Specification paragraph [0080] defines information for identifying a data request as “a device, a device type, an access type”. Allowed Third Parties, Restricted Third Parties, and Disallowed Third Parties are interpreted as access types).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 15:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the first device of claim 11.
Ninglekhu further teaches wherein the processor is further configured to (Ninglekhu – Paragraph [0311]: the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the network apparatus in order to perform the various required functions of the network apparatus): receive a retrieval request for data [stored in the resource] from a third device (Ninglekhu – Figure 22: data anonymization procedure in a oneM2M/IoT system; and Paragraph [0261]: At step 1, an AE that represents an ASP may send a RESTful read request to a oneM2M system via an Mca interface. As the request is received by the oneM2M system, the request for user data is identified), confirm that the third device has no right to read the original value (Ninglekhu – Paragraph [0262]: At step 2, as the oneM2M system identifies the request from an AE, the CSE asks for data anonymization policies applicable to the request received from the AE; and Paragraph [0266]: At step 6, the DAS acts as a PEP/PDP in the oneM2M system. Anonymization policies are applied over the raw user data. Thus, an anonymized/privatized version of user data is produced), and transmit, in response to the retrieval request (Ninglekhu – Paragraph [0261]: At step 1, an AE that represents an ASP may send a RESTful read request to a oneM2M system via an Mca interface. As the request is received by the oneM2M system, the request for user data is identified), the
one representation value of the plurality of representation values to the third device (Ninglekhu – Paragraph [0268]: At step 8, the CSE sends the anonymized version of user data to its requesting AE via a RESTful communication. Note that the reply may include an indication that the data has been anonymized. Furthermore, the reply may indicate what anonymization techniques were applied to the data).
Samuel further teaches data stored in the resource (Samuel – Paragraph [0048]: At step 510, the storage services 116 stores the pseudonym with the member-identifiable data in the database 124 as user data 122. Alongside the pseudonym and member-identifiable data, the storage services 116 also stores the map function created at step 508 as user data 122).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 16:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the first device of claim 15.
Ninglekhu further teaches wherein the processor is further configured to (Ninglekhu – Paragraph [0311]: the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the network apparatus in order to perform the various required functions of the network apparatus) confirm, based on the access type of the third device (Ninglekhu – Table 11: user-specified privacy preferences including lists of third parties that are allowed, restricted, or disallowed from accessing user data), that the third device is a device irrelevant to an owner of the second device (Ninglekhu – Table 11: Disallowed Third Parties - Description: Third Parties (other entities) that are not allowed to consume data related to this user; Examiner’s Comment: Examiner respectfully submits that this category would include devices irrelevant to the user who established the privacy profile (owner of the second device)).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 17:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the first device of claim 11.
Ninglekhu further teaches wherein the processor is further configured to (Ninglekhu – Paragraph [0311]: the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the network apparatus in order to perform the various required functions of the network apparatus): receive a retrieval request for data [stored in the resource] from a fourth device (Ninglekhu – Paragraph [0275]: One of the third party IN-AE's may be a health monitoring application that allows the owner of the smart watch to view his activity summary. This IN-AE may request to read the data as shown in FIG. 16, where the IN-AE is the ASP), confirm that the fourth device has right to read the original value (Ninglekhu – Paragraph [0275]: In step 2, when the IN-CSE invokes the Privacy Policy Service, the policies in the <userPrivacyProfile> may be provided to the Privacy Policy Service and used to determine that the health monitoring system is permitted to see all of the owner's data), and transmit, in response to the retrieval request, the original value to the fourth device (Ninglekhu – Paragraph [0275]: In step 7, the Data Anonymization service may provide the IN-CSE with a data set that represents all of the user's activity. This data is then provided to the IN-AE).
Samuel further teaches data stored in the resource (Samuel – Paragraph [0048]: At step 510, the storage services 116 stores the pseudonym with the member-identifiable data in the database 124 as user data 122. Alongside the pseudonym and member-identifiable data, the storage services 116 also stores the map function created at step 508 as user data 122).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 18:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the first device of claim 17.
Ninglekhu further teaches wherein the processor is further configured to (Ninglekhu – Paragraph [0311]: the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the network apparatus in order to perform the various required functions of the network apparatus) confirm, based on the access type of the fourth device (Ninglekhu – Table 11: user-specified privacy preferences including lists of third parties that are allowed, restricted, or disallowed from accessing user data) that the fourth device is a device related to an owner of the second device (Ninglekhu – Table 11: Allowed Third Parties - Description: Third Parties (other entities) that are allowed to consume data related to this user; Examiner’s Comment: Examiner respectfully submits that this category would include devices related to the user who established the privacy profile (owner of the second device)).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 19:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the first device of claim 11.
Ninglekhu further teaches wherein the resource includes a sub-resource for storing the original value (Ninglekhu – Paragraph [0273]: The user profile may include a <userPrivacyProfile> sub-resource; and Table 11: Elements of userPrivacyProfile sub-resource including Name/Street Address/Associated identifiers all interpretable as original value), and wherein the sub-resource includes an attribute for storing the original value (Ninglekhu – Table 11: Elements of userPrivacyProfile sub-resource including Name/Street Address/Associated identifiers all interpretable as original value) and an attribute for storing the plurality of representation values (Ninglekhu – Table 11: Elements Name/Street Address/Associated identifiers also include policies on how to protect (representation value(s)) the data (original value(s)); and Paragraph [0340]: Examples of data anonymization and sanitization techniques include but are not limited to shuffling, filtering, masking, and aliasing. An example of filtering is removing data. An example of masking is removing part of a data set (e.g., 6789 3rd Ave. is masked to XXXX 3rd Ave.). An example of aliasing is reassigning names to entities (e.g., user Bob is changed to User-A, device door-lock is changed to device-1)).
The motivation to combine the arts is the same as that of Claim 11.
Regarding Claim 20:
The combination of Ninglekhu, Samuel, and Nakhjiri teaches the first device of claim 11.
Ninglekhu further teaches wherein the resource includes a sub-resource for storing the original value (Ninglekhu – Table 2: Name/Associated Identifiers - authorized users of the subscription and their associated identifiers (original value(s)); Examiner’s Comment: Examiner respectfully submits that a field of a user profile resource may be considered a sub-resource of the user profile resource) and a sub-resource for storing the plurality of representation values (Ninglekhu – Table 2: Alias - A user profile may have one or more alias(s) associated with it. An alias may be used when anonymizing the data. For example, a user name alias may be used by the DAS to replace identifying information. Aliasing may be performed on field; Examiner’s Comment: Examiner respectfully submits that a field of a user profile resource may be considered a sub-resource of the user profile resource).
The motivation to combine the arts is the same as that of Claim 11.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Reich et al. (US 20140115098 A1) teaches providing placeholder content for at least a portion of requested content based on an identity of the requestor
Anderson et al. (US 11816234 B2) teaches a system and method for providing an intermediate representation of requested data based on data access policies associated with the data and the request
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/Jeremy S Duffield/Primary Examiner, Art Unit 2498
Prosecution Insights