DETAILED ACTION
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 Arguments
Applicant’s arguments have been carefully considered and are not deemed persuasive.
Applicant argues: Claims 1, 9, and 17 - Song Does Not Teach a Request to Be Authenticated by the Service Producer. Claims 1 and 9 require that the service operation request message include a request to be authenticated by the service producer. Claim 17 requires receiving such a request message from the service consumer. Song's service request message contains attestation information for the producer to verify the trustworthiness of the consumer (Song [0350]). Song's authentication paradigm is unidirectional, such that the producer authenticates the consumer. Song does not teach a request message that includes any indication that the consumer is requesting to be authenticated by the producer, nor does Song contemplate a protocol design in which the consumer signals to the producer that it wishes the producer to authenticate itself or perform a trust-based check on the consumer as part of a mutual or trust-index-based process initiated by the consumer. The Examiner relies on Kopack ([0165]) to supply a general concept of mutual authentication, but Kopack is directed to conventional credential-based authentication between users and online service providers. Thus, the context of Kopack is wholly distinct from a 5G/6G service-based architecture using WTRUs and trust-index-based authentication. Kopack does not disclose embedding any mutual-authentication request in a service operation request message. The Examiner's rationale of "better security" is conclusory and does not provide the articulated reasoning with rational underpinning required to support an obviousness rejection.
Examiner’s Response: The Examiner respectfully disagrees. Since Song teaches that the service consumer is sending attestation information to the producer that the producer is specifically using to verify the trustworthiness of the consumer, this can be considered a request to be authenticated (as part of the request for content). The consumer would know that they need to be authenticated before receiving content, and therefore, by requesting the content, they are requesting to be authenticated in the process. In response to Applicant’s comments on Kopak, the Examiner notes that Kopak is now only being relied upon to teach the notification of authentication due to the deletion of other claim limitations.
Applicant argues: Claims 1 and 9 - Song Does Not Teach the Claimed Four-Step Message Sequence. Claims 1 and 9 require a specific four-step message exchange: (1) service operation request; (2) authentication notification message indicating the service producer will execute the target service (distinct from, and preceding, service execution); (3) authentication confirmation message from the consumer; and (4) service operation response. Song discloses a service request followed by a single service response message that merges the authentication/trustworthiness. result with service delivery (Song [0356]-[0357], [0371]). Song has no intermediate authentication notification message - separate from and preceding the actual service response - and no consumer confirmation loop prior to service execution. Kopack's confirmation message ([0077]) arises in an entirely different context and does not, in combination with Song, reconstruct Song's two-message exchange into the distinct four-step handshake required by claims 1 and 9. No specific motivation has been articulated for why a skilled artisan would decompose Song's unified request/response architecture into this sequenced authentication-notification-then-execution structure.
Examiner’s Response: Song teaches both the request for service (and authentication) as well as providing the service. Kopak teaches authenticating a consumer and notifying the consumer of the authentication. It is the combination of these references that teaches the claimed limitations. It must be remembered that the references are relied upon in combination and are not meant to be considered separately as in a vacuum. It is the combination of all of the cited and relied upon references which make up the state of the art with regard to the claimed invention. Merely requesting authentication and receiving the notification as a separate step does not make applicant’s claims patentable over the prior art.
Applicant argues: Claim 17 - The Combination Does Not Teach Selecting a TMF or Requesting a Trust Index from the Selected TMF. Claim 17 requires a specific producer-side procedural sequence: (1) selecting a TMF; (2) sending to a network node comprising the selected TMF a request for a trust index of the service consumer; (3) receiving from that selected TMF a response including the trust index; and (4) authenticating the received service operation request using trust- based authentication based on that trust index. The Examiner acknowledges Song and Kopack do not teach these steps and relies on Su (Su, p. 84). Su describes a general trust management concept in which a trust management function computes a trust value. Su does not disclose a service producer procedurally selecting a TMF, sending a targeted query to that selected TMF for a consumer's trust index, and then performing trust-based authentication based on the received trust index. The Examiner's assertion that such steps would be "intrinsic to maintain basic security" (OA 1 22) is a conclusory statement unsupported by evidence; it is not a substitute for identifying where the prior art teaches or suggests this specific procedural sequence. The combination of Song, Kopack, and Su does not teach or render obvious the TMF-selection and trust-index-query sequence required by claim 17.
Examiner’s Response: The Examiner respectfully disagrees. The request and selection of the TMF in this scenario is merely data acquisition. Song clearly teaches that the data producer uses information to authenticate the consumer, as discussed above. Su clearly teaches using a TMF to compute a trust value. Therefore, it would clearly flow that a service producer could request any TMF to gather trust data for authentication. Again, it must be remembered that the references are relied upon in combination and are not meant to be considered separately as in a vacuum. It is the combination of all of the cited and relied upon references which make up the state of the art with regard to the claimed invention. The skilled artisan, having the cited references before him or her as a guide would be able to come up with the claimed invention and see the benefits of using TMF for authentication. The selection of a TMF, the request of the data, etc. do not make the claims patentably distinct from the prior art.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3, 4, 11, and 12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 3, 4, 11, and 12 recite limitations which seem to define limitations that were previously recited in the independent claims, which have now been amended to delete those limitations (trust index and trust indicators). Therefore, it is unclear how 3, 4, 11, and 12 are supposed to limit claims 1 and 9.
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.
Claims 1, 5, 6, 8, 9, 13, 14, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. (US 2024/0354429) in view of Kopack (US 2023/0179589).
Regarding claims 1 and 9, Song teaches a method (and corresponding service consumer) performed by a first wireless transmit/receive unit (WTRU) comprising a service consumer, the method comprising:
sending, to a second WTRU comprising a service producer, a service operation request message requesting access to at least one target service provided by the service produce, (the network function service consumer sends a service request message. The service request message is used to request to obtain the service provided by the network function service provider – see [0348] – [0349]), wherein the service operation request message includes a request to be authenticated by the service producer (the service request message further includes second attestation information is generated based on second challenge data is for verifying whether the network function service consumer is trusted (i.e., authenticated)) – see [0350].
receiving, from the second WTRU comprising the service producer, an authentication notification message including an indication of a trust-based authentication result indicating that the service producer will execute the at least one target service (the network function service consumer receives a service response message…The service response message indicates whether the service request is accepted and further indicates a result of the trustworthiness verification of the network function service consumer – see [0356] – [0357]).
receiving, from the second WTRU comprising the service producer, a service operation response message including at least one service execution result associated with the executed at least one target service (describing that having performed that verifications of the attestation data comprised in the service request, the network function service provider…proves the service to the network function service consumer based on a verifications status – see [0371]).
Song does not sending, to the second WTRU comprising the service producer, an authentication confirmation message.
Kopak teaches providing user authentication to online service providers, and/or provide online service provider authentication to users for the purpose of one-sided or mutual authentication – see [0165]. Kopak further teaches a confirmation of the authentication completion may be provided to the online service provider in order to allow the user to access the resource at the first device– see [0077].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Song by sending an authentication confirmation message, for informing the service producer of authentication, based upon the beneficial teachings provided by Kopak. These modifications would allow for a more informed system on the consumer side, which enhances organization.
Regarding claims 5 and 13, it is intrinsic to Song to that the service operation request message further includes an identifier of the device or user and the service operation being requested, as there must be some type of identification of the requester. The consumer is requesting a service and the service producer needs to know who is requesting and what they are requesting. Song teaches an attestation value, which can be considered an identification – see [0348] – [0371].
Regarding claims 6 and 14, it is intrinsic to Song that the service operation request message further includes an identifier of the device or user and the service operation being requested, as there must be some type of identification of the requester. The consumer is requesting a service and the service producer needs to know who is requesting and what they are requesting. Song teaches an attestation value, which can be considered an identification – see [0348] – [0371].
Regarding claims 8 and 16, Song teaches that the service consumer is a function entity service consumer (FESC) and the service production is a function entity service producer (FESP) (The Examiner notes that the applicant’s specification states that a FESC is generally a service consumer and a FESP is generally a service producer – see [0073] of applicant’s specification. Song teaches a service producer and a service consumer – see [0348] - [0349] which teaches a service provider and service consumer).
Claims 3, 4, 11, 12, 17, 20, 21, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. (US 2024/0354429) in view of Kopack (US 2023/0179589), and further in view of Su et al. (Ensuring Trustworthiness in IoIT/AIoT A Phased-Based Approach).
Regarding claim 17, Song teaches a method performed by a first WTRU comprising a service producer, the method comprising:
receiving, from a second WTRU comprising a service consumer, a service operation request message (the network function service consumer sends a service request message. The service request message is used to request to obtain the service provided by the network function service provider – see [0348] – [0349]).
Authenticating the received service operation request message using trust based authentication (see figure 4).
Sending, to the second WTRU comprising the service consumer, an authentication notification message including an indication of a result of the trust-based authentication (the network function service consumer receives a service response message…The service response message indicates whether the service request is accepted and further indicates a result of the trustworthiness verification of the network function service consumer – see [0356] – [0357]).
Song does not teach receiving, from the second WRTI comprising the service consumer, an authentication confirmation message.
Kopak teaches providing user authentication to online service providers, and/or provide online service provider authentication to users for the purpose of one-sided or mutual authentication – see [0165]. Kopak further teaches a confirmation of the authentication completion may be provided to the online service provider in order to allow the user to access the resource at the first device– see [0077].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Song by sending an authentication confirmation message, based upon the beneficial teachings provided by Kopak. These modifications would allow for a more informed system on the consumer side, which enhances organization.
Song and Kopak do not teach selecting a trust management function (TMF); sending to a network node comprising the selected TMF, a request message requesting a trust index of the service consumer; receiving from the network node comprising the selected TMF, a response message including an indication of the trust index of the service consumer; or that the that the trust based authentication os based on the trust index of the service consumer.
Su teaches: Trust management (i.e., TMF) gathers relevant parameters…the degree of trustworthiness, namely, the trust value, is calculated by a predetermined mathematical method in trust updating. Trust value is computed, and TM infers a conclusion based on this trust value to device if the node can be trusted or not – see page 84 2nd column.
The Examiner notes that the request and receipt of the trust values would be intrinsic to the teachings of Su, in order to simply gather the information.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Song and Kopak by using trust indexes for authenticating/authorizing in order to determine how trustworthy a consumer is, based upon the beneficial teachings provided by Su. These modifications would result in better security to the system.
Regarding claims 3, 4, 11, and 12, please see 112 rejection above.
Regarding claims 3, 4, 11, and 12, Song and Kopak do not teach using a trust index or trust indicator.
Su teaches: Trust management (i.e., TMF) gathers relevant parameters…the degree of trustworthiness, namely, the trust value, is calculated by a predetermined mathematical method in trust updating. Trust value is computed, and TM infers a conclusion based on this trust value to device if the node can be trusted or not – see page 84 2nd column.
Su teaches that a trust index is a metric that indicates a level of trustworthiness and is based on a trust evaluation of one or more trust indicators, wherein the trust indicators comprise factors related to security (trust value based on trustworthiness which relies on trust parameters applied to networking security – see page 84 second column).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Song and Kopak by using trust indexes for authenticating/authorizing in order to determine how trustworthy a consumer is, based upon the beneficial teachings provided by Su. These modifications would result in better security to the system.
Regarding claim 20, Song teaches that the service consumer is a function entity service consumer (FESC) and the service production is a function entity service producer (FESP) (The Examiner notes that the applicant’s specification states that a FESC is generally a service consumer and a FESP is generally a service producer – see [0073] of applicant’s specification. Song teaches a service producer and a service consumer – see [0348] - [0349] which teaches a service provider and service consumer).
Regarding claim 21, the Examiner notes that authenticating the TMF taught by Su would be intrinsic or at least obvious to maintain basic levels of security.
Regarding claim 22, Song teaches: wherein the service operation request message indicates at least one target service provided by the service producer (note: a request for service naturally indicates what service is being requested), further comprising:
Executing the at least one target service (service process – see figure 14, S1317).
Sending, to the second WRTU comprising the service consumer, a service operation response message including at least one service execution result associated with the executed at least one target service (the network function service provider provides the service to the network function service consumer based on a verifications status - see [0371]).
Claims 2 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. (US 2024/0354429) in view of Kopack (US 2023/0179589), and in view Su et al. (Ensuring Trustworthiness in IoIT/AIoT A Phased-Based Approach), and further in view of Campobasso et al. (US 2024/0256991).
The teachings of Song and Kopak are relied upon for the reasons set forth above.
Regarding claims 2 and 10, Kopak further teaches: providing user authentication to online service providers, and/or provide online service provider authentication to users for the purpose of one-sided or mutual authentication – see [0165].
Song and Kopak do not teach sending to a network node comprising a TMF, a request message requesting a trust index of the service producer; receiving from the network node comprising the selected TMF, a response message including an indication of the trust index of the service producer, wherein the service consumer authenticates the service producer.
Su teaches: Trust management (i.e., TMF) gathers relevant parameters…the degree of trustworthiness, namely, the trust value, is calculated by a predetermined mathematical method in trust updating. Trust value is computed, and TM infers a conclusion based on this trust value to device if the node can be trusted or not – see page 84 2nd column.
The Examiner notes that the request and receipt of the trust values would be intrinsic to the teachings of Su, in order to simply gather the information.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Song and Kopak by using trust indexes for authenticating/authorizing in order to determine how trustworthy a consumer is, based upon the beneficial teachings provided by Su. These modifications would result in better security to the system.
Song, Kopak, and Su does not teach authenticating by comparing the trust index to a preconfigured threshold.
Campobasso teaches: the authentication result may be “pass” if the trust score is higher than or equal to the threshold. The authentication result may also be “pass” if the trust score is lower than the threshold and the user successfully performed the additional authentication step. The authentication result may be “fail” if the trust score is lower than the threshold and the user failed to successfully perform the additional authentication step. The server system 104 then authenticates the user based on the authentication result – see [0034].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Song, Kopak, and Su by using a threshold of trust index to determine authentication, based upon the beneficial teachings provided by Su. These modifications would result in better configuration options for the system (such as desired trust level).
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. (US 2024/0354429) in view of Kopack (US 2023/0179589), and further in view of Wang (US 2024/0338227).
The teachings of Song and Kopak are relied upon for the reasons set forth above.
Regarding claims 7 and 15, Song and Kopak do not teach forwarding the at least one execution result to at least one of: an application server, a next application function in a chain of application functions, and a charging function.
Wang teaches storing execution results on application servers – see [0136] and [0155].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Song and Kopak by forwarding the execution results to an application, for the purpose of keeping logs of execution, based upon the beneficial teachings provided by Wang. These modifications would result in better record keeping.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 LISA C LEWIS whose telephone number is (571)270-7724. The examiner can normally be reached Monday - Thursday 7am-2pm.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
/LISA C LEWIS/Primary Examiner, Art Unit 2495
Prosecution Insights