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 .
DETAILED ACTION
2. This action is in response to the Amendment filed August 28, 2026.
3. Claims 1 and 5 have been amended and new claims 7 and 8 have been added.
4. Claims 1, 5, and 6-8 have been examined and are pending with this action.
5. The Information Disclosure Statement filed June 18, 2026, has been considered.
Response to Arguments
6. Applicant’s arguments, filed August 28, 2026, with respect to the rejections of claims 1 and 5, previously rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, have been fully considered and is persuasive. The rejection of claims 1 and 5, previously rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, has been withdrawn, based on the amendment filed August 28, 2026.
Applicant’s arguments with respect to the rejections of claims 1 and 5-6, previously rejected under 35 U.S.C. 103 as being unpatentable over Lo (US 2014/0229462 A1) in view of Mizutani et al. (US 2001/0002450 A1), have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Crabtree et al. (US 2020/0349647 A1).
Crabtree has been cited to better teach the amended limitation of acquiring first data by communicating with the vehicle, wherein the first data is data generated by a sensor or an ECU of a vehicle and flows on an in-vehicle network that is not able to be directly browsed by a first terminal or a second terminal. Please see rejections below.
For these reasons above, and the rejections set forth below, claims 1 and 5-6 have been rejected and pending.
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.
7. Claims 1 and 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Lo (US 2014/0229462 A1) in view of Crabtree et al. (US 2020/0349647 A1).
As per claim 1, Lo teaches an information processing device comprising a processor configured to:
acquire first data (see Lo, Abstract: “A system and method that includes providing a query platform with a normalized query tool and a collection interface presenting result items of a collection; adding result items produced by the query tool to a collection, wherein adding a result item to the collection comprising: receiving a query input in a query syntax normalized across multiple query services, retrieving result data of the first query input through a service provider application programming interface (API),… and adding the result item to the collection; and adding at least a second result item to the collection, wherein the second result card is retrieved from a second external service provider API according to the context parameter.”; [0027]: “A card stream interface 110 functions as a collection of digital query result items (e.g., "cards"). The card stream interface 110 is a user interface for interaction with the query platform system.”; and [0051]: “The query platform can use machine learning and other data analysis techniques to predict similar services and queries. Customized services can preferably be fully integrated into the query platform. By enabling outside entities to create and integrate new services, the query platform can grow to supply an ever-increasing range of data formats. Services may additionally be monetized by accounting, metering, charging, measuring, or monitoring usage of a particular service.”);
generate second data by converting the first data such that the second data is on a format supported by a first terminal associated with a first user (see Lo, FIGURE 9, S300; and [0029]: “Normalized query inputs are generalized to common format that can be converted to a native query input supplied to an associated service API module.”; and [0053]: “Additionally, between any two cards there can exist an associative trail of metadata, where context of one card is used to augment or modify another card.”);
determine whether the request is sent from the first terminal or the second terminal (see Lo, [0068]: “a collection and more specifically at least one result card may be rendered differently depending on who is accessing the collection. The augmentation of the collection is preferably automatic based on settings of the user, usage patterns of the user, or detected properties of the user.”),
transmit the second data to the first terminal in a case where the processor determined that the request is sent from the first terminal (see Lo, [0027]: “The card stream interface 110 is preferably presented in a website but may alternatively or additionally be implemented as a mobile application, a desktop application or any suitable application rendering a user interface… The cards are preferably rendered in the stream as a vertically scrollable list of cards. A user can review the previous queries and results (explicitly saved or from query history) by scrolling through the cards and optionally expanding upon queries through interacting with previous cards.”; and [0034]: “In one variation, a card is rendered in a consistent manner across queries to a particular service or more preferably to queries to similar services… ”); and
generate third data by deleting the information from the second data in a case where the processor determines that the request is sent from the second terminal (see Lo, [0068]: “In a variation of a preferred embodiment, modifying a collection can include presenting and augmenting the collection according to a second user S330, as shown in FIG. 18… a collection and more specifically at least one result card may be rendered differently depending on who is accessing the collection. The augmentation of the collection is preferably automatic based on settings of the user, usage patterns of the user, or detected properties of the user… In this way sensitive data may be removed and non-sensitive data of the result card still presented. Enforcing the permissions may be used such that result cards may be used for retrieving personal or sensitive information that would not be appropriate for displaying to other viewers of a collection.”), and
transmit the third data to the second terminal in response to generating the third data (see Lo, [0068]: “… and non-sensitive data of the result card still presented”).
Lo does not explicitly teach that the first data is acquired by communicating with a vehicle, wherein the first data is data generated by a sensor or an ECU of a vehicle and flows on an in-vehicle network that is not able to be directly browsed by a first terminal or a second terminal.
Crabtree teaches that the first data is acquired by communicating with a vehicle (see Crabtree, [0083]: “It should be appreciated that some or all components illustrated may be combined, such as in various integrated applications, for example Qualcomm or Samsung system-on-a-chip (SOC) devices, or whenever it may be appropriate to combine multiple capabilities or functions into a single hardware device (for instance, in mobile devices such as smartphones, video game consoles, in-vehicle computer systems such as navigation or multimedia systems in automobiles, or other integrated hardware devices)”),
wherein the first data is data generated by a sensor or an ECU of a vehicle and flows on an in-vehicle network that is not able to be directly browsed by a first terminal or a second terminal (see Crabtree, [0051]: “The result of transformation pipeline analysis may then be modified by results from batch analysis of the data stream and output 1006 in format predesigned by the authors of the analysis with could be human readable summary printout, human readable instruction printout, human-readable raw printout, data store, or machine encoded information of any format known to the art to be used in further automated analysis or action schema”; and [0060]: “In the embodiment, the sensor data is passed without transformation to the data management engine 220, where it is aggregated and organized for storage in a specific type of data store 225 designed to handle the multidimensional time series data resultant from sensor data. Raw sensor data can exhibit highly different delivery characteristics. Some sensor sets may deliver low to moderate volumes of data continuously”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Lo in view of Crabtree so that the first data is acquired by communicating with a vehicle, wherein the first data is data generated by a sensor or an ECU of a vehicle and flows on an in-vehicle network that is not able to be directly browsed by a first terminal or a second terminal. One would be motivated to do so because it is well-known, widely-implemented, routine, and conventional to acquire raw data (machine-readable, not browsable) from any networking devices so long as the devices can be physically or wirelessly connected.
As per claim 5, Lo and Crabtree teach an information processing method comprising:
acquiring first data by communicating with a vehicle, wherein the first data is data generated by a sensor or an ECU of a vehicle and flows on an in-vehicle network that is not able to be directly browsed by a first terminal or a second terminal (see Claim 1 rejection above);
generating second data by converting the first data such that the second data is on a format supported by a first terminal associated with first user (see Claim 1 rejection above);
determining whether the request is sent from the first terminal or the second terminal (see Claim 1 rejection above);
transmitting the second data to the first terminal in a case where the request is determined to be sent from the first terminal (see Claim 1 rejection above);
generating third data by deleting the information from the second data in a case where the processor determines that the request is sent from the second terminal (see Claim 1 rejection above); and
transmitting the third data to the second terminal in response to generating the third data (see Claim 1 rejection above).
As per claim 6, which depends on claim 1, Lo further teaches wherein the first data is not in a format supported by either the first terminal or the second terminal (see Lo, [0029]: “Normalized query inputs are generalized to common format that can be converted to a native query input supplied to an associated service API module.”).
As per claims 7 and 8, which respectively depend on claims 1 and 5, Crabtree further teaches wherein the generation of the second data includes one or more processes of flattening hierarchical data, deleting rows without values, deleting unused labels, removing outliers of latitude and longitude data, correcting time stamps, and aggregating or deleting duplicate values, conversion of label names, deletion of abnormal values, linear interpolation and left-right inversion processing of the first data, zero point correction, data shaping processing, or format conversion of the first data (see Crabtree, [0049]: “The sensor fusion suite then receives the collection of sensor data, data from internet or other networks, and manually entered data 820, causing it to ingest received data and record the data and timestamps of data in a connected or internal MDTSDB 830. Internal to the sensor fusion suite, data from an ingestion component is sent to a data transformer 840, where the data transformer acts on received data if necessary, for instance by normalizing inputs, stripping unnecessary data away, and more if applicable 850… Semantified views on incoming data (addressing cleanliness and deduplication type issues, for instance) support the use of such incoming heterogeneous data, including with probabilistic evaluation via uncertainty quantification or UQ for use in triggers/truth and sensor validation.”).
Conclusion
8. For the reasons above, claims 1 and 5-8 have been rejected and remain pending.
9. 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.
10. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL Y WON whose telephone number is (571)272-3993. The examiner can normally be reached on Wk.1: M-F: 8-5 PST & Wk.2: M-Th: 8-7 PST.
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, Nicholas R Taylor can be reached on 571-272-3889. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Michael Won/Primary Examiner, Art Unit 2443
Prosecution Insights