DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed on 12/31/2025
Claims 1, 5, 7-8, 11, 15, and 17-18 are currently amended
Claims 9-10 and 19-20 have been cancelled
Claims 1-8 and 11-18 are pending
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 .
Response to Amendment
Examiner has fully considered Applicant’s amendments to the Claims in the arguments filed on 12/31/2025. Claims 1, 5, 7-8, 11, 15, and 17-18 are currently amended, Claims 9-10 and 19-20 have been cancelled, and Claims 1-8 and 11-18 remain pending. The outstanding rejections under 35 USC 112(b) have been withdrawn in view of the amendments. However, claim objections arise in view of the amendments.
Response to Arguments
Applicant’s arguments filed 12/31/2025, with respect to the rejections of claims 1-8 and 11-18
under 35 USC 101 have been fully considered, but they are not persuasive. Examiner respectfully submits that at least independent claims 1 and 11, as amended, are not sufficient to overcome the outstanding 101 rejections. Applicant’s Argument, beginning on p. 9 of Applicant Arguments, relies on the newly added limitations “a transceiver and a processor” and “receive a mandatory parameter used for processing a response or a request with other devices” as reciting improvements to the functioning of a computer. However, the claimed transceiver and processor are broadly stated, generic computer components. The mandatory parameter is also broadly stated, and represents a routine function of networked devices. Thus, these limitations are not considered as reciting explicit technical improvements.
Applicant Arguments recites that the additional amended limitations regarding the storage of the values in first, second, or third “attributes” and accessing one of the second attributes based on an access type of a requesting device also provide an improvement to the functioning of a computer. However, these limitations also represent simple organization and management of information and subsequent retrieval and transmission of the information based on broadly-stated criteria. That is, the structural organization of the attributes and the data stored therein do not appear to represent an improvement on a broad capability for data storage and retrieval. The limitations, “the first attribute indicates access … based on the plurality of access types” and “accessing one of the second attributes based on an access type of a third device requesting retrieval of the data” are further details describing evaluations performable in the mind, coupled with further generic computer functionality.
Applicant’s Argument, beginning on P. 10 of Applicant Arguments, that the recitation of the claim “machine-to-machine (M2M) system” is sufficient to link the invention to a particular technological environment, therefore amounting to significantly more than the abstract ideas, is not persuasive. As highlighted in the previous Response to Arguments 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, the claims, as amended, do not provide significantly more than the judicial exceptions.
Updated rationale for maintaining the rejections is provided herein.
Applicant’s arguments filed 12/31/2025, with respect to the rejections of claims 1-8 and 11-18 under 35 USC 103 have been fully considered, but they are not persuasive. After an updated search and further consideration, Examiner respectfully submits that the teachings of the previously applied references from Ninglekhu and Nakhjiri collectively render obvious the limitations of the claims, as amended, including the newly added limitation(s) “the plurality of access types is stored in a first attribute of the resource, the plurality of representation values is stored in second attributes of a sub-resource for the resource, the original value is stored in a third attribute of the sub-resource, and the first attribute indicates access to one of the second attributes based on the plurality of access types; accessing one of the second attributes based on an access type of a third device requesting retrieval of the data”; and “and controlling the processor to control the transceiver to receive a mandatory parameter used for processing a response or a request with other devices”. Further, the combined teachings of Ninglekhu and Nakhjiri render the previously relied upon teachings from Samuel redundant. Therefore, Samuel will not be relied upon herein.
Examiner respectfully traverses Applicant’s Argument beginning on P. 10 of Applicant Arguments that the combination of Ninglekhu and Nakhjiri is not sufficient to teach at least the amended claims 1 and 11. As highlighted in Applicant Arguments, Ninglekhu teaches userProfile resources, attributes of which are highlighted in at least Tables 2, 3, and 10. The categories of third party data requesters (demonstrated in Table 3) are interpreted to be analogous to the claimed access types. Table 11 of Ninglekhu further describes a userPrivacyPolicy sub-resource of the userProfile resource, which includes original values and user-specified techniques for protecting the data values against potentially unauthorized parties.
While Ninglekhu lacks an explicit storage of a plurality of representation values corresponding to an original value from which an appropriate representation value is accessed according to an access type of a requesting device, the teachings from Nakhjiri naturally combine with those of Ninglekhu. Specifically, Nakhjiri establishes a known solution to a known problem for selective and variable degrees of data protection based on access permissions of a request originator. That is, Nakhjiri’s plurality of representation values corresponding to authorization levels (access types) of requesting users/devices, which are stored together in a resource, would have been obvious to inject into Ninglekhu’s user-configurable policies for data protection. Thus, the combination of Ninglekhu and Nakhjiri covers the structural and functional elements of the claim.
Updated rationale for maintaining the rejections is provided herein.
Claim Objections
Claims 1 and 11 are objected to because of the following informalities:
Independent claims 1 and 11 each recite the similar limitation “transmit(ting) one representation value”. The limitation should read: “transmit(ting) one of the plurality of representation values” for consistency with the antecedent bases of the plurality of representation values established earlier in the claims.
Appropriate correction is required.
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-8 and 11-18 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, accessing, 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, accessing, 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 “transmitting one representation value” are merely data communication 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. “Accessing one of the second attributes based on an access type …” is a conditional data retrieval combining a rules-based decision performable in the mind, coupled with the generically-stated organized data. Thus, 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, a transceiver, processor, M2M system, a second device, a resource, a third device, and the controlling step. All of the hardware elements are recited at a high level of generality. The controlling step including the mandatory parameter is also stated broadly and is not clearly connected with the other claim elements in a way that amounts to more than a well-understood capability of networked devices. 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, obtaining, and accessing 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, nor the controlling of the processor/transceiver. 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 recites substantially similar limitations.
Claims 2-8 and 12-18 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 Nakhjiri et al. (US 20150186635 A1), hereinafter Nakhjiri.
Regarding Claim 1:
Ninglekhu teaches a method for operating a first device comprising a transceiver and a processor coupled to 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). The processor 32, through the execution of computer executable instructions, may control the communication circuitry in order to cause the network apparatus 30 to communicate with other network apparatuses via the network to which it is connected) 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; and Paragraph [0201]: Policy 1: Enforce>User preferences AND Enforce>User consent to share data; and Paragraph [0202]: Policy 2: Abbreviate>User ID AND Sanitize>Street Name and Sanitize>SSN AND Encrypt>Date of Birth; and Paragraph [0204]: At step 6, raw data and applicable policies are received by the Data Anonymization Service as its input. Data may be anonymized based on the policies. As a result, an anonymized version of data that meets all the requirements is produced. For example, anonymized version of a “User ID”; “Sam Adams” may be “User ID”: “SA” (abbreviation), “Address”: “Philadelphia, Pa.”, “SSN”: “ ”, “Date of Birth”: “Nv/gQsVqxRa460ib1RYgRfw==IwEmS”), 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 Paragraph [0201]: Policy 1: Enforce>User preferences AND Enforce>User consent to share data; and Paragraph [0202]: Policy 2: Abbreviate>User ID AND Sanitize>Street Name and Sanitize>SSN AND Encrypt>Date of Birth; and Paragraph [0204]: At step 6, raw data and applicable policies are received by the Data Anonymization Service as its input. Data may be anonymized based on the policies. As a result, an anonymized version of data that meets all the requirements is produced. For example, anonymized version of a “User ID”; “Sam Adams” may be “User ID”: “SA” (abbreviation), “Address”: “Philadelphia, Pa.”, “SSN”: “ ”, “Date of Birth”: “Nv/gQsVqxRa460ib1RYgRfw==IwEmS”); and storing the original value … in a resource … for storing the data (Ninglekhu – Tables 2, 3, and 10: A User Profile resource includes various original data values associated with a device, subject to protection measures); the plurality of access types is stored in a first attribute of the resource (Ninglekhu – Table 3: User Profile includes a Privacy Protection Rules field, which includes access types for requesting users/devices), the plurality of representation [values] is stored in second attributes of a sub-resource for the resource, the original value is stored in a third attribute of the sub-resource (Ninglekhu – Table 11: illustration of a <userPrivacyProfile> sub-resource of a <userProfile> resource which includes original data and preferences for how the original data values should be protected during accesses by third parties), and the first attribute indicates access to one of the second attributes based on the plurality of access types (Ninglekhu – Table 3: User Profile includes a Privacy Protection Rules field, which includes access types for requesting users/devices; and Table 11: illustration of a <userPrivacyProfile> sub-resource of a <userProfile> resource which includes original data and preferences for how the original data values should be protected during accesses by third parties, the categories and corresponding access types of the third parties specified in Table 3’s demonstration of the <userProfile> resource); transmitting one representation value of the one of the second attributes (Ninglekhu – Paragraph [0195]: At step 1, the ASP sends a request for user data to the IoT service layer platform. The request may include the ASP's credentials and attributes. For example, the ASP's AE application may send a request with attributes such as User Category=Finance, Date Range=May 1, 2016 to Apr. 30, 2017, Location=Zip 19126, etc. The request may further comprise user credentials such as a User ID that consists of user's first name and last name; and Paragraph [0198]: For instance, user preferences may include: Abbreviate>User ID AND Sanitize>Street Name AND Sanitize>SSN AND Encrypt>Date of Birth etc. Here, “>” indicates command or instruction; and Paragraph [0201]: Policy 1: Enforce>User preferences AND Enforce>User consent to share data; and Paragraph [0202]: Policy 2: Abbreviate>User ID AND Sanitize>Street Name and Sanitize>SSN AND Encrypt>Date of Birth; and Paragraph [0204]: At step 6, raw data and applicable policies are received by the Data Anonymization Service as its input. Data may be anonymized based on the policies. As a result, an anonymized version of data that meets all the requirements is produced. For example, anonymized version of a “User ID”; “Sam Adams” may be “User ID”: “SA” (abbreviation), “Address”: “Philadelphia, Pa.”, “SSN”: “ ”, “Date of Birth”: “Nv/gQsVqxRa460ib1RYgRfw==IwEmS”); and controlling the processor to control the transceiver to receive a mandatory parameter used for processing a response or a request with other devices (Ninglekhu – Paragraph [0195]: At step 1, the ASP sends a request for user data to the IoT service layer platform. The request may include the ASP's credentials and attributes. For example, the ASP's AE application may send a request with attributes such as User Category=Finance, Date Range=May 1, 2016 to Apr. 30, 2017, Location=Zip 19126, etc. The request may further comprise user credentials such as a User ID that consists of user's first name and last name; and Paragraph [0215]: At step 3, the Privacy Policy Service (PPS) creates applicable policies based on request parameters, user preferences and defaults. The government policies and the data consumer preferences may be implemented as defaults. Additionally or alternatively, the policy may indicate choices (e.g., differentiation by data consumer type). The PPS may utilize the user preferences provided in the request or may discover user preferences based on other request parameters. For example, a request for policies associated with a piece of information created by a medical application for user X may trigger the centralized PPS to check if it already has user preferences associated with X and medical data, even if they are not provided by the SL. The policies may include the type of anonymization to be performed, algorithm type, strength, etc. The policy may also specify where and how the anonymized data and the de-anonymization parameters should be stored).
Ninglekhu does not expressly teach receiving, from a second device, data … generated by the second device; wherein each of the plurality of representation values is distinctly associated with one of a plurality of access types; 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; and accessing one of the second attributes based on an access type of a third device requesting retrieval of the data.
However, Nakhjiri teaches receiving, from a second device, data … generated by the second device (Nakhjiri – Paragraph [0058]: By way of a non-limiting example, a sensor 106 can be running an electronic health application in its application layer 702 that stores and/or processes measurements taken by the sensor 106; and Paragraph [0059]: At step 804, the measurements can be passed from the sensor's application layer 702 to the sensor's service layer 704. The sensor 106 can use its service layer 704 to transfer the measurement data from the sensor 106 to the service layer 704 of a server 104); wherein each of the plurality of representation values is distinctly associated with one of a plurality of access types (Nakhjiri – Paragraph [0033]: A resource 202 can be an object, file, or any other type of data stored on a server 104; and 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)); 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 (Nakhjiri – Paragraph [0048]: Different representations 204 of a resource 202 can be generated and be provided to clients 102 depending on the client's authorization level 404 and the redaction level 402 of each piece of data within the resource 202. Each different representation 204 can be redacted differently depending on the redaction levels 402 of the data in the resource 202. In some embodiments a plurality of representations 204 of a single resource 202 can be generated, and the plurality of representations 204 can be stored on a server 104 for later retrieval; and Figure 5: various representations of a resource reflecting redaction levels corresponding to an authorization level of a requester, including full access to the original resource (element 204a) and a plurality of different representations (elements 204b and 204c)); and accessing one of the [second attributes] based on an access type of a third device requesting retrieval of the 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).
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 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’s techniques for user-configurable data protection techniques for secure participation in a M2M system. Nakhjiri’s generation and storage of multiple representations which correspond to multiple levels of authorized access combine naturally with Ninglekhu’s establishment of user profiles defining data protection measures against third party data requesters. Nakhjiri’s representations achieve the predictable result of protecting certain data according to criteria while enabling convenient and secure information exchange.
Regarding Claim 2:
The combination of Ninglekhu 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).
Nakhjiri further teaches wherein the resource includes … first information on … storage of the plurality of representation values (Nakhjiri – Paragraph [0052]: In some embodiments, each of the plurality of representations 204 can be stored at a different URI 206, such that the client 102 can obtain a particular representation 204 of the resource 202 by requesting it from the URI 206 that corresponds to the client's authorization level 404 or requested redaction level 402).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 3:
The combination of Ninglekhu 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).
Nakhjiri further teaches the second device (Nakhjiri – Paragraph [0058]: By way of a non-limiting example, a sensor 106 can be running an electronic health application in its application layer 702 that stores and/or processes measurements taken by the sensor 106; and Paragraph [0059]: At step 804, the measurements can be passed from the sensor's application layer 702 to the sensor's service layer 704. The sensor 106 can use its service layer 704 to transfer the measurement data from the sensor 106 to the service layer 704 of a server 104).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 4:
The combination of Ninglekhu 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 and Nakhjiri teaches the method of claim 1.
Ninglekhu further teaches further comprising: receiving a retrieval request for the data [stored in the resource] from the 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 from the third device (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).
Nakhjiri further teaches data stored in the resource (Nakhjiri – Paragraph [0048]: Different representations 204 of a resource 202 can be generated and be provided to clients 102 depending on the client's authorization level 404 and the redaction level 402 of each piece of data within the resource 202. Each different representation 204 can be redacted differently depending on the redaction levels 402 of the data in the resource 202. In some embodiments a plurality of representations 204 of a single resource 202 can be generated, and the plurality of representations 204 can be stored on a server 104 for later retrieval; and Figure 5: various representations of a resource reflecting redaction levels corresponding to an authorization level of a requester, including full access to the original resource (element 204a) and a plurality of different representations (elements 204b and 204c)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 6:
The combination of Ninglekhu 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 and Nakhjiri teaches the method of claim 1.
Ninglekhu further teaches further comprising: receiving a retrieval request for the 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 from the fourth device, 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).
Nakhjiri further teaches data stored in the resource (Nakhjiri – Paragraph [0048]: Different representations 204 of a resource 202 can be generated and be provided to clients 102 depending on the client's authorization level 404 and the redaction level 402 of each piece of data within the resource 202. Each different representation 204 can be redacted differently depending on the redaction levels 402 of the data in the resource 202. In some embodiments a plurality of representations 204 of a single resource 202 can be generated, and the plurality of representations 204 can be stored on a server 104 for later retrieval; and Figure 5: various representations of a resource reflecting redaction levels corresponding to an authorization level of a requester, including full access to the original resource (element 204a) and a plurality of different representations (elements 204b and 204c)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 8:
The combination of Ninglekhu 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 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; and Paragraph [0201]: Policy 1: Enforce>User preferences AND Enforce>User consent to share data; and Paragraph [0202]: Policy 2: Abbreviate>User ID AND Sanitize>Street Name and Sanitize>SSN AND Encrypt>Date of Birth; and Paragraph [0204]: At step 6, raw data and applicable policies are received by the Data Anonymization Service as its input. Data may be anonymized based on the policies. As a result, an anonymized version of data that meets all the requirements is produced. For example, anonymized version of a “User ID”; “Sam Adams” may be “User ID”: “SA” (abbreviation), “Address”: “Philadelphia, Pa.”, “SSN”: “ ”, “Date of Birth”: “Nv/gQsVqxRa460ib1RYgRfw==IwEmS”), 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 Paragraph [0201]: Policy 1: Enforce>User preferences AND Enforce>User consent to share data; and Paragraph [0202]: Policy 2: Abbreviate>User ID AND Sanitize>Street Name and Sanitize>SSN AND Encrypt>Date of Birth; and Paragraph [0204]: At step 6, raw data and applicable policies are received by the Data Anonymization Service as its input. Data may be anonymized based on the policies. As a result, an anonymized version of data that meets all the requirements is produced. For example, anonymized version of a “User ID”; “Sam Adams” may be “User ID”: “SA” (abbreviation), “Address”: “Philadelphia, Pa.”, “SSN”: “ ”, “Date of Birth”: “Nv/gQsVqxRa460ib1RYgRfw==IwEmS”); store the original value … in a resource … for storing the data (Ninglekhu – Tables 2, 3, and 10: A User Profile resource includes various original data values associated with a device, subject to protection measures); the plurality of access types is stored in a first attribute of the resource (Ninglekhu – Table 3: User Profile includes a Privacy Protection Rules field, which includes access types for requesting users/devices), the plurality of representation [values] is stored in second attributes of a sub-resource for the resource, the original value is stored in a third attribute of the sub-resource (Ninglekhu – Table 11: illustration of a <userPrivacyProfile> sub-resource of a <userProfile> resource which includes original data and preferences for how the original data values should be protected during accesses by third parties), and the first attribute indicates access to one of the second attributes based on the plurality of access types (Ninglekhu – Table 3: User Profile includes a Privacy Protection Rules field, which includes access types for requesting users/devices; and Table 11: illustration of a <userPrivacyProfile> sub-resource of a <userProfile> resource which includes original data and preferences for how the original data values should be protected during accesses by third parties, the categories and corresponding access types of the third parties specified in Table 3’s demonstration of the <userProfile> resource); transmit one representation value of the one of the second attributes (Ninglekhu – Paragraph [0195]: At step 1, the ASP sends a request for user data to the IoT service layer platform. The request may include the ASP's credentials and attributes. For example, the ASP's AE application may send a request with attributes such as User Category=Finance, Date Range=May 1, 2016 to Apr. 30, 2017, Location=Zip 19126, etc. The request may further comprise user credentials such as a User ID that consists of user's first name and last name; and Paragraph [0198]: For instance, user preferences may include: Abbreviate>User ID AND Sanitize>Street Name AND Sanitize>SSN AND Encrypt>Date of Birth etc. Here, “>” indicates command or instruction; and Paragraph [0201]: Policy 1: Enforce>User preferences AND Enforce>User consent to share data; and Paragraph [0202]: Policy 2: Abbreviate>User ID AND Sanitize>Street Name and Sanitize>SSN AND Encrypt>Date of Birth; and Paragraph [0204]: At step 6, raw data and applicable policies are received by the Data Anonymization Service as its input. Data may be anonymized based on the policies. As a result, an anonymized version of data that meets all the requirements is produced. For example, anonymized version of a “User ID”; “Sam Adams” may be “User ID”: “SA” (abbreviation), “Address”: “Philadelphia, Pa.”, “SSN”: “ ”, “Date of Birth”: “Nv/gQsVqxRa460ib1RYgRfw==IwEmS”); and control the processor to control the transceiver to receive a mandatory parameter used for processing a response or a request with other devices (Ninglekhu – Paragraph [0195]: At step 1, the ASP sends a request for user data to the IoT service layer platform. The request may include the ASP's credentials and attributes. For example, the ASP's AE application may send a request with attributes such as User Category=Finance, Date Range=May 1, 2016 to Apr. 30, 2017, Location=Zip 19126, etc. The request may further comprise user credentials such as a User ID that consists of user's first name and last name; and Paragraph [0215]: At step 3, the Privacy Policy Service (PPS) creates applicable policies based on request parameters, user preferences and defaults. The government policies and the data consumer preferences may be implemented as defaults. Additionally or alternatively, the policy may indicate choices (e.g., differentiation by data consumer type). The PPS may utilize the user preferences provided in the request or may discover user preferences based on other request parameters. For example, a request for policies associated with a piece of information created by a medical application for user X may trigger the centralized PPS to check if it already has user preferences associated with X and medical data, even if they are not provided by the SL. The policies may include the type of anonymization to be performed, algorithm type, strength, etc. The policy may also specify where and how the anonymized data and the de-anonymization parameters should be stored).
Ninglekhu does not expressly teach receive, from a second device, data … generated by the second device; wherein each of the plurality of representation values is distinctly associated with one of a plurality of access types; 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; and access one of the second attributes based on an access type of a third device requesting retrieval of the data.
However, Nakhjiri teaches receive, from a second device, data … generated by the second device (Nakhjiri – Paragraph [0058]: By way of a non-limiting example, a sensor 106 can be running an electronic health application in its application layer 702 that stores and/or processes measurements taken by the sensor 106; and Paragraph [0059]: At step 804, the measurements can be passed from the sensor's application layer 702 to the sensor's service layer 704. The sensor 106 can use its service layer 704 to transfer the measurement data from the sensor 106 to the service layer 704 of a server 104); wherein each of the plurality of representation values is distinctly associated with one of a plurality of access types (Nakhjiri – Paragraph [0033]: A resource 202 can be an object, file, or any other type of data stored on a server 104; and 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)); 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 (Nakhjiri – Paragraph [0048]: Different representations 204 of a resource 202 can be generated and be provided to clients 102 depending on the client's authorization level 404 and the redaction level 402 of each piece of data within the resource 202. Each different representation 204 can be redacted differently depending on the redaction levels 402 of the data in the resource 202. In some embodiments a plurality of representations 204 of a single resource 202 can be generated, and the plurality of representations 204 can be stored on a server 104 for later retrieval; and Figure 5: various representations of a resource reflecting redaction levels corresponding to an authorization level of a requester, including full access to the original resource (element 204a) and a plurality of different representations (elements 204b and 204c)); and access one of the [second attributes] based on an access type of a third device requesting retrieval of the 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).
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 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’s techniques for user-configurable data protection techniques for secure participation in a M2M system. Nakhjiri’s generation and storage of multiple representations which correspond to multiple levels of authorized access combine naturally with Ninglekhu’s establishment of user profiles defining data protection measures against third party data requesters. Nakhjiri’s representations achieve the predictable result of protecting certain data according to criteria while enabling convenient and secure information exchange.
Regarding Claim 12:
Claim 12 is a device claim with limitations corresponding to those of method Claim 2. Therefore, Claim 12 is rejected with the same combination and rationale as Claim 2.
Regarding Claim 13:
Claim 13 is a device claim with limitations corresponding to those of method Claim 3. Therefore, Claim 13 is rejected with the same combination and rationale as Claim 3.
Regarding Claim 14:
Claim 14 is a device claim with limitations corresponding to those of method Claim 4. Therefore, Claim 14 is rejected with the same combination and rationale as Claim 4.
Regarding Claim 15:
Claim 15 is a device claim with limitations corresponding to those of method Claim 5. Therefore, Claim 15 is rejected with the same combination and rationale as Claim 5.
Regarding Claim 16:
Claim 16 is a device claim with limitations corresponding to those of method Claim 6. Therefore, Claim 16 is rejected with the same combination and rationale as Claim 6.
Regarding Claim 17:
Claim 17 is a device claim with limitations corresponding to those of method Claim 7. Therefore, Claim 17 is rejected with the same combination and rationale as Claim 7.
Regarding Claim 18:
Claim 18 is a device claim with limitations corresponding to those of method Claim 8. Therefore, Claim 18 is rejected with the same combination and rationale as Claim 8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Flynn, IV et al. (US 20210084112 A1) teaches methods for processing requests (including data retrieval) as to enable compatibility among previously incompatible devices. Techniques include changing and selectively presenting different values based on access profiles of requesters
Seed et al. (US 20200304510 A1) teaches service discovery in M2M systems implementing permissions to securely facilitate access to appropriate data
Schulz (EP 3515035 B1) teaches associations of requesting devices in IoT/M2M systems with certain requester properties which allow access to corresponding data annotations
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights