DETAILED ACTION
1. Claims 1-11, 23-31 are pending in this examination.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
3. 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 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.
Allowable Subject Matter
4. Claims 5, 7-11, 27, 29 and 31 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
5. Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Claim Rejections - 35 USC § 103
6.1. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
4.2. Claims 1-4, 6, 23-26, 28, 30 are rejected under 35 U.S.C. 103 as being unpatentable over LTE: 5G; Security Aspects of Common API Framework for 3GPP Northbound APIs (3GPP TS 33.122 version 15.0.0 Release 15)” (IDS) (“LTE”), in view of US Patent Application No. 20210037007 to Gupta et al (“Gupta”), and in view of US Patent Application No. 20210144550 to ITO et al (“ITO”).
As per claim 1, LTE discloses an apparatus for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and operable to cause the apparatus to: send, to an application programming interface provider domain of the wireless network, the first request (Figure 6 .1-1: "API invoker");
receive a first response that includes comprises enrollment data comprising key data associated with the application programming interface framework core function (pages 8- 9, Figure 6.1-1: "1. Onboarding enrollment information [CCF (Address, Root CA Certificate), OAuth 2.0 Access token]"; PAGE 9: "l. As a prerequisite to the onboarding procedure, the API invoker obtains onboarding enrolment information from the API provider domain. The onboarding enrolment information is used to authenticate and establish a secure TLS communication with the CAPIF core function during the onboarding process. The enrolment information includes details of the CAPIF core function (Address, and Root CA certificate) and includes an onboarding credential (the OAuth 2.0 [4] access token)."; PAGE 9:"2. The API invoker and CAPIF core function shall establish a secure session based on TLS (Server side certificate authentication). The API invoker shall use the enrolment information obtained in step 1 to establish the TLS session with the CAPIF core function."; Figure 6.1-1 //Comment-1: The "Root CA certificate" of 01 corresponds to the "key data", disclosed as such in the claim. The Root CA certificate comprises at least the public key of the root certificate authority, wherein this certificate is then used at the subsequent step of establishing the TLS connection with the CAPFI core function, CCF. See, the above cited passages); and
store the enrollment data for use by one or more of the apparatus or an application related to the apparatus with the application programming interface framework core to enable the apparatus to invoke one or more application programming interfaces exposed by the application programming interface provider domain (Page 9: "1. As a prerequisite to the onboarding procedure, the API invoker obtains onboarding enrolment information from the API provider domain. The onboarding enrolment information is used to authenticate and establish a secure TLS communication with the CAPIF core function during the onboarding process. The enrolment information includes details of the CAPIF core function (Address, and Root CA certificate) and includes an onboarding credential (the OAuth 2.0 [4] access token)."; page 9:"2. The API invoker and CAPIF core function shall establish a secure session based on TLS (Server side certificate authentication). The API invoker shall use the enrolment information obtained in step 1 to establish the TLS session with the CAPIF core function."; page 10:"6. The CAPIF core function shall respond with an Onboard API invoker response message. The response shall include the CAPIF core function assigned API invoker ID, AEF Authentication and authorization information, API invoker's certificate and the API invoker Onboard Secret (if generated by the CAPIF core function)."; Figure 6.1-1). Furthermore, LTE discloses onboarding enrollment information" (LTE: Figure 6 .1-1) of LTE is obviously a response to an enrollment request. "onboarding enrollment information" is a response to an enrollment request disclosed as such the claim, where otherwise the "API provider domain" would not be aware that an API invoker wants to be enrolled and so wants to obtain "onboarding enrollment information" (also in LTE, the API provider domain is the first contacted entity for the API invoker; see Figure 6.1-1). Also, the "user equipment identifier" is obvious, where at least the MAC address of the user equipment (the API invoker) will be present in every data packet sent from the API invoker to the API provider domain, also see (Page 12, Figures 6.5.2.1-1, step 2-3 and step 5, step 6 in page 13),
LTE does not explicitly disclose however in the same field of endeavor, Gupta discloses generate a first request to an application programming interface framework core function of a wireless network, the first request comprising a user equipment (UE) identifier for the apparatus ([0081], [0090], [0114] At step 610, after successful verification of the on-boarding request, the CCF server 300
generates API invoker profile for each of the on-boarding device 100, wherein the API invoker profile comprising at least one of the API invoker ID (generate a new one or use the API invoker ID if present in the OAuth 2.0 access token or based on service agreement between the service provider 200 and the CCF server 300), the API invoker certificate, the list of accessible service APIs by the On-boarding device 100, and authentication and authorization information for the accessible service APIs (i.e., the selected method for AEF authentication and authorization, and an Onboard Secret ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of LTE with the teaching of Gupta by including the feature of identifier, in order for LTE’s system for secure on-boarding of application programming interface (API) invoker of on-boarding devices to a Common API Framework (CAPIF) Core function (CCF) server. Provided is an API invoker of performing an onboarding. The API invoker includes a transceiver and a processor coupled with the transceiver and configured to obtain, from a service provider, onboarding information including an onboarding credential and information of a CAPIF core function, establish a secure session with the CAPIF core function based on the onboarding information and control the transceiver to transmit, to the CAPIF core function, an onboard API invoker request message along with the onboarding credential and to receive an onboard API invoker response message based on a result of a validating the onboarding credential at the CAPIF core function (Gupta, abstract).
LTE and Gupta do not explicitly disclose however in the same field of endeavor, ITO disclose the enrollment data further comprises one or more of an application programming interface provider domain function identifier or an access token ([0101-[105], also see [0120], [0125], [0186]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of LTE with the teaching of Gupta/ITO by including the feature of enrollment data, in order for LTE’s system to validate the authenticity of offboarding invocation triggered by an API invoker. The present document proposes security procedures for 3GPP Common API Framework (CAPIF) to solve various security issues that can occur during various phases such as, (i) API invoker Onboarding, (ii) API invoker Offboarding, (iii) Service API publishing, (iv) Service API unpublishing, (v) Update service APIs, (vi) Service API discovery, (vii) API invoker obtaining authorization from CAPIF core function (CCF) to access service API, (viii) Authentication between API invoker and API exposing function (AEF) upon the service invocation, (ix) Retrieve service APIs, (x) CAPIF event subscription, (xi) CAPIF event unsubscription, and (xii) API invoker authorization to access service APIs. ()ITO, abstract)
As per claim 2, the combination of LTE, Gupta and ITO discloses the apparatus of claim 1, wherein the apparatus comprises one or more of a UE or a network apparatus that interfaces with the UE, and wherein the onboarding procedure is for onboarding an application programming interface invoker of the user equipment UE, the application programming interface invoker comprising one or more of the application residing on the UE, or an application function residing external to the UE (Gupta, [0160]). The motivation regarding the obviousness of claim 1 is also applied to claim 2.
LTE and Gupta do not explicitly disclose however in the same field of endeavor, ITO discloses the enrollment data is stored to perform an onboarding procedure (ITO, [0105], [0160], [0186]). The motivation regarding the obviousness of claim 1 is also applied to claim 2.
As per claim 3, the combination of LTE, Gupta and ITO discloses the apparatus of claim 1, wherein the first request comprises an access token request, and wherein the first request comprises one or more of an application identifier for an additional application that resides on the apparatus, an application function identifier for the additional application, an identifier for an application function external to the apparatus, or user consent information indicating user consent to onboard with the application programming interface framework core function (Gupta, [0117], [0130]-[0134]). The motivation regarding the obviousness of claim 1 is also applied to claim 3.
As per claim 4, the combination of LTE, Gupta and ITO discloses the apparatus
of claim 1, wherein the UE identifier for the apparatus comprises one or more of a generic public subscription identifier for the apparatus, a UE internet protocols address for the apparatus, an ethernet address for the apparatus, an external group identifier for the apparatus, or an application programming interface framework apparatus identifier for the apparatus (Gupta, [0090], [0097], [0108]). The motivation regarding the obviousness of claim 1 is also applied to claim 4.
As per claim 6, the combination of LTE, Gupta and ITO discloses the apparatus of claim 1, wherein the key data comprises one or more of an application programming interface framework core function key, an application programming interface framework core function key identifier, or an application programming interface exposing function key (LTE, pages12-13 Figure 6.5.2.1-1, step 6 & Pages 12, step 6).
Claim 23 is rejected for similar reasons as stated above.
Claim 24 is rejected for similar reasons as stated above.
Claim 25 is rejected for similar reasons as stated above.
Claim 26 is rejected for similar reasons as stated above.
Claim 28 is rejected for similar reasons as stated above.
Claim 30 is rejected for similar reasons as stated above.
7.1. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure as the prior art discloses many of the claim features (See PTO-form 892).
7.2. a). US Patent Application No. 20230113108 to Tao et al., discloses methods and apparatuses for network capability exposure. A method at a network exposure entity comprises receiving, from a terminal device, a network exposure application programming interface (API) invocation message. The method further comprises validating whether the terminal device is allowed to use the invocated network exposure API. The method further comprises processing the network exposure API invocation message based on the validating result.
b). US Patent Application No. 20220174585 to Ge et al., discloses embodiments of this application disclose an information obtaining method that may be applied to the multi-access edge computing MEC field, for example, a vehicle to everything scenario of MCE or an internet of things scenario of the MEC. The method in the embodiments of this application includes: A first server receives information about a first instance of an application and information about a second instance of the application from a second server and a third server respectively, and then the first server stores the information about the first instance and the information about the second instance. In this way, the first server can centrally maintain information about different instances of the application, so that another device can directly obtain the information about the application instances from the first server.
Conclusion
8. 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 HARUNUR RASHID whose telephone number is (571)270-7195. The examiner can normally be reached 9 AM to 5PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
HARUNUR . RASHID
Primary Examiner
Art Unit 2497
/HARUNUR RASHID/Primary Examiner, Art Unit 2497
Prosecution Insights