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 .
This Office Action is in response to application 18/397,605 filed on 12/27/2023.
Claims 1-14 have been examined and are pending in this application.
The examiner notes the IDS filed on 12/27/2023 has been considered.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a memory unit configured to store”, “an interface unit configured to accept”, “a first control unit configured to acquire”, “a second control unit configured to acquire” found in Claim 1, “the second control unit is configured to transmit” found in Claim 2; “a server-side memory unit configured to store”, “a server-side authorization unit configure to determine”, “a vehicle-side memory unit configured to store”, “ a vehicle-side authorization unit configured to determine”, found in Claim 3; “a vehicle-side memory unit configured to store”, “ a vehicle-side authorization unit configured to determine” found in Claim 4; “a memory unit configured to store”, “an interface unit configured to receive”, “a first control unit configured to acquire”, “a second control unit configured to acquire” found in Claim 6; “an authorization information memory unit configure to store”, “an authorization unit configured to reject” found in Claim 7; “the first control unit is configured to extract” found in Claim 8; “the first control unit configured extract” found in claim 9 and 10; “an encryption information generation unit configured to generate”, and “an encryption unit configured to encrypt” found in Claim 11.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 102
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 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-7 and 12-14 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Katta et al. (US 2017/0161973 A1).
Regarding Claim 1;
Katta discloses a mobility service providing system (FIG. 2 - client system (e.g., third party application) ↔ system ↔ vehicle and [0015] and [0031]) comprising:
an in-vehicle device mounted on a vehicle and configured to collect vehicle data that is data acquired from the vehicle (FIG. 2 - vehicle and [0031] - The vehicle can include any one or more of: a processing system, communications system, sensor set (e.g., motion sensors, location sensors, fuel sensors, proximity sensors, optical sensors, oxygen sensors, etc.), and/or any other suitable component and [0032] and [0042] - Vehicle data preferably includes vehicle outputs, such as sensor measurements and/or the component operation states (e.g., instantaneous, past, or future), but can additionally or alternatively include any other suitable vehicle data. The vehicle data can be timestamped (e.g., with the time of data generation, with the time of data transmission, etc.) or time agnostic);
a mobility service providing server configured to perform wireless communication with the in-vehicle device (FIG. 2 – system ↔ vehicle and [0039] - The system and/or portions of the system (e.g., authorization subsystem, management subsystem, API subsystem, etc.) can entirely or partially be executed by, hosted on, communicate with, and/or otherwise include one or more of: a remote system (e.g., a remote server, at least one networked computing system such as servers, dynamically expandable and/or contractable networked servers for accommodating volume changes of vehicle requests and/or resource queries, stateless, stateful, etc.), a local computing system, an OEM platform (e.g., for receiving, storing, and transmitting vehicle data), a vehicle, a client system, a user device, databases (e.g., client databases of a client system, vehicle resources, etc.), and/or by any suitable component),
wherein
the in-vehicle device is configured to repeatedly and spontaneously transmit the vehicle data to the mobility service providing server (FIG. 1 – system ↔ vehicle and [0042] - Vehicle data preferably includes vehicle outputs, such as sensor measurements and/or the component operation states (e.g., instantaneous, past, or future), but can additionally or alternatively include any other suitable vehicle data [0050] - The parameter values can be determined in response to receipt of the vehicle request, in response to verification of the vehicle request, at a predetermined frequency (e.g., independent of responding to a vehicle request), and/or at any other suitable time), and transmits the vehicle data to the mobility service providing server in response to a request from the mobility service providing server ([0015]-[0016] - verifying the vehicle request S120; determining a parameter value for the vehicle parameter S130; and fulfilling the vehicle request with the parameter value S140.... and [0050]-[0051] - The parameter values can be determined in response to receipt of the vehicle request, in response to verification of the vehicle request... Retrieving vehicle data from the vehicle resource (e.g., vehicle, OEM platform, etc.) S131 functions to obtain vehicle data (e.g., in a pull paradigm) associated with the requested vehicle parameters), and
the mobility service providing server (FIG. 2 – system [0039]) includes
a memory unit configured to store the vehicle data for each predetermined time point acquired from the in-vehicle device by the wireless communication (FIG. 2 – system and [0037] - The API subsystem preferably stores the vehicle data (e.g., in raw or processed form) and [0042] - Vehicle data preferably includes vehicle outputs, such as sensor measurements and/or the component operation states (e.g., instantaneous, past, or future), but can additionally or alternatively include any other suitable vehicle data. The vehicle data can be timestamped (e.g., with the time of data generation, with the time of data transmission, etc.) or time agnostic and [0055] - ... determining parameter values can include obtaining vehicle data and/or other suitable data from the API subsystem (e.g., storing historic, current and/or predicted vehicle data)),
an interface unit configured to accept a first access request and a second access request from an outside (FIG. 2 - client system (e.g., third party application) ↔ system and [0023] - First, the technology can provide an inventive distribution of functionality across a network. For example, the technology can connect vehicles, OEM platforms, third party applications, and user devices in a network facilitating customization of communication between parties in the network. For example, improvements in computer-related technology can be conferred from, for example, customizable privacy settings for vehicle data associated with different user accounts, customizable permission settings for different third party applications to access vehicle data and/or vehicle controls, customizable request rules for fulfilling data retrieval preferences of third party applications and sharing preferences of users and OEM platforms, and/or other modifiable features. and [0032] - The system functions to enable third party access to vehicle data (e.g., sampled at sensors of the vehicle) and/or vehicle controls and [0035] and [0038]),
a first control unit configured to acquire the vehicle data from the memory unit and provide the vehicle data to a request source via the interface unit when the interface unit receives the first access request ([0023] - customizable permission settings for different third party applications to access vehicle data and [0033] and [0036] - However, the API subsystem can perform any other suitable functionality. The API subsystem is preferably a REST server (e.g., a stateless server), but can alternatively be a state server or have any other suitable configuration. In operation, the API subsystem can receive requests from the third party, redirect requests to the authorization subsystem, generate operating instructions for itself (e.g., call requests, routing requests, state change requests), generate requests for the vehicle resource (e.g., call requests, routing requests, state change requests), receive vehicle data from the vehicle resource, and/or forward vehicle data to the third party application and [0037] - In one variation of API subsystem operation, the API subsystem receives a request from the third party application including a resource request and an access token (e.g., a system access token), and, in response to verification of the access token (e.g., received from the authorization subsystem), sends the requested resource to the third party application and [0050] - The parameter values can be determined in response to receipt of the vehicle request, in response to verification of the vehicle request, at a predetermined frequency (e.g., independent of responding to a vehicle request), and/or at any other suitable time and [0057] - vehicle data can be regularly pushed (e.g., at predetermined time intervals), and
a second control unit configured to acquire an access result including the vehicle data from the in-vehicle device by accessing the in-vehicle device and provide the access result to a request source via the interface unit when the interface unit receives the second access request ([0023] - customizable permission settings for different third party applications to access vehicle data and [0033] and [0036] - In one example of system use, a request from a third party application is routed through the API subsystem and routed to the appropriate adapter module for the vehicle endpoint, where the respective adapter module communicates the request (and/or receives information) from the vehicle resource and [0049] - As shown in FIG. 6B, determining parameter values can additionally or alternatively include retrieving vehicle data from the vehicle resource S131 (e.g., in a pull paradigm); receiving vehicle data from the vehicle resource S135 (e.g., in a push paradigm), and/or any other suitable process and [0050] - The parameter values can be determined in response to receipt of the vehicle request, in response to verification of the vehicle request, at a predetermined frequency (e.g., independent of responding to a vehicle request), and/or at any other suitable time and [0057] - vehicle data can be pulled in response to vehicle requests).
Regarding Claim 2;
Katta discloses the mobility service providing system according to claim 1.
Katta further discloses wherein the second control unit is configured to transmit vehicle authentication information assigned in advance to the in-vehicle device together with an acquisition request to be transmitted to the in-vehicle device in order to acquire the vehicle data from the in-vehicle device (FIG. 1 – system ↔ vehicle and [0031] - The vehicle is preferably configured to sample values for vehicle parameters at the sensor set at any given time; receive resource queries (e.g., from a remote system, from an OEM platform, etc.); verify resource access tokens (e.g., included in a resource query); transmit sampled values (e.g., to a remote system, to an OEM platform); and/or perform any suitable operation and [0034] and [0036] and [0051] - For example, the resource query can include a resource access token stored in association with the user identifier, the resource access token granting access to the first vehicle resource. In another example, resource access tokens included in a resource query can be received from the requesting party (e.g., in the vehicle request, along with the system access token) and [0054] - Such system access tokens can be generated by the system and distributed to vehicle resources and/or any suitable entity transmitting vehicle data to the system), and the in-vehicle device is configured to transmit the vehicle data requested by the acquisition request to the mobility service providing server when authentication by on the vehicle authentication information is successful ([0031] - The vehicle is preferably configured to sample values for vehicle parameters at the sensor set at any given time; receive resource queries (e.g., from a remote system, from an OEM platform, etc.); verify resource access tokens (e.g., included in a resource query); transmit sampled values (e.g., to a remote system, to an OEM platform); and/or perform any suitable operation and [0034] and [0036] and [0051] and [0054]).
Regarding Claim 3;
Katta discloses the mobility service providing system according to claim 1.
Katta further discloses further comprising:
a server-side memory unit configured to store, for each provider of a mobility service using the mobility service providing server, per-service authorization information that defines an accessible range by the second access request (FIG. 2 – system and [0023] - For example, improvements in computer-related technology can be conferred from, for example, customizable privacy settings for vehicle data associated with different user accounts, customizable permission settings for different third party applications to access vehicle data and [0034] - The authorization subsystem functions to store user account information, such as vehicle identifiers that are associated with each user account, vehicle parameter permission settings (e.g., which vehicle parameters are available to third parties, on a per-vehicle basis), user profiles, user preferences, user credentials (e.g., login information to the system, to a third party application, to an OEM platform, etc.), OEM platform identifiers associated with each user account, and/or other user account information. The authorization subsystem can additionally or alternatively generate, store, and/or transmit any one or more of: third party information, such as authentication codes, access tokens, vehicle permission settings, user account permission settings, vehicle parameter permission settings (e.g., which vehicle parameters the third party has requested or has access to), query rate limits, and/or other third party account information. However, the authorization subsystem can be configured in any suitable manner); and
a server-side authorization unit configured to, when receiving the second access request, refer to the per-service authorization information to determine whether a provider of the mobility service has an access authority to access a target vehicle that is a vehicle to be accessed indicated in the second access request ([0034]-[0035] and [0044] - Verifying a vehicle request can be performed by a remote system (e.g., authorization subsystem, API subsystem) and/or any other suitable system component. Verifying a vehicle request is preferably in response to receipt of the vehicle request, but can additionally or alternatively be verified at any suitable time (e.g., in response to receiving a set of vehicle requests and/or based on a request scheduling rule, etc.). Verifying a vehicle request preferably includes mapping the vehicle request to a stored user identifier (e.g., in association with a vehicle identifier, access tokens, vehicle data, etc., which can be retrieved based on the user identifier), such as based on an endpoint identifier included in the vehicle request. Additionally or alternatively, the vehicle request can be mapped to and/or associated with any suitable identifier and/or other system information.), and, when it is determined that the provider of the mobility service has the access authority ([0034]-[0035] and [0044] and [0046]-[0047]), authorize access to the in-vehicle device mounted on the target vehicle ([0034]-[0035] and [0044] and [0046]-[0047),
wherein
the in-vehicle device further includes
a vehicle-side memory unit configured to store, for each vehicle user who is likely to request access to the target vehicle, per-user authorization information that defines a range accessible by the second access request (FIG. 2 and system ↔ vehicle and [0031] - The vehicle is preferably configured to sample values for vehicle parameters at the sensor set at any given time; receive resource queries (e.g., from a remote system, from an OEM platform, etc.); verify resource access tokens (e.g., included in a resource query); transmit sampled values (e.g., to a remote system, to an OEM platform); and/or perform any suitable operation and [0034] - The authorization subsystem can additionally or alternatively generate, store, and/or transmit any one or more of: third party information, such as authentication codes, access tokens, vehicle permission settings, user account permission settings, vehicle parameter permission settings (e.g., which vehicle parameters the third party has requested or has access to), query rate limits, and/or other third party account information. However, the authorization subsystem can be configured in any suitable manner and [0054] - Such system access tokens can be generated by the system and distributed to vehicle resources and/or any suitable entity transmitting vehicle data to the system), and
a vehicle-side authorization unit configured to determine, when receiving the second access request from the mobility service providing server, whether a vehicle user who has requested the second access request has the access authority to an access target indicated in the second access request with reference to the per-user authorization information, and authorize, when it is determined that the vehicle user has the access authority, access to the access target ([0031] - The vehicle is preferably configured to sample values for vehicle parameters at the sensor set at any given time; receive resource queries (e.g., from a remote system, from an OEM platform, etc.); verify resource access tokens (e.g., included in a resource query); transmit sampled values (e.g., to a remote system, to an OEM platform); and/or perform any suitable operation and [0034] and [0036] and [0051] and [0054]).
Regarding Claim 4;
Katta discloses the mobility service providing system according to claim 1.
Katta further discloses further comprising wherein the in-vehicle device further includes
a vehicle-side memory unit configured to store, for each vehicle user who is likely to request access to a target vehicle that is a vehicle to be accessed indicated in the second access request, per-user authorization information defining a range that is allowed to be accessed by the second access request ([0017] - ... verifying the access token with the third party application for the vehicle identifier; if the third party application access is verified, granting the third party application access to the vehicle and/or data of the vehicle identified by the vehicle identifier until a variable limit rule is met (e.g., a request limit, a time limit, etc. and [0031] - The vehicle is preferably configured to sample values for vehicle parameters at the sensor set at any given time; receive resource queries (e.g., from a remote system, from an OEM platform, etc.); verify resource access tokens (e.g., included in a resource query); transmit sampled values (e.g., to a remote system, to an OEM platform); and/or perform any suitable operation [0031] - The vehicle is preferably configured to sample values for vehicle parameters at the sensor set at any given time; receive resource queries (e.g., from a remote system, from an OEM platform, etc.); verify resource access tokens (e.g., included in a resource query); transmit sampled values (e.g., to a remote system, to an OEM platform); and/or perform any suitable operation and [0034] - The authorization subsystem can additionally or alternatively generate, store, and/or transmit any one or more of: third party information, such as authentication codes, access tokens, vehicle permission settings, user account permission settings, vehicle parameter permission settings (e.g., which vehicle parameters the third party has requested or has access to), query rate limits, and/or other third party account information. However, the authorization subsystem can be configured in any suitable manner and [0036] and [0051] and [0054]), and
a vehicle-side authorization unit configured to determine, when receiving the second access request from the mobility service providing server, whether a vehicle user who has requested the second access request has an access authority to an access target indicated in the second access request with reference to the per-user authorization information, and authorize, when it is determined that the vehicle user has the access authority, access to the access target ([0017] and [0031] - The vehicle is preferably configured to sample values for vehicle parameters at the sensor set at any given time; receive resource queries (e.g., from a remote system, from an OEM platform, etc.); verify resource access tokens (e.g., included in a resource query); transmit sampled values (e.g., to a remote system, to an OEM platform); and/or perform any suitable operation and [0034] and [0036] and [0045] and [0051] and [0054])..
Regarding Claim 5;
Katta discloses the mobility service providing system according to claim 1.
Katta further discloses further wherein the vehicle data transmitted by the in-vehicle device includes processed data obtained by processing raw data acquired from the vehicle ([0037] - The API subsystem preferably stores the vehicle data (e.g., in raw or processed form)), and the vehicle data transmitted by the in-vehicle device in response to a request from the mobility service providing server includes the raw data before being processed ([0037] and [0041] and [0050] - The raw information and/or auxiliary information can be processed according to instructions received from the client system (e.g., in a vehicle request by the third party application), based on request rules (e.g., associated with the endpoint identifier identified in the vehicle request), based on instructions associated with a requested vehicle parameter, and/or otherwise processed. However, raw information, auxiliary information (e.g., from auxiliary sources, such as weather sources, social media sources, etc.), and/or any other values regarding requested vehicle parameters can be determined and/or returned to the requesting party).
Regarding Claim 6;
Katta discloses a mobility service providing system (FIG. 2 - client system (e.g., third party application) ↔ system ↔ vehicle and [0015] – and [0031]) comprising:
a memory unit configured to store vehicle data provided from an in-vehicle device mounted on a vehicle (FIG. 2 – system and [0037] - The API subsystem preferably stores the vehicle data (e.g., in raw or processed form) and [0042] - Vehicle data preferably includes vehicle outputs, such as sensor measurements and/or the component operation states (e.g., instantaneous, past, or future), but can additionally or alternatively include any other suitable vehicle data. The vehicle data can be timestamped (e.g., with the time of data generation, with the time of data transmission, etc.) or time agnostic and [0055] - ... determining parameter values can include obtaining vehicle data and/or other suitable data from the API subsystem (e.g., storing historic, current and/or predicted vehicle data));
an interface unit configured to accept a first access request and a second access request from an outside (FIG. 2 - client system (e.g., third party application) ↔ system and [0023] - First, the technology can provide an inventive distribution of functionality across a network. For example, the technology can connect vehicles, OEM platforms, third party applications, and user devices in a network facilitating customization of communication between parties in the network. For example, improvements in computer-related technology can be conferred from, for example, customizable privacy settings for vehicle data associated with different user accounts, customizable permission settings for different third party applications to access vehicle data and/or vehicle controls, customizable request rules for fulfilling data retrieval preferences of third party applications and sharing preferences of users and OEM platforms, and/or other modifiable features. and [0032] - The system functions to enable third party access to vehicle data (e.g., sampled at sensors of the vehicle) and/or vehicle controls and [0035] - and [0038]);
a first control unit configured to acquire the vehicle data from the memory unit and provide the vehicle data to a request source via the interface unit when the interface unit receives the first access request ([0023] - customizable permission settings for different third party applications to access vehicle data and [0033] and [0036] - However, the API subsystem can perform any other suitable functionality. The API subsystem is preferably a REST server (e.g., a stateless server), but can alternatively be a state server or have any other suitable configuration. In operation, the API subsystem can receive requests from the third party, redirect requests to the authorization subsystem, generate operating instructions for itself (e.g., call requests, routing requests, state change requests), generate requests for the vehicle resource (e.g., call requests, routing requests, state change requests), receive vehicle data from the vehicle resource, and/or forward vehicle data to the third party application and [0037] - In one variation of API subsystem operation, the API subsystem receives a request from the third party application including a resource request and an access token (e.g., a system access token), and, in response to verification of the access token (e.g., received from the authorization subsystem), sends the requested resource to the third party application and [0050] - The parameter values can be determined in response to receipt of the vehicle request, in response to verification of the vehicle request, at a predetermined frequency (e.g., independent of responding to a vehicle request), and/or at any other suitable time and [0057] - vehicle data can be regularly pushed (e.g., at predetermined time intervals); and
a second control unit configured to acquire an access result including the vehicle data from the in-vehicle device by accessing the in-vehicle device and provide the access result to a request source via the interface unit when the interface unit receives the second access request ([0023] - customizable permission settings for different third party applications to access vehicle data and [0033] and [0036] - In one example of system use, a request from a third party application is routed through the API subsystem and routed to the appropriate adapter module for the vehicle endpoint, where the respective adapter module communicates the request (and/or receives information) from the vehicle resource and [0049] - As shown in FIG. 6B, determining parameter values can additionally or alternatively include retrieving vehicle data from the vehicle resource S131 (e.g., in a pull paradigm); receiving vehicle data from the vehicle resource S135 (e.g., in a push paradigm), and/or any other suitable process and [0050] - The parameter values can be determined in response to receipt of the vehicle request, in response to verification of the vehicle request, at a predetermined frequency (e.g., independent of responding to a vehicle request), and/or at any other suitable time and [0057] - vehicle data can be pulled in response to vehicle requests).
Regarding Claim 7;
Katta discloses the mobility service providing server according to claim 6.
Katta further discloses wherein the first access request and the second access request include user identification information for identifying a service user who provides a service using the mobility service providing server (FIG. 2 - client system (e.g., third party application) ↔ system and [0023] - First, the technology can provide an inventive distribution of functionality across a network. For example, the technology can connect vehicles, OEM platforms, third party applications, and user devices in a network facilitating customization of communication between parties in the network. For example, improvements in computer-related technology can be conferred from, for example, customizable privacy settings for vehicle data associated with different user accounts, customizable permission settings for different third party applications to access vehicle data and/or vehicle controls, customizable request rules for fulfilling data retrieval preferences of third party applications and sharing preferences of users and OEM platforms, and/or other modifiable features and [0031] - The vehicle is preferably configured to sample values for vehicle parameters at the sensor set at any given time; receive resource queries (e.g., from a remote system, from an OEM platform, etc.); verify resource access tokens (e.g., included in a resource query); transmit sampled values (e.g., to a remote system, to an OEM platform); and/or perform any suitable operation), and
the interface unit further includes
an authorization information memory unit configure to store the user identification information in association with an authorization class representing a range of the acquirable vehicle data (FIG. 2 – system and [0023] - For example, improvements in computer-related technology can be conferred from, for example, customizable privacy settings for vehicle data associated with different user accounts, customizable permission settings for different third party applications to access vehicle data and [0034] - The authorization subsystem functions to store user account information, such as vehicle identifiers that are associated with each user account, vehicle parameter permission settings (e.g., which vehicle parameters are available to third parties, on a per-vehicle basis), user profiles, user preferences, user credentials (e.g., login information to the system, to a third party application, to an OEM platform, etc.), OEM platform identifiers associated with each user account, and/or other user account information. The authorization subsystem can additionally or alternatively generate, store, and/or transmit any one or more of: third party information, such as authentication codes, access tokens, vehicle permission settings, user account permission settings, vehicle parameter permission settings (e.g., which vehicle parameters the third party has requested or has access to), query rate limits, and/or other third party account information. However, the authorization subsystem can be configured in any suitable manner); and
an authorization unit configured to reject acceptance of an acquisition request when the vehicle data to be acquired indicated in the first access request and the second access request is out of a range of an authority authorized by the authorization class according to the authorization class acquired from the authorization information memory unit based on the user identification information indicated in the first access request and the second access request ([0031] - The vehicle is preferably configured to sample values for vehicle parameters at the sensor set at any given time; receive resource queries (e.g., from a remote system, from an OEM platform, etc.); verify resource access tokens (e.g., included in a resource query); transmit sampled values (e.g., to a remote system, to an OEM platform); and/or perform any suitable operation and [0034] and [0036] and [0051] and [0054] and [0057] - For example, determining parameter values for fulfilling a vehicle request can be based on acceptance or rejection of a resource query transmitted to a vehicle resource).
Regarding Claim(s) 12; claim(s) 12 is/are directed to a/an method associated with the server claimed in claim(s) 6. Claim(s) 12 is/are similar in scope to claim(s) 6, and is/are therefore rejected under similar rationale.
Regarding Claim(s) 13; claim(s) 13 is/are directed to a/an method associated with the system claimed in claim(s) 1. Claim(s) 13 is/are similar in scope to claim(s) 1, and is/are therefore rejected under similar rationale.
Regarding Claim(s) 14; claim(s) 14 is/are directed to a/an medium associated with the server claimed in claim(s) 6. Claim(s) 14 is/are similar in scope to claim(s) 6, and is/are therefore rejected under similar rationale.
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.
Claim(s) 8-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Katta et al. (US 2017/0161973 A1) in view of Siegel (US 9,086,941 B1).
Regarding Claim 8;
Katta discloses the mobility service providing server according to claim 6.
Kata further discloses the first control unit is configured to extract [a] index corresponding to acquisition condition indicated in the first access request ... ([0023] - customizable permission settings for different third party applications to access vehicle data and [0033] and [0036] - However, the API subsystem can perform any other suitable functionality. The API subsystem is preferably a REST server (e.g., a stateless server), but can alternatively be a state server or have any other suitable configuration. In operation, the API subsystem can receive requests from the third party, redirect requests to the authorization subsystem, generate operating instructions for itself (e.g., call requests, routing requests, state change requests), generate requests for the vehicle resource (e.g., call requests, routing requests, state change requests), receive vehicle data from the vehicle resource, and/or forward vehicle data to the third party application and [0037] - In one variation of API subsystem operation, the API subsystem receives a request from the third party application including a resource request and an access token (e.g., a system access token), and, in response to verification of the access token (e.g., received from the authorization subsystem), sends the requested resource to the third party application and [0050] - The parameter values can be determined in response to receipt of the vehicle request, in response to verification of the vehicle request, at a predetermined frequency (e.g., independent of responding to a vehicle request), and/or at any other suitable time and [0057] - vehicle data can be regularly pushed (e.g., at predetermined time intervals), and
Katta fails to explicitly disclose wherein the memory unit includes
a first database configured to set, as a shadow, a group of pieces of the vehicle data spontaneously transmitted from the in-vehicle device and indicating a state of the vehicle on which the in-vehicle device is mounted at a same time, and store, as a shadow version, information indicating a time when the shadow has been generated, and
a second database configured to store an index generated corresponding to the shadow accumulated in the first database,
the index includes, with the vehicle that is a provider of the vehicle data belonging to the shadow as a provider vehicle, vehicle identification information that identifies the provider vehicle extracted from the shadow, position information about the provider vehicle, and the shadow version,
the first control unit is configured to extract the index corresponding to acquisition condition indicated in the first access request from the second database, and acquire the shadow identified from the extracted index from the first database.
However, in an analogous art, Siegel teaches wherein the memory unit includes
a first database configured to set, as a shadow, a group of pieces of the vehicle data spontaneously transmitted from the in-vehicle device and indicating a state of the vehicle on which the in-vehicle device is mounted at a same time, and store, as a shadow version, information indicating a time when the shadow has been generated (col. 4, lines 20-60 - Collection of the data allows for building of a "virtual vehicle" at the data server 100, as built by a virtual vehicle application, where specific information and trends of vehicle use may be used to anticipate future vehicle use and trends, as described further herein below. The virtual vehicle duplicates a multiplicity of measurable vehicle and related parameters, including environmental information ... This digital mirror, or "Avacar," created by the virtual application, consists of a dynamically updated, real-time model of a vehicle based off of On-Board Diagnostic information, data values reported from the sensor mirroring device itself (e.g., the telemetry device) (such as location, motion, and vehicle context), manufacturer-proprietary information made available to the connecting device, and a series of values bound to outputs such as actuation devices (e.g. door locks) or computer settings (e.g., writable radio presets) and col. 7, lines 64-col. 8, lines 29 - Specifically, the data server computer 120 includes a processor 122, a memory 124, a storage device 130, and one or more input and/or output (I/O) devices 132 (or peripherals) that are communicatively coupled via a local interface 134, each of which functions is a manner similar to that of the vehicle computer 30.), and
a second database configured to store an index generated corresponding to the shadow accumulated in the first database (col. 7, lies 15-29 - It should be noted that the historic user data need not be stored within the data server computer 120, but instead may be stored in a separate storage device of the data server 100 or at a remote location)
the index includes, with the vehicle that is a provider of the vehicle data belonging to the shadow as a provider vehicle, vehicle identification information that identifies the provider vehicle extracted from the shadow, position information about the provider vehicle, and the shadow version (col. 4, lines 10-60 - Data collected and transmitted by the telemetry device 22 includes, but is not limited to, identification of the vehicle, date and time when the vehicle is turned on, location of the vehicle, when the vehicle stops, and other vehicle use history, driver identification, On-Board diagnostic data, identifying information for linked devices, such as cellular telephones, and linked data, such as user calendars, all also referred to herein as historic user data... ... This digital mirror, or "Avacar," created by the virtual application, consists of a dynamically updated, real-time model of a vehicle based off of On-Board Diagnostic information, data values reported from the sensor mirroring device itself (e.g., the telemetry device) (such as location, motion, and vehicle context), manufacturer-proprietary information made available to the connecting device, and a series of values bound to outputs such as actuation devices (e.g. door locks) or computer settings (e.g., writable radio presets).
the first control unit is configured to extract the index corresponding to acquisition condition indicated in the first access request from the second database, and acquire the shadow identified from the extracted index from the first database (col. 4, lines 35-60 - At the server, server information itself, such as CPU load, may be paired with virtual vehicle data to aid in the decision-making process of the server for determining when to transmit data to the vehicle or a user device, as explained in further detail herein... In the simplest sense, the virtual vehicle application is provided with all measurable parameters relating to vehicle status in order to allow the digital representation of the operational state, health, and status of the physical vehicle with which the application is associated and col. 8, lines 42-44 - Additionally, the virtual vehicles may be access-controlled and secured to allow end-users to modulate and view the flow of information).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Seigel to the server of Katta to include disclose wherein the memory unit includes a first database configured to set, as a shadow, a group of pieces of the vehicle data spontaneously transmitted from the in-vehicle device and indicating a state of the vehicle on which the in-vehicle device is mounted at a same time, and store, as a shadow version, information indicating a time when the shadow has been generated, and a second database configured to store an index generated corresponding to the shadow accumulated in the first database, the index includes, with the vehicle that is a provider of the vehicle data belonging to the shadow as a provider vehicle, vehicle identification information that identifies the provider vehicle extracted from the shadow, position information about the provider vehicle, and the shadow version, the first control unit is configured to extract the index corresponding to acquisition condition indicated in the first access request from the second database, and acquire the shadow identified from the extracted index from the first database.
One would have been motivated to combine the teachings of Seigel to Katta to do so as it provides / allows where specific information and trends of vehicle use may be used to anticipate future vehicle use and trends (Seigel, col. 4, lines 11-39).
Regarding Claim 9;
Katta in view of Seigel discloses the mobility service providing server according to claim 8.
Seigel further discloses wherein the first control unit is configured to, when the acquisition condition includes time designation information designating a time or a time range, extract the index ...corresponds to the time designation information ([0036]-[0037] - In one variation of API subsystem operation, the API subsystem receives a request from the third party application including a resource request and an access token (e.g., a system access token), and, in response to verification of the access token (e.g., received from the authorization subsystem), sends the requested resource to the third party application and [0047] - Request rules can include any one or more of: variable limit rules (e.g., limiting data access to a particular time range, amount of data, types of data, etc.).
Seigel extract the index whose shadow version corresponds to ... information from the second database (col. 4, lines 35-60 - At the server, server information itself, such as CPU load, may be paired with virtual vehicle data to aid in the decision-making process of the server for determining when to transmit data to the vehicle or a user device, as explained in further detail herein... In the simplest sense, the virtual vehicle application is provided with all measurable parameters relating to vehicle status in order to allow the digital representation of the operational state, health, and status of the physical vehicle with which the application is associated and col. 8, lines 42-44 - Additionally, the virtual vehicles may be access-controlled and secured to allow end-users to modulate and view the flow of information).
Similar rationale and motivation is noted for the combination of Seigel to Katta in view of Seigel, as per claim 8, above.
Regarding Claim 10;
Katta in view of Seigel discloses the mobility service providing server according to claim 8.
Seigel further discloses wherein the first control unit is configured to, when the acquisition condition includes area designation information designating a geographical area, extract... the index indicating an area in which the position information is designated by the area designation information ([0019] - ...can automatically retrieve vehicle data (e.g., odometer readings, fuel level, location data, etc.) and [0036]-[0037] - In one variation of API subsystem operation, the API subsystem receives a request from the third party application including a resource request and an access token (e.g., a system access token), and, in response to verification of the access token (e.g., received from the authorization subsystem), sends the requested resource to the third party application.).
Seigel further teaches ...extract from the second database... (col. 4, lines 35-60 - At the server, server information itself, such as CPU load, may be paired with virtual vehicle data to aid in the decision-making process of the server for determining when to transmit data to the vehicle or a user device, as explained in further detail herein... In the simplest sense, the virtual vehicle application is provided with all measurable parameters relating to vehicle status in order to allow the digital representation of the operational state, health, and status of the physical vehicle with which the application is associated and col. 8, lines 42-44 - Additionally, the virtual vehicles may be access-controlled and secured to allow end-users to modulate and view the flow of information and col. 5, lines 11-29 - Historic virtual vehicles ...are used to feed information... and col. 7, lies 15-29 - It should be noted that the historic user data need not be stored within the data server computer 120, but instead may be stored in a separate storage device of the data server 100 or at a remote location)).
Similar rationale and motivation is noted for the combination of Seigel to Katta in view of Seigel, as per claim 8, above.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Katta et al. (US 2017/0161973 A1) in view of Madhok et al. (US 2014/0189888 A1).
Regarding Claim 11;
Katta discloses the mobility service providing server according to claim 6.
Katta further discloses wherein the second control unit includes an encryption information generation unit configured to generate encryption information ...to a notification destination designated by the second access request when the interface unit receives the second access request ([0041] - The vehicle request preferably includes one or more vehicle parameters and/or vehicle commands (e.g., vehicle actions, compression instructions, processing instructions to process raw data on the vehicle, encryption instructions, etc.), but can additionally or alternatively include an access token (e.g., a system access token used to verify the client's access), a redirection URI (e.g., to identify the location where the vehicle data should be sent), and/or include any other suitable information and [0066] - Controlling a vehicle can additionally or alternatively include receiving a confirmation that the control instructions associated with a vehicle command was received by a vehicle; receiving a confirmation that the vehicle was operated based on the vehicle command; receiving vehicle data indicative of vehicle command execution by the vehicle; and/or receiving any other suitable data from the vehicle subsequent to transmitting control instructions), and an encryption unit configured to encrypt the vehicle data acquired by requesting the in-vehicle device in accordance with the second access request using the encryption information generated by the encryption information generation unit and provide the encrypted vehicle data to a request source via the interface unit ([0041] - The vehicle request preferably includes one or more vehicle parameters and/or vehicle commands (e.g., vehicle actions, compression instructions, processing instructions to process raw data on the vehicle, encryption instructions, etc.), but can additionally or alternatively include an access token (e.g., a system access token used to verify the client's access), a redirection URI (e.g., to identify the location where the vehicle data should be sent), and/or include any other suitable information and [0066] - Controlling a vehicle can additionally or alternatively include receiving a confirmation that the control instructions associated with a vehicle command was received by a vehicle; receiving a confirmation that the vehicle was operated based on the vehicle command; receiving vehicle data indicative of vehicle command execution by the vehicle; and/or receiving any other suitable data from the vehicle subsequent to transmitting control instructions.),
Katta fails to explicitly disclose ...generate encryption information to transmit a key used to decrypt an encrypted text generated using the encryption information...
However, in an analogous art, Madhok teaches ...generate encryption information to transmit a key used to decrypt an encrypted text generated using the encryption information... ([0035] – The data is encrypted and stored and [0077] - The data encrypter 228 can encrypt the Vehicle X collection of information and associate a decryption key with the persistent digital identity).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Madhok to the server of Katta to include ...generate encryption information to transmit a key used to decrypt an encrypted text generated using the encryption information...
One would have been motivated to combine the teachings of Madhok to Katta to do so as it provides / allows reifies the vehicle as a digital identity in its own right and provides mechanisms to unify vehicle related data and associated relationships in a linked data cloud in a manner that is secure (e.g., encrypted) and gives the user the provenance over this unified data (Madhok, [0010]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892 attached.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARI L SCHMIDT whose telephone number is (571)270-1385. The examiner can normally be reached Monday-Friday 10am - 6pm (MDT).
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, Luu Pham can be reached at (571)270-5002. 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.
/KARI L SCHMIDT/ Primary Examiner, Art Unit 2439
Prosecution Insights