DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
2. 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.
3. 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.
4. 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.
5. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
6. Claims 1, 3, 4, 9 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Dao (US 2025/0056324 A1, hereinafter “Dao”) in view of Long (US 2021/0112514 A1)
Regarding claim 1, Dao teaches an apparatus configured to operate as a Data Control Function (DCF) in a 6th generation system (6GS) (figs. 5-9A, ¶ [0233], ¶ [0071], ¶ [0009], service provider function (SPF)), the apparatus comprising: processing circuitry (figs. 5, 10, ¶ [0028]) to configure the DCF in the 6GS to: receive a data registration request from a user equipment (UE) (service request or subscription from ED 901 in fig. 9A, fig. 8A, ¶ [0127], the ED 801 can request a data analytic service such as a service to obtain real-time vehicle and non-vehicle traffic density updates. ¶ [0234], ¶ [0128], In some aspects, the ED 801 can be a device in an autonomous vehicle, The service request or service subscription can include one or more of the following information: an ED ID, an ED location, an Application ID, a Service ID, a Destination information, a Data Network Name (DNN), a Network slice ID, a location of the requested service, and data to be analyzed by the mobile network service. ¶ [0129], ¶ [0187]-¶ [0189], ¶ [0190], ¶ [0015]); and send a data registration response to the UE to indicate whether the data registration request is accepted (service response or notification in fig. 9A, fig. 8A, ¶ [0196]-¶ [0199]-¶ [0205], [0209] At step 924, the EAIF 903 can receive the Service Response or Service Notification sent from the SPF 909 and forward the message to the ED 901. ¶ [0211], ¶ [0212]).
Dao does not explicitly teach allocate a data identifier (ID) in response to reception of the data registration request, the data registration response including the data ID: and a memory configured to store the data ID.
Long teaches a well-known method of allocating an ID in response to reception of the registration request; including the ID in the registration response, and storing the ID ( ¶ [0049], the UDM responds with “201 Created” with a message body containing a URI of the created subscription. ¶ [0050], the NF service consumer sends a DELETE request to the resource identified by the URI previously received during the subscription creation (i.e., the URI previously received). Where it is implicit that the previously received URI is stored in a memory. ¶ [0070]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to include an allocated data ID in the data registration response, and to store the received data ID in the system of Dao to identify the data registration/subscription.
Regarding claim 17, Dao teaches an apparatus configured to operate as a user equipment (UE) (figs. 5-9A, ¶ [0116], when an application in an ED 740 wants to access a service provided by the mobile network, the application can generate and send a service request or a service subscription message. ¶ [0128], In some aspects, the ED 801 can be a device in an autonomous vehicle), the apparatus comprising: processing circuitry (fig. 10, ¶ [0028], ¶ [0234]-¶ [0236]) to configure UE to: send a data registration request to a Data Control Function (DCF) in a 6th generation system (6GS) (figs. 5-9A, ¶ [0233], ¶ [0071], service request or subscription from ED 901 in fig. 9A, fig. 8A, ¶ [0127], the ED 801 can request a data analytic service such as a service to obtain real-time vehicle and non-vehicle traffic density updates. ¶ [0128], The service request or service subscription can include one or more of the following information: an ED ID, an ED location, an Application ID, a Service ID, a Destination information, a Data Network Name (DNN), a Network slice ID, a location of the requested service, and data to be analyzed by the mobile network service. ¶ [0129], ¶ [0187]-¶ [0189], ¶ [0190], ¶ [0015]); receive, in response to reception of the data registration request by the DCF, a data registration response from the DCF to indicate whether the data registration request is accepted (service response or notification in fig. 9A, fig. 8A, ¶ [0196]-¶ [0199]-¶ [0205], [0209] At step 924, the EAIF 903 can receive the Service Response or Service Notification sent from the SPF 909 and forward the message to the ED 901. ¶ [0211], ¶ [0212]); receive a data collection information message from the DCF; and send, in response to reception of the data collection information message, a data collection accept message to the DCF that indicates whether the data collection information message is accepted (Dao: fig. 6A, ¶ [0100], ¶ [0102], if the ED ID is provided in the data request or subscription message, the AN DFG 640 can send the data request or subscription message to the ED via an EAIF. ¶ [0103], the AN DGF 640 may request the ED to collect the sensing data. ¶ [0105] At step 616, the AN DGF 640 can send a data response or notification including the collected data to the DPF 644 directly, or via one or more of the AN NCIF 660 and the CN NCIF 662).
Dao does not explicitly teach at least one of the data registration response or the data collection information message including a data identifier (ID) allocated by the DCF to identity data for transfer between the UE and a Data Storage Function (DSF) in the 6GS; and a memory configured to store the data ID.
Long teaches a well-known method of allocating an ID in response to reception of the registration request; including the ID in the registration response, and storing the ID (¶ [0049], the UDM responds with “201 Created” with a message body containing a URI of the created subscription. ¶ [0050], the NF service consumer sends a DELETE request to the resource identified by the URI previously received during the subscription creation (i.e., the URI previously received). Where it is implicit that the previously received URI is stored in a memory. ¶ [0070]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to include an allocated data ID in the data registration response, and to store the received data ID in the system of Dao to identify the data registration/subscription.
Regarding claim 19, Dao teaches a non-transitory computer-readable storage medium (figs. 5, 10, ¶ [0027], ¶ [0236]) that stores instructions for execution by one or more processors of a Data Control Function (DCF) in a 6th generation system (6GS) (figs. 5-9A, ¶ [0233], ¶ [0071], ¶ [0009], service provider function (SPF)), the one or more processors to configure the DCF to, when the instructions are executed: receive a data registration request from a user equipment (UE) (service request or subscription from ED 901 in fig. 9A, fig. 8A, ¶ [0127], the ED 801 can request a data analytic service such as a service to obtain real-time vehicle and non-vehicle traffic density updates. ¶ [0234], ¶ [0128], In some aspects, the ED 801 can be a device in an autonomous vehicle, The service request or service subscription can include one or more of the following information: an ED ID, an ED location, an Application ID, a Service ID, a Destination information, a Data Network Name (DNN), a Network slice ID, a location of the requested service, and data to be analyzed by the mobile network service. ¶ [0129], ¶ [0187]-¶ [0189], ¶ [0190], ¶ [0015]); and send a data registration response to the UE to indicate whether the data registration request is accepted (service response or notification in fig. 9A, fig. 8A, ¶ [0196]-¶ [0199]-¶ [0205], [0209] At step 924, the EAIF 903 can receive the Service Response or Service Notification sent from the SPF 909 and forward the message to the ED 901. ¶ [0211], ¶ [0212]).
Dao does not explicitly teach allocate a data identifier (ID) in response to reception of the data registration request, and the data registration response including the data ID.
Long teaches a well-known method of allocating an ID in response to reception of the registration request; including the ID in the registration response, and storing the ID (¶ [0049], the UDM responds with “201 Created” with a message body containing a URI of the created subscription. ¶ [0050], the NF service consumer sends a DELETE request to the resource identified by the URI previously received during the subscription creation (i.e., the URI previously received). Where it is implicit that the previously received URI is stored in a memory. ¶ [0070]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to include an allocated data ID in the data registration response, and to store the received data ID in the system of Dao to identify the data registration/subscription.
Regarding claim 3, Dao in view of Long teaches the apparatus of claim 1, wherein the processing circuitry further configures the DCF to check UE context and metadata through verification with an Access and Mobility Function (AMF), a Security Anchor Function (SEAF), or a Data Verification and Security Function (DVSF) (Dao: figs. 8A, 9A, ¶ [0148], ¶ [0198], The SPF 909 can send a message, e.g., a Service Authorization Request, to an Authorization Function such as Service Authorization Function 911. ¶ [0199], the Service Authorization Function 911 may have an ED Context or ED 901 profile which indicates the services the ED 901 may access. The Authorization Function, e.g., Service Authorization Function 911, can use the information provided in the message from the SPF 909 at step 910 and the ED Context to determine if ED 901 is authorized to use the service).
Regarding claim 4, Dao in view of Long teaches the apparatus of claim 1, wherein the processing circuitry further configures the DCF to select a Data Storage Function (DSF) in response to a determination that the UE is allowed to send data to the DSF (Dao: figs. 5, 6, ¶ [0109], ¶ [0113], the DCF 642 can send the processed sensing data and the derived analytics data to a data storage function 664. At step 630, the data storage function 664 may send a response message to the DCF 642 to acknowledge the received message at step 628. ¶ [0099], ¶ [0100]).
Regarding claim 9, Dao in view of Long teaches the apparatus of claim 1, wherein the processing circuitry further configures the DCF to: send a data collection information message to the UE; and receive, in response to reception of the data collection information message by the UE, a data collection accept message from the UE that indicates whether the data collection information message is accepted by the UE (Dao: fig. 6A, ¶ [0100], ¶ [0102], if the ED ID is provided in the data request or subscription message, the AN DFG 640 can send the data request or subscription message to the ED via an EAIF. ¶ [0103], the AN DGF 640 may request the ED to collect the sensing data. ¶ [0105] At step 616, the AN DGF 640 can send a data response or notification including the collected data to the DPF 644 directly, or via one or more of the AN NCIF 660 and the CN NCIF 662).
Regarding claim 18, Dao in view of Long teaches the apparatus of claim 17, wherein the processing circuitry further configures the UE to: transfer data with the DSF using at least one of a control plane or a user plane: to transfer the data using the control plane, send the data directly to the DCF to forward to the DSF; and to transfer the data using the user plane, e(stablish at least one of a data session that is independent of a protocol data unit (PDU) session between the UE and the DSF, or a PDU session managed by a Communication Control (Comm CF) or session management function (SMF) (fig. 5, 6, ¶ [0088], ¶ [0109], At step 622, the DPF 644 can receive some or all of the collected sensing data from one or more of: AN, AN DGF 640, AN NCIF 660, CN NCIF 662. The DPF 644 can store, in a data storage function, the collected data received at 620. The DPF can also store the processed data to the data storage function).
7. Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Dao in view of Long as applied to claim 1 above, and further in view of Li et al. (US 2020/0137577 A1, hereinafter “Li”).
Regarding claim 2, Dao in view of Long teaches the apparatus of claim 1, wherein: the data registration request includes metadata for data registration (Dao: figs. 8A, 9A, ¶ [0129]).
Dao does not explicitly teach the processing circuitry further configures the DCF to receive the data registration request via a non-access stratum (NAS) container, a distributed NAS, a Hypertext Transfer Protocol (HTTP) using a service-based interface (SBI) N2 interface or radio resource control (RRC) message via a Central Unit for Control Plane (CU-CP), and the data registration request includes metadata for data registration and security keys for authentication.
Li teaches receive a registration request via a non-access stratum (NAS) container, a distributed NAS, a HTTP using a SBI N2 interface or RRC message via a CU-CP, and the registration request includes metadata for registration and security keys for authentication (¶ [0089], a registration request message may be placed in a NAS container, and the base key (Kan) and a security capability of the terminal device may be placed in the NAS container or may be placed outside the NAS container).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, receive the data registration request, including metadata for data registration and security keys for authentication via a NAS container, a distributed NAS, a HTTP using a SBI N2 interface or RRC message via a CU-CP in the system of Dao in view of Long to further improve industrial applicability.
8. Claims 5, 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Dao in view of Long as applied to claim 1 above, and further in view of Martinez de la Cruz et al. (US 2023/0006895 A1, hereinafter “Martinez”).
Regarding claim 5, Dao in view of Long teaches the apparatus of claim 4.
Dao does not explicitly teach wherein the processing circuitry further configures the DCF to select the DSF based on at least one of data type, location, security requirements, or Single Network Slice Selection Assistance Information (S-NSSAI).
Martinez teaches select a network function based on at least one of data type, location, security requirements, or S-NSSAI (¶ [0050] S106: The Network Repository Function 200 identifies, out of the service-providing NFs 400, at least that service-providing NF 400 which has a locality attribute that best matches the preferred locality. ¶ [0059]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to select the DSF based on at least one of data type, location, security requirements, or S-NSSAI in the system of Dao in view of Long to minimize the latency of the future communications (¶ [0023] of Martinez).
Regarding claim 15, Dao in view of Long teaches the apparatus of claim 1.
Dao does not explicitly teach wherein the processing circuitry further configures the DCF to: receive, from a Service Orchestration and Chaining Function (SOCF), a data Service request that includes a data filter, the data filter containing at least one of the data ID, data service, or metadata: and in response to reception of the data service request, look up at least one of data in a data registry using the data filter or the data service in a service registry using a Service Registration Function (SRF).
Martinez teaches receive, from a network function, a data Service request that includes a data filter, the data filter containing at least one of the data ID, data service, or metadata: and in response to reception of the data service request, look up at least one of data in a data registry using the data filter or the data service in a service registry using a SRF (¶ [0049], The Network Repository Function 200 obtains a request from a service-requesting NF 300 for one of the service-providing NFs 400. The request specifies a preferred locality of the requested service-providing NF 400. ¶ [0050], The Network Repository Function 200 identifies, out of the service-providing NFs 400, at least that service-providing NF 400 which has a locality attribute that best matches the preferred locality).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to receive, from a SOCF, a data Service request that includes a data filter, the data filter containing at least one of the data ID, data service, or metadata: and look up at least one of data in a data registry using the data filter or the data service in a service registry using a SRF in response to reception of the data service request in the system of Dao in view of Long to minimize the latency of the future communications (¶ [0023] of Martinez).
Regarding claim 16, Dao in view of Long and Martinez teaches the apparatus of clam 15.
Dao does not explicitly teach wherein the processing circuitry further configures the DCF to: select a Data Storage Function (DSF) for the data service or data storage, and send a data service response to the SOCF, the data service response including a DSF identifier of the DSF.
Martinez teaches wherein the processing circuitry further configures the DCF to: select a network function for the data service or data storage, and send a data service response to the requesting network function, the data service response including a network function identifier of the DSF (¶ [0051], The Network Repository Function 200 returns the registered locality of each identified service-providing NF 400. Hence, the Network Repository Function 200 is configured to perform action S108. ¶ [0087]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to select a DSF for the data service or data storage, and send a data service response, including a DSF identifier of the DSF, to the SOCF, the data service response in the system of Dao in view of Long and Martinez to minimize the latency of the future communications (¶ [0023] of Martinez).
Allowable Subject Matter
9. Claims 6-8, 10-14 and 20 are 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.
10. The following is a statement of reasons for the indication of allowable subject matter:
Regarding claims 6-8, prior art of record fails to teach or fairly suggest “wherein the processing circuitry further configures the DCF to configure the DSF with the data ID, UE context, data labels, metadata, and policy of storing data from the UE” in combination with the limitations specified in the base claim and the intervening claim(s).
Regarding claim 10, prior art of record fails to teach or fairly suggest “wherein: the data collection information message includes data metadata, a data collection policy, the data ID, and a selected Data Storage Function (DSF) identifier, and the data collection policy and parameters for data transfer are stored in the UE, and the data collection policy includes collection frequency” in combination with the limitations specified in the base claim and the intervening claim(s).
Regarding claim 11, prior art of record fails to teach or fairly suggest “wherein the processing circuitry further configures the DCF to: select a Data Storage Function (DSF) in response to a determination that the UE is allowed to send data to the DSF; and configure the DSF with the data ID, UE context, data labels, metadata, and policy of storing data from the UE” in combination with the limitations specified in the base claim and the intervening claim(s).
Regarding claims 12 and 13, prior art of record fails to teach or fairly suggest “wherein the processing circuitry further configures the DCF to: receive, from a next generation NodeB (xNB), a data session establishment request from the UE to establish a data session, the data session establishment request including the data ID, data labels and Data Storage Function (DSF) identifiers, and security keys for data; and in response to reception of the data session establishment request, send a data session establishment response to the UE vie the xNB, the data session establishment response indicating whether the data session is established successfully” in combination with the limitations specified in the base claim.
Regarding claim 14, prior art of record fails to teach or fairly suggest “wherein the processing circuitry further configures the DCF to: receive, from a Service Orchestration and Chaining Function (SOCF), a data verification request, the data verification request based on a data session establishment request sent to the SOCF from the UE via a next generation NodeB (xNB) to establish a data session, the data session establishment request including the data ID, data labeling and Data Storage Function (DSF) identifiers, and security keys for data; and in response to reception of the data verification request, verify data information for the SOCF to send a data session establishment response to the UE via the xNB, the data session establishment response indicating whether the data session is established successfully” in combination with the limitations specified in the base claim.
Regarding claim 20, prior art of record fails to teach or fairly suggest “wherein the one or more processors farther configure the DCF to: select a Data Storage Function (DSF) in response to a determination that the UE is allowed to send data to the DSF; configure the DSF with the data ID, UE context, data labels, metadata, and policy of storing data from the UE; after configuration of the DSF, send a data collection information message to the UE; and receive, in response to reception of the data collection information message by the UE, a data collection accept message from the UE that indicates whether the data collection information message is accepted by the UE” in combination with the limitations specified in the base claim.
Conclusion
11. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MANDISH RANDHAWA whose telephone number is (571)270-5650. The examiner can normally be reached Monday-Thursday (9 AM-7 PM).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chirag Shah can be reached at 571-272-3144. 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.
/MANDISH K RANDHAWA/Primary Examiner, Art Unit 2477
Prosecution Insights