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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Objections
Claim 9 objected to because of the following informalities:
Claim 9 reads “determining … whether the authorization information of the user needs to be checked, and if so, obtaining first authorization information …” For clarity purposes, claim 9 should instead read “determining … whether the authorization information of the user needs to be checked, and if the authorization information of the user needs to be checked, obtaining first authorization information …”
Appropriate correction is required.
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.
Claim 18 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.
Claim 18 recites the limitation "and sending, by the third network element, the first authorization information and/or the second authorization information of the user to the first network element.". There is insufficient antecedent basis for this limitation in the claim since neither claims 15 or 18 mention “a first” and “a second” authorization information.
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 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1 recites:
“checking … authorization information” (mental process – evaluation).
“… providing data …” (mental process - judgement)
Claim 11 recites:
“receiving … revocation information …” (mental process – observation.).
Claim 15 recites:
“sending … authorization information …” (mental process – observation.).
The judicial exception is not integrated into a practical application because claims, 1, 11 and 15 do not recite and further limitations that either apply, rely on, or utilize the abstract idea in a manner that imposes meaningful limit on the abstract idea itself. Specifically, claims 1, 11 and 15 do not recite any additional limitations that reflect an improvement to the functioning of a computer, or an improvement to another technology or technical field. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they recited generic computer components, “...network element…” that when considered individually or in combination with the above abstract idea, do not recite significantly more than the abstract idea itself.
Specifically, the recitations of the network elements are equivalent to components for merely storing (and retrieving) information in memory, which is recognized as well understood, routine, and conventional computer function (Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93). Thus, the above identified abstract idea recited within claims 11 and 15, when considered individually and in combination with the above recited well- known, conventional components, fails to recite subject matter that would constitute as significantly more than the abstract idea itself.
Further, dependent claim 2 which further limits claim 1 also fails to recite any further limitations that would either integrate the above identified abstract idea into a practical application and fail to recite anything which would constitute as significantly more than the abstract idea itself, as noted for the rejection of claim 1 above.
Claim 2 recites:
“checking … first authorization information and second authorization information” (mental process – evaluation.)
In addition, claim 2 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 1 above.
Claim 3 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 1 above.
Further, dependent claim 4 which further limits claim 1 also fails to recite any further limitations that would either integrate the above identified abstract idea into a practical application and fail to recite anything which would constitute as significantly more than the abstract idea itself, as noted for the rejection of claim 1 above.
Claim 4 recites:
“obtaining … authorization of the user …” (mental process – observation.).
“determining … based on first authorization information, whether the collection and/or analysis of the data … allowed” (mental process – judgement.).
In addition, claim 4 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 1 above.
Further, dependent claim 5 which further limits claim 1 also fails to recite any further limitations that would either integrate the above identified abstract idea into a practical application and fail to recite anything which would constitute as significantly more than the abstract idea itself, as noted for the rejection of claim 1 above.
Claim 5 recites:
“querying … a … context” (extra solution activity - data collection.).
“… obtaining the first authorization information of the user from the UE context.” (mental process- observation.)
In addition, claim 5 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 1 above.
Further, dependent claim 6 which further limits claim 1 also fails to recite any further limitations that would either integrate the above identified abstract idea into a practical application and fail to recite anything which would constitute as significantly more than the abstract idea itself, as noted for the rejection of claim 1 above.
Claim 6 recites:
“obtaining … first authorization information” (mental process- observation.).
“sending … at least one of an identifier …” (extra solution activity, data collection).
“receiving … first authorization information of the user …” (mental process- observation.)
In addition, claim 6 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 1 above.
Further, dependent claim 7 which further limits claim 1 also fails to recite any further limitations that would either integrate the above identified abstract idea into a practical application and fail to recite anything which would constitute as significantly more than the abstract idea itself, as noted for the rejection of claim 1 above.
Claim 7 recites:
“obtaining … second authorization information …” (mental process- observation.)
“determining … based on second authorization information, whether the data … is allowed to be provided to the second … element” (mental process – judgement.).
In addition, claim 7 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 1 above.
Further, dependent claim 8 which further limits claim 1 also fails to recite any further limitations that would either integrate the above identified abstract idea into a practical application and fail to recite anything which would constitute as significantly more than the abstract idea itself, as noted for the rejection of claim 1 above.
Claim 8 recites:
“obtaining … second authorization information” (mental process- observation.).
“sending … at least one of an identifier …” (extra solution activity, data collection).
“receiving … first authorization information of the user …” (mental process- observation.)
In addition, claim 8 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 1 above.
Further, dependent claim 9 which further limits claim 1 also fails to recite any further limitations that would either integrate the above identified abstract idea into a practical application and fail to recite anything which would constitute as significantly more than the abstract idea itself, as noted for the rejection of claim 1 above.
Claim 9 recites:
“determining … whether the authorization information … needs to be checked” (mental process – judgement.).
In addition, claim 9 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 1 above.
Further, dependent claim 10 which further limits claim 1 also fails to recite any further limitations that would either integrate the above identified abstract idea into a practical application and fail to recite anything which would constitute as significantly more than the abstract idea itself, as noted for the rejection of claim 1 above.
Claim 10 recites:
“determining … based on a first policy … whether the authorization information … needs to be checked” (mental process –judgement.).
In addition, claim 10 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 1 above.
Claim 12 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 11 above.
Further, dependent claim 13 which further limits claim 11 also fails to recite any further limitations that would either integrate the above identified abstract idea into a practical application and fail to recite anything which would constitute as significantly more than the abstract idea itself, as noted for the rejection of claim 11 above.
Claim 13 recites:
“stopping … based on revocation …” (mental process – judgement.).
In addition, claim 13 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 11 above.
Further, dependent claim 14 which further limits claim 11 also fails to recite any further limitations that would either integrate the above identified abstract idea into a practical application and fail to recite anything which would constitute as significantly more than the abstract idea itself, as noted for the rejection of claim 11 above.
Claim 14 recites:
“subscribing … notification service for … revocation” (extra solution activity, data collection).
“receives … revocation information…” (Mental process – observation.).
In addition, claim 14 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 11 above.
Claim 16 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 15 above.
Claim 17 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 15 above.
Further, dependent claim 18 which further limits claim 15 also fails to recite any further limitations that would either integrate the above identified abstract idea into a practical application and fail to recite anything which would constitute as significantly more than the abstract idea itself, as noted for the rejection of claim 15 above.
Claim 18 recites:
“receiving … data usage …” (mental process – observation).
“sending … authorization information …” (extra solution activity, data collection).
In addition, claim 18 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 15 above.
Claim 19 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 15 above.
Claim 20 fails to recite further limitations that would integrate the above identified abstract idea into a practical application, or recite any limitations which would be considered as significantly more than the abstract idea itself. Thus, this claim is rejected for the same reasons as claim 15 above.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-4, 7, 9-17 and 20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Kumar (US-20230413032-A1).
Regarding claim 1, Kumar teaches an authorization method, comprising: checking, by a first network element, authorization information of a user (Paragraph 185, "Data provider 815 may generally determine if consent is required for the data requested for that use case. The consent profile related to the use case may be queried via CMF 810, which may also track the list of current data provider(s) for that user ID, such as to support revocation). Data provider 815 generally initiates the data collection at a device and across different network services based on the consent profile For example, data provider 815 may generally provides relevant information to the data processor 820 to retrieve the data." Paragraph 194, "Accordingly and at 865, (E)UDM 805, CMF 810, and data provider 815 may initiate data collection at the end-user's device as well as with different network services (such as data processor 820) based on the consent profile (or consent type(s) of the consent profile).” The authorization information is interpreted to be in the consent types of the consent profile).
and providing data of the user and/or a data analysis result to a second network element when a check result is as follows:
collection and/or analysis of the data of the user is allowed; and (Paragraph 152, "Consent type 320 illustrates a consent type K+1, where K corresponds to an identifier of consent type 320. Consent type 320 includes similar consent parameters discussed with reference to consent type 315. However, consent type 320 may include a purpose of data request consent parameter, which generally defines the consent type 320 in terms of a threshold related to the purpose of the data request. That is, data processor(s)/consumer(s) may utilize a user's data for different purposes (e.g., tracking, ad preference updates, etc.). A request to access the user's data may include a purpose indication, which may be matched to the purpose of data request consent parameter. If the purpose indication matches the purpose of data request consent parameter, this may serve as an enabling threshold where the remaining consent parameters of consent type 320 are applied." The consent type 320 is interpreted as containing the authorization information being checked. The purpose of indication being matched against the data request consent parameter is seen as the "collection/analysis" of the user's data being allowed.)
the data of the user and/or the data analysis result is allowed to be provided to the second network element. (Paragraph 150, "A consent parameter of the consent type K may include a service data/processor ID, which may generally be identifier(s) for allowed and/or prohibited data processor(s)/consumer(s) (e.g., based on a corresponding subscription)." The service/data process IDs consent parameter is shown in Fig. 3, item 320/consent type 320, with the parameter being defined in the paragraph described consent type K, since consent type K+1/item 320, uses that same parameter.).
Regarding claim 2, Kumar teaches the method according to claim 1. Kumar further teaches wherein checking, by the first network element, the authorization information of the user comprises:
checking, by the first network element, first authorization information and second authorization information of the user, wherein the first authorization information is used to indicate whether the collection and/or analysis of the data of the user is allowed; and (Paragraph 193, "At 860, data provider 815 may identify, determine, or otherwise verify consent for the use case. For example, data provider 815 may use the consent profile (or consent type(s) of the consent profile) for that use case as well as the subscribe message received from data processor 820 to confirm or otherwise verify that the user has granted consent to the user's data for data provider 815 and/or data processor 820." Paragraph 152, "Consent type 320 illustrates a consent type K+1, where K corresponds to an identifier of consent type 320. Consent type 320 includes similar consent parameters discussed with reference to consent type 315. However, consent type 320 may include a purpose of data request consent parameter, which generally defines the consent type 320 in terms of a threshold related to the purpose of the data request. That is, data processor(s)/consumer(s) may utilize a user's data for different purposes (e.g., tracking, ad preference updates, etc.). A request to access the user's data may include a purpose indication, which may be matched to the purpose of data request consent parameter. If the purpose indication matches the purpose of data request consent parameter, this may serve as an enabling threshold where the remaining consent parameters of consent type 320 are applied." Fig. 3, item 320/consent type K+1 shows a first authorization information, purpose of data request, and a second authorization information, service/data process IDs.).
the second authorization information is used to indicate whether the data of the user and/or the data analysis result is allowed to be provided to the second network element. (Paragraph 152, "Consent type 320 illustrates a consent type K+1, where K corresponds to an identifier of consent type 320. Consent type 320 includes similar consent parameters discussed with reference to consent type 315. However, consent type 320 may include a purpose of data request consent parameter. … If the purpose indication matches the purpose of data request consent parameter, this may serve as an enabling threshold where the remaining consent parameters of consent type 320 are applied." Paragraph 150, "A consent parameter of the consent type K may include a service data/processor ID, which may generally be identifier(s) for allowed and/or prohibited data processor(s)/consumer(s) (e.g., based on a corresponding subscription)." The service/data process IDs consent parameter is shown in Fig. 3, item 320/consent type 320, with the parameter being defined in the paragraph described consent type K, since consent type K+1/item 320, uses that same parameter.).
Regarding claim 3, Kumar teaches the method according to claim 2. Kumar further teaches wherein the authorization information comprises user consent;
the first authorization information comprises user consent for the first network element; (Paragraph 152, "Consent type 320 illustrates a consent type K+1, where K corresponds to an identifier of consent type 320. … However, consent type 320 may include a purpose of data request consent parameter, which generally defines the consent type 320 in terms of a threshold related to the purpose of the data request. … A request to access the user's data may include a purpose indication, which may be matched to the purpose of data request consent parameter. If the purpose indication matches the purpose of data request consent parameter, this may serve as an enabling threshold where the remaining consent parameters of consent type 320 are applied." Paragraph 193, "At 860, data provider 815 may identify, determine, or otherwise verify consent for the use case. For example, data provider 815 may use the consent profile (or consent type(s) of the consent profile) for that use case as well as the subscribe message received from data processor 820 to confirm or otherwise verify that the user has granted consent to the user's data for data provider 815 and/or data processor 820." Paragraph 194, "Accordingly and at 865, (E)UDM 805, CMF 810, and data provider 815 may initiate data collection at the end-user's device as well as with different network services (such as data processor 820) based on the consent profile (or consent type(s) of the consent profile)." The first network element is permitted to perform the data collection request based on consent/permission of the system to perform data collection based on data request purpose (the purpose of data request consent parameter is the enabling threshold for checking the other consent parameters) before checking the service/data process IDs.).
and the second authorization information comprises user consent for the second network element. (Paragraph 150, "A consent parameter of the consent type K may include a service data/processor ID, which may generally be identifier(s) for allowed and/or prohibited data processor(s)/consumer(s) (e.g., based on a corresponding subscription)." The service/data process IDs consent parameter is shown in Fig. 3, item 320/consent type 320, with the parameter being defined in the paragraph described consent type K, since consent type K+1/item 320, uses that same parameter.).
Regarding claim 4, Kumar teaches the method according to claim 2. Kumar further teaches wherein checking, by the first network element, the first authorization information of the user comprises:
obtaining, by the first network element, the first authorization information of the user; (Fig. 8, item 855 shows a user consent profile being sent to the data provider for it to verify. Paragraph 192, "At 855, CMF 810 may transmit or otherwise provide (and data provider 815 may receive or otherwise obtain) an update message (e.g., a second response). That is, CMF 810 may transmit a second response (e.g., the update message) to data provider 815 that carries or otherwise conveys an indication of the user ID as well as the consent profile (or consent type(s) of the consent profile) for that use case." The sending of a consent type, an example of which is described in Fig. 3, item 320, is interpreted as sending a first and second authorization (these consent parameters are contained in the consent type).).
and determining, by the first network element, based on the first authorization information, whether the collection and/or analysis of the data of the user is allowed. (Paragraph 152, "… However, consent type 320 may include a purpose of data request consent parameter… That is, data processor(s)/consumer(s) may utilize a user's data for different purposes … which may be matched to the purpose of data request consent parameter. If the purpose indication matches the purpose of data request consent parameter, this may serve as an enabling threshold where the remaining consent parameters of consent type 320 are applied." Paragraph 193, "… data provider 815 may use the consent profile (or consent type(s) of the consent profile) … to confirm or otherwise verify that the user has granted consent to the user's data for data provider 815 and/or data processor 820." The first network element is permitted to perform the data collection request based on consent/permission of the system to perform data collection based on data request purpose (the purpose of data request consent parameter is the enabling threshold for checking the other consent parameters).).
Regarding claim 7, Kumar teaches the method according to claim 2. Kumar further teaches wherein checking by the first network element, the second authorization information of the user comprises:
obtaining, by the first network element, the second authorization information of the user; (Fig. 8, item 855 shows a user consent profile being sent to the data provider for it to verify. Paragraph 192, " That is, CMF 810 may transmit a second response (e.g., the update message) to data provider 815 that carries or otherwise conveys an indication of the user ID as well as the consent profile (or consent type(s) of the consent profile) for that use case. " As described in claim 2’s mapping, a consent type is interpreted to contain a first and second authorization information.).
and determining, by the first network element determines, based on the second authorization information, whether the data of the user and/or the data analysis result is allowed to be provided to the second network element. Paragraph 152, "Consent type 320 illustrates a consent type K+1, where K corresponds to an identifier of consent type 320. Consent type 320 includes similar consent parameters discussed with reference to consent type 315. However, consent type 320 may include a purpose of data request consent parameter. … If the purpose indication matches the purpose of data request consent parameter, this may serve as an enabling threshold where the remaining consent parameters of consent type 320 are applied." Paragraph 150, "A consent parameter of the consent type K may include a service data/processor ID, which may generally be identifier(s) for allowed and/or prohibited data processor(s)/consumer(s) (e.g., based on a corresponding subscription)." The service/data process IDs consent parameter is shown in Fig. 3, item 320/consent type 320, with the parameter being defined in the paragraph described consent type K, since consent type K+1/item 320, uses that same parameter.).
Regarding claim 9, Kumar teaches the method according to claim 1. Kumar teaches further comprising: determining, by the first network element, whether the authorization information of the user needs to be checked (Paragraph 187, "At 830, data provider 815 may identify or otherwise determine whether consent is needed. For example, the data that data processor 820 is requesting access to may be open or otherwise available for access without user consent (e.g., public or non-personable information). Other data, likely most of the data of or otherwise relating to the end-user, may require consent of the user before access is granted. If no consent is necessary, data provider 815 may simply respond to the subscribe message indicting that the data is available and/or providing the data.").
and if so, obtaining first authorization information of the user and/or second authorization information of the user. (Paragraph 188, “Otherwise and when user consent is required for data access, at 835 data provider 815 may transmit or otherwise provide (and CMF 810 may receive or otherwise obtain) a query message (e.g., a first request). Broadly, the query message (e.g., a first request) may generally request access to data associated with a user ID.” Paragraph 192, “At 855 … CMF 810 may transmit a second response (e.g., the update message) to data provider 815 that carries or otherwise conveys an indication of the user ID as well as the consent profile (or consent type(s) of the consent profile) for that use case.” Fig. 8 shows the consent profile/types being obtained by the first network element in the case it needs consent data, where 830 is the determining step, 835 is querying for authorization information if consent information is needed, and 855 is where the consent information is given to the first network element.).
Regarding claim 10, Kumar teaches the method according to claim 9. Kumar further teaches wherein determining, by the first network element, whether the authorization information of the user needs to be checked comprises: determining, by the first network element, based on a first policy and/or a data type involved in a data authorization request, Paragraph 186, “… The subscribe message may carry or otherwise convey an indication of a user ID (e.g., if known), may identify the data that access is being requested” Paragraph 187, "At 830, data provider 815 may identify or otherwise determine whether consent is needed.”).
whether the authorization information of the user needs to be checked. (Paragraph 187, "… For example, the data that data processor 820 is requesting access to may be open or otherwise available for access without user consent (e.g., public or non-personable information). Other data, likely most of the data of or otherwise relating to the end-user, may require consent of the user before access is granted. If no consent is necessary, data provider 815 may simply respond to the subscribe message indicting that the data is available and/or providing the data." The determining of a data type is interpreted as the element checking if the type of data the data processor is requesting is open or otherwise available for access without user consent.).
Regarding claim 11, Kumar teaches an authorization method, comprising: receiving, by a first network element, revocation information for user authorization. (Paragraphs 208-209, "Based on data provider 1020 being impacted by the revocation request, at 1040 CMF 1015 may transmit or otherwise provide (and data provider 1020 may receive or otherwise obtain) a notification message indicating the user ID and the revocation indication. Accordingly, at 1045, DGC 1005, (E)UDM 1010, CMF 1015, and/or data provider 1020 may update the actions occurring at end-user device(s) as well as across different network services based on the user ID/consent profile. For example, this may include stopping or otherwise modifying data collection based on the revocation request from the end-user. In some examples, this may include CMF 1015 updating the access level associated with the consent type(s) to a revoked status based on the revocation request. In some examples, this may include data provider 1020 and/or data processor(s)/consumer(s) adopting the action to be taken upon revocation consent parameter in the consent type(s) of the consent profile(s) of the user ID in response to the revocation request." The consent profile revoke indication is shown in Fig. 10 to be received by the data provider, the first network element. The revocation request is interpreted as revocation of consent and therefor authorization.).
Regarding claim 12, Kumar teaches the method according to claim 11. Kumar further teaches wherein the revocation information for the user authorization comprises revocation information for user consent. (Paragraph 204, “CMF 1015 may generally notify data providers (such as data provider 1020) currently subscribed for that user ID if the consent profile has changed for their use case.” Paragraphs 208-209, "Based on data provider 1020 being impacted by the revocation request, at 1040 CMF 1015 may transmit or otherwise provide (and data provider 1020 may receive or otherwise obtain) a notification message indicating the user ID and the revocation indication. … data provider 1020 … adopting the action to be taken upon revocation consent parameter in the consent type(s) of the consent profile(s) of the user ID in response to the revocation request." The revocation information for user consent is interpreted as the revocation indication paired with the user ID shown in Fig. 10, item 1040, the notification, since the revocation information notified the data provider that the consent associated with user ID has been changed.).
Regarding claim 13, Kumar teaches the method according to claim 11. Kumar teaches further comprising: stopping, by the first network element, based on the revocation information for the user authorization, collecting and/or analyzing data of a user. (Paragraphs 208-209, "Based on data provider 1020 being impacted by the revocation request, at 1040 CMF 1015 may transmit or otherwise provide (and data provider 1020 may receive or otherwise obtain) a notification message indicating the user ID and the revocation indication. Accordingly, at 1045, DGC 1005, (E)UDM 1010, CMF 1015, and/or data provider 1020 may update the actions occurring at end-user device(s) as well as across different network services based on the user ID/consent profile. For example, this may include stopping or otherwise modifying data collection based on the revocation request from the end-user. In some examples, this may include CMF 1015 updating the access level associated with the consent type(s) to a revoked status based on the revocation request. In some examples, this may include data provider 1020 and/or data processor(s)/consumer(s) adopting the action to be taken upon revocation consent parameter in the consent type(s) of the consent profile(s) of the user ID in response to the revocation request.").
Regarding claim 14, Kumar teaches the method according to claim 11, further comprising: subscribing, by the first network element, to a notification service for user authorization revocation from a third network element, wherein the first network element receives the revocation information for the user authorization from the third network element. (Paragraph 204, "Method 1000 illustrates a non-limiting example of a revocation request from an end-user revoking consent within the consent platform. Broadly, this may include the (E)UDM 1010 notifying CMF 1015 that consent has been revoked by the user. CMF 1015 may generally notify data providers (such as data provider 1020) currently subscribed for that user ID if the consent profile has changed for their use case. " Paragraph 163, "For example, DGC 505 may refer to an application, feature, or other function operating at a device (e.g., a UE or some other device) of or otherwise associated with an end-user (e.g., operating at the application layer of the UE)." The data provider is seen as subscribing to notifications from the third network element. As shown in Fig. 10, the user device sends to the UDM a user authorization revocation to the UDM/third network element, the UDM will then notify the data provider/ first network element that consent has been revoked).
Claim(s) 15 and 18-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by 3GPP (“3GPP TR 33.867 V17.1.0,” March 2022).
Regarding claim 15, 3GPP teaches an authorization method, comprising: sending, by a third network element, (Fig. 7.4.2.1-1 shows a UDM device, interpreted as the third network element.)
authorization information of a user to a first network element, (Page 21, “6) The UDM returns requested user consent parameters, which includes user consent result.” The returned consent parameters are interpreted as authorization information.)
for the first network element to check the authorization information of the user. (Page 21, “7) The NEF/CAPIF determines whether to authorize the API invocation or not according to the user consent parameters based on implementation.” The NEF/CAPIF, the first network element, checks the consent parameters.).
Regarding claim 18, 3GPP teaches the method according to claim 15. 3GPP further teaches wherein sending, by the third network element, the authorization information of the user to the first network element comprises: receiving, by the third network element, at least one of an identifier of User Equipment (UE), an application identifier, or a data usage from the first network element; and (Fig. 7.4.2.1-1 shows in item 4 that the get request contains the UE ID. Page 21, “The NEF/CAPIF sends Nudm_SDM_Get Request message to the UDM, the message includes UE ID, and may include purpose of data processing, data processor ID.” The UDM is the third network, element, receiving the UE ID from the first network element NEF.).
sending, by the third network element, the first authorization information and/or the second authorization information of the user to the first network element. (Fig. 7.4.2.1-1 shows in item 4 that the get request contains the UE ID, and a response from the UDM containing the user consent parameters. Page 21, “1) UDM maintains user consent parameters as subscription data as depicted in clause 7.4.2.2. … 6) The UDM returns requested user consent parameters, which includes user consent result.” Page 22, “The UDM maintains the following user consent parameters: - UE ID: can be SUPI. - Data Processor ID: refers to a data processor who process data for the UE, can be AF ID, or more generic, e.g. "3rd party" or "all". - Purpose of data processing: the goal that processing the data ultimately achieves, refers to which actions are done with the data to achieve which goal. - User Consent Result: whether there is consent for data processor to process the data according to purpose of data processing.” The consent parameter of purpose of data processing is interpreted as the first authorization information that is sent to the first network element.).
Regarding claim 19, 3GPP teaches the method of claim 15. Kumar does not teach wherein the first network element comprises a Network Data Analytics Function (NWDAF) or a Network Exposure Function (NEF). (Fig. 7.4.2.1-1 shows an NEF device, interpreted as the first network element.)
Regarding claim 20, Kumar teaches the method according to claim 15. 3GPP further teaches wherein the third network element comprises a User Data Management (UDM). (Fig. 7.4.2.1-1 shows a UDM device, interpreted as the third network element.).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 5-6, 8, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US-20230413032-A1) in view of Bi (WO-2022148254-A1).
Regarding claim 5, Kumar teaches the method according to claim 4. Kumar further teaches wherein obtaining, by the first network element, the first authorization information of the user comprises:
querying, by the first network element, a locally stored [user] context, (Paragraphs 188, "Otherwise and when user consent is required for data access, at 835 data provider 815 may transmit or otherwise provide (and CMF 810 may receive or otherwise obtain) a query message (e.g., a first request). Broadly, the query message (e.g., a first request) may generally request access to data associated with a user ID. For example, the query message may carry or otherwise convey an indication of the user ID, the use case, and the activate indication.” Paragraph 12, “Some examples of the method, apparatuses, and non-transitory computer-readable medium described herein may further include operations, features, means, or instructions for storing the consent profile and a subscription ID for the user ID in a UDM entity …” Paragraph 6, "In some examples, the device of the user (e.g., one of the user's UE(s) or other device(s)) may include a data governance client (DGC) (e.g., operating at the application layer within the wireless network) that supports consent management functions for the user. For example, the UE may transmit or otherwise provide the consent profile registration request to a network entity (e.g., a network entity coupled with the DGS, in this example). The UE may transmit or otherwise provide the consent profile to the network entity in response to the request." Paragraph 170, " At 535, DGS 510 may generally provision the consent profile with (E)UDM 515." The locally stored user context is interpreted as the consent profile information stored in the UDM.).
and obtaining the first authorization information of the user from the [user] context. (Paragraphs 189 - 192, "In response to the query message, at 840 CMF 810 may optionally transmit or otherwise provide (and (E)UDM 805 may optionally receive or otherwise obtain) a subscribe request message (e.g., a second request). The subscribe request message may carry or otherwise convey an indication of the user ID. … Accordingly, CMF 810 may optionally transmit the second request (e.g., the subscribe request message) to a second network entity (e.g., (E)UDM 805, in this example) indicating the user ID and requesting the access level. … At 850, (E)UDM 805 may optionally transmit or otherwise provide (and CMF 810 may optionally receive or otherwise obtain) a notification message (e.g., a first response). That is, CMF 810 may receive or otherwise obtain a first response from the second network entity (e.g., (E)UDM 805, in this example) that carries or otherwise conveys an indication of the access level. For example, the notification message may carry or otherwise convey the consent profile of the user ID, one or more consent type(s) for that use case … At 855, CMF 810 may transmit or otherwise provide (and data provider 815 may receive or otherwise obtain) an update message (e.g., a second response). That is, CMF 810 may transmit a second response (e.g., the update message) to data provider 815 that carries or otherwise conveys an indication of the user ID as well as the consent profile (or consent type(s) of the consent profile) for that use case." The data provider receiving the consent type is interpreted as receiving the first authorization information.).
However, Kumar does not explicitly teach a querying … a … UE context … and obtaining … from … UE context
Bi teaches querying … a … UE context … (Page 19, "Step 3: After receiving the first user information analysis request, the NWDAF network element sends a first query request to the UDM network element, which is used for requesting to query whether the target UE allows the network to analyze the user information of the target UE, or for requesting query Subscription information of the target UE, where the subscription information is used to indicate whether the target UE allows the network to analyze the user information of the target UE. … In this step, the first query request carries the indication information of the target UE. … Step 4a: After receiving the first query request, the UDM network element sends a fourth permission indication acquisition request to the NEF network element, which carries the indication information of the target UE and also carries the identifier of the AF.").
obtaining … from … UE context (Page 20, "Step 5: After receiving the permission indication information of the target UE, the UDM network element returns a first query response to the NWDAF network element, which is used to indicate whether the target UE allows the network to analyze the user information of the target UE. … Optionally, the first query response may carry permission indication information of the target UE, where the permission indication information is used to indicate whether the target UE allows the network to collect or analyze user information of the target UE.")
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Kumar’s consent processing system with Bi by enhancing Kumar’s consent handling system to include consent permissions for specific user equipment, allowing requesting parties to request consent information for these specific user equipment, as taught by Bi. The motivation is to provide a more granular means to request and and determine a user’s consent for data collection, where a user might not want to consent to data collection on one UE, but permits it on another.
Regarding claim 6, Kumar teaches the method according to claim 4. Kumar further teaches wherein obtaining, by the first network element, the first authorization information of the user comprises: obtaining, by the first network element, the first authorization information of the user from a third network element, (Fig. 8 shows the data provider receiving the user consent types/profile from the UDM, the consent profiles/types are shown in Fig. 3 as containing the first authorization information. the UDM is interpreted as the third network element. The first network element is permitted to perform the data collection request based on consent/permission of the system to perform data collection based on data request purpose (the purpose of data request consent parameter is the enabling threshold for checking the other consent parameters) before checking the service/data process IDs, in consent type 320.)
wherein obtaining, by the first network element, the first authorization information of the user from the third network element comprises: sending, by the first network element, at least one of an identifier of a [user], an application identifier, or a data usage to the third network element; and (Paragraph 189, "In response to the query message, at 840 CMF 810 may optionally transmit or otherwise provide (and (E)UDM 805 may optionally receive or otherwise obtain) a subscribe request message (e.g., a second request). The subscribe request message may carry or otherwise convey an indication of the user ID. The subscribe request message may generally request the access level for the data provider 815 and/or data processor 820. That is, the subscribe request message may generally request the access level for data provider 815 and/or data processor 820 to the end-user's data. Accordingly, CMF 810 may optionally transmit the second request (e.g., the subscribe request message) to a second network entity (e.g., (E)UDM 805, in this example) indicating the user ID and requesting the access level." Paragraph 15, “In some examples of the method, apparatuses, and non-transitory computer-readable medium described herein, the consent profile ID maps the consent profile to a user associated with the user ID at a UE.” Fig. 8 shows a user ID in the request for the consent information by the data provider.).
receiving, by the first network element, the first authorization information of the user from the third network element. (Paragraph 191, "At 850, (E)UDM 805 may optionally transmit or otherwise provide (and CMF 810 may optionally receive or otherwise obtain) a notification message (e.g., a first response). That is, CMF 810 may receive or otherwise obtain a first response from the second network entity (e.g., (E)UDM 805, in this example) that carries or otherwise conveys an indication of the access level. For example, the notification message may carry or otherwise convey the consent profile of the user ID, one or more consent type(s) for that use case, and/or may simply use a bit or flag to indicate that the access level of data provider 815 and/or data processor 820 is granted to the end-user's data." The UDM sends the consent profile/first authorization information.)
However, Kumar does not explicitly teach sending, by the first network element … an identifier of a UE …
Bi teaches sending, by the first network element … an identifier of a UE … (Page 19, "Step 3: After receiving the first user information analysis request, the NWDAF network element sends a first query request to the UDM network element, which is used for requesting to query whether the target UE allows the network to analyze the user information of the target UE, or for requesting query Subscription information of the target UE, where the subscription information is used to indicate whether the target UE allows the network to analyze the user information of the target UE. … In this step, the first query request carries the indication information of the target UE. … Step 4a: After receiving the first query request, the UDM network element sends a fourth permission indication acquisition request to the NEF network element, which carries the indication information of the target UE and also carries the identifier of the AF").
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Kumar’s consent processing system with Bi by enhancing Kumar’s consent handling system to include consent permissions for specific user equipment, allowing requesting parties to request consent information for these specific user equipment, as taught by Bi. The motivation is to provide a more granular means to request and and determine a user’s consent for data collection, where a user might not want to consent to data collection on one UE, but permits it on another.
Regarding claim 8, Kumar teaches the method according to claim 7. Kumar further teaches wherein obtaining, by the first network element, the second authorization information of the user comprises: obtaining, by the first network element, the second authorization information of the user from a third network element, (Fig. 8 shows the data provider receiving the user consent types/profile from the UDM, the consent profiles/types are shown in Fig. 3 as containing the second authorization information. the UDM is interpreted as the third network element.)
wherein obtaining, by the first network element, the second authorization information of the user from the third network element comprises: sending, by the first network element, at least one of an identifier of User …, an application identifier, or a data usage to the third network element; and (Paragraph 189, "In response to the query message, at 840 CMF 810 may optionally transmit or otherwise provide (and (E)UDM 805 may optionally receive or otherwise obtain) a subscribe request message (e.g., a second request). The subscribe request message may carry or otherwise convey an indication of the user ID. The subscribe request message may generally request the access level for the data provider 815 and/or data processor 820. That is, the subscribe request message may generally request the access level for data provider 815 and/or data processor 820 to the end-user's data. Accordingly, CMF 810 may optionally transmit the second request (e.g., the subscribe request message) to a second network entity (e.g., (E)UDM 805, in this example) indicating the user ID and requesting the access level." Fig. 8 shows a user ID in the request for the consent information by the data provider.)
receiving, by the first network element, the second authorization information of the user from the third network element. (Paragraph 191, "At 850, (E)UDM 805 may optionally transmit or otherwise provide (and CMF 810 may optionally receive or otherwise obtain) a notification message (e.g., a first response). That is, CMF 810 may receive or otherwise obtain a first response from the second network entity (e.g., (E)UDM 805, in this example) that carries or otherwise conveys an indication of the access level. For example, the notification message may carry or otherwise convey the consent profile of the user ID, one or more consent type(s) for that use case, and/or may simply use a bit or flag to indicate that the access level of data provider 815 and/or data processor 820 is granted to the end-user's data." The UDM sends the consent profile/second authorization information.).
However, Kumar does not explicitly teach sending, by the first network element … an identifier of a UE …
Bi teaches sending, by the first network element … an identifier of a UE … (Page 19, "Step 3: After receiving the first user information analysis request, the NWDAF network element sends a first query request to the UDM network element, which is used for requesting to query whether the target UE allows the network to analyze the user information of the target UE, or for requesting query Subscription information of the target UE, where the subscription information is used to indicate whether the target UE allows the network to analyze the user information of the target UE. … In this step, the first query request carries the indication information of the target UE. … Step 4a: After receiving the first query request, the UDM network element sends a fourth permission indication acquisition request to the NEF network element, which carries the indication information of the target UE and also carries the identifier of the AF").
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Kumar’s consent processing system with Bi by enhancing Kumar’s consent handling system to include consent permissions for specific user equipment, allowing requesting parties to request consent information for these specific user equipment, as taught by Bi. The motivation is to provide a more granular means to request and and determine a user’s consent for data collection, where a user might not want to consent to data collection on one UE, but permits it on another.
Regarding claim 18, Kumar teaches the method according to claim 15. Kumar further teaches wherein sending, by the third network element, the authorization information of the user to the first network element comprises: receiving, by the third network element, at least one of an identifier of User …, an application identifier, or a data usage from the first network element; and (Paragraph 189, "In response to the query message, at 840 CMF 810 may optionally transmit or otherwise provide (and (E)UDM 805 may optionally receive or otherwise obtain) a subscribe request message (e.g., a second request). The subscribe request message may carry or otherwise convey an indication of the user ID. The subscribe request message may generally request the access level for the data provider 815 and/or data processor 820. That is, the subscribe request message may generally request the access level for data provider 815 and/or data processor 820 to the end-user's data. Accordingly, CMF 810 may optionally transmit the second request (e.g., the subscribe request message) to a second network entity (e.g., (E)UDM 805, in this example) indicating the user ID and requesting the access level." The user ID is received by the third network element/UDM, which is received in the request from the first network element/data provider shown in Fig. 8.)
sending, by the third network element, the first authorization information and/or the second authorization information of the user to the first network element. (Paragraph 191, "At 850, (E)UDM 805 may optionally transmit or otherwise provide (and CMF 810 may optionally receive or otherwise obtain) a notification message (e.g., a first response). That is, CMF 810 may receive or otherwise obtain a first response from the second network entity (e.g., (E)UDM 805, in this example) that carries or otherwise conveys an indication of the access level. For example, the notification message may carry or otherwise convey the consent profile of the user ID, one or more consent type(s) for that use case, and/or may simply use a bit or flag to indicate that the access level of data provider 815 and/or data processor 820 is granted to the end-user's data." The first and second authorization information are sent to the data provider from the UDM through the consent profile information.).
However, Kumar does not explicitly teach receiving, by the third network element, … an identifier of User Equipment (UE) …
Bi teaches receiving, by the third network element, … an identifier of User Equipment (UE) … (Page 19, "Step 3: After receiving the first user information analysis request, the NWDAF network element sends a first query request to the UDM network element, which is used for requesting to query whether the target UE allows the network to analyze the user information of the target UE, or for requesting query Subscription information of the target UE, where the subscription information is used to indicate whether the target UE allows the network to analyze the user information of the target UE. In this step, the first query request carries the indication information of the target UE. … Optionally, the UDM network element may first query the subscription information of the target UE locally (the subscription information is used to indicate whether the target UE allows the network to analyze the user information of the target UE). , then the first query response can be returned to the NWDAF network element according to the subscription information (step 5) to indicate whether the target UE allows the network to analyze the user information of the target UE, so that steps 4a to 4d do not need to be performed. If the UDM network element does not query the above subscription information, step 4a to step 4d are performed.")
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Kumar’s consent processing system with Bi by enhancing Kumar’s consent handling system to include consent permissions for specific user equipment, allowing requesting parties to request consent information for these specific user equipment, as taught by Bi. The motivation is to provide a more granular means to request and and determine a user’s consent for data collection, where a user might not want to consent to data collection on one UE, but permits it on another.
Claim 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP (“3GPP TR 33.867 V17.1.0,” March 2022) in view of Kumar (US-20230413032-A1).
Regarding claim 16, 3GPP teaches the method according to claim 15. Kumar further teaches wherein the authorization information of the user comprises first authorization information and second authorization information, (Page 21, “1) UDM maintains user consent parameters as subscription data as depicted in clause 7.4.2.2.” Page 22, “7.4.2.2 User Consent Parameter The UDM maintains the following user consent parameters: - UE ID: can be SUPI. - Data Processor ID: refers to a data processor who process data for the UE, can be AF ID, or more generic, e.g. "3rd party" or "all". - Purpose of data processing: the goal that processing the data ultimately achieves, refers to which actions are done with the data to achieve which goal. - User Consent Result: whether there is consent for data processor to process the data according to purpose of data processing.” The first authorization information is interpreted as the Purpose of data processing, and the second authorization information is interpreted as the user consent result.).
However, 3GPP does not explicitly teach wherein the first authorization information is used to indicate whether collection and/or analysis of data of the user is allowed; and the second authorization information is used to indicate whether the data of the user and/or a data analysis result is allowed to be provided to a second network element.
Kumar teaches wherein the first authorization information is used to indicate whether collection and/or analysis of data of the user is allowed; (Paragraph 152, "However, consent type 320 may include a purpose of data request consent parameter, which generally defines the consent type 320 in terms of a threshold related to the purpose of the data request. That is, data processor(s)/consumer(s) may utilize a user's data for different purposes (e.g., tracking, ad preference updates, etc.). A request to access the user's data may include a purpose indication, which may be matched to the purpose of data request consent parameter. If the purpose indication matches the purpose of data request consent parameter, this may serve as an enabling threshold where the remaining consent parameters of consent type 320 are applied." Paragraph 150, "A consent parameter of the consent type K may include a service data/processor ID, which may generally be identifier(s) for allowed and/or prohibited data processor(s)/consumer(s) (e.g., based on a corresponding subscription)." Fig. 3, item 320/consent type K+1 shows a first authorization information, purpose of data request, and a second authorization information, service/data process IDs. The purpose of data request parameter permits whether or not the collection of user data is allowed in the first place as the enabling threshold, before checking the later consent parameters).
and the second authorization information is used to indicate whether the data of the user and/or a data analysis result is allowed to be provided to a second network element.(Paragraph 150, "A consent parameter of the consent type K may include a service data/processor ID, which may generally be identifier(s) for allowed and/or prohibited data processor(s)/consumer(s) (e.g., based on a corresponding subscription)." The service/data process IDs consent parameter is shown in Fig. 3, item 320/consent type 320, with the parameter being defined in the paragraph described consent type K, since consent type K+1/item 320, uses that same parameter. The service/data process IDs consent parameter requires the enabling threshold to be first met, where it indicates whether or not consent for the data collection that passed the enabling threshold is permitted for the specific requesting network elements.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify 3GPP’s consent system with Kumar by enhancing 3GPP’s consent parameters to include a more granular and detailed means of defining the consent parameters, with the first consent parameter being a general permission for the system to perform data collection as the threshold, and the second parameter being allowed and prohibited data processor entities if the general permission is met, as taught by Kumar. The motivation is to give users more in depth management of their consent information, allowing them to protect their data in more case specific ways.
Regarding claim 17, 3GPP in view of Kumar teaches the method according to claim 16. 3GPP further teaches wherein the authorization information comprises user consent; (Page 21, “1) UDM maintains user consent parameters as subscription data as depicted in clause 7.4.2.2.” Page 22, “7.4.2.2 User Consent Parameter The UDM maintains the following user consent parameters...).
However, 3GPP does not explicitly teach the first authorization information comprises user consent for the first network element; and the second authorization information comprises user consent for the second network element.
Kumar teaches the first authorization information comprises user consent for the first network element; (Paragraph 152, "… However, consent type 320 may include a purpose of data request consent parameter … related to the purpose of the data request. That is, data processor(s)/consumer(s) may utilize a user's data for different purposes (e.g., tracking, ad preference updates, etc.). A request to access the user's data may include a purpose indication, which may be matched to the purpose of data request consent parameter. If the purpose indication matches the purpose of data request consent parameter, this may serve as an enabling threshold where the remaining consent parameters of consent type 320 are applied." Fig. 3, item 320/consent type K+1 shows a first authorization information, purpose of data request. The purpose of data request parameter permits whether or not the collection of user data is allowed in the first place as the enabling threshold, before checking the later consent parameter, interpreted as consent for the first network element.).
and the second authorization information comprises user consent for the second network element. (Paragraph 150, "A consent parameter of the consent type K may include a service data/processor ID, which may generally be identifier(s) for allowed and/or prohibited data processor(s)/consumer(s) (e.g., based on a corresponding subscription)." The service/data process IDs consent parameter is shown in Fig. 3, item 320/consent type 320, with the parameter being defined in the paragraph described consent type K, since consent type K+1/item 320, uses that same parameter. The service/data process IDs consent parameter requires the enabling threshold to be first met, where it indicates whether or not consent for the data collection that passed the enabling threshold is permitted for the specific requesting network elements. The data for allowed and prohibited data processors/consumers (which are interpreted as the second network element) is interpreted user consent pertaining to secondary network elements.).
The motivation to combine 3GPP and Kumar is the same as in claim 15.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUHAMMAD H RASUL whose telephone number is (571)272-4613. The examiner can normally be reached Monday - Friday 6:30 A.M.- 5:00 P.M. E.D.T..
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, Rupal Dharia can be reached at 571-272-3880. 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.
/M.H.R./Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights